EMV Overview

The purpose of this section is to provide a quick reference to the different contact and contactless EMV transaction flows. This section does not supersede the specifications maintained by EMVCo or the card brands, and may refer to those documents.

EMV characteristics

EMV Benefits

The purpose of EMV is to provide a payment system standard based on smart cards (also known as chip cards), with a number of benefits:

• Global interoperability for smart card based payments.
• Card counterfeiting is significantly more difficult than with magnetic stripe cards
• Devalues transaction data.
• In transaction environments, where allowed, the EMV chip can make offline authorization decisions on behalf of the issuer.
• The card can have embedded risk management features managed by the issuer (such as risk decision, offline PIN, etc.), thus reducing the impact of lost/stolen scenarios.
• The card can be dynamically updated or modified by the issuer during a transaction.

Offline and Online transactions

When it comes to transaction authorization, it is necessary to differentiate offline and online scenarios:

• Offline authorization scenario

  • Offline approval
    The terminal requests, in the First Generate AC, a Transaction Certificate (TC). The card approves the transaction based on settings defined by the issuer. The transaction was not sent online for authorization. This scenario is defined as an “offline transaction.”

  • Offline decline
    An offline decline can be a result of either the First Generate AC (before an online authorization request), or Second Generate AC (after an online authorization request).

    This scenario can occur in three cases:

    • The terminal requests, in either the First or Second Generate AC, an offline approval from the card, but the card chooses to decline.
      • The terminal may request an offline approval in the Second Generate AC if the terminal tried to go online for authorization but was unable to do so.
      • The terminal requests, in the First Generate AC, an offline decline which is granted by the card. This is used in certain scenarios such as refunds, reversals, etc.
      • The terminal requests the card to provide a cryptogram to go online for authorization but the chip rejects the request and declines offline.

• Online authorization scenario
  Online authorization scenarios occur in the situations where the terminal requests the transaction go online to the issuer for approval (standard scenario in North America) or if the terminal requests an offline approval but is asked to go online by the card. Whatever is the trigger for seeking online authorization of the transaction, there are three possible outcomes:

  • Online approval:
    The issuer approves the transaction online.

  • Online decline:
    The issuer declines the transaction. This can happen for many reasons (insufficient funds, card compromised, suspected fraud, etc.).

  • Online approval declined by the card:
    The issuer can grant authorization to the transaction online but the card chooses to decline the transaction. This can happen for many reasons (e.g: information received from the issuer is suspicious or suspected fraud, other risk management parameters, etc.).

Full and Partial EMV transaction

This section reviews which step of the EMV transaction applies to full or partial transaction types.

• Full EMV transaction:
  Standard scenario for a purchase; all the steps of a standard EMV transaction flow are executed.

• Partial EMV transaction:
  Usually reserved for non-purchase scenarios, where the card is used as an authentication factor for the cardholder rather than a means of payment (e.g.: refund, reversal, etc.).

The table below summarizes the steps executed as part of the above two transaction configurations:

Contact EMV transaction flow

The EMV processing part of a payment transaction follows 11 specific steps.

Figure 12 EMV transaction steps

Select Application

The first step of the transaction consists of selecting the application to be used for processing. As EMV uses multi-application capable chip cards, cards can host multiple applications on the same card, such as:

• Debit and Credit application on the same card;
• Multiple debit (or credit) applications with different risk parameters.

Selection of the Application can be done in two different ways:

1. The terminal explicitly selects the AID (Application Identifier) by issuing multiple commands to the chip. The chip determines which applications supported by the terminal are also supported by the chip. The chip identifies a priority for each supported application, and the terminal chooses the highest mutually supported priority.

   

   Figure 13 Application Selection – Explicit selection

2. The card provides a list of supported AIDs from the PSE (Payment System Environment), which the terminal uses to select the application used for the transaction. The terminal will select a mutually supported application from the list based on the priorities set by the card for each application supported.

   

   Figure 14 Application Selection – Selection with PSE

Best Practice

• Application Selection should be made using the PSE (method 2 above), as it streamlines transaction processing, by avoiding unnecessary selection commands of non-present applications, and is more future-proof.

• Elavon recommends cardholder selection based on application name and merchant-preferred selection for the Application Selection.

