In a multi-connector payment stack, the routing layer sits between the payment request and the connector API call. Before any transaction reaches Stripe, Adyen, or Worldpay, Hyperswitch runs three sequential checks:

1. Eligibility filtering (which connectors can handle this specific transaction)
2. Rule evaluation (which connector the merchant has configured for this transaction type)
3. Dynamic scoring (which connector is currently performing best on this card type, currency, and amount).

The connector that clears all three gates receives the payment attempt. If it declines, cascading retry logic automatically routes to the next eligible connector without the customer seeing the failure. The gap between a 85% and 90% authorization rate on a $50M annual processing volume is $2.5M in recovered revenue. Connector configuration is what determines which side of that gap you're on. The goal should be maximise the first attempt auth rate (FAAR) as it has multiple benefits such as : better user experience and higher auth rates than a failed retry transaction.

Where the routing layer sits in the payment stack

Payment orchestration layer: A software layer that sits above individual payment connectors (PSPs) and intercepts every payment request before it reaches a connector API. The orchestration layer handles connector selection, retry logic, and fallback routing functions that connectors themselves do not perform.

In Hyperswitch's architecture, the routing decision is made entirely before any connector is called. The sequence is:

Payment Request from Merchant
→ Eligibility Filter: Which connectors can handle this?
→ Rule-Based Routing Active? If yes: Rule Evaluation (top-to-bottom merchant rules). If no: Dynamic Scoring (MAB auth-rate algorithm).
→ Rule matched? If yes: Selected Connector (e.g. Stripe). If no: Dynamic Scoring.
→ Downtime Check: Is connector healthy? If healthy: Connector API Call (Stripe / Adyen / Worldpay). If degraded: Elimination Routing (next eligible connector).
→ Authorized: Success. Declined: Cascading Retry (next connector in order).

Stripe, Adyen, and Worldpay are all leaf nodes in this architecture, they receive payment attempts, they don't make routing decisions. The routing decisions happen upstream, in the orchestration layer, based on connector configuration the merchant controls.

This placement matters for authorization rate optimization. By the time a transaction reaches Stripe, the routing layer has already determined that Stripe is the right connector for this transaction. If Stripe declines, the routing layer has already determined the next connector to try. The connector sees one payment attempt. The merchant sees one outcome - authorized or not regardless of how many connector attempts happened internally.

How connector eligibility filtering works

Eligibility filter: The first gate in Hyperswitch's routing pipeline. Before any routing rule or dynamic algorithm is evaluated, each connected PSP is checked against a set of connector-level capability conditions. Only connectors that pass all conditions are eligible for this transaction.

The eligibility check evaluates six dimensions per connector:

Why eligibility configuration matters more than routing rules: A routing error occurs by routing to the wrong connector produces a decline. An eligibility configuration error occurs by routing to a connector that can't handle the payment method - produces an error, not a decline. Errors break the cascading retry chain. When the primary connector returns an error (not a decline), the retry logic treats it differently than a soft decline: depending on the error type, the retry may not fire, or may fire to a connector that also can't handle the transaction. Silent eligibility gaps like a new connector added without confirming which payment methods are enabled, are the most common source of authorization rate drops after connector onboarding.

Rule-based routing: deterministic connector selection with merchant-controlled logic

Rule-based routing: A deterministic routing mode where the merchant defines explicit conditions - using payment method, amount, currency, and other dimensions that map to connector preferences. Rules are evaluated top-to-bottom; the first matching rule determines the connector selection.

Rule-based routing handles the cases where routing behavior needs to be predictable and controllable. The primary use cases for US merchants:

• PSP volume commitments: Contractual minimums with Adyen or Worldpay require a specific transaction volume per month. Rules enforce that a certain GMV of card transactions always route to Adyen.
• Payment method-specific connectors: Worldpay has a specific acquiring relationship for certain card BINs. Routing those BINs to Stripe produces lower authorization rates for structural reasons, the acquiring path is suboptimal. A rule locks those BINs to Worldpay.
• Currency-specific routing: Adyen's EUR settlement rates are better than Stripe's for European card transactions. A rule routes EUR-denominated transactions from US customers to Adyen.

Each rule has three possible connector preference types:

Single connector

Route all matching transactions to one connector.

IF currency = EUR AND payment_method = card
THEN connector = Adyen

Split routing

Distribute matching transactions across connectors by percentage.

