An EMV transaction has the following steps:
ISO/IEC 7816 defines a process for application selection. The intent of application selection was to allow cards to contain completely different applications, for example GSM and EMV. EMV however took application selection to be a way of identifying the type of product, so that all product issuers (Visa, MasterCard, etc.) have to have their own application. The way application selection as prescribed in EMV is a frequent source of interoperability problems between cards and terminals. Book 1 of the EMV standard devotes 15 pages to describing the application selection process.
An application identifier (AID) is used to address an application in the card. An AID consists of a registered application provider identifier (RID) of five bytes, which is issued by the ISO/IEC 7816-5 registration authority. This is followed by a proprietary application identifier extension (PIX), which enables the application provider to differentiate among the different applications offered. The AID is printed on all EMV cardholder receipts.
Initiate application processing (back to top)
The terminal sends the get processing options command to the card. When issuing this command, the terminal supplies the card with any data elements requested by the card in the processing options data objects list (PDOL). The PDOL (a list of tags and lengths of data elements) is optionally provided by the card to the terminal during application selection. The card responds with the application interchange profile (AIP), a list of functions to be performed in processing the transaction. The card also provides the application file locator (AFL), a list of files and records that the terminal needs to read from the card.
Smart cards store data in files. The AFL contains the files that contain EMV data. These all need to be read using the read record command. EMV does not specify which files data is stored in, so all the files need to be read. Data in these files is stored in BER TLV format. EMV defines tag values for all data used in card processing.
The purpose of the processing restrictions is to see if the card should be used. Three data elements read in the previous step are checked.
- Application version number
- Application usage control (This shows whether the card is only for domestic use, etc.)
- Application effective/expiration dates checking.
If any of these checks fails, the card is not necessarily declined. The terminal sets the appropriate bit in the terminal verification results (TVR), the components of which form the basis of an accept/decline decision later in the transaction flow. This feature allows, for example, card issuers to permit their cardholders to continue to use expired cards after their expiry date, but for all transactions made with an expired card to be performed on-line.
Offline data authentication (back to top)
Offline data authentication is a cryptographic check to validate the card using public-key cryptography. There are three different processes that can be undertaken depending on the card:
- Static data authentication (SDA) ensures data read from the card has been signed by the card issuer. This prevents modification of data, but does not prevent cloning.
- Dynamic data authentication (DDA) provides protection against modification of data and cloning.
- Combined DDA/generate application cryptogram (CDA) combines DDA with the generation of a card's application cryptogram to assure card validity. Support of CDA in devices may be needed, as this process has been implemented in specific markets. This process is not mandatory in terminals and can only be carried out where both card and terminal support it.
Cardholder verification is used to evaluate whether the person presenting the card is the legitimate cardholder. There are many cardholder verification methods (CVMs) supported in EMV. They are:
- Offline plaintext PIN
- Offline enciphered PIN
- Offline plaintext PIN and signature
- Offline enciphered PIN and signature
- Online PIN
- No CVM required
- Fail CVM processing.
The terminal uses a CVM list read from the card to determine the type of verification to be performed. The CVM list establishes a priority of CVMs to be used relative to the capabilities of the terminal. Different terminals support different CVMs. ATMs generally support online PIN. POS terminals vary in their support of CVM depending on their type and in which country they are located.
Chip and PIN vs. Chip and signature (back to top)
According to issuer preference, some EMV cards are "chip and PIN" cards that require the customer to supply a four-to-six-digit personal identification number (PIN) when making a purchase at PIN-capable terminals. The chips in these cards feature "PIN" ranked first in the list of possible cardholder verification methods (CVM), but with signature allowed as a fall-back option (or PIN verification at unattended terminals).
Other EMV cards are either signature-only or prefer signature over PIN in their CVM list (i.e., signature at the POS, but PIN at unattended terminals or ATMs). These are often called "chip and signature" cards.
Signature-only cards will not work at points of sale that allow no CVM other than PIN, such as some unattended ticket kiosks in Europe, whereas signature-preferring cards might work. Attended POS which are staffed by merchant personnel are required by the credit card agreement to accept magnetic stripe cards as well as chip and signature cards. Chip-and-PIN cards have not been adopted in the US as of June 2014 for a variety of reasons, including lack of PIN management features in ATMs.
Terminal risk management is only performed in devices where there is a decision to be made whether a transaction should be authorised on-line or offline. If transactions are always carried out on-line (e.g., ATMs) or always off-line, this step can be missed. Terminal risk management checks the transaction amount against an offline ceiling limit (above which transactions should be processed on-line). It is also possible to have a 1 in an online counter, and a check against a hot card list (which is only necessary for off-line transactions). If the result of any of these tests is positive, the terminal sets the appropriate bit in the terminal verification results (TVR).
The results of previous processing steps are used to determine whether a transaction should be approved offline, sent online for authorization, or declined offline. This is done using a combination of Terminal action codes (TACs) held in the terminal and Issuer action codes (IACs) read from the card.
An online-only device such as an ATM always attempts to go on-line with the authorization request, unless declined off-line due to Issuer action codesâ€”Denial settings. During IAC Denial and TAC Denial processing, for an online only device, the only relevant Terminal verification results bit is "Service not allowed".
When an online-only device performs IAC Online and TAC Online processing the only relevant TVR bit is "Transaction value exceeds the floor limit". Because the floor limit is set to zero, the transaction should always go online and all other values in TAC Online or IAC Online are irrelevant.
Online-only devices do not need to perform IAC-default processing.
First card action analysis (back to top)
One of the data objects read from the card in the Read application data stage is CDOL1 (Card Data object List). This object is a list of tags that the card wants to be sent to it to make a decision on whether to approve or decline a transaction (including transaction amount, but many other data objects too). The terminal sends this data and requests a cryptogram using the generate application cryptogram command. Depending on the terminal's decision (off-line, online, decline), the terminal requests one of the following cryptograms from the card:
- Transaction certificate (TC) Off-line approval
- Authorization Request Cryptogram (ARQC) Online authorization
- Application Authentication Cryptogram (AAC) Off-line decline.
This step gives the card the opportunity to accept the terminal's action analysis or to decline a transaction or force a transaction on-line. The card cannot return a TC when an ARQC has been asked for, but can return an ARQC when a TC has been asked for.
Online transaction authorization (back to top)
Transactions go online when an ARQC has been requested. The ARQC is sent in the authorisation message. The card generates the ARQC. Its format depends on the card application. EMV does not specify the contents of the ARQC. The ARQC created by the card application is a digital signature of the transaction details which can be checked in real time by the card issuer. This provides a strong cryptographic check that the card is genuine. The issuer responds to an authorization request with a response code (accepting or declining the transaction), an authorization response cryptogram (ARPC) and optionally an issuer script (a string of commands to be sent to the card).
Second card action analysis (back to top)
CDOL2 (Card data object list) contains a list of tags that the card wants to be sent after online transaction authorization (response code ARPC, etc.). Even if for any reason the terminal could not go online (e.g., communication failure), the terminal should send this data to the card again using the generate authorisation cryptogram command. This lets the card know the issuer's response. The card application may then reset off-line usage limits.
If a card issuer wants to update a card post issuance it can send commands to the card using issuer script processing. Issuer scripts are encrypted between the card and the issuer, so are meaningless to the terminal. Issuer script can be used to block cards, or change card parameters.