A payment gateway with multi-PSP routing connects your application to multiple payment processors and routes each transaction to whichever one is best positioned to approve it. Instead of sending all traffic to a single provider, the routing layer evaluates live signals (cost, uptime, historical approval rates) and picks a processor for each request.
This is a product infrastructure decision, not an operations one. If you’re embedding payment capability into a SaaS product or platform, the choice of whether to build multi-PSP routing is an architectural call that affects integration maintenance, payment reliability, and your platform’s ability to support customers in different regions. Understanding what a multi-PSP routing gateway actually does, and how routing logic works in practice, is where to start.
What a payment gateway with multi-PSP routing actually does
A standard payment gateway is a single connection: your application calls one processor’s API, the processor attempts authorization with the card network, and the result comes back. One path in, one path out. If that processor is slow, misconfigured for a specific card type, or simply down, the transaction fails.
A gateway with multi-PSP routing sits in front of several processors. When a transaction comes in, the routing layer applies a set of criteria to decide which processor handles it. The application sees one API surface; the routing layer manages all the provider-specific translation, error handling, and retry behavior behind that interface.
From a developer’s perspective, the integration looks like this: you send a standardized payment request to the routing layer, and it handles gateway selection, request transformation into that gateway’s format, response normalization, and webhook translation back to your webhook format. You write one integration. The routing layer writes (and maintains) the rest.
That abstraction is the practical value of a multi-PSP routing gateway. “As the number of direct integrations grows linearly, complexity and cost grow exponentially,” Brady Harris, CEO of IXOPAY, noted in Payments Dive. A routing layer stops that scaling problem before it starts.
How multi-PSP routing decisions get made
Routing decisions happen before the transaction is sent to a processor. Each transaction triggers an evaluation against a set of criteria, and the result picks which provider gets the request.
The most common inputs to a routing decision:
| Routing input | What the routing layer checks |
|---|---|
| Cost per transaction | Different processors charge different rates for different card types, currencies, and volumes. A transaction on a UK-issued Visa card might be cheaper through one processor; the same card type in Brazil routes differently. Cost routing picks the processor whose interchange-plus or flat rate minimizes total processing cost for that specific transaction. |
| Processor uptime | If a processor is returning errors or responding outside acceptable latency bounds, the routing layer removes it from consideration. Traffic automatically shifts to available processors without manual intervention. |
| Historical approval rates | Some processors have better relationships with specific card networks or stronger issuer connections in specific geographies. A card issued by a Brazilian bank may approve at a higher rate through a processor with local acquiring presence than through a processor routing it cross-border. Routing logic based on historical approval data exploits these patterns. |
| Business rules | Currency requirements, merchant category codes, regulatory constraints, and customer-tier rules can all be encoded as routing criteria. A platform customer running high-volume enterprise transactions might route to a dedicated processor; trial-period transactions might route to a lower-cost provider. |
For deeper context on how routing criteria get configured and prioritized, the payment routing fundamentals guide for developers covers the implementation side in more detail.
Single-PSP gateway vs. multi-PSP routing gateway
| Single-PSP gateway | Multi-PSP routing gateway | |
|---|---|---|
| Processor connections | One | Several |
| Failure mode | Any outage stops payments | Traffic routes to available processors |
| Cost optimization | Accept whatever rate one processor charges | Route to cheapest processor per transaction |
| Approval rate ceiling | Bounded by one processor’s issuer relationships | Route to processor with best historical rate for that card/region |
| New provider additions | Full integration: 3–6 weeks dev time | Enable through routing layer, no new API integration |
| Codebase maintenance | One integration to maintain | One routing layer integration; provider specifics handled by the layer |
| Negotiating position | Zero, you’re stuck with current pricing | Real, you can move volume if pricing changes |
The single-PSP path is simpler to start. The cost arrives later: when a provider has an outage, when pricing changes and you can’t walk away, or when you need to add a regional processor and discover it means building a second full integration.
Rules-based routing vs. dynamic routing
Two fundamentally different approaches exist, and most production systems use both.
Rules-based (static) routing encodes explicit conditions as routing rules: “if currency is EUR and card brand is Mastercard, route to Processor A; if BIN range is 4xxx and transaction amount exceeds $500, route to Processor B.” Rules are deterministic and auditable. You can read the config and predict exactly what will happen for any given transaction.
The limitation is maintenance. Every rule is a prediction about processor behavior. When approval rates shift (and they do), or when a processor changes its fee structure, the rules go stale. Rules-based routing is only as good as the team maintaining it.
Dynamic (smart) routing uses real-time performance data to make routing decisions. The routing layer tracks approval rates, latency, and cost data per processor, per card type, per region, and adjusts routing weights based on observed performance. No one writes a rule that says “route Brazilian-issued Visa transactions to Processor A.” The routing layer learns that pattern from actual approval data and weights accordingly.
Dynamic routing finds patterns in the data that rules-based systems miss. The tradeoff is opacity: it’s harder to audit why a specific transaction routed the way it did. Most production systems combine both: rules set hard constraints (regulatory requirements, customer-tier policies), and dynamic routing optimizes within those constraints.
For a detailed comparison of how static and dynamic routing differ in practice, the guide to payment routing strategies covers the trade-offs in depth.
What multi-PSP routing fixes: approval rates, uptime, and cost
Approval rates. Ferryhopper’s [authorization](/glossary/#authorization) rate improved from 91.76% to 93.87% after implementing multi-acquirer routing, recovering approximately €3.4 million in transactions in a single month via fallback routing (Primer case study). inDrive achieved 11% more payment approvals after implementing multi-PSP smart routing (Payrails case study). These are vendor-published case studies, not independent research, but the numbers reflect a real mechanism: routing a transaction to the processor with the best historical approval rate for that card type and region recovers declines that a single-PSP setup would lose.
Waterfall routing (retrying soft declines through alternative PSPs) recovers 15–22% of soft declines, according to Lago’s analysis, though no primary study is cited there. The mechanism is plausible: many soft declines are processor-specific, not card-specific. A “do not honor” from one processor may approve at another.
Uptime.
US retail and hospitality businesses lose $44.4 billion in sales annually from payment outages, with two-thirds of disruptions hitting during peak hours. (Dynatrace, FreedomPay, Retail Economics, January 2026)
Even Tier 1 processors go down: the 2018 Visa Europe outage resulted in 5 million failed transactions in 10 hours. A multi-PSP routing layer routes around a failing processor automatically, without engineering intervention.
Cost. Sending all traffic to one processor means accepting whatever rates that processor charges. With multiple processors active, the routing layer can direct each transaction to the cheapest available option for that specific card type, currency, and amount. This is particularly relevant for SaaS platforms processing transactions across multiple currencies or for platform customers in different regions where processor pricing varies significantly.
For a quantified breakdown of what single-PSP dependence costs mid-market businesses, the multiple payment gateways analysis has the specifics.
Building multi-PSP routing yourself vs. using an orchestration layer
If your team is evaluating whether to build multi-PSP routing in-house, the realistic scope is:
- A routing layer that normalizes requests into each processor’s format
- A response normalization layer that maps each processor’s result codes and error formats back to a consistent schema
- Webhook normalization for each processor’s event format
- Idempotency enforcement across all processors (preventing duplicate charges when requests are retried)
- Retry logic that respects network rules (Mastercard: 10 retries per 24 hours; Visa: 15 retries per 30 days, per network documentation)
- Routing decision logic, with the data pipeline to feed it
- Ongoing maintenance as each processor updates its API, changes its error codes, or modifies its webhook format
A single PSP integration takes 3–6 weeks of developer time for development and testing, extending to 3–6 months when compliance and certification steps are included (Orchestra and Akurateco estimates independently converge on this range). Building a custom routing layer from scratch takes 6–12 months to reach a production-ready state, not counting ongoing maintenance.
That maintenance load is the real argument against building. Each processor’s API is a moving target. Breaking changes, new authentication requirements, deprecation cycles, and webhook format updates arrive on the processor’s schedule, not yours. A routing layer you build is a routing layer you maintain indefinitely.
The case for building is narrow: multi-PSP routing is a core product differentiator for your business, you have the engineering capacity to maintain it, and the routing logic is sufficiently unique that off-the-shelf options don’t fit. For most SaaS and platform teams, that’s not the situation.
The multi-PSP strategy overview covers the build vs. buy decision in more detail, including what questions to ask before committing to an in-house build.
How Orchestra handles multi-PSP routing
Orchestra connects to 130++ payment providers through two integration paths: the Orchestra API for backend and serverless environments, and the Orchestra JavaScript library for teams that want pre-built payment UI components alongside routing. Both paths support the same routing and failover features.
When a transaction comes in, Orchestra’s routing layer applies the configured routing strategy (cost-based, performance-based, geographic, or hybrid) and sends the request to the selected processor. Routing decisions happen in under 50ms, per Orchestra’s published benchmarks. If the selected processor declines or fails, Orchestra applies the failover configuration, routing to the next available processor based on the same criteria.
For developers already running Stripe or Braintree in production, Orchestra sits alongside those integrations. You can route new transaction types or new platform customers through Orchestra while existing integrations continue handling what they already handle. Preply recovered 30% of previously failed payments by adding Payrails routing alongside existing integrations without rewriting existing PSP connections (Payrails case study). The same incremental adoption path applies with Orchestra.
Orchestra is PCI DSS Level 1 certified. The Library integration path keeps card data off your servers entirely; the API path leaves card collection with you in exchange for full UI control. Either way, the routing layer sits between your application and the processors, and Orchestra maintains the provider-specific integrations.
The sandbox is free, open, and requires no credit card or approval process. Access is immediate. For routing specifically, the payment routing optimization page documents the routing configuration options and what performance benchmarks those configurations typically achieve.
Frequently Asked Questions
What is a payment gateway with multi-PSP routing?
It’s a gateway that sits in front of several payment service providers and routes each transaction to one of them based on rules or real-time performance data, instead of sending all traffic to a single processor.
How is this different from a standard payment gateway?
A standard gateway connects to one processor. A multi-PSP routing gateway connects to several and picks which one handles each transaction, so a single processor outage or high decline rate doesn’t stop payment acceptance.
What criteria drive routing decisions?
Cost per transaction, processor uptime, historical approval rates by card type and region, and business rules like currency or merchant category are the common inputs. Most production systems use a combination of explicit rules (hard constraints) and dynamic routing (performance-optimized within those constraints).
Can I add multi-PSP routing without rewriting my existing integration?
Yes, if the routing layer sits between your application and the processors rather than replacing existing PSP integrations outright. Orchestra is built to run alongside integrations already in production.
Does multi-PSP routing improve approval rates?
Yes, when routing accounts for issuer- and region-specific approval patterns. Sending a transaction to the processor with the best historical approval rate for that card type recovers declines a single-PSP setup would lose. Ferryhopper’s authorization rate improved by ~2 percentage points after implementing multi-acquirer routing, recovering approximately €3.4 million in a single month via fallback routing (Primer case study).
What’s the difference between routing and failover?
Routing picks the best processor before the transaction is sent. Failover routing retries a transaction through a different processor after the first attempt fails. Most production systems need both. Visa limits retries to 15 per 30 days; Mastercard limits retries to 10 per 24 hours. A routing layer must enforce these limits automatically.
Is building multi-PSP routing in-house worth it?
Only if payment routing is a core differentiator for the business. For most SaaS and platform teams, the ongoing maintenance of routing logic, provider APIs, and compliance updates outweighs the build cost. A custom routing layer takes 6–12 months to reach production-ready state, and the maintenance load continues indefinitely after that.
