Smart payment routing
Send every transaction down the path most likely to be approved — chosen per payment from method, currency, region and how each provider is performing right now.
Smart payment routing is the practice of deciding, per transaction, which acquirer or payment provider should process it, rather than sending all traffic to one fixed provider. The routing decision is made from attributes of the payment — card scheme, issuing country, currency, amount, payment method — combined with live data on how each available provider is currently performing.
Why a single route costs you approvals
A payment that fails is not always a payment that should have failed. Issuers decline for reasons that have nothing to do with the shopper: an acquirer with a weak relationship in the issuing country, a cross-border transaction that could have been processed locally, a provider having a bad hour. With one acquirer, all of that is invisible and unfixable — the transaction either goes through or it does not.
Routing turns those into recoverable events. If a route degrades, traffic moves. If a payment would do better on a local acquirer than a cross-border one, it goes local. The shopper sees none of it.
How routing decisions are made
Classify the transaction
Scheme, issuing country, currency, amount, payment method and whether the payment is one-off or recurring.
Score the available routes
Each configured provider is scored against that profile using recent, observed authorisation behaviour for similar transactions — not a static preference order.
Apply your rules
Hard constraints you set — cost ceilings, provider preferences per market, contractual volume commitments — override the score. Your commercial terms win over the model.
Send, and watch
The transaction goes to the winning route. The outcome feeds straight back into scoring, so a provider that starts degrading loses traffic without anyone filing a ticket.
Retry deliberately
Soft declines can be retried on an alternative route, within scheme rules on retry counts and timing. Hard declines are not retried — retrying them is how you earn fines.
What you control
- Routing rules per merchant, per method and per market.
- Cost ceilings and provider preferences, which take priority over the scoring model.
- Failover behaviour: which route catches traffic when a primary degrades.
- Soft-decline retry policy, bounded by scheme rules.
- Full decision logs — which route a payment took, and which signals chose it.
Routing is not a black box
Every decision is logged with the inputs that produced it. When finance asks why a payment went to a particular acquirer, or a scheme asks you to evidence retry behaviour, the trail is already there. Automated routing that you cannot explain afterwards is a liability, not a feature.
Common questions
What is smart payment routing?
Smart payment routing decides, for each individual transaction, which acquirer or payment provider should process it — using the payment's own attributes plus live performance data — instead of sending every transaction to one fixed provider.
How is payment routing different from failover?
Failover is reactive: it moves traffic only after a provider has failed. Routing is a decision made before the transaction is sent, on every transaction, based on which route is most likely to succeed. Failover is one behaviour within routing, not a substitute for it.
Does routing require multiple acquirer contracts?
To route between acquirers, yes — you need more than one route available. Redlap Pay works with acquiring we provide, acquirer relationships you already hold, or a mix of both. With a single provider you still get retry logic and decline handling, but not cross-provider routing.
Can I override the routing model?
Yes. Rules you set — cost ceilings, per-market provider preferences, volume commitments — take priority over the scoring model. The model chooses within the boundaries you define, never outside them.
Will retrying declined payments get me penalised?
Only if you retry the wrong declines. Card schemes limit how often and how quickly a declined authorisation can be retried, and distinguish soft declines (retryable) from hard declines (not). Retries here are bounded by those rules, and hard declines are never retried.
Related
Ready to take control of your payments?
Talk to our team. We’ll walk you through the dashboard and answer the awkward questions.