GuidesGoing Live

Going Live

The checklist between a green sandbox and production traffic.

Before you flip the switch

Finish the sandbox checklist

All five sections of the sandbox test checklist pass: onboarding including the request-for-information loop, money movement including the 666.00 and 777.00 failure paths, wallets including one expired operation, idempotent webhook processing, and retry hygiene.

Complete your own onboarding

Live access requires your organization to be fully onboarded: partner terms executed, and your own business verification approved. Until both are done, live calls return 403 partner_tos_required or 403 partner_kyb_required. Your Rasto contact drives this with you, and it does not depend on your code, so start it early.

Register live webhook endpoints

Endpoints are per environment, and sandbox registrations do not carry over. Register the production URL and store its signing secret in your production secret store.

Register and activate live wallet keys

If you use wallets: register both public halves in the live environment, and complete the Recovery Key activation ceremony. Until it finishes, creating a send returns 400 activation_required, while wallet creation and deposits work normally.

Your live Recovery Key should not be the key you used in sandbox.

Swap key and base URL

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

That is the entire code change. Endpoints and shapes are identical, and keys must match their host (401 environment_mismatch otherwise).

Run one real end-to-end

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, and sandbox behavior always matches live.

Was this page helpful?