Payment method mix and rail routing across regions: a design for preference-aware checkout

1Context and motivation

A merchant that sells into several countries has to decide, for every checkout, which payment methods to show, in what order, and over which processor or rail the payment travels. The right answer differs by country, by basket and by buyer. Payment diary surveys harmonised across seven countries find that the level of cash use differs from country to country and is strongly correlated with transaction size, demographics and point-of-sale characteristics such as merchant card acceptance¹. In the United States, the characteristics of payment instruments, notably their relative convenience and cost, are the main determinants of which instruments consumers adopt and how much they use them². Survey data on how adults make and receive digital payments are published by economy³, and they are the kind of external input a design like ours needs, because a single global method list cannot reflect that variation.

Payment methods are also two-sided products. A card scheme, wallet or instant transfer service is worth something to a buyer only if merchants accept it, and to a merchant only if buyers hold it; platforms in such markets have to get both sides on board, and how they allocate prices between the two sides shapes the outcome⁴. A commerce platform sits between these networks and its own buyers. What it shows at checkout influences which networks its buyers use, and each network's fee and protection rules change what each choice costs.

We describe a design for a payment intelligence engine (GPIE) that orders payment methods per region and segment, routes each transaction to a rail and processor, scores fraud with rail-specific features, and applies protection and fairness constraints. We argue each part from published work. We report no experiments: a simulator we wrote would only restate our assumptions.

2Payment methods as bundles of attributes

The design does not reason about payment brands. It records, for each method in each market, a set of attributes: the merchant's cost, the time to settlement, observed approval behaviour, whether and how the buyer can reverse the payment, and the fraud exposure the method carries. The values come from the merchant's processor contracts, scheme rules and its own transaction history, not from this paper. Four families of methods motivate the attributes.

Fast payments. Fast payment services make funds available to the payee immediately and can be used around the clock, which removes two limits of traditional retail transfers: funds that arrive a day or more after they leave the payer's account, and transfers that can only be started at certain places and times. The CPMI report on these services also sets out their benefits and risks for the parties involved⁵. Our design stores, per scheme, whether a settled payment can be reversed, and treats an irreversible rail as ineligible for orders that the risk layer scores above a threshold. That rule is our design choice.

Mobile money and wallets. In Kenya, adoption of a mobile money service in the panel studied rose from 43 to 70 percent; shocks reduced consumption by 7 percent for nonusers while the consumption of user households was unaffected, through larger and more diverse remittances⁶. The finding concerns risk sharing, not checkout, but the lesson for the design is that a method which lowers transaction costs can change behaviour quickly, so preference models must be refitted as data arrive.

Buy now, pay later. In US transaction-level data, access to buy now, pay later (BNPL) credit increases total spending and the retail share of spending⁷. In banking data on 10.6 million US consumers, new BNPL users show rapid increases in overdraft charges and credit card interest and fees compared with nonusers, consistent with BNPL facilitating overborrowing⁸. Taken together, these results mean BNPL cannot be treated as a neutral conversion lever. In our design, whether to show or promote it is a decision with a buyer-harm guardrail, not a default.

Cards. Credit card fraud is a standard test case in published work on statistical fraud detection^{9, 10}. The design applies that literature to every rail, adjusted for each rail's features and label delays.

3Design principles

• Attributes, not brands. Every policy reads method attributes, so a new scheme enters the system as a new row of attributes rather than new code.
• Conditional, not global. Method order is conditioned on region, segment and basket, because method use varies with transaction size and venue as well as with country¹.
• Effects from experiments. The effect of adding, removing or reordering a method is estimated from randomised exposure with declared guardrails, not from correlations in logs¹¹.
• Protection before optimisation. Hard rules (eligibility, regulation, irreversibility limits, credit-harm limits) run before any learned policy.
• Exposure floors. No method or segment is starved of exposure by the learner; floors are part of the objective¹².
• Explanations for merchants. Every recommendation to a merchant states the attribute values and estimates behind it.

4Architecture

4.1Inputs

