Smart Routing

Smart Router decides, in real time, which of your Payment Service Providers should process each transaction — and which one should rescue it if the first attempt fails. Instead of a fixed PSP or a static split you maintain by hand, a machine learning model makes that choice transaction by transaction and keeps learning from the results.

You stay in control of the boundaries: Smart Router only ever chooses from the PSPs you allow on a given routing rule, and it never touches your blocking, 3DS or fraud rules — those run first, exactly as you configured them.

Business Benefits

Approval odds differ substantially from one PSP to another depending on the card scheme, the issuing bank, the country, the currency and the kind of purchase — and those differences move as issuers change their models and PSPs change their connections. A static rule encodes whatever was true on the day you wrote it. Smart Router routes each transaction to the PSP with the best measured chance of approving that specific type of payment, and revises that judgement continuously.

Key advantages:

Removes standing maintenance burden: no quarterly exercise of pulling approval rates per PSP, arguing about traffic splits and republishing rules
Handles degradation automatically — when a PSP starts declining or timing out, its share of traffic falls away within hours and returns on its own once it is authorizing normally again
Measured rather than asserted gains: every Smart Router rule holds back a small control group, so the dashboard shows the uplift produced on your own traffic rather than an industry average

How ML Routing Works

The model starts by recognising what kind of transaction it is looking at. Transactions that behave alike are grouped into transaction profiles, built from attributes such as:

Card scheme
Issuing country
Currency
Card type
Tokenization method

For each profile, the ML model calculates the probability that each of your eligible PSPs will authorize a transaction of that kind, based on the observed outcomes of historical transactions. It routes to the PSP with the highest probability of success, and the result — authorized or declined — feeds straight back into the estimates, so the next transaction benefits from what the last one revealed.

Two key properties:

Learning happens per profile, and profiles are independent: visa / GB / GBP and mastercard / FR / EUR have their own estimates and their own ranking, so there is no single global "best PSP"
The model deliberately keeps sending a small share of traffic to PSPs it currently ranks lower — without that, a PSP recovering from a bad week would never earn traffic back, because nothing would test it again

Alongside the first-attempt decision, the ML model also learns an instant fallback retry strategy: which PSP should rescue a failed attempt. That is learned separately, because the PSP most likely to approve a fresh transaction is not necessarily the one most likely to recover a declined one. The model also decides whether a Network Token should be applied, so the optimization covers the combination of acquirer and credential rather than the acquirer alone.

Volume and Learning

Smart Router learns from your transactions, which makes volume the main thing determining how quickly it pays off. Each transaction profile needs enough transactions before its estimates can separate one PSP from another with confidence; until then the model is still gathering evidence rather than acting on it.

Volume considerations:

The more of your traffic you route through Smart Router, the faster it converges and the more it can optimize
Enabling it on a narrow rule with a small share of volume is safe, but every profile inside that rule accumulates evidence slowly, so convergence takes proportionally longer and the benefit arrives later
Broad, high-volume rules converge fastest; long-tail profiles are the slowest, and a profile defined so finely that it sees a handful of transactions a day may never converge at all

The same volume governs what you can read in the dashboard. Below roughly 30 control-group transactions in the window there is no verdict to draw yet, and a few hundred is where the comparison becomes reliable. If you have just switched one narrow rule over, an inconclusive report is expected rather than a problem.

Setting It Up

Smart Routing is configured in the dashboard the same way you set up a PSP. Go to Dashboard › Smart Routing, open the Routing tab, and on the rule you want to optimize choose Smart Routing in place of a named PSP.

Configuration options:

It can serve as the main authorization target or as a fallback behind the PSPs you want tried first, on any rule
It is scoped by the same filter conditions as any other rule — currency, country, amount band, card attributes
There is no integration work and no API change

When you select Smart Routing you choose which PSPs it may use: either all enabled providers, or a defined subset. At least two are required, since with a single PSP there is nothing to decide. A rule takes one Smart Routing entry, and it must be the last step in the authorization chain — the dashboard will not let you add a fixed PSP after it, because from that point on Smart Routing is managing the retries itself. Put it first to hand the whole rule to the model, or place it after one or two fixed PSPs if you want those attempted first. Your retry controls still apply: you can cap the number of attempts and list the error codes that should never be retried, per rule as usual.

Measuring the Impact

Every Smart Router rule splits its traffic in two:

The larger group is routed by the ML model
The smaller one — a few percent of the rule's traffic — is a control group routed at random across the same eligible PSPs

That is what makes the comparison trustworthy: both groups see the same mix of transactions, so the difference in conversion rate between them is attributable to the routing decision rather than to a change in your traffic.

Open Monitoring › Smart router performance to review it over the last 7, 14 or 30 days. The headline is uplift versus baseline — the conversion rate of the Smart Router group minus the control group, with a significance test, shown overall and per transaction profile. Below it you can see:

The model's current ranking of your PSPs
The share of traffic each one actually received
A flow view from transaction profile through PSP to outcome
A first-attempt filter that isolates PSP selection from the retry strategy, which is useful when you want to know which of the two is driving a change

The page is in beta — ask your ProcessOut contact if you do not see it.

Reading the Results

A few things commonly look like problems and are not:

The ranking score is not a conversion rate: it is the model's internal probability estimate, used to order PSPs, so a score of 0.81 next to an observed 55% conversion rate is normal
A profile where one PSP has taken essentially all the traffic is usually a success rather than a stuck rule — the model found a clear winner and converged on it, which is the intended end state
When two PSPs are statistically tied their shares will drift back and forth over a few hours; that is the model continuing to test them, not instability

Most importantly: Judge Smart Router per profile rather than on the rule total. A rule-level number averages dozens of independent profiles, and can look flat while individual profiles move a great deal in both directions.

Staying in Control

Smart Router never routes to a PSP you did not select on the rule, never bypasses your blocking, 3DS or fraud rules, and changes nothing about your integration — same API, same payment flow. To put a rule back on a fixed PSP, change it and publish; the switch takes effect immediately.

FAQ

Does it add latency?
The decision is made in-line during routing and is negligible against the PSP authorization call itself.

What happens if a PSP goes down?
Declines and timeouts push its estimates down quickly, so traffic drains away from it and returns once it recovers. Your configured retry rules still cover the attempts already in flight.

Can I use it with network tokens and 3DS?
Yes. Your 3DS and authentication rules run as configured, and the model optimizes the authorization decision underneath them — including whether to present a network token.

Is the control group lost revenue?
It is a small, randomly routed slice of the rule, and it is what lets you prove the uplift. Without it you cannot distinguish optimization from a good month.

Next Steps

Start with one high-volume rule rather than everything at once: it converges quickly and tells you what to expect before you widen the scope
Check Monitoring › Smart router performance once it has a few days of traffic
Talk to your ProcessOut contact to pick a first rule and agree a target metric
To be notified when a PSP's performance degrades, see the Alerting section of the dashboard, which handles performance alerts independently of routing