> For the complete documentation index, see [llms.txt](https://docs.payments.thalescloud.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.payments.thalescloud.io/home/cloud-tsp-detokenization-api/message-structure.md). # 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** | Field | Description | | -------- | ---------------------------------------------------------- | | `tid` | Transaction ID. Unique ID of the request | | `header` | Information about the request/response, as described below | **HTTP Body** | Field | Description | | --------- | --------------------------------------------------------------- | | `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. | Offset | Length | Information | | ------ | -------- | -------------------------------------------------------------- | | 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: | Position | Content | | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 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. | Message | Description | | ------- | ------------------------------------------------------------------------------ | | `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 72 04 66 00 08 61 82 01 ``` * `11 00` → Message type (detokenization request) * `72 04 66 00 08 61 82 01` → Bitmap Bitmap in binary: ``` 0111 0010 0000 0100 (7204 hex) 0110 0110 0000 0000 (6600 hex) 0000 1000 0110 0001 (0861 hex) 1000 0010 0000 0001 (8201 hex) ``` Leftmost bit = `0` → single bitmap. Each subsequent bit position corresponds to a data element number; `1` = present, `0` = absent. | 2nd bitmap ind. | DE-02 | DE-03 | DE-04 | DE-05 | DE-06 | DE-07 | DE-08 | ... | DE-14 | ... | | --------------- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | --- | ----- | --- | | 0 | 1 | 1 | 1 | 0 | 0 | 1 | 0 | ... | 1 | ... | ### Data Elements Fields Attributes Type notations used for data elements: | Notation | Meaning | | ------------------ | ----------------------------------------- | | `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 characters * `LLVAR` = variable-length field using 2 digits for length * `LLLVAR` = 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):** ``` Attribute: n..19 Coding: 11 01 23 45 67 89 01 23 45 67 Length: 11 hex = 17 dec = 17 digits PAN: 1 2345 6789 0123 4567 ``` #### Alphanumeric fields ASCII encoded. Length is expressed as a number of ASCII characters (bytes). **Example — Field 43 (Card Acceptor Name and Address):** ``` Attribute: ans-55 Coding: 42 41 58 20 54 65 73 74 ... Value: "BAX Test / /Paris /FR " ``` #### Binary fields Hex encoded. Length is expressed as a number of bytes. **Example — Field 55 (Chip Related Data):** ``` Attribute: LLVAR b...255 Coding: 69 9f 02 06 00 00 00 00 21 00 ... Length: 69 hex = 105 dec ``` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.payments.thalescloud.io/home/cloud-tsp-detokenization-api/message-structure.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.