COMP1

Click to E-mail

Transaction Flow

An EMV transaction has the following steps:

Application selection (back to top)

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.

Read application data  (back to top)

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.

Processing restrictions  (back to top)

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  (back to top)

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:

  • Signature
  • 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  (back to top)

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).

Terminal action analysis  (back to top)

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.

Issuer script processing  (back to top)

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.

Home | About Us | Request More Info | POS Systems | Computer Services | EMV Compliance | History | Differences and Benefits | Chip Differences | CNP Transactions | Commands | Transaction Flow | Control of EMV Standard | EMV Documents | Vulnerabilities | USA Implementation | FAQ | Contact Us |

Southernmost POS Systems & Consulting, LLC
a division of
The Whole Nine Yards, LLC

138 East Sandy Circle - Big Pine Key, FL 3304303132
USA Toll Free: 877.771.8226 - Local: 305.433.5542
Fax: 305.851.8035 or 305.489.0365
Cell: 305.924.2781