Smart Routing 101: How Payment Routing Decisions Work

Peneu Editorial Team · 4 June 2026 · Updated 26 September 2026 · 7 min read

Cover illustration explaining payment routing across providers

With one payment provider, there's nothing to decide: every payment goes the same way. Add a second provider, for resilience or for a method the first handles poorly, and every payment now needs a decision. Payment routing is the logic that makes that decision, and 'smart routing' is routing that uses information about providers' current performance rather than a fixed rule alone.

This post explains how routing decisions are usually made, in any system, and how to tell whether they're helping.

The building blocks: rules

Most routing starts with plain business rules that anyone can read.

Common kinds of routing rule
Rule type	Example
By payment method	Cards to provider A, UPI to provider B
By amount	High-value payments to the provider with the better terms for them
By business unit or entity	Each brand's payments through the provider under its own contract
By customer or card type	International cards to the provider enabled for them
By split	A share of traffic to each provider, to keep both warm and compare them

Adding signals: health and performance

Smart routing adds live information to those rules: recent success rates by provider and method, error rates, response times, and known incidents. If one provider's UPI success rate drops sharply, new UPI payments can be sent to the other until it recovers.

The signals have to be read carefully. A drop in success rate can be the provider, a bank behind it, or simply a wave of customers with insufficient balance. Good routing looks at failure reasons, not just counts.

Failover and retries are different things

Failover moves new payments away from a provider that's struggling. Retrying sends a payment that already failed through another route. Retrying is only safe when the first attempt definitely didn't succeed; a payment that timed out may have gone through, and retrying it elsewhere risks charging the customer twice.

Retry only on failure reasons that mean the money didn't move.
Never retry a payment whose status is unknown until you've checked it.
Use idempotency so the same order can't be charged twice.

Where routing goes wrong

Routing that reacts too fast can make things worse.

Thresholds, minimum traffic levels, cooling periods and a log of every routing decision prevent most of these.

Flapping: switching back and forth between providers on noisy data, so both see erratic traffic.
Starving a provider: sending it no traffic, so there's no data to show it has recovered.
Ignoring cost: optimising success rate alone, and quietly paying more for it.
Opaque decisions: nobody can explain why a payment went where it did.

Measuring whether it helps

Routing should be judged on outcomes you care about, compared over the same periods: payment success rate by method, cost per successful payment, and how much revenue was protected during provider incidents. Look at the reasons for failures, not just the rate, and keep a record of every routing change so effects can be traced.

What this means if you're choosing a platform

Ask any orchestration platform, including Peneu, to show you how routing rules are set, which signals it uses, how retries are made safe, and whether you can see why each payment went where it did. How Peneu describes its routing is on the platform pages; what's available for your business is confirmed during onboarding.

Go deeper

Questions about your own payment setup?

Talk to Peneu