The document outlines the twelve-step process of EMV card transaction flow, starting from card detection to transaction completion. Each step involves different actions such as application selection, data authentication, and risk management, ultimately determining whether the transaction is accepted or declined. The document highlights key differences between online and offline transactions and ends with a prompt for further exploration of EMV services.

1. EMV CARD MIGRATION:
How the EMV Transaction Flow Works

2. Step One: Card Detection & Reset
During this step, the EMV card interfaces with the card terminal and responds
with an Answer to Reset (ATR) that communicates specifications about the
transaction about to take place.

3. Step Two: Candidate List Creation
EMV terminals have pre-installed lists of supported applications,
each with its own Application Identifier (AID). When you first
feed your card, the terminal generates a list of candidate applications
that will work for both the terminal and the card.
In certain cases, the terminal might try to pull up the directory from
your card’s Payment System Environment (PSE) or iterate through
its own list of stored AIDs to determine an appropriate match.
If you have more than one application on your card (say EMV and the
customary static application), the terminal will ask you to select your
preferred application.

4. Step Three: Application Selection
Here, the terminal performs a “get selected application” method on your card
to retrieve the necessary data for the transaction.

5. Step Four: Read Application Data
Next, the terminal requests your card data and retrieves processing
options.
In turn, your EMV card (basically, a Smart Card with on-card directories
that store data) supplies the terminal with the Application File Locator
(AFL).
This helps the terminal locate the correct directories, where it can read
data records and tags used to process the transaction and verify the
cardholder’s identity.

6. Step Five: Data Authentication
Important to Note: The Difference Between Offline and Online transactions
• Online transactions: typically refers to direct bank transactions (like, ATM
transactions, for example, where data authentication is optional).
• Offline transactions: typically happens at the point of sale with merchants,
and requires data to be authenticated (for good reason).
Data Authentication Types (depending on both the card and the terminal):
• Static Data Authentication (SDA): authenticating surface level data, like
account numbers and expiration dates.
• Dynamic Data Authentication (DDA): authenticating stored (dynamic) data
and the applications running on the card.
• Cryptogram Data Authentication (CDA): combines DDA and encryption to further
privatize data. It’s likely this will be the standard following wide EMV adoption.

7. Step Six: Processing Restrictions
Next, the terminal discovers any restrictions on the transaction.
This might include checking whether the application(s) on the card
have expired and if the Application Usage Control (AUC) will even
allow the terminal to proceed with processing the payment.

8. Step Seven: Terminal Risk Management
During this step, the terminal goes into risk management mode.
After assessing the level of risk, some transactions will need to be
verified online (by the bank or card issuer) if, say, the card exceeds
usage limits.

9. Step Eight: Terminal Action Analysis
Here, the terminal will analyze all the previous processes and
communicates a proposition – accept or decline – to the EMV card.

10. Step Nine: Card Action Analysis
This step seems a bit recursive, but the EMV card performs a similar
analysis on the above processes and either confirms the terminal’s
proposition to verify the transaction online, or continues with
authorization offline, on-site.

11. Step Ten: Online Offline Decision
The terminal then defers to the outcome of the Card Action Analysis.

12. Step Eleven: Online Processing
This step only applies if the transaction requires online authorization.
If needed, the card issuer will verify information (e.g., account status),
assess risk, and take action based on a set criteria. If the card issuer
cannot offer a valid response (due to a communication failure or error
message, for example), the terminal will the then analyze the transaction
further and manage the elevated level of risk.
Again, the terminal will offer the proposition – accept or decline – to the
EMV card for further review.

13. Step Twelve: Second Card Action Analysis
Here, the card makes the final decision, based on programed logic.
Once it’s analyzed the online processing results from the card issuer,
the card relays its final decision – accept or decline – to the terminal.

14. Step Thirteen: Transaction Completed
At long last (actually, this all happens pretty fast), payment processing is
complete, and the customer can remove their card from the reader.
If everything clears, then the customer can take the goods, else (if the card
was declined) they’ll have to take it up with their bank/card issuer.

15. Hope you found this useful! Still Curious?
Visit our site and our blog to read more about EMV
and learn about our marketing services and products.