Sticky and reverse-sticky routing: keeping or moving returning customers

Most routing rules treat every payment as a stranger. Yet a returning customer has a history: one provider approved them last month, and another declined them last week. Sticky and reverse-sticky routing use that history to choose where the next payment goes first.

This article explains what each rule does, when it helps, what data it needs, what can go wrong and how to measure it. It does not cover decline codes, which are in our guide to soft and hard declines, or how to build a cascade, which is in cascading and decline recovery.

What are sticky and reverse-sticky routing?

Sticky routing keeps a returning customer on the provider that worked before. Akurateco describes it as remembering the last successful route for a returning customer or stored credential and trying that route first. If it fails, the payment can still move to another route under the merchant’s rules.

Reverse-sticky routing is the opposite: it moves a customer away from the provider that declined them last time. It is not a standard term. We found no definition from a card scheme or regulator, and few vendors document it publicly, so ask any provider or platform what its version does.

	Sticky routing	Reverse-sticky routing
Looks at	The last approved payment	The last declined payment
First attempt goes to	The provider that approved	A provider other than the one that declined
Helps most when	Saved-card customers buy again	One route keeps failing for a customer
Main risk	Volume concentrates on one provider	Repeated attempts on a card that should be left alone

Neither rule replaces cascading. Akurateco puts the order simply: sticky logic chooses the first route, and cascading handles failures. The history comes from earlier payments. Cascading reacts to the current one.

Implementations also vary in how firm they are. Akurateco describes a preference that can fall back. Rebilly’s sticky gateways are a binding: an instrument with a sticky gateway ID always uses that gateway, and Rebilly’s setup steps recommend turning the feature off, saying routing works best without it. A preference and a binding carry very different risks.

Why would the same provider work better for a returning customer?

The usual argument is about issuer history. A PayPal article published by the Merchant Risk Council says that when a merchant changes acquirer, issuers have no chargeback history for the new combination of category, MID and descriptor, and may show more security and do not honor declines for the first 90 to 120 days. That finding is about new merchant accounts, not individual customers, but it shows that issuer decisions can depend on the route as well as the card.

Be careful with the conclusion. Akurateco says sticky routing helps avoid declines and makes performance easier to predict, but its page offers no data, and we found no independent study measuring the effect on approval rates. Treat it as something to test on your own traffic.

There are practical reasons too. A customer sees the same statement name each time, which reduces confusion. And a card saved with a provider’s token may only work at that provider, as our article on card token portability explains.

When does each rule help?

Sticky routing tends to suit:

• Returning customers with saved cards, where you have a reliable history and a repeat purchase is likely.
• Segments where providers differ clearly, such as card countries where one provider acquires locally. Our guide to local and cross-border acquiring covers why.
• Provider migrations, where you want existing customers to stay put while new customers move first.

It adds little when a customer’s history is thin, when providers perform about the same in that segment, or when your cheaper provider approves just as well.

Reverse-sticky routing tends to suit:

• A soft decline that looks route-related, such as a generic code clustered on one provider.
• Technical failures on the customer’s last attempt, such as a timeout or a provider error.

It does not suit declines that describe the card or the account. A card reported lost fails everywhere. Insufficient funds describes the customer’s account, which every acquirer checks. Our soft and hard declines guide sorts the codes, and our article on false declines explains why a suspected fraud decline should not be sent around until something approves it.

What data do these rules need?

The rule is only as good as its identifiers. Before you switch one on, confirm that you can fill in each row.

Data	Why you need it	What to watch
Stable customer ID	Links visits to one customer	An email or session ID can change, so use your own customer record
Card or token reference	Links payments to one card	Stripe’s card fingerprint identifies a card number, but for Apple Pay and Google Pay it may reflect the tokenised number, so one card can look like two
Payment account link	Joins token and card history	Mastercard’s Payment Account Reference links tokenised and PAN-based payments; check that your providers return it
Provider and MID	Shows which route was used	A provider can hold several merchant accounts, so a MID is the real unit
Outcome, code and date	Separates a useful signal from noise	A two-year-old approval says little
Method and segment	Keeps comparisons like for like	Card history should not steer a local method

