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 transactionsTransactions transactions Interactions where value is exchanged for goods or services.. 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 acquirer A financial institution or payment processor that manages the merchant account, enabling businesses to accept card payments. Acquirers receive all transactions from the merchant and route them to the appropriate issuing bank., issuerIssuer issuer A bank or financial institution that issues payment cards to consumers. Responsible for authorizations and chargebacks., merchantMerchant merchant An individual or business that accepts payments in exchange for goods or services., 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, securitySecurity security Measures used to protect transaction data from fraud and cyber threats. 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 settlementSettlement settlement The process of transferring funds from the issuer to the acquirer. takes place is not within the scope of ISO.
CardholderCardholder cardholder The person or business to whom a payment card is issued.-originated transactions include purchase, withdrawal, deposit, refund, reversal, balance inquiryBalance Inquiry balance-inquiry A request made by a cardholder to obtain the current available balance on their account., 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 VisaVisa visa A leading global payment technology company connecting consumers, businesses, and banks. 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 MastercardMasterCard mastercard A global payments network enabling electronic transactions between banks, merchants, and cardholders. 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 = authorizationAuthorization authorization The real-time process of verifying that a payment method has sufficient funds or credit limit for a transaction. Results in an authorization code from the issuer. 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 The act of finalizing an authorized payment. Funds are transferred from the cardholder’s account to the merchant. code for each transaction typeTransaction Type transaction-type Classifies transactions as sale, refund, reversal, etc..
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:
