Processing a transaction using a microprocessor card

Introduction of alternative microprocessor card technology on the market, any card operation begins with the procedure for selecting the technology. At the technology selection stage, depending on the capabilities of the terminal and the card, a decision is made about which technology — the magnetic stripe or chip — will be used to perform the current transaction. The capabilities of the terminal are determined by the presence of a reader for reading data from the magnetic stripe and (or) a chip, as well as appropriate software capable of processing information from the magnetic stripe and (or) “chip” data. Similarly, the card’s capabilities are determined by the presence of a personalized magnetic stripe and / or chip with the appropriate application.
Of the two technologies, the more priority is the microprocessor card technology. If the microprocessor card gets into a terminal that can work with the chip, the terminal attempts to perform an operation using the chip. Otherwise, the operation is performed using a magnetic stripe, which is currently present on the microprocessor cards of leading payment systems, or is not performed at all if there is no magnetic stripe on the card.
However, the choice of the microprocessor card technology by the terminal does not mean that the operation will be performed using the selected technology. To do this, the card and terminal must support at least one common application.

The second stage of the transaction-the application selection stage-specifically checks whether there is such a shared application. Moreover, if there are several common applications, the terminal, the card, and possibly the cardholder choose which one to use to complete the current transaction.
After the application is selected, the terminal initiates the transaction. To do this, use the GET PROCESSING OPTIONS command, which is used by the terminal to tell the card the data it needs in order to determine the profile for performing the operation. Depending on the selected profile, in response to the transaction initialization command, the card informs the terminal about its capabilities to perform the transaction (support for card authentication methods and verification of the cardholder, as well as the Issuer’s authentication method) and the requirements for the terminal to perform the risk management procedure. In addition, in the same response, the card indicates to the terminal data (in the form of links to file names and record numbers containing this data) that the terminal must read in order to successfully complete the transaction.
The terminal reads all the entries indicated by the card and starts performing the card authentication procedures, checking restrictions on its use (application version number, card expiration date, operations available on the card, and geographical area of its use), checking stop lists, and verifying the cardholder. The terminal can also perform risk management procedures that control the volume of transactions and the number of consecutive offline transactions performed on the card.
Next, the terminal analyzes the results of its checks. The analysis is performed using the criteria formulated for the terminal by the servicing Bank and the card Issuer, and ends with one of three decisions: approve the transaction offline, pass the transaction to the card Issuer for authorization, and reject the transaction. The solutions listed are listed in ascending order of priority, which is set by the EMV standard.
The terminal informs the card of its decision using the first GENERATE AC command. The card performs its own procedures risk management and analyzes the checks performed by it based on the criteria formulated by its Issuer. The result of this analysis may be one of the solutions mentioned above. However, the priority of the decision made by the card must not be lower than the priority of the terminal’s decision. This restriction is fundamental to the transaction processing process and is monitored by the terminal.
If the card and the terminal decide that the transaction should be sent for authorization to the Issuer, the card generates a special cryptogram, which is a signature of the transaction details, the card and the terminal. The terminal sends the cryptogram and other transaction-related data to the Issuer. After receiving the data, the Issuer checks the cryptogram, thereby authenticating the card, as well as performs a number of other checks. Based on the results of these checks, it decides whether to reject or approve the transaction being processed and, in turn, generates a cryptogram that is used by the card to authenticate the Issuer. The Issuer sends its response to the servicing Bank.
The Issuer’s response may contain script-process-sing commands intended for the card. Using these commands, the Issuer can change the values of certain card parameters, unblock the PIN verification procedure that was previously blocked due to exceeding the limit on the number of incorrect PIN entries, or change its value, block/unblock the card application, or block the entire card. The Issuer can assign each team the status of critical or non-critical. In the first case, the command is sent to the card immediately after it is received by the terminal. In the second case, the command is passed after the card makes a final decision on the operation result.
After receiving the Issuer’s response, the terminal re-analyzes the checks performed by it and sends the second GENERATE AC command to the card, in which it transmits the Issuer’s decision, the cryptogram generated by the Issuer, and the updated data of its checks to the card. If the Issuer’s response contained critical script processing commands, they are passed to the card before the second GENERATE AC command is executed.
If the Issuer authentication was successful, the card fulfills the Issuer’s will, obtained from the data of the GENERATE AC command. Otherwise (authentication failed), the transaction is usually rejected by the card.
Non-critical commands are executed after sending the second GENERATE AC command to the card, provided that the Issuer is successfully authenticated.
A detailed description of the individual stages of transaction processing is provided below.
Choice of technology
Cards with a microprocessor have a service code value equal to 2xx for international cards and bxx for cards that are used only within the country. The service code is present both on the magnetic stripe of the card and in the mandatory data object Track 2 Equivalent Data (Tag y57′) of the microprocessor card. The data in the Track 2 Equivalent Data object and on the magnetic stripe must be identical. The terminal or servicing Bank uses this data to form an authorization request to the Issuer.
If a service code of the type 1xx or 5xx is marked on the magnetic stripe of the card, then the terminal considers such a card as a card with a magnetic stripe only. Accordingly, the transaction on such a card is made on the basis of data read from the magnetic stripe of the card (we are talking about accepting the card in an electronic terminal).
An electronic POS terminal can be one of the following types, depending on its ability (availability of the appropriate card reader and application software):
the terminal is able to process transactions only for cards with a magnetic strip and unable to handle the operation of microprocessor cards;
a terminal that can process transactions on both magnetic stripe cards and microprocessor cards (hybrid terminal).
There are, of course, terminals that accept only microprocessor cards. However, in practice, they are not yet used in the largest payment systems.
If the card is used in the first type of terminal, regardless of the value of the card’s service code, it will be processed as a card with only a magnetic stripe. If the second type of terminal is used (hybrid terminal), the basic rule is that when accepting a card with the service code 2xx or bxx, the terminal must first try to perform an operation using the chip and, only if for some technical reasons it is not possible to do this, try to perform an operation using the magnetic stripe. In other words, microprocessor technology is a higher priority than magnetic stripe technology when both the terminal and the card support this technology.
When the terminal has two separate readers for reading card data (a magnetic stripe reader and a microprocessor reader), it may happen that the cashier at the point of sale will try to perform a magnetic stripe operation first. In this case, the terminal application should use the value of the service code read from the second track of the magnetic stripe to determine whether an attempt to process the card using a chip is necessary and inform the merchant’s cashier about this.
The General scheme of card processing in a hybrid terminal (CAT terminals are not considered) is shown in Fig. 4.2. The diagram describes both types of hybrid terminals: a terminal with two separate readers for the magnetic stripe and chip, and a terminal with a combined reader that can read data from the magnetic stripe and chip. In the case of a combined reader, the transaction review begins with the “chip reader” block.

