IOSOR Learn
Event order vs ledger posting
Out-of-order DLR and MO events must not break prepaid debit posting rules — arrival sequence is not money law.
Networks deliver callbacks out of order. A late DLR, early MO, or status flip before settle must not invent a second debit or rewrite a settled row. This page is the posting-order contract: ledger rules survive reordering — not a correlation-ID primer and not an MO-vs-MT billing essay.
Related: Duplicate webhook must not create a second debit, Webhook consumer ops at volume, Signature and replay-window gate, Webhook contract before the first send, Debit rows vs delivery status ledger.
Arrival order is not ledger law
HTTP arrival is a transport accident. Money posts under hold → settle → outcome-update — not “whatever callback landed last.” Soft USD 1,000/month treats reordering as a finance incident when product shows success while the ledger double-moves. USD 20 proves a forced late DLR never opens a parallel debit. Same-ID replays: Duplicate webhook must not create a second debit. This page owns different events, wrong sequence.
What out-of-order looks like
| Arrival pattern | Safe posting | Unsafe reaction |
|---|---|---|
| DLR before settle | Pending; settle once under hold | Debit from DLR alone |
| Failed then delivered | Update outcome in place | Second charge for flip |
| MO before MT correlate | File inbox; join on MT settle | Charge MO as outbound |
| Status after refund | No new money; annotate | Resettle released intent |
| Two terminals, one intent | One money row | Two debit rows |
Workers apply the same table at volume: Webhook consumer ops at volume. Authenticity first: Signature and replay-window gate.
Posting rules that survive reordering
Mint hold and idempotency keys before side effects (Webhook contract before the first send). Settle once per billable intent; later events update outcome only. Never open a parallel debit for early/late DLR or MO. Reject or park outside the signed window — no invented success. Export joins by intent — not arrival timestamp. Money↔outcome: Debit rows vs delivery status ledger. Soft volume language stays blocked while out-of-order smoke shows two money lines for one intent.
Lag is normal; double money is not
Pending after settle is ordinary. A second charge for the same key because a callback arrived late is a bug.
Buyer checklist for event order vs posting
- Hold/settle independent of HTTP arrival?
- Late DLR updates outcome — never a second debit?
3.
Start with IOSOR
In the console: Event order vs ledger posting must reconcile by shared id.. Name the owner and gates before you scale.
Related: duplicate webhook no second debit webhook consumer ops at volume
IOSOR takeaway
Duty-ready ops discipline—not brochure copy.
Do: name the owner and pass the gate. Do not: skip the gate.
Was this guide helpful?
Related guides
- Monitoring Consumer Webhook Endpoint Health Metrics
Learn how to track receiver response latency and status codes within the IOSOR platform to proactively manage webhook health and prevent callback failures.
- Configuring Threshold Webhook Alerts for Wallet Floors
Learn how to configure automated balance threshold webhooks in IOSOR to monitor prepaid accounts, prevent service interruptions, and manage JIT number provisioning effectively.
- Processing Just-in-Time Provisioning Webhook Events
Master the real-time lifecycle of inbound channels using IOSOR JIT provisioning webhooks. Automate number assignment and ledger updates for your white-label CPaaS.