# EMVL2 CTLSS FAQ (/global/en/docs/Terminal/EMVL2/EMV-FAQ/EMVL2-CTLSS-FAQ)

**"Q1: When Offline Data Authentication returns error code -1632, how to solve it?"**

This is caused by the terminal missing the public key index required by the card. Please search for the tag 8F and RID (the first five bytes of tag: 9F06) returned by the card, and add the corresponding public key to the RID and 8F values.

**"Q2: When Offline Data Authentication returns error code -1610, how to solve it?"**

This is caused by the card's certificate being expired. If it's a production environment, you can ask the customer to replace the card. If it's a test case and needs to pass, you can change the POS time based on the expiration date logged or found in tag `5F24` (Application Expiration Date) to pass the case.

**"Q3: When Offline Data Authentication returns error code -1602, how to solve it?"**

This is caused by a mismatch between the public key modulus length and the card's issuer certificate modulus length. This often happens due to using the wrong public key. Request the customer to download the correct public key.

**"Q4: How to set forced online for contactless transactions?"**

Set the `nForceOnlineEnable` field in the Entrypoint structure to 1, AND in the AID terminal parameters, `ics` (`DF24`) byte6 bit8 must be 1.

**"Q5: How to support partial matching for contactless transactions?"**

The value for `DF01` (AID Matching Indicator) passed into the kernel for this AID parameter must be `01`, AND `DF24` byte1 bit6 must be `1`.

**"Q6: Why is CVM not executed even though the contactless transaction amount is greater than the CVM limit (\`DF21\`)?"**

Please confirm if the relevant bit in the Limit Indicator (`DF27`) supports CVM limit checking.

**"Q7: Why does a contactless transaction return error code -2105?"**

Please confirm if the amount has exceeded the contactless transaction limit `DF20`.

**"Q8: Why did the contactless transaction not exceed the transaction limit, but ultimately result in error code -6 (Application not found)?"**

This is because some contactless kernels need to execute the `select next aid` flow when the amount exceeds the CVM limit, but often there is no next available AID in the candidate list. Therefore, it ultimately returns -6, unable to find a supported application.

**"Q9: How does a contactless transaction determine which card type and mode is being used?"**

The kernel provides the value of tag `DF1F` (Interface Device Mode and Card Type) to indicate the card type and mode for the current transaction. Please refer to the development manual for specific values of `DF1F`.

**"Q10: How to resolve contactless transaction APDU returning -1?"**

The APDU return value is provided by the contactless driver. Please contact the contactless driver related personnel directly for assistance.

**"Q11: Which contactless kernels send the GAC command, and how do they get their terminal-requested transaction outcomes?"**

Paypass mchip, Expresspay, JCB EMV, JCB mstripe, Rupay contactless, Gemalto Pure, MIR protocol1, Multibanco send the GAC command. Their terminal-requested transaction outcomes are determined by matching TVR with TAC/IAC. If it matches TAC/IAC decline, request decline. If it matches TAC/IAC online, request online. If neither matches, request offline.

**"Q12: Why does the backend sometimes return an ARQC verification error?"**

1. Please confirm if all the data uploaded in Field 55 was correctly retrieved from the kernel. 2. Please confirm if the data used by the backend to calculate the ARPC is consistent with what the terminal sent, and if the backend's calculation method is correct.

**"Q13: Why doesn't Paypass MSD mode return Tag 57 (Track 2 Equivalent Data)?"**

Paypass MSD mode does not return Tag 57. It returns Track 1 data in Tag 56 and Track 2 data in Tag `9F6B`.

**"Q14: Why can't the MSD mode of various kernels return offline?"**

MSD mode only allows online, decline, or terminate.

**"Q15: In which kernels is \`9F66\` (TTQ - Terminal Transaction Qualifiers) used?"**

TTQ is only used in Paywave, qpboc, dpas, bancomat legacy. Amex's `9F6E` (Form Factor Indicator) also uses `9F66` to set AID parameters.

**"Q16: Why don't most contactless transactions perform a second authorization process?"**

Currently, apart from Rupay's qsparc, other contactless kernels do not send a second GAC to perform second authorization. However, dpas and Amex require a second call to `process`, passing the online result to the kernel for online result processing (without sending a second GAC).

