What actually happens between tapping a card and the terminal saying "Approved"

The cast of characters

A card payment involves at least five parties, and mixing them up is the most common source of confusion:

• Cardholder — the person paying.
• Merchant — the business getting paid, and their terminal/POS (or e-commerce checkout).
• Acquirer — the merchant's bank (or a payment processor acting on its behalf), which has the relationship with the merchant and connects them to the card networks.
• Card network / scheme — Visa, Mastercard, etc. They don't hold money or issue cards; they route messages and set the rules everyone else follows.
• Issuer — the cardholder's bank, the one that actually approves or declines the transaction and is on the hook for the money.

The authorization hop, step by step

This is the real-time part — what happens in the ~1-3 seconds between tapping the card and the terminal printing a result.

1. Card read. The terminal reads the card (EMV chip, contactless NFC, or magstripe as a fallback) and generates a cryptogram — a one-time cryptographic proof that this is a genuine card present at this terminal, not a replayed or cloned transaction.
2. Terminal → Acquirer. The terminal packages the transaction (amount, card data, cryptogram, merchant ID) and sends it to the acquirer's payment gateway, usually as an ISO 8583 message — the decades-old message format the entire card industry still runs on.
3. Acquirer → Card network. The acquirer looks at the card's BIN (the first 6-8 digits) to identify which network it belongs to, and forwards the request onto that network's switch (Visa's VisaNet, Mastercard's Banknet, etc.).
4. Card network → Issuer. The network routes the request to the specific issuing bank, based on the BIN.
5. Issuer decision. The issuer checks the account: sufficient funds/credit, fraud rules, whether the card is blocked, velocity checks (too many transactions too fast), and the cryptogram's validity. It responds with an approval or a decline and a reason code.
6. The response retraces the same path back through the network, to the acquirer, to the terminal — which is why a slow or overloaded issuer, network, or acquirer can each independently make the transaction feel slow, even though the merchant's own systems did nothing wrong.

If the issuer can't be reached (network partition, timeout), the network or acquirer may fall back to stand-in processing — approving small transactions against pre-set risk rules on the issuer's behalf, to be reconciled later. This is why very rarely a transaction can be approved and then still fail to settle.

Authorization is not settlement

This is the distinction that trips up most people outside the industry: approval at the terminal does not mean money has moved. Authorization just places a hold and confirms the issuer is willing to pay. The actual movement of funds happens later, in a separate, batch-oriented process:

• Clearing. Periodically (often once a day), the acquirer submits a batch of all the day's approved authorizations to the network for clearing — this is where the network calculates what each acquirer owes and is owed relative to each issuer.
• Settlement. The network nets out the positions across all its member banks and moves the actual funds between the issuer's and acquirer's settlement accounts, typically T+1 or T+2.
• Reconciliation. The merchant/acquirer side then has to match what was authorized against what actually cleared and settled — this is where discrepancies (a transaction that was authorized but never captured, a partial capture, a reversal) get caught. Anyone who has built reconciliation logic against Visa/Mastercard settlement files knows this step is where the real edge cases live, not in the real-time authorization flow.

Why this two-phase design exists

Splitting authorization (fast, real-time, one-at-a-time) from clearing/settlement (slow, batched, net-everything-together) is what lets the whole system scale: issuers and networks don't need to move real money on every single swipe, only reach a yes/no decision, and settle the net positions once a day instead of millions of individual transfers. The cost of that design is complexity everywhere downstream — every system that touches card payments, from a merchant's accounting to a bank's regulatory reporting, has to model "authorized" and "settled" as genuinely different states, not two names for the same thing.

More posts