Mechanism for the Issuer to verify the EMV standard

Byte 1 TVR (leftmost)

B8 B7 BB B5 B4 BZ B2 s Value
1 Offline data authentication was not performed (offline card authentication was not performed)
1 Offline SDA failed (SDA authentication failed)
1 ICC data missing (some data related to the chip is missing)
1 Card appears on terminal exception file (the card is found in the stop list)

B8 B7 BB B5 B4 BZ B2 s Value
1 Offline DDA failed (DDA authentication failed)
1 CDA/AC Generation failed (CDA authentication failed)
0 Reserved for use
0 Reserved for use

Byte 2 of the TVR
B8 B7 BB B5 B4 BZ B2 s Value
1 ICC and terminal have different application versions (terminal and card applications have different versions)
1 application is Expired (the validity period of application has expired)
1 Application not yet effective (the application has not started yet)
1 Requested service not allowed for card product (the requested service is not allowed for the app)
1 New card (new card)

Reserved for use

Byte 3 of the TVR

B8 B7 B6 B5 B4 BZ B2 s Value
1 Cardholder verification was not successful (the cardholder verification procedure was unsuccessful)
1 Unrecognized CVM (the terminal does not understand the verification method)
1 PIN Try Limit exceeded (parameter PTL is exceeded)
1 PIN entry required and PIN pad not present or not working (you need to enter a PIN code, but the PIN pad is either missing or not working)
1 PIN entry required, PIN pad present, but PIN was not entered (PIN code required, PIN pad present, but PIN was not entered)
1 (Mine PIN entered (entered the value of the PIN code to check it online)
0 Reserved for use
Zero

Byte 4 of the TVR
B8 B7 BB B5 B4 BZ B2 s Value
1 Transaction exceeds floor limit (the transaction size exceeded the threshold value)

B8 B7 BB B5 B4 BZ B2 s Value
1 Lower Consecutive Offline
Limit exceeded (lower Sequential limit exceeded
Offline Limit)
1 Upper Consecutive Offline
Limit exceeded (limit exceeded Upper Consecutive
Offline Limit)
1 Transaction selected randomly for online processing (transaction selected for online processing)
1 Merchant forced transaction online (merchant insists on online transaction processing)
0 Reserved for use
Zero
Zero

TVR byte 5 (rightmost)

B8 B7 BB B5 B4 BZ B2 s Value
1 Default TDOL used (the default value is TD0L)
1 Issuer Authentication was unsuccessful)
1 Script Processing failed before final GENERATE AC (the script processing procedure failed before the 2nd GENERATE AC command)

B8 S BB B5 B4 BZ B2 s Value
1 Script Processing failed after final GENERATE AC (the script processing procedure failed after the 2nd GENERATE AC command)
1 Reserved for use
Zero
Zero
Zero

The purpose and method of filling in the bits of the TVR object will be described in the description of 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.
Byte 1 of the TSI

B8 B7 B6 B5 B4 BZ B2 s Value
1 Offline data authentication was performed (offline card authentication was performed)
1 Cardholder verification was performed (verification of the card holder was made)
1 Card risk management was performed (the risk management procedure was performed by the card)
1 Issuer authentication was performed (Issuer card authentication was performed)

B8 B7 BB B5 B4 BZ B2 s Value
1 Terminal risk management was performed (the risk management procedure was performed by the terminal)
1 issue Script Processing was performed (script processing was performed)
0 Reserved for use
Zero

The TSI data object displays a list of the main procedures performed by the terminal and the card during transaction processing. You will learn about the bit assignment and how to fill in the TSI as you describe the transaction processing procedures.
After selecting the application and resetting the parameters, the terminal sends the GET PROCESSING OPTIONS command to the card.
Structure of the GET PROCESSING OPTIONS command

Detail Value
CLA ‘ SO’h (a command specially created for the EMV standard)
INS ‘A8’h
P1 ’00’h
P2 ‘ OO’h
Lc size of the variable length command data field
Data Tag ’83’||Length||a string of bytes containing data concatenation according to PD0L

