Chapter 9 — How Card Payments Actually Work

Authorization at the protocol level — what happens in the milliseconds between your tap and the approval beep.

Let's zoom back to where our journey began — WhiteBottle Coffee.

It's 8:57am on a Monday. You just tapped your card at WhiteBottle Coffee, and in Chapter 4 we mapped the canonical payment flow — authorization, clearing, settlement, reconciliation — as a universal pattern across all payment rails. Now, it's time to zoom in on the dominant rail: Cards.

That "Approved" message on the screen? It arrived in under two seconds. And in that sliver of time, your bank made a decision that involved real money, real risk, and a surprising amount of complexity.

Let's rewind to the moment your card touched the terminal and slow things way down.

The Question Your Bank Had to Answer

Back at WhiteBottle, the terminal just sent a question to your bank: "Can this person pay $4.50?"

That sounds simple. But consider what your bank — let's say it's Chase — actually had to figure out in a few hundred milliseconds:

1. Is this card number real?
2. Has it been reported stolen?
3. Is there $4.50 available on the account?
4. Does this purchase look like something the cardholder would do?
5. Or does it look like someone halfway across the world just cloned a card?

All of that, in less time than it takes you to blink. And the stakes are genuinely high. Say yes to a fraudster, and the bank eats the loss. Say no to a legitimate customer, and that customer might close their account in frustration. Authorization is, at its core, real-time risk management — and your bank performs it thousands of times per second across all its cardholders.

The Four-Step Flow

If you refer back to the diagram in Chapter 4, you saw the full journey of a card transaction from tap to settlement. Authorization is the first leg of that journey — the part that happens while you're still standing at the counter.

Here's how it unfolds.

Step 1: The Payment Request

The moment your card touches the terminal, the merchant's point-of-sale (POS) system assembles a message. Think of it like a telegram: it contains your card number, the transaction amount ($4.50), the merchant's identity, a timestamp, and a few other details. This message is an authorization request — a formal question: "Should this transaction be approved?"

Step 2: The Acquirer Forwards It

That request doesn't go straight to your bank. It first hits the merchant's bank, known as the acquirer (or their payment processor). The acquirer's job here is straightforward: package the request and route it into the card network — Visa, Mastercard, or whichever network your card belongs to. The network acts as the postal service, making sure the message reaches the right issuing bank.

Step 3: The Issuer Makes the Call

This is where the real action happens. Your issuing bank receives the request and runs through its checklist at machine speed.

Is the card valid and active? Yes. Is the account in good standing? Yes. Is there enough available credit or balance to cover $4.50? Yes. Does this transaction match the cardholder's typical spending patterns — buying coffee in their home city on a Monday morning? Yes.

If everything checks out, the issuer does two things simultaneously. First, it generates an approval with a unique authorization code (a short alphanumeric string like AUTH-7X92K). Second, it places a hold on $4.50 in your account. That money is still technically yours, but it's been earmarked — set aside so you can't accidentally spend it twice.

If something doesn't check out — insufficient funds, a frozen account, a suspicious pattern — the issuer sends back a decline with a reason code. Those codes matter more than most merchants realize. A code 51 (insufficient funds) is temporary — the same card might work perfectly tomorrow after payday. A code 05 ("do not honor") means the issuer is suspicious and doesn't want to tell you why — retrying immediately can make things worse by making the card look more suspicious. And a code 04 (pickup card) means the card is reported stolen — do not retry at all. Reading these codes correctly, and retrying intelligently, is the difference between recovering a failed payment and burning it. We'll build a full playbook for this in Chapter 15, when we cover dunning.

Step 4: The Response Comes Back

The issuer's answer travels back the way it came: through the card network, to the acquirer, and finally to the merchant's terminal. The screen flashes "Approved," the barista hands you your coffee, and the whole thing took maybe one and a half seconds.

But here's the thing most people miss: no money has actually moved yet. That approval is a promise, not a payment. The actual transfer of funds won't happen until clearing and settlement — which we introduced at the conceptual level in Chapter 4. For cards specifically, clearing happens in overnight batches and settlement follows one or two days later — what the industry calls T+1 or T+2. For now, your bank has simply said, "Yes, this person is good for it," and put $4.50 on reserve.

This is one reason merchants in certain industries — hotels, car rentals, fuel stations — are aggressive about their authorization timing and sometimes place holds larger than the expected final amount. That "phantom charge" you've seen on your bank statement after filling up your gas tank? Now you know where it comes from.

On-Us vs Off-Us: Does the Routing Always Look Like This?

Not every card transaction takes the full four-hop journey shown above. When the merchant's acquirer and the cardholder's issuer happen to be the same bank, the network can be bypassed entirely — a shortcut known as an on-us transaction.

What Happens Next

So your bank said yes, reserved the money, and you walked away with your coffee. The authorization worked. But that "Approved" beep works the same whether you're paying with a debit card or a credit card. Behind that identical beep, your bank just did something fundamentally different depending on which card you used.

In the next chapter, we'll pull apart the two most common cards in your wallet and trace how the same rails carry very different financial instruments — with consequences for everyone from the cardholder to the merchant to the regulator.

Sources

• ISO 8583, Financial transaction card originated messages — the interchange message standard that authorization requests and responses travel in
• Visa, Visa Core Rules and Visa Product and Service Rules — authorization, hold, and response-code requirements
• Mastercard, Transaction Processing Rules — authorization routing and on-us processing provisions
• Visa and Mastercard published response-code references — decline reason codes (e.g., 05 "do not honor," 51 insufficient funds, 04 pickup card)