Once a mutually supported application has been selected on the card, both card and terminal activate the chosen payment application to process the transaction.

Read Application Data

This step finds a mutually agreeable configuration – for both card and terminal – on how to perform the transaction.

The terminal issues a GET PROCESSING OPTIONS command to the card, providing the specific elements required by the application. In return, the card provides its processing capabilities (offline support, CVM supported, etc.) with a list of other elements required by the terminal.

These elements can contain, but are not restricted to:

• PAN
• PAN Sequence Number
• Application Usage Control
• Application Effective Date
• Application Expiry Date
• Issuer Action Codes
• Issuer Public Key Certificate

Upon receiving this information, the terminal engages in the EMV Risk Management portion of the transaction (steps 3 to 6). The resulting decision determines if the transaction can be conducted offline or online.

Best Practice

• Mod-10 verification is not recommended for online authorized transactions. For offline authorized transactions, Elavon recommends merchants to perform mod-10 check on credit products only (debit transactions cannot be performed offline).

• Merchants may compare the PAN in tag 5A to the PAN in Track-2 equivalent data if the information is available (not applicable for P2PE implementations).

EMV Risk Management

Offline Data Authentication

Offline Data Authentication is performed by the terminal to validate the authenticity of the chip card. This is executed using public key cryptography methods and digital signatures on the card. One of three possible Offline Data Authentication methods can be used: SDA, DDA, or CDA.

Best Practice

• Offline data authentication is an optional step for online-only terminals. However, Elavon strongly recommends performing this step.
• For clients in the United States and Puerto Rico supporting Offline Data Authentication, Elavon recommends supporting SDA, DDA and CDA.

Processing Restrictions

The terminal kernel checks if there are any restrictions set by the issuer. This includes the expiry and effective date of the application, if the card can be processed domestically or internationally, and which transaction types the card can perform, such as cash or cashback. This step is similar to the Service Code check performed in the magnetic stripe transaction process.

Best Practice

Elavon recommends checking for application effective and expiration date.

The EMV kernel checks if the card application (AID) selected for the transaction is not yet effective or no longer effective (i.e. expired) by checking the Application Effective Date and Application Expiration Date (if present). The results of the corresponding check are saved in the TVR. Whether the transaction is declined or not depends on whether the acquirer has set the corresponding bits in the ‘Terminal Action Code - Denial.’’ The logic is applied to all card brands, but the different values of ‘Terminal Action Code – Denial’ can be defined per AID supported by the terminal.

Cardholder Verification

The kernel identifies a commonly supported Cardholder Verification Method (CVM) based on a list of CVM preferences set by the issuer on the card, and the list supported by the kernel.

Cardholder Verification Methods presently defined in the EMV specification are:

• Offline PIN (encrypted and plaintext)
• Online PIN (encrypted)
• Signature
• No CVM

Contactless transactions have an additional CVM available, CDCVM (Consumer Device CVM). In CDCVM, the cardholder authenticates themselves directly to the contactless payment instrument. Authentication could be through a PIN or various biometric options (i.e. fingerprint, etc.). Offline PIN is not supported for contactless transactions.

Terminal Risk Management

During this step in the EMV processing, merchant system-specific parameters (such as floor limit, random selection for online, and exception file check) set for the kernel are executed. This step is optional for an online only terminal. Terminal risk management must always be performed by offline-capable terminals.

Terminal Action Analysis

After execution of the EMV Risk Management process (steps 3 to 6), the terminal can now make a proposition about how the transaction should be conducted, based on:

• The risk assessment conducted in the previous steps (results are stored in the TVR)
• The Terminal Action Codes
• The Issuer Action Codes

The terminal can propose to:

• Decline the transaction offline
• Approve the transaction offline
• Go online to obtain authorization

This proposition is then sent to the card using the First Generate AC command for decision.

Card Action Analysis

Based on issuer-defined rules and limits (also known as the card risk management parameters), the card will respond with a verdict regarding the transaction outcome. Similar to the kernel, when the chip conducts its risk management, it will record the results in the Card Verification Results (CVR) field. The CVR is later passed to the terminal and then to the issuer indicating the chip’s analysis of the current transaction, as well as any previous transaction indications that have not been communicated to the issuer. Unlike the TVR, the CVR format is dependent on the chip’s application specification.

