Payment Routing Rules: Conditions, Cascade Order and Failover

Most routing advice stops one step before the work. Every guide agrees that intelligent routing beats a fixed cascade. Then nobody writes the rules. A rule set is a short ordered list of conditions and actions. The small decisions inside it decide whether the set earns approvals or pays scheme fees. Those decisions are: which attributes you may read, what order they evaluate in, and how deep the chain goes. Two more follow: how long to wait, and when to pull a gateway out. This post writes that configuration layer out, with the numbers that bound each choice.

What Is a Payment Routing Rule, in Practice?

A payment routing rule is condition-to-action logic. When these transaction attributes match, the rule sends the payment to this connection, in this order. In billing-platform terms, a rule holds one trigger, one or more conditions and one or more actions. You assemble those rules into a route map. The engine matches rules top to bottom, first match wins, and a default path takes the rest.

Three pieces of vocabulary carry the rest of this post. A BIN, or bank identification number, is the first six to eight digits of the card number. Those digits identify the issuing bank and the card product. A MID is the merchant identifier your acquirer scores you on. An MCC is the four-digit merchant category code attached to that MID. If you need the ground floor first, start with what is payment routing. Then read the case for adding data in intelligent payment routing.

Sending every payment to one gateway is also a documented routing type. Vendor documentation recommends it when you consolidate volume under one negotiated rate. So the real comparison is not platform against no platform. It is a rule set that reads performance data against a rule set that does not. One trap before you start: a payment that names a processor in the API request skips the rule set entirely. That named connection processes it. That is the usual reason a rule looks broken when the engine never evaluated it.

Which Conditions Belong in a Routing Rule (BIN, Currency, Card Brand, MCC, Amount, Subscription Cycle)?

Put in a rule only the attributes your platform can read at decision time. That list is card BIN range, card brand, card type, issuing bank, issuing country, currency, amount band and merchant category code (MCC). Add the subscription flags that separate a first charge from a renewal. Everything else is a guess dressed as a condition.

BIN conditions come in two tiers, and the second tier costs money. A plain BIN range condition takes a lower and an upper bound and needs nothing but the card number. Routing on BIN metadata (brand, category, type, issuing country, issuing bank) requires an enriched BIN lookup before the decision step. On Spreedly that means Advanced Vault at the organization level. Write any BIN rule against 8 digits. Visa and Mastercard extended the BIN from 6 to 8 digits globally on 1 April 2022. The stated operational impact landed on merchants running their own BIN-based routing, fee and fraud logic.

Merchants most often misunderstand the MCC condition. Visa requires the acquirer or its agent to assign the four-digit code describing your primary business. Visa also reserves the right to force corrections to how anyone assigns and uses that code. A merchant with several lines of business has two options. It processes all Visa sales under the MCC of its highest-volume line, or it holds a different MCC per line. So an MCC condition discriminates only if you genuinely hold more than one. A rule that moves a product line to a MID registered under a different MCC creates a miscoding exposure rather than an optimization.

Page-one guides skip the subscription cycle condition, and subscription businesses need it most. Gr4vy exposes is_subsequent_payment and merchant_initiated as booleans. A rule uses those two flags to separate a first customer-initiated charge from a renewal. Yuno goes one level deeper with SUBSCRIPTION_RETRY and SUBSCRIPTION_RETRY_COUNT. The count holds the attempt position in the ladder: 0 on the first attempt of a cycle, then 1 to n. With that field you send attempt 1 to your cheapest route and attempt 4 to the acquirer that historically clears tired cards.

Currency and issuer country belong in the rule because they change the issuer's read, not only the fee. Local acquiring makes the payment look domestic to the issuer, and a domestic attempt clears more often. Cross-border attempts often draw extra checks, stricter authentication and more declines, on top of the foreign exchange (FX) cost. For US debit the condition has legal teeth. Regulation II bars an issuer or network from restricting a debit transaction to fewer than two unaffiliated networks. It also bars anyone from inhibiting your ability to direct routing over any network that can process it. The Federal Reserve extended that rule to card-not-present debit effective 1 July 2023.

