Payment routing as a constrained contextual bandit: a design for acquirer and method selection

1Context and motivation

Payment systems are two-sided markets: a card network or wallet has to attract both payers and the merchants who accept it, and its pricing to each side reflects that¹. One consequence for a merchant is that buyers arrive holding different instruments. Card holders tend to concentrate their spending on one network even when they carry cards from several, and merchant acceptance and consumer use of a network move together region by region². A merchant that sells across countries therefore connects to more than one acquirer and offers more than one payment method, and each transaction can reach the issuer by more than one path.

Each path has its own probability of approval, fee, latency and exposure to fraud and disputes. The usual way to choose among them is a routing table: a fixed map from card country or currency to a preferred acquirer, with a fallback when the first fails. A table does not learn from approvals and declines, and it does not notice when a route's behaviour changes.

We describe a design that treats route choice as a sequential decision under uncertainty. We have not deployed it and report no outcomes.

2Problem formulation

A transaction arrives with a context x: amount, currency, merchant category, channel, card BIN range or wallet type, issuing country, and the risk score from the fraud model. The set of routes R(x) contains every combination of acquirer, network or local rail, and authentication option that is technically able to carry this transaction. Choosing route r yields an outcome: approved or declined, a fee, a latency, and, weeks later, possibly a chargeback.

Only the outcome of the chosen route is observed. We never learn what a declined transaction would have done on another acquirer. This partial feedback is the defining feature of the contextual bandit setting, in which a learner repeatedly observes a context, chooses one of several actions, and sees the reward of that action alone^{3, 4}. Treating routing as plain supervised learning on historical logs ignores the fact that the logs only contain the routes the old policy chose.

We define the reward of route r in context x as

U(r | x) = P(approve | x, r) × (m(x) − f(x, r)) − c_fraud(x, r) − c_friction(x, r)

where m(x) is the merchant's contribution margin on the order, f(x, r) is the fee charged on an approved transaction, c_fraud is the expected fraud and chargeback cost of the attempt, and c_friction is a penalty for adding an authentication step. The weights inside c_friction are a design choice set per merchant; we do not claim a value for them. Using margin rather than order value matters: a declined order loses its margin, not its price, and Table 2 shows that this changes which route is preferred.

3Architecture

The design has five components, run in order for each transaction.

3.1Eligibility and policy layer

Before any model is consulted, a rule engine removes routes that are not allowed. Rules come from three sources. Scheme and regulatory rules: in the European Union, when strong customer authentication is required for an electronic payment and which exemptions may be used are set by regulatory technical standards under PSD2⁵, so whether an authentication step may be skipped is a legal constraint, not a model output. Data security rules: in our design, each component sees only the card fields it needs. Merchant rules: a merchant may require domestic acquiring for some markets, exclude a provider, or cap the fee it will accept. The learned policy only ever chooses among routes that pass this layer.

3.2Outcome models

Three models estimate the terms of U for each eligible route.

• Approval model. A classifier estimates P(approve | x, r). Its output is multiplied by money, so it has to be a probability in the frequentist sense and not only a good ranking score. Boosted trees in particular push predicted probabilities away from 0 and 1, and post-hoc calibration with Platt scaling or isotonic regression corrects this⁶. The design calibrates every approval model on held-out data and monitors calibration per route.
• Cost model. Fees are mostly contractual and are computed from the acquirer's fee schedule, network fees and currency conversion, not learned. Where a fee depends on information known only after settlement, the model uses the expected value from recent settlements.
• Fraud and dispute model. Fraud detection in card payments has to deal with concept drift, extreme class imbalance and verification latency: only a small share of transactions is checked promptly, and most fraud labels arrive late⁷. The design therefore treats c_fraud as an estimate that is revised as chargebacks arrive, and it does not use recent transactions as negatives until their dispute window has largely passed.

3.3Authentication choice

