Two providers can still share one outage

Adding a second payment provider does not create a second checkout path. It creates another branch somewhere inside the first path. Both branches may still depend on the same checkout page, DNS service, cloud region, credential vault, 3-D Secure component, card network, issuer, routing control plane or operator action. If any shared component is required for a payment to finish, its failure can take both providers out together.

The useful question is therefore not “How many providers are integrated?” It is “Which failure can prevent every acceptable way to pay?” A sound redundancy design follows one customer attempt from browser to final state, finds the components and organisations common to all routes, and proves that switching works while the system is slow, partially available and uncertain about whether money moved. Research on correlated cloud failures gives this problem a precise shape: apparently redundant systems can share hidden network, hardware and software dependencies, creating a smaller failure set than their architecture diagram suggests.1

Provider diversity is not path independence

The easy availability calculation assumes independence. If each of two providers is unavailable for one transaction in a thousand, and their failures are unrelated, both are unavailable together in roughly one transaction in a million. That multiplication is doing nearly all the work. Once the two failures share a cause, the estimate no longer describes the system.

This is common-cause failure, not a rare mathematical footnote. Zhai and colleagues define a risk group as a set of components whose simultaneous failure can cause an outage. Their work shows how a shared aggregation switch, power source or lower-level cloud service can defeat replicas that appear separate at the application layer.1 The Basel Committee now treats the same pattern as third-party concentration risk: multiple providers may depend on the same “nth party,” or several services may be concentrated in one provider or geographic region.2

A checkout route is better represented as a dependency graph than as a vendor list. Nodes include the customer device, merchant edge, payment UI, session and order services, fraud checks, secrets, token services, authentication components, provider API, acquirer, network, issuer and the systems that receive later status events. Edges mean “must work before the customer can reach an acceptable outcome.” A provider logo covers only a subset of those nodes.

The graph also changes by payment method and lifecycle stage. A saved network token, a newly entered card and a bank redirect do not traverse identical components. Nor do authorization, capture, reversal and refund. ISO 8583 specifies a common interface for card-originated messages exchanged between acquirers and issuers, while explicitly leaving transport and settlement outside its scope.3 Even the standard message boundary is only one layer of a larger route.

This produces a stricter definition of redundancy: two routes are independent with respect to a failure only when that failure cannot disable both. Absolute independence is unrealistic. The engineering task is to identify the important shared risks, reduce the overlap that can be changed, and set honest expectations for the overlap that cannot.

The first shared outage can happen before provider selection

The payment providers may both be healthy while the customer sees no way to pay. The checkout document may not load. The API that creates an order may be unavailable. A session service may reject every request. The routing service may fail before it chooses either provider. A feature-flag system may return an empty configuration. A shared secrets service may withhold both sets of API credentials.

The browser adds its own dependency surface. W3C’s Payment Request specification describes a user agent mediating among payee, payer and payment method, and notes that merchants commonly delegate checkout activities to payment service providers through an iframe.4 PCI Security Standards Council guidance says PCI DSS v4.x requires payment-page scripts to be authorized, checked for integrity and monitored for tampering.5 These documents are about interoperability and security, but they expose an availability fact: executable code, frames and origins outside the merchant application can sit directly in the customer’s critical path.

Consider a page that eagerly loads two provider SDKs and waits for both initialization promises before enabling its pay button. Provider B cannot rescue provider A if A’s script host hangs and the application never reaches routing. A similar failure occurs when both SDK bundles are served through one merchant CDN, both API hostnames use one authoritative DNS provider, or one content-security-policy release blocks both frames. The commercial integrations are different. The delivery path is not.

The correct browser boundary is a usable checkout shell that can load and render a valid fallback without contacting the failed branch. Provider-specific code should be isolated so that one SDK’s slow DNS lookup, exception or initialization timeout cannot block the other. A fallback must also remain discoverable: an invisible alternative behind a failed “more ways to pay” call is not available to the customer.

