IOSOR Learn
Release prepaid hold after failed DID assign
Learn how IOSOR handles failed DID assignments by instantly releasing prepaid holds to prevent silent balance freezes.
A failed DID assign must release its prepaid hold so the wallet can try again.
Understanding JIT Number Provisioning and Prepaid Holds
When a tenant initiates a number acquisition request via API, IOSOR avoids holding physical inventory or pretending to operate inventory stock. Instead, numbers are provisioned via JIT upstream interfaces. To protect against race conditions, the platform places a temporary authorization hold on the active wallet. If the operation succeeds, this hold transitions into a confirmed MRC debit. However, network timeouts, invalid E.164 formatting, or carrier rejections can interrupt this flow.
Anatomy of an Assignment Failure Scenario
Consider an automated sub-account purchasing an E.164 DID for an OTP or SMS campaign. The API dispatches the provisioning payload, triggering the standard balance check against the USD 20 prepaid floor. The gateway places the hold, but the carrier rejects the assignment due to a localized routing glitch. Without state management, this unlinked reserve could linger, locking capital and halting automated traffic. IOSOR listens for negative DLR feedback or webhook timeout signals, ensuring the reconciliation engine steps in immediately.
The Automatic Refund and Reconciliation Loop
When a provisioning transaction fails, manual intervention is unnecessary. The reconciliation engine triggers an automatic release sequence. This mechanism operates similarly to the processes detailed in our guide on Hold fail auto-refund and status truth, ensuring funds are never left in limbo. If an order encounters complications further down the pipeline, operators can also reference DID order failure refund and switch to maintain complete ledger transparency.
Preventing Silent Balance Freezes in High-Volume Operations
Silent balance freezes destroy tenant trust, especially when managing automated campaigns that scale rapidly. What happens when funds get trapped by a phantom hold? Downstream tasks such as HB checks, webhook dispatches, or emergency number swaps stall instantly. By tying hold releases directly to negative HB feedback and gateway error codes, IOSOR protects platform liquidity. Tenants operating near the soft review threshold of USD 500 avoid unexpected credit blocks.
Comparison of Hold States and Resolution Outcomes
| State | Action Taken | Balance Impact | Recovery Time |
|---|---|---|---|
| Success | Convert to MRC | Decreased by rate | Instant |
| Timeout | Release hold | Fully restored | < 500 ms |
| Reject | Drop reserve | Fully restored | Immediate |
| Error | Trigger refund | Fully restored | Automated |
Start with IOSOR
When assign returns reject or timeout, drop the authorization hold on that order id. Export hold-dropped with the fail reason on the same row. A phantom reserve after a dead assign freezes the wallet for the next try.
Related: Caller ID vs messaging From: voice live does not mean SMS live E.164 normalize before DID bind: plus, zeros, and spaces.
IOSOR takeaway
Failed assign must release the hold, or the wallet lies.
Do: auto-release on reject or timeout. Don’t: keep a silent freeze after a dead assign.
Was this guide helpful?
Related guides
- Second-owner DID handover: who may assign and release
Master operational boundaries, JIT provisioning, and prepaid financial thresholds during second-owner DID handovers.
- Spend Cap Per DID: Rent Plus MT Burn On One Number
Control per-number exposure in your white-label CPaaS with a combined spend cap for MRC and outbound mobile terminated traffic.
- Inbound webhook routing on DID: MO without owner loses STOP
Route inbound webhooks to the owning account securely. Prevent orphan MO events and missed opt-outs in white-label prepaid CPaaS.