Skip to main content
Every integration starts in the sandbox. When you register an application in the business portal, it is issued sandbox application credentials by default. The sandbox exposes the same API contract as production, so you can build and test the full flow before requesting production access.
Base URL: https://api.zeam.money/gw/v1The sandbox uses the same base URL as production. Which environment a request runs in is determined by your application’s registration and role, not by the host. Sandbox and production credentials are separate.

What the sandbox is for

  • Authenticating: issuing an access token and calling protected endpoints.
  • Building the payment flow end to end: wallets, connectors, quotes, and P2P, swap, and off-ramp payments.
  • Exercising deterministic off-ramp outcomes.
  • Testing your webhook handling.
  • Validating your error handling against the RFC 7807 contract.

Sandbox versus production

  • Same base URL. Sandbox and production share https://api.zeam.money/gw/v1; your application’s registration determines the environment, so there is no host to switch.
  • Separate credentials. Sandbox and production credentials are distinct and not interchangeable. See Register your application.
  • Two specific off-ramp outcomes are simulated. A sender MSISDN ending in 111 or 000 deterministically succeeds or fails without reaching a real payout provider (see below) — this is the only simulation in the sandbox.
  • Same contract. Endpoints, request and response shapes, and error formats match production, so your integration code does not change between them.
A sandbox token does not provide test isolation. See Sandbox limitations below before you create records or move funds.
Treat the sandbox as a shared, non-production environment. Do not send real personal data, real customer identifiers, or anything you could not put in a test system.

Off-ramp testing

In the sandbox, off-ramp execution is simulated so you can test both outcomes deterministically. The simulator decides the result from the sender’s MSISDN (mobile number):
  • Sender MSISDN ends in 111: the off-ramp succeeds.
  • Sender MSISDN ends in 000: the off-ramp fails.
These are the only two guaranteed-simulated outcomes, and only apply in the sandbox. A sender MSISDN ending in anything else is not guaranteed to be simulated at all — it may attempt a real payout through the actual connector. Never rely on any MSISDN ending in production, where the real payout provider always determines the outcome. There is currently no equivalent way to simulate an off-ramp to a bank-account connector — the MSISDN convention only applies to mobile-money-style connectors.
The simulator evaluates the sender MSISDN that the platform resolves for the off-ramp. The gateway’s POST /v1/payments/offramp request does not itself carry a sender MSISDN field.
Off-ramps are asynchronous: a submission returns 202 Accepted with a transactionRecordId, and the simulated outcome arrives afterwards. Poll the transaction or receive webhooks to observe it.
1

Get a quote

Request a quote for the connector and amount first — POST /v1/payments/offramp executes against a quoteId, it does not create one. Quotes expire roughly two minutes after creation, so request one right before you submit.
cURL
200 OK
Use the returned quoteId in the next step before it expires.
2

Submit the off-ramp

cURL
202 Accepted
3

Confirm a success (sender MSISDN ends in 111)

A successful simulation moves the transaction to completed and emits the IntentSuccessful webhook event.
GET /v1/transactions/{transactionRecordId}
4

Confirm a failure (sender MSISDN ends in 000)

A failed simulation moves the transaction to failed and emits the IntentFailed webhook event.
GET /v1/transactions/{transactionRecordId}

Sandbox limitations

The sandbox is for integration testing, not load testing or production traffic. A sandbox token is a credential and role distinction only — it does not provide test isolation from production:
  • Wallets and beneficiaries are real, permanently persisted records — including real on-chain wallet funding — whether created with sandbox or production credentials. There is no synthetic or disposable version, and nothing to reset or discard afterward.
  • Beneficiaries created with a sandbox token are not separated from production. They appear in the same list as beneficiaries created with production credentials — there is no per-environment scoping.
  • P2P transfers are never simulated, regardless of token type. Sending from a wallet created with sandbox credentials moves real funds, including to a wallet or beneficiary that was created with production credentials.
  • Off-ramp simulation only covers the two MSISDN endings above. Any other sender MSISDN may attempt a real payout — see the warning in Off-ramp testing.
  • There is no way to simulate an off-ramp to a bank-account connector. The MSISDN convention only applies to mobile-money-style connectors.
Treat any sandbox call that creates a record or moves funds as if it were production, unless it is specifically the MSISDN-based off-ramp simulation described above.

Moving to production

When your integration works end to end in the sandbox, review Moving to production.