GuidesGoing Live

Going Live

The checklist between a green sandbox and live traffic.

Before you flip the switch

Finish the sandbox checklist

Every section of the sandbox test checklist passes, including the failure paths: the request-for-information loop, the 666.00 and 777.00 deposits, and one expired operation.

Complete your own onboarding

Live access requires your executed Partner Terms on record and your own business verification approved. Until they are, live calls return 403 partner_terms_required or 403 partner_kyb_required. Work through the dashboard's onboarding checklist: we record the Partner Terms once they are signed (contact us if the step stays pending), you accept our terms for your company, and you enter your company's details, its people, and its documents, then submit the KYB. It does not depend on your code, so start it early. Our team reviews your KYB by hand, which can take a few business days, its details cannot be changed while it is in review, and a decline is final.

Register live webhook endpoints

Endpoints are per environment, and sandbox registrations do not carry over. Register the live URL and store the secret the registration returns in your live secret store: it is shown only once.

Register and activate live wallet keys

Live access requires this step even if you do not use wallets. On the dashboard's Wallets page, in live, register both public halves and complete the Recovery Key activation ceremony. Until it finishes, live calls return 403 partner_wallet_keys_required.

Your live keys must differ from your sandbox keys: a key already registered in one environment is refused in the other (422 key_reused_across_environments).

Swap key and base URL

- BASE=https://sandbox.rasto.co   KEY=sk_test_...
+ BASE=https://api.rasto.co       KEY=sk_live_...

Create the sk_live_ key on the dashboard's API keys page, in live, once the checklist is done. That is the entire code change. Endpoints and shapes are identical, and keys must match their host (401 environment_mismatch otherwise).

Run one real payment

Onboard one real customer, create their virtual account, and send a small real payment before opening the gates. Verify the delivered amount, the tx_hash, your fee line, and every webhook.

Operational habits worth setting up on day one

  • Log the request-id from every response header. It is the fastest path through support.
  • Reconcile from GET /api/transactions and GET /api/balances, not from your own event replay. See Reconciliation.
  • Alert on deposit.on_hold. A held deposit needs human attention.
  • Alert on any verifier refusal. A signing service that refuses to sign is doing its job, and it is also the highest-signal alert in your integration: something did not match.
  • Restrict live keys. Use read_only keys anywhere you do not strictly need mutations, and rotate any key that may have leaked. Rotation gives the old key a grace window.
  • Guard the virtual-account PATCH. Whoever can repoint a destination controls where all future deposits are delivered.

Keep your sandbox integration running in CI after launch. It is the cheapest regression net for API-facing code.