Sandbox scenarios
Test failures before your customers find them.
Use these test mobile numbers in your own Sandbox requests to reproduce approvals, declines, delays, and unknown outcomes without moving money. They work in either currency: send USD or ZWG. The dashboard drills run in US dollars.
Test numbers for your own requests
| Mobile number | Scenario | Status sequence | Status | Code |
|---|---|---|---|---|
+263 77 000 0001 | Instant approvalThe customer approves the prompt on their phone, and the payment is Paid within seconds. | requires_action → succeeded | succeeded | — |
+263 77 000 0002 | Insufficient fundsThe customer's wallet doesn't have enough money, so the payment fails and no money moves. | requires_action → failed | failed | — |
+263 77 000 0011 | Provider declineThe provider declines the payment, so it fails and no money moves. | requires_action → failed | failed | provider_declined |
+263 77 000 0012 | Blocked by a risk checkA risk check blocks the payment, so it fails with its own failure code and no money moves. | requires_action → failed | failed | blocked_by_risk |
+263 77 000 0007 | Slow providerThe provider doesn't answer in time. The payment shows Confirming until our status check finds it Paid. | processing → succeeded | succeeded | — |
+263 77 000 0013 | Long confirmationThe provider keeps saying the payment is still in progress. It stays Confirming through several status checks, then turns Paid. | processing → processing → processing → succeeded | succeeded | — |
+263 77 000 0004 | Late approvalThe customer takes a while to approve, so the payment shows Confirming before it turns Paid. | requires_action → processing → succeeded | succeeded | — |
+263 77 000 0005 | Duplicate confirmationThe provider confirms the same payment twice. We record it once: one Paid payment and one payment_intent.succeeded event. | requires_action → succeeded | succeeded | — |
+263 77 000 0006 | Amount mismatchThe provider reports taking a different amount from the one you asked for, so we hold the payment for review instead of marking it Paid. | requires_action → processing | processing | manual_review |
+263 77 000 0009 | Customer declines the promptThe customer declines the prompt on their phone, so the payment is canceled and no money moves. | requires_action → cancelled | cancelled | — |
+263 77 000 0010 | Reconciliation mismatchThe payment is Paid, but it's missing from the provider's daily report, so reconciliation flags it for follow-up. | requires_action → succeeded → exception_opened | succeeded | succeeded_with_exception |
+263 77 000 0003 | Customer doesn't respondThe customer ignores the prompt. After 2 minutes the provider confirms no money was taken, and the payment expires. | requires_action → expired | expired | — |
+263 77 000 0008 | Provider outageThe provider is down, so the API answers 503. Nothing reaches the customer's phone and no money moves. | requires_confirmation | requires_confirmation | rail_unavailable |
Drills you start from the dashboard
These drills build on an instant approval, so a test number alone cannot start them. Run them from Developers → Sandbox scenarios.
| Drill | Status sequence | Status | Code |
|---|---|---|---|
| Refund lifecycleA few seconds after the test payment is Paid, we refund it in full. The provider accepts the refund, then confirms it, and the payment reads Refunded. | succeeded → refund_processing → refunded | succeeded | refunded |
| Webhook outageThe payment is Paid, but the first three deliveries of its event fail on our side, without calling your endpoint. You then replay the event, and it reaches your endpoint. | succeeded → delivery_retrying → replay_delivered | succeeded | —Add an enabled Sandbox webhook endpoint that receives payment_intent.succeeded first. |
Agents can run these scenarios too.
Our Model Context Protocol (MCP) endpoint, POST /mcp, runs in our staging sandbox only, with its own credential; its tools read this catalog, run a scenario, and read the resulting payment and events (see the tools). Invited merchants can ask Integration help for access.
A Sandbox pass doesn't approve Live.
For each run, record the scenario, the payment ID, and the statuses you observed. A passing sandbox run never approves live access on its own.