Two more conditions are worth the configuration time. An amount band is a fraud control as much as a cost control. Visa's current merchant guidance tells merchants to set velocity thresholds by amount and by count per timeframe. That guidance notes that enumeration attempts often run under $10 USD. A fraud-decision or risk-score condition sends the top risk tier through 3-D Secure (3DS) instead of straight to an acquirer. Watch the arity limits while you decompose. Gr4vy allows one amount, currency, BIN range, card country, card scheme and card type condition per rule. In Yuno, currency is not a standalone condition at all, so it has to ride along with AMOUNT.

In What Order Should Routing Rules Be Evaluated?

Order them most specific first, because the engine stops at the first match. A BIN rule belongs above a currency rule. A currency rule belongs above a cost rule. A catch-all default belongs at the bottom. Inside one rule the conditions combine with AND, so an either/or rule is really two rules in priority order.

Walk one payment down that stack and the ordering cost becomes concrete. A $42 US debit renewal misses rule 1, because the card BIN sits outside 455612 to 455613. It matches rule 2 on card type and issuing country. So it routes to the cheapest debit network with a backup behind it, and the engine stops reading. The engine never reads rule 3 (amount over $500), rule 4 (renewal, attempt 3 or later) or the default on this payment. The renewal logic you wrote for attempt 3 is live configuration that does not fire. Nothing in the dashboard tells you so.

So write evaluation order down as a spec rather than discovering it. Three rules of thumb cover most of it. First, every rule set needs an explicit terminal default. When nothing matches, the engine falls through to a configured default rather than failing the payment, and an account-level default outranks a tenant default. Second, when two rules overlap, the higher one owns the traffic. Resolve the overlap by narrowing the top rule rather than by reordering twice. Third, declare order across rule types too. A routing rule, a fraud rule and a retry rule can all fire on one payment, and platforms declare precedence between them. Primer's Adaptive 3DS takes priority over fallbacks on overlapping triggers, and a fallback fires only if that second authorization attempt also fails.

Cost rules sit below the data-driven rules for a reason. A cost condition should carry an approval-rate floor, written the way Hyperswitch documents it. Reroute when blended cost at one acquirer exceeds 85 basis points for a card segment. Apply that reroute only while the alternative holds at least 98% of baseline approval performance. The upside is real when the floor holds. In a pilot of over 20 enterprise merchants, Adyen reported an average 26% cost saving on US debit with a 0.22% authorization-rate uplift. Top merchants reached 55% and 52% savings and up to 1.15% auth uplift.

1. Geography and regulation first, because these rules decide which acquirer may settle the payment at all.
2. BIN and issuer rules next, since issuer-level performance is the highest-confidence signal you hold.
3. Card type and brand rules, including the US debit network choice Regulation II gives you.
4. Subscription cycle rules, separating the initial charge from renewal attempt 1 and from attempt 3 or later.
5. Cost rules, each carrying an approval-rate floor so a cheaper route cannot quietly cost approvals.
6. Health and performance rules, which de-prioritize a degraded connection rather than removing it permanently.
7. Fraud-tiered rules, routing the top risk tier through 3DS or blocking it, then the default path for everything that fell through.

Which Declines Should Cascade, How Deep, and How Long Between Attempts?

Cascade the temporary declines and stop on the permanent ones. Let the response tell you the wait. Visa permits reattempts of Category 2, 3 and 4 declines up to 20 attempts in 30 days, and zero after a Category 1 decline. Mastercard advice codes 24 to 30 set the waits, from 1 hour to 10 days.

Cascade eligibility is an allow list, not a deny list. Gr4vy's retriable ISO 8583 codes begin with 05, 06, 19, 20, 21, 22, 23, 28, 30 and 31. The same list continues with 40, 48, 50, 58, 68, 69, 70, 71, 72, 73 and 74. It also covers 76, 79, 80, 81, 84, 86, 87, 88, 90, 91, 92, 96, 98 and 99. Any code off that list stops the chain, including suspected fraud and violation of law. One signal outranks the list: the presence of a Mastercard merchant advice code prevents the automatic retry outright, ahead of any ISO code check. Checkout.com's three recommendation codes give you the branch in plain form. Code 01 means updated information is required, 02 means try again later, and 03 means do not try again.

