Skip to main content
The sandbox is a full copy of the API with no real money in it. Everything behaves the way production does — the same calls, the same events, the same states — except that the banks and networks behind it are stand-ins that answer on demand instead of on their own schedule. That is what makes it testable: outcomes you would wait days for in production are reachable in seconds, and outcomes you would never want in production are reachable at all.

​
Pointing at it

Sandbox is the same host with a /sandbox prefix:
The prefix goes on every path, not just the first call. …/sandbox/v1/users, …/sandbox/v1/payouts, and so on. Putting it only on the call you copied from a guide is the most common way a “sandbox” integration ends up talking to production.

​
What you need

Sandbox credentials are separate from production ones, and a sandbox key does not work against production. Ask for both at the same time — see Access. You also want your webhook endpoint registered for sandbox before you start, because several steps announce themselves only that way. Test your endpoint covers reaching a handler you are still writing.

​
How it differs from production

Outcomes are yours to choose. In production, whether an application is approved is the bank’s decision. In sandbox it follows from what you send — see Forcing outcomes. Timing is not representative. Sandbox settles in seconds what a real rail takes hours or days to do. Build your flow so that it tolerates waiting, and do not calibrate timeouts against what you see here. Accounts open with a balance. A sandbox account carries an opening float, so a payout can succeed before you have deposited anything. Read the balance rather than assuming it reflects only your own deposits.

Forcing outcomes

Approval, rejection, and the values that produce each one.