Multi-Acquirer Routing: When and How to Add a Second PSP

One PSP is simpler. It is also a single point of failure, a single point of negotiation, and a single point of optimisation.

Most operators add a second PSP for one of four reasons: their auth rate is underperforming and they believe another acquirer does better on their BIN mix; they want redundancy after a checkout outage cost them revenue; they are entering a market where a local acquirer outperforms their global processor; or they want competitive leverage at renewal. Usually it is a combination of two or three.

This guide covers when the second PSP is worth it, how to route across two, and what operators consistently underestimate about the cost of running both.

Why operators add a second acquirer

Auth rate optimisation

Authorisation rates vary by acquirer, by BIN range, by card type, and by issuer relationship. A transaction on a UK-issued Visa card processed through Stripe may authorise at a different rate than the same transaction routed through Adyen, because the two acquirers have different issuer relationships, different fraud model outputs, and different scheme fee structures that influence their routing priority.

For merchants with a complex BIN mix — cross-border cardholders, commercial cards, international consumer credit — routing different transaction types to the acquirer that performs best on that BIN can drive meaningful auth rate improvement.

The data to prove this: run your transactions through a single PSP for 90 days, export a BIN-level auth rate breakdown, and identify which BIN ranges underperform the network average. Those are the candidates for a second acquirer route.

Redundancy

Checkout outages cost real money. The PSP infrastructure outages that made news over the past several years — Stripe, Adyen, Worldpay all had incidents — represent hours of checkout downtime for merchants who had no fallback.

A second PSP gives you a failover path. When the primary processor returns a system error rather than a decline, the orchestration layer reroutes to the secondary. The customer sees a delayed response; they do not see a failed payment page.

The redundancy case is strongest for high-volume merchants during peak trading periods. Losing 30 minutes of checkout during a sale event is a different cost profile than losing 30 minutes on a quiet Tuesday.

Geographic optimisation

A global PSP like Adyen or Stripe performs differently in different markets. Local acquirers often have better issuer relationships in their home market, qualify for different interchange categories, and reduce cross-border processing fees.

Operators expanding into markets where their primary PSP has limited local presence — Southeast Asia, Latin America, parts of Africa — frequently find that adding a local acquirer for those markets improves both auth rates and effective cost of acceptance.

Contract leverage

The least discussed reason, but often the most financially significant. A PSP offering you a contract renewal knows that your cost of switching is high. If you have a second PSP already in production, your cost of moving volume is low. That changes the negotiation dynamic at renewal.

Operators who have invested in an orchestration layer routinely report better pricing outcomes at PSP contract renewal. The second PSP does not need to carry significant volume — it needs to be real and live.

---

Routing strategies

A multi-acquirer setup without routing logic is just two PSPs running in parallel. The value comes from the routing decisions.

Success-rate routing — Route each transaction to the acquirer with the highest historical auth rate for that card type, BIN range, or transaction category. Requires 30–90 days of data per PSP to build a reliable model.

Least-cost routing — Route to the acquirer that produces the lowest blended cost for that transaction. For domestic debit transactions in regulated markets, local acquirers often qualify for lower interchange. For cross-border consumer credit, the cost differences can be significant.

BIN-level routing — Route UK-issued Visa to PSP A, US-issued Mastercard to PSP B, and so on. A rougher version of success-rate routing that works well when you have clear data showing one acquirer outperforms on specific card origins.

Geo routing — Route based on the cardholder’s market rather than the card BIN. Useful for operators with a local acquirer in specific markets who want to capture local processing advantages.

Fallback routing — A safety net rather than a primary strategy. If PSP A returns a hard decline (do not honour, card blocked), do not retry there. If PSP A returns a soft decline (insufficient funds, retry), attempt once more with PSP A. If PSP A returns a connection error, immediately failover to PSP B.

Not all retries are equal. Retrying a hard decline on a second PSP is unlikely to result in authorisation and may flag the transaction for fraud. Success-rate and fallback routing logic should be informed by scheme rules, not just engineering intuition.

---

Build vs buy: the orchestration layer

