Every card tap — plastic, phone, or crypto card — triggers a message designed in the 1980s. ISO 8583 is the protocol that carries “can this person spend this much at this merchant” from a terminal to an issuer and back in a couple of seconds. This teardown shows what the message actually contains. If you want the higher-level tour first, start with how card authorization works. For the issuer-side checks, declines, and fallback rules, continue to Part 2.
Anatomy of an ISO 8583 message
An 8583 message has three parts:
- MTI (Message Type Indicator) — four digits classifying the message.
0100is an authorization request;0110is the response.0200covers financial transactions (like a purchase presentment),0400a reversal. - Bitmap — 64 or 128 bits declaring which data fields are present. Field 2 present? Its bit is set. This is how the format stays compact: only the needed fields travel.
- Data elements — the fields themselves, numbered and typed.
The fields that matter
A typical 0100 authorization request carries a subset of these:
| Field | Content | What it tells the issuer |
|---|---|---|
| DE 2 | PAN | Which account this is |
| DE 3 | Processing code | Purchase? Cash advance? Balance inquiry? |
| DE 4 | Amount | How much, in minor units |
| DE 7 | Transmission date/time | When the terminal sent it |
| DE 11 | STAN | A trace number tying request to response |
| DE 14 | Expiry | Card validity |
| DE 18 | MCC | What kind of merchant this is |
| DE 22 | Entry mode | Chip, contactless, magstripe, e-commerce |
| DE 25 | Condition code | Normal? Cardholder not present? |
| DE 35/45 | Track data | Magstripe or chip equivalent |
| DE 41 | Terminal ID | Which physical terminal |
| DE 42 | Acceptor ID | Which merchant |
| DE 49 | Currency | What currency the amount is in |
| DE 55 | EMV data | The chip’s cryptographic proof |
The issuer’s fraud engine reads this entire picture in milliseconds: DE 18 and DE 22 say a contactless tap at a grocery store; DE 4 says $43.12; velocity counters say third transaction today. Approve.
The 0110 response adds DE 39 (the all-important response code — 00 is approval; 05 is “do not honor”; 51 is insufficient funds) and, on approval, DE 38, the six-character authorization code printed on receipts.
The two worlds: single vs dual message
- Dual-message (the classic model): the
0100/0110authorization is message one; a separate clearing file, sent in batch later, is message two. Authorization reserves funds; clearing finalizes amounts. Pre-auths at fuel pumps and hotels live in this gap. - Single-message: authorization and financial presentment arrive together, common on some debit networks — the funds move with the approval.
Settlement then moves actual money between issuer and acquirer through the network’s settlement banks, typically next business day.
Why declines are usually DE 39, not “an error”
Most “card errors” users see are deliberate issuer decisions encoded in DE 39: 51 insufficient funds, 54 expired card, 57 transaction not permitted (often an MCC restriction — common with crypto cards on gambling or quasi-cash categories), 61 exceeds withdrawal limit, 91 issuer unavailable. Reading declines as data, not failure, saves a support ticket.
Where crypto cards attach
A crypto card program sits on the issuer side of this flow. When the 0100 arrives, the program’s systems check your stablecoin balance, price the conversion to fiat in real time, and answer 00 or 51 accordingly. The network, acquirer, and merchant see an utterly normal prepaid card. The blockchain part happens entirely behind DE 39.
Why this 40-year-old protocol still runs everything
Because it is compact, deterministic, and globally deployed — every terminal, every acquirer, every network speaks it. ISO 20022 is the modernized successor slowly spreading through banking, but for card authorization, 8583’s installed base is the standard. When you tap a card funded by a blockchain, the settlement asset may be new; the message asking permission is older than the web.
Try the interactive auth flow visualizer to watch this round trip animated, hop by hop. Then see Part 2 for what happens when the message reaches the issuer: balance checks, fraud scoring, decline codes, and stand-in processing.