The engine reads transaction telemetry (approvals, declines, retries, fraud flags, chargebacks, refunds and disputes), checkout behaviour (methods shown, selected, abandoned and retried, with device, channel, basket value and category), buyer attributes (region, past method use, risk segment), the method attribute table above, and external context such as scheme availability and processor outages. Every record carries consent and residency flags and is stored in its region.

4.2Preference segmentation

Buyers are grouped by observed method use into segments such as wallet-first, card-first, account-to-account and mixed. Membership is computed per basket rather than once per buyer, because the same person may choose differently for a small and a large purchase¹. Segments are refitted on a rolling window so that a newly launched scheme can move buyers between them, as the mobile money evidence suggests it can⁶.

4.3Method choice and conversion

This model predicts the probability that a session completes, given the set and order of methods shown. Its training data are confounded, because the current policy chose what was shown. The design therefore learns from randomised exposure: a contextual bandit selects among candidate method orders for each context and observes completion only for the order it showed. Oracle-based contextual bandit algorithms reach the statistically optimal regret bound while calling the underlying classifier few times¹³, which makes them practical at checkout scale. Each candidate order must receive at least a set fraction of exposures over the horizon, and the learner is judged by regret against the optimal policy that respects those floors¹².

4.4Routing and cost

For each transaction that has a choice of processor or rail, the router chooses the option with the higher expected net value: the approval probability times the order value less fees and expected fraud loss. Approval probabilities are learned per processor and context with the same bandit machinery. Table 2 works one instance of this rule by hand.

4.5Risk and protection

Fraudsters adapt and will usually find ways around prevention measures once they have time, so detection has to keep learning after deployment⁹. Real fraud detection systems face concept drift, as buyer habits and fraud strategies change; heavy class imbalance, as genuine transactions far outnumber frauds; and verification latency, as only a small set of transactions is checked by investigators in time¹⁰. The risk layer is built for those three conditions: it retrains on a schedule tied to drift, weights the rare class explicitly, and treats unverified transactions as unlabelled rather than genuine. Features are rail-specific; a push payment from a new payee and a card payment from a new device are different risk patterns.

4.6Regional adaptation

All models share one backbone and add a region and market embedding, so that markets with little data borrow strength from others while keeping their own baselines. Regulatory rules per market, such as authentication requirements, live in the rule engine, not in learned weights.

Table 1 maps each component to the problem it addresses and the published work it rests on.

Component	Problem it addresses	Evidence
Per-market method list	Payment use differs by country, transaction size and venue	1, 3
Attribute table per method	Instrument characteristics such as cost and convenience drive use	2
Platform view of schemes	Each method's value depends on adoption on both sides of the market	4
Rolling preference segments	Lower transaction costs can shift behaviour quickly	6
Irreversibility rule for fast rails	Immediate, around-the-clock settlement carries its own risks	5
BNPL credit-harm guardrail	BNPL raises spending and is linked to overdraft and fee increases	7, 8
Drift-aware, imbalance-aware fraud model	Adaptive fraud, class imbalance, delayed labels	9, 10
Contextual bandit over method orders	Logged checkout data are confounded by the policy that produced them	13
Exposure floors	Learned policies can starve methods or segments	12
Registered experiments with guardrails	Changes judged on noise or on one metric alone	11
Honest protection labels	Purchase intention depends on trust in the seller	14

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

5A worked routing model

Table 2 applies the routing rule to one order with two eligible rails. Every value in it is a hypothetical input chosen to show the arithmetic; none is a market figure or a measurement.

Quantity	Rail A (card)	Rail B (instant account transfer)
Order value V (input)	100.00	100.00
Fee (input)	2.90	0.50
Expected fraud and dispute loss (input)	0.50	1.00
Approval probability p (input)	0.90	0.85
Net if approved, V less fee less loss (computed)	96.60	98.50
Expected net, p times net if approved (computed)	86.94	83.73

Source: Worked model; inputs in the table.

