High Availability

High availability is achieved through redundancy at every layer of the payment stack: redundant servers, redundant network connections, redundant data centres, and redundant routing paths. No single component failure should take the entire system offline. This is typically implemented through active-active or active-passive architectures where a standby component takes over automatically when the primary fails.

A 99.99% uptime target (four nines) equates to approximately 52 minutes of allowable downtime per year. A 99.999% target (five nines) allows approximately 5 minutes of downtime per year. These figures sound similar but the operational gap is significant: achieving five nines requires automated failure detection and recovery in seconds, not minutes.

Payment infrastructure high availability requirements are more demanding than most web applications because transactions are synchronous, time-sensitive, and financially consequential. An e-commerce site experiencing a 30-second outage loses the conversions during that window. A payment processing outage during that window fails those transactions entirely; those sales cannot be recovered after the fact.

Geographic redundancy is a component of high availability for global merchants: infrastructure distributed across multiple data centre regions ensures that a regional outage or network event does not take all processing capacity offline. For merchants operating across multiple time zones, geographic distribution also enables lower-latency authorisation responses.

Uptime percentages translate directly to revenue impact: for a merchant processing $500M annually, each hour of payment downtime represents roughly $57,000 in lost transaction volume at average conversion. Understanding the revenue cost of downtime in concrete terms makes SLA negotiation with payment providers more grounded.

SLA terms must be read carefully: providers often define uptime based on their platform health page, excluding scheduled maintenance windows or incidents attributable to third parties (card networks, banks). Merchants should understand what is and is not counted in the SLA before relying on it.

Redundancy at the provider level does not eliminate merchant-side risk: if the merchant's checkout system, order management, or fraud tools have single points of failure, payment infrastructure uptime becomes irrelevant during those outages. End-to-end availability requires resilience across all components in the checkout flow.

Testing availability matters as much as the architecture: redundancy that has never been tested under realistic failure conditions may not perform as designed. Merchants should ask providers about their disaster recovery test cadence and failure simulation practices.