Payment routing is the logic that decides which acquirer or PSP processes each transaction, based on criteria such as card type, amount, country, payment method or issuer. For PayFacs, PSPs, ISOs and ISVs, a white-label routing engine lets them set these rules once and apply them to every merchant they serve, without code.
Connecting several acquirers is only the first step; deciding which one handles each payment is where acceptance and cost are won or lost. This article, updated in October 2026, explains what payment routing is, why manual routing no longer works, which criteria rules can use, how rule-based and smart routing differ, how to test a routing strategy safely, what happens when a route fails, and how operators offer routing under their own brand.
What is payment routing and why does it matter for a payment operator?
Routing is the decision taken for every transaction: which provider receives it. Each acquirer has its own strengths, such as domestic acquiring in some countries, better approval on some card types, lower fees on some volumes, or support for specific methods. Routing puts each payment where it has the best chance at the best cost.
For an operator, routing decisions apply across its whole merchant portfolio, so small differences in approval or cost per transaction add up quickly. The acquirer selection guide explains why operators run several acquirers in the first place.
Why is manual routing between PSPs no longer sustainable?
Because hard-coded routing turns every change into a development project. When the logic lives in custom code, adding an acquirer, opening a country or reacting to an outage means waiting for engineers, and the business teams who understand payments cannot adjust it themselves.
Visibility suffers too: without one place to see routes and their results, nobody can tell whether a rule still makes sense. A routing engine moves the logic into configuration that payment teams own, with results visible per rule and provider.
Which criteria can a routing rule use?
On NORBr, a routing rule can combine conditions such as:
- Issuer country and card BIN.
- Payment method and card type.
- Transaction amount.
- Merchant category code (MCC).
- Sales channel, such as e-commerce, in-app or in store.
All conditions of a rule must match for it to apply, rules are evaluated from top to bottom, and the first match wins. A named default route, chosen explicitly, handles every transaction no rule catches.
What is the difference between rule-based routing and smart routing?
Rule-based routing applies the conditions a payment team sets: predictable, auditable and easy to explain to a merchant. Smart routing uses performance data, such as approval rates by provider, card and country, to choose or adjust routes automatically.
In practice, operators combine both: rules encode contracts, regulation and business choices, while performance data tells them which rules to change. The payment analytics article lists the indicators to watch.
How do you test a routing strategy without disrupting merchants?
By splitting live traffic. A rule can send a defined share of matching transactions to a new provider and the rest to the current one, in percentages the merchant or operator sets. Comparing approval rates and costs on real traffic shows whether the new route performs better before it takes all the volume.
Splits can be adjusted without stopping the test, and changes to rule order take effect immediately, so a test that underperforms can be rolled back in seconds.
What happens when the chosen route fails?
Fallback takes over. Depending on the return code, the payment is retried on the same provider, rerouted to another one, or declined when retrying would be pointless or against scheme rules. The payment fallback routing article explains how return codes drive those decisions, and the payment resilience page describes the settings.
Fallback across providers requires credentials usable with each of them, which is why routing and universal tokenization go together.
How do PSPs and PayFacs offer routing to their merchants under their own brand?
By giving each merchant a routing builder in a console that carries the operator's brand. On NORBr, merchants build and reorder their own rules without involving the operator's team, while the operator sets which providers each merchant can use and sees, when a provider contract is revoked, which rules and volumes are affected.
The payment rails page shows how routing extends across cards, wallets and account-based methods.
_%2520a%2520game%2520changer%2520for%2520digital%2520transactions_-Cover.webp){kind=spacer}
