The Backup Payment Processor Readiness Checklist (Enterprise Edition)

Most advice about backup payment processors is written for small merchants worried about a sudden account shutdown, and it comes down to keeping a spare gateway approved somewhere. That's sensible at that scale. It falls apart for a platform or a subscription business at volume, where "have PayPal ready" is not a continuity plan. This checklist assumes revenue that matters, billing state that has to stay coherent, and auditors or enterprise customers who will eventually ask for evidence. (Whether you need a backup at all is a prior question: decision framework here.)

1. Choosing a backup payment processor and signing the contract

• Backup supports your required payment methods, currencies and markets, contracted as capabilities rather than roadmap promises
• Underwriting completed and the account fully approved now. Risk reviews take weeks, so approval during an incident is not a plan
• Processing limits confirmed at your full volume rather than your trickle-test volume; an account approved at 1% of traffic can throttle at 100%
• Settlement schedule, reserve policy and fee structure documented and accepted by finance
• Contract reviewed for minimums and inactivity fees (idle backups often carry both), and for termination and notice terms
• If you're DORA-scoped: provider added to your register of information, and the arrangement reflected in your exit strategy documentation (DORA guide)

2. Integration and parity

• Full checkout and API integration actually built, not a stub behind a feature flag that "mostly works"
• Configuration parity documented and diffed against the primary: 3DS rules, fraud settings, statement descriptors, currencies, payment methods, API versions
• Parity diff re-run on a schedule. Drift is the default state of two independently configured providers
• Webhook endpoints for the backup built, subscribed to the equivalent event set, and wired into the same downstream state machine
• Idempotency keys and event handling verified against the backup's semantics, because event names, ordering and retry behavior differ between PSPs

3. Tokens and stored credentials (the section that decides whether renewals survive)

• You know, precisely, where stored payment credentials live and which providers can charge them
• Renewal coverage calculated: what percentage of recurring revenue could the backup charge today? If tokens are vaulted solely with the primary, the honest answer is usually ~0% (see processor concentration risk)
• A token strategy exists and is in motion: network tokens, processor-agnostic vaulting, dual-vaulting on capture, or a documented migration path with a realistic timeline
• New-customer flows vault to a portable location from day one, so the exposure shrinks instead of growing

4. Operational readiness

• A written switchover runbook exists: trigger criteria, decision owner, exact steps, verification steps, and the return path
• Trigger criteria are quantified. Error rates, auth-rate drop, latency; "if it seems down" is not a trigger
• On-call knows the runbook exists and where it lives, so it survives the departure of the person who wrote it
• Support has macros ready for payment-disruption communications, with status-page language pre-drafted (outage playbook)
• Finance knows the backup's settlement format and schedule, and reconciliation can ingest its reports. A failover that breaks month-end close is a partial failover
• Fraud and risk have reviewed the backup's tooling, so switching doesn't mean running without fraud rules

5. Testing and evidence

• Sandbox rehearsal of the full runbook completed, timed, and repeated on a schedule
• Controlled live traffic has passed through the backup, with authorization rate, latency and decline-code mix benchmarked against the primary
• A full failure rehearsal (game day) has been run within the last 12 months
• Pass criteria defined in advance and results logged as evidence. Customers, auditors and regulators now ask for it, and "we believe it works" is not an answer
• Validation cadence is in the calendar, because every provider or stack change decays it (full methodology: how to test payment failover)

6. Maintenance, because readiness decays

• Ownership assigned: a named person or team owns backup readiness as a standing responsibility
• Credentials, certificates and webhook secrets for the backup are in the rotation schedule. An expired secret is not something to discover mid-failover
• Every change to the primary's configuration triggers the parity diff
• Quarterly review: volume limits still adequate, contract still sensible, coverage percentage trending the right way

Scoring yourself honestly

Count your unchecked boxes. The failure pattern is predictable: sections 1-2 mostly pass, section 3 fails outright, and sections 5-6 were never started. That gap is the difference between redundancy (two providers exist) and resilience (recovery is proven). Current PayRes provider coverage is on the integrations page. Mapping which of these boxes your stack actually satisfies, continuously, as the stack changes, is what PayRes is for.