**"Q17: Why is TVR byte2 bit 8 set?"**

Please confirm if `9F09` (Terminal Application Version Number) in the AID parameters is consistent with `9F08` (ICC Application Version Number) returned by the card.

**"Q18: Why don't paywave, dpas, qpboc, bancomat legacy transactions send the GAC command?"**

For these kernels, the interaction process between the terminal and the card only goes up to reading records. The application cryptogram (`9F26`) is already returned by the card during the GPO command response.

**"Q19: Why does a Paypass/MasterCard refund transaction not request AAC (Decline) during GAC?"**

The Paypass kernel requests AAC only if TVR matches TAC DENIAL. Therefore, for Paypass refund transactions, `DF13` (TAC-Denial) must be set to all `0xFF`.

**"Q20: How to configure Paypass/MasterCard kernel support for mobile transactions?"**

Need to set AID parameter `DF2F` bit6 to support mobile functionality, and `DF46` (Mobile C-less Kernel Conf) should be set to `0x01`.

**"Q21: Why did the Paypass/MasterCard transaction amount not exceed the \`DF20\` contactless transaction limit, but the transaction still exceeded the limit?"**

Confirm if the transaction was performed using a mobile phone. The contactless transaction limit for Paypass mobile transactions uses tag `9F7B` (Mobile C-less Txn Limit). Please confirm the value of `9F7B`.

**"Q22: Why did the Paypass/MasterCard transaction terminate abnormally after the GPO command?"**

The reason might be an incorrect setting for `DF2F` (Kernel Configuration). The first two bytes of `DF2F` generally need to be set to 0.

**"Q23: Why does a Paypass/MasterCard transaction return error code -2212, -2216?"**

If Paypass MSD mode does not return UDOL (Update Data Object List), it will use the default UDOL configured in the AID parameters, and the default UDOL must contain `9F6A`04 (Terminal Country Code).

**"Q24: How to configure Paypass/MasterCard support for RRP (Relay Resistance Protocol) functionality?"**

First, `DF2F` bit5 needs to support RRP functionality. Second, tag `DF52` (RRP Parameters - in the pptlv field of the parameter file) needs to be configured with a set of RRP tags:
memcpy(pptlv,"\xDF\x81\x33\x02\x00\x32\xDF\x81\x32\x02\x00\x14\xDF\x81\x36\x02\x01\x2C\xDF\x81\x37\x01\x32\xDF\x81\x34\x02\x00\x0B\xDF\x81\x35\x02\x00\x0D", 35);

**"Q25: How does a Paypass/MasterCard MSD transaction determine which CVM to perform?"**

Which CVM to perform in Paypass MSD mode is determined by AID configuration.

- Mag-stripe CVM Capability - CVM Required `DF42` (`DF811E`): When the transaction amount is greater than the CVM limit in mag-stripe mode, refer to value 0x10 (Signature) or 0x20 (Online PIN).
- Mag-stripe CVM Capability - No CVM Required `DF47` (`DF812C`): When the transaction amount is less than/equal to the CVM limit in mag-stripe mode, refer to value 0x00.
  - OP\_NO\_CVM 0x00
  - OP\_OBTAIN\_SIGNATURE 0x10
  - OP\_ONLINE\_PIN 0x20
  - OP\_CONFIRMATION\_CODE\_VERIFIED 0x30
  - OP\_CVM\_NA 0xF0

**"Q26: How is the CVM determined for Paypass/MasterCard mchip mode transactions?"**

Paypass mchip mode CVM determination is based on matching the `tag8E` CVM list, but terminal support for these CVM methods differs slightly.

- CVM cap - CVM required `9F33` byte2 (`DF8118`): When the transaction amount is greater than the CVM limit, the terminal's CVM capability uses this byte. Reference value: `0x60`.
- CVM cap - No CVM required `DF48` (`DF8119`): When the transaction amount is less than/equal to the CVM limit, the terminal's CVM capability uses this byte. The meaning of each bit is consistent with `9F33` byte 2. Reference value: `0x08`.

**"Q27: Why is the result of a Paywave/Visa refund transaction a decline?"**

