Go-live checklist

Most production incidents in the first week come from something on this list that was true in sandbox and not in production. Work through it with your relationship manager a few days before the switch, not on the morning of it.

1. Production credentials issued and stored. Your production client is a separate client from sandbox, with its own client_id and client_secret. Confirm the client is active (not pending approval), store the secret in your secrets manager, and confirm that nobody has it in a chat log or a ticket. See Authentication.

2. Production IP allowlist set. Give the bank every address production traffic will leave from: your NAT gateway or egress proxy, not your application hosts, and every availability zone you fail over to. Ask for CIDR blocks where you have them. Then confirm that the first production token request succeeds from each address before the day. See IP allowlist and rate limits.

3. Scopes confirmed against what you actually call. List every endpoint your integration uses and check each one’s scope against the scopes on your production client; sandbox clients are often issued wider scopes than production. If you onboard agents or merchants you need sub-agents:create; if you spend out of their accounts you need sub-agents:debit and the sub-agent visibility flag on the client. See Scopes.

4. Rate limit sized for your peak. Estimate your peak calls per minute, including any polling, and compare it with the per-minute budget on your production client. Ask for a higher limit now if you need one. Make sure your client reads X-RateLimit-Remaining and honours Retry-After.

5. Settlement and fee accounts funded. Funding an account debits your settlement account; a fund that exceeds it is refused with 0004. API usage fees are charged to your fee account. Confirm both account numbers with the bank, confirm they are the ones inside your production token, and fund them before the first call. See API access and billing.

6. Webhook endpoint live and signature verification tested. Register your production webhook URL, confirm it is reachable from the bank over HTTPS, and run the signature test vector through your verification code before any real event arrives. Verify the signature on every delivery and reject anything that fails. See Verifying signatures and Delivery and retries.

7. Virtual account callback registered. If you collect through virtual accounts, register your inflow callback URL for production and confirm it is distinct from the sandbox one. Decide now how you handle a callback you cannot process in time. See Inflow callbacks.

8. Reconciliation plan agreed. Decide what you reconcile each day, against which source, and who looks at a gap: inflows against your own expected payments, outward transfers against check-transaction, your settlement account statement against your ledger. Write down the cut-off time and whose clock it is on. See Reconciling a day.

9. Idempotency in place. Every money-movement call sends a transactionRef that you persisted before sending; transport failures retry with the same reference; 0094 and 0009 route to check-transaction, never to a resend. Test this by killing your process mid-call in sandbox. See Idempotency.

10. Monitoring for 429s and 0009s. Alert on any HTTP 429, on a rising count of 0009 responses, and on a 0009 that has not settled to 0000 or 0096 after your tolerance (interbank transfers are usually resolved within minutes; a stuck one is escalated to bank staff). Alert on 401s outside your token refresh, on SCOPE_DENIED and on IP_NOT_ALLOWED: all three mean configuration drifted, not that a user did something wrong. Log the X-Request-Id of every call so support cases carry it.

11. Portal users invited. Invite your finance and operations people to the partner portal and make sure at least one of them can see the Transactions, Virtual accounts and Webhooks pages before go-live, so the first dispute is checked against the bank’s view and not against yours. See The partner portal.

12. Support path known. Know who at the bank you call, what hours they keep, and what they will ask for: your client_id, the X-Request-Id, your transactionRef, and BankCore’s retRef. Keep all four in your logs.

A dry run that catches most of it

From a production host, with production credentials: fetch a token, read your own balance, run a name enquiry against one of your own accounts, and create and immediately expire a virtual account. That exercises the allowlist, the token, three scopes, the ownership guard and the legacy envelope without moving money.

In the portal

The API access page is the one to check on the day: it shows the client’s status, scopes, limits and allowlist, and updates its last-used time and address on your first production call.