The command data field is a concatenation of the Value fields of data objects listed in PD0L, if the PD0L list is contained in the FCI Template of the selected card application (in this case, the PD0L list is obtained by the terminal from the FCI Proprietary Template data object contained in the card response to the SELECT command).
If the PD0L list is not present 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 zero, and the data field of this object is missing.
If the PD0L list is contained in the FCI Proprietary Template of the selected application, it consists of the Tag and Value fields of the data objects whose values are needed by the card application to determine the most efficient way to process the current transaction. Such data may include the 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’), type of merchant (Merchant Category Code, Tag ‘9F15’), transaction type (transaction type, tag
The most effective way to process a transaction in this case is determined by the card (more precisely, by the card Issuer) by selecting the values of two data elements corresponding to the data received from the terminal: Application Interchange Profile (AIP, Tag ’82’, size 2 bytes) and Application File Locator (AFL, Tag ’94’, size up to 252 bytes).
For example, if the PD0L list contains the transaction currency and country code of the terminal, the card can differentiate the processing of domestic and international transactions, if desired, by offering the terminal with the AFL object links to different CVM List objects.
The Application Interchange Profile data element defines the card’s transaction processing capabilities for the terminal, as well as the card’s requirement for the terminal to perform risk management procedures.

First AIP byte

B8 B7 BB B5 B4 BZ B2 B1 Value
0 Not used
1 SDA supported
1 DDA is supported
1 CVM supported
1 Terminal Risk Management must be used
0/1 Authentication Issuer using the 2nd GENERATE AC/External Authenticate
1 CDA supported
0 He is used

The second byte of the AIP is null (the values of all bits are reserved for future use). The table shows that the AIP element defines:
authentication methods supported by the card;
the fact that the card supports the cardholder verification procedure;
the card’s requirement that the terminal perform the risk management procedure;
how the card supports the Issuer authentication procedure (via the second GNERATE AC command or the EXTERNAL AUTHENTICATE command).
Note that the m/Chip 4 application uses the EXTERNAL AUTHENTICATE command for Issuer authentication (bit 3 of byte 1 of AIP is equal to 1), while the VIS 1.4 application uses THE external AUTHENTICATE command.x— GENERATE AC command (bit 3 of byte 1 of the AIP is equal to 0).
The Application File Locator element defines a list of data that should be read by the terminal on the card in order to process the transaction in accordance with the algorithm of the selected application. This data element consists of a set of links. Each
a link is a sequence of four bytes for the following purpose:
the first byte defines the value of the SFI name of the elementary AEF file of the selected application (the highest 5 bits of the byte are equal to the SFI value), whose entries must be read by the terminal; all other bytes of the link specify parameters related to the AEF file defined in the first byte of the link;
the second byte defines (encodes) the number of the first entry in the linear AEF file that starts reading the AEF file entries; this number cannot be equal to 0;
the third byte defines the number of the last record (must be at least the number of the first record), up to and including which entries in the AEF file must be read sequentially;
the fourth byte defines the number of entries in the AEF file that are used for static authentication of the card (for forming the Static Data to be Authenticated element, starting with the entry number specified in the second byte of the descriptor). As noted earlier, it would be more accurate to talk about static authentication of the selected card application. If there are no such entries in the AEF file under consideration, the fourth byte consists of 8 null bits.
If the card successfully processes the GET PROCRSSING OPTIONS command, the card increments the value of the Application Transaction Counter transaction number (Tag ‘9F39’, 2 bytes) by one and initializes the card application to perform a new operation.
Based on the AIP and AFL data elements obtained from the card’s response to the GET PROCRSSING 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) to search for the necessary data to perform the operation.
Reading card data
First of all, the terminal must read the card data, whose location in the card file system is determined using AFL. To read data, the terminal uses the READ RECORD command, following the algorithm described below. When describing it, keep in mind that the value field of the AFL object has the form: AFL = /r1|| Fz\ … || f, where F. (i = 1, n) are 4 — 6-byte links whose contents are defined in the previous section. F. links specify the names and entries of elementary files that must be read by the terminal to process the transaction.
For each link, F. (/’=1, …, p) the AFL element repeats the sequence of steps described below.
Step1. The P2 parameter of the READ RECORD command is set using the SFI value specified in the first byte of reference F. (the first five bits of P2 are equal to SFI).
Step 2. The terminal verifies the correct format of the link F. (defined in the previous section). If it is violated, the transaction processing stops.
Two parameters are entered: “record Number” and “last record Number”. The “last entry number” is set to the value of the third byte of the reference F.. The initial value of the “record Number” is assumed to be equal to the value of the second byte F..
Stepz. The terminal sets parameter P1 of the READ RECORD command to the value of “counter Number” and sends the read RECORD command to the card.
Step4. If the R-APDU block received by the terminal in response to the READ RECORD command contains SWlSW2=9000’h, the terminal parses the AEF Data Template (Tag 70′) and remembers the required and optional data objects contained in the record, provided that for the stored data object:
the Tag field has a value known to the terminal;
the Tag field was not previously encountered by the terminal as part of the data reading when executing the current transaction; otherwise, the terminal stops processing the transaction.
After reading the data, the terminal verifies its correctness in accordance with the rules set out below in this section.
Step 5. If the current value of the “record Number” is less than the value of the “last record Number”, the “record Number” increases by 1 and the terminal proceeds to Step 3. Otherwise, the terminal proceeds to Step 6.
Step b. If the current link F. is not the last one in the AFL, the terminal starts processing the next link F.+1, starting from Step 1 of this algorithm. If the link is not the last one (; = p), the terminal ends reading data from the card.
The second most important function of the terminal at the card data reading stage, when the card supports any offline authentication method, is to build the Static Data to be Authenticated element used for static card authentication. The algorithm for building this data element is described below. In practice, the implementation of the algorithm is combined with the above-described algorithm for reading card data. However, in this book, for the sake of clarity, we have divided the descriptions of these algorithms.
For each reference in f (/= 1, …, p) of the AFL element, the fourth byte is checked. If it is null (consisting only of bits ‘0’), then the corresponding AEF file to reference F. does not contain the data used in Static Data to be Authenticated, and the terminal proceeds to analyze the next reference F.+1. It is assumed that i<n. If / = n, the algorithm for constructing the Static Data to be Authenticated element terminates.
Let’s assume that the result for some reference F. (; = 1, n) is that the fourth byte is not null. For this reference, the terminal defines two parameters: the / parameter equal to the value of the second byte, and the parameter equal to the sum of I and the value of the number encoded by the fourth byte, minus 1. In addition, the first byte of the reference F. the terminal determines the SFI name of the current AEF file. After that, the terminal incrementally attaches j{l<j<L) to the right of the current value of Static Data to be Authenticated records R. with the j numbers of the current AEF file. In other words, for the reference in question, F., incrementing j sequentially from / to L, the terminal performs the assignments: Static Data to be Authenticated:=Static Data to be Authenticated!\R .
However, if the SFI file name is in the range from 1 to 10 for this link, then the R entries are attached without the Tag (70′) field and the Length field. In other cases, when the SFI value is between 11 and 30, the values of the Tag and Length fields in the R record are included.