When operators decide to add a second PSP, they face a choice: build a routing layer internally, or use an off-the-shelf payment orchestration platform.

The economics of build vs buy:

Consideration	Build	Buy
Initial integration	High (6–12 months)	Low (weeks with existing PSP connectors)
Ongoing maintenance	High (scheme rules change, PSP APIs update)	Managed by vendor
Flexibility	Full	Vendor-limited
Token management	You own the vault	Vendor manages
Reporting	Custom build required	Normalised out of box
Typical threshold to justify	$20M+ monthly	Sub-$20M

The market for payment orchestration platforms has grown rapidly — from USD 2.65 billion in 2025 to a forecast of USD 7.27 billion by 2031 — driven by exactly this build-vs-buy question. For most operators below $20M monthly volume, buying an orchestration layer is significantly cheaper than building one.

Major orchestration platforms

Spreedly — The longest-established pure-play orchestrator. Connects to 120+ payment gateways across 100+ countries via a single API. Strong for marketplaces and platforms that need to support multiple merchant types with different PSP needs.

Gr4vy — Cloud-native orchestration with a distinctive architecture: each merchant gets a dedicated cloud instance (AWS, GCP, Azure, or private cloud) rather than shared infrastructure. Provides real-time routing optimisation and strong separation of merchant environments.

Primer — No-code configuration interface that allows business and payments teams to modify routing logic without engineering involvement. Strong in gaming, retail, and travel. The no-code layer reduces the operational overhead of maintaining routing rules.

Corefy — European-focused orchestrator with a broad connector library. Used by operators in regulated European markets who need compliance-aware routing.

Regional options: Pomelo (Latin America), Cellulant (Africa), and others serve specific geographic needs where global orchestrators have thinner connector networks.

---

What operators underestimate

Reconciliation

With one PSP, reconciliation means one settlement file. With two PSPs, you have two settlement files, two fee structures, two dispute management flows, and two data formats to normalise. The engineering required to produce a single source of truth across two processors is consistently underestimated.

Before adding a second PSP, map out your reconciliation process end to end. If your current reconciliation is manual or semi-automated, fix that first.

Token portability across acquirers

Existing PSP tokens only work on the PSP that issued them. If 30% of your transaction volume is from returning customers with stored credentials, those stored credentials are vaulted by your primary PSP. Routing those transactions to a second acquirer requires either cross-PSP token bridge support (most orchestration platforms have this, in limited form) or re-authorisation.

Network tokens mitigate this partially — see the network tokens breakdown — but do not eliminate it entirely. MID-bound network tokens still require a re-tokenisation event when switching the underlying acquiring relationship.

Chargeback ownership

When a transaction routed to PSP B results in a chargeback, the dispute is managed through PSP B’s chargeback process, using PSP B’s reporting and representment interface. If your team is accustomed to a single chargeback workflow, managing two separate flows with different timelines and evidence submission requirements adds operational complexity.

Define chargeback ownership clearly before routing any live volume to a second PSP.

The “when not to” case

Multi-acquirer routing is not always the right answer:

• Under $5M monthly: The operational overhead typically exceeds the auth rate and cost benefit. Fix your integration with your primary PSP before adding a second.
• Single-market merchants: If your card volume is primarily one country with one card type, BIN-level routing adds complexity without meaningful differentiation.
• No data on auth rate by PSP: Running two PSPs without measurement infrastructure means running blind. Build measurement before adding routing logic.
• Unhappy with your current PSP: Adding a second PSP does not fix a bad primary relationship. If your primary PSP has systematic issues — poor issuer relationships, unreliable infrastructure, poor support — fixing or replacing it is a better use of resources than routing around it.

---

The orchestration layer in 2026

The payment orchestration market is expanding faster than most adjacent infrastructure categories. The 18% CAGR through 2031 reflects a genuine shift in how operators think about PSP relationships — from single-vendor dependencies to managed portfolios of payment capabilities.

The direction of travel is toward treating PSPs as commodity inputs and building value at the orchestration layer. Whether you build that layer or buy it, the operators who will be best positioned at scale are those who decouple their checkout logic from any single processor’s API before they need to.

The right time to do that is before you need to.