IF payment_method = card AND amount <= 100
THEN Stripe: 70%, Worldpay: 30%

Split routing is the primary mechanism for satisfying PSP volume commitments without hard-coding all traffic to one connector.

Fallback routing

Route to a primary connector with an ordered fallback chain.

IF payment_method = card AND currency = USD
THEN primary: Stripe → fallback_1: Adyen → fallback_2: Worldpay

The fallback chain fires automatically on decline or error, in order, without merchant intervention.

Rules are evaluated sequentially from top to bottom. The first rule whose conditions match the transaction determines connector selection, subsequent rules are not evaluated. A transaction that matches no configured rule falls through to dynamic auth-rate routing (if enabled) or the merchant's default connector.

Supported condition operators: equal to, not equal to, greater than, less than, contains, not contains. Conditions on payment method, amount, currency, and card network are supported as rule dimensions.

Volume-based routing: satisfying contractual splits

Volume-based routing:

A routing mode that distributes transaction volume across connectors by percentage in a probabilistic manner, applied across all transactions rather than conditionally.For merchants with negotiated volume commitments to multiple PSPs, a common structure for high-volume US merchants with dedicated Adyen and Worldpay contracts, volume-based routing handles the distribution to adhere to the desired traffic share. The percentage is applied stochastically across the transaction stream; individual transactions are not deterministically assigned, but over any sufficiently large volume window, the split converges on the configured percentages.

Volume-based routing when combined with rule-based routing operates in layers. The configured rules - BIN routing, currency routing, high-value transaction routing - take precedence and the resulting options are then split as the volume rule configured. .

Auth-rate-based routing: the MAB algorithm and how it optimizes connector selection

Auth-rate-based routing: A dynamic routing mode that uses a Non-stationary Multi-Armed Bandit (MAB) algorithm with delayed feedback to continuously estimate each connector's authorization rate per transaction segment and route to the connector most likely to authorize the current transaction.

The MAB framing is precise: each payment connector (Stripe, Adyen, Worldpay) is an "arm" of the bandit problem. The algorithm's task is to maximize the total reward (authorizations) across the transaction stream, given that the reward probability for each arm (each connector's authorization rate) is non-stationary and it changes over time as issuers update their fraud models, as connectors experience partial degradation, and as transaction mix shifts.

The explore-exploit split

The algorithm divides traffic into two pools:

Exploitation pool: Routes to the connector with the highest estimated authorization rate for the current transaction characteristics. This is the traffic that directly drives authorization rate improvement.

Exploration pool: Routes a configured percentage (exploration_percent) across all connectors including lower-performing ones, to continuously update performance estimates. Without exploration, the algorithm would stop updating data for connectors not currently winning, making it unable to detect when a previously lower-performing connector has improved.

A 5% exploration_percent means 5% of overall transactions are distributed at probabilistic intervals to all the underserved connectors; 95% of transactions are routed to the observed best-performing PSP. Reducing this number increases exploitation but slows the algorithm's ability to respond to changing conditions. Increasing it maintains more current data across all connectors at the cost of some short-term authorization rate loss.

The scoring pipeline

Two parameters control how the algorithm scores connectors:

Bucket_size : The number of historical measurement buckets included in the connector score calculation. A larger value makes the score more stable (less reactive to single-bucket fluctuations) but slower to respond to sustained connector performance changes. A smaller value makes the score more reactive but more volatile.

Hedging_percent: The percentage of traffic that will used for exploration which is used to track the performance of the gateway and use that to route the remaining transactions

Measured performance

In a 21-day test across a production merchant portfolio, Hyperswitch's dynamic MAB routing delivered a 83.19% authorization rate compared to 82.60% for rule-based routing alone, a 59 bps improvement. The dynamic approach also showed lower variance across the measurement period, meaning fewer authorization rate dips during off-peak periods or partial connector degradation events.

At $50M annual processing volume, 59 bps represents approximately $295,000 in additional authorized revenue annually even before accounting for the authorization rate protection during downtime events.

Downtime detection and elimination routing: how connectors are deprioritized without being blacklisted

Elimination routing: A routing mode that continuously monitors connector health scores and deprioritizes but does not permanently remove connectors experiencing degraded performance. Unlike a simple circuit breaker that hard-blocks a connector, elimination routing maintains a health score per connector and adjusts routing probability proportional to that score.

The health scoring mechanism is inspired by PID (Proportional-Integral-Derivative) controller design:

• Each authorized transaction rewards the connector's health score
• Each declined or errored transaction penalizes the connector's health score
• The score decays toward a neutral baseline when no transactions are routing through the connector (preventing starvation of connectors during extended low-traffic periods)

When a connector's health score drops below the merchant-configured threshold, it enters elimination and it stops receiving new payment attempts until its score recovers. Recovery is gradual: as the connector receives exploration traffic (from the MAB's exploration pool) and that traffic authorizes, the score climbs back. A fully recovered connector re-enters the main routing pool without manual intervention.

The network effect in downtime detection: Because Hyperswitch processes transactions across a large merchant portfolio, it observes connector performance signals from many merchants simultaneously. When Stripe begins returning a higher-than-normal decline rate, Hyperswitch's detection layer sees this signal aggregated across the entire network, not just from a single merchant's transaction stream. This means Hyperswitch's elimination routing responds to Stripe degradation faster than any individual merchant's own detection logic could, because the individual merchant may not have enough transaction volume in the affected window to detect the statistical anomaly.

Hyperswitch's routing layer decides which connector receives the payment attempt. The connector decides whether to authorize it. These are separate decisions routing to the connector most likely to authorize is not the same as guaranteeing authorization. Elimination routing can deprioritize a degraded connector and route to a healthy one; it cannot recover an authorization that the issuing bank has declined for fraud or credit reasons.

Least-cost routing for US debit cards

Least-cost routing (LCR): A routing mode that selects the connector and card network path that minimizes processing cost for debit card transactions, based on card brand, issuer regulatory status, and transaction type.

For US debit card transactions, least-cost routing implements the Durbin Amendment fee structure. The decision logic:

Debit Card Transaction
  → Dual-branded card?
      Yes → Regulated issuer (assets > $10B)?
               Yes → Route via international network (Visa/Mastercard - capped interchange)
               No  → Route via local debit network (INTERLINK / STAR / PULSE - lower interchange)
      No  → Standard network routing

For unregulated issuers (bank assets below $10B - the majority of community banks and credit unions in the US), routing through local debit networks (Interlink, STAR, PULSE) produces meaningfully lower interchange rates than routing through Visa or Mastercard's international debit rails. The Durbin Amendment caps interchange only for regulated issuers; unregulated issuers are exempt, meaning local network routing is the fee optimization lever.

For regulated issuers, the interchange cap applies regardless of network - international network routing is acceptable because the fee is already capped.

LCR for debit requires that connector configuration correctly maps each connector's supported local debit networks. If Stripe is configured but its Interlink routing is not enabled in the Hyperswitch connector configuration, transactions from unregulated issuers route through Visa's international rails at the higher uncapped rate and the LCR decision reports a "least cost" selection that is actually sub-optimal because the local network option wasn't visible to the routing layer.

How rule-based and auth-rate routing combine: the hybrid configuration

For most production deployments, rule-based routing and auth-rate routing operate in combination rather than as alternatives. The configuration pattern:

1. Rule-based routing handles structural requirements - PSP volume commitments, payment method-specific connectors, BIN-based routing, currency routing. These conditions require deterministic behavior and take precedence.
2. Auth-rate routing handles residual transaction volume - regardless of which rule or algorithm selected the connector, downtime detection checks the connector's current health score before the API call fires. A connector selected by rule-based routing that is currently in elimination gets overridden to the next eligible connector.

In this case, the rules configured acts as a hard filter to finalise the consideration set of PSPs and use auth-rate routing to pick the best performing PSP from this set.

Key Takeaways

• The routing layer makes its connector selection before any PSP API call. Stripe, Adyen, and Worldpay are leaf nodes, they receive decisions, they don't make them.
• Eligibility filtering is the first gate and the most consequential misconfiguration point. A connector that returns errors (not declines) on unsupported payment methods breaks the retry chain.
• Rule-based routing handles structural requirements: PSP volume commitments, BIN routing, currency routing, payment method locks. Rules evaluate top-to-bottom; first match wins.
• Auth-rate routing uses a Non-stationary MAB with delayed feedback. The exploration_percent parameter controls explore-exploit split; min_aggregates_size controls the minimum data threshold before scores are applied. Setting min_aggregates_size too low causes routing instability during connector ramp-up.
• Least-cost routing for US debit requires local debit network (Interlink, STAR, PULSE) configuration per connector to activate and missing this configuration routes unregulated issuer cards through international rails at higher interchange.