The chip can only respond with the same verdict or a more restrictive verdict.

For example, if the terminal asks the card to decline the transaction offline, the chip must respond with a decline cryptogram. However, if the terminal asks the card to approve the transaction offline, the chip can either agree, decide to go online, or decline the transaction.

Figure 16 Terminal proposition – Card decision

Online Authorization

If the transaction is sent online for authorization (standard scenario in North America), the issuer host then performs its own set of verification steps before delivering a decision. The decision is based on the following:

• Whether the card is genuine (verification of the CAM via the cryptogram validation)
• The transaction data provided by the card and the terminal
• The Application Transaction Counter (ATC) value
• A set of financial rules related to the cardholder account (e.g: sufficient balance or credit limit)

At the end of this step, the issuer will send its decision back to the terminal in the form of:

• The ARC (Authorization Response Code), a 2 or 3 digit value defining the authorization disposition
• An Application Response Cryptogram (ARPC), to be sent back to the card
• (Optionally) Issuer Scripts, used to perform management actions on the card (e.g: PIN reset or modification, application block, card risk parameter update, etc.)

Issuer Scripting

Issuer scripting is a mechanism that allows issuers to perform management actions on a smart card. These scripts are updates in the form of data values that are sent along with the issuer response in addition to Issuer Authentication Data (Tag ‘91’).

Examples of issuer scripts are:

• Resetting/changing the PIN
• Blocking a smart card
• Blocking and unblocking an application
• Modifying the number or amount of offline transactions allowed

Issuer scripts are not present in each transaction. The execution of this step is optional in a standard EMV transaction. If the issuer sends issuer scripts to be executed, the terminal must support their execution.

Issuer scripts received from the acquiring host will contain a payload and a length. However, in the case of Visa, MasterCard and Discover, the length is calculated in an improper manner today; the length is calculated based on the number of characters in the payload as opposed to the number of bytes.

In order to transmit the correct length to the card, merchants shall ensure that the length calculation is performed as below.

• Extract the first 2 ASCII characters to get the TAG (Either ‘71’ or ‘72’)

  • Convert to the HEX representation

• Extract the fifth character through the end of the string

  • Convert to the HEX representation
  • Calculate the length of the string in HEX

• Build script string

  • Add Tag in HEX
  • Add calculated Length in HEX
  • Add Script in HEX

• Send string results

Completion

In this step, the terminal must pass the elements received from the issuer (ARC, cryptogram, etc.) to the card. The card then has the capability to issue a final verdict regarding the transaction execution (approve/decline).

APDU command summary

The following table summarizes the APDU commands used at each step of the EMV transaction.

Contactless transaction flow

Contactless transactions can be implemented using EMV, but some legacy implementations exist, such as MSD. For the purpose of this guide, we will focus on the contactless EMV implementation.

A contactless EMV transaction shares a number of characteristics with standard EMV contact transactions. In order to increase transaction speed, certain steps are not applicable. Although most of the features are similar, a number of specific risk management techniques are used for contactless.

Contactless terminal limits

Contactless terminal configurations include two limits specifically for contactless transactions:

• Floor Limit – Transaction amounts above this limit must go online for authorization

• CVM Limit – Transaction amounts above this limit requires a positive CVM (e.g. PIN, signature, etc)

Offline PIN CVM

Offline PIN is not supported by implementations when it comes to contactless. Do the following in order to avoid “double tap” scenarios and a slowdown in transaction processing speed:

• One “tap” to select the application and initiate processing
• Processing interruption and PIN entry on the terminal
• One “tap” to verify the PIN and complete the transaction

When using this type of CVM, multiple tap scenarios are possible.

However, these scenarios are distinct from an offline PIN CVM as the CVM (PIN/biometric) value is entered on the Mobile/Consumer device rather than on a certified PIN-entry device.

Generic contactless flow

In this section, we will define the standard contactless transaction steps, as compared to the contact EMV transaction steps.

Figure 17 Contactless transaction overview

Main differences from contact transaction flow

Pre-conditions

A number of checks are performed by the terminal in the pre-processing phase. As the limits are managed differently from a contact transaction (see Contactless terminal limits), the ‘Amount, Authorized’ must be known before the pre-conditions step as the transaction may exceed the contactless CVM transaction limit.

