As a payment gateway, one of Omise’s key operations is to communicate with payment providers and networks every time a charge request is made. As we offer many payment options to our merchants, the payment source varies; from a Visa card, an Alipay account, to a TrueMoney Wallet account, to name a few.

While newer systems may provide an HTTP/REST API through JSON, a lot of older systems require us to use technologies that many developers haven’t even heard of. Such technologies include ISO8583 messages. ISO8583 messages are used by many financial institutions and core banking systems as a means to send and receive all necessary data when a card transaction occurs. If you have used your card to withdraw money from an ATM or to make purchases at a POS terminal, there’s a high chance that ISO8583 messages were exchanged in the process.

In this article, we will break down the elements of an ISO8583 message and give an example with actual values for you to better understand.

The general structure of an ISO8583 message

An ISO8583 message is made up of three main parts:

Message Type ID (aka MTI): What kind of message are we sending? Here are some examples:

• 0100 — Authorization request
• 0110 — Authorization response
• 0400 — Reversal request
• 0410 — Reversal response

Bitmap: ISO8583 messages have a predefined set of data fields that can be sent. The bitmap is the representation of which data fields are present in the message and is crucial for the receiver to parse the message.

Data Fields: The actual values of the data fields we are passing.

Example

Note: In this example, we have simplified the structure and rules of the message to make it more digestible.

Alice is shopping online and wants to buy a hat from TheHat.com with her Visa card. TheHat.com uses Omise as a payment gateway. As Omise receives the transaction data from TheHat.com, the first step to charging Alice’s card for the purchase is to request approval from Alice’s bank through what is called an Authorization Request. This is where ISO8583 messages are exchanged between Omise, the Visa network, and Alice’s bank.

In order to make the payment between Alice and TheHat.com possible, Omise will collect the transaction data e.g., the card number, the charge amount, and the currency of the transaction. This transaction data (along with other Visa specific data) will then be sent to the Visa network via an ISO8583 message for an authorization request. Visa will then route the request to Alice’s bank for approval.

Building the three main parts of the ISO8583 message that represents our authorization request:

MTI

The message type, in this case, is an “authorization request” which is represented by the code 0100.

Data Fields

Here are the necessary data fields to send:

As shown in the last column of the table above, each value needs to be encoded first. Here are the rules used in our example:

• Data fields with a variable-length have a prefix with the length of the field expressed in hexadecimal
• Odd-length values are right-justified with a 0
• ANS fields are encoded using EBCDIC

Bitmap

The bitmap consists of 64 bits positioned from left to right. Each bit denotes the presence (1) or absence (0) of a given field. For instance, if the message includes Field #2 (Primary Account Number) then the second bit of the bitmap will be one.

Here’s is the bitmap of our message:

Most networks and financial institutions use a hexadecimal representation of the bitmap as follows:

723C600100808000

The final part is to put everything together. For most networks, it consists of concatenating the MTI, Bitmap, and Data fields altogether. In our example it will be:

Once the message is assembled, Omise will then send this message to the network which will ultimately be read by Alice’s bank. As we have detailed in this article, the message contains all the data necessary for Alice’s bank to verify whether Alice has sufficient available funds on the card and approve the transaction accordingly.

For more interesting articles, please visit our website here.