Cookies improve how our website works and how it is used, so that we can continue to improve the site.

For more information see our cookie policy.

By using this website you are agreeing to our use of cookies.

What is EMV? > EMV Contact - Transaction Flow Chart

How EMV (Chip & PIN) Works - Transaction Flow Chart

Card detection and reset needs to be performed by the card Card When using the NMI (formerly Creditcall) EMV.LIB Kernel, the
interface functions specific to the hardware device being used.
Detection and terminal application will use the Hardware Abstraction Layer
When a card is reset, it will respond with an Answer To Reset functions to detect and read cards.
(ATR) that specifies how the terminal must interface with the Reset
card. When using the NMI (formerly Creditcall) EmvX Kernel or the
NMI (formerly Creditcall) EmvJ Kernel, this processing will be
performed in the card reader drivers.

The terminal has a list containing the Application Identifier (AID) Candidate The NMI (formerly Creditcall) EMV.LIB Kernel has a single
of every EMV application that it is configured to support, and the
List Creation function that will build the candidate list, and the terminal
terminal must generate a candidate list of applications that are application can then use the Hardware Abstraction Layer to
supported by both the terminal and card. The terminal may allow the cardholder to select an application.
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 NMI (formerly Creditcall) EmvX Kernel and the NMI
the terminal must iterate through its list asking the card whether it (formerly Creditcall) EmvJ Kernel both have a single function
supports each individual AID. that will build the candidate list, and the PIN-pad driver will be
used to allow the cardholder to select an application.
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.
EMV Level 2 Kernels https://www.level2kernel.com/flow-chart.html

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 In all of the NMI (formerly Creditcall) Kernels, all of these
Selection processing steps can be performed in a single function.
However, 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.

When required, EMV.LIB will call the Hardware Abstraction

Once the application has been selected, the terminal provides
the card with any data that it requests in the PDOL and gets the
Application
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 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.
Data
When required, EmvX and EmvJ 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.

There are three types of offline Data Authentication that can be Data
performed, but the method to be used depends on the
Authentication
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.

Cardholder verification checks that the person using the card is Cardholder
the cardholder. The card contains a list of verification methods
Verification
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).

Processing restrictions allow the terminal to determine the Processing

compatibility of the applications on the card and terminal. This
Restrictions
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.

To safeguard against fraudulent use, the terminal will manage Terminal Risk
the level of risk by requiring certain transactions to be online
Management
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.

The terminal will analyse the results of the previous verification, Terminal
authentication and risk steps and this will result in the terminal
Action
informing the card that it proposes to either seek online
authorization of the transaction, or to complete it offline by Analysis
accepting or declining the transaction locally.

2 of 4 17/05/2022 17:32
 During the first Card Action Analysis step, the card will analyse Card Action
the results of all the previous steps and this will result in the card
Analysis
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).

The terminal must perform the action that the card requested Online Offline
during card action analysis.
Decision

Online processing enables the card issuer to analyse the Online

transaction details and decide whether it wishes to authorise or
Processing
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.

During the second Card Action Analysis step, after online Second Card
processing has been performed, the card will analyse the result
Action
of the online processing and will authenticate data received from
the card issuer. This will result in the card requesting the terminal Analysis
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).

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 When using the NMI (formerly Creditcall) EMV.LIB Kernel, the
Completed 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 NMI (formerly Creditcall) EmvX Kernel or the

NMI (formerly Creditcall) EmvJ Kernel, the card reader drivers
will detect the card removal and the terminal application can
retrieve any required data from the Kernel.

Login Talk to Our Team Insights Support

Full-Commerce Enablement ISVs Ecommerce Documentation Who We Are

Payment Gateway Features ISOs In-Person SDKs + APIs Careers

Processors + Devices Banks Mobile EMV Kernels News +

Press
Security + PCI Compliance Payment Facilitators Unattended + Self-
service
Payment Facilitator Enablement
Verticals You Serve
EMV Level 2 Kernels https://www.level2kernel.com/flow-chart.html

Switch to UK/EU site

CASE STUDIES

2021 Copyright Terms and Conditions Privacy Policy Cookie Policy GDPR Policy Modern Slavery Statement

4 of 4 17/05/2022 17:32