Encode the hard stops verbatim, because the fee starts at the first attempt rather than the twenty-first. Visa Category 1 codes are 04, 07, 12, 14, 15, 41, 43, 46, 57, R0, R1 and R3. After one of those, the merchant must not resubmit for the same payment credential, per the Visa Core Rules. Code 57 moved into the reattempt fee program effective 25 October 2026, so retries on it now carry System Integrity Fees from attempt one. Mastercard advice codes 03 and 21 are terminal in the same way. Code 21 reports that the recurring agreement itself is canceled. So stop the subscription rather than route the attempt to a backup MID.

Your platform caps depth long before the schemes do, and the vendors cluster tightly. Zuora allows up to two in-transaction retries per branch. Spreedly's Recover retries soft declines or gateway outages on up to two failover gateways, which is three attempts in total. So a cascade hop reads as attempt 2 of 3. Yuno's guidance is a maximum of two attempts beyond the initial decline. Stripe recommends a maximum of eight retries for retry-eligible charges. Stripe also warns that extra attempts can read as fraud to issuers, which raises declines on legitimate charges. Pick a number in that range and write it down. The failure mode is a chain with no declared stop count.

You read retry timing off the response rather than picking it. Mastercard advice code 24 means retry after 1 hour, 25 after 24 hours, 26 after 2 days and 27 after 4 days. Code 28 means 6 days, 29 means 8 days and 30 means 10 days. The network publishes these in the authorization response as a recommendation code field your rule can branch on. Where no advice code arrives, a published ladder gives you a defensible default. Yuno documents gaps of 5 hours, 12 hours, 24 hours, 36 hours, 48 hours and then 96 hours, measured from the previous attempt. That ladder puts the last retry about 9.2 days after the first failure. Stripe's default schedule is 8 tries within 2 weeks.

Then budget the depth against the scheme ceilings, because the cascade and the dunning schedule spend from the same account. Visa's non-compliance fee bites from the 21st reattempt in 30 days. It costs $0.10 per attempt domestic and $0.25 cross-border, after the cross-border rate rose from $0.15 on 25 April 2026. Mastercard counts per account number and charges after 10 declined attempts in 24 hours or 35 in a rolling 30 days. The US rate has been $0.50 per excess attempt since January 2025, and thresholds vary by market (7 and 35 in Brazil and Latin America). Mastercard reports on a delay, so the charge lands about two months after the activity. Depth therefore needs an attempt-count guardrail rather than a cost alarm.

Cascade order also has a dispute consequence most configuration guides omit. Visa dispute condition 11.2 (Declined Authorization) covers a transaction completed after an authorization request got a decline or pickup response. A chain that wins a genuine approval on a later attempt is protected. An 11.2 dispute is invalid where the merchant obtained authorization after a decline for the same purchase. That carve-out does not cover pickup responses 04, 07, 41 and 43. For the decline-side view of the same problem, see issuer decline.

Is CRM Cascading Across Your MIDs Already a Rule Set?

Yes. A fixed cascade across your MIDs, the kind a subscription customer relationship management (CRM) platform runs, is a rule set with one condition (the payment failed) and one action (try the next MID in the list). In a basic failover setup the order is the order you added the gateways. So every card gets the same order, with no per-issuer input and no cost or MID-health guardrail.

The blind leg is documented behavior, not a straw man. Zuora's cascade modes cover the case where every method in the priority list has failed once. On the next retry cycle, the engine invokes the same immediate in-transaction retries again. That is a deterministic loop: same order, same credentials, no new information. It spends from the same 20-attempts-in-30-days budget as everything else. The argument for adding data is not that your current setup has no rules. It is that your current rules cannot notice when they become wrong, which is the case intelligent payment routing is built on.

