Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 963
- Points
- 113
After selecting the application, the terminal must prepare for the current operation. To do this, he must reset the values of the parameters used to display the results of various procedures performed by the terminal during the processing of the current transaction. Such terminal parameters, in particular, include Terminal Verification Results objects (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 paragraphs 4.7 and 4.12.) Resetting parameters means that the values of all bits of the data fields of the TVR, TSI, CVM Results and Issuer Script Results objects are set to 0.
The TVR object is 5 bytes in size and records the results of checks performed by the terminal during the processing of the current transaction. The bytes of the data field of the TVR object display information on the results of the following types of checks:
A detailed view of the TVR data object is presented in table. 4.1-4.5.
Tab. 4.1. Byte 1 TVR (leftmost)
Tab. 4.2. Byte 2 TVR
Tab. 4.3. Byte 3 TVR
Meaning
Cardholder verification was not successful (the cardholder verification procedure was unsuccessful) Unrecognized CVM (the terminal does not understand the verification method)
PIN Try Limit exceeded
PIN entry required and PIN pad not present or not working
PIN entry required, PIN pad present, but PIN was not entered
The end of the table. 4.3
Tab. 4.4. Byte 4 TVR
Default TDOL used
Issuer Authentication was unsuccessful
Script Processing failed before final GENERATE AC (the script processing procedure failed before the 2nd GENERATE AC command)
Script Processing failed after final GENERATE AC (the script processing procedure failed after the 2nd GENERATE AC command)
Reserved for use
Reserved for use
Reserved for use
Reserved for use
The purpose and way of filling the bits of the TVR object will be discussed in the course of the description of the transaction processing procedures.
The TSI data object consists of two bytes. All bits of the second byte are reserved for future use, and the structure of the first byte is shown in Table. 4.6.
Tab. 4.6. Byte 1 TSI
B8
B7 | b6 | b5 | b4 | b3 | b2 | b
Meaning
Offline data authentication was performed
Cardholder verification was performed
Card risk management was performed
Issuer authentication was performed
Terminal risk management was performed
Issuer Script Processing was performed
Reserved for use
О Reserved for use
As you can see from the table. 4.6, the TSI data object records a list of the main procedures performed by the terminal and the card during transaction processing. The purpose of the bits and the method of filling TSI will be discussed in the course of the description of the transaction processing procedures.
After selecting the application and resetting its internal parameters, the terminal sends the GET PROCESSING OPTIONS command to the card. The main details of this command are presented in table. 4.7.
Tab. 4.7. GET PROCESSING OPTIONS command structure
Chapter 4. PROCESSING TRANSACTIONS BY MICROPROCESSOR CARD 293
G
MasterCard ^? 9
As you can see from the table. 4.7, the data field of the GET PROCESSING OPTIONS command is a concatenation of the Value fields of the data objects listed in the PDOL if the PDOL list is contained in the FCI Template of the selected card application (in this case, the PDOL list is obtained by the terminal from the FCI Proprietary Template data object contained in the card response to SELECT command).
If the PDOL list is not in the FCI Proprietary Template of the selected application, then in the data field of the GET PROCESSING OPTIONS command, the value of the Length field of the data object with Tag '83' is 0, and the data field of this object is absent.
If the PDOL is contained in the FCI Proprietary Template of the selected application, then it consists of the Tag and Value fields of those data objects whose values the map application needs to determine the most efficient way to process the current transaction. Such data may include transaction size (Amount, Authorized, Tag '9F02'), transaction currency (Transaction Currency Code, Tag '5F2A'), terminal type (Terminal Type, Tag '9F35'), terminal functionality (Terminal Capabilities , Tag '9F33'), terminal country code (Terminal Country Code, Tag '9F1A'), merchant type (Merchant Category Code, Tag '9F15'), transaction type (Transaction Type, Tag '9C'), etc. ...
The most efficient way of processing a transaction in this case is determined by the card (more precisely, by the card issuer) by selecting the values of two Application Interchange Profile data elements (AIP, Tag '82', size 2 bytes) and Application File Locator (AFL, Tag 'corresponding to the data received from the terminal) 94 ', size up to 252 bytes).
For example, if the PDOL list contains the country code of the terminal, then the card can differentiate the processing of domestic and international
Tab. 4.8. First byte of AIP
transactions, by offering the terminal, using the AFL object, references to various data objects that the terminal must use to process the transaction.
The Application Interchange Profile Data Element defines for the terminal the card's ability to process a transaction, as well as the card's requirement for the terminal for the terminal to perform risk management procedures. The structure of the first AIP byte is shown in Table. 4.8.
The second byte of the AIP is zero for contact cards (the values of all bits are reserved for future use; the eighth bit of this byte is sometimes used for contactless applications of some payment systems). The table shows that the AIP element defines:
The Application File Locator element defines a list of data that must be read by the terminal on the card in order to process a transaction. This data item consists of a set of links. Each link is a sequence of four bytes with the following assignment:
Based on the AIP and AFL data obtained from the card's response to the GET PROCESSING OPTIONS command, the terminal determines which commands should be sent to the card to process the transaction, as well as where (in which records of which card files) the data needed to perform the operation should be searched.
The TVR object is 5 bytes in size and records the results of checks performed by the terminal during the processing of the current transaction. The bytes of the data field of the TVR object display information on the results of the following types of checks:
- byte 1 - card authentication results;
- byte 2 - results of checks of restrictions on the use of the card (Processing Restrictions);
- byte 3 - results of cardholder Verification;
- byte 4 - results of Terminal Risk Management execution by the terminal;
- byte 5 - results of the issuer authentication procedure and Script Processing.
A detailed view of the TVR data object is presented in table. 4.1-4.5.
Tab. 4.1. Byte 1 TVR (leftmost)
| B8 | B71 bb | b5 | B4 | B3 | B2 | NS | Meaning |
| 1 | Offline data authentication was not performed | ||||
| 1 | Offline SDA failed | ||||
| 1 | ICC data missing (some data related to the chip is missing) | ||||
| 1 | Card appears on terminal exception file | ||||
| 1 | Offline DDA failed | ||||
| 1 | CDA / AC Generation failed | ||||
| 0 | Reserved for use | ||||
| 0 | Reserved for use |
Tab. 4.2. Byte 2 TVR
| B8 | B7 | b6 | b5 | B41 b3 | B2 | NS | Meaning |
| 1 | ICC and terminal have different application versions | ||||
| 1 | Expired application | ||||
| 1 | Application not yet effective (the application has not started yet) | ||||
| 1 | Requested service not allowed for card product | ||||
| 1 | New card | ||||
| 0 | Reserved for use | ||||
| 0 | Reserved for use | ||||
| 0 | Reserved for use |
Tab. 4.3. Byte 3 TVR
Meaning
Cardholder verification was not successful (the cardholder verification procedure was unsuccessful) Unrecognized CVM (the terminal does not understand the verification method)
PIN Try Limit exceeded
PIN entry required and PIN pad not present or not working
PIN entry required, PIN pad present, but PIN was not entered
The end of the table. 4.3
| B8 | b? | B6 | b5 b4 | bs | B2 | NS | Meaning |
| 1 | Online PIN entered | |||
| 0 | Reserved for use | |||
| 0 | Reserved for use |
Tab. 4.4. Byte 4 TVR
| B8 | B7 | b6 | b5 | B4 b3 | B2 b | Meaning | |
| 1 | Transaction exceeds floor limit | ||||
| 1 | Lower Consecutive Offline Limit exceeded | ||||
| 1 | Upper Consecutive Offline Limit exceeded | ||||
| 1 | Transaction selected randomly for online processing | ||||
| 1 | Merchant forced transaction online | ||||
| 0 | Reserved for use | ||||
| 0 | Reserved for use | ||||
| 0 | Reserved for use | ||||
| Tab. 4.5. Byte 5 TVR (rightmost) | |||||
| B8 | B7 | b6 b5 | B4 b3 | B2 | NS | Meaning |
Default TDOL used
Issuer Authentication was unsuccessful
Script Processing failed before final GENERATE AC (the script processing procedure failed before the 2nd GENERATE AC command)
Script Processing failed after final GENERATE AC (the script processing procedure failed after the 2nd GENERATE AC command)
Reserved for use
Reserved for use
Reserved for use
Reserved for use
The purpose and way of filling the bits of the TVR object will be discussed in the course of the description of the transaction processing procedures.
The TSI data object consists of two bytes. All bits of the second byte are reserved for future use, and the structure of the first byte is shown in Table. 4.6.
Tab. 4.6. Byte 1 TSI
B8
B7 | b6 | b5 | b4 | b3 | b2 | b
Meaning
Offline data authentication was performed
Cardholder verification was performed
Card risk management was performed
Issuer authentication was performed
Terminal risk management was performed
Issuer Script Processing was performed
Reserved for use
О Reserved for use
As you can see from the table. 4.6, the TSI data object records a list of the main procedures performed by the terminal and the card during transaction processing. The purpose of the bits and the method of filling TSI will be discussed in the course of the description of the transaction processing procedures.
After selecting the application and resetting its internal parameters, the terminal sends the GET PROCESSING OPTIONS command to the card. The main details of this command are presented in table. 4.7.
Tab. 4.7. GET PROCESSING OPTIONS command structure
| Props | Meaning |
| CLA | '80'h (a command invented specifically for EMV) |
| INS | * A8'h |
| Pl | '00'h |
| P2 | '00'h |
| Lc | Command data field size |
| Data | Tag '83' | | Length | | Byte string containing data concatenation according to PDOL |
| Le | '00'h |
Chapter 4. PROCESSING TRANSACTIONS BY MICROPROCESSOR CARD 293
G
MasterCard ^? 9
As you can see from the table. 4.7, the data field of the GET PROCESSING OPTIONS command is a concatenation of the Value fields of the data objects listed in the PDOL if the PDOL list is contained in the FCI Template of the selected card application (in this case, the PDOL list is obtained by the terminal from the FCI Proprietary Template data object contained in the card response to SELECT command).
If the PDOL list is not in the FCI Proprietary Template of the selected application, then in the data field of the GET PROCESSING OPTIONS command, the value of the Length field of the data object with Tag '83' is 0, and the data field of this object is absent.
If the PDOL is contained in the FCI Proprietary Template of the selected application, then it consists of the Tag and Value fields of those data objects whose values the map application needs to determine the most efficient way to process the current transaction. Such data may include transaction size (Amount, Authorized, Tag '9F02'), transaction currency (Transaction Currency Code, Tag '5F2A'), terminal type (Terminal Type, Tag '9F35'), terminal functionality (Terminal Capabilities , Tag '9F33'), terminal country code (Terminal Country Code, Tag '9F1A'), merchant type (Merchant Category Code, Tag '9F15'), transaction type (Transaction Type, Tag '9C'), etc. ...
The most efficient way of processing a transaction in this case is determined by the card (more precisely, by the card issuer) by selecting the values of two Application Interchange Profile data elements (AIP, Tag '82', size 2 bytes) and Application File Locator (AFL, Tag 'corresponding to the data received from the terminal) 94 ', size up to 252 bytes).
For example, if the PDOL list contains the country code of the terminal, then the card can differentiate the processing of domestic and international
Tab. 4.8. First byte of AIP
| B8 | B7 | B6 | B5 | B4 | bz | B2 | NS | Meaning |
| 0 | Not used | |||||||
| 1 | SDA supported | |||||||
| 1 | DDA supported | |||||||
| 1 | SUM supported | |||||||
| 1 | Terminal Risk Management must be used | |||||||
| 0/1 | Issuer authentication via 2nd GENERATE АС / External Authenticate | |||||||
| 1 | CDA supported | |||||||
| 0 | Not used |
transactions, by offering the terminal, using the AFL object, references to various data objects that the terminal must use to process the transaction.
The Application Interchange Profile Data Element defines for the terminal the card's ability to process a transaction, as well as the card's requirement for the terminal for the terminal to perform risk management procedures. The structure of the first AIP byte is shown in Table. 4.8.
The second byte of the AIP is zero for contact cards (the values of all bits are reserved for future use; the eighth bit of this byte is sometimes used for contactless applications of some payment systems). The table shows that the AIP element defines:
- authentication methods supported by the card;
- the fact that the card supports the verification procedure of the cardholder;
- card requirement on the need for the terminal to comply with the risk management procedure;
- the way the card supports the issuer authentication procedure (via the second GENERATE AC command or the EXTERNAL AUTHENTICATE command).
The Application File Locator element defines a list of data that must be read by the terminal on the card in order to process a transaction. This data item consists of a set of links. Each link is a sequence of four bytes with the following assignment:
- the first byte specifies the value of the SFI name of the AEF elementary file (the most significant five bits of the byte are equal to the SFI value) whose records are to be read by the terminal. All other bytes of the link specify parameters related to the elementary AEF file named SFI, identified by the first byte of the link;
- the second byte is the binary representation of the number of the first record of the linear AEF file from which to start reading the records of the AEF file; this number cannot be equal to 0;
- the third byte is a binary representation of the number of the last record (must be at least the number of the first record), up to which the records of the AEF file must be read sequentially;
- the fourth byte is a binary representation of the number of records in the AEF file that are used for static card authentication (to form the Static Data to be Authenticated element, starting with the record number specified in the second byte of the descriptor). If there are no such entries in the AEF file in question, the fourth byte consists of eight zero bits.
Based on the AIP and AFL data obtained from the card's response to the GET PROCESSING OPTIONS command, the terminal determines which commands should be sent to the card to process the transaction, as well as where (in which records of which card files) the data needed to perform the operation should be searched.
