Every modern payment orchestration platform makes it easy to build routing logic: send German cards to provider A, route Apple Pay through provider B, retry declined transactions on provider C.
In the beginning, this feels like a superpower. A set of sophisticated rules, and your payments flow exactly where you want them.
But rule sets grow. A new market launches, so you add rules. A provider has an outage, so you add exceptions. A BIN range underperforms, so you carve it out. Two years later, you're looking at hundreds of interlocking conditions that nobody fully remembers the reasons for.
When routing rules stop scaling
Every change risks breaking something else, testing a new idea means untangling the existing logic first, and the person who built half of it has left the company. The platform still executes your rules flawlessly, but the problem is that maintaining and extending them has become the bottleneck.
And here's the deeper problem. Even a perfectly maintained rule set can only encode the patterns a human has noticed. Payment traffic is enormously diverse: millions of transactions spread across issuers, card types, currencies, networks, token types, retry states, and times of day, each combination with its own approval behavior per provider. Somewhere in that haystack are thousands of needles: narrow slices of traffic where a different provider would approve meaningfully more payments. No analyst, however good, can find them all by hand. The space is simply too large, and the edge cases too many.
Luckily, this is exactly the kind of problem machine learning is especially adept at solving.
How Payrails uses machine learning to route smarter at scale
What if instead of writing ever more rules, you could train a machine-learning model on your own payment data - and let it figure out all of that complexity automatically?
That's exactly how we are currently applying machine learning to smart routing at Payrails. For each merchant, we train a model on their entire payment history across all connected providers. While we currently stick to only data of one merchant, we are noticing gradual improvements in the merchant-level model driven by insights gained from analyzing PSP behavior across the network. For every transaction, the model predicts which payment provider is most likely to get it approved. At the end, we turn those predictions into concrete, reviewable routing changes that lift authorization rates. It's AI-powered, human-in-the-loop, built on Payrails' own data, and fully explainable.
Because the model learns from your traffic, it captures the patterns that actually matter for your business: your markets, your customer mix, your providers' real-world behavior. Looking ahead, we'll train across merchants too, so the models learn approval behaviors from the whole Payrails network and every merchant benefits from patterns far beyond their own data.
What’s under the hood
We use gradient-boosted decision trees (LightGBM) that answer a single question for each payment and provider: "Will this payment be approved?" — expressed as a 0–100% probability.
Why gradient boosting instead of deep learning?
- It wins on tabular data. Gradient-boosted trees beat deep learning on structured payment data, time and again.
- It's explainable. We can show exactly why a route was suggested, feature by feature.
- It's fast to train and tune. That lets us iterate quickly and retrain weekly.
For a recent merchant, training drew on roughly 12 million payments covering six providers, 100+ separate inputs and 5+ months of history - with around half a million to a million payments per provider needed for robust predictions.
One lesson was learnt: more data isn't everything. The model predicted one provider's behavior much better than another's despite having double the volume for the latter. The lesson? How well a provider fits the merchant's markets matters as much as raw size. Providers with too little data or poor model fit are flagged, and guardrails stop bad routes before they're ever suggested (for example, never sending network-token payments to a vault-only provider).
There is one prerequisite: representative data. The model can only learn from routes it has actually seen. If a merchant's routing is already static or deterministic, we first run a short experimentation phase that randomises a slice of traffic across providers to collect unbiased training data before generating any recommendations.
From raw payments to a recommendation you can act on
ML-based routing runs in five steps:
- Payment history. Millions of transactions feed the pipeline.
- Approval model. Trained on the merchant's data in the Payrails platform, predicting the approval probability for every connected provider.
- "What-if" simulation. We swap the provider on historical payments and re-predict the outcome.
- Uplift rules. Recommendations are ranked, and only positive-uplift changes survive.
- Review & apply. An AI skill turns approved recommendations into a Modular Workflow.
The most important principle: you stay in control. These are recommendations, not forced routing. Payrails' payments team signs off before anything goes live, routing aggressiveness is tunable, constraints can restrict which payments may route to which PSP, and rollout is controlled. Traffic share can ramp slowly and be rolled back fast if issues arise. Recommendations are furthermore grouped into buckets so merchants act at exactly the right granularity: card BIN, market/workspace, currency, card network, issuer country, payment method, card type, order category, 3DS data, address info, or retry attempt. A confidence floor drops uncertain routes automatically.
How we prove it: the A/B test
We don't ask anyone to take the model's word for it. Every rollout runs as a controlled experiment:
- Group A (control): the merchant's current production routing, unchanged.
- Group B (treatment): top recommendations turned into a shadow Modular Workflow by an AI skill, then run live.
The process: check data coverage and model quality per provider (models retrain weekly), ramp the treatment's traffic share gradually from 5% to 50%, run both groups side by side over a roughly one-week window, monitor continuously. Our anomaly-detection model auto-alerts the moment approval rates degrade.Based on the results, we compare, document, and iterate.
The impact of ML-based routing on payment authorization rates
You may be reading this thinking, “yes it all sounds nice in theory, but what does this look like at scale in an actual multi-PSP environment”? For all the nuances of payments, the work of an enterprise payments team essentially boils down to one core objective: how do we get the highest possible auth rate at the lowest possible cost.
Every payment setup is different, so like any payment experimentation, uplift for ML-based routing depends heavily on each merchant's starting point. Here are some numbers from one of our recent deployments:
- +0.5–1.5% approval uplift per market
- 10–30% of payments re-routed
- ≈3× headroom growth as training data matures: for the merchant, modelled uplift rose from ~1% to ~3% in the same market as data accumulated
Across all markets, the merchant saw +0.8% total approval uplift on ~1 million monthly payments, with 22% of payments re-routed. Individual markets ranged from +0.5% to +1.5%. It may not sound like a lot in percentage terms, but on 1 million monthly payments at an average value of $100 USD, an improvement of 1% equates to $1.000,000 per month - or $12 million in additional annual revenue that was previously lost.
What’s more: these gains came on top of the merchant’s existing authorization rate, which was already over 90%. In payments as in most other business domains, the last mile of optimization is often the hardest to come by. For merchants who are already running a highly efficient and optimized payments setup, a 1% improvement on top of that setup is like finding money in your pocket.
Three factors drive how much any merchant gains:
- How optimized the setup already is. The biggest uplifts come where routing is static or rules-based.
- How much training data exists. More representative data means finer buckets and higher coverage.
- How many alternative PSPs are available. More connected providers means more room to re-route.
Where it's heading: a self-serve product
While ML-based routing is already providing measurable uplift across our merchants, the integration with the platform is currently activated offline by the admin, while the product will become a single building block inside the Payrails Modular Workflow in the upcoming iteration. One node picks the best provider for the merchant's goal, attempts the authorization, and automatically cascades to the next-best provider on a decline. The merchant just connects providers, picks a goal, and toggles strategies — no routing logic to build or maintain.
The merchant picks one goal:
- Maximise auth: Rank purely by likelihood of approval
- Minimise cost:Secure approval at the lowest expected fees
- Balanced:rade off approval and cost, tuned by Payrails
And can toggle strategies on top:
- Honour minimum volume commitments to a provider
- Cap any provider's traffic share for resilience and negotiating leverage
- Opt into peer-data uplift to route well before your own data exists
All powered by models that learn across the whole merchant network.
The bottom line
A fraction of a percentage point in authorization rate is real revenue at scale. Rules got you this far, but the next percentage points are hiding in slices of traffic too fine for any human to find.
ML-based routing finds them systematically, proves them in controlled A/B tests, and keeps humans in the loop at every step.
Want to see what smarter payment routing could do for your approval rates? Get in touch to book a demo with the Payrails team.
I am the text that will be copied.
.webp)