A data layer adds three measurable things. It scores each processor per segment across payment method, amount, currency, country, card network and authentication type. So the ordering differs per card profile instead of per account. It keeps a declared exploration share, which sends a slice of traffic to alternate eligible processors purely to keep the scores fresh. And it models the problem honestly. The literature treats routing as a non-stationary multi-armed bandit with delayed feedback. That is the formal reason a fixed order degrades. Success rates move, outcomes arrive late, and a rule with no exploration slice cannot learn that it is now wrong.

The fixed cascade keeps one real advantage. Consolidating volume under one negotiated rate is a documented reason to route statically. The shipped rule templates in billing platforms exist for exactly that kind of commitment. They include route to backup gateways, route by currency, route by splitting traffic for volume commitments, and route on multiple conditions. If your pricing is built on a volume tier, a performance-scored router that moves 30% of volume elsewhere can cost more than the approvals it wins. Price the tier before you re-rank the list.

When Should a Rule Exclude a Gateway or MID Entirely?

Exclude a gateway or MID when the traffic cannot legally or technically settle there. Exclude it too when its own numbers drift toward a scheme threshold. Three triggers are concrete: a compliance ceiling, a capability mismatch, and an outage your health signal caught. Visa's Acquirer Monitoring Program (VAMP), which tracks fraud and dispute volume, has set its excessive line at 150 basis points since 1 April 2026. The capability mismatches are captures and processor-run 3DS.

The guardrail has arithmetic behind it. The Visa Acquirer Monitoring Program (VAMP) ratio counts fraud reports (TC40) plus disputes (TC15) over settled card-not-present transactions. So a routing rule moves the denominator (where volume settles) and cannot retroactively clean the numerator. The merchant excessive threshold dropped to 150 basis points (1.50%) in Asia Pacific, Canada, Europe and the US on 1 April 2026. It was 220 basis points before that date, per Visa's acquirer monitoring fact sheet. Enrollment also needs a volume floor of at least 1,500 counted fraud and dispute events. That floor is why a small MID can run hot and stay unidentified, and why splitting volume changes which MID Visa flags. Treat three illustrative MIDs at 0.42%, 1.12% and 1.48% as three different rules: route freely, hold the share flat, ramp down.

Mastercard's side of the guardrail sets the exclusion's shape. Mastercard scores the Excessive Chargeback Program per merchant ID. It trips at a minimum of 100 chargebacks in a calendar month plus a chargeback-to-transaction ratio of 1.50% or more. The denominator lags: Mastercard divides chargebacks received this month by last month's sales count. Cutting volume to a hot MID this month therefore makes next month's ratio worse, so the rule should ramp down rather than slam shut. Exit requires three consecutive months below threshold, which gives a MID exclusion a natural minimum duration of three full calendar months.

Some exclusions are capability facts rather than performance calls, and these silently break a cascade. Captures settle on the gateway that authorized them, so capture traffic sits outside failover entirely. Processor-performed 3DS excludes a payment from fallback, because the processor owns that flow. Billing platforms exclude 3-D Secure 2 (3DS2) scenarios from gateway failover for the same reason. Stored-credential traffic is narrower still. Network tokens are reusable across participating acquirers, while a proprietary vault token is not. Where the payment service provider (PSP) provisions tokens under its own requestor ID, you cannot reroute saved-card payments at all. From 23 October 2026, merchants must send the stored Mastercard Transaction Link Identifier on subsequent merchant-initiated payments. So a renewal can only route to a gateway that can present the original charge's identifier.

Health-based exclusion should be numeric and time-bounded rather than a toggle someone remembers to flip. A reference failover configuration opens the circuit breaker after 5 consecutive failures, probes a half-open route every 30 seconds, and caps max attempts at 2. It tracks health per route and per segment: card brand, issuing country, currency, payment method and 3DS flow. A global breaker on a provider hides those differences and sheds healthy traffic. Elimination routing works the same way. It tracks acute incidents such as downtime and technical errors, and it runs as a final check after the other logic. It de-prioritizes a connector rather than permanently removing it. It takes a numeric threshold (an example value of 0.3) plus a bucket size and leak interval. Recurly's failover triggers on error velocity crossing a threshold rather than on a single decline, which separates an outage from an ordinary decline.

