Every API reference page carries a server selector, so a request copied from the documentation can be switched between environments without editing it.
What is isolated
Everything that identifies or holds value:- Credentials. An app ID and secret belong to exactly one environment. A sandbox key sent to production fails authentication rather than acting.
- Accounts. A UPA created in sandbox does not exist in production. Your
externalUserIdmapping has to be per environment. - Webhook endpoints and signing secrets.
- Enabled capabilities. A capability switched on in sandbox is not automatically on in production.
GET /v2/partners/configanswers per environment and per credential.
What differs beyond isolation
Sandbox is not a mirror of production. Two differences matter when planning. Networks. Sandbox uses test networks. Chain ids differ, and an address or asset that is valid in one is not valid in the other. Never carry a chain id across. Provider behaviour. Fiat rails run against provider sandboxes where one exists. Some corridors cannot be rehearsed end to end outside production, so a first production transfer is also the first real test of that corridor. Plan a supervised low-value transfer rather than a full launch.Moving to production
Before you switch a base URL:1
Read config in production
GET /v2/partners/config with the production credential. Capabilities are granted per environment, so do not assume anything carries across.2
Re-register webhooks
New endpoint, new signing secret. Verify a signature before you trust a payload.
3
Recreate accounts
Accounts do not migrate. Your first production call for a customer is a create.
4
Rehearse the failure paths
Underpayment, duplicate payment, late receipt and expiry are the states that need a human. Confirm your side handles each before volume arrives.
Next
Authentication
Credentials, permissions and client sessions.
Webhooks
Events, delivery and signature verification.