For Paywave/Visa refund transactions, when the card returns AAC, it cannot be treated as a decline. Therefore, before the transaction starts, the `ucRefundRequestAac` field in the Entrypoint structure needs to be set. Offline TC: `0x40`, Online ARQC: `0x80`.

**"Q28: Why does a Paywave/Visa transaction return -15?"**

This is because the Paywave/Visa transaction entered the CDCVM flow, the terminal should display a "see phone" prompt, then `tryagain` is returned, causing a re-poll for the card.

**"Q29: Why is the TVR obtained from a Paywave/Visa transaction all zeros, and the CVM result \`9F34\` is not obtained?"**

The Paywave/Visa kernel does not mark the TVR, so what is retrieved is all zeros. The Paywave kernel does not return the `cvm list` tag `8E` to select the CVM to execute, so the kernel does not generate `9F34`.

**"Q30: Why does a Paywave/Visa balance inquiry transaction terminate abnormally?"**

Because the amount passed into the kernel for balance inquiry is 0, please confirm if the AID parameters support 0 amount transactions. Paywave/Visa config: `DF34` (TTQ): Reference value `C4 00`.

**"Q31: Why is the transaction result rejected even though the CID \`9F27\` returned by the card in a Paywave/Visa transaction is Online or Offline?"**

Paywave/Visa does not have a GAC step, and `9F27` is returned in the GPO response. Subsequent Paywave/Visa transaction steps: Card reading completed, limit processing, offline data authentication, cardholder verification. If failures occur (e.g., ODA fail, CVM fail), the card's required transaction outcome might change at any time.

**"Q32: How is the CVM determined for Paywave/Visa transactions?"**

The Paywave/Visa CVM process is decided by checking whether the card returns tag `9F6C` (Card Transaction Properties). If returned, the CVM method is selected based on the value of `9F6C`. If not returned, the CVM method is selected based on the priority order: Signature, Online PIN, No CVM.

**"Q33: Why is CVM still required in a Paywave/Visa transaction even if the amount does not exceed the CVM limit?"**

Paywave/Visa cards have their own CVM limit. If the transaction amount exceeds the card's CVM limit, the `9F6C` returned by the card will require CVM execution.

**"Q34: Can we obtain the card's CVM limit?"**

No.

**"Q35: How does a Qpboc transaction control the SM (National Cryptography) switch?"**

When the terminal has tag `DF69` set to `01` or does not set tag `DF69`, the terminal supports SM. When the terminal has tag `DF69` set to `00`, the terminal does not support SM.

**"Q36: Why did a qpboc e-cash transaction fail offline data authentication but still get debited?"**

Because the e-cash balance deduction happens after the last interaction between the terminal and the card, while offline data authentication occurs when the interaction between the terminal and the card has already ended.

**"Q37: How to determine if a card supports SM in a Qpboc transaction?"**

When the card's `9F38` PDOL requests `DF69`, it indicates the card supports SM.

**"Q39: Why doesn't the qpboc transaction kernel provide a CVM method?"**

The qpboc transaction kernel does not perform CVM steps. Therefore, the final CVM method selection is decided by the application, either CVM-exempt or forced PIN entry, or based on `9F6C`.

**"Q40: How is the simplified flow set up for qpboc?"**

The qpboc simplified flow requires setting forced online, and the step parameters passed in by the application should go up to application initialization.

**"Q41: Why did an Amex transaction GPO fail?"**

The main reason is that the PDOL (`9F38`) requires sending `9F6E` and `9F6D`, but these two tags were not configured in the AID parameters. `9F6D` (`newland tag DF49`) needs to be set to `0xC0`.

**"Q42: Why is the transaction amount for Amex greater than the \`9F1B\` Floor Limit, but the relevant TVR bit is not set?"**

Unlike other kernels, Amex uses `DF19` (Contactless Floor Limit) for its Floor Limit check. Please confirm the value of `DF19`.

**"Q43: Why did the Amex test case for 'see phone' fail?"**

When `ucUIMessageId` returns `UI_MSGID_SEE_PHONE`, the application needs to display "seephone" and perform `try again`. The `ucRestart` flag must be set to 1 (can only try again once; the kernel judges based on this flag).

**"Q44: Why does an Amex transaction terminate abnormally when the amount is less than the CVM limit?"**

