Every payment integration starts the same way. You pick a PSP, wire up the API, handle webhooks, write tests, ship it. Then someone asks for a second processor. Maybe the primary has poor approval rates in Germany, or finance wants a cheaper option for low-risk domestic transactions, or the CEO read an article about redundancy. Whatever the reason, you now have two sets of API calls, two webhook formats, two error code mappings, two sets of card forms to embed in your site, and a routing decision that lives somewhere in your codebase.

That routing decision, how your system picks which PSP handles each transaction, is payment routing. And the way you implement it has measurable effects on revenue, uptime, and how much of your week gets spent on payment plumbing versus your actual product.

This is a developer-focused guide to payment routing fundamentals. We will cover the three routing strategies worth knowing, the real cost of maintaining routing logic yourself, and where an orchestration layer fits.

What payment routing actually does

Payment routing is the logic that decides which PSP processes a given transaction. The inputs are things you already know about: card type, issuing country, transaction amount, currency, provider availability. The output is a processor selection, made in milliseconds, before the customer sees a loading spinner.

def route_transaction(txn):
    candidates = get_psps_for(txn.card_network, txn.currency, txn.issuing_country)
    ranked = apply_routing_rules(candidates, txn)
    for psp in ranked:
        result = psp.authorize(txn, idempotency_key=txn.id)
        if result.approved:
            return result
    return DeclineResult(reason="all_providers_failed")

The reason this matters is straightforward. Different PSPs have different approval rates for different transaction profiles. A processor that approves 96% of UK Visa transactions might only approve 88% of Brazilian Mastercard transactions. Sending everything to one provider leaves money on the table.

The numbers bear this out. According to Optimus Tech, 15-20% of e-commerce payment attempts fail at authorization after the customer has already committed to purchase. Cross-border transactions are worse, with decline rates of 25-35% without geography-aware routing. That is not a rounding error. For a merchant processing $10M monthly, a 3% improvement in authorization rates represents $300K in recovered revenue per year.

Static routing, where every transaction goes to the same provider based on fixed rules, works fine when you have one PSP. The moment you add a second, you need to decide how traffic splits. And that decision should not be hardcoded.

Most routing implementations start as a simple if/else in your checkout flow: domestic transactions go to processor A, international to processor B. That works until processor A has an outage on a Friday night, or until you realize processor B charges 40 basis points more for certain card types. The routing logic grows incrementally, one business rule at a time, until it becomes the kind of code nobody wants to touch because nobody fully understands all the conditions.

Three routing strategies that matter

There are three routing patterns worth implementing. Each solves a different problem, and most production systems end up using all of them together.

Strategy	Optimizes for	Typical impact
Least-cost	Cost	1-2% fee reduction
Performance	Auth rates	2-3% approval uplift
Failover	Uptime	Prevents 28% churn risk

Least-cost routing

Least-cost routing sends each transaction to the cheapest processor that can handle it. PSPs charge different interchange rates, different markup percentages, and different per-transaction fees depending on card type, currency, and volume tier. Routing a $500 international corporate card transaction through the wrong processor can cost 1-2% more than routing it through the right one.

The implementation is a lookup: given the transaction attributes, which provider offers the lowest total cost? The complexity comes from keeping fee schedules current and handling the edge cases, like processors that offer lower rates but cap monthly volume.

Australia has actually mandated least-cost routing for contactless debit transactions, which tells you something about how much money is at stake.

One subtlety: least-cost routing needs to account for total cost, not just the per-transaction fee. A processor with lower interchange but higher chargeback fees can end up costing more depending on your dispute rate. The routing logic needs access to your full fee structure per provider, updated when contracts change, which happens more often than you might expect.

Performance-based routing

Performance-based routing sends transactions to the provider with the highest current approval rate for that transaction type. This is dynamic, not static. You monitor each PSP’s approval rate by card network, country, and transaction size, then route accordingly.

Capgemini Research Institute data shows that payment orchestration improves authorization rates by 2-3% on average through this kind of dynamic routing. Stripe reports a similar number: their Adaptive Acceptance system increases authorization rates by roughly 2.2% on average, with enterprise clients like Hertz seeing around 4% uplift.

A 2% improvement sounds small until you run the math on your transaction volume. For a business processing 100,000 transactions per month at a $75 average, that is 2,000 additional successful payments, roughly $150,000 in monthly revenue that would otherwise be declined.

Failover routing

Failover routing is the safety net. When a PSP goes down or starts declining transactions at an abnormal rate, the system reroutes to a backup provider. The customer sees nothing. The retry happens within the same checkout session.

This is where things get technically interesting. Failover requires solving three problems simultaneously:

• Idempotency keys to prevent duplicate charges when retrying
• Timeout logic aggressive enough to catch a degraded provider but not so aggressive that normal latency spikes trigger unnecessary failovers
• Handling the case where the primary PSP actually did charge the card but responded slowly, so your failover also charges the card

The stakes are real.

Key point: Stripe’s Adaptive Acceptance recovered $6 billion in falsely declined transactions in 2024, a 60% year-over-year increase.

And according to Retail TouchPoints, 28% of customers shop elsewhere after a single payment failure. Failover routing is not a nice-to-have. It is directly tied to customer retention.

For developers building high availability in payment processing, failover is the most impactful pattern you can implement.

In practice, failover configuration involves decisions that look simple but have real consequences. How many retries before giving up? Which decline codes are retryable (a “do not honor” response from the issuer is different from a network timeout)? Do you retry on the same PSP or immediately cascade to the next one?

Warning: Each of these choices affects both your approval rate and your relationship with card networks, which monitor retry behavior and can flag merchants who retry too aggressively.