Where regulation allows a choice, adding an authentication step is part of the route. The step moves fraud liability and lowers expected fraud cost, and it adds friction that some buyers abandon. The protocol in wide use, 3-D Secure, has been criticised on security and usability grounds, and its adoption has been explained by the incentives of banks and merchants rather than by the quality of its design⁸. The design makes no assumption about the size of either effect: both c_fraud and c_friction for the authenticated route are estimated from logged outcomes and treated as uncertain in the same way as approval.

3.4Route selection

The selector is a contextual bandit over the eligible routes. For each route it holds an estimate of U and a measure of uncertainty, and it chooses the route whose upper confidence bound on U is highest, in the manner of the linear upper-confidence-bound methods developed for content recommendation³. For policy classes too rich for closed-form confidence bounds, the oracle-based approach reduces contextual bandit learning to a sequence of cost-sensitive classification problems with few calls to the classifier⁴. Three constraints are added to the plain bandit.

• Budgets. Exploration costs money: a transaction sent to an uncertain route may be declined. The design bounds the share of traffic and the expected margin spent on exploration per merchant per day. Bandit problems with resource limits of this kind are studied as bandits with knapsacks⁹; we use that formulation to reason about the budget, though the exact algorithm is a design choice still to be tested.
• Non-stationarity. An acquirer's approval rate can change abruptly, for example after an outage or an issuer's rule change. Bandit policies that discount old rewards or use a sliding window track reward distributions that change at unknown times¹⁰. The design uses a sliding window per route and context cell, and a separate health monitor that removes a route from R(x) when its error rate crosses a threshold, so that an outage is handled by the eligibility layer rather than learned slowly by the bandit.
• Minimum exposure. Without a floor, the bandit can stop sending traffic to a route, after which it can no longer learn whether that route has improved. The design gives each eligible route a minimum share of exposures over a horizon and measures the cost of that floor as regret against the optimal policy that respects it¹¹.

3.5Logging

Every decision logs the context, the eligible set, the chosen route, the probability with which the selector chose it, and the eventual outcome, including later chargebacks. Without the selection probability, the offline evaluation below is not possible.

Table 1 summarises the components, the problem each addresses and the evidence behind it.

Component	Problem it addresses	Evidence
Several acquirers and methods per merchant	Buyers hold and use different instruments by region	1, 2
Contextual bandit selector	Only the chosen route's outcome is observed	3, 4
Exploration budget	Exploring uncertain routes costs declined orders	9
Sliding-window estimates per route	Route behaviour changes at unknown times	10
Minimum exposure per route	Starved routes can no longer be learned about	11
Calibrated approval model	Ranking scores are not probabilities and distort expected value	6
Delayed-label fraud cost	Fraud labels arrive late and classes are imbalanced	7
Authentication as part of the route	Step-up checks trade fraud cost against friction	8, 5
Eligibility rules before learning	Regulation and data security constrain the choice	5
Replay and doubly robust evaluation	New policies must be judged on data the old policy logged	12, 13

Source: our design, with the works cited in the table.

4A worked model of route choice

Table 2 applies the reward U to one hypothetical card transaction with three eligible routes. Every input is hypothetical and chosen to show the arithmetic; none is a measurement of a real acquirer. The friction penalty is set to zero to keep the arithmetic visible.

Route	P(approve) (input)	Fee if approved (input)	Expected fraud cost (input)	U at margin 30 (computed)	U at margin 5 (computed)
A: domestic acquirer	0.90	2.0	0.30	24.90	2.40
B: cross-border acquirer	0.85	1.6	0.30	23.84	2.59
C: domestic acquirer with authentication step	0.82	2.0	0.10	22.86	2.36

Source: Worked model; inputs in the table. U = P(approve) × (margin − fee) − expected fraud cost.

