Contact mode transaction processing

The terminal reads all entries specified by the card using the READ commands RECORD and proceed to perform offline data authentication, provided by card. At this point completely can be performed only SDA or DDA authentication. Data authentication by the method of CDA (due to the peculiarities of the implementation) is performed completely only after receiving a response from the first GENERATE AC command. The terminal then proceeds to perform constraint checking procedures on application application (version numbers are checked, the term is checked card actions, etc.) and stop-list control. The terminal looks through the list of cardholder verification methods, provided by the card, selects the appropriate method and verifies cardholder. The terminal at the direction of the card can also perform control procedures risks controlling the amount and number of consecutive transactions performed in offline. Next, the terminal analyzes the results of its checks with using the criteria formulated by the terminal servicing Bank and card Issuer. As a result, the terminal accepts one of three decisions on the handling of the transaction:

1. To approve the transaction in offline mode.

2. Transfer the transaction to the card Issuer for authorization.

3. Reject the transaction in offline mode.


Together with the GENERATE AC command the card is transferred transaction data, the results of the terminal risk management procedure and details of the terminal. Based on the data obtained, the card performs own risk management procedures and performs analysis the results of its tests using criteria, by the card Issuer. As a result, the card accepts the native transaction processing solution is one of three solutions, described above, but the rank of the solution card is always not lower than the rank of the solution terminal (for example, if the terminal has decided to reject transaction, the card has no right to change this decision). In EMV this the dependency is fundamental and is controlled by both the card and terminal.

If the card decides that the transaction should be sent for authorization to the Issuer, the card forms a special cryptogram, which is a signature of transaction details, cards and terminal. In all other cases cryptograms are formed, informing about the completion of the transaction (approval or rejection transactions in offline mode). In addition, in case of use the authentication method CDA cryptogram is entered in a special package data, which is encrypted on the card key and serves for offline data authentication by the terminal. The terminal, having received data from the card by the GENERATE AC command, executes card authentication if the CDA authentication method is used (decrypts the data packet with the cryptogram and makes sure that the data is in the package is correct). Then, the terminal checks the kind of cryptogram returned card . If a transaction approval or rejection cryptogram is returned in offline mode, the processing is completed. When the transaction must be sent for authorization to the Issuer, the terminal sends (through the host of the servicing Bank) cryptogram and other related transaction data to the Issuer. After receiving the data, the Issuer authorizes the transaction (checks the cryptogram and some of the other parameters). Based on the results of these audits, the Issuer makes a decision on whether to reject or approve the transaction and, in its the queue forms a cryptogram that is used by the card to authentication of the Issuer. The Issuer’s response is sent to the service provider the Bank that sends it to the terminal. The response of the Issuer may contain the command script processing, designed for the card. With these commands the Issuer has the ability to change the parameters of the payment application, unlock or change PIN, lock card app.

The Issuer may assign critical status to each script processing command (command sent to the card immediately after receiving it by the terminal before execution check the Issuer’s response) or non-critical (the command is transmitted to the card after verification of the Issuer’s response). The terminal, having received the Issuer’s response, transmits the Issuer’s decision to the card, the Issuer’s cryptogram and the updated data of its checks in the second the GENERATE AC command (or the EXTERNAL AUTHENTICATE command if the payment application uses this command to verify the response issuer’s). The card authenticates the Issuer by verifying the cryptogram. If the Issuer authentication was successful, the card performs the Issuer’s decision to complete the transaction forms the cryptogram approval or rejection of the transaction. When authentication of the Issuer failed, the transaction is usually rejected. Below is a more detailed description of the individual processing steps transactions and data objects exchanged between the terminal and the card.