Skip to main content
Every Business operates in two parallel environments simultaneously:
  • Sandbox: provider calls are routed to mock implementations. No money moves, no fees accrue. Open to every Business from the moment its email is verified.
  • Production: provider calls are real and money moves. Unlocked only once the Business’s verification (KYB) is approved. See Go live.
Both environments hold the same kinds of data (beneficiaries, bank accounts, payouts, webhook subscriptions, reports) as two disjoint sets. Nothing you create in sandbox exists in production, and vice versa.

​
The credential selects the environment

There is no environment parameter anywhere in the API. The environment comes from the credential making the call:
A key is bound to one Business and one environment at issuance. A sandbox key cannot read or modify production rows; a cross-environment (or cross-tenant) fetch returns 404, because the row is simply not visible to that credential. The same rule applies to dashboard sessions, which carry an environment toggle. This design removes an entire class of integration bug: there is no request that accidentally targets the wrong environment, because the environment is not writable per request.

​
What sandbox is for

Sandbox is a full copy of the platform against fake providers. The complete payout loop works (funding, beneficiary registration, approval, dispatch, disbursement confirmation, webhooks, reporting), with the sandbox provider confirming disbursements so payouts reach terminal states. Two things differ from production by design:
  • The sandbox wallet holds test money: it is provisioned when your business profile is completed, and POST /v1/business/funding-account/sandbox-balance sets it to whatever you like. That endpoint is rejected outside sandbox.
  • Beneficiary-facing emails sent from sandbox carry a sandbox banner.
Build and test your whole integration in sandbox first; going live is then a credential swap plus a real funding path, not a rewrite.