At a margin of 30, route A is preferred: the 0.4 fee saving on route B does not make up for five points of approval. Route B would match route A only if its approval probability reached 25.20 / 28.4, about 0.887. At a margin of 5 the order flips and route B is preferred, because the fee is now a large part of what an approval is worth. The same routes, with the same approval rates, call for different choices on a high-margin and a low-margin order. A routing table keyed only on card country cannot express this; a policy that reads the margin can. Route C is never preferred here because its lower fraud cost is outweighed by its lower approval probability, but that depends entirely on the inputs: on a high-risk transaction with a larger expected fraud cost the comparison would change.

The model also shows how sensitive the choice is to calibration. At margin 30, route A stays preferred unless its true approval probability is below (23.84 + 0.30) / 28, about 0.862, that is, unless the estimate of 0.90 is about four points too high. At margin 5, route B stays preferred unless route A's true probability is above (2.59 + 0.30) / 3, about 0.963, or route B's is below (2.40 + 0.30) / 3.4, about 0.794. In both cases the decision boundary lies four to six points from the estimates, the same size as the approval differences between the routes. A calibration error of a few points is enough to send traffic to the wrong route, which is why the design calibrates and monitors each approval model per route.

5Evaluation protocol

Before any claim about outcomes, a routing policy would pass three stages.

• Offline replay. When the logging policy chose routes at random with known probabilities, a candidate policy can be evaluated without bias by replaying the logs and keeping only the events where the candidate agrees with the logged choice¹². Where logging was not uniform, doubly robust estimators combine a reward model with the logged propensities and have lower bias than a reward model alone and lower variance than inverse-propensity weighting alone¹³. Either way, the logged propensity is required.
• Controlled online test. A candidate policy serves a randomised share of traffic against the current policy, with a pre-registered target metric (net margin per attempted transaction), guardrails on decline rate, authentication abandonment, latency and dispute rate, and a stop rule when a guardrail is breached¹⁴.
• Delayed outcomes. Chargebacks arrive weeks after the transaction. The test's dispute guardrail is reported again once most of the dispute window has passed, and a policy that looked better on approvals alone is not promoted until then.

The metrics follow from the reward. Net margin per attempt is the sum of approved margin less fees and fraud losses, divided by attempts. Approval rate is reported per route and per issuing country, because a policy can raise the average by moving traffic between segments while lowering approval in one of them.

6Governance and privacy

Each decision can be explained from its log: which routes were eligible, which rule removed the others, the estimated terms of U and the selection probability. A merchant sees its traffic share and fees per route and can set its own constraints. Each route and merchant has a kill switch that returns it to a fixed table. Card numbers are never model inputs; the BIN range is.

Routing can disadvantage buyers: a policy that learns that cards from one issuing country are declined more often may add authentication steps for them more often. The design reports approval and authentication rates by issuing country, and a gap above a merchant-set threshold goes to an operator.

7Limitations

• No measurements. We have not run this design on real traffic. Whether it raises net margin over a well-maintained routing table is unknown and is exactly what the protocol above would test.
• Worked model inputs. Table 2 is hypothetical; real approval gaps and fee structures differ.
• Thin data. Many context cells see few transactions, so estimates there are uncertain.
• Delayed and biased labels. Fraud labels arrive late and only for transactions that were approved; a route that declines more transactions also hides more of the fraud it would have let through.
• Friction is hard to estimate. The cost of an authentication step depends on the buyer, the device and the issuer's implementation; c_friction is a parameter, not a known quantity.
• Interaction with issuers. Issuers adapt their own models to the traffic they receive. A routing policy that shifts volume may change the approval rates it is learning from.
• Regulation changes. Eligibility rules, especially authentication exemptions, change over time and differ by country; keeping the rule engine current is an operational task this design does not remove.

8Conclusion

We have described a design that chooses a payment route per transaction as a constrained contextual bandit: eligibility rules first, calibrated estimates of approval, fee and fraud cost second, and a bandit with an exploration budget, sliding-window estimates and exposure floors last. The worked model shows why the reward has to use margin and why a few points of calibration error can change the choice. What is missing is evidence of the design's effect. The next step is to log routing decisions with their selection probabilities, so that candidate policies can be evaluated offline before any of them serves traffic.