ISO 8583 is the message standard behind card authorizations between terminals, acquirers, networks and issuers. This page explains how to read a message and lists the fields and codes you will meet most often.
Paste a message into the free decoder to see it broken down field by field.
Open the ISO 8583 decoder →Every message has three parts, in order: a four-digit Message Type Indicator (MTI), one or two bitmaps, and the data elements that the bitmap marks as present. The bitmap is what makes messages compact: only fields that are used are sent.
The standard defines up to 128 data elements (192 with a tertiary bitmap). Each element has a type and length rule, such as fixed length, LLVAR (two-digit length prefix) or LLLVAR (three-digit length prefix). Networks and acquirers then publish their own specifications, so two hosts can use the same field number differently.
The MTI is four digits and each digit means something. Read it left to right.
| MTI | Name | Typical use |
|---|---|---|
| 0100 | Authorization request | Acquirer asks the issuer to authorize an amount |
| 0110 | Authorization response | Issuer answer to a 0100 |
| 0200 | Financial transaction request | Request that posts funds, such as a purchase or withdrawal |
| 0210 | Financial transaction response | Issuer answer to a 0200 |
| 0400 | Reversal request | Acquirer reverses a previous transaction, for example after a timeout |
| 0410 | Reversal response | Answer to a 0400 |
| 0420 | Reversal advice | Notification that a reversal was applied |
| 0430 | Reversal advice response | Acknowledgement of a 0420 |
| 0500 | Reconciliation request | Totals exchanged to settle a period |
| 0800 | Network management request | Sign-on, sign-off, echo test, key exchange |
| 0810 | Network management response | Answer to a 0800 |
The primary bitmap is 64 bits, sent as 8 bytes or 16 hex characters. Bit n set to 1 means data element n is in the message. If bit 1 is set, a secondary bitmap follows (another 64 bits) and covers elements 65 to 128. A 32-character hex bitmap therefore means primary plus secondary.
Example: a primary bitmap that starts with hex 7 has bits 2, 3 and 4 set, so the PAN, processing code and amount follow in that order. The decoder expands any bitmap you paste and labels each element.
These are the fields you will see in most card-present authorizations. Formats follow the 1987 edition; your network may differ.
| DE | Name | Format |
|---|---|---|
| 2 | Primary account number (PAN) | LLVAR, up to 19 digits |
| 3 | Processing code | 6 digits |
| 4 | Transaction amount | 12 digits, minor units |
| 7 | Transmission date and time | MMDDhhmmss |
| 11 | System trace audit number (STAN) | 6 digits |
| 12 | Local transaction time | hhmmss |
| 13 | Local transaction date | MMDD |
| 14 | Expiration date | YYMM |
| 18 | Merchant category code | 4 digits |
| 22 | POS entry mode | 3 digits |
| 23 | Card sequence number | 3 digits |
| 25 | POS condition code | 2 digits |
| 35 | Track 2 data | LLVAR, up to 37 characters |
| 37 | Retrieval reference number | 12 characters |
| 38 | Authorization identification response | 6 characters |
| 39 | Response code | 2 characters |
| 41 | Card acceptor terminal ID | 8 characters |
| 42 | Card acceptor ID code | 15 characters |
| 43 | Card acceptor name and location | 40 characters |
| 49 | Transaction currency code | 3 digits |
| 52 | PIN data | 8 bytes, encrypted |
| 54 | Additional amounts | LLLVAR |
| 55 | ICC data (EMV chip data) | LLLVAR, BER-TLV, network specific |
| 64 / 128 | Message authentication code (MAC) | 8 bytes |
Data element 55 carries EMV chip data as BER-TLV. Decode it with the EMV TLV parser, and look up application identifiers with the AID decoder.
The processing code has three two-digit parts: transaction type, from-account type and to-account type. Account types are commonly 00 unspecified, 10 savings, 20 checking and 30 credit. For example, 003000 reads as type 00 (purchase), from account 30 (credit), to account 00 (unspecified).
| Type (digits 1-2) | Meaning |
|---|---|
| 00 | Purchase of goods or services |
| 01 | Cash withdrawal |
| 09 | Purchase with cashback |
| 20 | Refund or return |
| 21 | Deposit |
| 30 | Balance inquiry |
| 40 | Cardholder account transfer |
Data element 39 tells the terminal what the issuer or host decided. These are the codes you will see most. Networks add their own, and the meaning of a code can differ slightly by network, so treat this as a starting point and confirm against your specification.
| Code | Meaning |
|---|---|
| 00 | Approved |
| 01 | Refer to card issuer |
| 03 | Invalid merchant |
| 05 | Do not honor |
| 12 | Invalid transaction |
| 13 | Invalid amount |
| 14 | Invalid card number |
| 30 | Format error |
| 41 | Lost card, pick up |
| 43 | Stolen card, pick up |
| 51 | Insufficient funds |
| 54 | Expired card |
| 55 | Incorrect PIN |
| 57 | Transaction not permitted to cardholder |
| 58 | Transaction not permitted to terminal |
| 61 | Exceeds withdrawal amount limit |
| 62 | Restricted card |
| 65 | Exceeds withdrawal frequency limit |
| 75 | Allowable PIN tries exceeded |
| 91 | Issuer or switch inoperative |
| 96 | System malfunction |
ISO 8583 is the international standard for financial transaction card messages. It defines how terminals, acquirers, networks and issuers exchange authorization, financial, reversal, reconciliation and network management messages. A message is a Message Type Indicator (MTI), one or more bitmaps, and the data elements the bitmap says are present.
The Message Type Indicator is four digits. The first digit is the ISO 8583 version (0 is the 1987 edition), the second is the message class (1 authorization, 2 financial, 4 reversal, 5 reconciliation, 8 network management), the third is the function (0 request, 1 request response, 2 advice, 3 advice response) and the fourth is the originator (0 acquirer, 2 issuer). For example, 0200 is a financial request and 0210 is its response.
The primary bitmap is 64 bits that mark which of data elements 1 to 64 are present. If bit 1 is set, a secondary bitmap follows and covers elements 65 to 128. A 16-character hex bitmap is the primary alone; 32 characters means primary plus secondary.
Data element 3 is a six-digit processing code. The first two digits are the transaction type (for example 00 purchase, 01 cash withdrawal, 20 refund, 30 balance inquiry), the next two are the from-account type and the last two are the to-account type (00 unspecified, 10 savings, 20 checking, 30 credit). Exact values vary by network and acquirer specification.
Data element 39 carries the issuer or host response. 00 means approved, 05 do not honor, 14 invalid card number, 51 insufficient funds and 91 issuer or switch inoperative, among many others. Networks add their own codes, so always confirm against the specification for your acquirer or network.
Chip data is carried in data element 55 as BER-TLV. Networks define which tags are required in requests and responses. You can decode the contents with the EMV TLV parser.
No. ISO 8583 is a framework. Each network and acquirer publishes its own specification with its own field formats, private-use fields (such as 48, 60 and 63), encodings and response codes. That is why integrating with a new host is a project, and why host messages are part of every EMV Level 3 certification.
Host message formats are part of every EMV Level 3 project, and every new processor has its own variations. Paying.co builds and certifies against acquirer and network specifications. See our EMV Level 3 certification services, platform and host integrations and Foundry, our reusable certification framework. More free tools are at paying.co/tools.