Payment orchestration in practice: real routing rules from a 50-brand operator

Payment orchestration marketing pages talk about routing in abstract. "Smart routing." "Intelligent failover." "Optimized authorization." What the words mean in practice is a library of explicit rules written by someone on the engineering and finance teams, maintained over time, and tested against real conversion data. A 50-brand operator does not have one magical routing engine; they have 60–120 individual rules evaluated in sequence, each addressing a specific scenario. This is what those rules actually look like.

1. The structure of a routing decision

A routing engine evaluates each transaction in milliseconds. The inputs: brand, product category, customer BIN (first 6–8 digits of card), customer geography, transaction amount, currency, customer history flag, basket risk score, time of day. The output: one processor + one acquiring bank + any 3DS instruction.

The decision is a prioritized rule list. Rule 1 evaluates; if it matches, it routes. If not, rule 2 evaluates. This continues until a rule matches or the default route fires. The order matters enormously — a permissive rule placed too high in the list swallows transactions that should have been routed by a more specific rule below.

Testing discipline: any new rule is tested in shadow mode (evaluated but not executed) for 7–14 days before going live. Conversion impact, cost impact, and failure rate are measured against the incumbent rule.

2. Vertical routing rules

Different brands in the portfolio have different risk profiles based on product vertical. Clean retail brands route to the cheapest acquirer. Supplements route to a supplement-friendly acquirer. CBD routes to a CBD-capable acquirer. The vertical determines which acquirers are eligible before any other rule fires.

Example rules in plain English:

• If brand is in {list of 30 clean retail brands}, route to Acquirer A.
• If brand is in {list of 12 supplement brands}, route to Acquirer B.
• If brand is in {list of 5 CBD brands}, route to Acquirer C.
• If brand is in {list of 3 peptide brands}, route to Acquirer D.

This is the coarsest level of routing. Most 50-brand operators have 4–8 acquirers in their stack, each assigned to a vertical cluster. See our orchestration vs aggregation guide for why vertical-level routing is the foundation.

3. BIN-based routing

Every card number's first 6–8 digits (BIN) identify the issuing bank. Different issuing banks have different authorization rates with different acquirers. A Chase-issued card might auth at 94% through Acquirer A and 89% through Acquirer B. The right routing rule sends Chase cards to Acquirer A for that vertical.

BIN-level rules are data-driven, not intuitive. Build them from 90 days of production authorization data. For every (BIN range, brand, acquirer) tuple with more than 500 transactions, calculate the auth rate. Where the difference is statistically significant, write a rule.

Example: Chase BINs for brand A route to Acquirer A. Chase BINs for brand B (same vertical, different acquirer eligibility) also route to Acquirer A if Acquirer A is eligible.

A mature BIN-routing library has 40–80 rules covering the top BIN ranges. The long tail of BINs routes to the default acquirer. Refresh quarterly based on new data.

4. Cost routing

Two acquirers might both accept the same transaction. One is cheaper. Route to the cheaper one — all else equal.

Cost routing rules are written with a priority: auth rate first, cost second. If the cheaper acquirer's auth rate is within 0.5% of the more expensive one, route to the cheap one. If it is meaningfully worse, the savings do not justify the lost revenue.

Example rule: for standard retail transactions under $500, if Acquirer A costs 12 bps and Acquirer B costs 22 bps, and auth rates are within 0.5%, route to Acquirer A. If the transaction is over $500, revisit — higher-ticket transactions sometimes auth better at the more expensive acquirer because the cheaper one rate-limits large tickets.

Most 50-brand operators save 5–15 bps on effective rate through disciplined cost routing. On $3M/month, that is $20–60k/year. See our reduce effective rate playbook for the complementary cost levers.

5. 3DS routing rules

3D Secure adds friction (customer sees an authentication challenge) but shifts liability (issuer eats the fraud loss if the customer completes the challenge). Routing 3DS correctly is a trade-off between conversion and fraud protection.

Rules that work in practice:

