Inside the Payment Network: How VisaNet and Mastercard Network Actually Route Transactions

A coffee shop in Tokyo accepts a Visa card issued by a small credit union in Ohio.

The merchant has never integrated with the credit union.

The credit union has never built an API with the coffee shop.

They do not share databases. They do not share authentication systems. They do not even know each other exists.

Yet, within milliseconds, the transaction request travels across the planet, reaches the correct issuing bank, receives a risk decision, and returns an approval message.

The system that makes this possible is the card network.

Most developers think of Visa or Mastercard as payment companies that “move money.” That description is incomplete.

The card network is not the bank. It does not approve credit. It does not own the customer account. It does not hold the merchant balance.

The card network is a globally distributed transaction routing system.

Its primary responsibility is simple:

Take an authorization message from one financial institution, identify the correct destination institution, enforce network rules, and deliver the message within a strict latency window.

Behind the two-second card tap experience exists one of the largest real-time routing architectures ever built.

1. The Card Network’s Position in the Architecture

A card payment contains multiple independent systems:

Cardholder
    |
    |
Merchant POS
    |
    |
Payment Gateway
    |
    |
Acquirer Processor
    |
    |
Acquiring Bank
    |
    |
=====================
 Card Network
 VisaNet / Mastercard Network
=====================
    |
    |
Issuer Processor
    |
    |
Issuer Bank
    |
    |
Cardholder Account

The network sits exactly in the middle.

It connects two worlds:

The Acquiring Side

The acquiring bank represents the merchant.

Responsibilities:

• merchant onboarding
• merchant risk
• transaction acceptance
• funding merchant accounts

The Issuing Side

The issuing bank represents the cardholder.

Responsibilities:

• card issuance
• credit/debit account
• authorization decision
• fraud assessment
• customer liability

The network creates a trusted communication layer between these two independent institutions.

2. VisaNet and Mastercard Network Are Not Payment Ledgers

One of the biggest architectural misconceptions is that Visa or Mastercard maintain everyone’s money balances.

They do not.

The network does not have:

Tokyo Coffee Shop Balance = $10,000
Ohio Credit Union Balance = $500 Million

The actual financial state exists inside:

• issuer banking systems
• acquirer banking systems
• settlement banks

The network maintains something different:

Transaction State

For example:

Transaction ID:
7A82F92C

Merchant:
Tokyo Coffee

Acquirer:
Japan Acquiring Bank

Issuer:
Ohio Credit Union

Amount:
 $5

Status:
AUTHORIZED

The network remembers:

• where the transaction came from
• where it needs to go
• whether messages were delivered
• whether clearing records match

The network is closer to a distributed messaging backbone than a bank ledger.

3. The First Routing Problem: Finding the Issuer

When a customer taps a card, the first question is:

“Which bank owns this card?”

The answer comes from the card number.

Historically:

16 Digit PAN

4000 1234 5678 9012
^^^^
BIN

The first digits are the BIN (Bank Identification Number).

Today this is technically called the IIN (Issuer Identification Number), but the industry still commonly says BIN.

The network maintains massive routing tables:

BIN Range
    |
    |
Issuer Member ID
    |
    |
Issuer Processing Endpoint

Example:

BIN:
400012

Network:
Visa

Issuer:
Ohio Credit Union

Destination:
issuer-switch.ohcu.com

The network does not ask:

“Where is the customer’s account?”

It asks:

“Which institution is responsible for this credential?”

4. The Tokenization Routing Problem

Tokenization created a major architectural challenge.

Before tokenization:

PAN
 |
 |
BIN
 |
 |
Issuer

Simple.

The first digits directly identified the issuer.

After tokenization:

Device Token / Network Token

4000 9876 1234 5555

        |
        |
        v

Token Vault (Network Internal)

        |
        |
        v

Real PAN

5200 1111 2222 3333

The token may no longer contain the original issuer routing information.

A Visa network token typically starts with a Visa BIN, but the underlying card could have been issued by a completely different institution on a different network.

Therefore, routing changed.

The network now performs a stateful lookup:

Receive Token
      |
      |
Identify Token BIN
      |
      |
Query Internal Token Vault
      |
      |
Resolve Real PAN
      |
      |
Find Issuer
      |
      |
Route Authorization

Tokenization transformed the network from a simple stateless router into a stateful routing platform.

5. Inside the Network Switch

A card network switch is not a traditional API gateway.

It is optimized for:

• millions of transactions per second
• predictable latency
• deterministic routing
• zero message loss

A simplified architecture:

              Incoming Connection

                     |
                     |

             Network Edge Gateway

                     |
                     |

          Message Validation Layer

                     |
                     |

             Routing Engine

                     |
        ------------------------
        |                      |
        |                      |

   Visa Issuer Route      Mastercard Issuer Route

                     |
                     |

              Outbound Connector

                     |
                     |

              Issuer Processor

6. Network Edge Layer

The first component receiving traffic is the network edge.

Responsibilities:

Connection Authentication

The network verifies:

• acquirer identity
• cryptographic certificates
• network membership
• message signing

Only approved financial institutions can connect.

A random internet client cannot send:

0100 Authorization Request

to VisaNet.

Message Validation

The network validates:

• ISO 8583 format
• mandatory fields
• message type
• field lengths
• merchant identifiers

Example:

