Guides

Sandbox testing

Deterministic scenarios let you test success, failure, timeout and insufficient-funds paths on demand.

Choosing an outcome

The simulator looks at the last four characters of the destination’s account_number (bank accounts) or phone_number (mobile money):

Anything not listed below: the transfer succeeds (HTTP 201, status: "succeeded").
Ends with 0002 — HTTP 201. Transfer is created and immediately fails with `failure_code: destination_account_closed`.
Ends with 0003 — HTTP 504. Simulates a provider timeout. The transfer is recorded as failed and the reservation is released.
Ends with 0004 — HTTP 502. Simulates a provider-side error. The transfer is recorded as failed and the reservation is released.
Amount plus fee above the available balance — HTTP 402 insufficient_funds; no transfer is created.
Invalid input — HTTP 400 validation_error with the failing param.

For timeouts and provider errors the error body includes transfer_id. Fetch it with GET /transfers/{id} to see the failed transfer, and confirm the reservation was released with GET /balances.

Test funds

Each Sandbox wallet starts with 1,000,000 units of its currency. Add more simulated funds with POST /test/fund:

cURL

curl -X POST "https://api.gloresend.com/sandbox/v1/test/fund" \
  -H "Authorization: Bearer $GLORESEND_TEST_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "amount": 500000,
    "currency": "XOF"
  }'

Webhooks in the Sandbox

Sandbox transfers emit real transfer.succeeded and transfer.failed webhook deliveries to your Sandbox endpoints, signed exactly like Live. Use Send test event in the dashboard to trigger test.ping.

What the Sandbox does not simulate

Delayed settlement — Sandbox transfers resolve within the request.
Provider-specific rules such as corridor limits or name matching.
Real-world compliance reviews.