Skip to main content
This covers what is specific to Connect in sandbox: account creation, capability behavior, and settlement timing. First upgrade your platform account to a registered business to make Connect available in sandbox; production use waits for completed business compliance and live enablement. See Become a platform. For the base sandbox environment (base URL, isolation, keys) see Sandbox environment. For how a charge’s outcome is simulated, see Test payment outcomes.

​
Create an account

POST /v1/accounts works the same as live: same fields, same response shape, a sk_sandbox_ key against https://sandbox-api.bachs.io. See Accounts.

​
Capability grants depend on the operation

Sandbox capability grants are scoped to the personas named in configuration. Naming merchant does not automatically apply recipient, and naming recipient does not apply merchant. On update, naming a persona without capabilities applies that persona but requests nothing. conversions is granted automatically for recipient-capable accounts, so a narrow capability request does not mean every other capability must remain inactive. See Capabilities.
Sandbox grants do not exercise the complete live requirements and review flow. A capability active in sandbox can still need information or approval in live mode. Check the account’s capabilities and requirements in each environment, and build live requirement handling using Requirements and Onboarding.

​
Settlement is immediate

A sandbox charge’s outcome is simulated and finalizes on its own; see Test payment outcomes for how to control that. Once it succeeds, its amount reaches available_balance straight away, whatever the currency. Live does not work this way. There, a charge lands in pending_balance and moves across on a schedule set by the currency it was paid in. That is the same day for some currencies and a day or two later for others. Sandbox collapses that wait so you can watch a split land and run a withdrawal against it in one sitting.
This is the one place sandbox does not reproduce live timing. Anything your integration does with the gap between pending_balance and available_balance will not be exercised here: holding a payout until funds clear, showing a customer when money becomes available, retrying a transfer that failed for lack of balance. Build those against what Balances documents.

​
Withdrawals in sandbox

A withdrawal in sandbox is created the same way as live, moves to processing, and resolves to completed after a short delay rather than reaching a real destination. By default it resolves completed. For bank_transfer and crypto, sending specific destination values forces the outcome instead: mobile_money has no trigger values; it always resolves to the default outcome. See Payouts for the request and its fields.