Online processing emulation EMV parameters

You should immediately say that online processing is modeled only for contact mode, since in contactless mode, the terminal emulator always performs a transaction for one touch of the terminal. After you finish working with the card and get all the data from it, the emulator considers that processing is complete. In the real terminal, the Issuer’s response is analyzed and a decision is made to approve or reject the transaction. These actions are never performed in the terminal emulator, because they will not provide anything new for checking the payment application.

For the contact mode, emulating the online mode makes sense, since the work with the card after receiving all the data from it to form an authorization request to the Issuer is not yet complete. In real life, the terminal sends a message to the host of the servicing Bank that contains information about the transaction. Based on this data, the host of the servicing Bank generates an authorization request (message X100 of the ISO 8583 standard).

However, the terminal emulator is not intended for communication with the servicing Bank and the Issuer. No messages to the host of the servicing Bank or authorization requests to the Issuer are generated. Instead, the emulator can simulate various options for getting the Issuer’s response (or not). The main parameter for emulating online processing is the simulated situation, which is selected from the list of options defined by the combobox “gac2 Type” 1. From the list defined by this element, one of the following terminal actions is selected when executing the second GENERATE AC command:
▪ an AAC cryptogram must be requested (transaction rejection)
▪ a TC cryptogram is requested with a simulation of the “Unable to go Online” situation»
▪ the TC cryptogram is requested (the situation “Issuer’s Data is not provided” is simulated»)
▪ the TC cryptogram is requested (the situation “Issuer Authentication failed” is simulated for the payment application»)
▪ in the second GENERATE AC command, the TC cryptogram is requested and the Issuer’s data is provided, which allows the payment application to successfully authenticate the Issuer (for the application, the full response of the Issuer is simulated)

Further discussion of the features of the above options is still to be done, but in the meantime, we need to discuss other parameters for emulating the online mode. It should be noted immediately that the online mode emulation was developed for applications that meet the EMV CCD (Common Core Definitions) specifications. And for a number of payment applications, online mode parameters (data objects) are not used (not applicable). One of these data objects is the Card Status Update (CSU), which indicates whether the transaction was approved or rejected by the Issuer, and also defines the actions that the card should perform from the Issuer’s point of view (see Fig. 11). Defining attributes in the CSU is ignored if the Issuer’s host does not need to use the CSU to manage the payment application. As shown in Fig. 11, the ECV testing package also provides the ability to generate critical and non-critical commands, Meaning the type of requested cryptogram in the second GENERATE AC command. From the following discussion, it will be clear that the list determines not only the type of cryptogram requested, but also the various options for online processing.

Script processing commands are generated in accordance with EMV CCD specifications. The fact is that the Issuer uses the Secure Messaging algorithm when creating script processing commands. The main goals of Secure Messaging are to ensure data integrity, provide the ability to authenticate the data source, and guarantee the confidentiality of sensitive data. The Secure Messaging algorithm for the EMV CCD application is implemented in accordance with Secure Messaging Format 1, which is described in the document ” EMV. Integrated Circuit Card Specifications for Payment Systems. Book 2. Security and Key Management. Version 4.2. June 2008″. Two important conclusions follow from this. First, if the script processing commands for the analyzed payment application are not generated in accordance with Secure Messaging Format 1, then the script processing command definition tool provided in the testing package cannot be used. Second, as you can easily guess, the terminal emulator requires payment application keys to create script processing commands (see the section “Defining keys”). Now let’s return to the discussion of options for the terminal emulator when executing the second GENERATE AC command. As described above, the user can choose one of five options to emulate online processing. The actions of the terminal emulator depend on the selected option. But in any case, the emulator does the following:
▪ before executing the second command, GENERATE AC passes critical script processing commands to the card, if they are defined
▪ after executing the second command, GENERATE AC sends critical script processing commands to the payment application, if it is used

Other actions of the terminal emulator depend on the selected scenario. Reject the transaction. In this case, the actions of the terminal emulator are not interesting at all, since the payment application ignores the data provided in the second GENERATE AC command, and always returns the AAC cryptogram (transaction rejection) transaction Approval in the “Unable to go Online” situation, the terminal Emulator informs the payment application about this situation in the second GENERATE AC command, requesting transaction approval. Zeros are usually passed instead of the Issuer’s data.

Approval of a transaction in the “Issuer’s Data is not provided” situation is Not much different from the “Unable to go Online” situation. However, there are differences in the data passed to the payment application in the second GENERATE AC command, so the behavior of the payment application may differ. Transaction approval and simulation of the “Issuer Authentication failed” situation the terminal Emulator requests transaction approval in the second GENERATE AC command, passing a random number as the Issuer’s cryptogram (it is assumed that it will never match the cryptogram that the Issuer must generate in response to the authorization request). Approving a transaction with full emulation of the Issuer’s response the second GENERATE AC command requires approval of the transaction with the provision of data that allows the payment application to successfully authenticate the Issuer and perform the actions requested by the Issuer. For this option, the terminal emulator requires payment application keys (see the section “Defining keys”). It remains only to describe the two switches shown in Fig. 11. The “CDA” switch allows you to request a Signed Dynamic Application Data certificate from the payment application (used for the CDA offline authentication method), not only in the first, but also in the second GENERATE AC command. Although this option seems unnecessary at first glance, getting the CDA method certificate in the second GENERATE AC command is defined by the EMV specifications for special cases. Thus, the “CDA” switch allows you to check whether the payment application is able to provide a Signed Dynamic Application Data certificate in the second GENERATE AC command. The “Reject in case of Unable to go Online” switch reflects the option that is available to the servicing Bank for setting up a terminal that works only in online mode. For such terminals, it may be determined that in the case of an Unable to go Online situation, the transaction must be rejected without TAC/IAC analysis.