Two softer exclusions round out the set. Capping the monthly amount each MID processes keeps each account inside its limits. It also spreads dispute ratios rather than concentrating them, and a volume-or-count condition expresses that cap inside the rule itself. The hard boundary is compliance. Visa treats routing one entity's sales through another entity's merchant account as transaction laundering. Visa requires acquirers to monitor for mismatches in merchant name, MCC and URL, and to monitor the velocity and authorization-attempt spikes a blind cascade generates. A MID should receive traffic for the business your acquirer approved it for. That discipline is what makes a multi-acquirer strategy hold up under review.

How Do You Test a Routing Rule Without Risking Volume?

Test with a concurrent split, not a before-and-after read. Send 10% of matching traffic to the new rule for 7 to 14 days and keep the rest on the old path. Hold the arm assignment stable per payment so retries cannot leak between arms. Set an auth-rate drop threshold that pauses the test automatically.

Before any live traffic, prove the branches fire in sandbox. Adyen lets you force a specific result code and refusal reason by passing a value in paymentMethod.holderName or additionalData.RequestedTestAcquirerResponseCode. So you drive each cascade branch individually: blocked card, expired card, issuer unavailable, not enough balance, acquirer error and 3D not authenticated. Stripe publishes test cards per decline code, where 4000000000000002 returns a generic decline and 4000000000009995 returns insufficient funds. Orchestrators give you two separated environments and document testing card rules in sandbox before you migrate them to production. Stripe's own terms prohibit testing in live mode with real payment details, so probing live cards is not an option anyway.

The split mechanics are stricter than they look. Hyperswitch caps the variant arm at 1% to 49% of traffic, so the challenger cannot hold the majority. It assigns arms deterministically by hashing the payment ID modulo 100, which keeps every retry of one payment in the same arm. Percentages have to total exactly 100 in every platform that offers splits. Failover inside a split-routing outcome happens within one variant rather than across variants. One documented trap: Primer evaluates split percentages against a random number at runtime and does not track whether it met the configured distribution. Its own docs give the worked case of a 50/50 split with two requests landing both on one branch, an actual 100/0 distribution.

The ramp and the window are where most tests go wrong. Start at 90/10 to cap the downside. Hold three to five days of stable results before stepping to 70/30 and then 50/50. Treat 7 to 14 days of live traffic as the minimum: 7 at high volume, 14 at moderate volume. Change one variable and track one primary metric per test. Do not run during a promotional peak, because traffic composition changes and breaks the comparison. Do not run the arms sequentially, because seasonality and behavior shifts confound a before-and-after read. Primer's guidance is blunt on this point: run the test to completion and analyze the full dataset at 95% confidence rather than peeking.

Guardrails make a live test safe to leave running. Declare a minimum sample size per arm before results count. Declare an auto-pause expressed in percentage points of auth-rate drop against control. A breach flags the experiment immediately rather than waiting for the sample threshold. Let the verdict say nothing yet. Hyperswitch reports CollectingData before the sample reaches the threshold, and NotSignificant for a positive but noisy gap. It scores the result with a two-sample z-test on per-transaction economic value, which collapses to a two-proportion test when no cost dimension is in play. A split branch set to 0% is the documented way to park a losing arm without deleting the configuration.

Which Numbers Prove a Routing Rule Worked?

Four numbers matter, in increasing order of usefulness. The first two are deduplicated approval rate by segment and recovery rate on the declines the rule targets. The other two are cost per successful transaction and the dispute and refund rates that catch a rule buying approvals with fraud. Read all four in the same segments the rule's conditions use.

