> 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/request-validation.md). # Request Validation ## Requests Validation by Cloud TSP TSP performs a number of verifications upon reception of 1100 and 1120 request messages using information available at the TSP level. ### TSP Database When processing a message request, the TSP uses as a database either: * **Token Information** stored in the token vault, or * **Transaction History File** — logs information related to transactions previously detokenized in the last 18 months. Retrieval from the Transaction History File is performed using an index composed of: `Retrieval Reference Number (field 37)` + `Transaction Date and Time (field 07)` from the original transaction. #### 1100 – Detokenization Request The TSP can process two types of de-tokenization requests: * **Type 1** – New transaction: detokenization based on token vault data. Processing Code (field 03) positions 1–2 always equal `00` (purchase). * **Type 2** – Already performed transaction: detokenization based on TSP Transaction History File. Processing Code positions 1–2 equals one of: * `20` – Refunds * `22` – Credit reversal * `52` – Credit – return of goods * `92` – Confirmation of a pre-authorization > **Note 1:** For Type 2 transactions, the presence of field 55 in the detokenization request is optional even for chip transactions. > > **Note 2:** 1100 is optional for these use cases. The 1120 message (Advice) can be sent without 1100 if detokenization (PAN knowledge) is not required. #### 1120 – Transaction Advice (Re-tokenization) The TSP looks up a detokenization request in the TSP Transaction History File using the `TDT+RRN` value as transaction ID. The token tied to that transaction ID is used to look up the PAN in the token vault. TSP checks that the PAN in the token vault matches the PAN in the 1120 Advice message; otherwise an error is returned in the Advice response. *** ### HCE Verification Flow (1100) > Applies to any digital wallet based on Host Card Emulation (HCE) framework with software security measures such as single-use keys. This includes Samsung Pay, Google Pay, and proprietary HCE wallets. | Step | TSP Check | Field (02, 14, 35) | Field 39 | | ------------------------------------------ | ---------------------------------------------------------------------- | ------------------ | --------------- | | **1 – General Message Structure Checks** | | | | | 1.1 | Authorize client (mutual TLS / IP whitelist) | — | No message body | | 1.2 | Well-formed HTTP request (mandatory HTTP headers) | — | No message body | | 1.3 | Validate header | — | No message body | | 1.4 | Parse ISO request | — | No message body | | 1.5 | Validate processing code | — | No message body | | 1.6 | Find correct handler by MTI and processing code | — | No message body | | **2 – 1100 Message Checks** | | | | | 2.1 | Parse 1100 message | — | No message body | | 2.2 | Validate 1100 message | As request value | `006` | | 2.3 | Verify MAC | — | No message body | | **3.1 – Token Value Check** | | | | | 3.1.1 | Is VC known for given DPAN in token vault | As request value | `003` | | 3.1.2 | Is requestor authorized to access DPAN | As request value | `003` | | 3.1.3 | Validate issuer, VC and card (status active) | As request value | `003` | | 3.1.4 | Validate that VC and card have not expired | As request value | `001` | | **3.2 – PURE Transaction Data Validation** | | | | | 3.2.1 | Validate format and version of field 55 | PAN or Req (\*) | `015` | | 3.2.2 | Validate ATC is not outside the ATC window (see note below) | PAN or Req (\*) | `030` | | 3.2.3 | Validate SUK key is associated to key index in Issuer Application Data | PAN or Req (\*) | `014` | | 3.2.4 | Validate ARQC cryptogram | PAN or Req (\*) | `005` | | 3.2.5 | Optional (QR code only): Validate ARQC validity period | PAN or Req (\*) | `016` | | 3.2.6 | Validate if CDCVM cryptogram should be present (CVR\[2]\[8-6] = `100`) | PAN or Req (\*) | `020` | | 3.2.7 | Check CDCVM cryptogram when stamp is different from `0000000000000000` | PAN or Req (\*) | `021` | | 3.2.8 | Validate that Cloud PIN stamp is not used (CVR\[2]\[8-6] = `011`) | PAN or Req (\*) | `029` | | 3.2.9 | RFU: Validate if Cloud PIN stamp should be present | PAN or Req (\*) | `024` | | 3.2.10 | RFU: Check Cloud PIN stamp | PAN or Req (\*) | `025` | | 3.2.11 | Message verified OK | PAN | `000` | **ATC Window Check Logic (step 3.2.2):** * IF (TCC in DE48 equals `X`) AND (MCC in DE18 is a Transit value), THEN apply **ATC negative window**: * Check: `Previous value + ATC negative window < ATC < Previous value + ATC window` * ELSE, apply **positive window**: * Check: `Previous value < ATC < Previous value + ATC window` *** ### Secure Element-Based Verification Flow (1100) Steps 1 through 3.1 are identical to the HCE flow above. | Step | TSP Check | Field (02, 14, 35) | Field 39 | | ------------------------------------------------------ | ------------------------------------------------------------------ | ------------------ | -------- | | **3.2 – Apple Pay Applet Transaction Data Validation** | | | | | 3.2.1 | Validate format and version of field 55 | PAN or Req (\*) | `015` | | 3.2.2 | Validate ATC is not outside the ATC window (same logic as HCE) | PAN or Req (\*) | `030` | | 3.2.3 | Validate key is associated to key index in Issuer Application Data | PAN or Req (\*) | `014` | | 3.2.4 | Validate ARQC cryptogram | PAN or Req (\*) | `005` | | 3.2.6 | Message verified OK | PAN | `000` | #### (\*) PAN or Request Value Configuration A TSP configuration parameter controls the behavior of fields (02, 14, 35) in the response: * **Option 1:** Fields use PAN value only when **all TSP checks pass** (code `000`). On failure, the TSP echoes the request value. * **Option 2:** Fields use PAN value as soon as **detokenization succeeds**, even if a Token Domain Restriction check fails (codes other than `001`, `003`, `006`). This behavior is configurable per customer (domestic scheme or closed-loop environment). *** ### In-App Payment Cloud Cryptogram Verification Flow (1100) This flow is enabled per customer configuration. It is triggered when Field 22, Sub-field 1 (PAN Entry Mode) = `08`. Steps 1 through 3.1 are identical to the HCE flow above. | Step | TSP Check | Field (02, 14, 35) | Field 39 | | --------------------------------------------------------- | ---------------------------------------------------------------------------- | ------------------ | -------- | | **3.2 – In-App Payment Cloud Cryptogram Data Validation** | | | | | 3.2.1 | Validate format and version of field 55 | PAN or Req (\*) | `015` | | 3.2.2 | Validate format of cryptogram in tag C4 | PAN or Req (\*) | `015` | | 3.2.3 | Validate Version (tag C5 of cryptogram in tag C4) | PAN or Req (\*) | `015` | | 3.2.4 | Validate ATC (tag 9F36) is not outside the ATC window — positive window only | PAN or Req (\*) | `030` | | 3.2.5 | Validate LVR (tag C5) against allowed values | PAN or Req (\*) | `019` | | 3.2.6 | Validate Transaction Currency Code (tag 5F2A) | PAN or Req (\*) | `018` | | 3.2.7 | Validate amount: `0 ≤ amount_field ≤ (1+p) × amount_crypto` | PAN or Req (\*) | `017` | | 3.2.8 | Validate key associated to DKI (tag C5) | PAN or Req (\*) | `014` | | 3.2.9 | Validate cryptographically the Authentication value (tag C5) | PAN or Req (\*) | `005` | | 3.2.6 | Message verified OK | PAN | `000` | Same Option 1 / Option 2 configuration as described above applies. *** ### Verification on 1120 – Transaction Advice (Re-tokenization) | Step | TSP Check | Notification | Field (02, 14, 35) | Field 39 | | -------------------------------------------------------------- | ------------------------------------------------------------------------------------ | ------------ | ------------------ | --------------- | | **1 – General Message Structure Checks** | | | | | | 1.1 | Authorize client (mutual TLS / IP whitelist) | No | — | No message body | | 1.2 | Well-formed HTTP request | No | — | No message body | | 1.3 | Validate header | No | — | No message body | | 1.4 | Parse ISO request | No | — | No message body | | 1.5 | Validate processing code | No | — | No message body | | 1.6 | Find correct handler by MTI and processing code | No | — | No message body | | **2 – 1120 Message Checks** | | | | | | 2.1 | Parse 1120 message | No | — | No message body | | 2.2 | Validate 1120 message | No | Request | `006` | | 2.3 | Check that field 39 value is in supported range | No | As request value | `006` | | 2.4 | Validate MAC | No | — | No message body | | **3.1 – Field 02 = DPAN (Advice after failed detokenization)** | | | | | | 3.1.1 | Check that field 39 in 1120 is not `000` | No | Request | `003` | | 3.1.2 | Validate issuer | No | Request | `003` | | 3.1.3 | Try to retrieve original message in Transaction History File (no error if not found) | — | — | — | | 3.1.4 | If found, validate that the original response code is not `000` | No | Request | `006` | | 3.1.5 | Is requestor authorized to access DPAN | No | Request | `003` | | 3.1.6 | Send notification to mobile (transactionResult = DECLINED) | Yes | DPAN | `000` | | **3.2 – Field 02 = FPAN (Advice after detokenization)** | | | | | | 3.2.1 | Find original message in Transaction History File (by RRN and TDT) | No | Request | `003` | | 3.2.2 | Validate issuer | No | Request | `003` | | 3.2.3 | Is requestor authorized to access DPAN | No | Request | `003` | | 3.2.4 | Send notification to mobile (see mapping below) | Yes | DPAN | `000` | #### Notification Mapping (step 3.2.4) | Field 03 (pos. 1–2) | Field 39 | Transaction Type | Transaction Result | | ------------------- | -------- | ---------------- | ------------------ | | `00` | `00` | PURCHASE | APPROVED | | `00` | not `00` | PURCHASE | DECLINED | | `20` | `00` | REFUND | APPROVED | | `20` | not `00` | REFUND | DECLINED | | `22` | `00` | PURCHASE | REFUNDED | | `22` | not `00` | PURCHASE | DECLINED | | `52` | `00` | PURCHASE | REFUNDED | | `52` | not `00` | PURCHASE | DECLINED | | `92` | `00` | PURCHASE | APPROVED | | `92` | not `00` | PURCHASE | DECLINED | --- # 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/request-validation.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.