Sandbox

Run test flows for every product before going to production, with no real funds.

Test every product with no real funds before going live. Bank transfers and identity checks are driven end to end with the test calls below; card flows run against the card provider’s own test environment.

One key, per-product permissions

A partner gets one API key, not one per product. What that key may reach is a set of product permissions carried on the key itself, so the same key can be opened up one product at a time as you go live with each.

Permission	Opens
deposits	Crypto deposits - quote, transaction, status
cards	Card on-ramp and card off-ramp
bank	Bank transfers - on-ramp and off-ramp
virtual-accounts	Creating and managing virtual accounts, and paying out from them

A missing permission is a refusal, never a default. Calling a product your key does not carry returns permission_denied rather than quietly working - so a key scoped to deposits cannot spend on cards by accident.

The same key also carries which chains and tokens you may take payment from, so scope is not limited to the product level.

Test calls

Two calls exist on sandbox deployments and let you drive a flow that would otherwise need a real bank transfer or a real identity check. They mount only when the backend is pointed at a sandbox host - on production they answer 404 like any endpoint that does not exist, so there is no flag that could be flipped against real money.

Call	What it does
POST /v1/virtual-accounts/{id}/test-deposit	Simulates a bank transfer arriving into one of your virtual accounts. Takes the amount as a decimal string; the depositor name and reference are optional labels. Only the EUR/IBAN rail is wired.
POST /v1/test/identity-review	Forces the outcome of an identity check, so you can exercise both the approved and the rejected path without real documents. Takes the applicantId.

Anything recorded through the test deposit comes back marked as a test, so it can never be mistaken for a real payment.

Testing against providers’ own sandboxes

Card and bank flows run against the underlying providers’ test environments. Two limits are worth knowing before you interpret a result as a bug:

• A card payment never reaches completed on the provider’s sandbox. It settles the card leg and then stops at processing, because no chain transfer is ever broadcast there. Purchases sit that way indefinitely. Use it to exercise the flow, not to assert a terminal state.
• The card sandbox may settle a different asset than production. Read cryptoCurrency off the quote and the status rather than assuming USDC; a test environment that cannot settle USDC will hand you ETH with a correct amount.

What the sandbox cannot do

The sandbox cannot force a transaction to its completed state. There is no test call and no magic value that moves a crypto deposit to done, a card payment to completed, or a card payout to settled. The crediting path - the one branch of your code that matters most - can be exercised with the test deposit above for bank transfers, and for the other products only against production. Build the crediting branch to a terminal status from Transaction statuses and test the surrounding flow here.

Sandbox vs production

Aspect	Sandbox	Production
Funds	Mock	Real
Settlement	Instant	Real on-chain timing
Coverage	Subset	Full
Data	Mock - not for calculations	Real

Do not build pricing or calculation logic on sandbox responses - they are mock values.