The unpredictable number must also be known before the pre-conditions step.

The other configuration data elements processed during the Pre-Condition processing step must be retried in the terminal configuration per supported application (supported AID):

• Terminal Floor Limit
• Terminal Contactless Floor Limit
• Terminal CVM Required Limit
• Status Check Support Flag
• Zero Amount Allowed Flag
• Terminal Transaction Qualifiers (Visa only, see Card Transaction Qualifiers)

Pre-Processing

Once the configuration data elements have been retrieved, the terminal must then execute the following checks for each application supported:

• Are the limits exceeded?
• Is contactless allowed?

As a result of pre-processing, the terminal can then activate the contactless protocol and match its supported applications against the one supported by the card.

Protocol Activation

In this step, the terminal will:

• Activate the contactless interface
• Request the card to be presented
• Perform anti-collision protocol

Application selection

The contactless flow is designed for speed (“tap-and-go”) and, for this purpose, is set to limit user interactions. The application selection step is executed differently from the application selection process explained for contact (see Select Application).

In a contactless application selection, the goal is to automatically select the application to be used for the upcoming transaction.

The application selection step is executed as follows:

• The terminal sends a SELECT command to the card to retrieve the PPSE (Proximity Payment System Environment). PPSE is a predefined data element (2PAY.SYS.DDF01) present on the card. The PPSE command and format of the data element on the card is standardized and will not vary between brands.

• The contactless card provides the PPSE returned in the SELECT response, containing the Application Priority Indicator for any applications supported.

• The terminal matches the application list returned against its own list of supported applications.

  • If only one application is mutually supported by the card and the terminal, this application is selected for processing without customer confirmation.
  • If multiple applications are mutually supported, the terminal automatically selects the application with the highest Application Priority Indicator. This point differs from contact EMV processing.
  • If no applications are mutually supported, the transaction is aborted. The message displayed may be different from a declined transaction and may encourage the cardholder to try using an alternate interface (e.g.: contact).

• The appropriate kernel is then activated using the selected application identifier and application processing continues.

Best Practice

If the contactless transaction fails, the terminal may display a message encouraging to try an alternate interface to execute the transaction.

Protocol deactivation

When the kernel processing has finished, the kernel indicates which additional services are required:

• Decline the transaction
• Require Cardholder Verification (Signature, Online PIN, No CVM)
• Switch to an alternate interface
• Restart the transaction

Brand specific flows

Visa

The implementation for Visa contactless, although inspired by EMV, is significantly different from a standard contactless EMV transaction. The number of commands exchanged between the card and the terminal are reduced to increase transaction speed.

In the Visa implementation, it means all elements are exchanged as part of the Read Application Data step.

Figure 18 Visa contactless transaction flow

Terminal Transactions Qualifiers

Terminal Transaction Qualifiers (Tag ‘9F66’) is a terminal data element indicating capabilities and transaction-specific requirements (e.g., online) of the terminal. It is requested by the card in the PDOL and used by the card to determine how to process the transaction.

Card Transaction Qualifiers

The TTQ (Terminal Transaction Qualifiers) is passed to the card as part of the PDOL data. The TTQ indicates which CVM the terminal supports and whether CVM is required. The card then makes a decision based on its own risk processing and informs the terminal which CVM method it should perform. This is done using a proprietary tag called Card Transaction Qualifiers (Tag ‘9F6C’). The CTQ is passed to the terminal in the GET PROCESSING OPTIONS command response.

Offline Data Authentication

Visa allows for Offline Data Authentication using the proprietary fDDA (fast DDA) implementation.

There are a few significant differences with a standard EMV ODA implementation:

• The fDDA signature is generated as part of the GET PROCESSING OPTIONS command and does not use the INTERNAL AUTHENTICATE command.

• fDDA uses data from the PDOL in order to generate the signature and does not use a separate DDOL.

• The fDDA signature is verified by the terminal and not sent online to the issuer.

Cryptogram Version

In Visa qVSDC (Quick Visa Debit/Credit) implementation – also referred to as Visa EMV – three different Cryptogram Versions can be used: CVN 10,17, or 18. Based on the CVN (Cryptogram Version Number) used for the transaction, the data required in the PDOL will differ. The table below summarizes the minimum data elements required (minimum PDOL) to execute the Card Action Analysis and compute the Application Cryptogram:

