How Payment Transactions Are Routed Between Banks, Switches, and Processors

What happens in a payment hop by hop

The path runs from the merchant terminal through the acquirer or its processor and the switch, then across the card scheme to the issuer before the same hops reverse carrying the decision. Each hop is a request and a matching response.

At the terminal, a tap or a checkout submit builds an authorization request. The acquirer's processor formats it and the switch reads the card's Bank Identification Number (BIN) to select a route before the scheme delivers it to the right issuer endpoint for the issuer to answer. Then the answer retraces the chain.

Most of that traffic still speaks one language. Under ISO 8583, a four-digit Message Type Indicator classifies the message, so 0100 is the authorization request and 0110 the response, with bitmaps flagging which of up to 128 data elements are present.

Which tells you something useful before you design anything: every hop is a synchronous request-response pair, so your total time budget is the sum of all of them plus the slowest single participant. You cannot fix a slow issuer with a fast gateway.

Who does each party handle

Six parties touch a card payment, and each owns a different slice from the merchant who captures to the issuer who decides. Settlement follows later on a separate clock.

Authorization and settlement are two different jobs on two different timelines. Authorization is real-time and synchronous. Clearing and settlement move the actual money afterward, in daily batches on card rails that take 1 to 3 business days to complete, while account-to-account rails settle immediately and finally.

Here is what each party owns during authorization:

• Merchant and terminal: capture the card data and start the request

• Acquirer: holds the merchant account and takes the funding risk

• Processor: formats, forwards, and reconciles messages

• Switch: applies routing rules and translates protocols

• Scheme: delivers to the correct issuer and sets the rulebook

• Issuer: makes the approve or decline call

That split matters when you're buying. A vendor who sells you "payment processing" owns only two of those six boxes, and the contract rarely tells you which four you're still responsible for.

What the acquirer and processor do

The acquirer holds the merchant relationship and the money risk. The processor builds and forwards the authorization message. Same transaction and different jobs, handled by increasingly different companies.

The acquiring bank initiates authorization requests and retrieves funds on the merchant's behalf. The acquirer processor sits underneath and moves the message through the card network and back. Those roles used to sit in one entity and have been separating in recent years because the functions genuinely differ.

Scale explains why the split happened. The United States hosts over 320 active merchant acquirers handling more than $9 trillion in annual volume, which is far too many balance sheets for each to also run its own message-formatting stack. So processing consolidated while acquiring stayed fragmented. If you're mapping your own chain, ask which of the two your counterparty actually is, because only one of them can change your routing.

What the switch and scheme do

The switch decides where the message goes. The scheme carries it to the correct issuer. That's the whole middle mile.

Inside the switch, the BIN identifies the card's network and the routing table names the destination. The switch also translates protocols between parties who don't speak the same dialect, which is why it sits between processors and issuing banks rather than inside any one of them. It's the routing and protocol translation layer, distinct from both the gateway and the processor.

The scheme side is built for volume that dwarfs any single institution. VisaNet handles more than 65,000 transaction messages a second at capacity and serves 15,900 financial institutions.

Read that capacity figure as a warning about where your bottleneck lives. Your own switch, sized for last year's peak, almost certainly will be your constraint.

What the issuer decides

The issuer checks the balance and scores the risk before returning approve or decline. That decision is the only one in the chain that can create or destroy revenue.

The issuer processor normalizes the incoming message and scores it for fraud, then composes the response with a code in data element 39. Response code 00 means approved. 05 means declined.

Wrong calls at this hop cost more than any other failure in the system. Ron van Wezel, a strategic advisor in the retail banking and payments practice at Datos Insights, put the global cost of false declines at US$213 billion in 2025, a figure that will reach $297 billion by 2029, with a third of financial institutions reporting they'd lost 2% to 5% of customers to failed payments.

The uncomfortable implication for anyone tuning issuer rules: a tighter fraud threshold that catches marginally more fraud can lose you customers permanently, because the cardholder who gets declined reaches for the next card, and that one becomes the default.

How routing logic picks a path

A switch chooses the path by applying configured rules to each message in real time based on the BIN and the cost of each available rail.

Cost rules get the most attention because the money is countable. Least cost routing sends eligible transactions to the cheapest available network, and it works: CMSPI estimates that least-cost debit routing has already saved US merchants over $1 billion annually, with room for up to $3 billion in total as rule changes open more volume to it.

But approval rates and cost pull in different directions, and the second one is bigger. Each network applies its own acceptance criteria, so the cheapest rail is not reliably the one most likely to approve. If you route purely on cost, you'll book a fee saving measured in basis points against an approval loss measured in whole percentage points.

That's the tradeoff worth encoding in your rules. Cost as a tiebreaker, approval probability as the primary signal.

How failover keeps payments alive

Failover keeps payments alive through health checks that spot a dead hop and secondary routes that carry traffic around it.

Health checks watch each connection continuously. When a destination stops answering inside its timeout, the switch marks it down and sends the next message elsewhere, all inside the same customer session. The schemes run their own version at the issuer hop. Stand-in processing lets the network authorize on the issuer's behalf using pre-configured issuer parameters when the issuer can't respond.

The gain is measurable. Visa's Smarter STIP, which trained a deep-learning model on billions of records and reached 95% accuracy against the decisions issuers would have made themselves, cut declines by as much as 50% in some outage scenarios.

Retries need the same discipline. A soft decline is retryable and a hard decline is not, so a switch that retries everything turns one issuer hiccup into a fraud signal against your own BIN range.

Why latency and uptime matter

Card-present authorization is engineered for 400 to 800 milliseconds end to end, and every hop you add spends part of that budget. Nothing in the chain gets to be slow.

The math is unforgiving because the budget is shared. A reasonable target for a switch's own processing time is under 50 milliseconds at the 99th percentile, which leaves room for network transit and the issuer's response inside the window a cardholder tolerates. The issuer's internal slice is frequently held under 100ms for the same reason. Owning more of the path helps: Adyen's own acquiring infrastructure removes an intermediate hop worth 40 to 120 milliseconds compared with conventional processor-acquirer setups.

So the delay changes outcomes, because a timeout at any hop becomes a decline, and a decline becomes an abandoned cart. Uptime targets of 99.999% exist for switches precisely because downtime there fails transactions across an entire network at once.

Build resilient routing with EGS

If you've mapped your chain and found hops you don't control or can't measure, the next step is deciding what to build and what to buy. Energize Global Services is a multinational development centre founded in 2007, with roughly 500 people across delivery centres in Europe and Africa that build payment infrastructure and core banking platforms for financial institutions.

The work covers the parts of the path this article walked through: switch and authorization logic inside a millisecond budget and custom development where an off-the-shelf platform won't hold your routing rules. EGS runs ISO 27001 and SOC 2 certified engineering, and now supports ISO 20022 messaging alongside ISO 8583.

Book a call with the EGS engineering team to talk through your routing and where your current latency budget is going.