Skip to main content
This covers what is specific to Connect in sandbox: account creation, capability behavior, and settlement timing. For the base sandbox environment (base URL, isolation, keys) see Sandbox environment. For how a charge’s outcome is simulated, see Sandbox testing.

​
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.

​
Capabilities are active as soon as their persona is applied

In sandbox, a capability is granted active the moment its persona (merchant or recipient) is applied to the account, whether that happens at creation or later on POST /v1/accounts/{account_id}. Naming a persona’s capabilities does not decide how much is granted, in sandbox or live; it decides which capabilities are requested under that persona, and only those are granted. recipient is always applied, so payouts, transfers, and conversions are always granted active. merchant is applied only if you name it as a key in configuration, at creation or on update. Leave it out and the account is recipient-only: it has no payment-method capability at all, and cannot accept a payment, in sandbox or live. Live behaves the same way, except a granted capability lands restricted rather than active, as documented on Capabilities.
The practical effect: a sandbox account with a merchant capability, named at creation or applied later on update, can accept payments as soon as that call returns, and the requirements flow described on Requirements never has anything to surface for the capabilities that were granted, because none of them was ever left in a requested state waiting on information. If your integration depends on rendering requirements, driving a hosted account link, or reacting to a capability moving from restricted to active, sandbox will not exercise that path for a granted capability. Build and review those flows against what Capabilities and Onboarding document, since sandbox will not reproduce it. One difference between the two calls: creation grants every capability the applied personas allow, even ones you never named, the same blanket behavior Create an account documents for omitted capabilities. Update grants only what you actually named under a persona in that request; a persona’s other capabilities stay untouched until you name them too.

​
Settlement is immediate

A sandbox charge’s outcome is simulated and finalizes on its own; see Sandbox testing 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.