The real cost of building routing yourself

Building routing for one PSP is trivial. Building it for two is manageable. Building it for three or more is where the maintenance burden starts compounding in ways that are hard to predict until you are already committed.

Each PSP integration has its own API surface, its own authentication scheme, its own error codes, its own webhook payload format. According to Crafting Software’s architecture analysis, each new PSP integration requires 3-6 weeks of development, testing, and certification. A custom routing build takes 6-12 months, compared to 4-8 weeks for platform adoption.

Factor	Build in-house	Orchestration platform
Initial build	6-12 months	4-8 weeks
Each new PSP	3-6 weeks dev, test, and cert	Configuration
PCI scope	Expands with each connection	Reduced audit surface

But the initial build is not the hard part. The hard part is maintenance. PSPs deprecate API versions, change webhook formats, update authentication requirements, and modify their fraud rules, all on their own schedules. Each change requires investigation, code updates, testing, and a deployment cycle. If you have five PSP integrations, you are handling these changes five times, with five different timelines and five different breaking-change patterns.

Then there is the routing logic itself:

• Keeping fee schedules current
• Monitoring approval rates across providers
• Adjusting thresholds for failover triggers
• Handling edge cases where a provider is partially degraded (high latency but not fully down)

This is a product unto itself, one that needs its own monitoring, its own alerting, and its own on-call rotation.

We’ve seen teams estimate “two sprints” for a multi-PSP routing system and still be working on it six months later. The nonlinear scaling is the trap. One integration is a feature. Five integrations is a product. And every sprint spent on payment plumbing is a sprint not spent on whatever your company actually sells.

There is also the compliance dimension. PCI DSS 4.0, which became fully mandatory in March 2025, requires secure coding practices integrated into SDLC and security scanning in CI/CD pipelines. Each direct PSP integration that touches card data expands your PCI scope. A routing layer that handles tokenization before transactions reach your application server reduces the audit surface, but only if the routing layer itself is PCI-certified.

For a multi-processor authorization rate improvement strategy, the question is not whether multi-PSP routing helps. The data clearly says it does. The question is who maintains the routing layer.

What orchestration changes for developers

A payment orchestration platform sits between your application and your PSPs. You integrate once, and the platform handles the routing logic, failover, provider maintenance, and ongoing PSP API changes.

Orchestra does this through a single JavaScript library. You make one integration, and Orchestra routes transactions across 90+ providers based on cost, performance, geography, and your business rules. When a PSP updates their API or deprecates an endpoint, Orchestra handles the update. Your code does not change.

Here is what that means in practice. Instead of maintaining separate integration code for Stripe, Adyen, and a regional processor, you maintain one integration. Instead of building your own approval-rate monitoring and failover logic, you configure routing rules through Orchestra’s intelligent payment routing. Instead of managing PCI scope across multiple provider connections, you handle card data once through Orchestra’s tokenization layer, and the backend routing operates on tokens, not raw PANs. For developers working through PCI DSS 4.0 requirements, this scope reduction matters.

The trade-off is real and worth stating: you are adding a dependency. Orchestra becomes a component in your payment path, which means another network hop and another vendor relationship. The case for that trade-off is that maintaining five PSP integrations, a custom routing engine, failover logic, and fee optimization is itself a dependency, just one that lives in your codebase and consumes your team’s time. Most teams hit the break-even point somewhere around their second or third PSP integration, where the maintenance cost of doing it yourself exceeds the cost of a platform.

The adoption path matters too. You do not have to rip out working Stripe code on day one. A phased approach reduces risk:

1. Keep existing direct integrations running
2. Route new providers through the orchestration layer
3. Validate the platform against real traffic before committing fully

This is how most production migrations work: incremental, not big-bang.

For teams evaluating this decision, understanding how payment orchestration simplifies online payments provides useful context on what the integration actually looks like.

Frequently asked questions

What is payment routing and how does it work?

Payment routing directs each transaction to the most appropriate PSP based on geography, card type, cost, and provider performance. The routing decision happens in milliseconds and directly affects approval rates and processing costs. At its simplest, routing is a lookup: given the transaction attributes, which provider is the best fit right now?

What is the difference between static and dynamic payment routing?

Static routing sends transactions to a fixed provider based on predefined rules, like “all EUR transactions go to Adyen.” Dynamic routing adjusts in real time based on provider performance data, shifting traffic to the PSP with the highest current approval rate or lowest cost. Dynamic routing requires monitoring infrastructure but delivers measurably better results, with Capgemini Research Institute data showing a 2-3% average improvement in authorization rates.

How does fallback routing recover failed transactions?

When a PSP declines or fails to process a transaction, fallback routing automatically retries through an alternative provider. The customer sees no interruption, as the retry happens within the same checkout session. Implementation requires idempotency keys to prevent duplicate charges and careful timeout configuration to distinguish between provider failures and normal latency variation.

How much can dynamic routing improve authorization rates?

Capgemini Research Institute data shows payment orchestration improves authorization rates by 2-3% on average through dynamic routing (Gr4vy, 2025). Stripe reports a 2.2% average uplift via Adaptive Acceptance, with enterprises like Hertz seeing around 4% (Stripe, 2025). The improvement varies by merchant profile and geography.

Should developers build payment routing in-house or use an orchestration platform?

Building in-house is viable for one or two providers, but the maintenance cost scales nonlinearly. A custom build takes 6-12 months and requires dedicated engineering resources, while platform adoption takes 4-8 weeks (Crafting Software, 2025). Each additional PSP adds 3-6 weeks of development, testing, and certification. Once you are past two PSP integrations, the total cost of maintaining custom routing typically exceeds the cost of an orchestration platform.