Going live
Going live means using a live key instead of a test key. Your code does not change. What changes is that the funds are real, so a few things have to be in place first.
Before you switch
Section titled “Before you switch”-
Test the cases that matter. Your integration should handle a paid invoice, an underpaid one, an expired one, a late payment and a held settlement, and it should reject a webhook with a bad signature. The testing guide has the full list.
-
Verify your domain. In live mode, webhook URLs and checkout redirect URLs must be on a domain you have verified. See Domain verification.
-
Choose your networks and assets. In the dashboard, under Settings → Networks and assets, enable the assets on the networks you want to accept. See Networks and assets.
-
Fund your master wallet. On every network where you accept tokens, send some of that network’s native coin to your master wallet. The platform fee and the network fee of a token deposit are paid from it, and a token deposit is Held until it can pay. The dashboard shows each master wallet’s address under Balances. See Settlement and the platform fee.
-
Create a live secret key. Give it only the permissions it needs and, if your servers have fixed addresses, an IP allowlist. Store it in your production secrets. See API keys.
A new key cannot send payouts or create refunds. If your integration does either, grant those permissions when you create the key, and limit the key to the IP addresses of your servers, to the addresses it may pay (its payout allowlist), or both. See Payouts and refunds need more.
-
Add a live webhook endpoint. Live mode has its own endpoints and its own signing secrets. The URL must use
https. Store the new signing secret next to the live key. See Webhooks. -
Switch the key in your production environment to the live one, together with the live webhook secret.
-
Make one small real payment from start to finish. Create an invoice, pay it, check that
invoice.paidarrives and is verified, and watch the settlement reach Released.
What is different in live mode
Section titled “What is different in live mode”| Test mode | Live mode | |
|---|---|---|
| Funds | Test coins. | Real funds. |
| Webhook and redirect URLs | A verified domain, localhost or a .test hostname. |
A verified domain only. Webhook URLs must use https. |
| Payment simulator | Available. | Not available. |
| Data | Test invoices, keys and endpoints. | Starts empty. Nothing is copied from test mode. |
Events worth subscribing to
Section titled “Events worth subscribing to”Besides invoice.paid, subscribe your live endpoint to the events that need a person to act:
| Event | Why |
|---|---|
settlement.held |
A deposit is waiting for native coin in your master wallet. |
master_wallet.low_balance |
Deposits are held because the master wallet is short of native coin. It tells you how much to add. |
invoice.late_payment |
A payment arrived after its invoice expired. You need to accept or refund it. |
invoice.payment_reverted |
A payment you may have acted on was removed from the network. |
webhook_endpoint.failing |
Deliveries to one of your endpoints keep failing. |
Keep it running
Section titled “Keep it running”- Watch the master wallet balances. The dashboard warns you before a balance runs out.
- Check Developers → Webhooks now and then for failed deliveries, and resend them once your server is fixed.
- Roll a key at once if it may have leaked.
- Protect your dashboard account. Sign-in needs a second factor, either an authenticator app or a code sent by WhatsApp. The authenticator app is the recommended one. One channel is never both the password reset and the second factor: after you reset your password with a WhatsApp code, the next sign-in must use the authenticator app or a recovery code. A reset by WhatsApp is offered only to accounts that have an authenticator app; otherwise the reset code is sent by email.