Start with the denominator, because a cascade looks like either a triumph or a disaster depending on which one you pick. A raw rate counts every attempt including retries. A deduplicated rate groups the retried attempts and scores the final outcome. One success out of a three-hop cascade reads as 33.3% on the raw rate. The same cascade reads as a completed payment on the deduplicated rate, per Stripe's acceptance analytics. Deduplicated rates also lag. When the engine has not yet attempted every scheduled retry, the most recent month shows a temporary drop. Do not judge a cascade rule on a fresh window.

Separate the two rates that people call approval rate. Authorization rate divides issuer-approved payments by unique attempts that actually reached the network. It excludes invalid API calls, 3DS failures and blocked payments, because those never reached the network. Payment success rate includes them. A rule that adds a 3DS step can lift authorization rate while lowering payment success rate, and only the segment breakdown shows it. Pivot on the same dimensions your conditions use. Those dimensions are card country, card type, card verification code (CVC) response, input method and interaction type (customer-initiated against merchant-initiated). The rest are network token usage, processor and retry status.

Then put a price on the lift. The primary cost metric is cost per successful transaction, counting interchange, scheme fees, authentication costs and fraud losses. Benchmark it by payment method, region and route rather than as a blended processing rate. The spread is wide enough to matter: in card-not-present segments, interchange alone ranges from about 0.5% to 2.5% depending on card product and region. A rule that lifts approvals by moving volume to a pricier route can be net negative, and the blended rate hides it.

Harbor Lane Coffee shows the arithmetic at a real size. It runs a subscription roastery at about 120,000 card payments a month, and wants to prove a per-BIN rule worth 1 approval point. At a 90/10 split the challenger arm collects about 12,000 payments a month. So the 33,000 payments per variant that a 1-point effect needs takes about 2.75 months. At 50/50 the same test finishes in about 17 days, with half the volume exposed. Those are the two honest options. The third option, reading a blended rate before and after, answers a different question. For the per-MID and per-BIN view that makes either option readable, use routing performance measurement.

Benchmarks help you judge whether a result is worth the configuration. Fallback routing to a secondary provider recovers an average of 8% of transactions that would otherwise have failed, on Yuno's platform data. BIN-level routing by issuer country produced consistent approval-rate lifts of 2 to 5 percentage points across 12 tested configurations. Routing by device type and by time zone produced no measurable effect. Baby Bunting secured a 2.8% uplift in authorization rates within four months of moving to a dual-acquirer setup with failover routing. Treat each of these as the vendor's measurement of its own population, not a forecast for your card mix. Stripe says the same thing about its own optimization numbers: they are estimates rather than promised outcomes, and the methodology can change without notice.

Last, prove the rule actually fired, and check that it left no debris. Gr4vy's transaction flow panel lists the decline, routing and 3D Secure actions for a payment. It links each action name to the specific rule that applied, which turns attribution into a lookup rather than an inference. Check for the two cascade side effects that bill later. The first is a successful-but-unused authorization stranded on an earlier MID. Mastercard introduces a Not Reversed or Cleared Preauthorization program in Europe effective 1 October 2026. The second is a settled transaction you cannot match to its authorization, which carries Visa's Zero Floor Limit fee of $0.20 per item.

1. Write the condition list first, and delete any condition your platform cannot read at decision time.
2. Encode the Visa Category 1 codes (04, 07, 12, 14, 15, 41, 43, 46, 57, R0, R1, R3) as a hard stop before you design any hop.
3. Read the merchant advice code for the wait interval instead of setting one fixed delay.
4. Declare a cascade depth in writing, typically two attempts beyond the initial decline, and a stop condition per decline type.
5. Order rules most specific to most general, and end the set with an explicit default path.
6. Add a MID-health condition that acts below 150 basis points of fraud plus disputes, and ramps volume down rather than cutting it.
7. Launch at a 90/10 split with a minimum sample size and an auto-pause on an auth-rate drop, and run 7 to 14 days.
8. Report the result as deduplicated approval rate plus cost per successful transaction, cut by BIN, issuer and billing cycle.

Frequently Asked Questions