In some cases, the transaction cannot be processed using the chip. The reasons for this can be very diverse, starting with the fact that the terminal can’t select the application it supports on the card chip, and ending with various types of incompatibility between the card and the terminal. All these types of incompatibilities are the result of the fact that the card and / or terminal do not meet the EMV standard or / and payment system application specifications. (The most common types of non-compliance with the requirements of the EMV standard.)

The General scheme of processing of the card in a hybrid terminal
If the transaction cannot be processed using the chip, the terminal may decide to switch to magnetic stripe card service. If the reason for switching to the magnetic stripe was an incompatibility between the card and the terminal, otherwise in card jargon it is called a fallback to the magnetic stripe.
For transactions served in Fallback mode, the following rule applies, adopted by leading payment systems: all fallback transactions must be authorized online (except for SATZ terminals) and have a POS Entry Data element (DE 022) = 80X (in the terminology of the MasterCard payment system).
There are several reasons why payment systems prohibit switching to Fallback mode. Switching to Fallback mode is prohibited:
if the response to the SELECT command indicates that the card is blocked;
if the response to the SELECT command indicates that the selected card application is blocked;
after completing the chip transaction (the card returned the vehicle or AAS cryptogram to the terminal);
if there was a manual error (the card was removed from the terminal before the operation was completed, the card was inserted incorrectly in the reader) or a terminal error (loss of power supply, etc.).
Selecting an app
A microprocessor card, as well as a terminal, can support multiple applications. The terminal stores a list of AID IDs of applications supported by the terminal. When the cardholder is going to perform an operation using the IPC via the terminal, they must select the card application supported by both the card and the terminal together with the terminal. The procedure for selecting such an application (Application Selection) marks the beginning of any transaction using IPC and consists of two stages.

