A decision architecture for payment routing, retries and risk controls

1Context and motivation

A common payment setup routes every transaction through a fixed priority list of gateways, with retry rules written by hand. That setup has three weaknesses. It does not react when an issuer's approval behaviour or a corridor's latency changes during the day. Its rules are usually tuned by comparing approval rates before and after a change, a comparison that traffic mix and seasonality can confound¹. And its rules change only when someone edits them, which is slower than fraud patterns or issuer policies move. Consent and data residency checks, when they are added afterwards as separate services, can also be skipped on some paths.

We propose to treat each payment as a short sequence of decisions under constraints: which gateway or payment method to try first, whether to add a step-up authentication check, whether and when to retry after a decline, and what to offer the buyer if the payment cannot complete. This paper describes the architecture we propose for making those decisions and the reasoning behind it. It reports no outcomes.

2Design principles

• Event first. Every authorization request, risk check and handoff is an event with a schema and consent and residency flags.
• Effects, not correlations. A change to routing or retry policy is judged by its estimated causal effect, with confounders named in advance^{1, 2}.
• Constraints at decision time. Risk, cost, latency, exposure fairness and privacy are enforced when the decision is made, not audited afterwards.
• Reasoning separate from execution. One layer senses and scores; another executes, with rollback.
• People review high-impact changes. Policy changes above a set impact level go to an operator, with an explanation of the model's output³.
• Regions are configured, not forked. Latency budgets, fee rules, fairness parameters and compliance rules are set per region on one code path.
• Every decision is traceable from event to decision to outcome.

3Architecture

The design has two parts: a payment signal layer that senses and maintains features, and an orchestration layer that decides and acts.

3.1Payment signal layer

Events arrive on a message bus and are checked against versioned schemas. Each event is tagged with consent and residency flags at ingest. Payment events are often delivered more than once (gateway webhooks retry) and sometimes late, so the layer deduplicates on idempotency keys and uses event-time watermarks to decide when an aggregate is complete⁴.

Normalisation enriches each event with device, issuer identification number range, channel, merchant, corridor, amount and currency. A feature store serves the same feature values online and offline, with a freshness target and lineage per feature. Quality monitors track null rates, ingestion volume, and distribution drift, measured as the Kullback-Leibler divergence from a reference window⁵.

3.2Orchestration layer

The orchestration layer has five components.

• Causal services estimate the effect of routing and retry strategies by cohort (issuer, corridor, device), using tree-based estimators with honest sample splitting so that per-cohort confidence intervals remain valid². Where a change has to be applied to a whole corridor at once and no holdout is possible, the counterfactual comes from a synthetic control built from untreated corridors⁶.
• Predictive models score authorization probability and fraud risk with gradient-boosted trees⁷. Authorization models use monotonic constraints on features where the direction of effect is known, so that scores move predictably. Session-sequence models use a Transformer architecture⁸ only where the latency budget allows. Gateway latency is forecast with time-series models⁹.
• The policy engine chooses actions with a contextual bandit: given the context of a transaction, it picks one of several routes and observes the outcome only for the route it chose. An oracle-based algorithm learns such a policy with a statistically optimal regret bound while calling a supervised learning oracle fewer times than there are rounds¹⁰. Our design adds the payment-specific constraints (fee ceilings, latency budgets, step-up rules) as filters on the action set before the bandit chooses, and adds minimum-exposure quotas so that no eligible route is starved of traffic and its estimates stay current¹¹. A planner handles multi-step flows: risk check, then route, then retry, then recovery offer.
• The safety layer runs consent, residency and eligibility checks on the request path, and enforces latency guards, cost caps and fraud thresholds. A request that fails a check is not routed.
• Action connectors call gateways, alternative payment methods, fraud services, the ledger and notification systems. Every call carries an idempotency key, so a retried call cannot charge twice.

To avoid oscillation when conditions change quickly, the policy engine limits how far it shifts traffic between routes per interval and returns to a cached, known-good policy when upstream services degrade. These limits are our design choice; we have not measured their effect.

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

Component	Problem it addresses	Evidence
Idempotency keys and event-time watermarks	Duplicate and late payment events distort counts and can double-charge	4
Causal graph per policy change	Before-and-after comparisons confounded by traffic mix and season	1
Per-cohort effect estimates	An average approval lift hides issuers or corridors that lose	2
Synthetic control for corridor-wide changes	No randomised holdout is possible	6
Contextual bandit routing	Fixed priority lists ignore transaction context	10
Minimum-exposure quotas	Learned routing starves some routes, so their estimates go stale	11
Always-valid sequential tests	Watching a running test inflates false positives	12
Pre-period covariate adjustment	Approval rates too noisy to detect small effects	13
Local explanations for reviewers	Operators cannot see why a route was chosen	3
Drift monitor on inputs	Issuer or fraud behaviour shifts away from training data	5

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

4Signals

The design uses five groups of signals.

• Transaction and device: amount, currency, merchant category, issuer identification number range, issuer country, device and browser, app or web, IP geolocation, network quality.
• Session and history: session recency, cart changes, earlier attempts in this session, the buyer's past payment outcomes.
• Risk: fraud scores, velocity checks, chargeback and dispute history by issuer and corridor, decline codes.
• Cost and performance: gateway and payment-method fees, currency conversion spreads, per-gateway latency, timeouts and success rates.
• Compliance: consent and residency flags, eligibility rules (age, product, geography), and sanctions and anti-money-laundering flags where they apply.

5Decisions

5.1Routing

For each transaction, the policy engine chooses a primary route and a fallback from the routes that pass the safety layer. The reward is the expected contribution of the order net of payment cost, so a cheaper route is chosen only when its authorization probability is high enough to pay for the difference. Table 2 works through that trade-off with hypothetical inputs.

