A payment router has more than one boss

A payment router does not answer a single question such as, “Which provider is performing best?” It answers several questions at once. Can this provider process this particular payment? Is a fallback safe after what just happened? Do the credential, authentication state and applicable rules permit the next route? What has recent traffic taught the system—and is that lesson trustworthy?

Those are different bosses. Provider capability defines what is possible. Fallback semantics define what is safe. Transaction constraints define what is allowed. Feedback changes what appears preferable. The router’s job is not to let one boss win. It is to reconcile them in a deliberate order, for every attempt.

Routing starts by removing impossible routes

Imagine an online card payment arriving with an amount, currency, merchant configuration, stored credential, authentication context and operation type. The router may know three connected processors. That does not mean it has three valid routes.

One connector may support authorisation but not the later capture pattern. Another may accept the payment method but not the authentication data attached to this transaction. A third may be healthy yet unable to process a feature the payment requires. Public cross-processor retry documentation offers a concrete example: a retry is suppressed when the second processor does not support a feature used by the payment, and also after certain unsuccessful 3-D Secure outcomes.1

Credentials narrow the field too. EMVCo says an EMV payment token can be constrained to a specific merchant, device or payment scenario.2 A token is therefore not just a safer substitute for a card number. Its domain controls are routing inputs. “Provider available” and “credential usable on this route” are separate facts.

This suggests a two-stage decision.

First, construct the eligible set. Apply hard predicates: method and currency support, operation compatibility, credential usability, authentication support, merchant configuration, jurisdictional rules and current provider availability. Record why each rejected route was removed.

Only then rank the survivors. Approval likelihood, latency, cost and traffic policy belong here. A sophisticated score cannot rescue an ineligible route. If ranking and eligibility are blended into one opaque number, a high predicted approval rate can quietly compensate for a condition that should have been absolute.

A fallback is a new financial decision

The word failure hides several states.

A connector can reject a request before sending it downstream. A provider can return an explicit decline. A network call can time out before the router learns whether the authorisation occurred. An authentication step can fail before authorisation begins. These outcomes may look identical at checkout. They demand different next actions.

The timeout is the dangerous case. The absence of a response is not evidence that nothing happened. Payment APIs use idempotency precisely so callers can repeat an indeterminate request without performing the financial operation twice. Adyen’s public documentation, for example, describes replaying a timed-out payment request with the same key and receiving the first result without duplication.3

But the guarantee has a scope. The same documentation notes that its idempotency keys are scoped at company-account level and are not checked across simultaneous requests to different regional endpoints.3 By inference, a router spanning providers cannot outsource global duplicate protection to any one provider’s key. It needs its own durable identity for the customer’s payment, plus an attempt ledger that distinguishes “safe replay of attempt A” from “new authorisation attempt B.”

Explicit declines require another translation layer. Mastercard Merchant Advice Codes can say to obtain updated account information, retry later or not retry; Visa and ChaseNet expose authorisation response categories with different retry meanings. A public J.P. Morgan Payments reference surfaces those network-specific signals separately and normalises them for merchant action.4 Visa’s own response table is equally concrete: it distinguishes insufficient funds, additional authentication required, duplicates, invalid accounts and system malfunctions.5

Flatten those responses into failed, and the router discards the instruction it needs. A stolen-card or invalid-account response is not an invitation to cascade. “Try later” is not “try another acquirer immediately.” “Authentication required” calls for a customer or protocol step, not merely a new endpoint.45

Fallback policy therefore needs a stop condition, a retry budget and a state transition. It should know whether the next action is a same-route replay, a delayed retry, a fresh attempt through another eligible route, an authentication step, a status inquiry or a terminal failure. The fallback is part of the payment’s state machine—not an exception handler bolted onto routing.

Constraints outrank conversion

The strongest route on yesterday’s dashboard may be the wrong route for today’s transaction because routing sits inside rules it did not create.

Authentication is one example. EMV 3-D Secure exchanges transaction, payment-method and device data between merchant and issuer; higher-risk transactions may produce a cardholder challenge.6 That authentication outcome becomes part of the payment context. A fallback connector must be able to preserve and correctly use that context. Otherwise a route change is also a semantic change.

Regulation can make the dependency sharper. Under the EU’s strong customer authentication rules, a transaction-risk-analysis exemption depends on conditions including the payment service provider’s measured fraud rate, the transaction amount and a real-time risk assessment. The regulation also requires monitoring of fraud rates and cessation measures when the applicable rate is exceeded.7 Thus “low risk” is not a free-floating label owned by the router. The availability of an exemption depends on the responsible payment service provider’s record and the specific transaction.

