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.

Checks that do not run in sandbox

  • The payout account name. In live mode, the bank’s name for a payout account must match the account holder. In sandbox, any name is accepted. Test your error handling for account_name_mismatch against the live rules in Requirements.
  • Requirements. In sandbox, an account owes the same fields it would owe in live mode, so you can build and test your requirements screens and the onboarding link. Its capabilities are still granted active straight away, so it can take payments and pay out before those fields are given. See What an account owes.
  • Our team’s review. Sandbox grants capabilities at once, so you never see an account wait for review. In live mode, some capabilities do. See How a capability goes live.

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. A payout to mobile money or to a bank outside Nigeria needs international payouts on, in sandbox as in live. In sandbox the option is on as soon as you send it, with nothing to wait for. The account still needs a name, email and address on file, or the payout is refused with PAYOUT_RECIPIENT_INCOMPLETE.