IOSOR

IOSOR Learn

When a prepaid hold fails: auto-refund and status truth

Treat a failed prepaid hold as a wallet event: release or refund automatically, export honest statuses, and never paint Activated or Delivered on money that did not settle.

A prepaid hold that cannot complete must leave money and status finance can defend: release to available, explicit refund of a settled amount, or a named freeze until evidence exists. Success while funds are stuck destroys ledger trust.

IOSOR is white-label prepaid. Same rule for messaging, verification, email, voice, and JIT number intents on one wallet. The USD 20 minimum top-up is a pilot floor, not proof fail paths work. Review near USD 1,000/month only makes fail rows more visible.

Fail is a wallet event, not a toast

Spinners and “pending” banners are not money truth. After a fail, the wallet released the hold, refunded a debit, or froze the intent with an exportable reason. Success while a reservation stays open means the ledger lies. Pair with Prepaid hold before first debit for the happy path; this page is the fail path.

Outcome Wallet movement Client-readable status
Validation reject before work No hold or immediate release Rejected — no debit
Fulfillment fail under hold Full release of reserved amount Failed — funds returned
Timeout without completion evidence Release after expiry policy Timed out — funds returned
Settled amount that must reverse Explicit refund row Refunded — linked to original intent
Unknown mid-flight result Freeze retries; no second debit Needs attention — investigation

Auto-refund and release must be automatic

“Ops will fix it” is not a product. Release and refund fire from the same rules that created the reservation. Duplicates with the same idempotency key reuse the original money result — see idempotency, retries, and money. Partial batches settle completed units and return the unused portion in one export.

Release restores unused reserve; refund reverses a settled debit. Clients need timestamps, reasons, and business intent ID. Silent balance edits without a ledger row are forbidden. Number swap after a failed buy: DID order fail refund and swap; this article is money truth for every channel.

Status vocabulary finance can export

Short CSV list: funds held; completed / settled; released; refunded; needs attention; cancelled.

Do not invent “Activated”, “Delivered”, or “Live” without an assigned resource or billable unit. “Needs attention” is a work queue, not success. A status without amount, currency, and correlation ID is theatre.

Never fake Activated or Delivered

Fake success badges burn trust faster than empty search. Messaging fail ≠ delivered; unopened verify ≠ verified; unassigned JIT ≠ Activated. Low balance and over-cap reject before hold when possible — low-balance stop controls — so money never enters a dead-end hold.

Buyer checklist for fail honesty

  1. Does every failed hold end in release, refund, or needs-attention with an owner?
  2. Are release and refund automatic from product events, not chat?
  3. Can finance join fail rows to the original intent ID without support?
  4. Do retries with the same key move money at most once?
  5. Check named owner + UTC export for this control?

Start with IOSOR

Force a prepaid hold that cannot complete: cap, reject, or short funds. Prove money returns to available or an explicit refund row. Export the fail status finance can defend. Replay the same key with no second movement. This is hold-fail money truth, not a dead-assign release.

IOSOR takeaway

A failed hold is a wallet event, not a success play.

Do: auto-release or refund and a named status. Don’t: invent Activated or Delivered.

Was this guide helpful?

Related guides