When the Amex transaction amount is less than the CVM limit, tag `8E` (CVM List) preferentially selects "No CVM" if present. If the terminal does not support "No CVM" at this time, issues will arise. Therefore, confirm if `9F33` supports "No CVM".

**"Q45: Why does a Pure transaction GPO return 6985?"**

Please confirm if the `9F38` PDOL requests tag `C7`. If so, please confirm if the value of tag `DF62` (Pure C7 Data) is correct.

**"Q46: Why does a Pure refund transaction return AAC (Decline)?"**

According to the Pure specification flow, it is normal for a Pure refund transaction to return a decline.

**"Q47: Why do the MIR and Multibanco kernels only check the first byte of the kernel ID, failing to correctly enter the kernel process?"**

The effective bytes for the kernel ID in these kernels are three bytes. The first three bytes of the kernel ID need to match exactly to correctly enter the corresponding kernel process and perform the transaction.

**"Q48: Why does dpas have an extra RID \`A0 00 00 03 24\` (ZIP)?"**

This RID is specific to dpas zip mode. The flow is similar to dpas MSD mode.

**"Q49: How to determine if dpas used MSD mode?"**

If the AID parameter `9F66` (TTQ) supports MSD mode, and GPO returns `9F7D` (dpas MSD Cfg), then dpas will run in MSD mode.

**"Q50: How is CVM performed in dpas?"**

dpas zip and MSD modes do not perform CVM flows. EMV mode selects based on `9F71` (Card Processing Requirement - CPR). The card determines the priority order: online pin, signature, CDCVM. If the terminal does not support fallback to card CVM support, it fails.

**"Q51: What tags must be set for JCB transactions?"**

`TIP` (`9F53`) and `Combination Options` (`DF60`) must be configured, otherwise the transaction cannot complete normally.

**"Q52: Why does a UnionPay L3 test still require PIN entry for an amount of 202 CNY (which is less than the limit) even when the CVM Limit (qpslimit) is set to 300 CNY?"**

This happens because UnionPay's Quick Pass (QPS) contactless limit rules require the transaction amount to be *strictly less than* the configured `qpslimit` (L3 Tag `1F8124`, which is 300 CNY here) to bypass PIN entry. Although 202 CNY is less than 300 CNY, there might be an issue with your configuration, kernel processing logic, or the rule might actually require "less than or equal to" along with other conditions being met. Please verify that `qpslimit` (`1F8124`) is set correctly and the transaction amount truly meets the criteria for PIN bypass.

**"Q53: In the MCD04.test.01.01 test case, why does a transaction amount of 20 CNY return error code -2105 when the contactless transaction limit DF20 is 9999 CNY?"**

Error code -2105 (Preprocessing Amount Exceeded) is returned because, although the general contactless limit `DF20` (`DF8124`) is high, the specific limit for mobile device CVM, `9F7B` (`DF8125`), is shown as 0 in the logs. When the transaction involves a mobile device, the 20 CNY amount exceeds the 0 CNY limit set by `9F7B`. You need to check and correctly configure the value for `9F7B` (CLSS\_TRANS\_LIMIT\_ON\_DEVICE\_CVM).

**"Q54: Why does the actual 9F34 CVMResult return 1F0302 when the test case requires 3F0002?"**

The actual return is 1F0302 instead of the expected 3F0002 because Byte1 bit6 (On Device Cardholder Verification Supported) of the kernel configuration `DF2F` (ucKernelConfig) was not set to 1. Please set Byte1 bit6 of `DF2F` to 1 to enable support for CDCVM.

**"Q55: What causes a JCB application initialization to return the error INITERR\_CARDNOSUPPORT (-1413)?"**

JCB application initialization fails with error -1413 because the value of `9F4E` (Merchant Name and Location) configured for this JCB AID in the terminal's AID list does not match the `9F4E` value used during the actual application selection process. Please check and ensure the `9F4E` in the AID configuration is consistent with the one used in the transaction flow.

**"Q56: Why do some expired cards successfully read, while others fail?"**

This depends on the specifications of different card organizations (like Amex, UnionPay) and the card's own processing logic. For example, an Amex card might check the card expiry date during ODA (Offline Data Authentication) and reject the transaction immediately if expired. A UnionPay card, under certain flows, might not perform ODA and instead request online authorization directly, letting the backend determine if the card is expired. Therefore, the card might be read successfully at the terminal level.

