Message Structure
Structure and Content of Messages
Overview of the Message Structure
HTTP is used as transport layer for carrying ISO message payload. The HTTP header includes a unique transaction ID for a given request and some information related to the payload. The HTTP body contains the ISO Message Type, Bitmap and Data Elements encoded in base64.
HTTP Header
tid
Transaction ID. Unique ID of the request
header
Information about the request/response, as described below
HTTP Body
Payload
Base64 encoded ISO8583 (Message Type, Bitmap and Data Elements)
The payload includes information specified in the table below. Each part is detailed in this document.
1
4
Message Type
5
8
Primary Bitmap
13
variable
Data Elements (may include the secondary bitmap in field n° 1)
Header
The header is required in all messages. The header value is 8 bytes in length with the following format:
1
Request: Indicates the product associated with the message
'3' = Interface with an Acquiring Host (Card Present transaction with the issuer)
'4' = Interface with an Acquiring Host (Card Not Present transaction with the Issuer)
'5' = Interface with an Authorization HOST
Response: Value is echoed back
2–5
Request: Release & version of the protocol — 1000: version 1
Response: Value is echoed back
6–8
Request: Always set to 000
Response: When Cloud TSP rejects a message for format error, contains the number of the first erroneous data element. Otherwise 000.
Message Type
The message type is a 4-position element identifying the general function of the message. It is mandatory in all messages.
1100
Detokenization request to the Cloud TSP
1110
Detokenization request response from the Cloud TSP
1120
Transaction Advice communication to the Cloud TSP (re-tokenization)
1130
Transaction Advice communication response from the Cloud TSP (re-tokenization)
Primary Bitmap
The ISO 8583/1993-12-15 uses a message scheme by bits vector or "bit maps". The bitmap structure indicates the presence or absence of data elements (1 = present, 0 = absent). The bytes in the bitmap are numbered from left to right.
Each bitmap is 8 bytes length (64-bit string):
Primary bitmap — indicates the presence of fields 1 to 64.
Secondary bitmap — indicates the presence of fields 65 to 128. Its presence is signaled by bit 1 of the primary bitmap (leftmost bit).
In the current version of this document, the data elements referenced in the secondary bitmap are not used.
Example:
11 00→ Message type (detokenization request)72 04 66 00 08 61 82 01→ Bitmap
Bitmap in binary:
Leftmost bit = 0 → single bitmap. Each subsequent bit position corresponds to a data element number; 1 = present, 0 = absent.
0
1
1
1
0
0
1
0
...
1
...
Data Elements Fields Attributes
Type notations used for data elements:
a
Alphabetic characters A–Z and a–z
n
Numeric characters 0–9
an
Alphanumeric characters A–Z, a–z, 0–9
ans
Alphanumeric + space + special characters
ns
Numeric + space
b
Binary field
MM / DD / YY
Month / Day / Year
hh / mm / ss
Hour / Minute / Seconds
Fixed-length fields: type followed by length.
an-3→ 3 alphanumeric characters (e.g.ab8)n-5→ 5 digits (e.g.12345)
Variable-length fields: type followed by .. and max length.
an..25→ up to 25 alphanumeric charactersLLVAR= variable-length field using 2 digits for lengthLLLVAR= variable-length field using 3 digits for length
Data Elements Coding
Fixed-length fields
No length prefix is included. Only the field value is present in the ISO message.
Variable-length fields
A 1-byte hexadecimal length prefix is included, followed by the field value. Maximum length value is 255.
Numeric fields
BCD encoded. Length is expressed in nibbles (half-bytes). When length is odd, the leftmost nibble is zero-padded.
Example — Field 02 (PAN):
Alphanumeric fields
ASCII encoded. Length is expressed as a number of ASCII characters (bytes).
Example — Field 43 (Card Acceptor Name and Address):
Binary fields
Hex encoded. Length is expressed as a number of bytes.
Example — Field 55 (Chip Related Data):
Last updated
Was this helpful?