The goal of the first stage is to build a list of applications that are simultaneously supported by the card and the terminal. This list is called the candidate application list. The second step is to select the application to perform the operation from the list of candidate applications built in the previous step.
There are two ways to select an application (building a list of candidate applications):
direct or explicit application Selection, when the terminal builds a list of candidate applications by repeatedly polling the card for support for specific applications. In other words, the terminal consistently sends SELECT commands to the card with file names equal to the AID THAT are in the list of application IDs supported by the terminal. If the card response indicates that the card supports an application with the file name specified in the SELECT command, the application is placed in the list of candidate applications;
indirect or implicit application Selection when the PSE directory is used to select an application. In this case, the terminal sends the select command to the card with the DF Name equal to 1PAY.SVS.DDF01. After receiving the name of the SFI file DIR (DEF file of the PSE directory) in response to the command, the terminal sequentially reads the records of this file using the READ RECORD command, extracting Application Template templates (Tag ’61’) containing information about all ADF files contained in the PSE. Based on this information, the terminal builds a list of candidate applications.
To select an application, you must also set a match between the AID application ID (Tag ‘9F06′) contained in the list of applications supported by the terminal and the card application ID. When using the direct app selection method, the ADF file name (DF Name, Tag ’84’) acts as the card app ID. When you use the implicit application selection by application identifier is the object of the AID (Tag ‘4F’), JAV-
which is a mandatory element of the Application Template object (Tag “61′) for any ADF file (see clause 3.7).
There are two criteria for compliance:
full match of the names AID (Tag ‘9F06′) and DF Name (Tag ’84’)/ AID (Tag ‘4F’) when the length and values of the Value fields of the specified data objects match;
partial name matching when the terminal’s AID data element is the beginning of the DF Name of the card/ AID ADF file (Tag ‘4F’). As explained in the description of the SELECT command (see clause 3.10), the card and terminal can support the procedure for selecting an application by partial name (for the card, support for this method of selecting an application is optional). in this case, the terminal can restrict the list of supported applications considered as candidates for selection.
When using the criterion of matching on partial name of the application it is necessary to card:
supported the partial app selection procedure;
there were no applications whose ID matched the partial name from the list of terminal applications.
Note that the list of application IDs supported by the terminal, when using partial name matching, must contain the Application Selection Indicator value for each AID. The Application Selection Indicator indicates the type of criteria used — full match or partial match of names applied for this AID terminal.

