The redundancy illusion: why five PSPs do not guarantee five payment routes

Operators and payment service providers commonly deploy multiple PSP integrations with the expectation that five or seven partners equal five or seven independent routes. Alexander Mikhailovski, co-founder and chief product officer at eComCharge, argued in an EGR Intel analysis on 15 October 2026 that those counts can be misleading: several PSPs frequently rely on the same underlying acquirer, domestic rail or traffic restriction, so a single event can remove multiple so-called routes at once.

Why payment provider redundancy can be an illusion

Counting providers is a simple metric. It is also often wrong. An operator might contract with five PSPs — five integrations and five routing destinations on architecture diagrams — but several of those PSPs can converge on the same acquiring relationship for an important market. If that acquirer changes its gambling risk appetite, or stops accepting a market's transactions, three configured routes can disappear simultaneously.

The practical consequence is immediate during an incident: routing systems will move traffic from Provider A to Provider B and then to Provider C because all APIs are healthy, but the business problem remains if all three share the same acquiring dependency. The routing logic has executed perfectly while the operator has no usable destination for that class of traffic.

Map dependencies, not logos — a pragmatic resilience checklist

A useful resilience review focuses on what sits behind each route, not on provider brand names. For card routes, that requires identifying:

• the underlying acquiring bank or relationship

• the supported markets and merchant category codes (MCCs)

• applicable currency and transaction-type restrictions

• any domestic payment rail dependencies for local methods

If multiple routes depend on the same acquirer or local rail, they are correlated failure domains. Independence is not enough: a backup route must actually accept the same traffic in practice — the relevant market, MCC, currency and transaction type. When adding a provider to improve resilience, ask explicitly: "What failure does this integration protect us from?" The answer should name the dependency and the failure mode, not simply the provider logo.

Correlation is the hidden risk in routing logic

Most orchestration platforms and in-house routers can answer a single operational question: if Provider A becomes unavailable, where should traffic go next? They cannot, by themselves, answer whether Provider B is a truly useful alternative for the specific traffic that failed. Imagine an acquiring bank withdraws acceptance for gambling transactions from a country. The router shifts traffic through the configured sequence but every configured provider uses that same acquirer for that country. Connections remain healthy; the traffic has nowhere to go.

This is the central point Mikhailovski makes from his work at eComCharge: a provider is only one failure domain. Several PSPs can expose several acquiring paths in normal conditions, yet converge on the same underlying banking relationship for a market or traffic segment. The result is an architecture that looks diversified on a diagram but, in reality, offers only a small number of independent alternatives.

How to test whether redundancy is genuine

A tabletop exercise exposes false redundancy quickly. Pick an important dependency and assume it disappears tomorrow. Useful scenarios include:

1. the main acquiring relationship for a market becomes unavailable

2. a country-specific payment rail stops processing

3. an acquirer stops accepting the operator's primary market or MCC

4. a provider tightens or withdraws its gambling risk appetite

Run the routing exercise and track where the affected traffic would go. The key metric is whether the alternative destination is both independent and able to accept the same traffic. A stack with seven integrations can turn out to have only three independent alternatives for its most important traffc; conversely, two providers with different acquirers and geographies can provide superior protection to five superficially separate connections.

Orchestration helps manage routes but does not create independence

A centralised orchestration layer makes defining routing logic and observing provider performance easier, and it can move traffic immediately when conditions change. Link orchestration to your payment operations and it becomes faster to respond. However, orchestration cannot manufacture an independent acquiring route where none exists.

Routing engines should be treated as execution platforms, not risk mitigants. They can shift traffic from Provider A to Provider B, but if both share the same underlying acquirer or rail, that flexibility is of limited value. As Mikhailovski notes, centralised orchestration can make route management faster and more transparent, but routing decisions can only account for dependencies you actually know about.

Operators and PSPs wanting to raise resilience should therefore combine orchestration with dependency mapping and targeted testing. That approach clarifies whether an added integration protects against an acquirer-level failure, a domestic rail outage, MCC-based restrictions, currency limitations or provider-level API downtime.

Practical steps for payments teams

Payments and product teams can apply a short set of actions to convert perceived redundancy into real resilience:

• inventory every active route and record the underlying acquirer or rail

• tag routes by market, MCC, currency and transaction type

• run failure scenarios for the most revenue-sensitive traffic

• prioritise new integrations that introduce different acquiring relationships or geographies

• document the protection each integration provides and the specific failure modes it mitigates

These steps turn integration count from an inventory metric into a decision tool. Integration still matters — acquiring channels will appear, disappear and change terms — but the objective should be enough independence between the routes that matter most so that losing an important part of the stack leaves somewhere genuinely different and usable to send the traffic.

Alexander Mikhailovski is co-founder and chief product officer at eComCharge and has more than 20 years' experience in payment technologies, specialising in rules-based payment core systems for high-risk verticals including iGaming and forex. His analysis on the redundancy illusion first appeared on EGR Intel on 15 October 2026.

For payments teams, the takeaway is simple: stop counting providers and start mapping dependencies. Technical orchestration and routing are necessary, but true resilience comes from knowing which routes can fail independently and which cannot. See the wider implications for payments operations in our payments and b2b coverage.