IOSOR

IOSOR Learn

Failover ledger tags finance can reconcile

Tag which rail fulfilled each prepaid unit without exposing brands so finance can join wallet, delivery, and switch exports on one opaque identity.

When failover hops a unit primary → backup, finance still needs which rail fulfilled the billable attempt — with no upstream brands on the client export. A ledger tag is that join: opaque rail identity, debit id, intent key, and terminal status.

IOSOR is white-label prepaid. USD 20 is the pilot top-up floor; soft review near USD 1,000/month is when missing tags become night spreadsheets. Hold: Prepaid hold before first debit. Fail: Hold fail auto-refund and status truth. Ordered path: Primary rail fails: ordered backup without double-debit. Mid-flight: Partial failover send without double charge.

What a failover ledger tag must carry

A tag is not marketing copy. It is a stable field set on the settled or released money row so finance knows which ops rail completed the unit, under which intent, with which terminal outcome — without ops chat.

Field Finance use
Intent / idempotency key Join wallet ↔ product
Debit or release id Money moved once
Rail tag (opaque) Fulfilling path — brand-safe
Corridor / channel SMS ≠ voice ≠ verify
Terminal status Delivered, failed, released, needs attention
Switch timestamp Primary → backup fired

Without the rail tag, debit + DLR cannot explain failover burn spikes. Without the intent key, tags float unjoined.

Brand-safe rail identity for finance joins

Ops may know rail A vs rail B. Client and finance exports must not print upstream brands — opaque codes (rail_01, rail_02) or UUIDs in an ops vault. Buyers reconcile IOSOR money and outcomes, not third-party invoices on the CSV.

Live honesty: Failover gates before any Live badge. Latency ≠ brand column — DLR, latency, and failover. White-label: path visible to ops, joinable for finance, invisible as a brand in buyer UI.

Join keys across wallet and delivery exports

Finance joins wallet ledger, delivery/status export, and failover switch log. Shared keys: intent id, debit id, opaque rail tag. Prefer one row with all three over three CSVs at 03:00.

Night timeline: Failover incident export at 02:00. Roles: Failover ops runbook at live volume. Tag without join key is decoration; join key without tag cannot explain which path burned the unit.

Distinct from debit-row vs DLR ledger article

Debit rows vs delivery status ledger teaches money↔outcome without double settle. This page adds which rail fulfilled under failover without brand leaks. Debit↔DLR can be green while a backup hop stays unexplained — rail tags close that gap.

Buyer / finance checklist for tags

  1. Every settled failover unit carries an opaque rail tag?
  2. No upstream brands on client or finance exports?

Start with IOSOR

Force one primary-to-backup hop on a non-production corridor. Export wallet and delivery on the same intent key. Finance must see one debit, one opaque rail tag, and one terminal status. The tag names the hop, never a rail brand. Repeat the key — no extra movement. Prove that join before Live volume.

IOSOR takeaway

A failover tag is a join key for finance, not a marketing label.

Do: stamp one opaque hop tag on wallet and delivery; keep one debit.

Don’t: print a rail brand on the export, or leave finance guessing which hop ate the money.

Was this guide helpful?

Related guides