This does not mean duplicating every script or disabling payment-page security controls. It means treating the page, headers, dependencies and load order as part of the availability design. A tightly controlled, smaller script graph is easier to reason about for both security and failure isolation. PCI SSC’s 3-D Secure guidance is especially revealing: a typical web implementation can involve a merchant page serving an iframe whose URL ultimately comes from a 3DS Server and may point to scripts associated with an Access Control Server or Directory Server.6 The browser can therefore cross several administrative boundaries before authorization even begins.

Authentication and credentials can collapse two routes into one

For regulated or risk-based card flows, switching the authorization endpoint may not switch the authentication path. EMVCo’s 3-D Secure documentation defines a three-domain architecture and distinct server- and device-side components for authentication.7 PCI SSC’s implementation description names the 3DS Server, the payment network’s Directory Server and the issuer-side Access Control Server in a typical checkout flow.6 Two acquiring providers can therefore converge on the same card scheme’s directory infrastructure and the same issuer’s ACS.

That convergence has several consequences. If the issuer’s challenge page is unavailable, changing acquirer may send the customer back to the same unavailable ACS. If a scheme-level directory service is impaired, every provider using that scheme’s 3DS route may see the same class of failure. If both providers use the same external 3DS Server vendor, the shared point moves closer to the merchant. Provider failover helps only when the failed component is actually inside the part of the graph that changes.

Credentials can create another hidden coupling. EMV payment tokens can be constrained to a merchant, device or payment scenario, and their use runs from the point of purchase through the acquirer and payment network to issuer authorization.8 A token stored by one provider is not automatically a portable credential for another route. The fallback may require a separately provisioned token, access to an appropriately scoped underlying credential, or fresh customer entry. Those options have different security and user-experience costs; none can be created during an outage by a router alone.

Portability must be tested for each credential class: newly entered cards, merchant-stored credentials, network tokens, device wallets and payment-method-specific mandates. The test is not whether provider B has an API that accepts a field named token. It is whether the credential produced before route selection is valid on B, whether required authentication data survives the switch, and whether subsequent operations remain possible.

After authentication, nominally distinct providers may still converge on the same card network and issuer. Visa’s public acceptance flow shows an acquirer or processor sending a request to Visa, Visa routing it to the issuer, and the issuer returning the payment decision through Visa.9 ISO 8583 similarly locates its interchange interface between acquirers and issuers.3 A second acquirer can route around an acquirer-specific failure. It cannot route around the customer’s issuer while continuing to charge the same card, and it cannot provide an independent Visa path if the relevant failure is in shared Visa processing.

That is not an argument against multi-acquirer routing. It defines its coverage. A different payment method may sometimes create more structural diversity than a second route for the same card: it can change the credential authority, network and decision-maker. Yet it may still share the merchant page, order service and cloud edge. Independence has to be evaluated from the customer action outward, not inferred from labels such as “card,” “wallet” or “bank pay.”

Redundancy has an eligibility denominator

A backup counts only for the attempts it can complete. Provider B may be live but ineligible for a particular currency, country, payment method, credential type, authentication result or capture model. It may be able to authorize a newly entered card but not use the saved credential presented at checkout. It may support the sale but not the later partial capture that the order requires. In those cases the system has two integrations and one usable route.

The dependency map therefore needs an eligibility matrix beside it. For each meaningful traffic segment, identify the routes that can accept the credential, satisfy authentication and risk policy, preserve the order’s payment semantics, and own the transaction through reversal, capture and refund. The matrix should reflect runtime facts. A route disabled by exhausted capacity, missing keys, an expired certificate or a risk hold is not an alternative merely because its integration passed a test last quarter.

This changes the denominator used to describe coverage. “Ninety per cent of card traffic has an independent second route” is a testable proposition; “we have two card providers” is not. The uncovered ten per cent can then receive an explicit response: another payment method offered before credential entry, a pending order that preserves inventory while payment is retried, or a clear failure that does not imply money was declined.

Eligibility also belongs in the customer interface. If the system discovers only after authentication that the selected credential cannot move to the surviving route, it has created friction without resilience. Early capability checks can present the alternatives that are actually viable for that order, while final route selection remains late enough to use current health. The balance is deliberate: decide eligibility early, decide route as late as safely possible, and never confuse an eligible route with a healthy one.

