ISO 8583 is described as the “workhouse of legacy retail payments” and has been in wide use since the 1980’s to support card-based financial transactions. ISO 8583 is by far the dominant messaging standard used by financial institutions, card networks, card issuers, acquirers and merchants to exchange retail payment messages.
The ISO 8583 standard is officially titled “Financial Transaction Card-Originated Messages — Interchange Message Specifications”.
ISO 8583 specifies message structure, format and content, data and values of data elements. It is the most widely used standard for financial industry messaging, but it is also the most widely modified and customized.
Whenever a transaction is conducted ie. a card is swiped or cash withdrawn at an ATM, the transaction involves data transfer between different parties i.e. acquirerAcquirer (or Acquiring bank) Acquirer (or Acquiring bank) A bank or a financial institute, which acquires funds for its merchant from a shopper. To accept card payments, an acquirer should be licensed by corresponding card networks and either partner with a payment processor, or be a payment processor itself. , issuerIssuer Issuer (or Issuing bank) A bank that issued a card for a shopper to make cashless payments via an ecommerce website, inside a mobile app, or in a physical store. To be able to issue a card, an issuer must be a member of one or several card networks. Sometimes a shopper’s bank is referred to as an issuer even if there is no card issued. This is to distinguish between a shopper’s bank, which sends funds, and a merchant’s bank, which acquires funds., merchant, and customer using ISO 8583 data elements, messages and code values. The data interchange that takes place between different systems needs to follow standard formats for integration, exchange and interoperability.
The transaction carries information about the type of transaction, the card used, the merchant, the transaction amount, security information etc. The response, authorizing or declining the transaction, needs to be returned via the same route to the terminal.
ISO 8583 specifies message structure, format and content, data element and values of data elements. Application specification may remain at the private level (implementer) and the method (message) by which settlement takes place is not within the scope of ISO.
Cardholder-originated transactions include purchase, withdrawal, deposit, refund, reversal, balance inquiry, payments and inter-account transfers. ISO 8583 also defines system-to-system messages for secure key exchanges, reconciliation of totals, and other administrative purposes.
In particular, both Master Card and Visa networks base their transactions on the ISO 8583 standard, as well other institutions and networks.
Header – This part is network specific, and shows Institution Identification Codes (IICs) The Institution Identification Code explains why Mastercard and Visa use different message header structure.
The header can be optionally zero padded. It typically shows the size of the message, (which is known in advance by the recipient), but it can also contain information about the size of header plus the size of message.
An example of a header is 0158 which depicts the content of the message (mti+bitmap+data elements) is 158 bytes
Message Type Indicator (MTI) – A message type indicator includes which version of ISO 8583 is being used, as well as the message class, the message function and the message origin. The MTI consists of four numerical parts that identify the specific version of the ISO8583.
Three versions of the standard exist in 1987, 1993, and 2003. The combination of the four MTI fields specifies the type of interchange message that is being transmitted.
Typically, applications use the Message Type Indicator to determine whether the message requires a response and the format of the response.
Digit 1 indicates the version of ISO 8583
Digit 2 indicates the class of the message
Digit 3 indicates the function of the message
Digit 4 indicates who initiated the communication
For instance, with a Message Type value of 0110, the following example lists what each position indicates:
- 0xxx → version of ISO 8583 (0 = 1987 version)
- x1xx → class of the message (1 = authorization message)
- xx1x → function of the message (1 = response)
- xxx0 → who began the communication (0 = acquirer)
This means that MTI 0110 is an authorization response message stating that the actual financial transaction was originated by the acquirer.
Bitmaps – A bitmap is a field or sub-field contained in a message, which indicates whether there are other data elements or data element sub-fields somewhere else in the message.
Each message class can have one or more bitmaps, and each message always includes a primary bitmap which contains individual bits that indicate which of the fields are present in the specific message. The primary bitmap specifies whether fields 1 – 64 are present.
If there is also a secondary bitmap in the message, it indicates whether fields 65 – 128 exist.
Bitmap Example:
Data elements or fields – Message data elements are defined by the ISO 8583 protocol, and each individual data element contains the information for that specific transaction and each has a specified meaning.
The data elements and code values relating to the transaction, includes amounts, times, dates, and country codes. Organizations that use ISO 8583 may sometimes customize these fields.
There are also some general purpose data elements included in ISO 8583, as well as some system-specific data elements that are used in different ways by various standards that have derived from ISO 8583.
Example 1 : Bit value 2 is assigned to primary account number, Bit 3 is assigned to processing code, Bit 4 is for transaction amount, etc.
Example 2: x + n Numeric (amount) values, where the first byte is either ‘C’ to indicate a positive or credit value, or ‘D’ to indicate a negative or Debit value, followed by the numeric value (using n digits)
Each data element is set out in a standard format which defines:
- The permitted content of the field (for example, binary or numeric values ).
- The field length (fixed or variable). If it’s variable, the length of the field is preceded by a length indicator.
The message formats specified in the ISO 8583 protocol are designed to ensure that the systems conforming to this standard are always compatible.
Binary data
In data structures, packed binary data usually signifies that there are more bit combinations used to encode the message. Unpacked signifies that some bit combinations remain unused. This is usually to make it more readable. To summarize, ISO 8583 defines two different encoding methods:
- Packed – or 8 bytes of data
- Unpacked – or 16 bytes as hexadecimal characters
The following is a table specifying the code values message format and service captureCapture Capture (or Clearing and settlement) A payment that has been authorised by the payment processor must be captured to be completed. Capturing is the act of transferring the reserved funds from the shopper to the merchant. By default, payments are captured automatically, immediately after authorisation. Many payment methods support separate authorisation and capture. This means as a merchant you can set up a capture delay; capture payments manually; perform partial captures; or cancel an authorisation. code for each transaction type.
Service entry mode value
The Point Of Service (POS) entry mode value has 2 parts:
- PAN entry mode value – the first 2 digits
- PIN entry capability – the third digit
The following table shows PAN entry modes and their meanings.
Credit Card Issuer Response Codes
An authorization request on a credit card can be denied for a variety of reasons, often with a different financial request issuer response on each occasion.
The process of passing network specific details throughout the transaction life-cycle is complicated, with many aspects to consider. From advice response messages to authorization advice confirmation, secure key exchange to country specific data elements and data element subfields, it’s a lot for merchants and acquirers to take in.
An abbreviated section of the following table shows response codes and meanings:
