Cards & Merchant Payments / Learning brief
Card authorization under the hood
Your notes
In simple terms / 01
What this means in plain language
The real-time round trip behind an approved card payment: the ISO 8583 authorization request and response legs, what the issuer checks before answering, the authorisation hold that reserves money without moving it, and stand-in processing when the issuer cannot answer at all.
Authorisation is the real-time question-and-answer at the start of every card payment. The merchant's terminal builds an authorization request — an ISO 8583 message, classically an 0100 — carrying the amount, card data, and the EMV chip's cryptogram. The acquirer forwards it into the network, which routes it to the issuer. The issuer checks the card's status, the available money, the authentication data, and its fraud rules, then answers with an 0110 authorization response: approved with an approval code, or declined with a reason. An approval places an authorisation hold — the cardholder's available balance drops so the money cannot be promised twice — but no money moves anywhere. If the issuer is unreachable, the network can answer on its behalf within pre-agreed limits (stand-in processing) and advise the issuer afterwards.
Key takeaways / 03
Three things to remember
- 01
Authorisation is two message legs — request out, response back — and one decision, made by the issuer alone.
- 02
An approval creates a hold on available balance; the booked debit and the merchant's money come later, in clearing and settlement.
- 03
A decline is a refused promise rather than a failed transfer, so nothing needs unwinding; stand-in processing keeps tills answering when the issuer is down.
Practical use cases / 04
Where you would use this
Reading terminal or gateway logs: matching request and response legs, approval codes, and decline reasons to explain what a customer saw.
Designing e-commerce retry logic that respects decline reasons instead of repeating requests the issuer will never approve.
Explaining to a cardholder why a cancelled hotel booking still reduces their available balance until the authorisation hold expires.
Worked example / 05
Put the idea into a real situation
Illustrative example (SYNTHETIC / TRAINING ONLY): Maya Chen taps her Bank Alfa card for EUR 3.80 at Demo Coffee Ltd. The terminal sends an 0100 authorization request through Meridian Bank into Cardnet — a fictional card network standing in for Visa- or Mastercard-style networks — which routes it to Bank Alfa. Bank Alfa verifies the chip cryptogram, sees sufficient funds, scores the risk as normal, and returns an 0110 authorization response with approval code 04117B. Maya's available balance falls by EUR 3.80; her booked balance is unchanged and Demo Coffee has received nothing yet. Had Bank Alfa been offline, Cardnet's stand-in service could have approved the small tap within Bank Alfa's pre-set limits and sent the issuer an advice message once it was reachable again.
Operational sequence / 06
Follow the message and decision path
This compact sequence is a learning model. Exact routing and rulebook behavior can vary by scheme, participant, and implementation.
Read the steps as text
- 01MessageMaya presents her cardMaya Chen (cardholder) → Demo Coffee Ltd (merchant terminal)
Maya taps her card for a EUR 42.50 catering order. The terminal reads the chip or contactless data defined by EMV (the chip-card standard maintained by EMVCo) — including a one-time cryptogram that proves a real card was present.
- 02MessageThe terminal builds and sends the authorisation requestDemo Coffee Ltd (merchant terminal) → Meridian Bank (acquirer) · 0100 authorisation request (ISO 8583)
The terminal packs the card data, amount and merchant details into an authorization request — a 0100 message in ISO 8583, the card industry's messaging standard — and sends it to Meridian Bank, the acquirer that serves Demo Coffee.
- 03MessageMeridian Bank forwards the request to CardnetMeridian Bank (acquirer) → Cardnet (card network) · 0100 authorisation request (ISO 8583)
The acquirer checks the merchant is one of its own and the message is well formed, then forwards the request into the card network. The acquirer cannot approve — only the card's issuer can say yes.
- 04MessageCardnet routes the request to Bank AlfaCardnet (card network) → Bank Alfa (issuer) · 0100 authorisation request (ISO 8583)
The network reads the bank identification number (BIN) — the opening digits of the card number — recognises Bank Alfa as the issuer, and delivers the request to it.
- 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.
- 06MessageBank Alfa approves and respondsBank Alfa (issuer) → Cardnet (card network) · 0110 authorisation response
The issuer answers with a 0110 response carrying an approval and an authorisation code — a short reference that will later tie the clearing record back to this exact approval.
- 07MessageCardnet relays the approval to Meridian BankCardnet (card network) → Meridian Bank (acquirer) · 0110 authorisation response
The network sends the response back along the same path it came. Request out, response back — one conversation, a few seconds end to end.
- 08MessageThe terminal shows approvedMeridian Bank (acquirer) → Demo Coffee Ltd (merchant terminal) · 0110 authorisation response
Meridian Bank passes the approval to the terminal. Maya sees 'approved'; Demo Coffee stores the authorisation code with the sale for tonight's clearing batch.
- 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
Evidence & review / 07
Evidence & review
Online authorisation on four-party card schemes, card-present and card-not-present; message dialects, decline codes, and stand-in parameters are scheme- and issuer-specific.
What this brief simplifies: Shows one online authorisation pair. Partial and incremental approvals, pre-authorisations, offline EMV approvals, tokenised flows, and scheme dialect differences are noted but not walked through.
Sources for this brief2
- 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.