Country of the customer and country of the issuer, which decide whether a local route exists.
Smart Payment Routing for Multi-Provider Setups
Rules you write. Results you can measure.
Smart payment routing picks the best provider for each transaction instead of the same one for all of them. This page is the practical version: which signals to use, how to configure the rules and what the change is worth.
What Is Smart Payment Routing?
It is a rule layer between your checkout and your providers. Four things have to be true before it counts as smart rather than as a switch statement.
- The decision is made per transaction, not per merchant or per currency.
- It uses live data from your own traffic, not a configuration written last year.
- Your team can change a rule without a code release.
- Every decision is recorded, so you can explain any single payment afterwards.
Signals Used to Route Payments
Everything the engine knows about a transaction before it sends it anywhere. These six inputs are the default signal set.
Currency and amount, which determine route eligibility and any conversion applied.
BIN and card scheme, the best available clue about the issuer and the card product.
Live approval performance per provider for that exact segment over a recent window.
Cost per transaction across the eligible routes, including scheme and conversion charges.
Current availability, measured from real traffic rather than from a published status page.
Smart Routing Strategies
Most platforms run two or three of these at once, layered in priority order.
Explicit conditions with an explicit destination, evaluated in order. This is the baseline every other strategy sits on top of, because it is the only one you can fully explain to a partner, an auditor or a colleague six months later.
Traffic split by percentage across two or more routes. Used to keep a secondary provider warm, to honour a volume commitment, and to introduce a new route on a small share before it takes anything meaningful.
Rank by observed approval for the segment, then break ties on price, then prefer a domestic acquirer where one is reachable. Local acquiring moves both numbers at once, which is why it is applied last and matters most. The components around it are on payment gateway infrastructure.
Want these strategies mapped onto your own provider mix?
Smart Routing and Automatic Cascading
One ordered list, two jobs
The engine does not produce a single route. It produces a ranked list. The first entry is the routing decision; everything below it is the cascade, used automatically when an eligible failure comes back. Configure them together and the retry inherits the same logic that chose the original route. The eligibility rules are set out on cascading payments.
Improving Approval Rates
1
Find the weak segment
Split approval by country, currency and card product until the underperforming slice is visible.
2
Write one rule
Send that slice to the route with the better record for it. One change at a time keeps the result attributable.
3
Hold some back
Leave a share on the old route as a control group, otherwise seasonality will take the credit or the blame.
4
Keep or revert
Compare over a full weekly cycle, then promote the winner and move to the next segment on the list.
Handling Provider Downtime and Degradation
Total outages are the easy case: the route stops answering and traffic moves. Degradation is harder. A provider that is slow, or approving at half its usual rate for one card range, will pass a naive health check while quietly costing you revenue all afternoon.
The platform therefore watches approval against each route's own baseline, alongside latency and error rates. A route that trips a threshold is demoted rather than removed, a small probe share keeps testing it, and it is promoted again automatically once it recovers.
Degradation — a provider that is technically available but performing below its own normal baseline. It is the failure mode that costs the most, because nothing alerts unless you are measuring the route against itself rather than against an uptime check.
Routing Configuration and Merchant Control
Rules live in the back office, not in a support queue. Your team creates conditions, orders them, sets weights and switches them on for a share of traffic. Every change is versioned with an author and a timestamp, and any change can be reverted in one action.
A PSP or platform can run a distinct configuration per merchant, inheriting a house default and overriding only what differs. Merchants see their own performance without seeing anyone else's. The decision model behind these controls is described on intelligent payment routing.
Performance Analytics and Testing
Route performance is only meaningful per segment. A portfolio-level approval rate can stay flat while your second-largest market quietly falls apart underneath it, so read approval, cost, latency and recovery per country, per method and per provider. All four sit in the payment analytics dashboard, alongside the holdback comparison that tells you whether a rule change was actually the cause.
API and Provider Integration
Four steps from a signed contract to live traffic on a new route.
Your platform integrates once. Providers sit behind connectors and never appear in your codebase.
Statuses and decline codes arrive in one taxonomy, so your rules do not need a dialect per partner.
Callbacks are authoritative for the final state. Nothing is settled on a browser redirect.
A new provider goes live on a small traffic share, then scales as its own numbers justify it.
Smart vs Static Payment Routing
The same five questions, answered by each approach.
Question
How is the route chosen?
What happens on a decline?
Provider goes down?
Changing a rule
Cost control
Static routing
Fixed per merchant or currency
Returned to the customer
Manual switchover
A release
Whatever the default route costs
Smart routing
Per transaction, from live data
Cascaded if eligible
Automatic demotion and recovery
A back-office edit
Cheapest viable route wins ties
How is the route chosen?
Static
Fixed per merchant or currency
Smart
Per transaction, from live data
What happens on a decline?
Static
Returned to the customer
Smart
Cascaded if eligible
Provider goes down?
Static
Manual switchover
Smart
Automatic demotion and recovery
Changing a rule
Static
A release
Smart
A back-office edit
Cost control
Static
Whatever the default route costs
Smart
Cheapest viable route wins ties
Still routing every transaction down the same fixed path?
Use Cases
Where the rules earn back the effort of writing them.
- High-volume merchants, where a basis point on cost and a point of approval are both material.
- Multi-PSP platforms that need every provider comparable on the same evidence.
- Cross-border sellers converting foreign transactions into local ones market by market.
- Subscription businesses treating a failed renewal as churn rather than as a payment error.
- Gaming operators handling peak deposit traffic, covered further on igaming payment provider.
Frequently Asked Questions
How many providers do we need for this to help?
Two is enough to start seeing a difference. Three gives the rules somewhere useful to go in most markets. Beyond four, the gain usually comes from better rules rather than from another contract.
Who writes and owns the routing rules?
Your team, from the back office. We help design the first set during deployment, but ownership sits with the people accountable for payment performance rather than with a vendor ticket queue.
How long before results are visible?
A full weekly cycle per change, because payment behaviour varies by day. Segments with low volume need longer before a difference is trustworthy rather than noise.
Does it affect the checkout our customers see?
No. Routing happens behind the checkout, so rules and providers can change without touching the interface or asking your customers to do anything differently.