Building a list of candidate applications using PSE
The algorithm described below follows the description given in section 12.3.2 Of book 1 of the EMV 4.1 standard.
Step 1. Checks whether the PSE directory is present on the card. The terminal sends the SELECT command to the card with the parameters DF Name = 1PAY.SYS.DDF01, P2 = ’00’h, Lc =’ 0’H.
If the response to the SELECT command contains SW1SW2 = ‘ 6A81’h (invalid parameters P1 and P2; the function is not supported this means that either the card is blocked, or it does not support the SELECT command with a file name reference.
If the response to the SELECT command contains SWlSW2= ‘ 6A82’h (invalid parameters P1 and P2; the file was not found), it means that the card does not support PSE, and in this case, the direct method of selecting the application described in the next section should be used to build the list of candidate applications.
If the response to the SELECT command contains SWlSW2=6283’h (the non-volatile memory state has not changed, the selected file is blocked), it means that the PSE directory exists on the card, but is blocked. In this case, the direct method of selecting an application must be used to build a list of candidate applications. If the response to the SELECT command contains SWlSW2= ‘ 9000’h, the terminal determines the SFI value of the DIR directory file from the FCI Template contained in the response to the SELECT command.
If you receive responses to commands sent to the card in steps 2-5 other than ‘9000’h and ‘6A83’h, the terminal must erase the list of candidate applications it created and start using the direct method of selecting applications.
Step 2. The terminal uses the READ RECORD command to read all entries in the DIR file sequentially, starting with entry number 1 and continuing reading until it receives a response with SWlSW2=’6A83’h in response to the READ RECORD command.
This response corresponds to the fact that the entry with the specified number is not contained in the DIR file. This last circumstance means that the terminal has read all entries in the DIR file. Each record read by the terminal is processed in accordance with steps 3-5 of this algorithm.
If the response with SWlSW2= ‘ 6A83’h comes to the READ RECORD command, which is intended for reading the first entry of the DIR file (i.e. there are no entries in this file), then you go to Step 5.
Stepz. Each entry in the DIR file (AEF Data Template, Tag 70’h) consists of Application Template (Tag ’61’) templates corresponding to ADF and DDF files. Let’s assume that the Application Template processed by the terminal belongs to an ADF file. Then if the AID (Tag ‘4F’) in the Application Template object meets the matching criteria with one of the AID list of applications supported by the terminal, then this AID value, along with the rest of the information contained in the Application Template, is included in the list of candidate applications.
Step 4. If the Application Template processed by the terminal is a DDF file, the terminal finds the required DDF Name element in the Application Template (Tag ‘9D’). Using the SELECT command with a name selection, the terminal determines the name of the SFI file in the DDF file directory and then repeats steps 2-5 of this algorithm to search for candidate applications that meet the criteria for matching one of the AID list of applications supported by the terminal. After analyzing all applications in this DDF directory, the terminal starts analyzing the next Application Template in order.
Step 5. The algorithm stops building a list of candidate applications after analyzing all the Application Template templates in the DIR file. After that, the procedure for selecting an application from the built list of candidate applications begins.
The procedure for selecting candidate applications from the PSE is effective if the terminal supports a large number of applications.
Building a list of candidate applications using a direct selection procedure
The algorithm described below corresponds of the EMV 4.1 standard. This method is effective if the number of IDs when-
there are few exceptions in the list of applications supported by the terminal.
Step 1. Sequentially, starting from the first AID ID of the list of applications supported by the terminal, the terminal sends the SELECT command to the card with the parameters DF Name=AID and P2= ‘ 00’h.
Step 2. If the processing of the command is unsuccessful because the card is blocked or does not support the SELECT command with a name selection (SWlSW2=’6A81’h), the terminal terminates the session installed with the card, and the transaction is not processed further (it is possible to switch to the magnetic stripe Fallback mode).
Stepz. If the SELECT command is processed successfully (SWlSW2= ‘9000’h or SWlSW2=’ 6283’h), the terminal compares the AID ID with the DF Name (Tag ’84’) obtained from the FCI Template object contained in the command response. The AID ID can either be identical to DF Name,or it can be the beginning of the DF Name. If the AID and DF Name are identical, the terminal proceeds to perform Step 4 of this algorithm. Otherwise, the card processes the SELECT command as a partial name selection command, and the terminal proceeds to Step 6.
If the response to the SELECT command contains SW1SW2 values other than ‘6A81’h, ‘9000’h, ‘6283’h, the terminal proceeds to Step 5.
Step 4. If the response to the SELECT command contains the value SWlSW2= ‘ 9000’h, the terminal adds AID to the list of candidate applications and proceeds to Step 5. If the response to the SELECT command contains the value SWlSW2=6283’h, which means that the application is blocked, the terminal does not add AID to the list of candidate applications and proceeds to Step 5.
Step 5. If the list of applications supported by the terminal is not yet complete, the terminal selects the next AID ID from the list and sends the SELECT command to the card with the parameters DF Name=AID and P2= ‘ 00’h, repeating the steps of this algorithm, starting from Step 3.
If the list of applications is exhausted, the terminal starts the procedure for selecting an application from the built list of candidate applications.
Step 6. The terminal checks the Application Selection Indicator value corresponding to the AID value under consideration. If the value requires applying the full name match criterion, the application is not added to the list of candidate applications, and the terminal proceeds to Step 5.
If the Application Selection Indicator value indicates that the partial name matching criterion is used and the application is not blocked (SWlSW2= ‘ 9000’h), it is added to the list of candidate applications, and the terminal proceeds to Step 7.
If the Application Selection Indicator value indicates that the partial name match criterion is used and the application is blocked (SW1SW2 ‘9000’h), the application is not added to the list of candidate applications, and the terminal proceeds to Step 7.
Step 7. The terminal sends the SELECT command to the card with the same AID value, but with the value P2= ‘ 02’h (Select Next). If the card returns a response with SWlSW2= ‘9000’h, SWlSW2=’ 62xx’h, and SWlSW2= ‘ 63xx’h, the terminal returns to Step 3. If the card returns any other response, the terminal returns to Step 5.
Final app selection
It is assumed that the terminal has built a list of candidate applications that are mutually supported by the card and the terminal.
Step 1. If the list of candidate applications is empty, the transaction ends.
Step 2. If the list of candidate applications contains the only application supported simultaneously by the card and the terminal, the terminal checks the value of bit B8 in the Application Priority Indicator if
the latter is present in the FCI Proprietary Template of the candidate application.
If B8=0, the terminal selects this application.
If B8=1, the terminal asks the cardholder for confirmation of the application selection. If the terminal cannot request confirmation (for example, the terminal does not have a display), or if the terminal does not receive confirmation from the cardholder in response to its request, it completes the transaction without selecting applications.
Step Z. If the list of candidate applications contains several applications, the terminal can ask the cardholder to select the application according to the description of Step 4 of this algorithm, or it can select it independently according to the description of Step 5. The first approach (choosing Step 4) is preferable.
Step 4. The list of candidate applications is presented to the cardholder for their choice of application. The list should be presented in the order in which the application with the higher priority is in the list before the application with the lower priority. If the card application’s FCI Proprietary Template objects do not contain the Application Priority Indicator, the applications must be presented to the cardholder in the order in which they were encountered on the card, unless the terminal has determined its preferences in the application view.
The same application representation rule applies within a group of candidate applications that have the same priority, and a group of applications for which the Application Priority Indicator is not defined in the FCI Proprietary Template. In this case, the terminal can either define its own order of representation of such applications within the group, or display the applications within the group in the order in which they occur on the card. The groups themselves are ordered by the terminal according to their priorities (an application group with an undefined priority is considered the lowest priority).
Applications are represented on the terminal display using the application Preferred Name (if present on the card) in the encoding specified by the Issuer Code Table Index. If the Application Preferred Name element is not present on the card, the required Application Label data element is used to represent the application on the terminal display.
Step 5. The terminal can select an app without the help of a card holder. There are two cases.
In the first case, the terminal can request the cardholder to confirm the application selected by the terminal. In this case, the application with the highest priority is selected from the list of candidate applications. If the selected application has a bit B8 of the Application Priority Indicator equal to 0, the terminal selects this application. If B8=1 is executed, the terminal displays either the Application Preferred name of the application in the encoding specified by the Issuer Code Table Index, if these data elements are present, or the Application Label of the application selected by the terminal. Only after the cardholder confirms the terminal selection is this application considered to be finally selected.
In the second case, the terminal cannot request confirmation of the application selected by the terminal from the cardholder. In this case, the list of candidate applications is narrowed to a list of applications that have the bit B8 of the Application Priority Indicator equal to 0.
Initializing a transaction
After selecting an application, the terminal must put ourselves in a state of readiness to implement the new operation. To do this, it must reset the values of parameters used to display the results of various procedures performed by the terminal during the processing of the current transaction. These terminal parameters include, in particular, Terminal Verification objects
Results (TVR, Tag ’95’, 5 bytes) and Transaction Status Information (TSI, Tag ‘9B’, 2 bytes). (For other data objects— CVM Results and Issuer Script Results — see sections 4.7 and 4.12.) Resetting the parameters means that the values of all bits in the data fields of the TVR, TSI, CVM Results, and issue Script Results objects are set to 0.
The TVR object has a size of 5 bytes and records the results of checks performed by the terminal during the processing of the current transaction. In summary, TVR bytes display information based on the results of the following types of checks:
byte 1-results of performing the card authentication procedures;
byte 2 — the results of inspections restrictions on the use of the card (Processing Restrictions);
byte 3 — the results of verification of the cardholder (Cardholder Verification);
byte 4-results of terminal risk Management procedures performed by the terminal);
byte 5-results of performing Issuer authentication and Script Processing procedures.