Go-live Checklist

A practical checklist for moving an integration from sandbox to production. Every item below is grounded in the behavior the API actually exposes today. Where a value or guarantee is environment-specific, confirm it with your Migo onboarding contact rather than assuming a default.

Credentials & authentication

• Production credentials requested separately from sandbox — credentials and keys are not shared across environments. See Environments & Base URLs.
• Merchant token stored in your secret manager, never embedded in client-side code. It is long-lived and has no refresh flow — rotate it through your Migo contact if it may have been exposed. See Authentication → Merchant token.
• Correct Authorization header per surface: Payment Links accept the token with or without a Bearer prefix; Alternative Payments conventionally send Bearer <token>. See Authentication → Header format by endpoint.
• If your integration uses the internal short-lived JWT flow, your client refreshes the access token on 401 TOKEN_EXPIRED instead of re-logging-in, and discards the old refresh token (refresh tokens are single-use). See Authentication → Refresh.
• Server IPs allowlisted with Migo (your outbound webhook source for production).

Environments

• Production base URLs in place of sandbox — for example https://mw.migopayments.com (Middleware) instead of https://sb-mw.migopayments.com. Full matrix in Environments & Base URLs.
• No sandbox tokens, hosts, or test cards remain in production configuration. A sandbox token will not work against a production host.

Integration correctness

• You walked through the recommended scenarios in sandbox: happy-path charge, declined charge, 3-D Secure, and a duplicate/replayed delivery. See Testing your integration.
• Tokenization confirmed — you store the cardId returned by Migo, never the PAN. See Security & PCI scope.
• You parse identifiers (such as the transaction uid / reference) from real API responses rather than constructing them yourself.

Webhooks

• Webhook receiver uses HTTPS with a valid certificate (production requires HTTPS).
• Inbound webhooks protected by IP allowlisting on your side. The Ed25519 signature scheme is documented as a target standard but is not yet enforced end-to-end — do not rely on signature validation alone until Migo confirms it is active for your tenant.
• Handler responds 2xx quickly and offloads heavy work; a non-2xx or timeout is treated as a delivery failure and retried.
• You confirmed the delivery/retry behavior that applies to your flow with Migo (the dispatch path and retry semantics depend on the flow Migo selected for your client).

Error handling & idempotency

• Every caller inspects CustomResponse.error.code and maps at least the codes in the Error Catalog.
• Webhook handler is idempotent — deliveries are at-least-once, so dedupe on a stable identifier from the body (for example uid, or (uid, status)). Replays must not double-fulfill orders.
• Client-side retries on transient failures use exponential backoff. (There is no general Idempotency-Key header on POST requests today — confirm the deduplication contract for any specific endpoint with Migo.)

Observability

• Alerting on elevated 4xx / 5xx rates from Migo endpoints.
• Alerting on webhook handler failures and TLS certificate expiry (expired certs surface as delivery failures).
• Logging that never records full PANs, CVVs, or tokens.
• You know how to request a delivery report from your Migo contact and how to ask for a missed delivery to be re-sent (there is no self-service replay endpoint).

Production cutover

• TLS 1.2+ enforced end-to-end.
• Security review completed against your PCI scope — see Security & PCI scope.
• Incident runbook in place: Migo contact and escalation path, plus your merchant-token rotation procedure.
• Run the recommended test matrix against production with a disposable cardholder before your first real transaction.