ISO 8583 is the international standard for the messages exchanged when a payment card is used. It defines how an authorization request, its response, a reversal and related messages are laid out, so that the systems of a merchant's bank, a card network and a cardholder's bank can understand each other. Nearly every card purchase and cash machine withdrawal in the world is carried, for at least part of its journey, in a message based on this standard.
The standard was first published in 1987 and revised in 1993, 2003 and 2023. It is a compact, binary-friendly format designed when network capacity was scarce and transactions had to complete in a second or two over slow lines. It is distinct from ISO 20022, the XML-based standard used for bank transfers and securities, which carries far richer data and is gradually being adopted for some card flows.
Structure of a message
An ISO 8583 message has three parts in a fixed order.
- Message type indicator. Four digits state the version of the standard, the class of message, its function and who originated it.
- Bitmap. A string of bits in which each position corresponds to one numbered field. A bit set to one means the field is present. The primary bitmap covers fields 1 to 64; if its first bit is set, a secondary bitmap follows for fields 65 to 128.
- Data elements. The fields themselves, in numerical order. Each has a defined format: numeric or alphanumeric, fixed length or variable length with a prefix giving the length.
The bitmap is what makes the format efficient. A message contains only the fields it needs, and the receiver knows exactly where each one begins without any labels being sent.
Message types
The message type indicator tells the receiver what kind of exchange is taking place. In the widely used 1987 version, a request for payment authorization is type 0100 and the reply is 0110. Type 0200 and its response 0210 are financial transaction messages, used where a single message both authorizes and posts the transaction, as with most automated teller machine withdrawals. A reversal uses the 0400 series, and the 0800 series covers network management such as sign-on, key exchange and echo tests that confirm a link is alive.
Requests and responses are matched by fields the receiver echoes back, chiefly the system trace audit number and the transmission date and time.
Key data elements
A typical authorization request carries the card number in field 2, a processing code in field 3 that identifies the kind of transaction and account, and the amount in field 4. Other fields give the card's expiry date, the merchant's merchant category code, how the card was read, the terminal and merchant identifiers, the merchant's name and location, and a retrieval reference number used to find the transaction later. Currencies are given as numeric ISO 4217 codes and countries as numeric ISO 3166 codes.
Security data travels in dedicated fields. The encrypted block containing the cardholder's PIN has its own field, and the cryptogram and related data produced by an EMV chip are packed into field 55. The response returns an approval code and, in field 39, a two-character response code: 00 for approval, other values for the various kinds of decline. These are the origin of the decline code that merchants see.
How messages travel
When a card is presented at a point of sale, the terminal or gateway sends the transaction to the acquirer or its processor, which builds the request in the format of the relevant card network and sends it to the network's switch. The network routes it to the card issuer or the issuer processor, which checks the account and returns a response along the same path. If the issuer cannot be reached in time, the network may answer on its behalf under stand-in processing.
Connections are long-lived links over private networks, with each message preceded by a length header. In dual-message systems, used for most credit card purchases, the real-time authorization is followed later by a separate clearing record sent in batch files, whose formats also derive from the standard. A payment switch inside a bank or processor translates between the dialects of the different networks it connects to.
Dialects and limitations
ISO 8583 is better described as a framework than as a single interoperable format. The standard leaves many fields for national or private use, and each network publishes its own specification saying which fields are required, how they are encoded and what the private fields contain. A message built for one network cannot be sent to another without conversion, and integrating with a new network means implementing and certifying against its specification.
Encoding adds to the variety: numeric fields may be packed in binary-coded decimal or sent as characters, and text may be in ASCII or EBCDIC. The fixed set of fields makes it awkward to add new data, so features such as tokenization, authentication results and wallet identifiers have been fitted into private fields and nested sub-elements.
These limits explain the interest in ISO 20022 for cards and in JSON-based APIs for newer payment products. Even so, the installed base of terminals, switches and issuer systems is very large, and ISO 8583 remains the working language of card authorization.