What is the mechanism behind ISO 8583, the standard for messages communicated between acquirers and issuers when using credit cards?
by
When you use a credit card to make a purchase at a store, information from the store's payment terminal is first sent to the merchant contracting company ( acquirer ), which then transmits it through the card network to the card issuing company ( issuer ), who then decides whether to approve or deny the transaction. ISO 8583 is a standard for real-time messages exchanged between acquirers and issuers in major card networks.
ISO 8583: The language of credit cards — Increase
https://increase.com/articles/iso-8583-the-language-of-credit-cards
The card transactions we carry out every day, such as making a touch payment at a store or clicking the 'purchase' button when shopping online, are exchanged as 'messages' between the merchant's acquiring processor, the card network, and the customer's bank's issuer processor. These messages can only be sent and received between parties that have shared specifications.
In ISO 8583, a message basically consists of three elements: a message type indicator (MTI), a bitmap, and a data element.
The MTI is a four-digit number that indicates what type of message it is and is used by the receiver to predict which fields will or will not be present in the message.
A bitmap is a map that indicates which fields are present and which are omitted in a message: each bit is 1 to indicate that the field is present, and 0 to indicate that it is absent. This bitmap allows the recipient to parse messages of variable length accurately.
The data elements are the actual field values arranged in order, such as card number in field 2, processing code in field 3, transaction amount in field 4, etc. Each field can be fixed or variable length and is arranged in the order indicated by the bitmap.
There are three ways to represent the fields contained in this message and the sub-fields that make up the fields: the table format, the nested bitmap message format, and the TLV (Tag-length Value) format.
The table format is the simplest format. For example, the following is an image of field 43, which shows the name and address of the store where the card was used, and consists of 40 bytes. Of the 40 bytes, the first 25 bytes are the location information of the place where the card was used, 13 bytes are the city name, and 2 bytes are the country name.
The following diagram shows the structure of field 54, which indicates the additional amount. Field 54 can contain up to three 20-byte fixed-length subfields, each of which is divided into account type (navy blue), amount type (blue), currency code (green), amount sign (yellow), and amount (pink). This additional amount field 54 can store multiple amounts related to one transaction.
In the table method, each field is fixed length, and if there is no value, it is filled with a default value or placeholder. Therefore, even if the field is empty, it requires a fixed amount of space, which is inefficient. Therefore, 'telescoping' was adopted, which makes the field variable length by including only the necessary elements.
Below is a diagram of field 43 written using telescoping. The top one is 25 bytes long and contains only location information, the second one is 38 bytes long and contains only location information and city name, and the third one is 40 bytes long and contains location information, city name, and country name. There is also a length indicator (green) at the beginning of the field.
However, telescoping is a mechanism that omits all subsequent elements, so the order of elements is fixed and intermediate elements cannot be omitted. Therefore, although it is possible to transmit data efficiently, it is not a flexible structure.
In ISO 8583, fixed-length and variable-length fields can be combined. For example, the following figure shows the length of a message, where field 1 and field 2 are fixed length, and field 3 is variable length. There is also an indicator at the beginning of the message.
Additionally, there is a format used for data efficiency called 'nibble tables' - a nibble is half a byte = 4 bits, and one byte contains two nibbles.
Normally, numbers are stored using 1 byte = 8 bits. However, if many items can be expressed as single digit numbers, using an entire byte is inefficient. In a nibble table, the value of each item is stored one nibble at a time. In other words, one item is stored in the first 4 bits of a byte, and another item is stored in the last 4 bits. Using a nibble table can halve the data size of a message, but it also has the disadvantage of making data
Although tables are less flexible, they offer a good compromise between simplicity and efficiency. In fact, the American Express network makes extensive use of them.
The nested bitmap message format places another bitmap before the field, this one indicating which subfields are present: just as a bitmap for the message as a whole indicates the presence of a field, the bitmaps in the nested bitmap message format indicate the presence of subfields.
The advantages of the nested bitmap message format are that it saves data size by eliminating the need to store non-existent subfields, it makes the presence or absence of subfields clearer, making it easier to distinguish between empty and missing values, and it preserves backward compatibility by allowing
However, the nested bitmap message format is complex to implement, and there are large differences in implementation between networks, so adding new fields must be done carefully. Nevertheless, it provides much more flexibility and extensibility to messages, so VISA and China UnionPay networks have adopted the nested bitmap message format.
In the TLV format , each subfield is represented by three elements: tag, length, and value. The tag is an identifier for the subfield, usually a number. The length indicates the number of bytes in the value of the subfield. And the value is where the actual data is stored.
The main feature of the TLV format is that the order of the fields can be arbitrary. The data set tag at the beginning of the format tells you what each field represents, so they do not need to be in order. It is also highly extensible because adding a new subfield does not require changing the existing subfields, but simply assigns a new tag.
The TLV format is mainly used in the Mastercard network, and other card networks are gradually migrating to the TLV format. It is expected that the TLV format will become the mainstream of ISO 8583 in the future.
In ISO 8583, when multiple messages are sent in succession, a mechanism called 'framing' is used to indicate the boundaries between messages.
ISO 8583 messages are usually sent over long-term TCP sockets. Therefore, the receiver must correctly extract each ISO 8583 message from the TCP data stream. To do this, a 4-byte value called the 'message length indicator' is placed at the beginning of the message. Some card networks, such as VISA, also include meta information such as the message origin and delivery destination between the message length indicator and the message body.
Error handling is a very important consideration when implementing a message parser for ISO 8583. In particular, merchants, who are the acquirer's processors, need to be able to properly process messages from various issuers. Even if the message format is not fully compliant, it is required to properly handle errors and continue processing as much as possible.
For example, if an unimplemented tag appears in the TLV format, it is recorded and processing of the entire message continues. Also, if an unknown value or error occurs in a subfield, it treats that part as a partial error and proceeds to parse the next field, minimizing the impact on other data processing. When reconstructing data in the erroneous part, it fills in spaces or zeros to maintain the consistency of the message.
On the other hand, serious errors at the top level, such as failure to parse a length indicator, will abort processing of the entire message, preventing further problems from using incomplete data.
Distinguishing between fatal errors and recoverable errors and dealing with each appropriately is the basic principle for operating ISO 8583. This design makes it possible to limit the impact of errors while still making use of as much data as possible.
Related Posts:
in Software, Posted by log1i_yk