Skip to main content
After your platform is upgraded to a registered business, you can build with Connect in sandbox. Production use requires completed business compliance and an active live connect capability. Then point the same integration at https://api.bachs.io with an sk_live_ key instead of https://sandbox-api.bachs.io with sk_sandbox_. Sandbox and production are isolated, so nothing crosses over: not accounts, not balances, not keys. What changes is that everything is real. Verification is checked against real records, capabilities go live only when their real checks pass, and a transfer moves real money that cannot be reversed.

Before your first account

1

Confirm connect is active in production

Complete your registered-business compliance requirements and wait for live Connect enablement. Your sandbox access does not authorize production use. Check your live account:
capabilities.connect.status has to be active. See Become a platform.
2

Scope your production keys deliberately

A production key needs connected_accounts:write to create accounts, transfers:write to move money, and payouts:write to withdraw. Grant what the integration uses and no more. See API keys and authentication.
3

Point your webhook endpoint at production and set event_source

Endpoints do not carry across environments. Create the production endpoint with event_source set to connect or all, or you will receive nothing about your accounts. See Monitor onboarding.
4

Decide what each account owes and who logs in

Request only the capabilities each account needs: in production, that decides what the person behind it has to give, and how soon it goes live. Pick each account’s access mode, and which switches to turn on. See What an account owes and Give an account a dashboard.
5

Verify your signature check against a live delivery

Signing secrets are per endpoint, so the live endpoint has a different one. A verification step that silently passes in sandbox and fails in production is the most common go-live failure.

Before you move money

  • Trigger transfers on settlement, not on the charge succeeding. This works in sandbox where balances settle quickly and fails in production where they do not. See Balances.
  • Send an Idempotency-Key on every transfer and withdrawal. A retry without one pays twice.
  • Never treat a 5xx as a failure. Read the current state before retrying.
  • Decide when you transfer a seller’s share. Once it is transferred and withdrawn, a reversal cannot recover it. See Split payments.

What does not change

The API paths and request shapes are the same. Production capability review, settlement timing, and real money movement still need live-specific handling.

What does change

Capability grants do not. In sandbox, a capability whose persona the account has applied is granted active at creation, with no review. In production, the same request lands the capability restricted. It reaches active once the account’s requirements are complete and their checks pass, and for some capabilities once our team has reviewed them. See How a capability goes live. An integration that assumes a capability is usable immediately after creation, because that is what it saw in sandbox, will find it restricted in production until then. See Testing for exactly what sandbox grants and what it does not.