A shared cloud or control plane can erase data-plane diversity

Provider A and provider B can run separate payment systems while the merchant’s adapter services run in one cloud region. They can expose different APIs while both names resolve through one DNS operator. They can have independent data planes while the merchant stores both routing rules in one database. They can even run in different clouds while receiving the same broken software build, certificate bundle or configuration from one deployment pipeline.

Public outage reports show why infrastructure categories are too coarse. During AWS’s December 2021 US-EAST-1 event, congestion between an internal network and the main network affected foundational services including internal DNS, monitoring, authorization services and parts of the EC2 control plane. The impairment also delayed AWS’s understanding of the event and affected the health-dashboard failover path.10 One underlying network event crossed several service names and weakened both production and the machinery used to observe it.

Cloudflare’s June 2022 outage offers the complementary lesson. A network configuration change was deployed to 19 locations that handled a significant share of its global traffic; those locations became unavailable despite Cloudflare’s broader geographic footprint.11 Geographic replication did not protect the affected path from a shared configuration action.

The merchant-side route selector deserves the same suspicion. If it depends synchronously on a central configuration service, that service is upstream of both providers. If it treats missing health data as “send to primary,” loss of telemetry disables the backup precisely when evidence is weakest. If its emergency override uses the same identity provider, network and control plane as production, an operator may be unable to change the route.

Control-plane independence does not require two copies of every administrative system. It does require a last-known-good routing configuration in the serving path, bounded local decisions when central control is unavailable, and a tested emergency mechanism that survives the scenarios it is meant to control. The fallback should not need a fresh deployment, a new firewall approval or an engineer’s first-ever login to become usable.

Failover is a money-state transition, not a retry policy

Even a genuinely independent second route can be unsafe to use. The dangerous moment is a timeout after provider A may have accepted the instruction. Silence does not say whether authorization happened. Sending the same business intent to provider B can create a second authorization or charge.

PayPal’s idempotency documentation gives a concrete example: a capture request times out, yet the server captures the payment; retrying with the same provider-scoped request identifier returns the earlier request’s latest status.12 That protection does not cross into another provider’s idempotency store. The merchant needs its own durable attempt record above both integrations.

The routing decision should distinguish at least three outcomes. A failure before submission is safe to reroute if no side effect could have occurred. A definitive business decline is usually final for that attempt, not evidence that the provider is down. An ambiguous technical outcome must be resolved through the original provider’s status, event or reconciliation channel before creating another financial attempt—or deliberately moved into a controlled exception state when resolution cannot meet the customer deadline.

The boundary persists after authorization. PayPal’s capture API requires the identifier of the authorized payment.13 Adyen’s cancellation API likewise operates on the original payment reference, and its documentation recommends a reversal when the caller does not know whether capture has occurred.14 These public interfaces illustrate a general lifecycle constraint: provider B cannot simply capture, reverse or refund state created inside provider A. A checkout that fails over authorization but has no provider-aware post-payment workflow has moved the outage into fulfilment and reconciliation.

The durable record must keep the merchant payment intent, each provider attempt, idempotency identity, provider reference, observed response and current confidence about money state. It must permit one customer intent to have several attempts without pretending those attempts are the same provider operation. Routing then becomes a guarded state transition: not_submitted may move to another route; submitted_unknown may not; declined_final ends; authorized remains owned by the route that created the authorization.

Retries need system-wide limits as well. Google’s SRE guidance shows how retries at several layers multiply and how shifting traffic from an unhealthy cluster can overload the remaining one.15 During a provider incident, browser retries, API client retries, router failover and customer resubmission can all amplify load. A retry budget, jittered backoff, per-route concurrency limits and explicit deadlines protect the surviving provider from becoming the second failure.

Map the route, then look for the smallest cut

A useful dependency map begins with outcomes, not systems. “Customer can complete an eligible purchase” is one outcome. “An accepted order reaches an authoritative paid or unpaid state” is another. “Operations can reverse or refund it” is a third. Each outcome may have a different set of viable routes and shared cuts.