After all the links have been processed in accordance with the above algorithm, the terminal checks for a Static Data Authentication Tag List (SDA Tag List, Tag ‘9F4A’) object containing a single AIP object (Tag ’82’) among the read data. If such an object is present in the card application, the value of its Value field will be attached to the right of the received Static Data to be Authenticated value, thus completing the formation of this data element.
It has already been noted that the Static Data to be Authenticated string is generated by all terminals that support offline card authentication methods. In accordance with the rules of payment systems today, all terminals support offline authentication, with the possible exception of the so-called “online only” terminals that can only perform transactions in real time.
Using the READ RECORD command, the terminal reads the records of linear card files specified in the AFL. Data objects shown in the table. 4.9, are not extracted by the READ RECORD command, because they are not stored in linear card files. This data can be extracted by the terminal using the GET DATA command.
Data extracted by the terminal using the command
GET DATA

Tag Value Presence
‘9F361 Application Transaction Counter (PBX) Required
‘9F17’ PIN Try Counter Optional
‘9F13’ Last Online ATC Register Optional
‘9F7F’ Card Production Life Cycle (CPLC) is Required for VIS 1.4 cards.x

Among the objects shown in the table, only the Application Transaction Counter (PBX) is required for the card. It can be received by the terminal either using the GET DATA command, or from the response to THE generate AC command. The PBX object must be received by the terminal in response to the GET DATA command only in the following case-
when the microprocessor card contains the Lower Sequential Offline Limit and Upper Sequential Offline Limit data objects. This is because the need to get the PBX value before processing the first GENERATE AC command occurs only if the terminal is present in the risk management procedures to check the number of consecutive offline operations performed on the card.
If the Issuer does not want the terminal to perform Velocity Checking during transaction processing, the card may not support the GET DATA command. Unfortunately, the lack of understanding of this fact has caused a large number of cases of Fallback to the magnetic stripe. The terminal tries to get the PBX value from a card that does not support the GET DATA command, and stops processing the transaction when it receives the corresponding card response.
After reading the card data, the terminal checks its completeness and correctness. When checking the completeness of EMV application data, the criteria set in the payment system specifications are used. A common criterion is that all card data is divided into several categories:
critical data (not to be confused with the data of the same name used in SDA!), if there are no transactions on the card, the terminal stops processing the transaction;
required data (data that should be on the card, but in the absence of which the transaction processing continues);
data that must be present on the card if certain conditions are met (for example, if some other data is present on the card);
optional data (data that may or may not be present on the card regardless of any conditions).
First of all, it checks whether there are any critical objects among the read data. Such data usually includes:
card number (Application Primary Account Number, Tag ‘5A’);
the validity of the card (Application Expiration Date, Tag ‘5F24’);
list of data Card Risk Management Data Object List 1
(CD0L1, Tag ‘8C’);
— data list Card Risk Management Data Object List 2 (CD0L2, Tag ‘8D’);

