Some suggestions for analyzing EMV transactions and results

 Check Mandatory Tags are present in the Transaction request as suggested by the Host
specification (Vantiv/FirstData…etc). Please thoroughly refer to the specific EMV sections in
these documents as the information is scattered across and you will need to collate it.

 Check Optional Tags are present in the Transaction request as suggested by the Host
specification (Vantiv/FirstData…etc). You may have to refer to Local Journal for cross
verification. Please thoroughly refer to the specific EMV sections in these documents as the
information is scattered across and you will need to collate it.

 Always, Refer to EMVCo Book 3 and Book 4 for any more/additional information.

Transactions/Conditions EMV Tags and other Additional Comments

behaviors to Look / Check
Transaction is Sent for Online Authorization Value of 9F27 = 80 (ARQC)
OR Check that 9F26 exists
Online (Authorization) Request (Application Cryptogram)
9F27 is called Cryptogram
Information Data (CID)
/ FYI
The Chip and POS
have MUTUALLY
decided to go to the
Host (issuer) to decide
the outcome of the
transaction.

Transaction is Declined ONLINE by HOST Value of 9F27 = 00 (AAC)
Value of 8A is not “00”
(3030)
Transaction is Offline Approved Value of 9F27 = 40 (TC)
OR
Offline Approval/Authorization Value of 8A = Y1 (or Y3, if
terminal is unable to go
online)
Transaction is Approved ONLINE by HOST Value of 9F27 = 00
Value of 8A = “00” (3030)
This is sometimes
referred to as Online
Mutual
Authentication.
8A (Authorization
Response Code) is
sent back in the Host
response
The transaction has
been locally approved
between the POS and
the Chip card (without
ever going to the
host…)
The POS and Chip
have decided to go to
the host (issuer) to
decide the outcome.
The host has
approved the
transaction. 8A
(Authorization
Response Code) is

Transaction is Offline Declined Value of 9F27 = 00
OR
Offline Declined Value of 8A = Z1 (or Z3, if
terminal is unable to go
online)
Cardholder Verification Methods (CVMs) 1) Check and Interpret TVR
Bytes/Bits
>Offline PIN 2) Check and Interpret for
>Online PIN 9F34 CVM Results
>Signature 3) Online PINs contain PIN
BLOCK/PIN DATA in Request
4) Offline PINs do not have
such data in Request
Fallback Scenario Chip transaction fails and
you are prompted to Swipe
the card
Chip Reversal 9F27=00 (AAC/Decline, most
common scenario of Chip
reversal)
9F27 = 40 (TC/Approval,
technically possible, rarely
happens)
Issuer Scripts 71, 72
sent back in the Host
response
The transaction has
been locally declined
between the POS and
the Chip card (without
ever going to the
host…).
No meaning to go to
host for its decision.
Refer EMVco Books 3
and 4 for
interpretation.
It is good to Check for
(POS) Entry Mode
field to indicate that
Magstripe was used as
the Entry mode (check
for the exact values
of EMs with the team)
Chip will REVERSE the
outcome of the
Transaction. For
example, if Host says
approved, Chip will
reverse it and say it
declines (and vice
versa).
Usually a Chip reversal
means a DECLINE
(9F27 = 00) by the
Chip
Issuer Scripts are sent
by the Host to the POS
in the Response
message. These are
optionally sent and
may not be present
for all transactions

Issuer Script Results (ISRs)
(which is the most
usual scenario).
These are sent for
example, to block a
card, to unblock a PIN,
to unblock an
application etc.
9F5B - Refer to Host spec This EMV tag captures
document for this tag. the Results or the
outcome of the Issuer
scripts that were
executed.