This is why constraints should be expressed as named, testable policy rather than scattered connector conditionals. A route can be healthy, cheap and historically successful and still be disallowed. The decision record should say so plainly: excluded: authentication_context_unsupported is more useful than a score of zero.

Hard exclusions also make changes reviewable. When a provider adds a capability, a token domain changes or an authentication rule is revised, operators can update one predicate and see which transactions enter the eligible set. When everything is a weight, no one can tell whether a rule was enforced or merely encouraged.

Feedback is a boss, not an oracle

Static rules cannot detect every live degradation. The router needs feedback: transport errors, latency, normalised authorisation outcomes and later payment results. Published research on smart payment routing describes exactly this combination: static filtering removes unsuitable terminals, while a dynamic model uses recent success and payment attributes, with time decay and a real-time feedback loop, to estimate success probability.8

The architecture matters more than the choice of model. Feedback ranks routes after static pruning. It does not repeal the pruning.

Feedback also creates traps. The router observes outcomes only for routes it selected. If one provider receives most of the traffic, its estimate becomes well sampled while alternatives grow stale. A provider can look excellent because it receives easier transactions; another can look poor because it is reserved for difficult fallbacks. This is ordinary selection bias wearing a payments badge.

Retries can corrupt the headline metric too. Suppose 100 customer payments produce 100 first attempts and ten second attempts. Counting approvals per attempt answers a different question from counting customers who ultimately paid. A router needs both views, joined by payment identity and attempt sequence. Otherwise it can “improve” an attempt-level rate by avoiding hard traffic, or improve eventual conversion by generating an unacceptable number of extra authorisations.

The feedback loop therefore needs guarded exploration, segmented comparisons and delayed outcomes. It should compare like with like: payment method, issuer or card range where lawful and appropriate, currency, authentication path, transaction type, route position and policy version. Authorisation is not the final risk label: the EU rules calculate payment-service-provider fraud rates over a rolling 90-day period.7 A route should not be rewarded permanently for approvals whose risk cost has not yet appeared.

Give the bosses an order

A router becomes governable when its chain of command is explicit.

Safety comes first: preserve one financial intent, reconcile indeterminate attempts and prevent duplicate effects. Legality and scheme policy come next: do not route or retry where the transaction is not permitted. Capability follows: retain only routes that can carry the method, credential, authentication state and lifecycle operation. Optimisation chooses among what remains.

For each decision, the router should leave a compact receipt: payment identity, attempt number, policy version, eligible candidates, exclusion reasons, provider-health snapshot, score components, selected route and permitted next actions. This is not logging for its own sake. It is how an operator can answer the questions that matter during an incident: Did the first provider receive the request? Why was the backup excluded? Which rule authorised the retry? What evidence changed the ranking?

That receipt also keeps learning honest. A model can be replayed against the candidate set that actually existed, rather than an imaginary set reconstructed from today’s configuration. A policy change can be evaluated separately from a provider outage. A conversion gain can be checked against retries, latency, fraud and duplicate risk.

The most mature payment router is not the one that switches traffic fastest. It is the one that knows when switching is valid, when repetition is safe, when a constraint must overrule a score and when fresh evidence should change the next decision. More than one boss is not a design flaw. Pretending there is only one is.

Sources

1. “Cross-processor retries with Orchestration,” Stripe Documentation. https://docs.stripe.com/payments/orchestration/retries (opens in a new tab)
2. “EMV® Payment Tokenisation,” EMVCo. https://www.emvco.com/emv-technologies/payment-tokenisation/ (opens in a new tab)
3. “API idempotency,” Adyen Docs. https://docs.adyen.com/development-resources/api-idempotency (opens in a new tab)
4. “Authorization retry logic,” J.P. Morgan Payments Developer Portal. https://developer.payments.jpmorgan.com/docs/commerce/online-payments/capabilities/online-payments/payment-methods/cards/authorization (opens in a new tab)
5. “Request & Response Codes,” Visa Developer Center. https://developer.visa.com/request_response_codes (opens in a new tab)
6. “EMV® 3-D Secure,” EMVCo. https://www.emvco.com/emv-technologies/3-d-secure/ (opens in a new tab)
7. “Commission Delegated Regulation (EU) 2018/389,” EUR-Lex, European Union. https://eur-lex.europa.eu/legal-content/en/TXT/?uri=CELEX%3A32018R0389 (opens in a new tab)
8. “An AI-powered Smart Routing Solution for Payment Systems,” IEEE Big Data Conference; manuscript hosted by arXiv. https://arxiv.org/abs/2111.00783 (opens in a new tab)