Multi-Region Payment Routing at Scale

Multi-region payment routing stops being a theoretical concern the moment a single authorization round trip crosses three continents. The card-not-present gateways we engineer for clients route across multiple regions, and the difference between a 180ms approval and a 940ms approval is not a graph in a Grafana dashboard. It is the difference between a converted basket and an abandoned one. This post walks through how we think about routing decisions, why settlement timing is a separate problem from authorization latency, and where the Visa Direct versus Mastercard Send fork actually matters.

Why Latency Decides Approvals

A card-not-present authorization is a chain of network hops. The cardholder hits the merchant page, the merchant page calls the gateway, the gateway calls the acquirer, the acquirer calls the card scheme, and the scheme reaches the issuing bank. Every hop adds round-trip time. When the issuing bank is in Riyadh and the acquirer is in Frankfurt and the gateway origin is in Virginia, you are paying for geography.

We measure two numbers per corridor. P50 authorization latency and P99 authorization latency. P50 tells you whether the routing is sensible. P99 tells you whether the routing is resilient. A corridor with a P50 of 220ms and a P99 of 4.1 seconds is broken even if the median looks fine, because the long tail is where 3DS challenges, network retries, and issuer timeouts live.

Edge compute changes the arithmetic. By terminating TLS, running our pre-authorization risk model, and selecting the acquirer at the edge, we shave the gateway leg from a single transcontinental hop to something measured in tens of milliseconds. Cloudflare Workers gives us 300+ points of presence to do this work in. The acquirer leg still has to happen, but we are not adding our own latency on top of it.

Routing By Acquirer, By Issuer Country, By Risk

A naive payment gateway sends every transaction to one acquirer. A serious one routes. We make routing decisions on three axes.

Acquirer Selection

Each acquirer has different strengths by region, by card brand, and by merchant category code. An acquirer with a 94% approval rate on UK-issued Visa Premier cards may have an 81% approval rate on Saudi-issued Mada cards. We maintain a rolling 14-day approval matrix per acquirer, per BIN range, per MCC. Routing picks the highest expected approval probability that also satisfies the merchant's settlement currency preference.

Issuing Bank Country

The issuer's country dictates which acquirer is local versus cross-border, which determines the interchange tier and the likelihood of a soft decline. A US-issued card hitting a UAE acquirer pays cross-border interchange and is more likely to trigger an issuer fraud rule. Where we have a same-country acquirer relationship, we use it. Where we do not, we route to the acquirer with the strongest historical performance against that issuer's BIN range.

3DS Challenge Probability

Strong Customer Authentication is not free. A frictionless 3DS flow adds maybe 400ms. A challenged flow adds 8 to 30 seconds and bleeds 18% to 25% of carts depending on the geography. We score every transaction for challenge probability before we route it, then prefer the acquirer whose 3DS server has the lowest historical challenge rate for that issuer. The Stripe documentation on payment routing covers the public mechanics of this approach if you want to read how the larger gateways describe it.

Settlement Timing Is A Different Problem

Authorization latency is about the next 800ms. Settlement timing is about the next 72 hours. They are unrelated optimizations and operators conflate them constantly.

Settlement is when funds actually move from the acquirer to the merchant account. T+1 is the marketing answer. The reality is that settlement timing depends on the acquirer's batch cutoff, the currency of settlement, the FX leg if any, and the day of the week. A transaction authorized at 23:58 UTC on a Friday in a corridor that batches at 23:00 UTC settles three banking days later than a transaction authorized at 23:02 UTC the same Friday.

For merchants on our platform with daily working capital cycles, we batch toward the earliest viable cutoff per acquirer. For merchants who optimize for FX rate, we batch into windows where the corresponding currency desk is liquid. The point is that settlement is a routing decision in itself, not a downstream side effect.

The Visa Direct Versus Mastercard Send Fork

Push payments are the second order problem. Refunds, marketplace payouts, and creator earnings all need to move money from the gateway to a card. The two pipes are Visa Direct and Mastercard Send.

Visa Direct has broader issuer reach in EMEA and APAC and lower per-transaction cost at volume, but its participating issuer list updates slowly and a non-trivial number of pushes fail with no useful error code. Mastercard Send has tighter issuer participation but better push-failure diagnostics and faster funds availability in the Americas. Visa publishes its position on the broader network direction in its payment innovation research.

Our routing logic checks BIN against both networks' participating-issuer feeds before initiating the push. If both networks support the destination card, we choose by cost and by historical success rate per corridor, in that order. If only one supports it, we use that one and we tell the merchant in the API response which network carried the payout. If neither supports it, we fall back to a domestic ACH or SEPA rail and the merchant knows the funds availability shifts from minutes to days.

Where Hitpixel Sits

Building payment infrastructure as an engineering firm rather than as a venture-funded fintech changes what you optimize for. We do not need to win a logo war. We need every transaction across our client engagements to clear at the highest viable approval rate at the lowest viable cost. The routing engine described above is the same one that runs behind every checkout in the integrations engineered by our practice, and the gateway architecture is documented at a higher level in our technology overview.

What we have learned is that routing is a continuous optimization, not a configuration. Approval matrices drift week to week as issuers update their fraud rules. Acquirer performance shifts when a scheme rolls out a new mandate. The teams that treat their gateway as a fire-and-forget vendor relationship are leaving four to nine percentage points of approval rate on the table. The teams that own the routing layer recover those points and ship them straight to revenue.

What To Measure

If you are evaluating your own routing today, three numbers tell you almost everything.

First, the spread between your best-performing acquirer and your worst-performing acquirer for the same BIN range. A spread above five points means you are not routing, you are guessing.

Second, your P99 authorization latency by issuer country. Above 1.5 seconds means your edge story is incomplete, and the cart abandonment math will eventually force the issue.

Third, your push payment success rate per network per corridor. Below 96% on a corridor where both Visa Direct and Mastercard Send are available means your routing logic is not checking participation feeds before initiating the push, and your operations team is reconciling failures by hand.

Routing is unsexy infrastructure work. It is also where margin lives.