Case	m (input)	f (input)	p (input)	Expected contribution (computed)
Route A, lower-margin order	30.00	3.00	0.90	24.30
Route B, lower-margin order	30.00	2.00	0.86	24.08
Route A, higher-margin order	60.00	3.00	0.90	51.30
Route B, higher-margin order	60.00	2.00	0.86	49.88

Source: Worked model; inputs in the table.

In this model the cheaper route B is worse for both orders, because its lower fee does not make up for its lower authorization probability. Route B would break even with route A at p = 0.90 x 27 / 28, about 0.868, for the lower-margin order, and at p = 0.90 x 57 / 58, about 0.884, for the higher-margin order. The higher the margin, the more a point of authorization probability is worth relative to a unit of fee. The model ignores retries, fees charged on declines, currency conversion and chargeback cost; a deployed reward would have to include them.

5.2Retries and step-up

A retry is conditioned on the decline code, the elapsed time and the route's current latency. Codes that signal a permanent refusal are not retried. The policy limits the number of attempts a buyer sees, so that recovery does not turn into repeated failures. Step-up authentication is added by corridor and risk level: it is added where predicted fraud risk is high and withheld where it would add friction without reducing risk.

5.3Recovery offers and messaging

When a payment cannot complete, the recovery flow can offer an alternative payment method or a split payment, chosen by predicted acceptance and risk. Offers are capped per buyer, respect opt-outs, and are not concentrated on particular cohorts. Error messages say what happened and what the buyer can do, in the buyer's language, and present alternatives without a pre-selected option. This matters beyond the single order: online purchase intention depends on trust in the seller, alongside the perceived usefulness and ease of use of the site¹⁴.

6Experimentation and evaluation

Before any outcome could be claimed for this design, each policy would need to pass the following protocol.

• Pre-registration. Hypothesis, target metric (authorization rate or contribution per attempt), guardrail metrics (latency, dispute rate, cost per transaction) and minimum detectable effect are recorded in an experiment registry¹⁵.
• Sequential testing with always-valid p-values, so that monitoring a running test does not inflate false positives¹².
• Variance reduction using each merchant's or cohort's pre-experiment approval rate as a covariate¹³.
• Per-cohort effects by issuer, corridor and device².
• Holdouts kept for drift and fairness monitoring after launch.
• Staged rollout. Shadow mode first, then a small share of traffic, widening with rollback on any guardrail breach. Each region and each gateway has its own kill switch.

The metrics are defined as follows. Authorization rate is approved attempts over attempts, segmented by corridor, issuer and device. Retry success rate is orders recovered after a first decline over first declines. Cost per 1,000 transactions is the sum of fees, conversion spread and taxes, divided by transactions, times 1,000. Fallback hit rate is decisions served by the fallback policy over all decisions; a rising value is an early sign of instability. Dispute rate is disputes over orders. The fairness gap is the largest minus the smallest estimated effect across protected cohorts. We leave thresholds for these metrics as parameters, because setting them needs baselines we do not have.

7Observability and governance

Each request carries one identifier from ingest through features, decision and gateway call; the policy version, model hash and cohort tags are logged with it. A replay harness re-runs logged decisions for audits and incident review. The experiment registry records hypotheses, guardrails and rollback triggers. Audit trails cover consent and residency evidence, policy changes and access logs.

Security follows least privilege: scoped access, secrets in a vault, mutual TLS between services, hashed personal identifiers and redaction in logs. New signals go through a data protection impact assessment before use.

Incident playbooks share one structure. Data quality: quarantine, backfill with lineage, replay decisions, report the difference. Drift: fall back, recalibrate, test in shadow, ramp again. Fairness: halt, analyse the gap by cohort, adjust constraints, retest. Latency: switch to a lighter policy, scale, profile. Fraud surge: tighten thresholds and add step-up selectively.

8Regional adaptation

Latency budgets, fee rules, fairness parameters, decline-code mappings, regulatory rules and messages are configured per region. New corridors have little data, so the design shares strength through hierarchical priors across similar corridors and explores cautiously until their estimates settle. Each region is isolated so that a fault in one does not reach the others.

9Limitations

• No measurements. We have not measured the effect of this design on authorization rate, cost, latency or disputes. Every benefit it implies is a hypothesis.
• Unobserved confounding. Issuer policy changes are often invisible to the merchant. A shift in approval rate attributed to a routing change may come from the issuer¹.
• Sparse corridors. New corridors have too little volume for confident per-cohort estimates, and cautious exploration there slows learning.
• Interacting decisions. Routing, step-up, retries and recovery offers act on the same order, which makes the effect of any one of them hard to isolate.
• The worked model is simple. Table 2 omits retries, decline fees, currency conversion and chargebacks, and its inputs are hypothetical.
• Adversaries adapt. Fraud patterns change in response to controls; drift detection notices change but does not anticipate it.
• Smoothing is untested. The limits on traffic shifts between routes are a design choice whose effect on stability we have not measured.
• Operator interpretation. How operators read model explanations varies, and that affects which policies are approved.

10Conclusion

We have described a design that replaces a fixed gateway priority list with constrained decisions: a signal layer under schema, consent and residency contracts, and an orchestration layer that estimates effects by cohort, chooses routes with a constrained contextual bandit, and acts behind a safety layer with staged rollout. Table 1 maps each component to the published work it rests on; Table 2 shows, with hypothetical inputs, why the routing reward has to weigh authorization probability against fees rather than minimise fees. The design's own effect is unmeasured. The next step is to run the evaluation protocol on one corridor and report the result.