Designing redundancy for a payment gateway

Gateway redundancy is an operating capability: a second connection only helps when the route is commercially approved, technically ready and included in tested policy.

Define the failure you need to survive

Separate provider outage, regional degradation, method-specific failure, exhausted limits, bad configuration and merchant-side integration problems. Each failure needs different health evidence and may make a different fallback route eligible.

Track route readiness explicitly

A provider can be known but not qualified, integrated but not approved, or configured but unable to accept the intended traffic. Record commercial status, credentials, limits, callbacks, support ownership and reconciliation before labelling a route as backup.

Design routing and observability together

Specify the hard constraints that protect eligibility, the preferences that order valid routes and the signal that justifies a change. Preserve the selected rule, provider response and later action so an incident can be explained after traffic moves.

Redundancy is proven by a controlled recovery exercise, not by the presence of a second logo on an architecture diagram.

Exercise recovery and return

Test failover with representative operations, monitor the result and define how traffic returns when the primary route recovers. Include support and finance: incidents affect customer communication, callbacks, reports and settlement expectations as well as authorization.