You also need a rule for conflicts. A customer may have been approved on provider A in March and declined on it in May. Decide which event wins, and how old an event can be before it is ignored. Usually the most recent event within your window should win.

Finally, set the rule order. Eligibility and limits come first. A sticky preference should never send a payment to a provider that cannot take its country, currency or amount, or that is unavailable. Sticky and reverse-sticky rules then choose among the providers that remain, and your normal rules and traffic split decide for customers with no usable history.

What are the risks?

Concentration. Every approval strengthens the rule. Over time, returning customers build up on the providers that were favoured early, and your actual shares drift away from the ones you set. A provider may then get close to its cap, while another falls short of a volume commitment or goes cold. Our articles on provider limits and volume caps and traffic splitting cover both sides.

Stale history. Akurateco notes that sticky routing may need fallback rules when provider performance changes. Providers change acquirers, issuers change risk settings and customers replace cards. PayPal’s MID warming article advises treating moderately aged cards on file as likely out of date and refreshing them. Give history an expiry date, and clear it when a provider, MID or descriptor changes.

Retry rules. A new provider does not create a new card. PayPal’s guidance says Mastercard’s limits of 10 retries in 24 hours and 35 in 30 days apply to the same account number, at the same card acceptor and for the same amount, and that Visa allows 20 retries in 30 days on soft declines and none on Category 1 hard declines. It does not say whether those counts span acquirers, so count attempts per card across all providers. Our guide to soft and hard declines covers the fees.

Card testing. A reverse-sticky rule moves a declined card to a fresh route, which is what someone testing stolen cards would want. Keep customer blocks and fraud screening ahead of the rule.

Outages. If most returning customers are stuck to one provider, its outage hits your best customers first. Stickiness must give way when a provider is down. Our payment outage playbook covers what to do on the day.

Misleading tests. Sticky customers stay on the incumbent, so a new provider receives mostly first-time customers and looks worse than it is.

How do you measure whether it works?

Compare customers with the rule against similar customers without it, at the same time.

1. Choose the group. Returning customers with a history inside your window, in one segment.
2. Hold some back. Keep a random group on your normal rules. Assign by customer, so one person stays in one group.
3. Fix the sample in advance. Primer’s guide says that from a 70% baseline, detecting a rise to 71% takes 33,000 payments per variant, while a rise to 80% takes about 330. Returning-customer segments are often small, so a small gap may take months to confirm.
4. Track first-attempt approval. This shows whether the first route improved.
5. Track payment approval. This shows whether more customers actually paid. Our guide on how to calculate approval rate defines both.
6. Track the side effects. Check provider shares, cost per approved payment, decline code mix and chargebacks. Primer warns that chargebacks can take weeks or months to appear.

Example figures, for illustration only.

A store tests sticky routing on 40,000 returning card payments in one month.

Measure	Sticky on	Comparison group
Payments	20,000	20,000
First-attempt approval	86.0%	84.5%
Payment approval after cascading	90.2%	89.9%
Largest provider’s share	71%	60%

The rule improved first attempts by 1.5 points, so fewer customers waited for a second attempt. Payment approval moved by only 0.3 points, because cascading was already recovering most of those payments, and a gap that small may be noise. The price was 11 points of concentration on one provider. Whether that trade is worthwhile depends on that provider’s cap, fees and reliability. Without the comparison group, the store would have seen only the first-attempt gain.

Review the rule again after any provider change. A result from last year says little about a route that has since moved to a new acquirer.

How does Omno handle sticky and reverse-sticky routing?

In Omno, sticky routing keeps a returning customer on the provider that approved them before, and reverse-sticky routing moves a customer away from the provider that declined them. Both are rules your team sets in the dashboard, not automated guesses. If a provider is unavailable or rejects the request, the payment moves to the next provider in the rule until one accepts, and customer profiles and the transaction trail show the history behind each decision. The smart routing and cascading page explains how these rules work with splits and limits.