The simple version
When you click Pay, your card details travel through a chain of at least four separate companies before your bank decides whether to approve the charge. The whole sequence takes under two seconds, and almost none of it is visible to you or the merchant.
The players you’ve never heard of
Most people assume a card transaction involves two parties: the person paying and the business getting paid. The actual chain has four, and understanding them explains almost everything else.
The merchant is whoever is selling you something. They connect to a payment processor (companies like Stripe, Square, or Adyen) that handles the technical work of routing transactions. That processor sends the transaction to a card network (Visa or Mastercard, most likely) which acts as the message-routing layer between processors and banks. Finally, your issuing bank, the one that gave you the card, makes the yes-or-no call.
Each of these parties takes a small cut of every transaction. The combined fee, called the interchange rate, typically runs between 1.5% and 3.5% of the transaction value depending on card type, merchant category, and geography. That spread funds rewards programs, fraud protection, and the infrastructure that makes the whole thing work.
The first 200 milliseconds: encryption and routing
When you click Pay on a website, the merchant’s payment form (almost always hosted by the processor, not the merchant, even if it looks seamless) encrypts your card number using a public key. The actual card number never touches the merchant’s servers if the integration is done correctly. This matters enormously: it’s why a breach at an online retailer usually doesn’t expose raw card numbers.
The encrypted payload travels to the processor’s data center. The processor strips out identifying information about you, packages the transaction details, and forwards an authorization request over a private, dedicated network to Visa or Mastercard. These networks run on separate infrastructure from the public internet, which is one reason payment systems stayed online during major internet outages that took down consumer services.
Visa’s network, VisaNet, processes an average of around 5,000 transactions per second globally, with capacity to handle over 65,000 per second during peaks. Mastercard publishes similar figures. These are not web servers. They are specialized financial messaging systems that have been continuously running, in one form or another, since the 1970s.
The 800 milliseconds that matter most: your bank’s decision
Once the card network receives the authorization request, it routes the message to your issuing bank. This is where the real decision happens, and it’s more complicated than a simple balance check.
Your bank runs the transaction against a fraud-scoring model in real time. The model considers dozens of variables: the merchant’s category code, your purchase history with similar merchants, whether the location (or IP address) matches your recent activity, the transaction amount relative to your typical spending, and whether your card has been dormant or unusually active in the prior hours.
This is not a human decision. It’s a statistical model assigning a probability to the question: “Is the person making this charge the cardholder?” If the score crosses a threshold, the bank approves. If it triggers a higher-risk flag, the bank may decline, or in some cases, trigger a step-up authentication request (the SMS code you sometimes receive).
The bank sends its response back through the card network to the processor to the merchant in a matter of milliseconds. The response is essentially a single piece of data: approved or declined, plus an authorization code or a reason code.
What the bank is not doing at this moment is moving any money. Approval is a promise, not a transfer. The actual settlement, the movement of funds, happens later, typically within one to three business days, in a separate batch process.
Why declines happen even when your balance is fine
Fraud models decline legitimate transactions, and they do it frequently. The industry term is “false positive,” and it costs real money. A major card network study found that false declines cost merchants and issuers more in lost revenue than actual fraud does, though precise figures vary by region and card program.
The model has imperfect information. It doesn’t know you’re traveling. It doesn’t know you’re buying an unusual gift. It doesn’t know the merchant in a different country is legitimate. It’s pattern-matching against your history, and anything that breaks the pattern raises your risk score.
This is the core tension in payment systems: the fraud model has to be aggressive enough to catch real fraud but not so aggressive that it declines good customers who then take their business elsewhere. Banks tune these thresholds constantly, and different issuers make different tradeoffs. Cards marketed to frequent travelers are tuned differently than cards designed for local everyday use.
The legacy infrastructure holding everything together
One detail that surprises most people: significant parts of this infrastructure run on technology that predates the iPhone by four decades. The messaging format that banks use to communicate authorization requests, ISO 8583, was standardized in 1987 and is still the foundation of most card transactions globally.
This isn’t negligence. Replacing core financial messaging infrastructure across thousands of banks and processors simultaneously is an engineering and coordination problem of extraordinary difficulty. The systems work, they’re understood, and the cost and risk of replacing them outweigh the benefits of modernization for most participants. As with many critical systems, stability is worth more than novelty. The same dynamic appears in how TCP/IP keeps your data intact across bad hops, where decades-old protocols continue to handle modern scale because the fundamentals were right.
Newer entrants like Stripe have built modern APIs on top of this old infrastructure, which is a large part of their value. The developer-facing experience looks clean and contemporary. Under the hood, they’re translating your API call into ISO 8583 messages and routing them through the same rails every other processor uses.
The two seconds you spend waiting for the approval screen is not a technical limitation. It’s the time required for a message to travel across multiple private networks, get scored by a fraud model, return a response, and render in your browser. Given that it involves at least four organizations’ systems communicating with each other using a protocol designed before the web existed, two seconds is fast.
