Going Live

Switching to production is one line of configuration. Everything that makes it safe happens before that line changes, which is what this page is for: a checklist you can actually tick off, then the list of things that behave differently in production and could not have been tested in the sandbox.

Before anything else, get verified

Production opens when your compliance record is approved, and not a moment earlier. Live keys exist before that, they authenticate, and every limit on them sits at zero. Account activation & KYC covers the dossier and the review.

Submit it early. Review takes up to 48 hours, and your sandbox integration keeps working throughout, so the sensible order is to file the dossier first and work through the rest of this page while it is being reviewed.

The checklist

Tick these off in your own environment. Every item is something you can verify by running code, not something to take on trust. Your progress is kept in this browser, so you can come back to it.

Go-live checklist

0/23

• Keys and access
• Production keys read from environment variables, never from source.
• The private key never reaches a browser, a mobile binary or a log line.
• A restricted key carrying only the scopes you actually call.
• An IP allow-list on the production key, so a leaked key is worthless elsewhere.
• Someone other than you can roll a key and redeploy, and has done it once in sandbox.
• Payments
• Fulfilment happens on the payment.succeeded webhook, never on the redirect back.
• failed, cancelled and expired each lead somewhere sensible in your interface.
• An Idempotency-Key header on every POST /payments and POST /transfers.
• Amounts sent in the major unit, and read back with the currency field beside them.
• Your own unique reference on each payment, so a duplicate submission returns 409.
• Webhooks
• A production endpoint registered, with its own signing secret in your environment.
• Every incoming signature verified before the payload is trusted.
• The endpoint answers 2xx in under ten seconds and queues its real work.
• Deliveries deduplicated on the X-Wajub-Delivery-Id header.
• You have watched a retry happen: five attempts, at 30s, 1min, 5min, 10min and 1h.
• Failure and load
• Back-off on 429, reading retry_after from the body rather than guessing.
• Network timeouts and 5xx retried with the same idempotency key.
• Balance checked before a payout run, not discovered mid-loop.
• Alerts on a failure spike, wired to somewhere a human looks.
• Konsole reachable by whoever is on call.
  View guide →
• Team
• Roles assigned by least privilege, so support staff cannot mint keys.
• Two-factor enforced for the team.
• At least two people can reach the Dashboard, verified by logging in.

What is different once you are live

This is the part a sandbox cannot teach you, so read it before you flip rather than after.

Five feature areas were never available to you. Payment links, invoices, tax, Shield and customer tax IDs all refuse sandbox keys with 403 This feature is only available in live mode. If your integration touches any of them, production is the first time that code has ever run. Plan a narrow rehearsal for those paths specifically.

Your rate limit changes with your plan, not with your environment. Pay as you go allows 120 requests per minute, Growth 360, Scale 720, and Enterprise is uncapped. On an uncapped plan the X-RateLimit-* headers are omitted entirely, so any code that reads them must treat their absence as normal rather than as zero.

The webhook signing secret is different. It belongs to an endpoint, and an endpoint belongs to one environment. Registering the same URL in production gives you a new whsec_ value. Copying the sandbox one across is the single most common reason a first live webhook fails signature verification.

Identifiers lose their test_ segment. A sandbox payment is trx_test_… and its production equivalent is trx_…. Nothing in your code should depend on that segment, and anything that pattern-matches ids should be checked once before you switch.

Money can actually run out. A payout fails on an insufficient balance, a wallet has its own daily ceiling below yours, and a customer can simply not confirm. None of these happen in a sandbox where the outcome is decided by the test number you dialled.

Making the switch

Do these four in one deployment rather than spread across an afternoon. A half-switched integration sends live payments to a sandbox webhook, and you will not notice until reconciliation.

1. Register your production webhook endpoints and copy each new signing secret.
2. Put the production key and those secrets in your production environment.
3. Deploy. The SDK needs no other change, the key alone decides the environment.
4. Confirm in Konsole that your first production request was authenticated as live.

Your first real payment

Pay yourself. Take the smallest amount your operator accepts, usually 100 XAF, and run the whole path with your own phone.

Four things have to be true before you open the doors. The transaction reaches succeeded. Your production endpoint received payment.succeeded and the signature verified. The amount appears in your balance. And your own database recorded the order as paid, through the same code path a customer would trigger.

Then refund it. A refund is the one flow nobody tests before they need it, and the day you need it is never a calm one.

If something is wrong

Rolling back is redeploying your sandbox key. No data is lost and nothing needs undoing on Wajub's side, because the two environments never shared anything. Payments already taken stay where they are, and you can inspect every one of them in Konsole while you fix whatever broke.