Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 963
- Points
- 113
This chapter will walk you through all the steps in the processing of a microprocessor card initiated transaction.
In fig. 4.1 shows a general diagram of transaction processing.
As can be seen from the figure, with the appearance on the market of an alternative to the magnetic stripe technology of microprocessor cards, any card transaction begins with the procedure for choosing a technology. At the stage of choosing a technology
Diagram of the stages of the logic transaction, depending on the capabilities of the terminal and the card, a decision is made on which technology - magnetic stripe or chip - will be used to execute the current transaction. The capabilities of the terminal are determined by the presence of a reader for reading data from a magnetic stripe and / or a chip, as well as appropriate software capable of processing information from a magnetic stripe and / or "chip" data. Similarly, the capabilities of the card are determined by the presence of a personalized magnetic stripe and / or a chip with a corresponding application on it.
Of the two technologies, the higher priority is the technology of the microprocessor card. If a microprocessor card gets into a terminal that can work with a chip, then the terminal makes an attempt to perform an operation using the microcircuit. Otherwise, the operation is carried out using a magnetic stripe, which today is necessarily present on the microprocessor cards of leading payment systems, or is not carried out 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 carried out using the selected technology. This requires that the card and terminal support at least one common application. The second phase of the transaction — the application selection phase — specifically verifies that such a common application exists. Moreover, if there are several common applications, then the terminal, the card, and possibly the cardholder choose which one to use for the current transaction.
After the application is selected, the terminal initiates the transaction. For this, the GET PROCESSING OPTIONS command is used, with the help of which the terminal informs the card with the data it needs in order to determine the profile of the operation. Depending on the selected profile, in response to the transaction initialization command, the card informs the terminal about its capabilities to carry out the transaction (about the support of card authentication and cardholder verification methods, as well as the issuer authentication method) and the requirements for the terminal if it needs 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 their record numbers) that the terminal must read in order to successfully complete the transaction.
The terminal reads all records indicated by the card and proceeds to perform card authentication procedures, check restrictions on its use (application version number, card validity period, transactions available on the card and geographic restrictions on card use), check stop lists, verify the holder cards. The terminal, at the direction of the card, can also execute risk management procedures that control the volume of transactions and the number of consecutive offline transactions performed using the card.
Then the terminal analyzes the results of the checks it has performed. The analysis is carried out using the criteria formulated to the terminal by its servicing bank (more precisely, by the payment system through the servicing bank) and the card issuer, and ends with one of three solutions: approve the transaction offline, transfer the transaction for authorization to the card issuer, reject the transaction offline.
The terminal informs the card about its decision using the first command GENERATE AC. The GENERATE command informs the card about the most important transaction data (size and type of operation), the results of the terminal's risk management procedure, as well as the terminal details (type of terminal, its ability to process a transaction, etc.). Based on the data received, the card performs its own risk management procedures and analyzes the checks performed by it on the basis of the criteria formulated by the card issuer. The result of this analysis may be one of the solutions mentioned above. However, there is a dependency between the solutions of the card and the terminal. If all possible solutions are ranked as follows: 1) approve the transaction, 2) send the transaction for authorization to the issuer, 3) reject the transaction, then the card's decision rank is always not lower than the terminal's decision rank (the terminal always makes a decision first during transaction processing). According to EMV, this dependence is fundamental to the transaction processing process and is controlled by the terminal.
If the card and the terminal decide that the transaction should be sent for authorization to the issuer, then the card generates a special cryptogram, which is a signature of the transaction, card and terminal details. The terminal sends (of course, through the host of the serving bank) the cryptogram as well as other transaction-related data to the issuer. Having received the data, the issuer checks the cryptogram, thereby authenticating the card, and also performs a number of other checks. Based on the results of these checks, he 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, which forwards it to the terminal.
The issuer's response may contain script processing commands for the card. Using these commands, the issuer has the ability to change the values of some card parameters, unblock the PIN-code verification procedure, which was previously blocked due to exceeding the limit on the number of incorrect PIN-code entries, block / unblock the card application or block the entire card. The issuer has the ability to assign critical or non-critical status to each command. 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 transferred after the card has made a final decision on the result of the operation.
The terminal, having received the issuer's response, on its basis re-analyzes the checks performed by it and sends the card a second GENERATE AC command, in which it sends the card the issuer's decision, the cryptogram generated by the issuer, and the updated data of its checks. 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 authentication of the issuer is successful, then the card performs the will of the issuer obtained from the data of the GENERATE AC command. Otherwise (issuer authentication failed), the card transaction is usually rejected.
Non-critical commands are transmitted to the card after the second GENERATE AC command is sent, provided that the issuer is successfully authenticated.
Below is a detailed description of the individual steps in transaction processing.
In fig. 4.1 shows a general diagram of transaction processing.
As can be seen from the figure, with the appearance on the market of an alternative to the magnetic stripe technology of microprocessor cards, any card transaction begins with the procedure for choosing a technology. At the stage of choosing a technology
Diagram of the stages of the logic transaction, depending on the capabilities of the terminal and the card, a decision is made on which technology - magnetic stripe or chip - will be used to execute the current transaction. The capabilities of the terminal are determined by the presence of a reader for reading data from a magnetic stripe and / or a chip, as well as appropriate software capable of processing information from a magnetic stripe and / or "chip" data. Similarly, the capabilities of the card are determined by the presence of a personalized magnetic stripe and / or a chip with a corresponding application on it.
Of the two technologies, the higher priority is the technology of the microprocessor card. If a microprocessor card gets into a terminal that can work with a chip, then the terminal makes an attempt to perform an operation using the microcircuit. Otherwise, the operation is carried out using a magnetic stripe, which today is necessarily present on the microprocessor cards of leading payment systems, or is not carried out 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 carried out using the selected technology. This requires that the card and terminal support at least one common application. The second phase of the transaction — the application selection phase — specifically verifies that such a common application exists. Moreover, if there are several common applications, then the terminal, the card, and possibly the cardholder choose which one to use for the current transaction.
After the application is selected, the terminal initiates the transaction. For this, the GET PROCESSING OPTIONS command is used, with the help of which the terminal informs the card with the data it needs in order to determine the profile of the operation. Depending on the selected profile, in response to the transaction initialization command, the card informs the terminal about its capabilities to carry out the transaction (about the support of card authentication and cardholder verification methods, as well as the issuer authentication method) and the requirements for the terminal if it needs 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 their record numbers) that the terminal must read in order to successfully complete the transaction.
The terminal reads all records indicated by the card and proceeds to perform card authentication procedures, check restrictions on its use (application version number, card validity period, transactions available on the card and geographic restrictions on card use), check stop lists, verify the holder cards. The terminal, at the direction of the card, can also execute risk management procedures that control the volume of transactions and the number of consecutive offline transactions performed using the card.
Then the terminal analyzes the results of the checks it has performed. The analysis is carried out using the criteria formulated to the terminal by its servicing bank (more precisely, by the payment system through the servicing bank) and the card issuer, and ends with one of three solutions: approve the transaction offline, transfer the transaction for authorization to the card issuer, reject the transaction offline.
The terminal informs the card about its decision using the first command GENERATE AC. The GENERATE command informs the card about the most important transaction data (size and type of operation), the results of the terminal's risk management procedure, as well as the terminal details (type of terminal, its ability to process a transaction, etc.). Based on the data received, the card performs its own risk management procedures and analyzes the checks performed by it on the basis of the criteria formulated by the card issuer. The result of this analysis may be one of the solutions mentioned above. However, there is a dependency between the solutions of the card and the terminal. If all possible solutions are ranked as follows: 1) approve the transaction, 2) send the transaction for authorization to the issuer, 3) reject the transaction, then the card's decision rank is always not lower than the terminal's decision rank (the terminal always makes a decision first during transaction processing). According to EMV, this dependence is fundamental to the transaction processing process and is controlled by the terminal.
If the card and the terminal decide that the transaction should be sent for authorization to the issuer, then the card generates a special cryptogram, which is a signature of the transaction, card and terminal details. The terminal sends (of course, through the host of the serving bank) the cryptogram as well as other transaction-related data to the issuer. Having received the data, the issuer checks the cryptogram, thereby authenticating the card, and also performs a number of other checks. Based on the results of these checks, he 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, which forwards it to the terminal.
The issuer's response may contain script processing commands for the card. Using these commands, the issuer has the ability to change the values of some card parameters, unblock the PIN-code verification procedure, which was previously blocked due to exceeding the limit on the number of incorrect PIN-code entries, block / unblock the card application or block the entire card. The issuer has the ability to assign critical or non-critical status to each command. 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 transferred after the card has made a final decision on the result of the operation.
The terminal, having received the issuer's response, on its basis re-analyzes the checks performed by it and sends the card a second GENERATE AC command, in which it sends the card the issuer's decision, the cryptogram generated by the issuer, and the updated data of its checks. 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 authentication of the issuer is successful, then the card performs the will of the issuer obtained from the data of the GENERATE AC command. Otherwise (issuer authentication failed), the card transaction is usually rejected.
Non-critical commands are transmitted to the card after the second GENERATE AC command is sent, provided that the issuer is successfully authenticated.
Below is a detailed description of the individual steps in transaction processing.
