Authorization: the first journey
How a tap becomes an approval in seconds: the ISO 8583 request and response, the authorisation hold, and what happens when the issuer cannot answer.
L0 Explain simply
An everyday analogy: authorisation is a phone call, not a payment. When a card is tapped, the terminal in effect rings the cardholder's bank and asks: will you stand behind this amount? The answer comes back within seconds — yes with a code, or no with a reason. Nothing has been paid yet; the bank has only promised, and set the amount aside so the promise can be kept. At Demo Coffee Ltd, Maya Chen's tap travels from the terminal to Meridian Bank, the merchant's acquirer, through the Cardnet network — a fictional stand-in for Visa- or Mastercard-style networks — to Bank Alfa, her issuer; the answer retraces the same path. (SYNTHETIC / TRAINING ONLY — all names fictional.) The money itself makes a separate, slower journey later — that second journey is the next topic.
L1 Core concepts
Authorisation runs on a messaging standard called ISO 8583. The terminal reads the card — EMV chip, contactless tap, or typed-in details online — and builds an authorization request, message type 0100, carrying the PAN (primary account number), the amount, merchant details and, for chip and contactless, a one-time cryptogram. The acquirer forwards it to the network, which reads the BIN (bank identification number — the PAN's leading digits) to route it to the right issuer. The issuer checks the account, limits and fraud signals, then answers with a 0110 response: approved, carrying an authorisation code, or declined with a reason. Approval creates an authorisation hold: the amount is earmarked and reduces what the cardholder can spend, but no money has moved. Card-present and card-not-present payments ride the same message legs; they differ in how the card is proven genuine.
L2 Practitioner view
Operationally, authorisation is engineered to produce an answer in seconds, every time — so the interesting cases are the ones where it cannot. When an issuer is unreachable or too slow, the network can answer on its behalf: stand-in processing, approving or declining within limits the issuer agreed in advance, then sending the issuer an advice message once it is back. An approval, note, is not a guarantee of final payment: it can expire unused, be reversed when a basket is abandoned, or be followed at clearing by a different amount — fuel pumps and hotels authorise estimates. Practitioners therefore manage the authorisation hold as a lifecycle of its own; holds that outlive their purchase are a steady source of cardholder complaints. And at the margins, offline authorisation survives: chip and terminal can approve small payments between themselves without going online, trading issuer certainty for speed under rules the schemes define.
L3 Technical details
Strictly speaking, each network runs its own dialect of ISO 8583: the message types are shared — 0100 authorization request, 0110 response, 0400 reversal, plus advice classes that inform rather than ask — but many data elements are network-defined, which is why an acquirer processor certifies against each network separately. Inside the request, the chip's ARQC (authorization request cryptogram) lets the issuer verify mathematically that a genuine card built this exact transaction; the response can carry a matching cryptogram back for the chip to check. Stand-in processing is a ruled service, not a courtesy: the scheme manuals define when the network may answer for an unavailable issuer, within issuer-set limits, and how the resulting advice reaches the issuer for posting. The authorisation code returned on approval is similarly governed — it identifies a specific issuer decision and travels into clearing, where it lets a presentment be matched back to the authorisation it consumes.
Sources & standards2
- Market practiceMarch 2003 edition
A glossary of terms used in payments and settlement systems ↗ — CPSS (now CPMI), Bank for International Settlements
Terminology has evolved since this edition; newer CPMI publications refine some definitions.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.
SEE THE PAYMENT MOVE
Read the steps as text
- 05ProcessingBank Alfa checks the card, the funds and the riskBank Alfa (issuer)
The issuer decides in well under a second: is the card open, does the EMV cryptogram verify, do funds cover the amount, and does the fraud engine trust this purchase? Approve or decline — the whole flow exists for this moment.
- 09PostingBank Alfa places an authorisation holdBank Alfa (issuer)
The issuer reserves EUR 42.50 against Maya's available balance so she cannot spend it twice. This hold is not a movement of money — nothing has been debited and nothing has moved between the banks. The real debit comes at clearing and settlement.
An approval is a promise, not a payment. No money has moved yet — the debit, the interbank movement and the merchant's payout all happen later, in clearing and settlement.
- RESERVE Maya Chen's card account at Bank Alfa — EUR 42.50
Sources for this topic2
- Market practiceMarch 2003 edition
A glossary of terms used in payments and settlement systems ↗ — CPSS (now CPMI), Bank for International Settlements
Terminology has evolved since this edition; newer CPMI publications refine some definitions.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.
Deepest material on this page: L3 — Technical details. Where a topic stops short of implementation depth, that is a deliberate coverage decision, not an oversight — see coverage.