MasterCard

MasterCard contactless EMV implementation is referred to as MasterCard Paypass M/Chip. The transaction flow is very similar to a standard transaction execution. However, there is only one Generate AC command executed as part of the transaction. Issuer Scripting is not supported.

Figure 19 MasterCard contactless transaction flow – overview

Offline Data Authentication

Only the CDA method is allowed for MasterCard PayPass M/Chip.

Introduction to Quick Chip and M/Chip Fast

In order to address concerns over transaction times in the U.S., the card brands announced an alternate implementation of EMV that uses a subset of the standard EMV features.

This implementation, known as Quick Chip (for Visa, Discover, and American Express) or M/Chip Fast (for MasterCard), allows the user to insert their card before the final amount of the transaction is known, and remove it earlier in the transaction process. For simplicity this is referred to as Faster EMV.

Implementation

Standard EMV flow

Standard EMV implementation requires the final amount to be known before the transaction is executed, and the card to remain inserted throughout the transaction.

The steps of EMV execution, including the steps requiring cardholder interaction (application selection, amount confirmation, CVM) can only start once the final amount (tag ‘9f02’ - Amount, Authorized) is known.

The card can only be removed when:

• The authorization request has been completed online
• The TC has been generated
• (Optionally) Issuer scripts have been executed

Faster EMV flow

Faster EMV addresses the two restrictions above and allows the following process:

Figure 21 Quick Chip transaction execution

In this flow, the card can be inserted before the final amount is known, allowing some of the processing steps to be executed while the merchant system executes other actions of the sale transaction (e.g: scanning items)

1. The card is inserted.

2. An EMV transaction is initiated using a Placeholder Amount as the Amount, Authorized (Tag ‘9F02’). Note that this amount may not be equal to the final transaction amount. It is only used to execute the EMV transaction (i.e. verify ODA, perform risk management, verify CVM, etc.).

3. The terminal requests an ARQC in the First Generate AC command (request online authorization) based on the placeholder amount to which the card responds appropriately.

4. The terminal sends a Second Generate AC command with a response code ‘Z3’ (Unable to go online) and stores the ARQC from the First Generate AC command. It requests an AAC in the Second Generate AC command (i.e. transaction aborted).

5. The cardholder is prompted to remove their card.

6. Once the final amount of the transaction is known, the terminal then initiates an online authorization request with:

   • The ARQC collected from the card, based on the placeholder amount. Both the Application Cryptogram and the Amount, Authorized tag are based on this placeholder amount.

   • The real transaction amount is sent to the issuer in the financial message amount field (e.g. DE 4 in ISO-8583).

In effect, steps 3-6 are similar to a deferred authorization scenario.

Cashback

Cashback is possible when using Faster EMV. However, the cashback amount needs to be known before the transaction is initiated (while the real transaction amount may not).

In a cashback scenario the EMV processing is then initiated with:

• The Placeholder Amount in tag ‘9f02.’
• The real cashback amount in tag ‘9f03’ (Amount, Additional).

The authorization transaction will contain (based on an ISO-8583 message scenario):

• DE 4
  • Actual amount of the transaction including the cashback amount
• DE 55
  • Placeholder Amount in tag ‘9f02’
  • Cashback amount in tag ‘9f03’

Key differences with Classic EMV

This implementation allows the cardholder to retrieve the card faster but with certain consequences:

• The cardholder cannot confirm the real transaction amount before the transaction is executed. However, the final amount can be displayed at the end of the transaction.
• The Authorization request will contain two different amounts:
  • The placeholder amount in DE 55 – Tag 9f02
  • The real transaction amount in DE 4
• Card risk management, including CVM processing, is based on the placeholder amount, which can be different from the actual amount (e.g. placeholder amount can be under the CVM limit, while actual amount will be above).
• Card risk management based on the issuer data (ARPC validation, second Card Action Analysis) cannot be executed.
• Issuer scripting cannot be executed.

Best Practice

• Placeholder amount is at discretion of the Merchant. However, it is highly recommended to use the average high ticket value for the placeholder amount.

• POS solutions that implement both Classic EMV and Faster EMV should make the switch between two modes configurable.

• previousCertification Process
• nextEMV Transaction Processing