Processing a transaction in contactless mode.

After selecting an application, the kernel corresponding to the application to which the terminal’s Entry Point passes control is activated. The kernel completes processing by generating the result for the Entry Point. Possible results of processing the kernel are rejection of the transaction or approval in offline mode, sending the transaction for authorization to the Issuer, requiring switching to contact mode, and so on. One of the main features of working in contactless mode is that the transaction is usually performed in one touch to the terminal.1 in Addition, it is required that the time spent on the card in the terminal’s reading area is minimal. For example, MasterCard insists that the card and the terminal have time to exchange data in 150 msec (although it violates these requirements). As a result, the implementation of a contactless transaction in the payment application is characterized by the following features:
▪ offline PIN verification method cannot be used to verify the cardholder. 2
▪ risk management procedures performed by the terminal take into account that the transaction is performed in contactless mode
▪ in the case of online transaction authorization, the Issuer’s response is not verified by the card, the script processing commands are not executed (the card is no longer available for the terminal), and there is no possibility to perform actions defined by the Issuer in the CSU (for example, setting the PIN count counter, resetting offline counters, etc.)
▪ the set of commands used by the terminal (the application processing core) to perform a transaction is usually minimized to reduce the time the card is in the terminal’s read zone

A number of payment systems (for example, AmEx) followed the path of implementing a transaction in two touches to the terminal. The second touch is needed after the Issuer’s response is received to process it. In this case, the contact handling is virtually indistinguishable from the contact. This method is not only inconvenient for the cardholder, but also slows down payment for goods (services). Therefore, most payment systems still use a single touch. This method is described below. Offline PIN verification is undesirable for many reasons. First, it’s not safe. Secondly, it is inconvenient for the cardholder. Not without reason, a common feature of contactless app specifications is the refusal to present a PIN code in offline mode. Contactless applications use two verification methods – presenting the PIN code online (when sending a transaction for authorization to the Issuer) and signing (offline). For example, a number of payment applications do not use the GENERATE AC command, and the data required for approval of the transaction by the Issuer (cryptogram and other transaction parameters) is provided to the terminal in the GET PROCESSING OPTIONS command. Verification of the contactless card holder is limited to several methods:
▪ verification of the encrypted PIN code performed by the Issuer (online PIN code)
▪ getting the cardholder’s signature
▪ verification of the cardholder is not required (this is important in some cases when the transaction amount is small or it is necessary to ensure a high speed of payments)

In addition, there is a special case of verification for a mobile device. The mobile device can inform the terminal, that verification of the cardholder has already been done (at device PIN entered or made by a finger). It should be noted that to select a verification method, a contactless card may not use the CVM List, which defines a list of methods and conditions for verifying the cardholder for the contact mode. For a number of applications, other objects are used that determine the choice of verification method for contactless mode. The risk management procedures performed by the terminal in contactless mode are quite simple. First, the terminal must compare the transaction amount with the Contactless Transaction Limit threshold amount. If the transaction amount exceeds this value, the contactless transaction is not executed. Second, the terminal compares the transaction amount with the CVM Required Limit threshold amount. When the transaction amount exceeds this threshold, the terminal considers that the cardholder must be verified. Usually, after this, the terminal issues the GET PROCESSING OPTIONS command, which sends the data necessary for the card to make a decision on how to process the transaction. This data is determined by the PDOL list and determines not only the parameters of the transaction, but also the capabilities of the terminal, as well as the result of pre-processing of the transaction by the terminal in contactless mode. The card performs risk management procedures and generates a CVR. When setting individual CVR bits, the signs of special situations that occurred during the processing of the previous transaction in contact mode are taken into account (the signs of special situations in contactless mode are usually not set).

After all procedures are completed, the card makes a decision about completing the transaction according to the CIAC1 array. One of the following decisions can be made:
▪ the transaction is approved offline
▪ requires on-line authorization of the transaction by the Issuer
▪ the transaction must be rejected
▪ switching to contact mode is required

The card can make the last decision if it is impossible (or undesirable) to perform a transaction in contactless mode due to a number of factors. However, the decision to switch to contact mode is made only if the terminal supports contact mode (otherwise, the transaction is rejected). Thus, the solution of the payment application is always consistent with the capabilities of the terminal and is final. Depending on the decision made, the card may provide different data. The only element that is always included in the returned data informs the terminal about the card selection. If the card returns a transaction cryptogram, it also provides other data that the terminal may need to continue processing (for example, to generate an authorization request to the Issuer). Among this data, there is an Application File Locator (AFL) element that contains links to the data that the terminal must read in order to successfully complete the transaction. After reading the AFL-defined data using the READ RECORD command, the kernel processing is completed by generating the result. Starting from this point in time, the card is no longer needed for further processing and can be removed from the terminal’s reading area. Further actions of the terminal depend on the result of processing the kernel. The following options are available.

1. Switching to contact processing mode is required. The terminal attempts to perform a transaction in contact mode.
2. The transaction is declined. The terminal finishes processing the transaction. Keep in mind that the CIAC for contactless mode may differ from the CIAC used for processing a transaction in contact mode. Or CIAC is not used at all for contactless mode.
3. Online processing must be performed. The terminal requests the PIN code, if required, generates an authorization request for the Issuer and sends this request to the host. The main difference between online transaction processing in contactless mode is that the Issuer’s response is checked not by the card (it has already been deleted), but by the terminal. Of course, the terminal can not perform authentication of the Issuer. Its decision to process the transaction must match the Issuer’s choice.