With these inputs the router chooses rail A, even though its fee is almost six times higher, because the five-point gap in approval probability outweighs the fee difference. Rail B would match rail A at an approval probability of 86.94 divided by 98.50, about 0.883. A small error in p moves the decision more than a large error in fees, so approval probabilities have to be estimated per context and kept current. The model leaves out two things a deployment would need. It ignores buyers who abandon when their preferred method is missing, which the conversion model covers, and it values a loss on an irreversible rail the same as a loss on a reversible one, which the protection rule handles separately.

6Protection, inclusion and fairness

Buyer protection. Online purchase intention depends on trust in the seller as well as on the perceived usefulness and ease of use of the site¹⁴. Protection labels at checkout therefore state each method's actual recourse and never imply protection a rail does not give. A rail without reversal is not promoted for high-value orders or for buyers the risk layer flags.

Credit harm. Because new BNPL users show increases in overdraft charges and card fees⁸, the design does not rank BNPL by conversion alone. It suppresses BNPL promotion for baskets and segments where a merchant's policy or local rules call for it, and it tracks a credit-harm proxy as a guardrail in every BNPL experiment.

Inclusion. Account ownership and digital payment use differ across and within economies³. An optimiser trained on cost and approval alone would tend to drop methods used mainly by buyers who are less profitable to serve. The design reports method availability and approval rate per segment and market, and exposure floors keep low-volume methods in the candidate set¹².

Privacy. Payment telemetry is sensitive. The design keeps only fields a decision uses, hashes identifiers, and keeps records in their region.

Oversight. Changes that alter which methods a market can use, or which buyers see credit offers, go to human review with the estimates behind them.

7Evaluation protocol

Before any claim about outcomes could be made, each policy would pass these steps.

• Registration. Hypothesis, primary metric, guardrail metrics and minimum detectable effect are recorded before launch¹¹.
• Randomised exposure. Method orders and routing choices are randomised within the bandit's exploration budget, with exposure floors^{13, 12}.
• Per-market reporting. Effects are reported by market and segment, not only pooled, because a gain in one market can hide a loss in another.
• Delayed labels. Fraud and dispute guardrails are read only after the verification window closes¹⁰.

The metrics follow from the decisions. Approval rate is approved over attempted authorisations. Checkout completion is completed orders over sessions that reach payment. Dispute rate is disputes over approved orders, read after the dispute window. Cost per approved order is fees plus fraud losses over approved orders. The inclusion gap is the largest minus the smallest approval rate across monitored segments. We do not propose target values; they have to be set from measured baselines, which we do not have.

8Illustrative scenarios

The scenarios are hypothetical and show how the parts would interact. They are not results.

A market with a widely used instant scheme. If a merchant entered a market where an instant account transfer scheme carried a large share of online payments, the per-market list would include it, the bandit would test it in several positions, and the irreversibility rule would keep it off high-risk orders. Whether showing it first raised completion would be what the experiment measured.

A BNPL promotion test. A merchant wanting to promote BNPL in a category would run it as a registered experiment, with completion as the primary metric and the credit-harm proxy and dispute rate as guardrails.

9Limitations

• No measurements. We have not measured the effect of this design on approval, completion, disputes or inclusion. Every implied benefit is a hypothesis.
• Evidence from other settings. The cited payment-choice studies cover particular countries and periods; their findings motivate the design but do not predict effect sizes elsewhere.
• Coarse regions. Region embeddings can hide differences between countries and corridors; some markets will need their own models.
• Label delay. Fraud and dispute labels arrive weeks after the decision, so the routing learner sees incomplete rewards and can favour a rail before its losses appear.
• Adversarial adaptation. Fraudsters can learn the routing and protection rules and target the rail with the weakest checks.
• Sector rules. Travel, digital goods and regulated categories have rules this design does not model.

10Conclusion

We have described a payment design that treats methods as bundles of attributes, conditions method order on market, segment and basket, routes by expected net value, scores fraud under drift and delayed labels, and puts buyer protection, credit harm and exposure fairness ahead of optimisation. Each part rests on published work, summarised in Table 1. The design has no evidence of its own effect yet; the next step is the registered evaluation above, in one market, with results reported per segment.