**"Q57: Why does a JCB contactless transaction return error code -514 (with associated logs)?"**

Error code -514, accompanied by the kernel log `nRet=19` (corresponding to `EMV_TRANS_RF_SELECT_NEXT_AID`), is returned because the transaction amount exceeds the contactless limit. According to the kernel code snippet, when the transaction amount (`unAuthAmt`) is greater than or equal to the contactless transaction limit `DF20` (`unClLimit`), the kernel returns `EMV_TRANS_RF_SELECT_NEXT_AID` (19). This manifests as error -514 at the upper layer, indicating the transaction needs to try another application or interface due to exceeding the limit.

**"Q58: Why does a Cashback transaction return error code -514 (with associated logs) (Or prompt downgrade, swipe card)?"**

Error -514 is returned because the second GAC (Generate Application Cryptogram) was rejected by the card. The TVR (`gpusTVR`) in the log is `0290008000`, where Byte4 bit8 (Requested service not allowed by card) is set. Further inspection reveals the card's AUC (Application Usage Control, Tag `9F07`) value is `0xFF00`, indicating that the card itself does not support the Cashback transaction type, hence rejecting the service request.

**"Q59: Why does a PayWave contactless transaction return error code -2105 (RFERR\_PREPROCESS\_AMTLIMITOVER)?"**

Error code -2105 is returned because the transaction amount `9F02` exceeded the PayWave contactless transaction limit `DF20`. During the transaction preprocessing stage, the kernel detected that the amount was over the limit and therefore rejected the transaction.

**"Q60: Why is Tag 9F39 unobtainable in contactless transactions?"**

Failure to obtain Tag `9F39` (POS Entry Mode) in a contactless transaction might be because the terminal's AID configuration does not specify a value for this tag for the contactless flow. Please check the AID's XML configuration file. Set the value of `9F39` to `07` for contactless transactions and `05` for contact transactions.

**"Q61: In the MCD93 test case, a contactless transaction is required to request TC or ARQC during the first GAC, have the card return AAC, and then fall back to contact. Why doesn't the fallback actually happen?"**

The fallback doesn't occur because the current transaction type (`9C`) is not among those defined in the Paypass specification to trigger the "Try Another Interface" logic. According to the kernel logic, only when the transaction type is Purchase (`0x00`), Cash Advance (`0x01`), Purchase with Cashback (`0x09`), or Cash Disbursement (`0x17`) will the kernel, under specific conditions (like GAC1 returning AAC), return `EMV_TRANS_RF_TRYOTHERINT` (17) to instruct the application layer to try the contact interface. If the current transaction type is not in this list, fallback will not be triggered even if GAC1 returns AAC.

**"Q62: During a Paywave balance inquiry (transaction amount 9F02 is 0), why is the result L3\_TXN\_APPROVED instead of the expected L3\_TXN\_ONLINE?"**

You need to configure Tag `DF34` to ensure that zero-amount transactions result in an online request.

**"Q63: How do you configure Dynamic Reader Limit (DRL) for Paywave?"**

To configure and enable DRL for Paywave, the following three conditions must be met and configured:

1. **Enable DRL Feature:** Set the value of Tag `DF3D` (\_EMVPARAM\_DF3D\_DRLSTATUS) to 1 to enable the DRL check logic (`CheckDrl`).
2. **Card Supports DRL:** The card must return Tag `9F5A` (Program ID) during the transaction. The kernel uses this ID to find a matching DRL rule (`FindDrlMatchAid`).
3. **Configure DRL Dataset:** The terminal must be configured with Tag `DF3F` (\_EMVPARAM\_DF3F\_DRLDATA), containing at least 8 sets of DRL limit data, and one set must match the `9F5A` returned by the card.
   If all these conditions are met and a match is found, the kernel will perform `DrlLimitCheck`; otherwise, it will perform the default limit check (`DefaultLimitCheck`).

**"Q64: In the DGN\_DPAS\_L3\_CL\_001 test case, Tag 9F33 in the Field 55 of the authorization request indicates the terminal does not support Online PIN. How should this be modified to pass the case?"**

