ISO8583 payments message format, programmers guide

Posted on 13th Dec 2018 11615 views

There is plenty of documentation about ISO8583 out there on Wikipedia, so making that again does not make sense. However, I want to have a different approach, more pragmatic and more programmatic.

1 What it is

An ISO8583 message is, from a developer's point of view, a TCP/IP message containing a number of bytes. Given that is it a TCP/IP message, it will have 2 bytes of data at the beginning, to specify the length of the message to follow. Then the message, with the length as specified in the 2-byte header. We will refer to this body as the message, from here on.

2 How it looks

It looks like an array of bytes. After the 2-byte TCP header mentioned above, the message starts.

From here on, we expect this structure of data:

1. A fixed-length header split into several fields, and this is optional. The documentation should specify it, if it exists.

2. A bitmap of 16 bytes, in general. This bitmap is a 8, 16, or 32 byte array which needs to be converted into its binary form. We end up with a binary array like 01101010010001... Later I will tell you how to read it.

3. A succession of fields usually called "Data Elements", numbered from 2 to 128 , which, as the name says, carry the data of the message.

That's it, this is how the message looks like in its most common form, and it ends after the length specified by the TCP header.

3 How you read ISO8583 messages from the network

1. You read the TCP header, 2 bytes. That tells you how many bytes to read in the message, like 552 bytes.

2. Read the 552 bytes of data, parse the message.

3. Repeat steps 1-2 forever;

4 How you parse ISO8583 messages

We are talking about the 552 bytes in the example above. You start parsing that info.

1. Header - it is optional and fixed length. If it exists, you need to read a fixed number of bytes into it, like 10 bytes. This usually does not exist.

2. Message Type. Fixed length, 4 bytes, most of the time. Read that.

3. Bitmap. It is fixed length 16 bytes, most of the time. Read that, get the binary value. Interpret it according to the paragraph below. This will tell us to read fields 2, 3, 4, 7, 8, 11, 12, 18, ....

4. Read the fields of the message, the ones specified by the bitmap, like the example above.

That is it you get the data in the fields.

5 Reading the bitmap of the message

Let's say you have this bitmap array that you obtain by converting the bitmap bytes read, into its binary representation: 011110010100010001110001111...

Simplistically, you read it like this:

Position 1, value is zero, means that there will be no field at position 1;

Position 2, value is one, means that there will be a field at position 2; We must read Field 2

Position 3, value is one, means that there will be a field at position 3; We must read Field 3

Position 4, value is one, means that there will be a field at position 4; We must read Field 4

Position 5, value is zero, means that there will be no field at position 5;

Position 6, value is zero, means that there will be no field at position 6;

Position 7, value is one, means that there will be a field at position 7; We must read Field 7

And so it goes until 128.

6. Reading the ISO8583 fields

As we are reading the bitmap above, we know which fields to read or not read.

Read Field 2. We know from the specification document how it looks like. Usually it is LLVAR. This means 2 byte length[LL], and then the value [VAR] so it is like 161234567890123456. We read this as 16 length, followed by the value: 1234567890123456. Done, next.

Read Filed 3. We know from the specification document how it looks like. Usually it is Fixed 6. This means 6 bytes, fixed. Next

Read Field 4. We know from the specification document how it looks like. Usually it is Fixed 12. This means 12 bytes, fixed. Next

Read Field 7. See, we skipped 5 and 6 because the bitmap said they are not present. We know from the specification document how it looks like. Usually it is Fixed 7. This means 7 bytes, fixed. Next

And so we go until Filed 128.