For every route, record the concrete dependency and its role: browser origin, authoritative DNS, CDN and certificate path; checkout and order services; session, identity, secrets and configuration; credential vault or token service; fraud and authentication components; provider endpoint and region; processor, acquirer, scheme and issuer path; webhook ingress, queue and reconciliation feed. Record ownership, location, change mechanism, timeout behaviour, data portability and the evidence used to declare it healthy.

Then compare routes column by column. “Different vendor” is weak evidence. Better questions are operational: Do both host their public endpoints behind the same edge network? Do both merchant adapters run in the same region? Does one provider subcontract authentication to the same vendor as the other? Do both routes require one token service? Can either path operate from cached configuration? Can the backup receive callbacks if the primary DNS or queue is down?

This exercise will expose shared dependencies that cannot reasonably be removed. A card’s issuer is one. A scheme may be another. The merchant’s order ledger may be intentionally singular. Marking these explicitly is more useful than drawing duplicate boxes around them. It supports honest impact analysis and reveals where another payment method, an offline recovery flow, a queue or a clear “payment pending” state is the only feasible response.

Regulatory resilience guidance converges on this end-to-end view. The Bank of England expects recognised payment system operators and specified service providers to map the people, processes, technology, facilities and information required for important business services, including outsourced providers, and to use the map to understand concentration and design disruption scenarios.16 The Basel Committee similarly says mapping should be detailed enough to identify vulnerabilities and test whether critical operations remain within disruption tolerance.17

Prove the backup under the failure it is supposed to cover

A successful test payment through provider B proves basic compatibility. It does not prove failover. Real evidence comes from removing a dependency, applying realistic load, preserving uncertainty and observing whether the customer and money states stay within their defined limits.

Tests should start outside the merchant’s primary infrastructure. Synthetic customers from independent networks can verify that the checkout loads, the alternative is visible, authentication completes and the final state arrives. Provider API probes alone miss failures in the browser, merchant edge and callback path. Aggregate authorization rate alone can also conceal a narrow outage; Stripe’s engineering account of payment monitoring describes segmenting traffic across issuers, countries, currencies, card products and payment features to isolate degraded slices.18

Each major shared risk needs a severe but plausible scenario. Remove the primary provider before submission. Delay its response after acceptance. Break the shared 3DS service. Make the token for A unavailable to B. Freeze the central routing configuration. Withdraw a DNS answer. Stop webhook delivery while status polling works. Saturate the backup at the full traffic it would inherit. Expire a certificate. Deny operators access to the normal control plane.

The assertions should be financial, not merely technical. No business intent produces two successful charges. Every ambiguous attempt reaches a resolvable state. Authorized payments can still be captured or reversed through their owning provider. Webhook recovery does not repeat fulfilment. The surviving route respects its capacity and risk controls. Customer messaging distinguishes failure from pending state. Settlement and reconciliation can attribute every movement to the correct attempt.

Run the exercise with production-shaped credentials, authentication rules, routing constraints and operational permissions. A dormant integration drifts: certificates expire, API versions change, risk rules diverge, token coverage narrows and staff lose familiarity. Sending a controlled share of ordinary traffic through each intended route continuously catches more of that drift than a cold standby checked only during incidents.

Tests must also include recovery. Restoring provider A can cause queued callbacks, delayed status changes and customer retries to arrive together. AWS reported EventBridge delivery latency while a backlog was processed after service was re-enabled in its 2021 event.10 The payment system must absorb that return without routing new attempts into old uncertainty or allowing the recovered route to be overwhelmed.

Measure coverage, not provider uptime

Provider health is an input. The service-level measure is the fraction of eligible customer intents that reach a correct outcome within the tolerated time. Break it down by route and by failure-domain signature: page load, credential preparation, authentication, submission, issuer response and final-state confirmation. A green provider dashboard cannot compensate for a checkout script that never offered the provider.

Track overlap explicitly. For each critical dependency, report which payment routes it can disable, what share of eligible traffic has an alternative that excludes it, and whether that alternative was exercised recently. A dependency with high route coverage and no tested exclusion path deserves more attention than a provider with a marginally worse standalone uptime number.

