EMV Transaction Flow Diagram

Process Description

EMV Steps

CreditCall's Kernel Process

Card detection and reset needs to be performed by the card interface functions specific to the hardware device being used. When a card is reset, it will respond with an Answer To Reset (ATR) that specifies how the terminal must interface with the card. Card Detection and Reset
arr
When using the CreditCall EMV.LIB Kernel, the terminal application will use the Hardware Abstraction Layer functions to detect and read cards. When using the CreditCall EmvX Kernel, this processing will be performed in the card reader drivers.
The terminal has a list containing the Application Identifier (AID) of every EMV application that it is configured to support, and the terminal must generate a candidate list of applications that are supported by both the terminal and card. The terminal may attempt to obtain a directory listing of all card applications from the card's PSE. If this is not supported or fails to find a match, the terminal must iterate through its list asking the card whether it supports each individual AID.

If there are multiple applications in the completed candidate list, or the application requires it, then the cardholder will be asked to choose an application; otherwise it may be automatically selected.
Candidate List Creation
arr

The CreditCall EMV.LIB Kernel has a single function that will build the candidate list, and the terminal application can then use the Hardware Abstraction Layer to allow the cardholder to select an application.


The CreditCall EmvX Kernel has a single function that will build the candidate list, and the PIN-pad driver will be used to allow the cardholder to select an application.

When the application to use has been chosen, the terminal must select the application on the card, so that the card can supply the correct data records for the transaction. Application Selection
arr

In the CreditCall EMV.LIB Kernel, all these processing steps will be performed in a single function. When required, EMV.LIB will call the Hardware Abstraction Layer functions to communicate with the card, perform secure PIN entry, perform RSA and SHA-1 encipherment and to perform an online authorization with the card issuer.

 

In the CreditCall EmvX Kernel, all these processing steps can be performed in a single function. When required, EmvX will use the card reader, PIN-pad and display driver interfaces to communicate with the card, perform secure PIN entry and to update the display. If provided, it will also use the EFT interface to perform an online authorization with the card issuer. If the payment application wishes to pause execution after any step then a break state can be set, and once the application has performed any necessary processing, then the Kernel will resume the processing.

Once the application has been selected, the terminal provides the card with any data that it requests in the PDOL and gets the processing options. The card will supply the Application File Locator (AFL), which is used by the terminal to read the application data records from the card. These records contain the card PAN and expiry date, plus many other tags of information that are used for transaction processing such as cardholder verification and card authentication. Read Application Data
arr
These steps can be performed in any order. There are three types of offline Data Authentication that can be performed, but the method to be used depends on the capabilities of the card and terminal. Online-only terminals are not required to support data authentication, but all other terminals must support both SDA and DDA and may also support CDA. SDA - Static Data Authentication of the card data (e.g. account number and expiry date) to verify that it has not been modified. DDA - Dynamic Data Authentication of card and terminal data to verify that the card application and data are genuine. CDA - Combined DDA and Application Cryptogram Generation. Data Authentication
arr
Cardholder verification checks that the person using the card is the cardholder. The card contains a list of verification methods that it supports, and the conditions under which they should be applied. The terminal must navigate through this list and attempt the first method it finds for which the condition is met. If a method fails, the terminal must check whether additional methods are allowed. For example, a list might contain: online PIN (if unattended cash), offline PIN (if supported), signature (always). Cardholder Verification
arr
Processing restrictions allow the terminal to determine the compatiblity of the applications on the card and terminal. This involves checking if their Application Version Numbers match, if the card application is expired or pre-valid, and whether the Application Usage Control (AUC) permits the current transaction to be performed. Processing Restrictions
arr
To safeguard against fraudulent use, the terminal will manage the level of risk by requiring certain transactions to be online authorized that would otherwise have been authorized locally. This involves comparing the transaction amount against floor limits, and detecting when the number of consecutive offline transactions on a card has reached a defined limit. In addition, offline-capable terminals will also randomly select certain transactions to go online. Terminal Risk Management
arr
The terminal will analyse the results of the previous verification, authentication and risk steps and this will result in the terminal informing the card that it proposes to either seek online authorization of the transaction, or to complete it offline by accepting or declining the transaction locally. Terminal Action Analysis
arr
"During the first Card Action Analysis step, the card will analyse the results of all the previous steps and this will result in the card requesting the terminal to either seek online authorization of the transaction, or to complete it offline by accepting or declining the transaction locally. This request may differ from the action that the terminal proposed following Terminal Action Analysis, but is subject to certain logic rules (e.g. the card is not permitted to request offline acceptance of the transaction if the terminal proposed online authorization). Card Action Analysis
arr
The terminal must perform the action that the card requested during card action analysis. Online Offline Decision
arr
Online processing enables the card issuer to analyse the transaction details and decide whether it wishes to authorise or reject the transaction. This allows the issuer to check the account status and apply criteria based upon acceptable limits of risk defined by the card issuer, the payment scheme and the acquirer. If no valid response is received from the host (e.g. due to communications failure) then the terminal is required to perform additional Terminal Action Analysis to manage the increased level of risk, and this will result in the terminal informing the card that it proposes to either accept or decline the transaction locally.; Online Processing
arr
During the second Card Action Analysis step, after online processing has been performed, the card will analyse the result of the online processing and will authenticate data received from the card issuer. This will result in the card requesting the terminal to complete the transaction by either accepting or declining the transaction. This request may differ from the result of online processing, but is subject to certain logic rules (e.g. the card is not permitted to request acceptance of the transaction if the host declined the payment). Second Card Action Analysis
arr
When the card processing has been completed, the card may be removed. If the transaction has been authorized then payment can be submitted for settlement and any goods or services can be provided. Transaction Completed
arr
When using the CreditCall EMV.LIB Kernel, the terminal application will use the Hardware Abstraction Layer functions to detect the card removal, and can retrieve any required data from the Kernel. When using the CreditCall EmvX Kernel, the card reader drivers will detect the card removal and the terminal application can retrieve any required data from the Kernel.

 

EMV Kernel by CreditCall Home
Give us a call  dots UK +44 117 930 44 55
  USA  +1 800 868 1832

 

Copyright © 2001 - 2014 CreditCall All Rights Reserved | site map | privacy | terms & conditions    

Powered By Intergage | www.intergage.co.uk