Modify the value of `9F33` from `E0 F8 C8` (where `F8` has bit 7 = 1) to `E0 B8 C8` (where `B8` has bit 7 = 0) to indicate that the terminal does not support Enciphered Online PIN.

**"Q65: In the DGN\_DPAS\_L3\_CL\_015 test case, why is the format of Tag 9F53 sent by the application considered incorrect?"**

The format of `9F53` sent by the application is considered incorrect because the Dpas specification has specific requirements for `9F53` (Consecutive Transaction Counter International Limit - CTCLimit). According to the Dpas specification, `9F53` is a 1-byte value, for example, `01`. If the value set by the application layer does not conform to the Dpas requirements in length or format, it will be treated as incorrect.

**"Q66: In the MCD65.Test.01.01 test case, the requirement is for the contactless transaction to be declined and fall back to contact, but why did the first contactless transaction succeed directly?"**

The first contactless transaction succeeded directly because the simulated host response was not set according to the test case requirements. This case requires that for the first transaction, the host responds with DE 39 (Response Code) = `65` (Exceeds withdrawal count limit), which corresponds to Tag `8A` having the value `65`.

**"Q67: Why are contactless transactions below a certain high amount (e.g., 2,000,000) declined, while transactions above that amount are processed normally?"**

The issue lies in the terminal's configuration: the contactless floor limit `DF21` (CLSS Floor Limit) is set to 2,000,001, while the Terminal Capabilities `9F33` are configured *not* to support "No CVM Required". To resolve this, you can either: 1) Modify the value of `DF21`, or 2) Modify `9F33` to support "No CVM Required" (set Byte2 bit4 to 1) to accommodate potential No CVM scenarios triggered by lower-amount transactions.

**"Q68: Why does the L3 layer report the value of gstTransData.unFileOffset as 0?"**

As seen from the kernel code, if `EMVL3` is defined, file operations are handled by the L3 layer. The value being 0 might relate to how L3 manages file offsets or if the specific data isn't being accessed via a file offset mechanism in that context.

**"Q69: What are the special conditions or circumstances regarding the Paypass Bypass issue in the USM01.Test.20.01 case?"**

Support for Paypass CVM Bypass is not universal. According to the specification, only specific card products in contactless transactions (e.g., US Maestro, with AID `A0000000042203`) explicitly support CVM Bypass. When using such a card for a transaction that meets the Bypass conditions, skipping the CVM is permitted, and `9F34` (CVM Result) should return `3F 00 01`.

**"Q70: How is the CVM (Cardholder Verification Method) determined for Paypass MChip mode transactions?"**

In Paypass MChip mode, the choice of CVM method is based on matching the CVM List returned by the card (Tag `8E`) with the terminal's capabilities. However, the basis for determining the terminal's support for a CVM method changes depending on whether the transaction amount exceeds the CVM limit:

- When the transaction amount is **greater than** the CVM limit, the terminal uses the second byte of Tag `9F33` (Terminal Capabilities) to declare its CVM capabilities (e.g., support for Online PIN, Signature, etc.). A recommended value is `0x60` (`0110 0000`b, indicating support for Online PIN and Signature).
- When the transaction amount is **less than or equal to** the CVM limit, the terminal uses the first byte of the Paypass-specific tag `DF48` (sometimes referred to as CVM Capability - No CVM Required) to declare its capabilities. A recommended value is `0x08` (`0000 1000`b, indicating support for No CVM Required).
  The kernel determines whether it supports a CVM method from the `8E` list based on the configuration (`9F33` or `DF48`) corresponding to the current transaction amount.

**"Q71: Which Tags can be used to distinguish between transactions originating from a mobile device versus a physical card?"**

You can differentiate the transaction device type by checking the values of these specific Tags:

- **QPBOC:** Tag `9F63` (Product Identification Information) - If Byte 10 has the value `0x20`, it indicates a mobile device.
- **VISA:** Tag `9F6E` (Form Factor Indicator) - If bits 5-1 (the lower 5 bits) of Byte 1 are `00011`, it indicates a mobile device.
- **PAYPASS:** Tag `82` (Application Interchange Profile - AIP) - If bit 2 of Byte 1 (Mobile CVM Processing Capability bit) is set to `1`, it indicates a mobile device.
- **JCB / AMEX:** Tag `82` (AIP) - If bit 7 of Byte 2 (Device Type Indicator bit) is set to `1`, it indicates a mobile device.

