Go-live checklist

Work through this list before you ask Multigate to enable production. Each item prevents a problem we have seen in real integrations, and links to where it's explained. Tick an item only when you have done or tested it.

Credentials and security

• Generate a production API key. Sandbox keys don't work in production. In the production dashboard (multigate.app, Developer Tool › API Configuration › API keys), generate a key with a clear name (for example "Production – payouts server"). It is shown once. See Get an API key.
• Store the API key and the client secret in a secrets manager. Load them at runtime; keep them out of code, config files, container images, logs and tickets. The client secret comes from the same page and verifies your webhooks. See Your credentials.
• Plan key rotation. Decide how often you rotate (for example every 90 days, and at once when someone with access leaves or a key may have leaked), who does it, and test the steps once: generate the second key, deploy it, check Last used, revoke the old one. Your business can have only 2 active keys, so revoke old keys as soon as they are replaced. See Rotate an API key.
• Register your production server addresses on the IP allow-list. Find each server's public outbound IP address, and add them in the production dashboard (Developer Tool › API Configuration › IP Whitelist) or with Add or update a client configuration. Then call Get the current user from each server: a missing address gets 403 "Unauthorized access". See IP allow-list.
• Alert on 401 instead of retrying. With an API key, a 401 means the key is wrong or revoked and retrying won't help: raise an alert. See When a request returns 401.
• Keep secrets and account numbers out of logs. Search your logs for API keys (mgk_live_… and mgk_sandbox_…), passwords, client secrets and full account numbers, and mask them (show only the last 4 digits). Make sure your HTTP client doesn't log request headers.
• Give your API user only the permissions it needs, and decide on approvals. Check its permissions with Get the current user. Decide with your administrator whether its payouts need a second person to approve them (pending_approval) or go straight to processing. See Approvals.

Moving money safely

• Send a uniqueRequestId on every money-moving request (transfers, refunds, remittances and account requests; bulk payout rows get IDs from Multigate). Generate it once per business operation, make it unique across Multigate (for example a UUID), and store it before you call the API. See Idempotency.
• Treat a timeout, 5xx or dropped connection as unknown, not failed. Look the request up by its uniqueRequestId (for transfers, with Find transfers), and retry only with the same ID. See Unknown outcomes.
• Pay from the right account. Use the wallet's own account number (or its accountId as sourceAccountId), never a virtual account number. See Which ID goes where.
• Check new beneficiaries before the first payment. For NGN accounts, call Validate a beneficiary account (NGN) or Look up an account name, and show the returned name to your user. See Beneficiaries.
• Show the fee before your user confirms. Use Get a transfer fee. See Fees.
• Never use floating-point numbers for money. Keep amounts as decimal strings or integers in minor units (for example kobo) in your system. See Amounts and currencies.

Webhooks

• Register your production webhook URL before you create anything in production. Events that happen while no URL is registered are lost. Use HTTPS with a valid certificate, reachable from the internet, with no redirects. See Set up your endpoint.
• Verify the signature of every webhook with your production client secret, and reject failures with 401. See Verifying signatures.
• Reply 2xx within 5 seconds (Multigate gives up after 9) and do the work afterwards, for example from a queue. See How delivery works.
• De-duplicate and accept any order. Store each Idempotency-Key header you process, also compare the object's ID and status, and ignore events that would move a status backwards. See Handle events safely.
• Use your production server's URL, not a development tunnel.
• Alert on stuck events: stored webhook events that stay unprocessed for more than 15 minutes.
• Poll when no final webhook arrives. A job checks every payout still pending, pending_approval or processing after your timeout, because some outcomes send no webhook. See Outcomes without a webhook.

Operations

• Log errors so support can trace them: the HTTP status, the error body, the reference ID and your uniqueRequestId. See Server errors and reference IDs.
• Alert on payouts stuck in a non-final status longer than you expect. See Transfer statuses.
• Reconcile daily: match your records against account statements. See Daily reconciliation.
• Know how to reach Multigate support and what to include. See Support.
• Watch the mailbox that receives Multigate emails. Transfer emails go to the API user's email address; inflow emails go to your business contact. See Who receives emails.

Testing in the sandbox first

• Run every flow you'll use in production in the sandbox, including failures: an invalid account, insufficient balance, a reused uniqueRequestId, a failed transfer webhook. See the sandbox test checklist.
• Test your signature check with a real sandbox webhook, and confirm a tampered payload is rejected.
• Keep environment differences in configuration only. No if sandbox branches in your code, and no call to Simulate an inflow in production code.
• Use real email domains in test data. Production refuses disposable ones such as yopmail.com. See Email addresses.
• Check the source balance before an FX lock and handle 402. The sandbox doesn't enforce it. See FX conversions.
• Base production timeouts and alerts on production, not sandbox, timings. The sandbox is slower. See Payout results and timing.