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.
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.
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.
Set the nForceOnlineEnable field in the Entrypoint structure to 1, AND in the AID terminal parameters, ics (DF24) byte6 bit8 must be 1.
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.
Please confirm if the relevant bit in the Limit Indicator (DF27) supports CVM limit checking.
Please confirm if the amount has exceeded the contactless transaction limit DF20.
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.
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.
The APDU return value is provided by the contactless driver. Please contact the contactless driver related personnel directly for assistance.
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.
Paypass MSD mode does not return Tag 57. It returns Track 1 data in Tag 56 and Track 2 data in Tag 9F6B.
MSD mode only allows online, decline, or terminate.
TTQ is only used in Paywave, qpboc, dpas, bancomat legacy. Amex's 9F6E (Form Factor Indicator) also uses 9F66 to set AID parameters.
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).
Please confirm if 9F09 (Terminal Application Version Number) in the AID parameters is consistent with 9F08 (ICC Application Version Number) returned by the card.
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.
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.
Need to set AID parameter DF2F bit6 to support mobile functionality, and DF46 (Mobile C-less Kernel Conf) should be set to 0x01.
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.
The reason might be an incorrect setting for DF2F (Kernel Configuration). The first two bytes of DF2F generally need to be set to 0.
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 9F6A04 (Terminal Country Code).
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);
Which CVM to perform in Paypass MSD mode is determined by AID configuration.
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).DF47 (DF812C): When the transaction amount is less than/equal to the CVM limit in mag-stripe mode, refer to value 0x00.
Paypass mchip mode CVM determination is based on matching the tag8E CVM list, but terminal support for these CVM methods differs slightly.
9F33 byte2 (DF8118): When the transaction amount is greater than the CVM limit, the terminal's CVM capability uses this byte. Reference value: 0x60.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.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.
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.
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.
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.
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.
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.
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.
No.
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.
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.
When the card's 9F38 PDOL requests DF69, it indicates the card supports SM.
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.
The qpboc simplified flow requires setting forced online, and the step parameters passed in by the application should go up to application initialization.
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.
Unlike other kernels, Amex uses DF19 (Contactless Floor Limit) for its Floor Limit check. Please confirm the value of DF19.
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).
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".
Please confirm if the 9F38 PDOL requests tag C7. If so, please confirm if the value of tag DF62 (Pure C7 Data) is correct.
According to the Pure specification flow, it is normal for a Pure refund transaction to return a decline.
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.
This RID is specific to dpas zip mode. The flow is similar to dpas 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.
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.
TIP (9F53) and Combination Options (DF60) must be configured, otherwise the transaction cannot complete normally.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
You need to configure Tag DF34 to ensure that zero-amount transactions result in an online request.
To configure and enable DRL for Paywave, the following three conditions must be met and configured:
DF3D (_EMVPARAM_DF3D_DRLSTATUS) to 1 to enable the DRL check logic (CheckDrl).9F5A (Program ID) during the transaction. The kernel uses this ID to find a matching DRL rule (FindDrlMatchAid).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).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.
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.
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.
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.
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.
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.
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:
9F33 (Terminal Capabilities) to declare its CVM capabilities (e.g., support for Online PIN, Signature, etc.). A recommended value is 0x60 (0110 0000b, indicating support for Online PIN and Signature).DF48 (sometimes referred to as CVM Capability - No CVM Required) to declare its capabilities. A recommended value is 0x08 (0000 1000b, 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.You can differentiate the transaction device type by checking the values of these specific Tags:
9F63 (Product Identification Information) - If Byte 10 has the value 0x20, it indicates a mobile device.9F6E (Form Factor Indicator) - If bits 5-1 (the lower 5 bits) of Byte 1 are 00011, it indicates a mobile device.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.82 (AIP) - If bit 7 of Byte 2 (Device Type Indicator bit) is set to 1, it indicates a mobile device.The relevant bits in TTQ (Tag 9F66) are not set for the following reasons:
9F66 in the terminal configuration, setting Byte 3's bit 8 to 1, or ensure the related functional configuration is enabled.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:
9F6C requires CDCVM (Byte 2 bit 8 = 1):
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.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.9F6C requires Signature (Byte 1 bit 7 = 1), and the terminal supports Signature, then Signature verification is performed.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).
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.
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).
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.
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.
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.
The AID corresponding to the transaction's DF3A needs to be configured as 0x01 to support a 0 amount.
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.
In this case, the card will only return AAC. The application should implement a downgrade process.
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:
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.5F2A (Transaction Currency Code) is consistent with Tag 9F1A (Terminal Country Code).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.