**"Q72: In the DGN\_DPAS\_L3\_CL\_001 case, why are TTQ's Byte2, bit7 (CVM required) and Byte3, bit8 (Issuer Update Processing supported) not set to 1?"**

The relevant bits in TTQ (Tag 9F66) are not set for the following reasons:

- **Byte 2, bit 7 (CVM required):** Whether this bit is set depends on whether the transaction amount exceeds the CVM limit. If the amount is below the CVM limit, this bit will not be set to 1.
- **Byte 3, bit 8 (Issuer Update Processing supported):** This bit indicates whether the terminal supports issuer update processing (like scripts). It usually directly reflects the terminal's configured capability. To set this bit, you need to directly modify the initial value of `9F66` in the terminal configuration, setting Byte 3's bit 8 to 1, or ensure the related functional configuration is enabled.

**"Q73: What is the CVM selection logic for UnionPay transactions?"**

If both the card and terminal support Online PIN, there's no need to check other bits; Online PIN is performed.

If Online PIN is not supported, the following rules apply, attempting CDCVM and Signature in order.

When a UnionPay card returns Card Transaction Properties (Tag `9F6C`), the terminal should decide the CVM method based on `9F6C` and its own capabilities:

1. **CDCVM (Mobile Device CVM):** If the Online PIN condition is not met, and `9F6C` requires CDCVM (Byte 2 bit 8 = 1):
   - If the card also returned Card Verification Related Data (Tag `9F6C` - *Note: Ensure clarity if this refers to the same tag or a different one with the same number*), and bytes 6-7 of this data match bytes 1-2 of the Card Transaction Properties (`9F6C`), then CDCVM is successful, and CVM processing ends. If they don't match, the transaction is declined.
   - If the card did not return Card Verification Related Data (`9F6C`): If the card returned an ARQC (online request), CDCVM is considered successful (verifiable by the host), and CVM processing ends. If it returned a non-ARQC cryptogram, the transaction is declined.
2. **Signature:** If neither Online PIN nor CDCVM was performed, and `9F6C` requires Signature (Byte 1 bit 7 = 1), and the terminal supports Signature, then Signature verification is performed.
3. **No CVM:** If none of the above conditions are met, no mutually supported CVM was found, and no CVM is performed.
4. **Final Check:** If the terminal requested a CVM but ultimately no CVM method was performed, the transaction should be declined.

**"Q74: Why is directly modifying Tag DF20 in the final application selection callback for Paypass contactless transactions ineffective?"**

Directly modifying `DF20` in the final application selection callback is ineffective because the Paypass kernel has its own internal logic for handling limits after this stage. You need to modify the value of `DF8124` in the final application selection callback. The kernel assigns the configured value of `DF8124` to an internal variable (like `DF57`) and cannot directly modify `DF20`. Subsequent limit checks (usually performed after reading records) use this internal value (`DF57`), not the original `DF20`. Therefore, to dynamically modify the contactless limit in this callback, you must modify `DF8124` (CLSS\_TRANS\_LIMIT\_NO\_ON\_DEVICE\_CVM).

**"Q75: Why does calling the card polling interface consecutively result in error -2008?"**

Calling the card polling interface consecutively results in error -2008 (typically indicating device busy or status error) because the interval between calls is too short. The underlying hardware and driver need some time to reset their state or release resources after completing one polling operation. Initiating the next poll immediately finds the device unprepared, leading to a busy or error status. Specifications or best practices usually recommend a minimum interval of at least 100 milliseconds between polling interface calls to ensure the device can respond normally.

**"Q76: What should be done if the 9F34 CVM Result does not meet expectations in the USM05.Test.03.01 case?"**

This test case requires the terminal *not* to support CDCVM. You need to set bit 6 (On Device Cardholder Verification Supported) of the Paypass kernel configuration Tag `DF2F` (or `DF811B`) to 0. This means configuring the value of `DF2F` to `90` (`1001 0000` binary).

**"Q77: VB90S device, why didn't Mastercard-UnionPay card use this AID：A0000000108888?"**

