How Card Authorization Works: A Practical Walkthrough

What happens in the two seconds after you tap your card: the players, the ISO 8583 message, approval and decline paths, and where crypto cards plug in.

When you tap your card and the terminal beeps “approved” two seconds later, your payment has already made a round trip across up to five systems. Understanding that trip explains why payments fail, why holds appear on your balance, and how crypto cards fit into the same rails.

The five players

  • Cardholder — you, with a physical card, virtual card, or phone wallet.
  • Merchant / Acquirer — the shop and its bank or payment processor, which captures the transaction.
  • Card network — Visa or Mastercard, the messaging and rules layer in the middle.
  • Issuer — the institution that holds your line of credit or balance and says yes or no.
  • (Optional) Processor / program manager — companies that run the technical stack on behalf of an issuer. Most crypto card programs rely heavily on these.

The authorization round trip

  1. Capture. The terminal (or payment page) reads your card and builds an authorization request: card number, amount, currency, merchant category code (MCC), and cryptographic proof that the card is genuine.
  2. Acquirer → network. The acquirer packages the request and sends it to the card network.
  3. Network → issuer. The network routes it to the issuer identified by the card’s BIN (the first 6–8 digits).
  4. Issuer decision. The issuer checks: Is the card active? Is the balance or credit sufficient? Does this transaction fit the risk profile (location, MCC, velocity)? Is 3-D Secure required? It then responds with an approval code or a decline reason.
  5. Back again. The response travels the same path in reverse. The whole round trip typically takes 1–3 seconds.

The message format carrying all this is usually ISO 8583 — a dense, field-numbered binary protocol that has powered card payments since the 1980s. Our deep dive dissects an actual message field by field.

Authorization is not settlement

The beep means the issuer promised to pay — no money has moved yet. Two separate processes follow:

  • Clearing (usually same day, batched): the acquirer submits the transaction for the record, and the final amount replaces the authorized estimate. This is why a fuel pump’s $100 pre-auth later becomes your actual $43 fill-up.
  • Settlement (T+1 or later): funds actually move between issuer and acquirer through the network’s settlement banks.

Pending charges, hotel deposits, and car-rental holds all live in the gap between these steps.

Where crypto cards plug in

A crypto card adds one step in front of this flow, and changes nothing inside it:

  • Your stablecoin balance sits with the card program’s provider.
  • When an authorization arrives, the issuer side checks your crypto balance, converts the needed amount to fiat at that moment, and approves against the fiat result.
  • From the merchant and network’s point of view, it is a completely ordinary prepaid or debit authorization.

This is why a crypto card works “everywhere Visa is accepted” — and also why conversion fees and spreads are charged per transaction: the conversion happens per transaction.

Why transactions decline (beyond “insufficient funds”)

  • Risk scoring — unusual country, unusual MCC, or unusual velocity for your profile.
  • MCC restrictions — many prepaid and crypto cards block gambling, money services, or quasi-cash MCCs outright.
  • 3-D Secure failures — the online verification step timed out or was abandoned.
  • Issuer or processor downtime — rare on the big networks, more common at smaller program managers.

For a visual, animated version of this flow, try the interactive auth flow demo — it walks through each hop with the ISO 8583 fields annotated.