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