• Apply 3DS on any transaction over $X (threshold varies by brand; typical $150–500).
• Apply 3DS on any first-time-customer transaction regardless of amount.
• Apply 3DS on any transaction where the basket risk score is above threshold.
• Skip 3DS on repeat customers with prior clean transactions and low basket risk.
• Skip 3DS on Apple Pay / Google Pay transactions (already authenticated).

Within the "apply 3DS" branch, the flavor matters. 3DS 2.0 frictionless allows issuer to authenticate silently in the background; 3DS 2.0 challenge interrupts the customer. Route frictionless where possible, challenge only when required.

6. Failover routing

When the primary acquirer returns a soft decline (not hard declines — those are issuer decisions and retrying does not help), the transaction retries through a secondary acquirer. Done well, failover recovers 1–3% of declined transactions. Done poorly, it double-charges customers.

Failover rules:

• On soft decline code {list of safe retry codes}, retry immediately at the secondary acquirer.
• On hard decline code {list of issuer-authoritative codes}, do not retry. Show the customer a different payment method option.
• Never retry more than twice — each retry increases the chance of double-charge or fraud flag.
• Never retry across brands (different descriptors) — this looks like card testing to issuers.
• Log every failover for reconciliation. A successful failover is recorded under the acquirer that completed, not the one that started.

The list of "safe retry codes" is the critical detail. Network-specific docs define retry-eligible declines vs issuer-final declines. Use those lists; do not guess.

7. Compliance routing

Some transactions must route to specific acquirers for regulatory reasons, regardless of cost or conversion:

• EU customer with EUR currency must route to an EU-licensed acquirer for SCA compliance.
• High-risk vertical above a specific monthly volume may have to route through a dual-acquirer structure to stay under each acquirer's per-merchant exposure caps.
• A specific customer on a sanctions watchlist must route to a processor with OFAC screening enabled.

Compliance routing rules fire early in the decision tree — often ahead of vertical and cost rules. Getting the compliance branch wrong has consequences much worse than a few basis points of suboptimal routing.

8. The per-brand override layer

Above the general rule library, each brand can have specific overrides. Brand A's marketing team wants to run a promotional period without 3DS friction regardless of basket size — override the 3DS rule for that brand for that date range. Brand C had a chargeback spike last month and the fraud team wants tighter basket risk scoring for 30 days — override the risk-scoring rule for that brand.

The override layer runs highest priority (overrides win against any general rule). Each override has an expiration date. Without expirations, overrides accumulate forever and the rule library drifts away from the documented default.

Audit overrides weekly. Any override older than its expected duration either needs to be extended with a new rationale or retired.

9. The rule evaluation cost

Every routing rule adds microseconds to the checkout decision. At 60–120 rules evaluated per transaction, the cumulative time matters. The target: the entire routing decision runs in under 15 milliseconds at the 99th percentile.

Optimizations that preserve rule clarity without sacrificing speed: compile the rule list into a decision tree at deploy time rather than iterating the list per request. Index common rule predicates (brand, BIN range) for O(1) lookup. Cache repeated computations within a single decision.

A badly-structured rule engine can hit 100+ ms, which is a noticeable checkout delay. A well-structured one disappears into the network round-trip budget. The engineering cost to optimize is 20–40 hours once, amortized over years of operation.

10. The ops cost of rule maintenance

Rules rot. Acquirers change their auth patterns. BIN ranges get reassigned. Card networks publish new decline code semantics. 3DS protocols update. A rule library written in year one will be materially wrong by year two if no one maintains it.

The maintenance calendar: weekly 2-hour review of any rule showing performance drift, monthly full-library audit of conversion and cost impact by rule, quarterly rewrite of the BIN-level rules based on fresh authorization data, annual review of vertical routing against current acquirer AUPs.

Staffing: one payment operations engineer at 20–40% time allocation is usually enough for a 50-brand library at steady state. Below that, the library drifts and stops delivering the 5–15 bps savings it was designed for.

Orchestration is only as good as the rules it runs. If you want to see a real rule library — sanitized for your industry and portfolio — send the intake or see how the multiflow rule engine exposes the rule interface to portfolio engineers.