Meet us at conferences around the world
SiGMA Europe
Per-customer payment routing picks the acquiring route using what you know about the customer — trust level, history, behaviour — on top of card, country and amount. Here is how to design it so it lifts approvals without hiding risk.
By Daniel Karpilovsky, Head of Success, Payneteasy
Per customer payment routing means the routing engine looks at who is paying before it picks a route. Card BIN, issuer country and amount still matter. But they describe the transaction. Customer signals — verification status, history with each route, behaviour — describe the person. Two people with similar cards can deserve very different routes.
This guide is for payment and risk leads at PSPs (payment service providers), gateway operators and merchants in demanding verticals. It covers which customer signals to route on and where they sit in the rule order. It also shows how cascading should behave per customer level, which mistakes turn routing into risk, and how to measure the result. If you need the module-level view of customer tiers first, start with our overview of per-customer payment logic.
Classic rules-based routing answers one question: which acquirer (the bank or provider that processes card payments for the merchant) is most likely to approve this card, in this currency, for this amount. That logic works on data that arrives with the authorisation request. Some engines add a short memory of the card — sending it back to the acquirer that approved it last time. But none of this tells the engine who the customer is. A first-time buyer and a verified customer paying with a new card look the same.
Per-customer routing adds a second layer of input. Before the engine compares acquirers, it knows the customer's level: new, verified or restricted. It knows how their past payments did on each route and which limits apply. The difference is easiest to see side by side:
| Transaction-level routing | Customer-level routing | |
|---|---|---|
| Question it answers | Which route can approve this card? | Which route should see this customer? |
| Typical inputs | BIN, card type, issuer country, currency, amount | Trust level, KYC status, history per route, velocity, dispute record |
| How often inputs change | Every transaction | Over days and weeks, as the customer builds history |
| Where the data lives | In the authorisation request | In a customer registry or the merchant's CRM |
| Typical risk if misused | Sending traffic to a route that cannot accept it | Sending a risky customer to a route chosen for trusted ones |
Transaction attributes tell you which acquirer can approve this card. Customer history tells you which acquirer should see this customer.
The two layers do not compete. Good intelligent payment routing uses transaction attributes to find the routes that can technically approve, and customer signals to choose among them.
Most teams already hold these signals somewhere — in KYC tools, CRM fields or spreadsheets. The work is getting them to the payment layer in a form a routing rule can read.
One filter before any signal goes into a rule: could you explain it to your acquirer's risk team? If routing on a signal would be hard to justify in a review, it does not belong in the routing logic.
A customer signal is powerful, which is exactly why it should not run first. A workable order looks like this:
Here is how it plays out. A new customer makes a first deposit. Eligibility leaves three routes. The New level narrows them to one: the route with the strictest screening, full 3-D Secure checks and low daily limits. After KYC and a run of clean payments, the customer moves to Verified. The same card now goes to the route that performs best for repeat customers, with higher limits. A dispute or a burst of failed attempts moves the customer to Restricted — through your demotion rules or your CRM. The routing follows the level — no one edits a routing rule.
Route on who is paying only after you have routed on what is allowed.
Cascading — sending a declined payment to the next route — recovers sales when the first acquirer fails for reasons that another acquirer would not share. It also costs money and can create risk. Whether a decline is eligible for a retry depends on scheme rules, acquirer rules, the fraud score and your retry policy, and customer level is a sensible input to that policy:
| Decline type | Cascade? | Per-customer nuance |
|---|---|---|
| Technical: acquirer unavailable or connection error | Usually yes, to the next eligible route | Same for all levels — the problem was the route, not the customer |
| Timeout with no response | Only after confirming the first attempt did not authorise | Otherwise the customer can be charged twice |
| Issuer unavailable | Rarely useful — every acquirer reaches the same issuer | Counts toward scheme retry limits |
| Generic soft decline | Sometimes, within scheme and acquirer rules | Reasonable for Verified and VIP; keep tight or off for New |
| Soft decline asking for authentication (Visa 1A, Mastercard 65) | Retry with 3-D Secure, not on another route | Authentication data is tied to the acquirer it was created for |
| Insufficient funds | Rarely useful — another acquirer meets the same balance | Better handled by a later retry policy than by a cascade |
| Hard decline: lost or stolen card, closed account, invalid card | No | Also a signal to review the customer's level |
| Declined by fraud screening | Not to a looser route | A cascade here moves risk; it does not recover a sale |
Card schemes also police retries directly. Visa groups decline responses into categories and treats some as “do not reattempt”; Mastercard returns Merchant Advice Codes, including “do not try again”. Both schemes can charge for excessive reattempts on the same card. A cascade policy that ignores these responses will pay for declines it was never going to recover.
Per-customer limits close the loop. A cap on how many attempts and how much volume one customer ID may generate per day stops a single customer — or someone testing stolen cards under one account — from walking the whole route list.
A cascade that sends a new customer's declined payment to your most permissive acquirer is not recovery. It is risk transfer.
A blended approval rate hides exactly what per-customer routing changes. Read these per customer level and per route:
| Metric | Why it matters |
|---|---|
| First-attempt approval rate | Shows whether the chosen route was right before any cascade |
| Approval rate after cascade | Shows what the cascade policy recovers, and for whom |
| Cost per approved transaction | Processing fees plus the cost of declined attempts and retries |
| Dispute and fraud ratio | Shows whether trusted levels stay trustworthy on looser routes |
| Share of customers per level | Reveals frozen levels and promotion rules that are too strict |
| Payout success and speed | Withdrawals are part of the customer experience, not an afterthought |
To compare fairly, keep a control share of each level on your previous routing for a fixed period and compare like with like: same level, same issuer countries, same payment type. A percentage split in the routing configuration is the simplest way to hold that control share. Comparing VIP customers on the new route with new customers on the old one only proves that VIP customers pay better. Look at the approval rate and the dispute ratio together — an uplift that arrives with more disputes is not an uplift.
On Payneteasy, customer levels live in the Customer Management System (CMS), a payment-aware customer registry inside the gateway. The building blocks map onto the stack above:
The routing sits on a payment orchestration platform (one integration that connects and manages many payment providers) with more than 1,000 integrations and 130+ fraud filters. Payneteasy is the technology and control layer: you keep your acquirers, your merchant accounts and your risk decisions.
If you want to see how your current customer segments would map onto levels and routes, talk to our team — we will walk through your traffic and the rule order with you.
Per-customer payment routing chooses the acquiring route using what is known about the customer — trust level, payment history on each route, risk behaviour — in addition to transaction attributes such as card BIN, issuer country and amount. Two customers with similar cards can be routed differently because their histories differ.
Smart routing by BIN or country looks only at the transaction. Per-customer routing adds a customer layer: it first narrows the eligible routes to those set up for the customer's level, then applies transaction rules and balancing among them.
Only for declines that are eligible for a retry under scheme rules, acquirer rules, the fraud score and your retry policy — an unavailable acquirer or a connection error is the clearest case. Declines from fraud screening should not be cascaded to a looser route, and many teams keep cascading tight for new customers.
On Payneteasy, yes. Auto-leveling in the Customer Management System moves customers between levels on thresholds you configure, for deposits and withdrawals, in Payment Gateway mode. In CRM/API mode your CRM sends the level with each transaction and CMS applies it.
It can. Merchant-initiated payments rely on the network transaction ID of the original customer-initiated transaction and on stored credentials, and not every acquirer accepts a reference created on another route. Check before a level change moves a customer's recurring payments, or route recurring payments separately and keep them on the route where they started.
Thank you for reaching us. Your request has been sent successfully. We will get back to you as soon as possible.
Message was not sent