MTI:
0100

DE 2:
PAN / Token

DE 4:
Amount

DE 41:
Terminal ID

DE 42:
Merchant ID

Invalid messages are rejected before routing.

7. The Routing Engine

The routing engine is the heart of the network.

Its job:

“Given this transaction, where should it go?”

Inputs:

PAN / Token
Network
Country
Currency
Issuer Identifier
Product Type

Outputs:

Issuer Processor Endpoint

Example:

Input:

Token:
4765xxxx

Country:
Japan

Currency:
JPY

Routing decision:

Issuer:
Ohio Credit Union

Processor:
FIS

Destination:
FIS authorization gateway

8. The Network Does Not Perform Credit Decisions (Usually)

A common misunderstanding:

“Visa approved my transaction.”

Technically incorrect 99% of the time.

Visa transported the request.

The issuer approved it.

The real decision happens here:

Issuer Processor

       |
       |

Account System

       |
       |

Risk Engine

       |
       |

Credit Rules

       |
       |

APPROVE / DECLINE

The network simply carries:

0100
Authorization Request

-->

0110
Authorization Response

The Exception: Stand-In Processing (STIP)

There is one critical architectural exception. If the network attempts to route the message to the issuer and the issuer’s systems are down or unresponsive, the network will not simply time out and fail.

Instead, VisaNet runs a service called STIP (Stand-In Processing), and Mastercard runs MIP (Mastercard In-Process).

If the issuer is unreachable, the network intercepts the timeout and makes a localized risk decision based on cached cardholder profiles, spending velocity, and risk parameters. It generates the 0110response itself.

This prevents a single bank’s data center outage from causing global declines for their cardholders.

9. STAN, RRN, and Transaction Tracking

Because billions of messages move through the network, every transaction needs identity.

Two important identifiers:

STAN

System Trace Audit Number

Usually six digits.

Example:

482921

Used for:

• transaction tracking
• operational troubleshooting
• message matching

RRN

Retrieval Reference Number

A longer reference used across the payment lifecycle.

Used for:

• clearing
• reconciliation
• disputes
• investigations

Example:

Transaction Authorization

0100
 |
 |
STAN generated
 |
 |
RRN generated
 |
 |
0110 response
 |
 |
Clearing file

10. Network Reliability Architecture

A card network cannot behave like a normal web service.

A website outage means users refresh later.

A payment network outage means:

• merchants lose revenue
• banks cannot authorize cards
• millions of transactions fail

Therefore networks use:

Active-Active Data Centers

Example:

North America Region

Data Center A
        |
        |
        |
Data Center B


Europe Region

Data Center C
        |
        |
        |
Data Center D

Traffic can immediately shift without DNS failover delays.

To achieve this, the routing edge must be entirely stateless, pushing transaction state to highly replicated, distributed backing stores only when necessary (like STIP lookups).

Persistent Connections

Banks do not call:

POST /authorize

for every transaction.

Instead, they maintain:

Long-lived TCP/TLS connections

between:

Acquirer Processor

        |

VisaNet

        |

Issuer Processor

This removes connection overhead. Multiplexing multiple ISO 8583 messages over a single persistent socket is standard practice.

11. The Latency Budget

A card authorization has a strict time constraint.

A simplified budget:

Merchant POS
|
| 50ms
|
Gateway
|
| 100ms
|
Acquirer
|
| 100ms
|
Network
|
| 200ms
|
Issuer
|
| 500ms
|
Risk + Ledger Decision
|
Return Path

Every layer competes for milliseconds.

A slow component does not create a slow payment.

It creates a decline.

12. Clearing Is a Different Network Path

Authorization is real-time.

Clearing is not.

The same network has two personalities:

Real-Time Authorization Network

Purpose:

“Can this transaction happen?”

Protocol:

ISO 8583

Latency:

milliseconds

Clearing Network

Purpose:

“Who owes whom money?”

Protocol:

Batch files (ISO 8583 financial advices, or increasingly ISO 20022)

Latency:

hours/days

The authorization path:

Merchant

10:01:05

APPROVED

The settlement path:

End of Day

Captured Transactions

Clearing Files

Net Settlement

Merchant Funding

Different systems. Different optimization goals.

13. Why the Network Model Works

Before card networks, every bank would need direct relationships.

Without a network:

Bank A
 |
 |
Bank B

Bank A
 |
 |
Bank C

Bank A
 |
 |
Bank D

The number of connections explodes combinatorially.

The card network creates a hub-and-spoke architecture:

             Bank A

              |
              |

Bank B ---- Network ---- Bank C

              |

             Bank D

Every participant integrates once.

The network provides global reach.

14. The Architecture Revealed

The card network is not a bank.

It is not a wallet.

It is not a payment processor.

It is a global financial routing layer.

Its architecture solves one fundamental distributed systems problem:

How do independent financial institutions reach agreement without trusting each other directly?

The answer is:

• standardized messaging (ISO 8583)
• deterministic routing
• cryptographic identity
• network membership rules
• transaction identifiers
• real-time switching
• asynchronous settlement

When a customer taps a card, the visible experience is a green checkmark.

Behind that checkmark is a global routing engine moving a cryptographically authenticated message from one isolated financial institution to another in milliseconds.

The card network is not moving the money.

It is making the world’s disconnected financial systems communicate as if they were one system.