Operational signals should preserve ambiguity rather than hide it. Timeouts, unknown states, suppressed reroutes, late authorizations, duplicate customer submissions and backlog age are primary reliability signals. If the dashboard reports only success and decline, it will make a shared incident look like scattered noise until reconciliation finds the consequences.

No architecture can eliminate every common cause. The goal is bounded failure: optional components degrade without blocking payment; one provider’s failure does not poison the other route; shared scheme or issuer failures affect only the relevant slice; uncertain money states do not trigger blind rerouting; and operators can recover the system without the failed control plane.

Two providers are valuable when they create two usable paths through the failures that matter. The count is the beginning of the argument, not the evidence. The evidence is a dependency map, portable state where portability is possible, guarded failover where money may already have moved, and repeated tests that cut the shared links. Until those exist, two provider contracts can still describe one outage.

Sources

1. Heading Off Correlated Failures through Independence-as-a-Service — USENIX Association, 11th USENIX Symposium on Operating Systems Design and Implementation. https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-zhai.pdf (opens in a new tab)
2. Principles for the Sound Management of Third-Party Risk — Basel Committee on Banking Supervision, Bank for International Settlements. https://www.bis.org/bcbs/publ/d605.pdf (opens in a new tab)
3. ISO 8583:2023 — Financial-transaction-card-originated messages — Interchange message specifications — International Organization for Standardization. https://www.iso.org/standard/79451.html (opens in a new tab)
4. Payment Request API — World Wide Web Consortium. https://www.w3.org/TR/payment-request/ (opens in a new tab)
5. New Information Supplement: Payment Page Security and Preventing E-Skimming — PCI Security Standards Council. https://blog.pcisecuritystandards.org/new-information-supplement-payment-page-security-and-preventing-e-skimming (opens in a new tab)
6. How does PCI DSS Requirement 6.4.3 apply to 3DS scripts called from a merchant check-out page as part of 3DS processing? — PCI Security Standards Council. https://www.pcisecuritystandards.org/faqs/how-does-pci-dss-requirement-6-4-3-apply-to-3ds-scripts-called-from-a-merchant-check-out-page-as-part-of-3ds-processing/ (opens in a new tab)
7. 3-D Secure Documentation — EMVCo. https://www.emvco.com/dynamic/emv-3-d-secure-whitepaper-v2/3-d-secure-documentation/ (opens in a new tab)
8. EMV Payment Tokenisation — EMVCo. https://www.emvco.com/emv-technologies/payment-tokenisation/ (opens in a new tab)
9. VisaNet Connect — Acceptance — Visa Developer Center. https://developer.visa.com/capabilities/visanet-connect-acceptance (opens in a new tab)
10. Summary of the AWS Service Event in the Northern Virginia (US-EAST-1) Region — Amazon Web Services. https://aws.amazon.com/message/12721/ (opens in a new tab)
11. Cloudflare outage on June 21, 2022 — Cloudflare. https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/ (opens in a new tab)
12. Idempotency — PayPal Developer. https://developer.paypal.com/api/rest/reference/idempotency/ (opens in a new tab)
13. Capture authorized payment — PayPal Developer. https://developer.paypal.com/api/payments/v2/authorizations-capture (opens in a new tab)
14. Cancel — Adyen Docs. https://docs.adyen.com/online-payments/cancel (opens in a new tab)
15. Addressing Cascading Failures — Site Reliability Engineering, Google. https://sre.google/sre-book/addressing-cascading-failures/ (opens in a new tab)
16. Operational resilience: recognised payment system operators and specified service providers — Bank of England. https://www.bankofengland.co.uk/paper/2026/ss/operational-resilience-rpsos-ssps-ss (opens in a new tab)
17. Principles for Operational Resilience — Basel Committee on Banking Supervision, Bank for International Settlements. https://www.bis.org/bcbs/publ/d509.pdf (opens in a new tab)
18. Using ML to detect and respond to performance degradations in slices of Stripe payments — Stripe Engineering. https://stripe.com/blog/using-ml-to-detect-and-respond-to-performance-degradations-in-slices-of-stripe-payments (opens in a new tab)