IOSOR

IOSOR Learn

Partial failover send without double charge

Mid-flight rail switch on one client intent must settle once and never invent Delivered on backup — white-label prepaid honesty for partial failover.

A mid-flight failover is still one client intent. Primary may accept, time out, or reject after a hold; backup may then carry the same unit. That switch must not open a second settle, invent Delivered the backup never earned, or blur into a user retry.

IOSOR is white-label prepaid. USD 20 is the public minimum top-up (pilot floor). Soft review near USD 1,000/month is when partial-send bugs multiply burn. Ordered path: Primary rail fails: ordered backup without double-debit. Live gates: Failover gates before any Live badge. Hold: Prepaid hold before first debit.

Mid-flight switch is still one intent

Partial failover means the unit left the buyer API once, then ops moved rails because primary could not finish. The client still sees one message row, one idempotency key, one money story. Do not treat the backup hop as a new send or mint a second hold. Reuse identity from idempotency, retries, and money.

If the hold never settled and the unit was never owed, release via Hold fail auto-refund and status truth. Partial send is not permission for ghost settles on two rails.

What “partial send” means in money terms

Stage Money Client truth
Hold on intent Reserve once Funds protected for one unit
Primary accepts then fails mid-path One settle candidate Pending / needs attention — not Delivered
Backup accepts same key No second settle Same debit; rail changed ops-side
Backup never completes Failed or release No invented success

“Partial” is ops language for the hop. Finance counts one billable debit when any rail accepted under that key — never two. User resend is a new intent with a new key.

Never invent Delivered on the backup

Switching rails does not prove inbox. Backup may accept and still return failed DLR, timeout, or silence. Client status follows evidence: accepted, pending, delivered, failed, needs attention — white-label only. Ops may log the fulfilling rail; buyers must not see brand strings.

Inventing Delivered “because failover fired” breaks trust and finance. Wait for real terminal signals. If backup fails after primary accepted, keep one money identity and an honest failed outcome — do not double-charge to “try harder.

Distinct from retry policy and ordered path

This is mid-flight money on a switch already started — not when to retry a failed DLR (DLR failed retry policy under prepaid) and not the pre-written primary → backup sequence (ordered-path sibling). A clean retry policy does not fix a double settle; an ordered path without partial-send rules still invents Delivered.

Buyer checklist for partial failover

  1. One idempotency key covers primary and backup money for the same intent?
  2. Backup can accept without a second settle?

Start with IOSOR

Force a mid-flight primary fail on a non-production corridor. The ordered backup must take the same intent key. Export one debit, the remainder, and an honest terminal status. If primary already sent part of a concatenated body, do not invent Delivered on backup and do not open a second settlement for those parts.

IOSOR takeaway

A partial failover is still one customer intent.

Do: keep one key and one debit across the mid-flight hop.

Don’t: invent Delivered on a backup that never owned the parts, or charge the remainder twice.

Was this guide helpful?

Related guides