Application Interchange Profile (AIP, Tag ’82’);
Application Version Number (Tag ‘9F08’).
If at least one of the critical data objects is missing on the card, the terminal stops processing the transaction.
Next, the terminal checks for mandatory objects among the read data that are necessary for performing the transaction, in particular, objects that are required on the card based on the value of the AIP element:
the card’s support for cardholder verification (in byte 1, AIP bit 5 is equal to 1) means that the Cardholder Verification Method (CVM) List object (Tag ‘8E’is required on the card);
the card’s support for the SDA method (in byte 1, AIP bit 7 is equal to 1) means that the card must have objects necessary for performing static authentication of the card (listed in clause 3.12.1);
the card’s support for dynamic authentication methods DDA and (or) CDA (in byte 1, AIP bit 7 and (or) bit 2 are equal to 1) means that the card must have objects necessary for performing dynamic authentication of the card (listed in clause 3.12.2);
the presence of the Lower Sequential Offline Limit and Upper Sequential Offline Limit data elements on the card means that the terminal must get the value of the PBX transaction counter in response to the GET DATA command.
Note that the terminal checks the availability of data required for performing card authentication procedures only after selecting a specific authentication method (SDA, DDA, CDA).
If at least one mandatory data object is missing, the terminal sets bit 6 of byte 1 of the TVR ‘ICC Data Missing’ object data field to 1.
Note that if the card supports static and / or dynamic authentication, data objects such as the CA Public Key Index (Tag ‘8F’) and the Issuer Public Key Certificate (Tag ’90’) must be placed in the first record that the AFL points to. The first entries must contain other objects related to the card authentication procedures. This is required so that multitasking terminals can read data in parallel-
you can perform the card authentication procedure (verification of the Issuer’s certificates, system, card, and signed Static/Dynamic Application Data).
In conclusion, we note that the correctness of the card data is checked by the terminal throughout the entire transaction processing procedure. If the terminal detects that a data object has an incorrect format, takes an invalid value, occurs several times on the card, contains syntax errors, and so on, it must stop processing the transaction and reject it. However, if the terminal encounters a data object that it does not know, it must continue processing the transaction, ignoring the unfamiliar data.
Card authentication
The first procedure performed by the terminal and the card after the terminal reads the card data (or in parallel with the data reading) is card authentication. The procedure begins with the terminal determining which offline authentication method will be used to process this transaction. To do this, the terminal analyzes data from two objects: AIP (Tag ’82’) and Terminal Capabilities (Tag ‘9F33’). The structure of the Terminal Capabilities element is shown in table. 4.10— 4.12.
The Terminal Capabilities byte 1 (leftmost)

B8 B7 BB B5 B4 BZ B2 s Value
1 Manual entry of transaction details (Manual Key Entry)
1 Entering the magnetic Stripe)
1 Entering data from the contact form
MP (ICC with contacts)
0 Reserved for use
Zero

B8 B7 BB B5 B4 BZ B2 s Value
0 Reserved for use
Zero
Zero

Byte 2 Of Terminal Capabilities

B8 B7 BB B5 B4 BZ B2 s Value
1 Entering an open PIN code on the card
1 Entering an encrypted PIN code to transmit to the Issuer
1 signature of the receipt (Signature)
1 Entering an encrypted PIN code on the card
1 cardholder Verification is not supported (No CVM)
0 Reserved for use
Zero
Zero

The Terminal Capabilities byte 3 (most right)

B8 B7 BB B5 B4 BZ B2 s Value
1 Support for SDA
1 DDA Support
1 Support for card capture)

