EMV Contactless Application
Authentication Data and updated data of their own checks (TVR). In the second GENERATE AC command, the terminal can request the card to generate one of the following cryptograms.
- AAC cryptograms if the transaction should be rejected.
- TC cryptograms if the terminal believes that the transaction should be approved.
The decision-making process for the card after receiving the second GENERATE AC command includes the following steps.
- 1. If the terminal requests an AAC cryptogram, the card generates the requested cryptogram.
- 2. When the terminal informs you of the “unable to go online” situation, the card checks whether the bits set in CIAC-Default do not match the non-zero bits in the CVR. If such a match is found, the transaction is rejected, and the card forms an AAC cryptogram. Otherwise, the card may approve the transaction after additional checks are performed.
- 3. The card authenticates the Issuer (checks the value of the ARPC cryptogram in the Issuer Authentication Data element). If the Issuer’s authentication is not performed, the transaction is usually rejected (an AAC cryptogram is generated).
- 4. If the Issuer authentication is successful, further actions of the card are determined by the Issuer’s choice, which is defined in the Card Status Update (CSU). The card generates a TC or AAC cryptogram, depending on the Issuer’s decision to process the transaction, and performs the actions that the Issuer has defined in the CSU (for example, setting the counter for the remaining pin number, resetting offline counters, etc.). In addition, the card resets signs of special situations that were recorded during the previous or current transaction. The card decision made when executing GENERATE AC is final.
- After completing the second GENERATE AC command, the terminal must pass non-critical script processing commands to the card, if they are present in the authorization response.
- If online processing is not possible (the “unable to go online” situation), the terminal reports this via the Issuer’s authorization code (the Issuer Authentication Data element is reset). Contactless transaction the Interest in contactless cards can be explained by several of their technical advantages:
- ▪ ease of use of the card (the card does not need to be passed to the cashier, correctly oriented and inserted into the reader slot, you can even not pull out of the wallet))
- ▪ faster transaction execution speed
- ▪ higher reliability of using cards and terminals – due to the absence of mechanical contact between the card and the terminal, a lower level of physical wear is provided
- ▪ better protection of contactless terminals from vandalism
EMVCo has long been working on creating a single contactless application EMV Contactless Application-an analogue of the Common Payment Application (CPA) for contact cards. However, EMVCo is in no hurry to develop this standard. The reason given by EMVCo is the lack of experience in using contactless cards. Every year, an internal discussion is held on the feasibility of developing a standard, but there is still no positive decision. The appearance of a standard for a single contactless app in the future is not entirely obvious. Therefore, EMVCo, anticipating the appearance of such a standard, developed the EMV Contactless Specifications for Payment Systems – Entry Point Specification (in the future we will call it Entry Point Specification for short), which solves a number of issues. ‘This standard defines the General scheme for processing a contactless card transaction on the terminal side (Entry Point) and goes into sufficient detail to describe the procedures that precede the selection of the application. For rice. 5 shows the General scheme of transaction processing in contactless mode. Without stopping at the details of processing, we note that after pre-processing and activation of the Protocol, the terminal begins the procedure for selecting a contactless application. If the terminal supports a single contactless application, it immediately selects this application using the SELECT command. Otherwise, the terminal selects the PPSE (Proximity Payment System Environment) application that has the 2pay ID.SYS.DDF01, and receives in response an FCI object that contains information about contactless apps on the card.
Although the idea that you can not pull a card out of your wallet still passes from book to book, from article to article, it is difficult to implement. First, a good wallet significantly reduces the ability of the terminal to recognize the card due to a decrease in signal strength. Second, if there are other contactless cards in the wallet, the terminal will most likely be unable to recognize the card due to collisions.