The terminal selected AID `A0000000108888`, but the card returned `6985` (Conditions of use not satisfied) during GPO. This is likely because the Kernel ID for AID `A0 00 00 00 10 88 88` needs to be set to `07` , not `02` . Please check and ensure the correct Kernel ID is configured for this AID.

**"Q78: In a Paypass contactless transaction involving Online PIN, the \\"Online PIN entered\\" bit in the TVR is set. Can this be changed?"**

During the Online PIN flow, the "Online PIN entered" bit in the TVR is set *before* the GAC (Generate AC) request is sent. This is a requirement of the Paypass specification. Furthermore, this updated TVR value (with the bit set) is sent to the card within the GAC command. This behavior is defined by the specification and cannot be changed, as doing so would likely cause verification errors on the host side.

**"Q79: In MCD55.Test.01.01 case, involving Single Tap and PIN Request (related to strong cardholder authentication), why does the case require a PIN input but no PIN is actually entered?"**

Cases involving Single Tap require application handling. From the 8583 packet returned by the backend, check the field indicating Single Tap. Then the application should call for PIN input, resend the message request for online transaction, and finally call complete and terminate.

**"Q80: For a 0 amount balance inquiry transaction, error code -2105 is returned. How to resolve this?"**

The AID corresponding to the transaction's DF3A needs to be configured as 0x01 to support a 0 amount.

**"Q81: What to do if the amount exceeds the limit?"**

Check the required transaction amount range for the case. The contactless transaction limit is DF20, and the CVM limit is DF21. Search the logs for 'Tag: DF20' and 'Tag: DF21' accordingly. The transaction amount can be found by searching for 'Tag: 9F02'. Configure 9F7B (DF8125) and DF20 (DF8124) to ensure the transaction does not exceed the limit.

**"Q82: In CHN33.Test.01.01 case, the case requires a prompt to insert the card, but the card is actually rejected. How should this be handled?"**

In this case, the card will only return AAC. The application should implement a downgrade process.

**"Q83: How to handle error 6984 during Visa contactless application initialization?"**

This is generally caused by incorrect configuration. If the transaction amount exceeds the CVM (Cardholder Verification Method) Limit, and the terminal and card do not share a common CVM, the card will return `6984`, often leading to a fallback (e.g., to a contact transaction). It's also possible that the card has an internal limit, and contactless transactions are not permitted above a certain amount. For this specific case, the following points might be the reasons:

1. **MCCS/VCCS Prioritization:** If prioritization of MCCS (Mastercard Contactless System) or VCCS (Visa Contactless Card Specification) is required, ensure the AID (Application Identifier) that prioritizes MCCS/VCCS is selected. If the multi-application selection dialog does not appear, update the EMVL3 library.
2. **Large Transaction Amount & CVM Limits:** If the transaction amount is large, try setting the first byte of Tag `9F66` (Terminal Transaction Qualifiers) to `36` or `26` (this is generally not recommended). This can help prevent the card's internal CVM (Cardholder Verification Method) limit from being exceeded when no CVM method is matched, which might otherwise cause the card to return `6984`.
3. **Tag Configuration Consistency:** Verify that other tag configurations are correct. For example, ensure Tag `5F2A` (Transaction Currency Code) is consistent with Tag `9F1A` (Terminal Country Code).

**"Q84: When performing a CDCVM transaction with a Visa card, why does the POS prompt for a PIN?"**

Firstly, confirm that the transaction amount (Tag: 9F02) is greater than Tag: DF21 (CVM limit)(9F02 and DF21 have been expressed in decimal format).Check if bit 7 of Byte 3 in Tag 9F66(Terminal Transaction Qualifiers(TTQ)) is set to 1 to support CDCVM, and also check if bit 8 of Byte 2 in Tag 9F6C(card returned) is set to 1 ("CDCVM Performed"). If both of these conditions are met, the POS will not prompt for a PIN. If bit 8 of Byte 1 in Tag 9F6C is 1 while bit 8 of Byte 2 is 0, then the CDCVM condition is not met, and the POS will prompt for a PIN. If bit 7 of Byte 1 in Tag 9F6C is 1 while bit 8 of Byte 2 is 0, the POS will prompt for a signature.