B8 B7 BB B5 B4 BZ B2 s Value
1 Reserved for use
1 Support the CDA
0 Reserved for use
Zero
Zero

The Value field of the Terminal Capabilities data object contains three bytes. The first byte determines the terminal’s ability to enter card data (whether the terminal can read and transmit magnetic stripe data, whether it can work with IPC, and whether it can be used to enter transaction details (card number, expiration date, etc.in manual mode).
The second byte determines the terminal’s ability to verify the cardholder. Finally, the third byte defines the card authentication methods supported by the terminal.
The terminal selects a specific card authentication method (SDA, DDA, or CDA) as follows.
Step 1. First, the terminal determines the card authentication methods supported by the terminal (SDA, DDA, or CDA). If bits 2, 3, and 7 of the first AIP byte are simultaneously 0, the card does not support any authentication procedure, and therefore this procedure is not performed by the terminal. In this case, the terminal sets bit 8 of” Offline data authentication was not performed “of byte 1 of TVR to 1 and proceeds to Step 5 (the same is done by the terminal if it is an” online only ” terminal).
Step 2. The terminal is considering the possibility of card authentication using the CDA method. To do this, two conditions are checked simultaneously: the card supports CDA (bit 2=1 in the first AIP byte) and the terminal supports CDA (bit 5=1 in the third terminal Capabilities byte). If the specified conditions are met simultaneously,
the CDA method is selected. Otherwise, the terminal proceeds to Step 3.
Stepz. The terminal is considering the possibility of card authentication using the DDA method. To do this, two conditions are checked simultaneously: the card supports DDA (bit 6=1 in the first AIP byte) and the terminal supports DDA (bit 7=1 in the third terminal Capabilities byte). If the specified conditions are met simultaneously, the DDA method is selected. Otherwise, the terminal proceeds to Step 4.
Step 4. The terminal is considering the possibility of card authentication using the SDA method. To do this, two conditions are checked simultaneously: the card supports SDA (bit 7=1 in the first AIP byte) and the terminal supports SDA (bit 8=1 in the third terminal Capabilities byte). If the specified conditions are met simultaneously, the SDA method is selected. Otherwise, the terminal sets bit 8 “Offline data authentication was not performed” of byte 1 of TVR to 1 and proceeds to Step 5.
Step 5. The procedure for selecting the card authentication method is considered complete.
If the terminal is an “online only” type of terminal, it can skip the offline card authentication procedure and immediately proceed to the next stages of transaction processing. In this case, mutual authentication of the card and its Issuer is performed. Therefore, there is no need for offline card authentication in this case. At the same time, in accordance with the principle “you can’t spoil porridge with butter”, offline authentication can be performed just in case when using an “online only”terminal. In theory, this significantly increases the reliability of card authentication, but in the range of values of this reliability, which is not necessary in practice.
The terminal type is defined by a data object called “terminal Type” (Terminal Type, Tag ‘9A35’, 1 byte) and stored on the terminal. In General, the Terminal Tour object determines the communication capabilities of the terminal, the controlling authority of the terminal (financial institution, commercial enterprise, or lack of a controlling authority, i.e. in the latter case, the terminal is controlled only by the cardholder during the transaction), as well as the presence of a representative of the controlling authority during the transaction (attended terminal, if a representative is present, and unattended terminal, if there is no representative). The structure of the Terminal Tour object is shown in table. 4.13.
Structure of the Terminal Tour data object

Environment a Terminal controlled by a financial institution a Terminal controlled by a merchant a Terminal controlled only by a cardholder
Attended Terminal –
Online Only 11 21 –
Offline with online capabilities 12 22 –
Offline Only 13 23 –
Unattended Terminal
Online Only 14 24 34
Offline with online capabilities 15 25 35
Offline Only 16 26 36

As can be seen from the table, the elder nibble of the element Terminal Round determines the controlling body of the terminal (‘l h — financial institution, ‘2’h — commercial enterprise, ‘3’h — lack of Supervisory authority), and least significant nibble specifies the communication capabilities of the terminal and the presence of a representative of the Supervisory authority.
From the given definition, it follows that an ATM can be a terminal for which Terminal Tour takes the values ’14’h, ’15’h,’ 16’h.
A terminal with the value Terminal Toure, equal to one of the values ‘ll’h,’ 12’h, Y13’h, is a terminal located in a Bank branch.

A terminal with the value Terminal Toure, equal to one of the values ’21’h, ’22’h, ’23’h, is a terminal installed in retail outlets (the most popular type of terminal in practice).
A terminal with the value of Terminal Toure equal to ’24’h,’ 25’h, ’26’h is a gas station, ticket vending machine or vending machine for selling various goods (vending machine), a pay phone, etc.
A terminal with the value of Terminal Toure equal to ’34’h,’ 35’h, ’36’h is a home personal computer, mobile phone or TV receiver operating in interactive digital television mode, etc.
Sometimes an additional terminal Capabilities data object (Tag ‘9F40’) is used to describe terminal capabilities. This object is mandatory for use in the largest payment systems MasterCard and VISA. It has a size of 5 bytes, of which the most common is the first byte, which determines the type of transactions supported by the terminal. The structure of the first byte of the Additional Terminal Capabilities object is shown in table. 4.14.
Structure of the first byte of the Additional Terminal object
Capabilities

B8 B7 B6 B5 B4 BZ B2 s Value
1 cash Withdrawal (Cash)
1 Purchase (Goods)
1 Provision of the service (Services)
0 cash Withdrawal when making a purchase (Cashback)
0 account Information (Inquiry)
0 Transfer of funds between the client’s accounts in the same Bank (Transfer)
0 Payments (Payment)
0 Administrative transaction (Administrative)

After completing the procedure for selecting the offline authentication method, the terminal starts implementing the card authentication procedure itself. For dynamic card authentication, the card itself takes an active part in this process. (The card authentication procedures were described in detail in clause 3.12.)
If the terminal detects that the necessary data is missing when trying to perform offline authentication (see paragraphs 3.12.1 and 3.12.2), bit 6 “ICC Data missing” and one of the bits 3 (“Combined CDA/Generate AC Failed”), 4 (“Offline DDA Failed”) or 7 (“Offline SDA Failed”) of the first TVR byte corresponding to the selected authentication method are set to 1.
If the terminal performs offline card authentication, bit 8 of the first TSI byte is set to 1. However, the result of the authentication procedure when setting the TSI object bit is not important.
If the terminal does not perform offline card authentication, bit 8 of the first TVR byte is set to 1.
In any case, if the terminal performs offline card authentication and it fails, one of the bits 3 “Combined CDA/Generate AC Failed”, 4 “Offline DDA Failed “or 7″ Offline SDA Failed ” of the first TVR byte corresponding to the selected authentication method is set to 1.
Since the Issuer only learns about the result of card authentication based on the TVR data generated by the merchant’s terminal, the EMV standard provides a mechanism for the Issuer to verify that the card has been authenticated. This mechanism protects the Issuer from unscrupulous merchants/service banks who claim that the card authentication procedure has been completed, when in fact it has not been performed.
The verification mechanism is as follows. As already mentioned, the terminal stores Data Authentication Code (DAC) values for static authentication and ICC Dynamic Number (IDN) values for dynamic DDA/CDA authentication in data objects with the tags ‘9F45’ and ‘9F4C’, respectively (see clauses 3.12.1, 3.12.2.1 and 3.12.2.2). If the Issuer includes the values of these tags in the CD0L1 and CD0L2 objects, the card gets the DAC and IDN values when it processes the GENERATE AC command. The received DAC/IDN data can be sent by the card to the Issuer inside the data object of the Issuer Application Data (Tag; 9F10′) contained in the data field of the response to THE generate AC command.
In the case of an online transaction, the Issuer can verify that the card was authenticated during transaction processing and take the verification result into account when making a decision about the transaction result. In the case of an offline transaction, the fact of card authentication is verified by a clearing message received by the Issuer. Payment systems may provide for the possibility of the Issuer’s refusal to make a payment if the Issuer refutes the fact of card authentication by a merchant.
Thus, in order for the Issuer to verify that the card authentication terminal has been performed, it is necessary to:
include the ‘9F45’ and ‘9F4C’ tags in the CD0L1 and CD0L2 lists;
include the ‘9F45’ and ‘9F4C’ tags in the Issuer Application Data returned in the response to THE generate AC command.
Checking transaction processing restrictions)
The terminal performs this stage of transaction processing independently (without contacting the card and the Issuer), using the data previously received from the card. This stage can be implemented by the terminal at any time between the end of the card data reading by the terminal and the beginning of analysis of the result of terminal checks.
At this stage, we consider three criteria for matching the terminal and card applications to each other.
Matching the version numbers of the card and terminal applications (Application Version Number).
Control app usage (Application Usage Control).
Application effective/expiration dates checking.