If you're running multiple PSPs, there's a good chance your revenue is slipping through the cracks in two places. One is soft declines that another processor probably would've approved. Another is transaction fees that gradually climb because your routing logic no longer reflects how processors are actually performing in the real world.
The tricky part is that neither problem announces itself. There's no flashing dashboard alert or dramatic outage telling you fees are creeping upward. But once you unify the data, the patterns become clear, and smarter payment routing is usually where the turnaround starts.
If you want to know the basics first, we recommend checking out our piece on the fundamentals of payment routing. In this article, we'll dig into how routing engines work in practice: the difference between cascading and weighted routing, where rule-based logic struggles, the role of machine learning, and how routing fits into a broader payment orchestration strategy.
What smart payment routing does
Smart payment routing is the real-time process of selecting the best available processor for each transaction before the authorization request even leaves your stack.
With static routing, every payment goes to the same fixed processor, whether it's the right fit or not. That might seem harmless early on, but at scale, it leaks revenue in ways that can go unnoticed for months. One processor may perform reliably with domestic debit payments but struggle with cross-border credit. Another may offer attractive EUR pricing while maintaining weaker issuer relationships in Southeast Asia. Static routing accepts those declines.
Smart routing works differently. The transaction is evaluated in real time against fixed attributes and live processor performance signals, then sent to the processor most likely to approve it at the lowest viable cost.
So if the routing engine sees that Processor B is approving a specific BIN in a specific market 12 percentage points more often, it routes there instead, and the transaction clears the first time.
Inside the routing engine: Inputs and decisioning
Every routing decision happens in under 100 milliseconds. The engine balances two types of input simultaneously: fixed transaction attributes that don't change, and live performance signals that do.
Fixed transaction-level attributes include:
- BIN data (the first 6–8 digits) reveals the issuing bank, card scheme, card type, and country of issue.
- Card network – Visa, Mastercard, Amex, and local schemes all behave differently when it comes to interchange, issuer relationships, and processor performance.
- Currency and transaction amount – some processors consistently perform better in certain currency corridors or transaction bands.
- Cardholder geography – the relationship between the issuing country and transaction country determines cross-border classification and which processor agreements apply.
- Merchant Category Code (MCC) – some MCCs face processor-specific restrictions or elevated decline rates on certain networks.
- SCA exemption status – transactions eligible for TRA exemptions can be routed to acquirers with strong exemption acceptance rates, keeping checkout friction low.
Real-time performance signals include:
- Current approval rate per processor, segmented by card type and geography.
- Recent decline-rate movement, especially when a processor's performance suddenly deteriorates over the last few minutes.
- Latency and availability – processors are automatically removed from selection if response times drift outside acceptable thresholds.
A $420 Visa debit transaction illustrates how this plays out.
Historically, Processor A performs well with this BIN, so in a static setup, it gets the traffic automatically. But the routing engine also sees that Processor A's decline rate on this card type has spiked in the last five minutes.
Processor B has a slightly lower overall approval rate, but live performance is stable, and recent issuer results look stronger. The engine reroutes to Processor B, and the transaction clears.
Without that live performance layer, the payment would have followed historical preference straight to Processor A and likely declined.
AI and payment routing: Separating signal from noise
There's a lot of noise in the payments industry about AI-based routing. Much of it assumes routing decisions can be handed to large language models or generative AI systems. That assumption doesn't hold.
Payment authorization decisions happen in under 100 milliseconds. LLMs are too slow and too resource-intensive to operate at that latency – they simply cannot fit inside the decision window that authorization requires. This is an architectural constraint, not a feature gap. Any vendor claiming to use LLMs in the authorization path is either describing something happening outside the transaction window (like pre-processing analytics), or overstating what their system actually does.
The AI approach that does work is ML models trained on historical authorization data. These are lightweight, fast, and purpose-built for one task: scoring approval probability given a specific combination of transaction attributes, processor state, and issuer behavior. The model doesn't need to understand language. It needs to reliably predict, in milliseconds, which processor is most likely to approve a given transaction.
The most effective implementations today combine ML with expert oversight. The model surfaces routing recommendations based on patterns in the merchant's own traffic. A payments expert reviews them. Approved recommendations go into the routing workflow. As confidence in the model builds, the loop tightens and the model handles more of the pattern-recognition work.
For merchants early in a multi-PSP setup, running rules alongside ML while the model trains on live data is usually the most stable approach. The rules provide continuity, and the model gradually learns the patterns that manual logic can't track at scale.
For more on how we're approaching this at Payrails, see our breakdown of AI in payments.
Cascading routing: Recovering soft declines
Cascading turns a soft decline into a recovered transaction rather than a lost sale. A soft decline is a temporary rejection from the issuer; the payment is eligible for retry. A hard decline (e.g., a closed account) is permanent and should never enter a cascade flow.
The flow is precise: soft decline → the engine checks the transaction against retry rules → resubmit via a secondary processor → stop or escalate based on the result and your configuration.
From the customer's side, none of this is visible. Checkout clears on the first attempt rather than failing. At scale, those recoveries add up, which is why intelligent routing and cascading have become high-return levers for merchants with multiple PSPs.
Network retry rules
Visa and Mastercard both enforce retry limits, and exceeding them can become expensive quickly.
As of 2026, Visa allows up to 15 retries within 30 days for Category 2 and 3 declines. Mastercard's Transaction Processing Excellence (TPE) program applies two separate penalty structures:
- An excessive authorization fee of $0.30–$0.55 per retry above the limit (10 per 24 hours, 35 per 30 days).
- A separate MAC fee of $0.03–$0.50 per transaction for retries following a MAC 03 or MAC 21 decline code.
These thresholds shift regularly, so always confirm the latest guidance directly with Visa and Mastercard before relying on any figures operationally.
When the system automatically filters retry eligibility by decline code, tracks retry counts per transaction, and stops retries before thresholds are breached, a major compliance burden disappears from your ops team. More importantly, it prevents the slow-burning fines that bad retry logic can accumulate without anyone noticing.
Weighted routing: Distributing volume across processors
Instead of betting every payment on a single best route, weighted routing spreads transaction volume across processors using set percentages – e.g., 60% to Processor A, 30% to Processor B, 10% to Processor C. Where cascading kicks in after a decline, weighted routing proactively distributes traffic before anything breaks. In mature payment stacks, the two typically work side by side.
You also spot performance issues earlier. If Processor B's approval rate drops 4 points over 48 hours, that's the kind of shift processor analytics catches long before it becomes a finance conversation. Rather than pulling the processor entirely, you might shift the split from 60/30/10 to 70/15/15, cutting exposure while preserving the relationship.
Without unified PSP data, that kind of trend can take days to identify. With it, the adjustment takes minutes.
Why merchants run weighted even with a 'best' processor
Approval rates are only part of the story. The operational and commercial case for weighted routing matters just as much:
- Redundancy: If checkout depends on a single processor, one outage can shut down your revenue. Spreading traffic across multiple active processors keeps payments flowing when one provider dips in performance.
- Continuous measurement: Running similar transaction profiles across processors creates live performance data without needing a separate testing phase. Production becomes the test environment.
- Negotiation leverage: A merchant that can credibly move 30% of volume elsewhere walks into PSP renewal talks with considerably more bargaining power than one tied to a single provider.
Weighted routing is only as good as the data behind it. If processor data is fragmented or incomplete, you're redistributing volume blindly. Reliable, standardized processor measurement is what makes the strategy worthwhile.
A/B testing routing logic with weighted splits
Weighted splits also create a clean way to test routing decisions in production.
A 50/50 or 60/40 split across a tightly matched transaction segment – same BIN range, geography, or amount band – becomes a controlled processor comparison in a live environment. Once the sample is statistically meaningful, you can compare the approval-rate delta between routes with confidence.
Decisions stop being driven by instinct or anecdotal processor complaints. Rebalancing is backed by data that finance and engineering teams can actually trust.
Explainability and auditability trade-offs
ML routing models usually outperform static rules at scale, but there's a trade-off worth naming: the smarter the decisioning becomes, the harder individual routing decisions can be to interrogate without proper monitoring and explainability tooling. The same unified data layer that powers routing also needs to support the audit trail.
Cross-border routing and local acquiring
Cross-border routing is usually where the biggest gains appear in both approval rates and interchange costs. Get transactions flowing through the right regional processors and acquirers, and you can often lower interchange costs and lift authorization rates on the very same transactions.
Take a French cardholder buying from a US merchant. Two problems stack up immediately:
- The issuer sees an unfamiliar acquiring geography and may treat it as a fraud signal, hurting approval rates.
- The transaction falls outside the EU Interchange Fee Regulation's domestic caps – IFR 2015/751 limits domestic consumer card interchange to 0.2% for debit and 0.3% for credit, but transactions acquired outside the cardholder's region can attract higher scheme fees or sit outside those caps entirely. Post-Brexit, UK transactions fall under equivalent caps enforced by the PSR (Payment Systems Regulator). Merchants acquiring across both regions need processor agreements that reflect each framework separately.
Route that same payment through a local acquirer instead, and you'll typically see both a higher approval rate and a lower processing cost.
Why multi-region acquiring stalls without an orchestration layer
The catch is that local acquiring multiplies operational complexity quickly. Each regional acquirer adds a contract, settlement flow, compliance requirement, and FX process to manage.
That overhead is exactly what an orchestration layer absorbs. Payrails handles the per-acquirer complexity so you can keep the approval-rate benefit without the operational burden.
Benefits and what smart routing does not solve
Smart routing can give authorization rates a real lift, but the actual uplift depends on how well the setup aligns with your transaction mix.
inDrive increased payment approvals by 11%, while Preply recovered 30% of previously failed payments using our platform alongside unified analytics. That visibility is what let them prove where the improvements came from.
When false declines drop, checkout abandonment falls with them.
What these numbers require
Smart routing needs at least two active PSPs and enough transaction volume – roughly 10,000 transactions per month – to surface meaningful processor-level patterns. Below that, there isn't enough signal to optimize against.
These outcomes typically rely on three things being right:
- Correct routing configuration: Rules or ML models tuned to your actual transaction patterns rather than generic defaults.
- Clean PSP data: Authorization outcomes normalized into a consistent schema across processors.
- Multi-PSP relationships: Requires at least two active processors to route between. With one PSP, there's nothing to optimize.
Without unified analytics sitting across processors, it's also hard to tell whether routing is genuinely improving performance or simply shifting volume around at the same approval rate.
What smart routing is not
Smart routing solves one specific problem: getting each transaction to the processor most likely to approve it at the lowest cost. Everything else sits outside that scope.
Chargeback prevention sits with fraud controls, 3DS configuration, and a structured chargeback management program. Checkout UX improves only to the extent unnecessary declines disappear; wider UX work belongs elsewhere. PSP relationships stay where they are.
Smart payment routing with Payrails
Payrails sits across your existing PSPs as a processor-agnostic platform. You keep ownership of your tokens, routing logic, and data, while Payrails adds the payment orchestration that makes multi-PSP routing workable at scale.
Because Payrails connects providers through a single integration, it also handles the normalization and API maintenance, so your engineers aren't maintaining PSP integrations every time a provider changes something.
A good example is Teknasyon. Even with hundreds of experienced in-house developers, they found the overhead of scaling multi-PSP integrations too resource-intensive. After moving to our modular setup, they reduced PSP time-to-market by 75%, which meant engineering effort could go back into building the product.
The Payrails stack behind this includes:
- Unified API – a single integration point across connected PSPs.
- Provider-agnostic Token Vault – portable card data across processors without retokenization.
- ML-assisted routing – approval probability scoring using BIN, issuer, currency, and live performance signals, currently in rollout with select merchants.
- Unified Analytics – cross-PSP performance data consolidated into a single view.
Put smart routing to work
A production routing layer brings together real-time decisioning, cascading, weighted routing, and live PSP performance data in one place. Because everything runs on unified PSP data, routing decisions are made with more context than any single processor can provide on its own.
The signals are often already sitting in your decline data. Once you can see performance across processors side-by-side, it becomes much clearer where smarter routing would lift approval rates or recover failed payments.
Share your processor mix and decline breakdown with the Payrails team, and we'll model exactly where intelligent routing can move the needle for your transaction mix.
I am the text that will be copied.
