EMV Implementation Tandem Supplemental Guide

EMV Implementation
Tandem Supplemental Guide

June 2023
Version 3.6.0.0
EMV Implementation Tandem Supplemental Guide Legal notice
Copyright © 2023 JPMorgan Chase & Co. All rights reserved.
This publication is for informational purposes only, and its content does not represent a contract or
agreement, in any form. Chase reserves the right to alter product specifications without notice. No part of
this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical,
including photocopy, recording, or any information storage or retrieval system, without Chase’s
permission.
All brand names and product names used in this document are trade names, service marks, or registered
trademarks of their respective owners. No part of this publication shall be construed as any license,
express or implied, to any of the respective owners’ trade names, service marks or trademarks or any
patents, copyrights or other intellectual property of JPMorgan Chase Bank, N.A., and its respective
affiliates and shall not be used or furnished as any reference and/or in connection with any
advertisement, announcement, release or promotional materials by any persons other than such
respective owners.
Page 2
EMV Implementation Tandem Supplemental Guide What’s new
What’s new
Version 3.6.0.0
The following updates have been made since version 3.5.0.0:
Effective upon publication
UPI CVM limits
• Under EMV Testing Parameters > UnionPay via Discover Integration Testing Parameters.
changed the Contactless CVM Required Limit values to $250 CAD and $100 USD for both
UnionPay Credit and UnionPay Debit in the following topics:
o UnionPay Credit and Debit Contactless Testing Parameters
o UnionPay Quasi Credit and US Common Contactless Testing Parameters
Version 3.5.0.0
The following updates have been made since version 3.4.0.0:
Effective upon publication
UnionPay brand name
• Throughout the document, updated CUP references to UnionPay via Discover.
Page 3
EMV Implementation Tandem Supplemental Guide Contents
Contents
EMV Implementation ................................................................................................................................... 1
Tandem Supplemental Guide .................................................................................................................... 1
What’s new................................................................................................................................................... 3
Version 3.6.0.0 .......................................................................................................................................... 3
Version 3.5.0.0 .......................................................................................................................................... 3
Contents ....................................................................................................................................................... 4
Overview .................................................................................................................................................... 10
Purpose ................................................................................................................................................... 10
Scope....................................................................................................................................................... 10
Audience .................................................................................................................................................. 11
EMVCo LLC ............................................................................................................................................. 11
EMV Terminal Configurations.................................................................................................................. 11
Integrated solutions.............................................................................................................................. 11
Standalone solutions............................................................................................................................ 12
Fully Integrated ECR Solution ............................................................................................................. 12
Partially Integrated ECR Solution ........................................................................................................ 13
Semi-Integrated ECR Solution ............................................................................................................. 15
Standalone POS Solution with Internal PIN Pad ................................................................................. 16
Standalone POS Solution with External PIN Pad ................................................................................ 17
Safetech Encryption ................................................................................................................................ 18
Safetech Tokenization ............................................................................................................................. 19
EMV and Contactless Solution Components .......................................................................................... 19
Merchant Services Supported Configurations ......................................................................................... 20
US Debit .................................................................................................................................................. 22
Development Process............................................................................................................................... 32
Development and Testing........................................................................................................................ 32
Page 4
Technical Profile Questionnaire .............................................................................................................. 38
Training .................................................................................................................................................... 40
Technical Support .................................................................................................................................... 41
Development Host Connection Information ............................................................................................. 41
Integration Testing Process ..................................................................................................................... 41
Integration Testing Process ................................................................................................................. 42
Card Brand Certification .......................................................................................................................... 45
Pilot .......................................................................................................................................................... 47
Post Rollout Re-Test ............................................................................................................................... 47
EMV Contact and Contactless Test Tools ............................................................................................... 48
Collis Merchant Test Suite ................................................................................................................... 49
ICC Solutions Test Suite Bundles for Certification .............................................................................. 52
Integrated Solution Validation ................................................................................................................. 54
EMV............................................................................................................................................................. 55
EMV Benefits ........................................................................................................................................... 55
EMV Capability Enablement or Disablement .......................................................................................... 55
Online versus Offline EMV Transactions ................................................................................................. 55
EMV Transaction Steps ........................................................................................................................... 56
EMV Credit Transaction Set ................................................................................................................ 58
EMV Debit Transaction Set ................................................................................................................. 59
Transaction Processing ........................................................................................................................... 60
Sale Transactions ................................................................................................................................ 60
Authorization or Pre-Authorization Transactions ................................................................................. 60
Incremental Authorization .................................................................................................................... 61
Completions ......................................................................................................................................... 61
Return .................................................................................................................................................. 61
Balance Inquiry Transactions .............................................................................................................. 62
Quick Service Transactions ................................................................................................................. 62
Page 5
Contactless .............................................................................................................................................. 64
Contactless Benefits ............................................................................................................................ 64
MSD vs EMV Grade............................................................................................................................. 64
Contactless Card Schemes ................................................................................................................. 64
EMV Contactless Transaction Sets ..................................................................................................... 65
EMV Transaction Flow ............................................................................................................................ 67
Full EMV Transaction Flow .................................................................................................................. 67
Partial EMV Transaction Flow ............................................................................................................. 73
Contactless Transaction Flow .............................................................................................................. 76
Chip Processing Guidelines .................................................................................................................... 78
Tender Processing ............................................................................................................................... 78
EMV Transaction Initiation ................................................................................................................... 82
Chip Read Flow ................................................................................................................................... 83
Fallback Processing ............................................................................................................................. 86
Application Selection............................................................................................................................ 90
Read Data Records ............................................................................................................................. 98
Cardholder Language Selection .......................................................................................................... 99
Cardholder Prompting ........................................................................................................................ 100
Processing Restrictions ..................................................................................................................... 102
Offline Card Authentication ................................................................................................................ 104
Cardholder Verification ...................................................................................................................... 105
Terminal Risk Management ............................................................................................................... 113
Data Object Lists ................................................................................................................................ 115
Terminal Action Analysis.................................................................................................................... 117
1st Generate Application Cryptogram ................................................................................................ 118
EMV Offline Approvals ....................................................................................................................... 120
Online Response Processing ............................................................................................................ 121
External Authenticate ......................................................................................................................... 124
Page 6
2nd Generate Application Cryptogram .............................................................................................. 124
Transaction Completion Processing .................................................................................................. 126
EMV Parameter Download .................................................................................................................... 131
EMV Download Parameters .............................................................................................................. 131
PNS ISO Parameter Download Processing....................................................................................... 133
UTF Parameter Download Processing .............................................................................................. 135
Stratus EMV Parameter Download Processing ................................................................................. 137
EMV Contact and Contactless Parameters ........................................................................................... 138
Contact EMV Parameters .................................................................................................................. 138
Contactless EMV Parameters ............................................................................................................ 141
Host Message Processing ..................................................................................................................... 144
Host Transaction Sets........................................................................................................................ 144
Host Message EMV Fields ................................................................................................................ 150
Host Message EMV Tags .................................................................................................................. 153
Host Message Examples ................................................................................................................... 163
EMV Receipt Guidelines........................................................................................................................ 183
EMV Receipt Data ............................................................................................................................. 183
EMV Report Guidelines ......................................................................................................................... 195
EMV Transaction Report.................................................................................................................... 195
EMV Statistics Report ........................................................................................................................ 197
Technical Fallback Reports ............................................................................................................... 198
POS Entry Mode Report .................................................................................................................... 199
EMV Configuration Report ................................................................................................................. 200
EMV Public Key Load Report ............................................................................................................ 206
EMV Contact and Contactless Data Elements ...................................................................................... 208
EMV Contact and Contactless Data Elements Definitions ................................................................ 208
Reference Materials .............................................................................................................................. 243
EMV Testing Parameters ........................................................................................................................ 244
Page 7
Amex Integration Testing Parameters ................................................................................................... 244
Amex Credit Contact Testing Parameters ......................................................................................... 244
Amex Credit Contactless Testing Parameters ................................................................................... 245
UnionPay via Discover Integration Testing Parameters ........................................................................ 246
UnionPay Credit and Debit Contact Testing Parameters .................................................................. 246
UnionPay Credit and Debit Contactless Testing Parameters ............................................................ 247
UnionPay Quasi Credit and US Common Contact Testing Parameters ........................................... 248
UnionPay Quasi Credit and US Common Contactless Testing Parameters ..................................... 250
Debit Network Alliance Integration Testing Parameters ........................................................................ 251
Debit Network Alliance Debit Contact Testing Parameters ............................................................... 251
Debit Network Alliance Debit Contactless Testing Parameters ......................................................... 252
Discover Integration Testing Parameters .............................................................................................. 253
Discover Contact Testing Parameters ............................................................................................... 253
Discover Contactless Testing Parameters......................................................................................... 254
Interac Integration Testing Parameters ................................................................................................. 255
Interac Debit Contact Testing Parameters ........................................................................................ 255
Interac Debit Contactless Testing Parameters .................................................................................. 256
JCB Integration Testing Parameters ..................................................................................................... 257
JCB Credit Contact Testing Parameters............................................................................................ 257
JCB Credit Contactless Testing Parameters ..................................................................................... 258
Mastercard Integration Testing Parameters .......................................................................................... 259
Mastercard Credit Contact Testing Parameters ................................................................................ 259
Mastercard Credit Contactless Testing Parameters .......................................................................... 260
Mastercard Debit Contact Testing Parameters ................................................................................. 261
Mastercard Debit Contactless Testing Parameters ........................................................................... 263
Visa Integration Testing Parameters ..................................................................................................... 264
Visa Credit Contact Testing Parameters ........................................................................................... 264
Visa Credit Contactless Testing Parameters ..................................................................................... 266
Page 8
Visa Debit Contact Testing Parameters............................................................................................. 266
Visa Debit Contactless Testing Parameters ...................................................................................... 268
Wright Express Integration Testing Parameters.................................................................................... 269
Wright Express Credit Contact Testing Parameters .......................................................................... 269
Voyager Integration Testing Parameters ............................................................................................... 270
Voyager Credit Contact Testing Parameters ..................................................................................... 270
Appendix .................................................................................................................................................. 272
List of appendices .................................................................................................................................. 272
Appendix A Glossary ............................................................................................................................. 272
Abbreviations ..................................................................................................................................... 272
Terms ................................................................................................................................................. 282
Appendix B Reference........................................................................................................................... 305
Answer to Reset ................................................................................................................................. 305
ASCII Chart ........................................................................................................................................ 306
BCD to ASCII Conversion .................................................................................................................. 309
Canadian Processing ......................................................................................................................... 309
EMV Chip Commands ....................................................................................................................... 319
EMV Reference Tables ...................................................................................................................... 338
Page 9
EMV Implementation Tandem Supplemental Guide Overview
Overview
Purpose
This document is the Merchant Services EMV Implementation Guide specific to Point of Sale
environments. The information that follows encompasses the Merchant Services ISO, UTF and Stratus
host environments, which are referred to as the “host” or “Merchant Services host” throughout the
document.
Scope
This document provides guidelines for developing a Merchant Services EMV POS Solution:
• Terminal Configurations
• Merchant Services development and integration testing process
• EMV Transaction Flow
• Merchant Services EMV Best Practices
• Merchant Services EMV Requirements
• Host Message EMV Considerations
• Receipt and Report Guidelines
This document also includes EMV reference material useful during the development and integration
testing process:
• EMV Tag Descriptions
• EMV AID Lists
• EMV Parameter Configuration
• Certificate of Authority Public Key (CAPK) File Format
Page 10
Audience
This document is intended for Software Developers, Gateway Providers, Merchants, 3rd Party
Developers and Project Managers.
It is intended to provide a basic understanding of how Merchant Services handles EMV chip card
processing and how best to integrate their products to the Merchant Services host.
EMVCo LLC
EMVCo LLC is the regulator agency, originally formed by Europay International, MasterCard International
and Visa International, to manage, maintain and enhance the EMV Integrated Circuit Card specification
for Payment Systems. EMVCo is responsible for the EMV type approval process and compliance testing.
It is imperative that developers are familiar with the EMVCo requirements when developing their EMV
POS Solution. Current active EMVCo members are Amex, Discover, JCB, MasterCard, UnionPay via
Discover, and Visa.
This EMV Implementation Guide provides insight into EMVCo requirements and outlines the expected
EMV transaction flow. However, because EMV rules differ for each card brand and include rules specific
to the PIN Pad and related EMV chip interaction, it is not possible to provide all EMVCo and integration
testing requirements; nor is it possible to ensure this document always reflects the most current EMVCo
requirements. For the most current EMV information and to keep up to date with all EMV regulatory
updates, please refer to the EMVCo web site at emvco.com
Note: Within this document all EMV and contactless configurations are generically referred to as an “EMV
POS Solution”.
EMV Terminal Configurations

There are several possible EMV configurations which can be split into two categories; Integrated and
Standalone.
Integrated solutions
Integrated solutions generally have an Electronic Cash Register (ECR) directly connected to an external
PIN Pad which provides the EMV and contactless functionality. The smartcard reader, PIN entry
Page 11
capability and EMV kernel all reside within the external PIN Pad. There are three supported integrated
configurations each of which are detailed in following sections.
Standalone solutions
Standalone solutions consist of a POS terminal that utilizes a PIN Pad to provide the EMV and
contactless functionality. The smartcard reader, PIN entry capability and EMV kernel all reside within the
PIN Pad. All standalone solutions must adhere to PCI requirements and require full EMV integration
testing. There are two supported standalone solutions described later in this section.
Within this document all EMV and contactless configurations are generically referred to as an “EMV POS
Solution”.
Fully Integrated ECR Solution

In Fully Integrated mode the ECR application controls the transaction, provides the Merchant Services
host interface, and stores the authorization data. The ECR interfaces with an external PIN Pad for card
entry (swipe / tap / insert) and EMV kernel functionality. The ECR builds the Merchant Services host
authorization message and parses the Merchant Services response message. This solution provides the
most control over the transaction process.
• PCI is in scope for the ECR as the ECR handles the card track data (PCI scope may be reduced
or eliminated if P2PE and tokenization are implemented. Refer to Safetech Encryption.)
• EMV integration testing is required for the complete solution
Page 12
For Fully Integrated implementations the ECR is within PCI scope (if not using Safetech Encryption and
Safetech Tokenization) as the ECR can see non-encrypted card data. EMV integration testing of the
complete solution is required.
Partially Integrated ECR Solution

In Partially Integrated mode the ECR application controls the transaction, communicates with the host,
and stores the authorization data. The ECR interfaces with an external PIN Pad for card entry (swipe /
insert / tap) and EMV kernel functionality. The PIN Pad also builds the Merchant Services host
authorization message and parses the Merchant Services response message. However, the ECR
provides the actual host connectivity and is responsible for transmitting and receiving host messages and
storing the authorization data. This solution reduces the amount of development required on the ECR as
it does not build the host messages.
Page 13
• PCI is in scope for the ECR as the ECR handles the card track data (PCI scope may be reduced
or eliminated if P2PE and tokenization are implemented. Refer to Safetech Encryption.)
• EMV integration testing is required for the complete system
Partially Integrated mode is generally used when the ECR wants to control the host interface and see
card data without having to implement the host request and response message logic. This
implementation is ideal for companies with ECR applications that connect to multiple Merchant Services
hosts as the ECR application can remain consistent and only the PIN Pad logic would need to differ.
Chase
Paymentech Host
Partially Integrated ECR External PINPad

Host Build Request Msg
Host Msg Interface
Messaging Parse Response Msg
MSD Interface Magstripe Magnetic Stripe Reader
PIN Entry Device

ECR EMV POS EMV Interface EMV Kernel
ICC Reader
Application Application
Amex ExpressPay
Contactless Discover D-PAS

Contactless Interface
Kernel MasterCard PayPass
Visa payWave
For Partially Integrated implementations the ECR is within PCI scope (if not using Safetech Encryption
and Safetech Tokenization) as the ECR can see non-encrypted card data. EMV integration testing of the
complete solution is required.
Page 14
Semi-Integrated ECR Solution

In Semi-Integrated mode the ECR interfaces with a PIN Pad (or terminal) for EMV functionality. The PIN
Pad also provides the Merchant Services host interface and stores the authorization data. This solution
eliminates much of the ECR development as the ECR does not build the host authorization message. The
ECR initiates the transaction and utilizes the external PIN Pad to provide the Merchant Services host
interface, to store the authorization data, for card entry (swipe / insert / tap) and to provide EMV kernel
functionality.
• PCI is not in scope for the ECR as the ECR does not see the card data
• EMV integration testing of the complete solution is not required as the PIN Pad contains the full
payment application
In Semi-Integrated mode the PIN Pad interface generally consists of high level commands that are simple
to implement on an ECR. This is ideal for companies with multiple ECR vendors (or types) as most of the
host and EMV functionality is contained within the PIN Pad, meaning that host and EMV development
would not need to be replicated on each type of ECR supported.
Page 15
Note: For Semi-Integrated implementations the ECR is not within PCI scope as the transaction is
controlled by the external PIN Pad and the ECR does not see cardholder data. EMV integration testing of
the complete solution is not required as the PIN Pad contains the complete payment application. The PIN
Pad requires full EMV integration testing.
Standalone POS Solution with Internal PIN Pad

In this mode a single standalone POS terminal is used that includes an internal PIN Pad. The POS
terminal contains the POS application and utilizes the EMV kernel residing in the internal PIN Pad to
provide EMV functionality.
This is often the simplest and most cost effective EMV POS Solution.
Page 16
Note: Standalone internal PIN Pad implementations are within PCI scope (if not using Safetech
Encryption and Safetech Tokenization). EMV integration testing of the complete solution is required.
Standalone POS Solution with External PIN Pad

In this mode a standalone POS terminal controls the transaction, provides the Merchant Services host
interface, and stores the authorization batch data. The POS terminal interfaces with an external PIN Pad
for card entry (swipe / insert / tap) and EMV kernel functionality.
This is a cost effective EMV POS Solution for environments where the merchant and cardholder cannot
easily share the same device, or if you have an existing terminal base that is not EMV compliant and you
Page 17
wish to add EMV functionality by simply adding an EMV certified PIN Pad.
Note: Standalone external PIN Pad implementations are within PCI scope and EMV integration testing of
the complete solution is required.
Safetech Encryption
Safetech Encryption is a point-to-point encryption (P2PE) technology that protects the primary account
number (PAN) on a payment card from the moment of capture at the point of sale (POS) until it reaches
the Merchant Services host, without requiring the cardholder to process, transmit or store unprotected
card account data.
Using Safetech Encryption may reduce or eliminate PCI requirements as your EMV POS Solution does
not see unencrypted card data. Please contact your Account Representative for more information.
Page 18
Safetech Tokenization
Safetech Tokenization provides cardholder data security by returning a token in the transaction response
message. By returning tokens to merchants, no cardholder data needs to be passed in subsequent
transactions as the token serves as a proxy for the original account number. Merchants can also use
tokens in lieu of clear card numbers in their internal systems as well.
Using Safetech Tokenization may reduce or eliminate PCI requirements as your EMV POS Solution does
not see unencrypted card data. Please contact your Account Representative for more information.
EMV and Contactless Solution Components

All EMV POS Solutions must have the following components:
• An EMV capable PIN Pad that is:
o EMV Level 1 and Level 2 type approved
o PCI PTS approved
o Mastercard© TQM (Terminal Quality Management) labeled
o Merchant Services approved (i.e. can be injected by Merchant Services or an authorized

provider, and the PIN Pad application has been approved for use by Merchant Services)
• A receipt printer (if an attended device)
• The ability to download EMV parameters. The methods used to manage and download EMV
parameters are the responsibility of the developer. For a list of required EMV parameters, refer to
the EMV Testing Parameters section
• The ability to download Certificate of Authority (CA) Public Key (CAPK) information. The CA
Public Key file cannot be hardcoded as it will change. For more information on downloading
CAPK information, see Certificate of Authority Public Keys (CAPK) section.
Page 19
Merchant Services Supported

Configurations
The US payment industry is migrating to EMV. Merchant Services, along with industry payment partners
are committed to this migration. All existing non-EMV applications, at some point, should be upgraded to
support EMV.
The migration to EMV is expected to take a considerable amount of time. Cards with a magnetic stripe will
continue to be issued and used for the foreseeable future. Therefore, all EMV POS Solutions must
continue to support magstripe transactions.
Merchant Services EMV Best Practices (CMS EMV BP) 00101Contactless should be supported
• Merchant Services recommends that all EMV POS Solutions support contactless transactions.
Merchant Services EMV Requirement (CMS EMV RQ) 00101 All EMV POS Solutions must support
MSR transactions
• Merchant Services requires that the EMV POS Solution includes support for magstripe only cards
and fallback magstripe transactions.
CMS EMV RQ 00102 Debit on chip enabled EMV POS Solutions must support EMV and MSR debit
• It is optional for clients/merchants to accept debit. Merchant Services requires that if debit will be
accepted on chip enabled EMV POS Solutions, those devices must be capable of supporting
EMV PIN debit and magstripe PIN debit.
The EMV architecture supports several configuration modes for EMV POS Solutions. Currently, Merchant
Services is an Online-Only acquirer which means that all transactions must go online for authorization.
The following table defines the EMV configuration modes and for each mode identifies whether it is
supported by the Merchant Services host.
EMV Configuration Modes
Mode Usage Host
Online Only Transactions are always sent to the host for authorization. Yes
Floor Limit processing is not used.
Page 20
Mode Usage Host
Online with Transactions can be locally authorized, based on Risk Yes

Offline Management processing or sent to the host for authorization.
Capabilities
The EMV Floor Limit must be set to zero; therefore, the EMV POS
Solution will behave like an Online-Only solution.
Offline Only Transactions are always locally approved. Yes
Used for attended and unattended, cardholder activated devices.
Note: Merchant Services is an Online-Only acquirer. However, during integration testing, EMV POS
Solutions may be required to perform and pass non-zero EMV Floor Limit (Offline) test cases. This is to
ensure the EMV POS Solution supports a non-zero EMV floor limit in the future.
The following table shows the EMV Terminal Types and identifies whether they are supported by the
Merchant Services host.
EMV Configuration Modes By Terminal Type
Environment Operation Modes Terminal Type Host
Attended Financial Online Only 11 Yes

Institutions
Attended Financial Offline with Online 12 Yes

Institutions Capabilities
Attended Financial Offline Only 13 No

Institutions
Attended Merchant Online Only 21 Yes
Attended Merchant Offline with Online 22 Yes

Capabilities
Attended Merchant Offline Only 23 No*
Unattended Financial Online Only 14 Yes

Institutions
Page 21
Environment Operation Modes Terminal Type Host
Unattended Financial Offline with Online 15 Yes

Institutions Capabilities
Unattended Financial Offline Only 16 No

Institutions
Unattended Merchant Online Only 24 Yes
Unattended Merchant Offline with Online 25 Yes

Capabilities
Unattended Merchant Offline Only 26 No*
*Speak to your Implementation Manager if Offline-Only processing is required.
Note: The EMV Terminal Type (Tag 9F35), Terminal Capabilities (Tag 9F33) and Additional Terminal
Capabilities (Tag 9F40) tags are used to set and identify the current EMV kernel configuration.
US Debit
To meet the requirements of the Durbin amendment to the Dodd–Frank Wall Street Reform and
Consumer Protection Act (“Durbin regulations”), which enables merchants and acquirers to choose to
route transactions from debit and prepaid card programs via unaffiliated networks, Visa© and Mastercard
have introduced the following AIDs (commonly referred to as the “US Common Debit AIDs”).
US Common Debit AIDs
Brand Scheme Common Debit AID
Mastercard US Maestro A0000000042203
Visa Visa Common A0000000980840

Debit
Discover® Debit A0000001524010
DNA DNA Shared A0000006200620
Page 22
Brand Scheme Common Debit AID
UnionPay via Debit A000000333010108

Discover
In addition to Mastercard and Visa, the Debit Network Alliance (DNA) and other individual debit networks
will offer their own US Debit AIDs that will only reside on non-Visa and non-Mastercard branded cards.
Visa, Mastercard, and Discover branded chip cards issued in the US under debit and prepaid card
programs, will support both a US Common Debit AID and a Global AID (either the standard Visa AID, the
standard Discover AID, the standard Mastercard AID or the Maestro® AID).
• If a Global AID (Visa, Mastercard, Global Maestro, or Discover) is used to initiate the chip
transaction, the transaction will be routed via the appropriate Visa, Mastercard, or Discover credit
network. The network used is based on the card IIN.
• If a US Common Debit AID is used to initiate a chip transaction, the resulting transaction may
also be routed via unaffiliated networks that have executed the necessary access agreement with
Visa, Mastercard, or Discover.
For both contact and contactless transactions, EMV POS Solutions should use the standard Application
Selection process described for EMV transactions. The merchant may filter the resulting Candidate List to
remove multiple AIDs which access the same underlying funding account. EMV POS Solutions must not
assume that if a US Common Debit AID is present, that this AID can be automatically selected to the
exclusion of all other AIDs on the card, as those AIDs may relate to alternative products which the
cardholder may wish to use (such as a credit product which is issued together with a debit product).
All AIDs which relate to debit or prepaid programs will be identified in the data read during Application
Selection. The presence of the following two data elements identifies the AID as relating to a US Debit or
prepaid program:
• Issuer Country Code (Tag 5F55). Two alpha digits with a value of 0x5553 (“US”)
• Issuer Identification Number (Tag 42). Contains the Bank Identification Number (BIN)
There are four possible situations that must be handled:
1. The card has two or more AIDs where these data elements are present and the values of the
Issuer Identification Number (IIN) are the same (Scenario One in the table below):
Page 23
o The EMV POS Solution may assume that the AIDs with the same IIN access the same
underlying funding account and can eliminate all but one of those AIDs from the
Candidate List.
o When these are the only AIDs present in the card, the EMV POS Solution may
automatically select the remaining AID in the Candidate List.
2. The card has two or more AIDs where these data elements are present and the values of the
Issuer Identification Number (IIN) are the same. There are also one or more other AID(s) present
on the card that have a different IIN or the IIN is not present (Scenario Two in the table below):
o The EMV POS Solution may assume that the AIDs with the same IIN access the same
underlying funding account and can eliminate all but one of those AIDs from the
Candidate List.
o For contact transactions the EMV POS Solution should present the remaining Candidate
List choices to the cardholder in accordance with Final Selection processing.
o For contactless transactions, the EMV POS Solution should automatically select the AID
in the Candidate List with the highest Application Priority Indicator (Tag 87).
3. When a card has two or more groups of AIDs where these data elements are present and each
group has two or more AIDs with the same IIN (Scenario Three in the table below):
For each group of AIDs with the same IIN, the EMV POS Solution may assume the AIDs access the
same underlying funding account and can eliminate all but one of those AIDs from the Candidate List -
leaving only one AID for each IIN.
o For contact transactions, the EMV POS Solution should present the remaining Candidate
4. When a card has multiple AIDs where these data elements are present and all AIDs have the
same IIN, and there are multiple US Common Debit AIDs present (Scenario Four in the table
below):
o The EMV POS Solution should assume that each US Common AID relates to a different
underlying funding account.
Page 24
o The EMV POS Solution should eliminate either of the following from the Candidate List:
▪ All of the US Common Debit AIDs
▪ All of the Global Debit AIDs
o For contact transactions, the EMV POS Solution should present the remaining Candidate
US Common Debit Scenarios One, Card accesses single debit funding account
Scenario AID Country IIN Tag Candidate List Choice for the Merchant
Code 42
Tag 5F55
Global A00000000X1010 US XX0000 Merchant may decide which AID to select

Debit AID based on their preferred routing choice:
• Global AID: may only be routed to the

associated card brand’s credit network
(any supported CVM may be used)
• US Common Debit AID: may be routed to

any of the supported debit networks (any
supported CVM may be used)
US A00000000XXXXX US XX0000 Merchant may decide which AID to select

Common based on their preferred routing choice:
Debit AID
US Common Debit AID: may be routed to any

of the supported debit networks (any
Page 25
US Common Debit Scenarios Two, Combo card accessing a credit account and a single funding
debit account
Code 42
Tag
5F55
Global A00000000X1010AA01 N/A N/A Global Credit AID will remain in the
Credit Candidate List for cardholder selection as
AID described in EMV.
Global A00000000X1010AA02 US XX0000 Merchant should decide on either the

Debit Global AID or the US Common Debit AID
AID based on their preferred routing choice:

• US Common Debit AID: may be routed

to any of the supported debit networks
US A00000000XXXXX US XX0000 Merchant should decide on either the

Common Global AID or the US Common Debit AID
Debit based on their preferred routing choice:
AID
US Common Debit AID: may be routed to

any of the supported debit networks (any
Page 26
US Common Debit Scenarios Three, Card accesses two debit funding accounts, Accounts have
different IINs
Code 42
Tag
5F55
Global A00000000X1010AA01 US XX0000 Merchant should choose either the Global

Debit AID 1 or the US Common Debit AID 1
AID 1 based on their preferred routing choice:
• Global AID 1: may only be routed to

the associated card brand’s credit
network (any supported CVM may be
used)
• US Common Debit AID 1: may be

routed to any of the supported debit
networks (any supported CVM may be
used)
US A00000000XXXXXAA01 US XX0000 Merchant should choose either the Global

Common AID 1 or the US Common Debit AID 1
AID 1
used)
US Common Debit AID 1: may be routed

Page 27
Code 42
Tag
5F55
Global A00000000X1010AA02 US XY9999 Merchant should choose either the Global

Debit AID 2 or the US Common Debit AID 2

used)
• US Common Debit AID 2: may be

used)
US A00000000XXXXXAA02 US XY9999 Merchant should choose either the Global

Common AID 2 or the US Common Debit AID 2
AID 2
used)
US Common Debit AID 2: may be routed

Page 28
US Common Debit Scenarios Four, Card accesses two debit funding accounts, Accounts have
same IINs
Code 42
Tag
5F55
Global A00000000X1010AA01 US XX0000 Merchant should choose either Global AID

Debit 1 and Global AID 2 or US Common Debit
AID 1 AID 1 and US Common Debit AID 2
based on their preferred routing choice:
• Global AID 1 and 2: may only be

routed to the associated card brand’s
credit network (any supported CVM
may be used)
• US Common Debit AID 1 and 2: may

be routed to any of the supported debit
used)
US A00000000XXXXXAA01 US XX0000 Merchant should choose either Global AID

Common 1 and Global AID 2 or US Common Debit
Debit AID 1 and US Common Debit AID 2

may be used)
US Common Debit AID 1 and 2: may be

used)
Page 29
Code 42
Tag
5F55
Global A00000000X1010AA02 US XX0000 Merchant should choose either Global AID

Debit 1 and Global AID 2 or US Common Debit
AID 2 AID 1 and US Common Debit AID 2
based on their preferred routing choice:

may be used)

used)
US A00000000XXXXXAA02 US XX0000 Merchant should choose either Global AID

Common 1 and Global AID 2 or US Common Debit
Debit AID 1 and US Common Debit AID 2

may be used)

used)
For each of the scenarios described above, the method used by the EMV POS Solution to identify the
AID(s) to eliminate from the Candidate List is described in more detail in the Credit / Debit section and US
Debit Processing section.
CMS EMV BP 00102 US Debit selection method should be configurable
Page 30
• Merchant Services recommends that the US Debit identification method be configurable to

support changes in merchant and acquirer preferences. Both methods must be supported during
integration testing.
CMS EMV BP 00103 Select US Common Debit AIDs when present on card
• Merchant Services recommends that when both US Common Debit and Global AIDs are present
for the same funding account, that the Global AIDs be removed from the Candidate List. Using
the US Common Debit AID provides the maximum flexibility in debit routing options.
CMS EMV BP 00104 Allow Cardholder to select AID when more than one funding source
• If more than one funding source is present, the cardholder must be able to choose which account
to pay from.
Page 31
EMV Implementation Tandem Supplemental Guide Development Process
Development Process
Development and Testing
Please be aware that implementing an EMV POS Solution is a much more difficult and time consuming
process than implementing a traditional magstripe solution. EMV solutions are more complex and are
subject to an extended and more rigorous integration testing process which, in addition to the standard
Merchant Services integration testing, includes certification by the card brands and possibly a pilot.
Note: It Is important that your development timelines reflect the development complexity and the
additional time required to complete all integration testing.
The table below outlines the development and integration testing components that will be used when
developing an EMV POS Solution with Merchant Services. The information that follows encompasses the
Sales, Account Executive and Relationship Management team, which will be generically referred to as the
“Account Representative” and the Technical Implementation team which will be generically referred to as
the “Implementation Manager”.
Development and Integration Testing Components
Integration Testing Description

Component
Client Consulting Merchant Services performs a “Discovery” process to define and understand
Discovery the client’s project business requirements. The team will interface with the
client management and business decision makers to determine:
• Project timing
• High level project requirements
• Connectivity requirements
• Security implementations
• Funding windows
In some cases, this step may involve more technical discussions on some
issues.
Page 32

Component
Contract The Account Representative will initiate the client setup process:
• Review contracts (new and existing)
• A contract will be put into place for the client development project.
• If the client already has a Merchant Services contract, it may be modified

or amended to include the new development.
• Engage Risk and Credit
• Add products and features
Assign a Case Number (this number must be referenced on all

correspondence).
Client Setup The Account Representative will engage the boarding team to configure the
client’s business parameters:
• Merchant information
• Products and services
• Methods of Payment (MOPs)
• EMV Parameters
Implementation The Implementation Manager works with the client to finalize:

Managers
• Connectivity requirements
• Products and Services
• Payment processing options:
• EMV field guidance
• Technical Specifications
• Special processing requirements
Page 33

Component
Technical Profile The Technical Profile Questionnaire (TPQ) is completed by the client, with
Questionnaire the assistance of their Implementation Manager. The TPQ is used to ensure
that the client is implementing a valid, supportable EMV configuration that
meets Merchant Services requirements.
The TPQ defines EMV information related to the:
• Terminal Type
• Terminal Capabilities
• Additional Terminal Capabilities
• PIN Pad Certification Letters
For more information see the Technical Profile Questionnaire section.
Technical The Technical Implementations team will:

Implementations
• Provide detailed test scripts
• Configure host connectivity
• Configure test credentials
• Generate Proof of Readiness (POR) test cases and email them to the
client
EMV Training EMV projects are considerably more complex than traditional magstripe
applications. For this reason, Merchant Services highly recommends that
first time EMV developers receive EMV training before beginning an EMV
development project.
For more information see EMV training section.
Page 34

Component
EMV Integration The Collis Merchant Test Suite (MTS) contains all required card brand
Testing Test Tools certification test cases, as well as Merchant Services specific EMV test
cases that must be completed during EMV integration testing.
For more information about the Collis Merchant Test Suite, see EMV
Contact and Contactless Test Tools section.
Merchant Services has also partnered with ICC Solutions to offer the ICC
Test Suite Bundles for Certification tools as an option to the Collis MTS for
thorough and complete EMV integration testing.
For more information about ICC Solutions’ Test Suite Bundles for
Certification Collis Merchant Test Suite, see ICC Solutions Test Suite
Bundles for Certification section.
Development and The client develops their EMV POS Solution based on the project
Testing information provided to Merchant Services and performs standalone testing.
During this process the client can submit their questions into the support
email box.
If during development the project goes dormant and Merchant Services has
no communication with the client, the project may be closed. If that occurs,
the project will have to be reopened by the client when ready to proceed.
• After 2 weeks with no client communication, the Merchant Services

Implementation Manager will send an email warning that the project may
be closed
• After 4 weeks with no client communication, the project will be closed

until the client is ready to resume
• If the project is closed, the client will need to contact their Account
Representative to have the project reopened
Page 35

Component
Proof of Readiness Proof of Readiness (POR) testing must be performed by the client and
(POR) Testing reviewed by Merchant Services before any formal integration testing can
begin.
The purpose of POR testing is to ensure that the client has host connectivity
and is ready to begin self-testing and integration testing.
POR testing is a simple process that involves running a few magstripe

transactions, one EMV transaction for each card brand supported and a
single contactless transaction.
At the completion of POR testing Merchant Services will review the results.
If there are any issues, they will have to be corrected by the client and POR
testing will have to be redone.
For more information on POR testing see Certification Process section.
Test Case Document Merchant Services creates a test case document that must be completed by
the client to Class “B” test the EMV POS Solution. This document will
include:
• Class “B” magstripe test cases
• Merchant Services specific EMV test cases
Class “B” Integration The client will execute the magstripe and EMV test cases defined in the Test
Testing Case document:
• Magstripe test cases
When all test cases have been completed, Merchant Services will review the
test case results and create an issues document. If there are any issues, the
errors will have to be corrected and the failed test cases must be rerun.
Note: This process generally requires multiple passes over a 2-3 month
period.
Page 36

Component
Class “B” Integration Once all Class “B” magstripe and EMV test cases have been passed,
Testing Summary Merchant Services will issue a Class “B” integration testing summary.
At this point, the client may begin to deploy the solution as a magstripe
solution only. The deployed solution may include End-to-End Encryption and
Tokenization.
Note: The deployed solution cannot include any EMV functionality.
EMV Card Brand EMV Card Brand Certification must be performed once for each combination
Certification card brand / kernel configuration supported.
During EMV Card Brand Certification:
• The client is responsible for running the card brand EMV test cases
• Merchant Services is responsible for supplying the test case

requirements (e.g. M-TIP) and submitting the test case results for card
brand approval
To reduce the time required to complete this process, Merchant Services

staggers the start of each EMV Card Brand Certification and provides
parallel processing of all brand certifications. While the client is running the
next certification’s test cases, Merchant Services will be submitting
previously completed card brand test case results for card brand approval.
If any test cases fail, your Implementation Manager will determine, based on
the type and complexity of the error, whether only the current brand test
cases must be rerun or if all test cases for all card brands must be rerun.
Note: The time required to complete EMV Card Brand Certification varies
depending on the number of card brands supported and the complexity of
the EMV POS Solution. It is a lengthy process, so be sure the EMV POS
Solution is ready before beginning this process. Failed certification
submissions greatly increase the time required to complete.
EMV Certification Letter Once all EMV card brands have been certified, EMV Card Brand
Certification is complete and Merchant Services will issue an EMV
integration testing summary.
The EMV POS Solution may now be deployed as an EMV capable solution.
Page 37

Component
Pilot Merchant Services does not require a pilot before beginning a rollout of an
EMV POS Solution; however:
• Merchant Services does recommend that the rollout begin slowly with a
few test locations so results can be analyzed by the client before
beginning a full rollout
• In some cases, Mastercard will require that an End-To-End-

Demonstration (ETED) be performed at a pilot location before a full
rollout may begin
For more information on pilot and ETED requirements see Pilot section.
Rollout A full rollout of the EMV POS Solution may begin.
Note: Completed EMV integration testing is not permanent. For information

on EMV POS Solution re-test requirements, see Pilot section.
Technical Profile Questionnaire

To ensure that the client is implementing a valid, supportable EMV configuration that meets Merchant
Services requirements, the client in conjunction with their Implementation Manager, will complete a
Technical Profile Questionnaire (TPQ). The information on this form is obtained from the device and PIN
Pad information provided by the client.
The TPQ allows Merchant Services an opportunity to review the proposed implementation, validate that
the configuration is currently supported and document the configuration, including all associated
certification documents, for future reference.
To complete the TPQ, the client must supply information relating to the PIN Pad and PIN Pad kernel
being implemented. This includes but is not limited to:
• PIN Pad Terminal Brand/Model
• PIN Pad Software API (Example VeriFone XPI 5.32)
• EMV Co Level I and II Approvals
• TQM Label or Action Plan
Page 38
• PCI. PED Approval
• Kernel Terminal Capabilities
• Kernel Additional Terminal Capabilities
CMS EMV RQ 00201 Notify Merchant Services of all PIN Pad kernel configurations being used
• Merchant Services requires the client to notify their Account Representative of all PIN Pad kernel
configurations being used by the EMV POS Solution as all kernel configurations must be
documented in the TPQ.
The client will be required to provide the following PIN Pad certification letters for the PIN Pad model and
kernel configuration being used. These letters can generally be obtained from the PIN Pad vendor.
PIN Pad and PIN Pad kernel certifications do expire. It is the developer’s responsibility to ensure that the
PIN Pad and PIN Pad kernel are current and that none of the certification letters have expired. The
following table identifies the required PIN Pad certification letters and their duration.
PIN Pad Certification Letters
Letters Expires After
EMVCo™ EMV Level 1 Letter of Approval 4 Years
EMVCo EMV Level 2 Letter of Approval 3 Years
EMVCo Contactless Level 1 Letter of Approval 4 Years
Brand Contactless Level 2 Letters of Approval Typically, 2 years after date of approval
(one per supported brand)
Mastercard TQM Letter or TQM Label N/A
PCI PTS Certification Letter PCI PTS certification expiry is dependent on the PTS
version the device was certified under.
Note: PTS 1.0 devices are no longer supported
CMS EMV RQ 00202 Provide PIN Pad Certification Letters of Approval (LOA)
Page 39
• Merchant Services requires the client to provide all certification Letters of Approval (LOA) for the
EMV PIN Pad being implemented. Failure to do this will cause the project to be delayed until the
required certification letters have been provided.
CMS EMV RQ 00203 EMV certification letters must be current
• Merchant Services requires that all EMV certification letters be current and not about to expire.
An EMV POS Solution will not be tested if any of the certification letters is scheduled to expire
within 90 days of the date of integration testing.
Training
It is important that everyone involved in the development and testing of an EMV project receive EMV
training before beginning. Although this is not considered mandatory by Merchant Services, it is highly
recommended as EMV and contactless solutions are considerably more complex than traditional
magstripe solutions. Beginning EMV projects without proper training will lead to extended project
timelines and integration testing issues that could require extensive time and redevelopment to resolve.
Merchant Services cannot provide low level EMV, contactless or PIN Pad kernel integration support. It is
the developer’s responsibility to obtain this information from other third party sources.
There are several external sources where EMV training may be obtained:
• b2ps.com/education
• ul-ts.com/catalog/elearning
• emv-connection.com
• smartcardalliance.org
• acquirer.com
• clear2pay.com
• fime.com
• galitt.us
• iccsolutions.co.uk/emv-in-the-usa/4591022695
Please check with your Implementation Manager for other possible EMV and contactless training options.
Page 40
CMS EMV BP 00201 Obtain EMV Training before beginning an EMV project
• Merchant Services highly recommends that everyone involved in EMV development and testing
receive EMV training prior to beginning an EMV project.
Technical Support
The intent of this document is to provide developers who are familiar with EMV, the necessary information
to be self-supporting while developing their EMV POS Solution. Your Implementation Manager can
provide some additional EMV implementation information and recommendations. However, Merchant
Services cannot provide low level EMV, contactless or PIN Pad kernel integration support. It is the
developer’s responsibility to obtain this information from other sources:
• EMV requirements and guidelines can be obtained from the EMVCo website emvco.com
• For PIN Pad kernel technical support, refer to the PIN Pad vendor’s documentation or contact the
PIN Pad vendor to inquire about the availability of PIN Pad integration training and support
Merchant Services does not recommend or endorse any specific external support service.
Development Host Connection Information

During development and testing it will be necessary to send online EMV transactions to the Merchant
Services host (or host simulator). Your Implementation Manager will provide the required development
configuration information (Terminal IDs, Merchant IDs, IP address (URL), port, etc.).
Integration Testing Process

Merchant Services requires full integration testing of all EMV, contactless and traditional magstripe
transactions before an EMV POS Solution can go live as an EMV solution. The integration testing
duration is dependent on the complexity of the EMV POS Solution and the quality of the implementation.
It is important to note that if the EMV POS Solution fails integration testing at any point, the entire process
may have to be repeated.
EMV integration testing is an extensive multi-step process which involves completing Merchant Services
Class “B” integration testing, which includes both magstripe and EMV testing, and then completing EMV
card brand certification for each card brand and kernel configuration supported.
Page 41
• Class “B” integration testing validates message format adherence to the Merchant Services host.
• EMV card brand certification validates EMV functionality adherence to the card brands.
EMV integration testing is extremely rigorous and far more time consuming than traditional magstripe
integration testing. This additional complexity should be accounted for in your project implementation
timelines.
The integration testing process cannot begin until development and self-testing has been completed. The
integration testing process is performed per the steps below. All steps must be completed before
integration testing is considered complete.
Note: Merchant Services does not charge for integration testing. However, any certification fee dictated
by the card brands will be passed directly on to the client.
Integration Testing Process

Process Description
Proof of Readiness Before integration testing can begin, Proof of Readiness (POR) testing must
Testing be performed by the client and reviewed by Merchant Services, to ensure
the EMV POS Solution is ready.
• POR testing requires the client to perform:
• Several magstripe transactions for specific dollar amounts
• One EMV contact transaction for each of the card brands supported (e.g.
Visa, Mastercard, Amex, etc.)
• A single contactless transaction (if supported)
At the completion of POR testing Merchant Services will review the results. If
there are any issues, the issues will have to be corrected and POR testing
must be rerun.
Note: All POR transactions should be approved by the host.
Page 42
Process Description
Class “B” Magstripe The client will execute the Class “B” magstripe test cases as defined in the
Integration Testing Merchant Services Test Case document.
• Tests are run using the Certify platform
• If assistance is required email your Implementation Manager
• Test results should be populated into the test case document
When testing is complete, Merchant Services will review the integration

testing results and create an issues document. If there are any issues, the
errors will need to be corrected and the failed test cases must be rerun.
Note: This process generally requires multiple passes over a 2-3 month
period.
Page 43
Process Description
Card Brand Card Brand Certification must be performed once for each card brand /
Certification kernel configuration combination supported.
Once pre-certification has been successfully completed, final card brand

certification can be run while connected to the host and the card brand
simulators.
The card brand certification process is performed as follows:
• Merchant Services will provide test case documents (e.g. M-TIP)

identifying the test cases that must be performed for a specific card brand
• The client will execute the required test cases for the specific card brand
and submit the results to Merchant Services including:
• card logs
• completed questionnaires
• receipts
• Merchant Services will review the results to ensure they are complete and
submit them to the appropriate card brand for approval
To decrease the time required to complete this process, the EMV Card
Brand Certification steps will be performed one card brand at a time with the
client and Merchant Services working in parallel.
• The client submits card brand results immediately after completion of

each card brand, before beginning testing of the next card brand
• While the client tests the next card brand, Merchant Services will review
and submit the completed card brand test case results for card brand
approval
If any test cases fail, Merchant Services will determine, based on the type
and complexity of the error, whether only the current brand test cases must
be rerun or if all test cases for all card brands must be rerun.
For more information see the Card Brand Certification section.
If you require additional information, contact your Implementation Manager.
CMS EMV BP 00202 Budget adequate time for certification
Page 44
• EMV POS Solutions require considerably more time to certify than traditional magstripe solutions.
Please ensure that you budget at least 6-8 weeks to complete Pre-Certification and 3-5 weeks to
complete Final (Card Brand) Certification. This length of time varies based on the complexity of
the implementation and the number of card brands and kernel configurations being certified.
CMS EMV RQ 00204 EMV Test Tool is required for Card Brand Certification
• Merchant Services requires that an approved EMV Test Tool be used to perform Card Brand
Certification. For information about the recommended EMV Test Tools, see EMV Contact and
Contactless Test Tools section.
Card Brand Certification

Card Brand Certification is the final step in the EMV certification process and is performed while
connected to EMV Card Brand Simulators. A separate Card Brand Certification must be performed for
every card brand and PIN Pad kernel combination being used by the EMV POS Solution.
The following Card Brand Certification Test Suites must be used when performing card brand
certification.
Card Brand Certification Test Suites
Card Brand EMV Test Suite Contactless Test Suite
American Express and JCB via AEIPS ExpressPay®

American Express
Debit Network Alliance Contact your n/a

integration testing
analyst
Discover, Discover Diners, JCB D-PAS E2E D-PAS Contactless E2E

via Discover
UnionPay via Discover D-PAS E2E D-PAS Contactless E2E
Interac® Terminal Reader Terminal Interoperability and

Certification Confidence Test
Mastercard M-TIP M-TIP
Page 45
Card Brand EMV Test Suite Contactless Test Suite
Visa ADVT CDET
qVSDC (only required for contactless-only

implementations)
Note: Per the Visa Inc. US EMV Chip Terminal Testing Requirements, qVSDC DM test results are no
longer required in Visa CCRT when a dual-interface integrated terminal is selected. The qVSDC DM
testing is still required for a standalone contactless-only device.
CMS EMV RQ 00205 qVSDC certification is required for contactless-only Visa EMV POS
Solutions
• Visa requires that a qVSDC certification be completed when implementing a Visa contactless-
only EMV POS Solution. This is in addition to the Visa CDET certification that must be completed
for all contactless implementations.
As each Card Brand Certification is completed, the results, including all card logs and receipts must be
forwarded to Merchant Services. Merchant Services will review the results and forward them to the card
brands for formal analysis and approval. If multiple PIN Pad kernel configurations are being certified, the
certification timeframe will increase accordingly.
If any EMV Card Brand Certification test case fails, EMV Card Brand Certification must be redone for the
failing card brand. Depending on the severity and type of failure, it is possible that another entire EMV
Card Brand Certification will be required for all card brands supported. Merchant Services will determine
what must be done based on the severity of the failure and the complexity of the changes required to
correct.
CMS EMV BP 00207 Be ready before attempting Card Brand Certification
• Card Brand Certification is a time consuming and costly process. If your EMV POS Solution fails
Card Brand Certification, it will have to be redone which means additional time and cost. So do
not perform Card Brand Certification until you are confident that your EMV POS Solution will pass
all test cases.
CMS EMV RQ 00206 Multiple certifications required if multiple kernel configurations supported
• The card brands require that a card brand certification be performed for every kernel
configuration supported. Therefore, multiple certifications may be required for each card brand.
One for each kernel configuration supported.
Page 46
Pilot
Merchant Services does not require a pilot before beginning a full rollout of an EMV POS Solution.
However, due to the complexity of EMV applications it is recommended that a short pilot be run at a few
locations before beginning a rollout. This will help ensure that the EMV POS Solution is properly
configured for production and that EMV transactions are being processed and settled properly.
In some situations, Mastercard will require that the EMV POS Solution undergo End-to-End
Demonstration (ETED) testing. When required:
• ETED testing is performed by a Mastercard representative at a pilot site
• Mastercard will perform a few live online transactions while connected to the production Merchant
Services host
• Mastercard will analyze the messages and transaction results
When ETED testing is required, it must be completed to Mastercard’s satisfaction before a full rollout may
begin.
CMS EMV BP 00203 Production validation prior to rollout is strongly encouraged
• Although not required Merchant Services recommends that a single device or store be tested in
production before a rollout, or even a pilot, begins.
Post Rollout Re-Test

EMV integration tests are not permanent. There are several reasons that a deployed EMV POS Solution
may need to be updated and re-tested after it has been rolled out:
1. Changes to an EMV parameter, other than a parameter that is downloaded from the Merchant
Services host
2. Expiring certifications (PIN Pad hardware or kernel); check with your Account Representative to
determine if re-testing is required
3. Inter-operability issues
4. Payment application changes
Page 47
When a situation occurs that affects your EMV POS Solution, it will be necessary to make the required
changes and to re-test your solution. How quickly this must be completed depends on the reason re-
testing is required:
• A date may be set by which time the EMV POS Solution must be re-tested using updated EMVCo
or card brand approved hardware or software
• It may be possible to continue using the EMV POS Solution as is, until the next scheduled client
modifications are made, and a re-test is required
It is the client’s responsibility to know when EMV certifications are expiring (see PIN Pad Certification
Letters table in Technical Profile Questionnaire section).
CMS EMV BP 00204 Respond quickly when notified of re-test requirements
• Merchant Services recommends that the client act quickly when an EMV POS Solution must be
re-tested to meet new regulatory requirements. When regulatory changes are mandated, many
deployed solutions will require re-testing and the integration testing queue will fill quickly.
CMS EMV RQ 00207 Keep track of the EMV POS Solution certification status
• Merchant Services requires the client to ensure that their deployed EMV POS Solutions are using
supported EMVCo or card brand certified hardware and software. The US Payments Forum
(formerly EMV Migration Forum) has relevant information that can assist in this effort.
CMS EMV RQ 00208 Merchant Services must be notified of changes to EMV functionality
• Merchant Services requires the client to notify their Account Representative before a change is
made to a deployed EMV POS Solution that will alter the EMV payment functionality.
EMV Contact and Contactless Test Tools

Merchant Services mandates that an EMV Test Tool be used to perform EMV Card Brand Certification.
These tools simplify the certification process and provide all reports and card logs required by the card
brands when submitting certification test case results.
To complete Merchant Services certification the EMV Test Tool used must support:
• The EMV Card Brand Certification test cases for all card brands supported by the EMV POS
Solution
Page 48
Merchant Services currently supports the following EMV test tools for EMV and contactless certification.
Merchant Services Approved EMV Test Tools
Company Test Tool Description
UL (Underwriters Collis For details see Collis Merchant Test Suite below.
Laboratories) (formerly Merchant Test
known as Collis) Suite (MTS)
ICC Solutions Test Suite For details see ICC Solutions Test Suite Bundles for
Bundles for Certification (ICC TS) below.
Certification
(TS)
CMS EMV BP 00205 The Collis MTS or ICC Solutions TS are recommended
• Merchant Services recommends that the Collis Merchant Test Suite (MTS) or the ICC Solutions
Test Suite Bundles for Certification (TS) be purchased for use during card brand certification and
when executing the Merchant Services EMV test cases. By using the Collis MTS or ICC TS, a
client can reduce their overall integration testing timeframe based on the enhanced validation
provided.
Collis Merchant Test Suite

The Collis Merchant Test Suite (MTS) is a fully-equipped hardware and software suite that provides
merchants, acquirers, processors, and acceptance device vendors with the tools necessary to validate
their EMV configurations, and to run all the major card brand certification test suites.
The Collis MTS supports both Point of Sale (POS) terminals and Automated Teller Machines (ATM) and
includes detailed scripts that guide the user through the testing process, eliminating much of the
complexity and confusion associated with EMV and contactless brand certifications.
The Collis MTS includes all the hardware and software required for contact and contactless EMV
certifications and comes in a robust carrying case so the complete MTS kit can be easily taken to
wherever you need it.
The Collis MTS includes two unique boxes (SmartLink™ and SmartWave™) to emulate both contact and
contactless cards. The MTS software provides true card simulation by emulating all the functions of actual
EMV and contactless cards.
Page 49
Collis MTS Software:
• Collis Brand Test Tool (BTT). Supports all major US card brand contact and contactless
certification test scripts, and it not only guides you through the certification process, it also tells
you if each test case passed or failed. Once certification testing is complete, the BTT allows you
to extract all information and reports required for card brand submission.
• Collis Card Simulator. Simulates physical contact and contactless EMV cards allowing
developers to perform ad hoc testing. Developers and testers can also alter existing simulated
card profiles or create their own test specific EMV conditions.
• Collis Card Spy. Inspects, measures performance and reports on the flow of data between the
EMV chip (contact and contactless interfaces) and acceptance devices such as terminals and
PIN Pads.
All of the Collis MTS software applications provide a comprehensive interface that displays and interprets
all of the commands being passed between an EMV capable device and the EMV chip card. This
information is invaluable to developers and testers when debugging EMV applications.
Collis MTS Hardware:
• SmartLink™ Box. Physical box and probe used for contact EMV testing
• SmartWave™ Box. Physical box and contactless probe used for contactless EMV testing
• Magstripe Test Cards. Physical cards used to perform Fallback card testing
• License Dongle. Secures access to the software and allows the Collis MTS to be run on any PC
Page 50
All required accessories such as cables, probes, power supplies etc. are included.
The real key to the Collis MTS is the Collis Brand Test Tool (BTT) software. Using the Collis BTT
software, you can test EMV devices within the environment in which they will be operated and test them
using the actual brand settings that will be used for development, certification, and production.
The Collis BTT software produces reports that can be used for local examination and documentation of
the test cases. The reports can also be easily saved and exchanged with other parties involved in the
certification process.
Using the Collis BTT software results in a more robust, repeatable, and well-documented development
environment which leads to a contact and contactless-compliant, brand-certified payment device that can
perform trouble-free EMV transactions within the payment infrastructure.
The BTT is constantly being improved and upgraded to keep up with the latest brand certification
requirements. It currently supports the following certification suites:
• Visa ADVT, qVSDC, CDET, payWave™
• Mastercard M-TIP, PayPass™
• Amex AEIPS
• Discover D-PAS E2E
• Diners E2E
• JCB TCI
• UnionPay UCA
• Interac Flash™
Page 51
Collis is constantly updating their products to add functionality, improve usability and to keep pace with
ever changing card brand certification requirements. The Collis product roadmap can be found at
b2ps.com/brochures/collis_roadmap.pdf.
More information about the Collis MTS can be found at b2ps.com/acquirer_merchant.html or email
sales@b2ps.com.
ICC Solutions Test Suite Bundles for Certification

ICC Solutions Ltd is a global leader in the provision of EMV test tools and services offering the complete
set of qualified test suites for card brand accreditation of contact and contactless EMV terminals,
(American Express, Discover, Interac, JCB, Mastercard, Visa), in addition to EMVCo type approval. ICC
TS stand-alone contact and contactless certification device test tools are used worldwide by Payment
Networks, Terminal and Card Vendors, Test Laboratories, Acquirer / Processors and Merchants /
Retailers enabling development, quality assurance, and regression testing in addition to formal merchant
certifications.
The ICC Solutions contact and contactless test suite bundles are qualified by all payment brands to
perform EMV Chip Terminal level 3 brand accreditation tests for integration testing with Merchant
Services.
Page 52
ICCSimTMat uses standard EMV chip card form factor ICCSim cards onto which each individual test case
is downloaded via the ICCSim card reader prior to running the test. The ICCSim card is also used to
capture the transaction log without any need for complex box of electronics, restrictive card paddle,
expensive spy hardware or huge deck of cards and is also suitable for creating your own test cards.
Operation of ICCSimTMat to perform EMV chip terminal accreditation testing is very straightforward and
can be performed by a non EMV expert. Operational assistance is also included in the purchase price
which is provided remotely by phone or email which includes product training conducted over the internet
using WebEx available upon request. A user guide with clear step–by–step instructions is available after
installation.
The Test Suite Bundle comprises a single software license featuring full set of the latest test cases for
each ICCSimTMat test suite, 1x Dual I/F ICCSim Card Reader / Writer, full set of ICCSim Cards for each
ICCSimTMat test suite plus USB License key enabling access to the test suites.
Page 53
Support & Maintenance (S&M) is included in the purchase price for 12 months which entitles you to
receive ICCSimTMat test tool upgrades and test script release updates free of charge for each test suite
purchased as well as access to technical support.
The Test Suite Bundle software can be installed on multiple computers; however, it is only the one having
the USB license key connected at any point in time that is able to perform / run the tests. It is possible to
run different test suites in parallel by purchasing additional USB license keys priced along with additional
ICCSim readers.
Additional ICCSim cards are available suitable for creating your own test card packs for regression / QA
testing or training / confidence testing etc.
ICC Solutions Ltd provides powerful, efficient, and simple solutions through automated Testing Tools for
ease of use for the client.
Further information about ICC Solutions’ products and services can be found at:
iccsolutions.co.uk/our-products or Email: info@iccsolutions.com
Integrated Solution Validation

Full integration testing is not required when testing solutions that integrate a pre-tested middleware
product or when implementing a semi-integrated solution.
In these cases, Merchant Services may only require a confidence test be performed. This could be done
by running a small number of Merchant Services selected card brand test cases (interop test) using an
EMV Test Tool (i.e. Collis Merchant Test Suite) or by purchasing a set of test cards and running test
cases that will be supplied.
Note: Physical test cards can also be very useful for development, testing, training, and demonstration
purposes as multiple sets of cards are often required and physical cards are the most economical
solution.
Physical EMV test cards are provided by the following vendors:
• B2 Payment Solutions (b2ps.com/B2_test_card_sets.html)
• ICC Solutions (iccsolutions.co.uk/chip-card-confidence-packs-us/4590572123)
Page 54
EMV Implementation Tandem Supplemental Guide EMV
EMV
EMV Benefits
EMV is an international payment system standard for the use of an integrated chip card. Because EMV
utilizes a smart card chip, EMV card transactions, depending on how the issuer personalizes the card,
can be processed either online or offline and validated using NO CVM, Signature or PIN.
EMV provides several significant benefits:
• Counterfeiting and skimming of cards is much more difficult than with existing magstripe cards
• Lost & stolen cards are more difficult to use as EMV cards can require a PIN to be used
• Transactions can be approved offline (if the issuer personalizes the card parameters to allow it)
The EMV references in this document are based on the EMV 4.3 specification.
EMV Capability Enablement or Disablement

Point-of-sale applications may be developed with the ability to turn EMV chip transaction acceptance
capabilities on and off. If this is applicable, the device must be capable of dynamic enablement or
disablement functionality, depending on whether chip cards can be accepted and processed using EMV
technology.
CMS EMV RQ 00300 Enablement / Disablement of EMV functionality within the point-of-sale
application
• Merchant Services requires that if EMV functionality is disabled within an EMV-tested application,
causing chip cards to be processed using its magstripe, the host request message Data Entry
Source or POS Entry Mode and Terminal Capability Code be set to indicate a magstripe swipe
transaction from a non-chip capable terminal.
Online versus Offline EMV Transactions

When authorizing an EMV transaction, the transaction must first be sent to the card for an authorization
decision. The card has three options:
Page 55
• Approve the transaction
• Decline the transaction
• Request the transaction be sent to the issuer host for online authorization
If the EMV chip approves or declines the transaction, it is considered an “Offline” transaction. If the EMV
chip requests the transaction be sent to the issuer’s host for authorization, it is considered an “Online”
transaction.
The card makes the final authorization decision for all online and offline full EMV transactions (e.g. Sale,
Return, etc.). Even if a transaction is sent for online authorization, the issuer authorization decision
returned must be sent to the card for a final authorization decision by the card.
Note: Merchant Services is an Online-Only acquirer. This means that all transactions initiated by
deployed EMV POS Solutions must go online for authorization. During integration testing, Merchant
Services may run additional non-zero floor limit test cases in special scenarios such as client request.
CMS EMV RQ 00301 Transactions must go online for issuer authorization
• Merchant Services requires that all transactions go online to the host for issuer authorization.
EMV Transaction Steps

EMV POS Solutions can perform a combination of EMV and non-EMV transactions. In general terms,
“Full” EMV transactions are purchase transactions where the EMV chip participates in the authorization
decision. Other transactions such as credit return (offline) and reversal are generally implemented as
“Partial” EMV transactions as they are performed the same as magstripe transactions with the exception
that the Track 2 data is read from the chip rather than from the magstripe.
• Full EMV Transaction. EMV chip is used to read card data and the chip participates in the
authorization decision
• Partial EMV Transaction. EMV chip is used to read card data but, the chip does not participate
in the authorization decision and no cryptogram is generated (sometimes referred to as non-EMV
transactions that use EMV functionality)
For information relating to the Full EMV and Partial EMV transaction flows see EMV Transaction Flow
section.
Page 56
Full EMV vs. Partial EMV Transaction Steps
EMV Transaction Full Partial Comment

Step EMV EMV
Transaction Initiation Y Y
Card Presentation Y Y Card is inserted or tapped
Application Selection Y Y
Read Card Data Y Y
Offline Data Y N
Authentication
Processing Y N
Restrictions
Cardholder Verification Y N
Terminal Risk Y N
Management
1st Generate AC Y Y* Includes Terminal Action Analysis and Card Action Analysis
Online Processing Y N
External Authenticate Y N Some cards do not support this step as they include the
Issuer Authentication Data as part of 2nd Generate AC (in
CDOL 2 (Tag 8D), when the AIP is set to support Issuer
Authentication (Tag 82 Byte-1 bit-3)
Script Processing (Tag Y N Executes Tag 71 script commands

71)
2nd Generate AC Y N Some cards include the Issuer Authentication Data as part
of the 2nd Generate AC (in CDOL 2 (Tag 8D) - when the
AIP is not set to support Issuer Authentication (Tag 82 Byte-
1 bit-3))
Page 57
EMV Transaction Full Partial Comment

Step EMV EMV
Script Processing (Tag Y N Executes Tag 72 script commands

72)
Card Removal Prompt Y Y
Partial EMV transactions request an AAC at the 1st Generate AC to terminate the card usage.
EMV Credit Transaction Set

The following table lists the EMV credit transactions supported by Merchant Services and indicates how
each transaction should utilize the EMV chip. Refer to the appropriate host message specification for the
most complete list of supported transactions.
EMV Credit Transaction Set
Refer to the notes below the table.
Transaction Transaction EMV Chip Usage Store EMV

Authorized By Cryptogram (1)
Sale / Authorization Issuer / Card Full Required
Prior / Forced Sale Call Center Partial (2) N/A
Pre-Authorization Issuer / Card Full Required (3)
Completion/Deposit POS Partial or None (4) Required (5)
Authorization Reversal POS Partial or None (6) N/A
Return (Online) (7) Issuer Full Required
Return (Offline) (7) POS Partial N/A
Balance Inquiry Issuer Full Optional
Account Verification Issuer Partial or None N/A
Deferred Authorization Issuer Full Required
Page 58
Notes
(1) Column indicates if the final EMV cryptogram (TC Transaction Certificate) should be stored with an
approved transaction.
(2) The EMV chip is only used to obtain the card PAN.
(3) The EMV cryptogram will be required when performing the Pre-Authorization Completion.
(4) The card must be presented if the Pre-Authorization transaction did not store the PAN.
(5) The final Pre-Authorization cryptogram is used for the Pre-Authorization Completion.
(6) The original transaction PAN is read from the transaction database. If desired that card may also be
used to validate that the cardholder is present by comparing the original PAN to the card PAN.
(7) Return is also known as a Refund. A Return can be generated as an offline or an online transaction.
• Returns (Offline) require that the transaction is a partial EMV transaction
• Returns (Online) must use a Full EMV transaction as these are sent to the Issuer for approval.
See your Account Representative before implementing this function.
EMV Debit Transaction Set

The following table lists the EMV debit transactions and indicates how the transaction should utilize the
EMV chip
EMV Debit Transaction Set
Transaction Transaction Authorized EMV Chip Store EMV Cryptogram*

By Usage
Sale Issuer / Chip Full Required
Sale with Issuer / Chip Full Required

Cashback
Return (Online) Issuer / Chip Full Optional
Reversal Issuer / Chip Partial or Optional

None
Page 59
Transaction Transaction Authorized EMV Chip Store EMV Cryptogram*

By Usage
Balance Inquiry Issuer / Chip Full Optional
*Column indicates if the final EMV cryptogram (TC Transaction Certificate) should be stored with an
approved transaction.
Transaction Processing
The following sections identify EMV transaction specific processing rules.
Sale Transactions
Credit and debit Sale transactions should be processed as Full EMV transactions. Prior Sale and Forced
Sale transactions should be processed as Partial EMV transactions.
CMS EMV BP 00301 Prior/Forced Sale transactions should be Partial EMV transactions
• Merchant Services recommends that the Prior/Forced Sale transaction be a Partial EMV
transaction and only use the chip to obtain the chip Track 2 data. Once obtained the chip
interaction should be terminated by requesting a decline (AAC) at the 1st Generate AC. The
transaction should then continue as a magstripe transaction.
CMS EMV RQ 00302 Sale transactions must be Full EMV transactions
• Merchant Services requires that all credit and debit Sale transactions be processed as Full EMV
transactions and that the cryptogram requested at the 2nd Generate AC be based on the issuer
authorization decision.
Authorization or Pre-Authorization Transactions

Authorization and Pre-Authorization transactions are Full EMV transactions performed with the cardholder
present.
• If a PIN is entered, the receipt should not include a signature line
• If a PIN is not entered, the receipt must contain a signature line
Page 60
CMS EMV RQ 00303 Auth and Pre-Auth transactions must be processed as Full EMV
transactions
• Merchant Services requires that Authorization and Pre-Authorization transactions be Full EMV
authorization decision.
Incremental Authorization
Incremental Authorizations are required when a transaction amount exceeds the original authorization
limits. Incremental Authorizations are not EMV transactions and do not require chip data.
CMS EMV RQ 00304 Incremental Authorizations must be sent as keyed transactions
• Merchant Services requires that Incremental Authorizations be sent to the host in keyed format
and do not include any other card data obtained from the original Authorization transaction.
Completions
Completions (including tip adjustments) are Partial EMV transactions that use EMV data from the original
Pre-Authorization transaction. The cardholder is not required to present their card when the Completion is
performed.
CMS EMV RQ 00305 Completions without cardholder present require Pre-Authorization chip
data
• Merchant Services requires that the Completion request message includes all chip data from the
original Pre-Authorization transaction including the final Pre-Authorization cryptogram.
Return
Return, also known as a Refund, transaction processing differs depending on the type of return being
performed.
CMS EMV RQ 00307 Credit Return (Online and Offline) EMV transactions
• Merchant Services requires that Credit Return (Offline) transactions are Partial EMV transactions
and request a decline (AAC) at the first Generate AC to terminate the card interaction.
Page 61
• Merchant Services requires that Credit Return (Online) transactions are Full EMV online
authorization decision. Before implementation, refer to your Account Representative.
CMS EMV RQ 00308 Debit Returns must be Full EMV transactions
• Merchant Services requires that Debit Return transactions be Full EMV online transactions and
that the cryptogram requested at the 2nd Generate AC be based on the issuer authorization
decision. See your Account Representative before implementing this function.
Balance Inquiry Transactions

Balance Inquiry transactions are Full EMV transactions as they perform all EMV steps up to and including
Issuer Script processing. Because Balance Inquiry transactions do not transfer funds they should not be
reversed if the card declines the transaction at the 2nd Generate AC.
Quick Service Transactions

This section describes the following Quick Service Transactions: QSR, QPS, FPS.
For traditional magstripe Quick Service transactions, receipt printing is optional if the transaction amount
is below the no signature floor limit. However, “no signature floor limit” processing does not apply to Full
EMV transactions. EMV transactions must follow CVM processing rules to determine if a signature or PIN
is required.
Quick Service Restaurants may wish to have a floor limit under which NO CVM is used and over which a
Signature or PIN CVM is used. To do this, multiple selectable kernel configurations must be implemented.
One kernel configuration would include a standard configuration supporting multiple CVMs (i.e. PIN,
Signature or NO CVM) and the other would only include NO CVM. The kernel configuration to be used
would be selected at the beginning of each transaction by the EMV POS Solution based on the
transaction amount.
Note: EMV POS Solutions that implement a selectable kernel configuration must undergo multiple EMV
card brand certifications. One certification for each kernel configuration implemented.
CMS EMV RQ 00309 CVM processing must be performed for QSR transactions
• Merchant Services requires that Cardholder Verification Method (CVM) processing be performed
for EMV QSR transactions. If the CVM selected is ‘Signature’, a receipt must be printed
regardless of the transaction amount. If printing a receipt is not desired, using a selectable NO
Page 62
CVM only kernel configuration will allow the transaction to be performed as a NO CVM
transaction which does not require a receipt to be printed.
Page 63
Contactless
Contactless Benefits
For the consumer and merchant there are three benefits to contactless transactions:
• Efficiency. There is no need for consumer verification (i.e. no PIN required) for low value
payments. It becomes ‘Tap and Go’.
• Security. With the chip, there can be dynamic security. The consumer receives the same level of
fraud protection on contactless payments that they would for contact payments. This means the
consumer is not liable for any losses.
• Speed. Using contactless technology there is no need for swiping or inserting the payment card,
therefore transaction throughput can be increased. In many cases, a receipt is only printed at the
cardholder’s request.
These benefits create an advantage for merchants as consumers tend to spend more. When merchants
can accept a payment method that encourages consumers to spend more, and the transaction speed is
faster, there is an incentive to invest in the technology.
MSD vs EMV Grade

When implementing contactless technology, two current environments must be supported for global
acceptance:
1. MSD. Contactless magstripe cards use the Track 2 with dynamic data embedded within the track
data
2. EMV. contactless or dual interface cards that use EMV technology (i.e. cryptograms) to secure
the transaction
Contactless Card Schemes

A number of contactless card schemes have been implemented by the card brands.
Page 64
Contactless Card Schemes
Scheme Specifications
Amex ExpressPay ExpressPay 3.0 Card Specification
Discover D-PAS D-PAS Contactless Specifications 1.0
Interac Interac Flash 1.4
Mastercard PayPass Mastercard PayPass Reader Card Application Interface Specification

3.0
Mastercard M/Chip Advance
Visa payWave VCPS 2.1 + Updates List
EMV Contactless Transaction Sets

The following table lists the EMV Contactless Form Factor (CFF) transactions supported by Merchant
Services and indicates how the transaction should utilize the EMV chip.
EMV Contactless Transaction Set
Transaction Transaction CFF Used Store EMV Cryptogram*

Authorized By Interactively
Online Sale Issuer / CFF** Yes*** Mandatory
Pre-Authorization Issuer / CFF Yes Mandatory****
Completion Terminal No Mandatory*****
Authorization Reversal Issuer / No N/A

Terminal
Return (also known as Issuer Yes N/A

Refund)
Reversal Issuer / No N/A

Terminal
Balance Inquiry Issuer Yes Optional
Page 65
*This column indicates whether the final EMV cryptogram (TC Transaction Certificate) should be stored
with an approved transaction.
**Contactless Form Factor (CFF).
***The CFF is used interactively only up until the 1st Generate AC or until the magstripe data has been
received by the reader.
****The final EMV cryptogram is required when sending offline approved transactions to the host. After
the authorization, the cryptogram can be handled in the same manner as Online Sale transactions.
***** The original Pre-Authorization EMV cryptogram is required when performing the Pre-Authorization
Completion.
Page 66
EMV Transaction Flow

Full EMV Transaction Flow
The following table outlines a generic overview of the steps required to perform a Full EMV transaction
(e.g. Sale, Return (Online), etc.). For Full EMV transactions the card makes the final authorization
decision.
Full EMV Transaction Flow
Process Description
Tender Initialization Transaction type is selected, and the transaction amount is determined
including:
• Tax
• Tip
• Cashback
Card Entry Card is inserted and chip initialization is performed:
• Validate ATR (Answer to Reset)
• Set Language
• Set Terminal Country Code (US=”840”)
• Set Transaction Amount (see Tender Processing section)
Page 67
Process Description
Application Selection A Candidate List is created of AIDs that are mutually supported by both
the card and the EMV POS Solution:
• US Common Debit selection processing (see Credit / Debit Selection

and US Debit Processing section)
• If the Candidate List is empty, fallback processing is performed
• If only one mutually supported AID is found:
• AID is automatically selected
• Cardholder is required to confirm selection if Application Priority

Indicator - Cardholder Approval Indicator (Tag 87 bit-8) is set to ‘1’
• If more than one mutually supported AID is found:
• If a US Common Debit AID is present, it may be selected
• Otherwise, the cardholder should be prompted to select the

application or, if prompting is not possible, the highest priority AID
should be automatically selected
Read Data Records EMV POS Solution reads data records for the AID selected:
• Card PAN (Tag 5A)
• Expiry Date (Tag 5F24)
• Track 2 Equivalent Data (Tag 57)
• Card Validation Checks (IIN, MOD10, etc.)
• Etc.
Card Validation Checks (IIN, MOD10, etc.) are performed on data read.
Page 68
Process Description
Risk Management The kernel and chip perform multiple risk management processes. The
results are stored in the TVR (Tag 95) and CVR part of the Issuer
Application Data (Tag 9F10), and are transmitted to the issuer as part of
the authorization request:
• Processing Restrictions
• Application Effective Date
• Application Expiry Date
• Application Version Number
• Card Usage Control (based on the AUC Tag 9F07)
• Offline Card Authentication (SDA / DDA / CDA)
• Terminal Risk Management
• Cardholder Verification (PIN / Signature / NO CVM)
Apply Card Discounts The final transaction amount is determined by applying applicable card
discounts based on the type of card presented (if any).
For contact transactions there are two options. The EMV POS Solution
can either:
• Update Transaction Amount (Tag 9F02) with the new (lower)

transaction amount and send the updated tag value to the PIN Pad
kernel before the 1st Generate AC.
• Leave Transaction Amount (Tag 9F02) set to the original (higher)

transaction amount and continue to the 1st Generate AC using the
original amount. This means that the amount stored in Transaction
Amount (Tag 9F02) will differ from the final transaction amount.
For contactless transactions Transaction Amount (Tag 9F02) cannot be

changed during the transaction. This means that the amount stored in
Transaction Amount (Tag 9F02) will differ from the final transaction
amount.
Page 69
Process Description
1st Generate AC The EMV POS Solution requests an authorization from the chip. The
EMV chip will respond with an Application Cryptogram:
• Offline Approved (returns TC)
• Offline Declined (returns AAC)
• Online Authorization Required (returns ARQC)
Host Authorization If online authorization is required, the EMV POS Solution sends the
transaction to the Merchant Services host for authorization.
If unable to go online, the EMV POS Solution may, based on Floor

Limits, locally approve or decline the transaction.
Note: EMV US Debit transactions cannot be approved locally.
Transaction Completion The authorization decision is sent to the EMV chip for final processing
Processing including.
• Issuer Authentication Data (Tag 91)
• Issuer Scripts (Tag 71 or Tag 72)
• Authorization Response Code (Tag 8A) from the issuer or locally

generated
Completion processing includes:
• External Authenticate (if an ARPC is returned by the issuer and the

AIP Issuer Authentication (Tag 82 Byte-1 bit-3) flag is enabled
• Issuer Script Processing (if any)
• 2nd Generate AC (to determine the final transaction disposition.

Approved (TC) or Declined (AAC))
Page 70
Process Description
Host Reversal Processing If the issuer approves the transaction and any of the following occurred
(if required) during Transaction Completion Processing (previous step), a reversal
must be sent to the Merchant Services host:
• PIN Pad not available
• Card removed prior to the completion of processing
• Chip Malfunction (except Mastercard, see requirement below)
• Chip declines the transaction (2nd Generate AC)
• Cardholder cancels transaction
Store Transaction Results The transaction results including the Application Cryptogram should be
stored in the transaction database.
Note: It is optional whether Decline and Reversal transactions are

stored in the transaction database. However, the information relating to
the transaction must be available for the EMV Transaction Report (see
EMV Transaction Report section).
Remove Card The cardholder is prompted to remove the EMV card.
Receipt Printing The EMV transaction receipt is printed. The receipt must contain the
following EMV information:
• Card Entry Indicator (to indicate how cardholder data was obtained)
• Application Preferred Name (or Application Label)
• Signature Line (if the CVM was Signature or NO CVM)
• “Verified by PIN” (if the CVM was one of the PIN types)
• AID. Application Identifier
• TVR. Terminal Verification Results
• TSI. Transaction Status Indicator
• AC. Application Cryptogram
• ARC. Application Response Cryptogram
Transaction Upload If the transaction was locally authorized, it is sent to the host prior to or
at settlement.
Page 71
CMS EMV RQ 00501 Mastercard requires issuer decision be used for 2nd Generate AC chip
error
• Mastercard requires that the transaction be approved or declined based on the issuer
authorization decision returned in the host response when a chip malfunction occurs at the 2nd
Generate AC.
Full EMV Transaction Flowchart
Page 72
Partial EMV Transaction Flow

The following table outlines a generic overview of the steps required to perform a Partial EMV transaction
(e.g. Credit Return (Offline) or Void). For these transactions the EMV card is only used to obtain Track 2
information stored on the chip. The card does not participate in the authorization decision.
Partial EMV Transaction Flow
Process Description
Tender Initialization Transaction type is selected, and the base transaction amount is
determined including:
• Tax
• Tip
• Cashback
Note: For transactions such as Reversals or Completions this

information may be read from the transaction batch.
Card Insertion Card is inserted and chip initialization is performed:
• Validate ATR (Answer to Reset)
• Set Language
• Set Terminal Country Code (US=”840”)
• Set Transaction Amount (see Tender Processing section)
Page 73
Process Description
Application Selection A Candidate List is created of AIDs that are mutually supported by both
the chip and the EMV POS Solution:
• US Common Debit selection processing (see Credit / Debit Selection

• If the Candidate List is empty, MSR Fallback processing is

performed
• If only one mutually supported AID is found:
• AID is automatically selected
• Cardholder is required to confirm selection if Application Priority

Indicator - Cardholder Approval Indicator (Tag 87 bit-8) is set to ‘1’
• If more than one mutually supported AID is found:
• If a US Common Debit AID is present, it may be selected
• Otherwise, the cardholder should be prompted to select the

application or, if prompting is not possible, the highest priority AID
should be automatically selected
Read Data Records EMV POS Solution reads data records for the AID selected:
• Card PAN (Tag 5A)
• Expiry Date (Tag 5F24)
• Track 2 Equivalent Data (Tag 57)
• Card Validation Checks (IIN, MOD10, etc.)
• Etc.
Apply Card Discounts The final transaction amount is determined by applying applicable card
discounts based on the type of card presented (if any).
Note: Transaction Amount (Tag 9F02) does not need to be updated as

Partial EMV transactions request an AAC at the 1st Generate AC to
terminate the card usage.
1st Generate AC The EMV POS Solution requests an AAC from the card to terminate the
chip interaction.
Authorization The transaction is sent online or locally authorized.
Page 74
Process Description
Store Transaction Results The transaction results are stored in the transaction database.
Remove Card The cardholder is prompted to remove the EMV card.
Receipt Printing The EMV transaction receipt should be printed. The receipt must
contain the following EMV information:
• Chip Indicator (to indicate cardholder data was read from a chip)
• AID
• Application Preferred Name (or Application Label)
• Signature Line (always)
Transaction Upload If the transaction was locally authorized, it is sent to the host prior to or
at settlement.
Page 75
Partial EMV Transaction Flowchart
Contactless Transaction Flow

When a contactless form factor is presented, the Contactless kernel will select a mutually supported
application, read the data contained in the contactless form factor for the selected application and make a
transaction decision to:
• Not accept contactless at all (if amount is over the contactless transaction limit)
• Approve offline
• Decline offline
Page 76
• Request an online authorization
The contactless form factor sends the authorization decision, optionally the cryptogram (depending on
which type of contactless application has been selected, MSD or EMV) and any CVM options that may be
processed based on the contactless CVM limits and conditions, to the payment application for further
processing.
Page 77
Chip Processing Guidelines

Note: The transaction process implemented will differ based on the PIN Pad selected and the API the
PIN Pad supports. The processes described in this document are based on a “typical” PIN Pad API which
combines several EMV transaction steps into a single API command and supports modification of the
Transaction Amount (Tag 9F02) during transaction processing. Please refer to the PIN Pad vendor
specifications for specific details on implementing PIN Pad API commands.
Tender Processing
For EMV transactions the full transaction amount must be known prior to card entry. This includes the
base transaction amount plus any cashback that may be added. Tip may be included as part of the full
transaction amount or adjusted later. Refer to Tip Transaction Flow section for more information on Tip
Processing.
If card discounts are applicable based on the card presented, then card discounting must occur after card
entry and before the 1st Generate AC.
Suggested amount confirmation display text can be found in Amount Confirmation Prompting section.
Note: For contactless transactions, Transaction Amount (Tag 9F02) cannot be changed once the card
has been presented.
CMS EMV RQ 00601 Total transaction amount must be known before the card is presented
• Merchant Services requires that all EMV POS Solutions complete the tendering process before
prompting for card entry.
CMS EMV RQ 00602 Transaction Amount (Tag 9F02) must be set to total transaction amount
• For single message transactions it is required that the Transaction Amount (Tag 9F02) be set to
the total transaction amount (including cashback and tip) before performing the 1st Generate AC.
It is optional whether applicable card discounts (if any) are applied to Transaction Amount (Tag
9F02).
CMS EMV RQ 00603 Cardholder amount confirmation is optional
• Merchant Services does not require that cardholder confirm transaction amount. However, if a
confirmation amount screen is presented and cardholder does not confirm the transaction
amount, then the transaction must be cancelled.
Page 78
Cashback Transaction Flow

Cashback is supported for online debit and Discover transactions only, and the cashback amount must be
known prior to card entry. Therefore, after card entry completes, the EMV POS Solution must ensure that
a debit or Discover card was presented. If not, the transaction must be cancelled.
For cashback transactions:
• The cardholder must confirm the cashback amount prior to card entry
• Transaction Amount (Tag 9F02) must include the cashback amount
• Other Amount (Tag 9F03) must be set to the cashback amount
• For Mastercard transactions, transaction Type (Tag 9C) must be set to ‘09’ indicating a “Purchase
with Cashback”
For Canadian Interac cashback requirements see Appendix A.
CMS EMV RQ 00604 Transaction Amount (Tag 9F02) must include the cashback amount
• Merchant Services requires that the cashback amount be included in the full transaction amount
stored in Transaction Amount (Tag 9F02).
CMS EMV RQ 00605 Other Amount (Tag 9F03) must contain the cashback amount
• Merchant Services requires that the cashback amount be stored in Other Amount (Tag 9F03) and
sent to the host as part of the authorization message.
CMS EMV RQ 00606 Cashback is only allowed for online debit and Discover AIDs
• Merchant Services requires that the transaction be cancelled if a cashback amount is entered and
the AID selected for the transaction is not a debit or Discover AID.
CMS EMV RQ 00607 Transaction Type must be set to ‘09’ for Mastercard debit cashback
transactions
• It is required that Transaction Type (Tag 9C) be set to ‘09’ for all Mastercard purchase with
cashback transactions.
Page 79
Tip Transaction Flow

Historically, transactions with tipping are completed by performing a Pre-Authorization for the pre-tip
amount and a Completion for the final amount (pre-tip amount + tip amount). This practice does not need
to change for an EMV transaction.
There are three basic acceptance models for card-based tip and gratuity payments, all of which are
supported by Merchant Services.
• Tip Allowance. Merchant authorizes for ticket amount only, excluding tip. A receipt is printed for
the cardholder to sign and optionally add a tip. Settlement may be adjusted to include the tip.
• Counter. When paying at the counter, the cardholder may add a tip to their total as part of the
checkout process. The merchant authorizes for the total amount of the transaction including both
the ticket amount, tip amount and cashback amount.
• Table Pay. Using portable or wireless terminal solutions the merchant can bring a payment
device directly to the cardholder allowing them the opportunity to add a tip amount. The merchant
authorizes for the ticket amount plus the actual amount of the tip. This is recommended if the
terminal supports PIN CVM.
CMS EMV BP 00601 If PIN CVM is supported use Table Pay for restaurant tipping
• For environments such as Restaurants that require tipping it is recommended that a Pay at Table
solution be implemented so that an EMV purchase transaction with a tip prompt and PIN entry
can be used.
Faster EMV Transaction Flow

This section describes the following Faster EMV methods: Quick Chip, M/Chip Fast.
“Faster EMV” is a term generally used to describe the optimized online-only EMV transaction processing
solutions announced separately by American Express (Quick Chip), UnionPay via Discover (Quick Chip),
Discover (Quick Chip), Mastercard (M/Chip Fast), and Visa (Quick Chip). These solutions retain the
counterfeit protection security features of EMV, while removing issuer validation dependencies which can
negatively impact the cardholder perception of transaction time.
The Faster EMV solutions are ideal for multi-lane retailers that support a “swipe-ahead” option for
magnetic swipe transactions as the Faster EMV transaction flow will provide a similar user experience.
Page 80
The swipe-ahead option allows a cardholder to swipe their card prior to the final amount of the transaction
being known.
Characteristics of faster EMV transaction flow
• Use a pre-determined amount to obtain the 1st Generate AC ARQC prior to determination of the
final transaction amount (check with your Merchant Services Implementation Manager for a
recommended amount or we recommend using the merchant’s average ticket amount rounded
up to the nearest $10). After this all the standard EMV transaction steps are performed including
application selection, cardholder verification, processing restrictions, terminal risk management
and offline data authentication.
• The chip card transaction is finalized by requesting a termination cryptogram (AAC) at the 2nd
Gen AC with tag 8A set to “Z3” (Unable to go Online), to complete EMV processing. This must be
done before the authorization response is received by the terminal. Request the 2nd Gen AC
before the authorization message is sent to the host. At settlement (required for TCS batch
upload and file processing), tag 8A must be updated and sent with the correct value per the
transaction’s final authorization status (approved), refer to the section Host Message Processing
> Host Message EMV Tags > Settlement EMV Tags.
• The chip card can now be removed from the reader.
• Once the final transaction amount is known, the terminal authorizes the transaction online. The
authorization request message should have:
o the final transaction amount in the Transaction Amount field
o the original pre-determined amount in tag 9F02 of the EMV Data Field (also known as
DE55 or Field 55)
The issuer host uses the Transaction Amount to score and approve the transaction and tag 9F02 for
cryptogram validation.
• The terminal indicates whether the transaction was approved or declined according to the issuer’s
decision and captures the cardholder’s signature when necessary.
• If the host response message contains EMV tags (71, 72 or 91) these can be ignored.
• Refer to the diagram on the following page for the visual transaction flow.
Page 81
EMV Transaction Initiation

EMV transaction initiation prepares the PIN Pad to accept an EMV card. A prompt must be displayed on
the PIN Pad indicating the card should be inserted or tapped (if contactless is supported). It is optional
whether the prompt indicates that the card may be swiped.
EMV transactions can be initiated by:
• Card Insertion or Card Tap. Must be attempted first for all EMV chip cards.
Page 82
• Card Swipe. If a card is swiped, the Service Code must be interpreted to determine if the card
contains a chip. If the Service Code indicates a chip card, the swipe must be discarded and a
prompt to insert or tap (if contactless EMV is supported) must be displayed. A card swipe is only
allowed for EMV cards when in fallback. For more information on Fallback see Fallback
Processing section.
Service Code Processing

When processing the magstripe information, the EMV POS Solution must read and act upon the contents
of the Track 2 Service Code.
EMV chip cards contain a Track 2 Service Code beginning with “2 or “6”. The Service Code value must be
checked to determine if a chip read is required.
Chip Service Codes Processing
Service Code Card Type Action Required
2xx International Use Chip
6xx Domestic Use Chip
CMS EMV RQ 00608 Service Code ‘2xx’ and ‘6xx’ must force a chip usage
• The card brands require that when a card is swiped with Service Code ‘2xx’ or ‘6xx’ (indicating
that a chip is present), that the EMV POS Solution prompts for the card to be inserted into the
chip reader.
Chip Read Flow

For EMV cards it is mandatory that a chip transaction be attempted before a magstripe or fallback
transaction is allowed. If your EMV POS Solution accepts magstripe reads from a device other than a
locally attached PIN Pad, you must ensure the Service Code is being checked by that device and that an
attempt is made to use the EMV chip before proceeding as a magstripe transaction.
If a card with an EMV Service Code (‘2xx’ or ‘6xx’) is swiped, the swipe must be rejected, and the
cardholder must be prompted to use the chip reader. For suggested text see Card Entry Prompting
section.
The following table shows the actions that should be taken when issues occur while reading card data
from the chip and magstripe.
Page 83
Chip Reader Actions
Condition Action
Card Insertion (ATR) Error Technical Fallback processing
Card Blocked (card returns “6A81”) Reject card. Prompt for another card
Application Blocked (card returns Reject card. Prompt for another card or cancel
“6283”)
Empty Candidate List MSR Fallback processing
Card removed before host Cancel transaction

authorization
1st Generate AC Unsuccessful Fallback enabled for AID. Technical Fallback
Fallback not enabled for AID. Cancel transaction
1st Generate AC Successful Proceed with EMV transaction
Magstripe Reader Actions
Condition Action
Read Failed Reject card. Prompt for another card
Unknown IIN Reject card. Prompt for another card
EMV Service Code ‘2xx’ or ‘6xx’ If a fallback swipe. Continue with fallback
If not a fallback swipe. Force chip read
Non-EMV Service Code (not ‘2xx’ or ‘6xx’) Proceed with magstripe transaction
CMS EMV RQ 00609 Cancel transaction if card accepted but removed before host authorization
• Merchant Services requires that the transaction be cancelled when an EMV card is successfully
read but is removed before performing the online authorization.
CMS EMV RQ 00610 Reverse and cancel if host approves but card removed before 2nd Gen AC
Page 84
• Merchant Services requires that the transaction be cancelled if the card is removed before the
2nd Generate AC completes. If the host approved the transaction, a reversal must also be sent to
the Merchant Services host.
CMS EMV RQ 00611 Decline transaction if host declines and card removed before 2nd Gen AC
• Merchant Services requires that the transaction be declined when a host authorization is
performed and the transaction is declined by the issuer, and the card is removed before the 2nd
Generate AC completes.
CMS EMV RQ 00612 Only one card interface may be active once a read has begun
• Merchant Services requires that once a read has begun using one of the device interfaces
(swipe, contact or contactless), all other card interfaces be deactivated (e.g. when a contact read
is being performed the swipe and contactless interfaces should be deactivated).
Page 85
Chip Read Flowchart
Fallback Processing
For the purposes of this document, the term “Fallback” is defined as the acceptance of chip cards via
magnetic stripe processing at a chip-enabled device. EMV POS Solutions must accept both chip and
magstripe cards and thus have both chip and magnetic-stripe readers.
When a chip card is presented, the card information must be obtained via the chip reader (or EMV
contactless interface) and not the magnetic-stripe reader, if the chip and the chip reader are both
functioning. In situations where either the chip or the chip reader is not functioning, card information may
be obtained by reading the magstripe. The resulting transaction is referred to as a “Fallback” transaction.
Page 86
These transactions are deemed less secure because magnetic-stripe acceptance circumvents the control
and risk management protection available with chip acceptance.
There are two primary reasons why fallback occurs. The difference is based on where in the transaction
flow it is determined that a chip transaction cannot proceed and that a magstripe transaction must be
performed:
• Empty Candidate List (no mutually supported AIDs)
• Unable to read chip (chip or chip reader failure)
Several terms are used in the US market pertaining to fallback including MSR Fallback and Technical
Fallback. Using this nomenclature creates confusion therefore this section will focus on the reason for the
fallback rather than on any given name. The term “Fallback” refers to any transaction where the
magstripe on a chip card is used to process a transaction on a chip enabled terminal.
CMS EMV RQ 00613 Service Code ‘2xx’ and ‘6xx’ must be accepted for fallback card swipes
• It is required when in fallback that the magnetic-stripe reader accepts a swiped EMV card and
processes it as a non-chip card (i.e. as a standard magstripe card) even though the Service Code
is ‘2xx’ or ‘6xx’.
CMS EMV RQ 00614 Fallback must be cancelled when a card is inserted at fallback card entry
• While waiting for a fallback card swipe, if an EMV card is inserted or tapped, fallback processing
must be discontinued, and the transaction proceeds as an EMV transaction.
CMS EMV RQ 00615 Fallback must be cancelled if a non-EMV card is swiped during fallback
• When waiting for a fallback card swipe, if the swiped card does not have a ‘2xx’ or ‘6xx’ Service
Code, fallback must be discontinued, and the transaction is performed as a traditional magstripe
transaction from a chip enabled terminal.
Fallback Acceptance
Fallback is used when a chip enabled device is unable to read a chip card due to either a chip read failure
or unsupported AID. In these cases, the card information must be obtained by reading the magnetic
stripe. There are several situations when Fallback occurs:
• When the chip on the card is inoperative (no ATR received from the chip)
Page 87
• An invalid ATR is received from the chip
• When the PIN Pad chip reader is malfunctioning
• When Application Selection returns Empty Candidate List.
CMS EMV RQ 00618 Fallback transactions must be identified in the host message
• Merchant Services requires that the proper values* be used in the host message when a swiped
transaction is performed on a chip card from a chip enabled device. *Refer to the host message
specification applicable to your implementation.
Fallback Not Allowed Scenarios

After successful Application Selection, there are several reasons why a chip transaction may fail, but
fallback processing is not allowed. When any of these situations occur, another form of payment is
required:
• The card has been blocked
• The card application has been blocked
• The transaction is offline declined (AAC generated at 1st Generate AC)
• The card is removed prematurely, before the transaction has been completed
• Fallback is not supported by the card brand
• The Transaction is cancelled at any point
Fallback Prompting
If fallback is required, the cardholder should be prompted to use the magnetic-stripe reader followed by a
standard card entry prompt indicating that a card may be inserted, swiped, or tapped (if supported). Even
though fallback is active the cardholder should be allowed to either insert or tap the same or a different
EMV card.
CMS EMV BP 00602 Fallback Prompting should only be allowed for a limited time
• Merchant Services recommends that when a fallback prompt is displayed, it only be enabled for
60 seconds. After that period, if a card is swiped with an EMV Service Code (‘2xx’ or ‘6xx’), the
prompt to use the chip reader should be displayed.
Page 88
CMS EMV RQ 00619 Fallback must be cancelled when card is inserted during fallback card entry
• Merchant Services requires that fallback processing be discontinued and the transaction
proceeds as an EMV transaction, when an EMV card is inserted or tapped while waiting for a
fallback card swipe.
CMS EMV RQ 00620 Service Code ‘2xx’ and ‘6xx’ must be accepted for fallback card swipes
• It is required that when in fallback the EMV POS Solution accepts a swiped EMV card (Service
Code ‘2xx’ or ‘6xx’) and processes it as a standard magstripe card.
Fallback Timeline
Fallback is a temporary practice that may only be allowed for a limited time, after which fallback
transactions may not be permitted. EMV POS Solutions must have the technical capability to allow or
disallow fallback transactions by card scheme and must be able to activate/deactivate this capability
based on rules established by the card brand and as subsequently directed by Merchant Services.
When fallback is discontinued for a card scheme, the EMV chip cards for that scheme may no longer be
processed as magstripe cards. At this time, the US has not set a date by when Fallback is no longer
allowed.
Note: The Merchant Services EMV Parameter Download includes a Fallback Flag for each card scheme
(AID). For more information, refer to the EMV Parameter Download section.
CMS EMV RQ 00621 Fallback Flag must be downloaded from the host and used
• Merchant Services requires that the Fallback Flag included in the Merchant Services EMV
Parameter Download be used by the EMV POS Solution.
CMS EMV RQ 00622 Fallback is not allowed if not supported by card scheme
• It is required that fallback only be allowed when permitted by the card scheme. If a fallback
situation occurs and fallback is not allowed for the card presented, the transaction must be
cancelled.
Exception to Fallback
There are exceptional circumstances where a terminal is deployed into the US market that is only partially
enabled for EMV. These situations should be rare and only under a waiver facilitated by Merchant
Services. A common example of a partially enabled terminal is one that was integration tested for EMV
credit but continues to process PIN-Debit through magnetic stripe interface.
Page 89
If a terminal has in place code that will intentionally ignore the 2XX or 6XX service code on the mag stripe
and allow the transaction to be processed as mag stripe, then the terminal is considered partially enabled.
In the scenario where the service code is ignored upon swiping a chip card, the terminal is considered
non-chip capable for that particular transaction. When this situation occurs, the terminal must dynamically
alter its capability indicator and reflect in the authorization request that it is a mag-stripe terminal.
CMS EMV RQ 00617 Transactions sent as swiped because EMV was not enabled must not be
sent as Fallback
• Merchant Services requires that if a terminal intentionally ignores the service code and forces a
chip card to be processed using its magstripe, the host request message Data Entry Source or
POS Entry Mode and Terminal Capability Code be set to indicate a magstripe swipe transaction
from a non-chip capable terminal.
Application Selection
An EMV card may support more than one application (AID). When a card with multiple applications is
presented, Application Selection must be performed to select the AID to be used for the transaction.
Note: The Application Selection process differs slightly for Canadian Interac transaction processing. For a
description of the differences see the Canadian Application Selection section in Appendix A.
The EMV POS Solution must be configured with the AIDs of all chip payment applications it supports. If
none of the AIDs supported by the EMV POS Solution match an AID supported by the card, a chip
transaction cannot be performed. In this case MSR fallback processing must be initiated.
The AID consists of three components:
• Registered Application Identifier (RID). Represents the payment scheme (e.g. Visa, Mastercard,
etc.)
• Proprietary Application Identifier Extension (PIX). Represents the payment brand (i.e. credit,
debit, prepaid, ATM-only, etc.)
• Issuer Suffix. Optional suffix sometimes added to the end of the AID by the issuer
An Application Selection Indicator associated with each AID designates how application matching is
performed:
Page 90
• Full Selection. The EMV POS Solution AID must exactly match the entire card AID, including any
issuer assigned suffix, to be selected
• Partial Selection. The EMV POS Solution can select an AID based on only its AID matching the
card AID excluding the issuer assigned suffix (if any)
CMS EMV RQ 00623 Partial Selection must be supported
• It is required that Partial Selection be supported for all card schemes. This ensures that all chip
applications for a supported AID can be selected regardless of any issuer assigned suffix.
The following table shows the EMV AIDs supported by Merchant Services.
Application Identifiers (AID)
Application Type AID (RID + PIX) RID PIX
Amex Credit A00000002501 A000000025 01
ChaseNet Credit A0000000031010 A000000003 1010
Discover Credit A0000001523010 A000000152 3010
Discover US Common Debit A0000001524010 A000000152 4010
Discover Zip Credit A0000003241010 A000000324 1010
Debit Network Alliance (DNA) Debit A0000006200620 A000000620 0620
UnionPay via Discover Credit A000000333010102 A000000333 010102
UnionPay via Discover Debit A000000333010101 A000000333 010101
UnionPay via Discover Quasi Credit A000000333010103 A000000333 010103

Credit
UnionPay via Discover US US Debit A000000333010108 A000000333 010108

Common
Interac (see Note below) Debit A0000002771010 A000000277 1010
JCB Credit A0000000651010 A000000065 1010
Page 91
Application Type AID (RID + PIX) RID PIX
Mastercard Credit Credit A0000000041010 A000000004 1010
Mastercard International Debit A0000000043060 A000000004 3060

Maestro
Mastercard US Maestro Debit A0000000042203 A000000004 2203
Visa Credit Credit A0000000031010 A000000003 1010
Visa Electron Credit A0000000032010 A000000003 2010
Visa Interlink Debit A0000000033010 A000000003 3010
Visa US Common Debit Debit A0000000980840 A000000098 0840
Voyager Credit A0000000049999 A000000004 9999
Wright Express Credit A0000007681010 A000000768 1010
Note: The ChaseNet card is defined as a Visa card and therefore uses the Visa RID (AID and PIX).
Note: Interac EMV AID is only permitted with Canadian POS solutions at this time. US POS solutions
must not be coded to support the Interac AID until further notice from Merchant Services. Interac
transactions originated through US POS solutions, where the presented Interac card supports Visa Debit,
will process as EMV using the Visa Global AID. Interac cards that do not support Visa Debit must
continue to be processed by magnetic stripe.
CMS EMV RQ 00624 Accept valid AIDs only
• Merchant Services requires that EMV POS Solutions only accept AIDs allowed based on the
Merchant Services merchant agreement. Any AID that has not been approved for use should be
rejected by the EMV POS Solution without being sent to the Merchant Services host for
authorization.
Application Selection Methods

The first step of Application Selection is to build a Candidate List of AIDs supported by both the card and
the EMV POS Solution. There are two methods that may be used by the kernel to build the Candidate
Page 92
List. The method used is dependent on whether the card has a Payment System Environment (PSE)
present:
• Implicit Application Selection Method: used when PSE is present on the chip
• Explicit Application Selection Method: used when PSE is not present on the chip
Note: The Payment System Environment (PSE) is a list of all payment applications (AIDs) that exist on
the card.
Implicit or Explicit Application Selection is performed by the kernel, not by the EMV POS Solution. It is up
to the kernel to determine which selection method to use and to build the initial Candidate List of
commonly supported AIDs.
Implicit Application Selection is the most efficient selection method, but it can only be used when the chip
contains a Payment System Environment (PSE). Therefore, the first step of Application Selection is for
the kernel to read the PSE from the card. If a PSE is returned, Implicit Application Selection will be
performed. If no PSE is returned, Explicit Application Selection will be performed.
CMS EMV RQ 00625 AID list must be loaded into the kernel at kernel initialization
• It is required that as part of kernel initialization, all AIDs supported by the EMV POS Solution be
loaded into the kernel for use during Application Selection.
Implicit Application Selection
This section describes Implicit Application Selection (PSE).
To perform Implicit Application selection, the kernel reads the PSE from the card to obtain the list of AIDs
supported by the card. This list is then compared to the list of AIDs supported by the EMV POS Solution.
AIDs supported by the EMV POS Solution and found in the PSE application list are added to the
Candidate List.
Explicit Application Selection
To perform Explicit Application Selection, the kernel uses the list of AIDs supported by the EMV POS
Solution. For each supported AID, the kernel attempts to select the AID from the card. If successful, the
AID is added to the Candidate List. If unsuccessful, the AID is not eligible.
Page 93
Credit or Debit Selection and US Debit Processing

For traditional magstripe debit transactions, merchants chose what cardholder verification to use for the
transaction. This would be either to:
1. Prompt the cardholder to enter the PIN (commonly referred to as “PIN Preferring Merchants”).
2. Prompt the cardholder to select either “Credit” or “Debit” (commonly referred to as “Credit / Debit
button supporting merchants”). In this situation:
o Credit: perform a Signature Debit transaction
o Debit: perform a PIN Debit transaction
Note: During integration testing, Merchant Services may test the EMV POS Solution’s support of both the
“PIN Preferring” and “Credit / Debit” selection methods. Please check with your Implementation Manager
to determine if this is a requirement for your implementation.
US Debit Routing
This section describes how to perform Application Selection for EMV US Debit so that the routing choice
of the merchant is retained, and the expected cardholder verification is performed based on merchant or
cardholder preferences.
The following assumptions have been made when describing the Application Selection process for US
Debit:
• Solutions supporting US Debit should have the following kernel configuration:
o All CVM Config. Terminal Capabilities (Tag 9F33) is set to support all CVMs the
merchant wishes to support (e.g. PIN, Signature, NO CVM)
• When using a configurable kernel, the Terminal Type (Tag 9F35) and Additional Terminal
Capabilities (Tag 9F40) values will remain the same regardless of the value used for Terminal
Capabilities (Tag 9F33).
The steps required to manipulate the Candidate List to fully support US Debit are:
1. For each transaction the final amount for the transaction must be known prior to manipulating the
Candidate List.
Page 94
2. Once the final amount is known and the Candidate List is created, the card type will be identified
based on the list of AIDs in the Candidate List. If the:
o Candidate List does not contain any US Common Debit AIDs. This is either an
international or domestic credit card, or an international debit card. In this case, there are
no additional steps required and the application can continue to Final Selection.
o Candidate List contains one or more US Common Debit AIDs. This is a US Debit card.
3. For US Debit cards, the EMV POS Solution must determine which AIDs should remain in the
Candidate List, based on the various options described in the US Debit section. The next
processing step depends on the number of AIDs in the Candidate List. If the:
o Candidate List only contains one AID. Continue to step 4.
o Candidate List contains more than one AID. Perform Final Selection.
4. If the Candidate List contains only the US Common Debit AID, the following should be performed
based on the cardholder verification process supported by the merchant:
o PIN Preferred Merchants. Set the Terminal Capabilities (Tag 9F33) to All CVM Config.
Later during Cardholder Verification, the application will prompt for a PIN.
o Credit / Debit Button Merchants. Prompt the cardholder to select either Credit or Debit.
o Credit Selected: In this case the transaction will be defined as a NO CVM transaction. As
the transaction is over the NO CVM limit, the application should print a signature line on
the receipt.
o Debit Selected. Set the Terminal Capabilities (Tag 9F33) to the All CVM Config and
proceed to the Final Selection step.
CMS EMV BP 00604 When prompting use “No PIN” / “PIN” rather than “Credit” / “Debit”
• Merchant Services recommends that when using the Cardholder Selection method, the
cardholder be presented a “No PIN” / “PIN” prompt rather than the traditional “Credit” / “Debit”
prompt.
CMS EMV BP 00605 PIN Preferring and Credit / Debit selection methods should be supported
• Merchant Services recommends that EMV POS Solutions support both the “PIN Preferring” and
“Credit / Debit” selections methods.
Page 95
US Common Debit Processing Flowchart
Final Selection
Once the Candidate List has been built and US Common Debit processing has been performed, Final
Selection can begin. During this process the AID to be used for the transaction is selected.
If the Candidate List only contains one application it is automatically selected, Final Selection ends and
Cardholder Application Confirmation is performed.
If the Candidate List contains two or more mutually supported applications (AIDs), the application list
should be presented to the cardholder for selection.
Page 96
When presenting Candidate List for selection, the application names may be displayed all on one screen
or with one application name per screen, using navigation buttons to traverse the list (e.g. ‘Next’ and
‘Previous’). Regardless of the method used to display the Candidate List, the application names displayed
are determined as follows:
1. Display Application Preferred Name (Tag 9F12) if it is stored in a character set supported by the
display. This can be determined by checking Issuer Code Table Index (Tag 9F11). A value of “1”
indicates that the Application Preferred Name is encoded using the Latin character set (i.e.
contains standard English alphabetic characters).
2. Display Application Label (Tag 50) if the Application Preferred Name is not present or cannot be
displayed.
3. If the Application Preferred Name and Application Label are not present or cannot be displayed,
display a default application name assigned to the AID by the EMV POS Solution.
Once the application has been chosen, the kernel may relay the application information back to the
payment application so the following can be performed:
• Set the Terminal Capabilities (Tag 9F33). This will be based on the NO CVM limit set for the AID
selected (either the All CVM Config or the NO CVM Only Config). If the:
o Transaction is over the NO CVM limit. Select the All CVM Config
o Transaction is under the NO CVM limit. Select the NO CVM Only Config
The kernel can now select the card AID and Final Selection ends.
Note: In some implementations, it may not be feasible to perform cardholder Application Selection. For
these implementations an EMV transaction should not be performed if the chip card contains multiple
applications unless there is a method to inform the cardholder which application is being used.
Note: Brand certification will test that up to five mutually supported applications can be supported in the
Candidate List.
CMS EMV BP 00606 A default application name should be assigned for all AIDs
• Merchant Services recommends that a default application name be assigned to each supported
AID. These names will be used to display and print the application name when Application
Preferred Name (Tag 9F12) and Application Label (Tag 50) are not present or cannot be used.
Page 97
CMS EMV RQ 00626 Final Selection application names must be displayed to cardholder
• It is required that the list of application names displayed during Final Selection be displayed to the
cardholder.
Cardholder Application Confirmation

Cardholder Application Confirmation is only required when the Candidate List contains only one AID and
the Application Priority Indicator - Cardholder Approval Indicator (Tag 87 bit-8) is set to ‘1’.
If cardholder confirmation is required, the cardholder must be prompted to confirm that the application
may be used. To do this, Application Preferred Name (Tag 9F12) or Application Label (Tag 50) is
displayed to the cardholder who must confirm the selection.
Cardholder Approval Indicator (Tag 87 bit-8)
Value Action
1 The EMV POS Solution must request confirmation from the cardholder before using the
application for the transaction.
If the cardholder declines, the transaction must be cancelled.
0 The application may be used without prompting the cardholder.
CMS EMV RQ 00627 Transaction must be cancelled if Cardholder Application Confirmation fails
• It is required that the transaction be cancelled if during Cardholder Application Confirmation the
cardholder indicates that the application should not be used.
Note: There is currently no requirement to perform Cardholder Application Confirmation at unattended

EMV implementations.
Read Data Records

After the AID has been selected AID card data is read from the chip. During the Read Data record
processing the card data must be validated. If any of the validation checks fail, the card should be
rejected, and the transaction should be terminated.
When performing this validation any field padding (e.g. hex ‘F’) should be stripped before the check is
performed.
Page 98
CMS EMV RQ 00628 Application Expiration Date must match Track 2 Equivalent Data Expiry
Date
• It is required that the Application Expiration Date (Tag 5F24) be the same as the Expiry Date
included as part of Track 2 Equivalent Data (Tag 57). If they are different the card must be
rejected.
CMS EMV RQ 00629 Service Code must not be validated against Track 2 Equivalent Data
• It is required that the Service Code (Tag 9F30) not be validated against the Service Code
included as part of the Track 2 Equivalent Data (Tag 57).
Cardholder Language Selection

Cardholder Language Selection is only performed if the EMV POS Solution supports more than one
language. If required, it is performed after the card has been presented and the AID has been selected.
Cardholder Language Selection is performed by reading Language Preference (Tag 5F2D) from the card
and comparing it to the languages supported by the EMV POS Solution.
• If there is only one common language, it should be used.
• If there are multiple common languages, the language with the highest preference based on the
order the languages are listed in the Language Preference tag should be used.
• If none of the languages in the Language Preference tag are supported by the EMV POS
Solution, the cardholder should be prompted to select one of the EMV POS Solution supported
languages. If the EMV POS Solution only supports one language, it may be auto-selected.
Until the card is presented the EMV POS Solution default language should be used for cardholder display
and prompting.
CMS EMV BP 00607 If multiple languages supported, cardholder should be prompted to select
• Merchant Services recommends that when the EMV POS Solution supports multiple languages
and none of the supported languages matches a language in the Language Preference (Tag
5F2D) list, that the cardholder be prompted to choose one of the EMV POS Solution supported
languages.
CMS EMV RQ 00630 Merchant prompts and receipts must be in default merchant language
Page 99
• Merchant Services requires use of the default merchant language for all merchant prompting and
receipt printing even if the selected cardholder language is different.
CMS EMV RQ 00631 Cardholder prompts and receipts should be in selected cardholder
language
• Once selected, Merchant Services requires all cardholder prompting and receipt printing in the
selected cardholder language.
CMS EMV RQ 00632 If Language Preference Indictor is not present use merchant language
• Merchant Services requires that when Language Preference Indicator (Tag 5F2D) is not present
on the card, that the cardholder be prompted to select one of the languages supported by the
EMV POS Solution. If only one language is supported, it may be auto selected.
Cardholder Prompting
This section outlines the Merchant Services recommended card entry, PIN entry and amount confirmation
prompting. These prompts are not mandated and should be considered as guidelines only.
Card Entry Prompting

During the EMV transaction process there are several steps that require PIN Pad prompting to obtain
cardholder confirmation or provide instructions to the cardholder. This prompting must be performed in
the cardholder language, as determined by the Cardholder Language Selection process.
Merchant Services recommends that the following prompts be used for card entry.
Recommended Card Entry Prompting
Prompt Reason Recommended Prompt Text
Card presentation required “Insert, Tap or Swipe Card”
Inform cardholder not to remove the card “Leave Card Inserted”
Transaction is complete, card should be “Remove Card”

removed
Chip card is swiped with Service Code ‘2xx’ “Use Chip Reader”
or ‘6xx’
Page 100
Chip error (Technical Fallback) “Chip Error, Use Magstripe”
MSR Fallback is initiated “Use Magstripe”
CMS EMV BP 00608 Prompt cardholder to “Leave Card Inserted”
• Merchant Services highly recommends that the prompt informing the cardholder to leave the card
inserted does not include the word “remove”. Doing this often leads to confusion with the remove
card prompt displayed at the end of the transaction, causing the EMV card to be removed
prematurely (i.e. avoid using the prompts such as “Do Not Remove Card”).
PIN Prompting
Several prompts are required during PIN entry to inform the cardholder of the PIN entry status.
Recommended PIN Entry Prompting
PIN entry required “Enter PIN”
Invalid/incorrect PIN entered “Invalid PIN”
Only one PIN try remaining before card is “Last PIN Try”
blocked
PIN tries exceeded and card may be blocked “PIN Tries Exceeded”
Correct PIN entered “PIN Accepted”
Amount Confirmation Prompting

Merchant Services does not require transaction amount confirmation. However, if amount confirmation is
presented and there are multiple amounts requiring confirmation, the amount confirmations should be
combined into a single screen display.
Page 101
Recommended Cardholder Amount Confirmation
Amount Confirmation Prompt 4-Line Display
Amount confirmation only Amount $xxxx.xx
OK?
Cashback only Amount $xxxx.xx
(for multi-line displays can be added to amount Cashback $xxxx.xx

confirmation)
Total $xxxx.xx
OK?
Tip confirmation only Amount $xxxx.xx
Tip $xxxx.xx
Total $xxxx.xx
OK?
Cashback and Tip confirmation Amount $xxxx.xx
Cashback $xxxx.xx
Tip $xxxx.xx
Total $xxxx.xx
OK?
Processing Restrictions
Processing Restrictions must be performed to determine if the transaction should be allowed. Failure of
any check does not result in the transaction be cancelled. The failed result is logged in the Terminal
Verification Results (TVR) and Processing Restrictions continues.
Processing Restrictions includes the following checks:
• That the effective date for the card has been reached
• That the card has not expired
• That the application versions of the EMV chip and application match
Page 102
• If all Application Usage Control (Tag 9F07) restrictions are in effect
Note: An Issuer may use Application Usage Control (Tag 9F07) to restrict a card’s use for domestic or
international transactions; as well as cash, goods, services, or cashback.
Processing Restrictions Steps

The Processing Restrictions steps involve comparing data read from the EMV chip with data resident in
the EMV POS Solution. Depending on the PIN Pad capabilities, this step may be performed by the kernel
or the EMV POS Solution. Please refer to the EMV PIN Pad specification to determine your PIN Pad
capabilities.
The Processing Restrictions steps are as follows:
1. Check Card Application Version Number (Tag 9F08) to ensure it matches one of the application
versions supported by the kernel. Some kernels support a primary and a secondary application
version number and others support just the primary version. The table below shows the
Application Version Numbers currently supported for each brand.
Card Brand Application Version Numbers
Card Brand Primary Version Secondary Version
Amex 0x0001
Debit Network Alliance 0x0001
Diners 0x0001
Discover 0x0001
UnionPay via Discover 0x0020
Interac 0x0001
JCB 0x0200 0x0120
Mastercard 0x0002
Visa 0x008C 0x0096
Page 103
2. Verify that the type of transaction (POS, cash advance, purchase, cashback) is in domestic or
international mode and is compatible with the card’s Application Usage Control. The Application
Usage Control (Tag 9F07) bits are checked as follows:
Valid at EMV POS Solutions other than ATMs (Byte-1 bit-1) must be ‘1’
Valid for domestic use:
i. Issuer Country Code (Tag 5F28) = Terminal Country Code (Tag 9F1A)
ii. Goods and Services (Byte-1 bit-6, Byte-1 bit-4) must be ‘1’
Valid for international use:
iii. Issuer Country Code (Tag 5F28) ≠ Terminal Country Code (Tag 9F1A)
iv. Goods and Services (Byte-1 bit-7, Byte-1 bit-5) must be ‘1’
3. Verify that Application Effective Date (Tag 5F25) is on or before the current date.
4. Verify that Application Expiration Date (Tag 5F24) is after the current date.
The results of these tests are stored in the Terminal Verification Results (Tag 95).
CMS EMV RQ 00633 AID list must be supported with associated Application Version Numbers
• It is required that the EMV POS Solution maintains a list of supported AIDs and corresponding
Application Version Numbers.
Offline Card Authentication

Offline Card Authentication is performed between the EMV chip and the kernel to ensure that the EMV
chip is valid.
This EMV transaction step may or may not be performed automatically by the kernel (i.e. without being
requested to do so by the EMV POS Solution). Please refer to the PIN Pad EMV specification to
determine how this function is performed.
Offline Card Authentication Methods

EMV defines three offline Card Authentication Methods (CAM). All three methods use Certificate of
Authority Public Key (CAPK) technology to protect against card counterfeiting and / or card skimming.
Page 104
• Static Data Authentication (SDA). Comparable to CVV checking on magstripe transactions as it

detects alterations of selected static data elements after personalization. SDA differs from CVV in
that it is performed offline by the PIN Pad.
• Dynamic Data Authentication (DDA). Has all the benefits of SDA and additionally protects
against copying of chip data by generating a dynamic signature for each transaction.
• Combined DDA/Application Cryptogram Generation (CDA). Has all the benefits of DDA and
additionally assures that the transaction data is not altered between the card and kernel, by
including transaction data as part of the DDA calculation.
CMS EMV RQ 00634 All Offline CAM failures must be sent for online authorization
• Merchant Services requires that the TAC settings have each of the offline CAM failure TVR bits
set to ensure the transaction is selected for online authorization.
CMS EMV RQ 00635 If offline CAM is not performed transaction must go online
• Merchant Services requires that the TAC settings ensure that the transaction is sent for online
authorization when offline CAM is not performed and there is no other reason to offline decline
the transaction.
CMS EMV RQ 00636 All Offline Card Authentication Methods must be supported
• Merchant Services requires that all three offline Cardholder Authentication Methods be supported
(SDA, DDA and CDA).
Cardholder Verification
Cardholder Verification is used to ensure that the cardholder is legitimate and that the card has not been
lost or stolen. The kernel uses the Cardholder Verification Method (CVM) List from the card to determine
the type of verification to be performed (e.g. Signature or PIN). The CVM List establishes a CVM priority
to be used relative to the capabilities of the PIN Pad and characteristics of the transaction.
If the card does not support CVM processing or if NO CVM is selected, the EMV POS Solution must
perform the cardholder verification as specified for magstripe transactions:
• Signature for attended devices
• NO CVM for unattended devices
Page 105
Note: Visa recommends merchants retain CVM information for 180 days to assist in chargeback
resolution.
Merchant Services EMV Processing Guidelines Update

When processing a transaction using EMV Chip technologies, Merchant Services merchants and
integrators must code terminal applications in accordance with EMVCo specifications and in compliance
with Card Brand requirements. The following clarifications will ensure that US Debit processing will flow
correctly through the Merchant Services host systems when processing via EMV Chip.
Credit and Debit Transaction Options for Each Supported AID
To ensure that EMV transactions are submitted to the credit card brands or debit networks properly, the
following mapping must be applied to choose the type of Merchant Services transaction to submit when a
particular AID is selected following normal EMV processing rules.
Credit and Debit Transaction Options for Each Supported AID
AID Brand US Merchant Canadian EU

Transaction Type Merchant Merchant
Transacti Transacti
on Type on Type
A00000002501 American Express Credit Credit Credit
A00000033301 UnionPay via Discover Credit Credit Credit Credit

0102
A00000033301 UnionPay via Discover Debit US Debit n/a Credit

0101
A00000033301 UnionPay via Discover Quasi Credit Credit Credit

0103 Credit
A00000033301 UnionPay via Discover US US Debit n/a n/a

0108 Common
A00000015230 Discover Global Credit Credit Credit

10
Page 106

Transacti Transacti
on Type on Type
A00000015240 Discover US Common Debit US Debit n/a n/a

10
A00000062006 DNA US Shared Debit US Debit n/a n/a

20
A00000027710 Interac US Debit n/a Canadian n/a

10 Debit
A00000000330 Interlink Global Debit Credit Credit

10
A00000006510 JCB Credit Credit Credit

10
A00000000422 Maestro Common Debit US Debit n/a n/a

03
A00000000430 Maestro Global Debit Canadian Credit

60 Debit
A00000000410 Mastercard Global Credit Credit Credit

10
A00000000320 Visa Electron Credit Credit Credit

10
A00000000310 Visa Global Credit Credit Credit

10
A00000009808 Visa US Common Debit US Debit n/a n/a

40
A00000000499 Voyager Credit n/a n/a

99
Page 107

Transacti Transacti
on Type on Type
A00000076810 Wright Express Credit n/a n/a

10
The Transaction Type refers to the host message to formulate and the appropriate PNS ISO Processing
Code, UTF Transaction Code or Stratus MOP Code that must be used.
Merchant Services Transaction Type Mapping to Hosts
Transaction Tandem PNS ISO Bit Tandem UTF Stratus Online Method of Payment
Type 3 Processing Code Transaction Code (MOP) Code
From Account
Values
US Debit 92 21,22,24,25,26, 46, CX, DE

92
Canadian 97 27, 28, 29, 30, 31, n/a. Canadian Debit processes only to
Debit 32, 33, 38, 39, 48, the Tandem Front End
44, 45, 47, 49, 92
Credit 91 01, 02, 03, 06, 07, AX, CR, CZ, DD, DI, IM, JC, MC, MR,
09, 16, 17, 41, 46, VI, or VR
91
CVM Limits for each supported AID
A merchant’s or integrator’s terminal application must allow for maintenance of unique configuration
values for each AID that they support. Among those unique configuration values, the CVM Limit that
applies for a given AID must be supported. At this time, the values set for the US Debit AIDs shown
above must be set to zero. When a chip read presents a No CVM Method, follow the EMV CVM List
processing rules which state the CVM Limit of zero must be considered resulting in a failure of that CVM
Method. By requiring this configuration, Merchant Services prevents issues that could occur from sending
a transaction without PIN data to a Debit network that cannot support it.
Page 108
US EMV Debit PIN Bypass
PIN Bypass is a concept of allowing the cardholder to exit from a PIN prompt and continue with an EMV
transaction. While this practice is encouraged to allow cardholders to complete transactions in the US
market where PIN entry on Credit transactions is new, this is not applicable to US Debit transactions.
If a terminal is processing a transaction with a US Common Debit AID and the cardholder chooses to
bypass PIN entry, one of two actions can be performed by the point-of-sale:
• Restart the EMV transaction to select a Global AID and format a Credit Type transaction to the
Merchant Services host
o The PIN Pad should display a message acknowledging the PIN Bypass choice and
prompting for the cardholder to choose to continue as Credit (or displaying the Global
AID preferred name or label) or exit.
o The format of this transaction mirrors the “Signature Debit” Credit processing that is
commonly done for Magnetic Stripe, except the transaction includes defined EMV
parameters
o Selection of a Global AID will present a broader CVM List that will include non-PIN
methods that are fully supported in Credit type transactions. This option is highly
recommended by Merchant Services.
• Optionally, continue to use the selected US Common Debit AID, but reformat the EMV
transaction from ‘Debit’ to ‘Credit’ before submitting the request to the Merchant Services host
o The PIN Pad should display a message acknowledging the PIN Bypass choice and
prompting for the cardholder to choose to continue as Credit or exit.
o The format of this transaction mirrors the “Signature Debit” Credit processing that is
commonly done for Magnetic Stripe, except the transaction includes defined EMV
parameters
Page 109
Supported Cardholder Verification Methods (CVM)

Cardholder Verification Methods
CVM Description
Offline Plaintext The PIN Pad prompts the cardholder for a PIN and transmits the cardholder-
entered PIN to the card in the clear. The card then compares the cardholder-
(also known as
entered PIN to the Reference PIN stored secretly in the chip.
Clear Text PIN)
Offline The PIN Pad prompts the cardholder for a PIN, encrypts it with public key
Enciphered PIN technology and sends it to the card, where it is card decrypted. The card then
compares the cardholder-entered PIN to the Reference PIN stored secretly in the
chip.
Online PIN The PIN Pad prompts the cardholder for a PIN and encrypts it using the same
DUKPT key used for magstripe debit PIN encryption. The encrypted PIN block is
sent to the host in the online authorization message.
Signature This method is optionally supported and operates in the same manner as in the
magstripe environment. The cardholder signs the transaction receipt and the
merchant compares this signature to the signature on the card.
NO CVM This method operates in the same manner as in the magstripe environment where
transaction authorization is independent of cardholder verification.
No cardholder verification is currently supported in some merchant environments,

such as certain unattended environments, quick service restaurants and other
small ticket environments. For attended environments, signature is required.
The EMV POS Solution should use CVM Results (Tag 9F34) to determine if a signature line is required
on the receipt. For more information on receipt CVM requirements see EMV Receipt Guidelines section.
Note: A failed CVM does not mean that the transaction has failed or is declined. The CVM failure is
logged in the Cardholder Verification Results (CVR) and forwarded along with the Terminal Verification
Results (TVR) to the host during online authorization.
CMS EMV BP 00609 PIN CVM is not required
Page 110
• Merchant Services recommends that the choice of which Cardholder Verification Methods (Online
PIN, Offline Plaintext PIN, Offline Enciphered PIN, Signature and NO CVM) to support is carefully
considered and weighed against business needs, environment, and risk factors.
CMS EMV BP 00610 Allow opportunity for cardholders who don’t know their PIN to continue
with the transaction
• Merchant Services recommends some form of PIN Bypass be utilized to allow the transaction to
continue in the event the cardholder does not know (or prefers not to enter) their PIN.
CMS EMV RQ 00637 If PIN CVM is supported then both Online and Offline PIN must be
supported
• Merchant Services requires that both Online and Offline PIN CVM be supported when choosing
to support PIN.
CMS EMV RQ 00639 NO CVM must be supported for unattended solutions with no PIN Pad
• Merchant Services requires that unattended EMV POS Solutions with no PIN Pad support NO
CVM.
PIN Prompting
PIN CVM is not required by Merchant Services. If the EMV POS Solution supports PIN prompting, several
rules must be followed:
1. The prompt text displayed for offline and online PIN entry should be identical
2. PIN Bypass is strongly encouraged
3. The PIN Try Counter (Tag 9F17) value must be obtained before Offline PIN entry begins and its
value must be used as the maximum number of PIN attempts allowed
4. The cardholder must be notified before the last Offline PIN attempt and when the card is blocked
because the maximum Offline PIN tries have been exceeded
5. Both online and offline PIN must be supported
Note: The PIN Try Counter (Tag 9F17) is reset every time a valid Offline PIN is entered.
CMS EMV RQ 00640 Maximum number of PIN tries must not exceed PIN Try Counter (Tag 9F17)
Page 111
• It is required that the number of Offline PIN tries allowed does not exceed the initial PIN Try
Counter (Tag 9F17) value.
CMS EMV RQ 00641 Cardholder must be notified of last offline PIN attempt
• It is required that the cardholder be notified when only one invalid Offline PIN attempt remains
before the card is blocked.
CMS EMV RQ 00642 Cardholder must be notified when maximum Offline PIN tries is exceeded
• It is required that the cardholder be notified when the Offline PIN tries have been exceeded.
CVM Results Validation (Tag 9F34)

The following details how the CVM result is interpreted.
(CVM) Cardholder Verification Method Results (Tag 9F34) Byte 1
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
x x 0 0 0 0 0 0 Fail CVM processing
x x 0 0 0 0 0 1 Plaintext PIN verification performed by card
x x 0 0 0 0 1 0 Enciphered PIN verified online
x x 0 0 0 0 1 1 Plaintext PIN verification performed by card and signature

(paper)
x x 0 0 0 1 0 0 Enciphered PIN verification performed by card
x x 0 0 0 1 0 1 Enciphered PIN verification performed by card and signature

(paper)
x x 0 1 1 1 1 0 Signature (paper)
x x 0 1 1 1 1 1 NO CVM
Value Meaning
00-09 Ignore this byte
Page 112
Value Meaning
00 Unknown (e.g. for signature)
01 Failed (e.g. Offline PIN)
02 Successful (e.g. Offline PIN)
Terminal Risk Management

Terminal Risk Management is always performed by the kernel regardless of the setting of the ‘Terminal
Risk Management Is To Be Performed’ bit in the Application Interchange Profile (Tag 82 Byte-1 bit-4).
Risk Management Requirements
Type Requirement Usage
EMV Floor Limit Mandatory Required for all EMV POS Solutions.
Checking
Performed by the EMV kernel.
Random Transaction Mandatory Required for EMV POS Solutions capable of both offline and
Selection online transactions.
Transaction Velocity Mandatory Required for EMV POS Solutions capable of offline
Checking transactions. Checks if the card’s consecutive offline
transaction or cumulative offline spend limit has been
exceeded.
New Card Verification Mandatory Required for EMV POS Solutions capable of offline
transactions.
The following EMV Risk Management parameters control the EMV 1st Generate AC offline approval
process. These parameters are described in more detail in the following sections:
• EMV Floor Limit. Defines the maximum transaction amount that can be approved offline at the
1st Generate AC
Page 113
• EMV Random Selection. Defines values used to force transactions online even if the transaction
amount is below the EMV Floor Limit
CMS EMV BP 00611 Terminal Risk Management features should be supported
• Merchant Services recommends that all EMV Terminal Risk Management features be supported
regardless of the offline capabilities of the terminal.
EMV Floor Limit

For a transaction to be approved offline by the chip the EMV Floor Limit must be greater than zero. Each
card scheme has defined a maximum EMV Floor Limit that can be used for each Merchant Category
Code. For deployed production implementations the Merchant Services host download will optionally
return a PNS/ISO Bit 48 Subtag P6 or UTF Token FL with a floor limit that should override any current
setting of floor limit on the device. When a value is not returned in the host download, the device must be
set to the default zero floor limit.
Only transactions with amounts below the EMV Floor Limit can be approved by the card offline at the 1st
Generate AC. A transaction can also be approved offline at the 2nd Generate AC if the host is
unavailable and the transaction amount is below the EMV Floor Limit.
Note: Even if the transaction amount is below the EMV Floor Limit the card can decline the transaction
offline for other reasons.
CMS EMV RQ 00643 Floor Limit must be set to zero
• Merchant Services requires that the EMV Floor Limit be set to zero. Therefore, the production
Merchant Services host download used by deployed EMV POS Solutions, will optionally return a
Floor Limit record to set in a device. When no Floor Limit record is returned in the host download,
the device should default to a zero value.
CMS EMV RQ 00644 Non-zero EMV Floor Limits must be supported
• Merchant Services requires that all EMV POS Solutions be capable of supporting a non-zero
EMV Floor Limit. This capability will be tested during EMV integration testing to future proof the
EMV POS Solution in case Merchant Services begins to support non-zero EMV Floor limits in the
future.
Page 114
EMV Random Selection

EMV Risk Management parameters can be set to ensure that all transactions are “Randomly Selected to
Go Online” at the 1st Generate AC, even if the transaction amount is below the EMV Floor Limit. The
following values should be used for this purpose.
Random Selection Values
Parameter Value
Target Percentage to be used for Random Selection 99%
Maximum Target Percentage to be used for Biased Random 99%

Selection
Threshold Value for Biased Random Selection 0
Note: Most kernels interpret 99% as being 100% but that should be confirmed with your PIN Pad vendor.
CMS EMV RQ 00645 Random Selection parameters must ensure transaction is attempted
• Merchant Services recommends that the Target Percentage, Maximum Target Percentage and
Threshold for Biased Random Selection values be set to ensure transactions are always selected
to go online.
Data Object Lists

There are several Data Object Lists (DOL) used by the chip during transaction processing. Each DOL is
stored on the chip and contains one or more EMV tag number and length pairs identifying tag data that
should be used for specific functions. The Data Object Lists currently supported are:
• Card Risk Management Data Object List 1 (CDOL1) (Tag 8C). List of data objects (tag and
length) to be passed to the card in the first GENERATE AC command
• Card Risk Management Data Object List 2 (CDOL2) (Tag 8D). List of data objects (tag and
length) to be passed to the card in the second GENERATE AC command
• Dynamic Data Object List (DDOL) (Tag 9F49). List of data objects (tag and length) to be
passed to the chip in the INTERNAL AUTHENTICATE command
Page 115
• Processing Options Data Object List (PDOL) (Tag 9F38). List of terminal-related data objects
(tag and length), requested by the card and transmitted to the card in the GET PROCESSING
OPTIONS command
• Transaction Certificate Data Object List (TDOL) (Tag 97). List of data objects (tag and length)
to be used by the EMV POS Solution to generate the TC Hash Value
Dynamic Data Object List (DDOL)

The DDOL (Tag 9F49) is stored on the card and contains the list of data objects (tag and length) to be
passed in the INTERNAL AUTHENTICATE command. However, in some cases the chip does not contain
a DDOL. Therefore, if the EMV POS Solution supports DDA, a Default DDOL must be defined that can be
used when the chip DDOL is not present.
CMS EMV RQ 00646 A Default DDOL is required for EMV POS Solutions that support DDA
• Merchant Services requires that EMV POS Solutions supporting DDA, have a Default DDOL
defined that can be used when the chip does not contain a DDOL. The default DDOL must
contain Unpredictable Number (Tag 9F37) only.
Transaction Certificate Data Object List (TDOL)

The TDOL (Tag 97) is stored on the chip and contains the list of data objects (tag and length) to be used
by the EMV application to generate the TC Hash value. In some cases, the chip does not contain a
TDOL. Therefore, the EMV POS Solution should have a Default TDOL defined that can be used when the
chip TDOL is not present.
CMS EMV RQ 00647 The Visa Default TDOL (if used) must include Transaction Amount only
• Merchant Services requires that when the EMV POS Solution supports a Default TDOL for Visa
that includes Transaction Amount (Tag 9F02) only.
CMS EMV RQ 00648 The Mastercard Default TDOL (if used) must include multiple tags
• Merchant Services requires that when the EMV POS Solution supports a Default TDOL for
Mastercard that contains the Transaction Amount (Tag 9F02), Currency Code (Tag 5F2A),
Transaction Date (Tag 9A), Transaction Type (Tag 9C), TVR Results (Tag 95) and Unpredictable
Number (Tag 9F37) only.
Page 116
Processing Data Object List (PDOL)

The PDOL (Tag 9F38) list sometimes contains the Transaction Amount (Tag 9F02). Therefore, it is
mandatory that the Transaction Amount (Tag 9F02) be set to the total transaction amount before the Get
Processing Options step is performed.
Terminal Action Analysis

In Terminal Action Analysis the kernel makes its authorization recommendation. This is done by
comparing three data objects:
• Issuer Action Codes (IACs). Rules set by the issuer in the card
• Terminal Action Codes (TACs). Rules set by the payment system in the kernel
• Terminal Verification Results (TVR). Contains the current transaction results generated by the
Processing Restrictions, Offline Data Authentication, Cardholder Verification and Terminal Risk
Management steps
The IACs and TACs are applied against the results stored (bits set) in the TVR to determine if the
transaction should be approved offline, declined offline or sent online for an authorization.
The results from Terminal Action Analysis will determine the cryptogram to be requested by the kernel
from the card in the 1st Generate AC.
CMS EMV RQ 00649 Do not set kernel to force transactions online
• Merchant Services requires that the EMV POS Solution not enable/use the kernel “force online”
feature to force transactions to go online. Using this kernel feature results in the TVR Merchant
Forced Online bit (Byte-3 bit-4) to be set indicating a suspicious transaction.
Issuer Action Codes (IACs)

There are three IAC data elements personalized on the card by the issuer. The IACs consist of a series of
bits with each bit corresponding to a bit in the Terminal Verification Results (TVR).
When an IAC bit and the corresponding TVR bit are both set to ‘1’, the action specified by the IAC is
taken. There are three possible actions: decline offline, go online for an authorization, and decline offline
if online authorization is unable to complete:
Page 117
• IAC-Denial (Tag 9F0E). The issuer sets the IAC bits to ‘1’ that correspond to the TVR bits for
conditions which the issuer wants to result in a 1st Generate AC offline decline.
• IAC-Online (Tag 9F0F). The issuer sets the bits to ‘1’ that correspond to the TVR bits for
conditions which the issuer wants to result in the 1st Generate AC requesting an online
authorization.
• IAC-Default (Tag 9F0D). The issuer sets the bits to ‘1’ that correspond to the TVR bits for
conditions which the issuer wants to result in a 2nd Generate AC decline when online processing
was requested but was not possible.
Terminal Action Codes (TACs)

The TACs are three data elements set by the card scheme and loaded as parameters by the EMV POS
Solution. The TACs consist of a series of bits with each bit corresponding to a bit in the Terminal
Verification Results (TVR) (Tag 95).
When a TAC bit and the corresponding TVR bit are both set to ‘1’, the action specified by the TAC is
taken. There are three possible actions: decline offline; go online for an authorization; decline offline if
online authorization is unable to complete.
The three TACs defined by the card schemes are:
• TAC-Denial. The card scheme sets the TAC bits to ‘1’ that correspond to TVR bits for conditions
which the card scheme wants to result in a 1st Generate AC offline decline.
• TAC-Online. The card scheme sets the bits to ‘1’ that correspond to TVR bits for conditions
which the card scheme wants to result in the 1st Generate AC requesting an online authorization.
• TAC-Default. The card scheme sets the bits to ‘1’ that correspond to the TVR bits for conditions
which the card scheme wants to result in a 2nd Generate AC decline when online processing was
requested but was not possible.
1st Generate Application Cryptogram

The 1st Generate AC consists of two steps. The first step is performed by the kernel to request the
Generate AC. The second step is performed by the card and results in the Generate AC response.
1. Terminal Action Analysis. The kernel makes an authorization recommendation and then sends
a GENERATE AC command to the card with this recommendation
Page 118
2. Card Action Analysis. The card makes the initial authorization decision to; offline approve,
offline decline or request online authorization, and then returns the decision to the EMV kernel
Terminal Action Analysis

In Terminal Action Analysis the kernel analyzes the IAC, TAC and TVR values and sends a GENERATE
AC command requesting the card return an Application Cryptogram with its offline authorization decision.
This 1st Generate AC command must:
1. Specify whether a CDA signature is requested
2. Indicate the type of Application Cryptogram being requested based on the kernel’s preliminary
authorization decision:
AAC. Decline the transaction (this is generally used to terminate chip interaction for Partial EMV
transactions. e.g. Credit Return (Offline) after card data has been obtained)
ARQC. Process the transaction online (this is recommended by Merchant Services)
TC. Approve the transaction offline
3. Provide the transaction data required by the card to perform Card Risk Management
4. Provide transaction data required to calculate the Application Cryptogram (data required by the
chip is specified by CDOL1 (Tag 8C) retrieved from the chip during Read Data Records).
Card Action Analysis

The EMV card performs Card Action Analysis and responds with one of three possible decisions based
on the type of cryptogram requested in the 1st Generate AC command. This decision is returned in
Cryptogram Information Data (CID) (Tag 9F27):
1. AAC (Decline CID=00) Requested, card must respond with:
AAC. Declined
2. ARQC (Online authorization CID=80/90) Requested, card may respond with either:
ARQC. Go Online (online issuer authorization required)
AAC. Declined
Page 119
3. TC (Approval CID=40/50) Requested, card may respond with any of the following:
TC. Approved
ARQC. Online Authorization Required
AAC. Declined
Note: The Application Cryptogram returned by the card will always be the same or more restrictive than
the Application Cryptogram requested. For example, if the GENERATE AC command requests that the
transaction go online for authorization (requests an ARQC), the chip will either agree (return an ARQC) or
decline the transaction (return an AAC). The chip cannot offline approve the transaction (i.e. returns a
TC).
EMV Offline Approvals

*NOTE* Merchant Services does not support any offline transaction processing in the US EMV Floor
Limits are typically set to $0 in the EMV parameter downloads. However, if EMV offline processing is
desired, this section outlines the processing steps to be taken.
EMV transactions can be approved offline by the chip at the 1st Generate AC or at the 2nd Generate AC
when the host is unavailable. In both cases the transaction amount must be below the EMV Floor Limit.
When a transaction is offline approved by the card (without host authorization), the card returns a final
cryptogram called the Transaction Certificate (TC) and the EMV POS Solution should:
1. Set the Authorization Response Code (Tag 8A) to ‘Y1’.
2. Store the cryptogram (TC) and Approval Code in the batch with the transaction details.
3. Send the transaction (including the TC) to the host prior to or at settlement.
Note: The final card decision is reflected in the Cryptogram Information Data and not in the Authorization
Response Code.
The following table shows the Authorization Response Code (Tag 8A) values used when processing
offline transactions.
Page 120
Authorization Response Code Values
Authorization Response Code Value
Offline approved Y1
Offline declined Z1
Unable to go online, offline approved Y3
Unable to go online, offline declined Z3
CMS EMV BP 00612 Generated Offline approval codes should be in the format “E999999”
• Merchant Services recommends offline approval codes generated by the EMV POS Solution
begin with an ‘E’ followed by six digits.
Offline Transaction Upload

Prior to performing Settlement, all offline approved transactions must be uploaded to the host. Uploading
offline approved transactions may be done using the same process used for traditional magstripe
transactions with the exception that EMV tags must be included as part of the transaction data.
For host capture implementations the offline approved transactions must be sent to the host individually
or in a transaction batch using a capture request message.
For a list of EMV tags that must be uploaded with offline approved transactions see Settlement EMV Tags
section.
Online Response Processing

When a transaction is sent online for authorization the host will return several data elements required by
the card for 2nd Generate AC, External Authenticate and script processing (Full EMV transactions only).
This applies to both host approved and declined transactions.
The data elements required by the card to complete an online transaction are:
• Authorization Response Code (Tag 8A). If this is not returned by the Merchant Services host it
must be set based on the host response code.
Page 121
Host Decision ASCII Hex
Approved 00 0x3030
Declined 05 0x3035
• Issuer Authentication Data (Tag 91). Used for External Authenticate (see EMV Offline
Approvals section) - as returned in the host response message
• Issuer Scripts (Tag 71 or Tag 72). Script commands are forwarded to the card by the EMV
kernel for execution - as returned in the host response message
The card will return one of the following in the 2nd Generate AC response:
• TC (CID=40/50). The transaction was approved
• AAC (CID=00). The transaction was declined (If the transaction was originally approved by the
issuer, a Reversal must be sent to the host)
Note: A maximum of one Issuer Script will be returned in a Merchant Services host response message. A
host response message will never contain both Tag 71 and Tag 72.
CMS EMV RQ 00651 Authorization Response Code must be set based on host Response Code
• Merchant Services requires that when the Authorization Response Code (Tag 8A) is not present
in the host response message, it be set by the EMV POS Solution based on the host response
code returned in host response message. This must be done before the 2nd Generate AC is
performed.
CMS EMV RQ 00652 Issuer Scripts must be supported in host responses
• It is required that the EMV POS Solution be capable of extracting an Issuer Script from the host
response message and forwarding it to the EMV kernel for execution by the card.
Partial Authorizations
It is possible for the host to partially approve a transaction for an amount less than the amount requested.
When this occurs, the cardholder must be prompted to accept the lower authorization amount before the
External Authenticate or 2nd Generate AC processing is performed.
If the cardholder does not approve the authorized amount, the cardholder should be prompted to remove
the card, a host reversal should be sent, and the transaction should be cancelled.
Page 122
If the cardholder wishes to continue the transaction using the lower amount the EMV POS Solution must:
1. Store the lower authorized amount in Transaction Amount (Tag 9F02) and make sure it is
updated in the EMV kernel
2. Set Authorization Response Code (Tag 8A) = 0x3030 to indicate the transaction was approved
3. Perform an External Authenticate (if required)
4. Perform a 2nd Generate AC
The transaction is now complete, and the receipt should be printed using the updated Transaction
Amount (Tag 9F02).
CMS EMV RQ 00653 Reversal must be sent if cardholder declines partial authorization
• Merchant Services requires that a host Reversal message be sent for a Partial Authorization
when the cardholder declines to continue the transaction using the lower authorized amount. In
this case the EMV POS Solution must set the Authorization Response Code (Tag 8A) to 0x3035,
request a decline (AAC) at the 2nd Generate AC and send a Reversal message to the Merchant
Services host.
CMS EMV RQ 00654 Transaction Amount (Tag 9F02) must reflect the partially authorized
amount
• It is required for Partial Authorizations where the lower authorized amount is accepted by the
cardholder, that Transaction Amount (Tag 9F02) be updated to reflect the lower authorized
amount and sent to the kernel prior to the 2nd Generate AC.
CMS EMV RQ 00655 Partially authorized amount must be sent in the settlement message
• Merchant Services requires that Partial Approval settlement messages include the lower partially
authorized amount in Transaction (Tag 9F02).
Referrals
Merchant Services host returns a Referral response when additional information is required, and a voice
authorization should be attempted. When this occurs, the current transaction must be cancelled. If the
voice authorization is successful another transaction can be processed to obtain the funds.
CMS EMV RQ 00656 Referral transactions must be declined
Page 123
• Merchant Services requires that when a Referral response is received, that the transaction be
declined by requesting a Decline (AAC) at the 2nd Generate AC.
External Authenticate
External Authenticate is used to validate that Issuer Authentication Data (Tag 91), included in an issuer
authorization response message, is valid and was created by the issuer.
An EXTERNAL AUTHENTICATE command must be sent to the card when the host response includes
Issuer Authentication Data (Tag 91) and the Application Interchange Profile (Tag 82) indicates that the
chip supports Issuer Authentication (Byte-1 bit-3).
Note: Some cards do not support the EXTERNAL AUTHENTICATE command and will validate the ARPC
as part of the 2nd Generate AC processing. This is managed by the EMV kernel.
2nd Generate Application Cryptogram

The final step of the issuer authorization process (Full EMV transactions only), is for the EMV POS
Solution to send the card a GENERATE AC command requesting the chip to return a final Application
Cryptogram. This is generally referred to as the 2nd Generate AC (or 2nd Gen AC).
The 2nd Generate AC command must:
1. Indicate the type of Application Cryptogram being requested based on the host (or stand-in)
authorization decision:
AAC. Decline the transaction (issuer declined the transaction)
TC. Approve the transaction (issuer approval)
2. Provide the transaction data required to calculate the Application Cryptogram as retrieved from
the chip during the initial Read Application Data processing (data required by the chip is specified
by CDOL2 (Tag 8D))
The EMV chip responds with one of two possible decisions based on the type of cryptogram requested in
the 2nd Generate AC command:
3. AAC (Decline requested), card must respond with:
AAC. Declined
Page 124
4. TC (Approval requested), card may respond with either:
TC. Approved
AAC. Declined
Note: The Application Cryptogram returned by the card will always be the same or more restrictive than
the Application Cryptogram requested by the Generate AC command.
For example, if the 2nd Generate AC command requests that the transaction be declined (requests an
AAC), the chip will always agree (return an AAC). In this case the chip cannot approve the transaction
(return a TC).
Issuer Script Processing

If an Issuer Script is returned in the host response message it must be sent to the EMV kernel for
execution by the card prior to performing the 2nd Generate AC. Tag 71 scripts will be executed before
2nd Generate AC processing begins and Tag 72 scripts will be executed after the 2nd Generate AC
completes.
A host response will never include both Tag 71 and Tag 72 Issuer Scripts. A maximum of one Issuer
Script will be returned in each host response message.
CMS EMV RQ 00657 Issuer Scripts must be executed for approved and declined transactions
• It is required that Issuer Scripts returned in the host response message be sent to the card for
execution, regardless of whether the transaction was approved or declined.
CMS EMV RQ 00658 Must support Issuer Scripts up to 128 bytes in length
• It is required that Issuer Scripts up to 128 bytes in length be supported.
CMS EMV RQ 00659 Handling Issuer Script errors
• It is required that the transaction continues when an error is returned by the kernel during Issuer
Script processing. However, no other issuer commands should be sent to the card. If a Tag 71
Issuer Script returns an error, the application should continue to the 2nd Generate AC command.
Page 125
Transaction Completion Processing

Transaction Completion Processing consists of analyzing the card decision to determine if a host reversal
is required, performing the reversal when required, prompting the cardholder to remove the card, printing
receipts, and storing the transaction data in the transaction batch.
Reversal Processing
There are several additional EMV reversal types that must be supported by the EMV POS Solution in
addition to the standard reversal processing required by traditional magstripe implementations. The
additional reversals are required because Full EMV transactions return the online authorization decision
to the card for final authorization.
EMV reversals are required when the transaction was approved by the host but the EMV POS Solution is
unable to complete 2nd Generate AC. When generating a reversal for an EMV transaction, EMV tags
must be included in the host reversal message. The following table identifies the additional EMV reversal
reasons and whether EMV tag data from the first or second Generate AC is required in the reversal
message.
EMV Reversal Types
Reversal EMV Tags Description

Reason
PIN Pad 1st Generate PIN Pad disconnected or malfunctioning when attempting 2nd
Unavailable AC Generate AC
Transaction 1st Generate Transaction is cancelled by the merchant or cardholder (during

Cancelled AC or after host authorization)
Card Removed 1st Generate Cardholder removed card before 2nd Generate AC completes
AC
Chip Error 1st Generate The card returned an error during 2nd Generate AC or External
AC Authenticate processing indicating the chip is malfunctioning
Note: For a chip malfunction at the 2nd Generate AC,

Mastercard requires that the transaction disposition be based on
the host message authorization decision (Approved/Declined)
Page 126
Reversal EMV Tags Description

Reason
Card Decline 2nd Generate The card declined the host approved transaction at the 2nd
AC Generate AC
CMS EMV RQ 00660 EMV transaction reversals must include EMV tags
• Merchant Services requires that all EMV host reversal messages include tag data from either the
1st or 2nd Generate AC. The list of tags sent must match the original authorization message but
must be updated to include 2nd Generate AC values (if performed).
Card Removal Prompting

When the transaction completes the cardholder should be prompted to remove their card before receipts
are printed.
CMS EMV BP 00613 Do not print receipt until the card has been removed
• Merchant Services recommends that the receipt not be printed until the cardholder has removed
the card. This decreases the incidence of the cardholder forgetting their card.
CMS EMV BP 00614 Sound audible beep while waiting for card to be removed
• Merchant Services recommends that there is an audible beep while waiting for the EMV card to
be removed. This decreases the incidence of the cardholder forgetting their card.
Transaction Storage
At the completion of a transaction EMV tag information must be stored to ensure it is available for
settlement or problem determination and reporting. The table below identifies the EMV tags that should
be stored in the transaction batch.
Transaction Batch EMV Tag Information Required
Tag Tag Name Comment
9F02 Transaction Amount
9F03 Additional Amount
9F26 Application Cryptogram 1st Generate AC value
Page 127
9F26 Application Cryptogram 2nd Generate AC value
4F Application ID
82 Application Interchange Profile
50 Application Label
9F12 Application Preferred Name
9F40 Application Terminal Capabilities
9F36 Application Transaction Counter
9F07 Application Usage Control
9F09 Application Version Number
8A Authorization Response Code Must match the final value from the host
response.
Refer to Chip Processing Guidelines >

Tender Processing > Faster EMV
Transaction Flow for quick chip
requirements.
9F27 Cryptogram Information Data 1st Generate AC value
9F27 Cryptogram Information Data 2nd Generate AC value
9F34 CVM Results
84 Dedicated File Name
5F24 Expiry Date
9F0D IAC Default
9F0E IAC Denial
Page 128
9F0F IAC Online
9F10 Issuer Application Data
91 Issuer Authentication Data
9F11 Issuer Code Table Index
5A PAN Encrypted / Masked / Tokenized
5F34 PAN Sequence Number
9F39 POS Entry Indicator
9F33 Terminal Capabilities
9F1A Terminal Country Code
95 Terminal Verification Results 1st Generate AC value
95 Terminal Verification Results 2nd Generate AC value
9F02 Transaction Amount
5F2A Transaction Currency Code
9A Transaction Date
9F21 Transaction Time
9F35 Terminal Type
9C Transaction Type
9B Transaction Status Indicator Final value
9F37 Unpredictable Number
Note: The table above identifies the EMV tags that should be stored by the EMV POS Solution. This does
not represent the EMV tag information that must be sent to the Merchant Services host.
Page 129
CMS EMV RQ 00661 Last EMV transaction data must be available even if transaction is declined
• Merchant Services requires that the final EMV transaction tag data be retained so it can be
reprinted if necessary. This applies to both approved and declined EMV transactions. It is
preferred that EMV transaction data be available for every transaction in the batch.
Page 130
EMV Parameter Download

EMV POS Solutions require additional parameters to process EMV and contactless transactions. It is the
client’s responsibility to manage most EMV parameters. However, the Merchant Services host does
maintain and download several EMV parameters that must be used by the EMV POS Solution.
Different methods are used by the EMV POS Solution to obtain the Merchant Services EMV Parameters
depending on host interface being used:
• PNS ISO & PNS UTF
• Stratus Online and 120-Byte Batch
The sections that follow outline the implementation for each host interface.
CMS EMV RQ 00701 Merchant Services EMV Parameters must be downloaded whenever new
version is available
• Tandem and Stratus SFTP solutions must download the parameter file whenever a new version
is available. During integration testing the client will be required to confirm to Merchant Services
that the EMV POS Solution includes this functionality.
CMS EMV RQ 00702 Download EMV parameters within nine Settlement periods of notification
• Merchant Services requires that EMV POS Solutions using the PNS ISO or UTF interfaces
download EMV parameters within nine settlement periods after being notified that a new
parameter download is required. After the 9th settlement period with no download transactions
will no longer be performed.
EMV Download Parameters

The Merchant Services host maintains and downloads the following EMV parameters. These parameters
must be used by the EMV POS Solution:
• Certificate of Authority Public Keys. Public Keys issued by each card brand used for Offline
Data Authentication and offline PIN validation. There is a maximum of six public keys per card
brand.
• Fallback Indicator. Flag indicating if fallback is supported for the card brand. There is one flag
per card brand.
Page 131
• EMV Offline Floor Limit. Floor limit used to determine when the chip can offline approve an
EMV transaction without going online for authorization. There is one EMV Offline Floor Limit for
each card brand.
Note: Currently the EMV Offline Floor Limits are always set to zero. Therefore, the host download may or
may not return a Floor Limit value in response messages. When the Floor Limit Subtag or token is not
present in the download response message, a default of zero should be used.
• Threshold for Biased Random Selection. Used in conjunction with the EMV Floor Limit to
determine when a transaction may be authorized offline by the chip without going online for
authorization.
Certificate of Authority Public Keys (CAPK)

The Certificate of Authority (CA) Public Keys are required by the EMV POS Solution to support Offline
Data Authentication (SDA / DDA / CDA) and Offline PIN validation.
It is important that current CA Public Keys are always being used and that expired and revoked keys are
removed. Failure to remove expired and revoked keys could result in expired cards being approved.
Regulations state that Certificate Authority (CA) Public Key changes must be implemented within six
months of notification.
EMV POS Solutions must be capable of storing up to six CA Public Keys per card brand. The total
number of CA Public Keys required depends on the number of card brands supported by the EMV POS
Solution:
• American Express
• UnionPay via Discover
• Discover
• Interac
• JCB
• Mastercard / Maestro
• Visa / Interlink / ChaseNet
• Wright Express
Page 132
The Merchant Services EMV Parameter Download will include CA Public Keys for all card brands
supported by Merchant Services. It is the responsibility of the EMV POS Solution to ignore CA Public
Keys for card brands that are not supported.
CMS EMV RQ 00703 Must be capable of storing six CA Public Keys per card brand
• Merchant Services requires that EMV POS Solutions be capable of storing up to six active CA
Public Keys per card brand.
Fallback Indicator
The Merchant Services EMV Parameter Download includes a Fallback Indicator for each AID. If the
Fallback Indicator indicates fallback is not allowed, then the EMV POS Solution must not allow cards with
Service Codes ‘2xx’ or ‘6xx’ to be processed as magstripe cards. If the EMV chip is not functional, and
fallback is not allowed, the card may not be used.
EMV Offline Floor Limit

The Merchant Services EMV Parameter Download includes one EMV Offline Floor Limit for each RID.
This parameter is used to determine the minimum transaction amount that the chip can approve offline,
without going online for authorization.
Note: The Chip Floor Limit is currently set to zero for all card brands. If the value is downloaded from the
host, it must be used by the EMV POS Solution and it may not be changed at the device. However, if a
value is not downloaded, the default of zero should be set.
Threshold for Biased Random Selection

The Merchant Services EMV Parameter Download includes one Threshold for Biased Random Selection
parameter for each AID. This parameter is used in conjunction with the EMV Offline Floor Limit to
determine when a transaction may be approved offline without going online for authorization.
PNS ISO Parameter Download Processing

This section details how the Merchant Services PNS ISO interface manages and downloads parameters
to an EMV POS Solution.
For additional information, refer to the PNS ISO Format tandem developer guide.
Page 133
PNS ISO Download Notification

The PNS ISO host response message includes a Download Required Indicator (Bit 48 Subtag ‘D8’) at the
completion of the Batch Close or Batch Release process.
When the Download Required Indicator is received, it is up to the EMV POS Solution to initiate a
Merchant Services EMV Parameter Download. The parameter download does not have to occur
immediately, but it must be performed within nine settlement periods. After that time, the EMV POS
Solution will be unable to process transactions until a Merchant Services EMV Parameter Download is
performed.
Note: Even Terminal IDs that are set up as manual batch release will receive the Download Required
Indicator.
PNS ISO Parameter Download

PNS ISO EMV parameters are downloaded using the EMV Parameter Download Request (1340) and
EMV Parameter Download Response (1350) messages.
The parameter download requires multiple host request/response messages to download all EMV
parameters. At the completion of the download, the EMV POS Solution must send a final EMV Parameter
Download Request (1340) message to the host identifying the final status of the download.
The following data fields are used by the PNS ISO interface to download EMV parameters.
PNS ISO EMV Parameter Fields
Parameter Field
Certificate of Authority Public Key Bit 44 Subtag ‘P1’
EMV Fallback Indicator Bit 48 Subtag ‘P5’
EMV Offline Floor Limit Bit 48 Subtag ‘P6’
Biased Random Selection Limit Bit 48 Subtag ‘P6’
To identify the current state of the download from the POS EMV Solution perspective, the EMV
Parameter Download Request (1340) message includes an EMV POS Parameter Download Request
Status (Subtag ‘C7’) that must be set on all download request messages:
I = Initial download request
Page 134
S = Subsequent download request
Y = Download completed successfully. Checksums are valid (last request only)
N = Download failed, or checksums are not valid (last request only)
The EMV Parameter Download Response (1350) message includes Subtag ‘D9’ that identifies if the
download is complete or if additional parameter data is available:
M = More parameter data exists
F = Final download buffer sent
Note: When the final EMV Parameter Download Response (1350) message (Subtag ‘D9’ = “F”) is
received, the EMV POS Solution must send a final EMV Parameter Download Request (1340) message
indicating the status of the download (Subtag ‘C7’ set to ‘Y’ = Successful or ‘N’ = Failed).
UTF Parameter Download Processing

This section details how the Merchant Services UTF Host Capture System and Terminal Capture System
manages and downloads EMV parameters.
For additional information on the UTF message formats, refer to the UTF Terminal Capture and UTF Host
Capture tandem developer guides.
For additional information on the Token Data formats refer to the UTF Token Guide.
UTF EMV Download Notification

The UTF host response messages include a Download Required Indicator at the completion of the Batch
Close or Batch Release process.
The following table identifies where the EMV Parameter Download Required flag is sent.
EMV Parameter Download Required Indicator
Message Field
UTF - TCS Batch Upload Final Response Field 10
UTF - HCS Batch Release Response Field 11
Page 135
Message Field
UTF - HCS Auto Close Transaction response (1st transaction of ‘DL’ Token
the day only)
When the Download Required Indicator is received, it is up to the EMV POS Solution to initiate an EMV
Parameter Download. The parameter download does not have to occur immediately, but it must be
performed within nine settlement periods. After that time, the EMV POS Solution will be unable to process
transactions until a Merchant Services EMV Parameter Download is performed.
Note: Even Terminal IDs that are set up as manual batch release will receive the Download Required
Indicator.
UTF EMV Parameter Download

The UTF interface downloads EMV parameters using a series of EMV Parameter Download Request and
EMV Parameter Download Response messages.
The EMV parameter data is sent in the Token Data section of EMV Parameter Download response
messages. The following table identifies the tokens used for each EMV parameter.
UTF EMV Parameter Fields
Parameter Token
Certificate of Authority Public Key ‘PK’
EMV Fallback Indicator ‘FI’
EMV Offline Floor Limit ‘FL’
Biased Random Selection Limit ‘FL’
Downloading EMV parameters requires multiple EMV Parameter Download Request messages. To
identify the state of the download each request message must include the Download Status field set as
follows:
I = Initial download request
S = Subsequent download request
Y = Download completed successfully. Checksums are valid (last request only)
Page 136
N = Download failed, or checksums are not valid (last request only)
The EMV Parameter Download Response message includes a Parameter Download Status indicator
(‘DS’ token) that identifies if the download is complete or if additional parameter data is available. The
‘DS’ token is set as follows:
M = More parameter data exists
F = Final download buffer sent
Note: When the final EMV Parameter Download Response message (‘DS’ Token = “F”) is received, the
EMV POS Solution must send a final EMV Parameter Download Request message indicating the final
Download Status (‘Y’ = Successful or ‘N’ = Failed).
Stratus EMV Parameter Download Processing

The Stratus interface does not notify EMV POS Solutions when a download is required. Instead the
Stratus host will push out a new EMV parameter file monthly. This file will be available for pickup by the
EMV POS Solution for a period of three days. It is the responsibility of the EMV POS Solution to retrieve
the file while it is available. The EMV POS Solution will use SFTP or TCP/IP to download the file.
For a description of the Stratus EMV parameter file format refer to the Chip EMV® Download
specification.
Page 137
EMV Contact and Contactless Parameters

Contact EMV Parameters
This section lists the EMV parameters that should be supported by EMV POS Solutions.
For development and integration testing parameter values, refer to the EMV Testing Parameters section.
Table of Contact EMV Parameters
Tag Name Report Description

Label
Acquirer ID Acquirer ID ID assigned to the acquirer per scheme.
9F40 Additional Terminal Addl Indicates the data input and output capabilities of the
Capabilities Capability terminal.
Allow Fallback Flag Allow Controls whether fallback to swipe is allowed for a card
Fallback type when an error occurs while reading the chip.
Allow PIN Bypass Allow PIN Identifies if PIN entry can be bypassed by pressing the
Bypass Enter key without entering a PIN.
Note: The method used to bypass the PIN prompt may

differ based on the PIN Pad being used.
9F06 Application Identifier AID Uniquely identifies the application (RID + PIX).
(AID)
9F09 Application Version App Ver Version number assigned for the application by the
Number (Primary) Num Pri payment system.
9F09 Application Version App Ver (Optional) Secondary version number assigned for the
Number Num Sec application by the payment system.
(Secondary)
Certificate Authority CAPKx Certificate Authority Public Key Index Number

Public Key Index Index
Number
Page 138

Label
Default AID Label AID Label EMV POS Solution assigned AID Label.
Used when both Application Preferred Name (Tag 9F11)

and Application Label (Tag 50) are unavailable.
Default DDOL Default Used to construct the Internal Authenticate command if

(Dynamic Data DDOL card DDOL is not present on the card.
Authentication Data
Padded with trailing zeroes.
Object List)
Default TDOL Default Used to construct the Internal Authenticate command if

(Transaction TDOL card TDOL is not present on the card.
Certificate Data
Padded with trailing zeroes.
Object List)
EMV Random Rand Sel Maximum percentage of transactions having a value

Selection Maximum Max more than the EMV Random Selection Threshold that
Percentage must be sent online.
Numeric: 0 to 99
EMV Random Rand Sel Percentage of transactions having a value greater than
Selection Target Target the EMV Random Selection Threshold that must be sent
Percentage online.
Numeric: 0 to 99
EMV Random Rand Sel The transaction amount which is used to determine
Selection Threshold Thresh when to apply random selection to go online.
Numeric, whole numbers.
9F15 Merchant Category Merch Cat Type of business being performed by the merchant’s
Code Code device, represented according to ISO standard
8583:1993
Partial Name Partial Used to determine whether the terminal‘s AID must
Selection Flag Select exactly match the entire card AID including issuer suffix
or whether only the AID portion must match to be
selected.
Page 139

Label
Terminal Action TAC Default Identifies conditions where the transaction should be
Code-Default offline declined at the 2nd Generate AC if unable to go
online.
Terminal Action TAC Denial Identifies conditions that cause a transaction to be

Code-Denial offline declined at the 1st Generate AC.
Terminal Action TAC Online Identifies conditions that cause a transaction to be sent
Code-Online for online authorization at the 1st Generate AC.
9F33 Terminal Term Identifies the supported hardware, cardholder

Capabilities Capability verification methods and security capabilities.
9F1A Terminal Country Term “840” represents USA

Code Country
5F2A Terminal Currency Term “840” represents US Dollars

Code Currency
5F36 Terminal Currency Trans Curr Number of digits to the right of the decimal place in the
Exponent Exp currency.
e.g. If this parameter value is ‘2’ then 12345 represents

123.45
9F1B Terminal Floor Limit Term Floor The amount indicating the lowest value at which EMV
(EMV) Lim transactions must seek authorization online.
9F35 Terminal Type Term Type Indicates the environment of the terminal, its
communications capability, and its operational control.
Page 140

Label
9F53 Transaction Trans Cat Mastercard AIDs only.

Category Code Code
May be used to assist with Card Risk Management.
Merchant Services values include:
A: Automobile/Vehicle Rental
C: Cash Disbursement
F: Restaurant
H: Hotel/Motel and Cruise Ship Services
O: College/School Expense Hospitalization
R: Retail/All Other Transactions
T: Mail/Telephone Order Preauthorized Order
U: Unique Transaction
X: Transportation
Z: ATM
Contactless EMV Parameters

This section lists the contactless parameters that should be supported by EMV POS Solutions.
For development and integration testing parameter values, refer to the EMV Testing Parameters section.
Table of Contactless EMV Parameters
Tag Name EMV Report ID Description
Contactless CVM CTLS CVM Transaction amount above which a CVM is required
Required Limit Req Lim and the Contactless Terminal Capabilities CVM
Required setting should be used.
Contactless Floor CTLS Floor The number indicating the lowest value at which
Limit Limit contactless EMV transactions must seek authorization
online.
Page 141
Contactless CTLS Recpt Transaction amount above which a contactless

Receipt Required Req Lim transaction must print a receipt.
Limit
Interac only
Contactless CTLS Used to overwrite Terminal Capabilities when the

Terminal TermCapCVMR transaction amount is above the Terminal CVM
Capabilities CVM Required Limit (i.e. CVM is Required).
Req
Mastercard Only
Contactless CTLS Used to overwrite Terminal Capabilities when the

Terminal TermCapCVMN transaction amount is below the Terminal CVM
Capabilities CVM Required Limit (i.e. NO CVM).
NotReq
Mastercard Only
Contactless CTLS Trans Only amounts below this limit may be performed as
Transaction Limit Limit contactless transactions.
Default UDOL M/Chip Only
Default UDOL list used to Compute Cryptographic

Checksum when a TDOL is not available.
Default 0x9F, 0x6A, 0x04. Unpredictable Number (Tag

9F6A)
Enable Enable ExPay Flag indicating if ExpressPay contactless EMV is

ExpressPay EMV EMV supported.
Amex only
Enable Enable Flag indicating if ExpressPay contactless MSD is

ExpressPay MSD ExPayMSD supported.
Amex only
Enable MChip Enable MChip Flag indicating if PayPass contactless EMV is

supported.
Mastercard only
Page 142
Enable MStripe Enable MStripe Flag indicating if PayPass contactless MSD is

supported.
Mastercard only
Merchant Type Merchant Type Identifies the Merchant Type.

Indicator
Interac Only
9F6D MSD Version MSD Version Version number assigned by the payment system for
Number Num the specific PayPass. Magstripe functionality of the
application.
Mastercard Only
9F66 Visa TTQ Visa TTQ Visa Only. Terminal Transaction Qualifiers.
Page 143
Host Message Processing

This section outlines the information required to process EMV transactions using the Merchant Services
PNS ISO, UTF and Stratus interfaces. The information includes:
• Host Transaction Sets
• Host Message EMV Fields
• Host Message EMV Tags
• Host Message Examples
Note: The information provided in this section is provided for clarity and completeness. The PNS ISO,
UTF and Stratus specifications provide more complete and up to date information. Therefore, those
specifications should be used when developing an EMV POS Solution.
Host Transaction Sets

Merchant Services supports three host interfaces. All three interfaces include EMV transaction support.
This section defines the credit / debit transaction sets supported by Merchant Services and specifies how
the transactions are identified for each of the host interfaces:
• PNS ISO
• UTF
• Stratus Online 7.4 / Stratus 120 Byte Batch
The following tables identify the standard credit and debit transaction sets used to process transactions
with the Merchant Services hosts. For information relating to the Canadian debit transaction set see
Appendix A - Canadian Processing section.
Credit Transaction Set

The following table defines the credit transaction set used for EMV transactions and provides information
on how the transaction is identified for each host interface.
Page 144
Credit Transaction Set
Transaction ISO (TCS)* ISO (HCS)** UTF UTF Stratus Stratus Batch
Type (TCS)* (HCS)** Online (TCS)*
(TCS)*
Auth Only Authorization Authorization Auth Auth Auth N/A

Only Only
1100 1100 AU
02 02
Sale N/A EFT Sale Sale N/A Deposit
1200 01 01 DP
Prior Sale/ Detail EFT Prior Prior N/A N/A

Deposit Record Auth Auth
1200
Sale Sale
1300
Prior Auth
03 03
Prior Auth
(Bit 3 = 17)
(Bit 3 = 17)
Offline Detail 1200 Prior Prior N/A N/A

Posting Record Auth Auth
Bit 3 = 11
Sale Sale
1300
11 11
Prior Auth
(Bit 3 = 11)
Return / Return Return Credit Credit N/A Refund

Refund Return Return
1300 1200 Action Code =
(offline)
06 06 RF
Bit 3 Bit 3
Transaction Transaction
Type = 20 Type = 20
Page 145
(TCS)*
Return / Return Auth Return Credit Credit Refund Auth Refund Auth
Refund Return Return Action Code Action Code =
1100 1200
(online) = RA RA
06 06
Bit 3 Bit 3
Transaction Transaction
Type = 20 Type = 20
Void / Reversal EFT Reversal Void Auth N/A

Merchant Advise Advice Reversal
Void 41
Reversal
1420 46 AR
1400 Auth
Bit 3 Original Only
Bit 3 Original
Reversal
Auth Only
Advice
Reversal
46
Advice
1420
Bit 3 Original
Partial Void Auth Auth Auth Auth N/A N/A

Reversal Reversal
(Mastercard) 1100 1100
09 09
(Discover) Bit 48 (V7) = Bit 48
R (V7)=R
Page 146
(TCS)*
Reversal Reversal EFT Reversal Reversal Auth N/A

Advise Advice Advice Reversal
(2nd Gen Void
Chip 1420 46 46 AR
1400
Decline)
Bit 3 Original Reason Reason
Bit 3 Original
(EMV Data Code = Code =
Bit 48 (R3) =
Bit 48 (R3) =
Required) 4 4
4
4
Auth Only
Reversal
Advice
1420
Bit 3 Original
Bit 48
(R3)=4
Reversal Reversal EFT Reversal Reversal Auth N/A

Advise Advice Advice Reversal
(EMV Other) Void
1420 46 46 AR
(EMV Data 1400
Required) Bit 3 Original
Bit 3 Original
Auth Only
Reversal
Advice
1420
Bit 3 Original
Page 147
(TCS)*
EMV Authorization Authorization Balance Balance Balance N/A

Balance Inquiry Inquiry Inquiry
1100 1100
Inquiry
16 16 BI
(zero (zero
amount) amount)
Bit 3 = 31 Bit 3 = 31
*Terminal Capture System
** Host Capture System
Debit Transaction Set

The following table shows the debit transaction set used for EMV transactions and information on how the
transaction is identified for each host interface.
Debit Transaction Set
* **
Type (TCS) (HCS) Online (TCS)*
(TCS)*
Auth Only N/A Pre-Auth N/A Pre-Auth N/A N/A

25
1200
Sale N/A 1200 N/A 21 Purchase N/A

Authorization
PA
Sale N/A 1200 N/A 22 Purchase N/A

Authorization
w/Cashback Processing
Code = PA
099200
Page 148
* **
(TCS)*
Prior Sale / N/A 1200 N/A 26 N/A N/A

Completion
Processing
Code =
099200
Return / N/A 1200 N/A 24 Refund Auth Refund

Refund
Processing RA RF
Code =
099200
Void / N/A N/A N/A N/A Purchase N/A

Auth
Merchant 1420 46
Reversal
Reversal
PR
Return / N/A 1420 N/A 46 Refund N/A

Refund Reversal
Reversal
DR
Partial Void N/A N/A N/A N/A N/A N/A
(Mastercard)
(Discover)
Page 149
* **
(TCS)*
Reversal N/A Reversal N/A Reversal Purchase N/A

Advice Advice Auth
(2nd Gen
Reversal
Chip 1420 46
Decline) PR
Bit 3 EMV
(EMV Data Original Data Not
Required) Required
Bit 48 (R3)
=4
EMV Data
Not
Required
Reversal N/A Reversal N/A Reversal Purchase N/A

Advice Advice Auth
(EMV Other)
Reversal
1420 46
(EMV Data
PR
Required) EMV Data EMV
Not Data Not
Required Required
EMV N/A N/A N/A N/A N/A N/A

Balance
Inquiry
**Host Capture System
Host Message EMV Fields

This section contains host message field usage information related to EMV and contactless processing.
Note: The information provided in this section is provided for clarity and completeness. The PNS ISO,
UTF and Stratus specifications provide more complete and up to date information. Therefore, those
specifications should be used when developing an EMV POS Solution.
Page 150
Cardholder Data
The following rules must be adhered to when sending EMV cardholder data read from the chip to the
Merchant Services host:
1. If Track 2 data is sent in the host message, the Track 2 data must be populated from Track 2
Equivalent Data (Tag 57).
2. The Track 2 Equivalent Data (Tag 57) uses a ‘D’ to delimit between the end of the cardholder
account number and the beginning of the expiry date. In the Merchant Services host message,
the ‘D’ should be replaced with an ‘=’ to match the format used when sending Track 2 data read
from a magstripe.
3. If the cardholder account number (PAN) is sent in the host message, the PAN must be populated
from Application PAN (Tag 5A).
4. Application PAN (Tag 5A) may be suffixed with one or more trailing ‘F’ (0xF) characters. The
trailing ‘F’ characters must not be sent in the host message.
Chip Card Data

Chip Card Data sent in EMV request messages and returned in EMV response messages. This field
consists of a 3-byte length field followed by a variable number of BER-TLV encoded EMV tag data fields.
Chip Card Data Field Format
Total Tag Tag Tag Tag Tag Tag TLV

Field Number Length Value Length Value
Length (hex) (hex)
3 Bytes 2 or 4 2 or 4 Variable 2 or 2 or 4 Variable Tag / Length / Value

(Decimal) Bytes Bytes length 4 Bytes length fields repeat for each tag
tag data Bytes tag data
Tag Number Size
The hex Tag Number is either 2 or 4 bytes in length. To determine the number of bytes used for the Tag
Number, check the last bit of byte one and all four bits in byte two, if they are all ‘1’, the tag number is four
(4) bytes in length (including the current byte).
Example 1: Tag 9F10 is a 4-byte Tag Number. This is known because the last bit of the first byte (‘9’) and
all bits in the second byte (‘F’) are all ones (‘10011111’)
Page 151
Example 2: Tag 72 is a 1-byte tag number. This is known because the last bit of the first byte (‘7’) and all
bits in the second byte (‘2’) are not all ones (‘01110010’)
Tag Length Size
The 2 or 4 bytes following the Tag Number contain the Tag Length. To determine the number of bytes
used for the Tag Length, check the first bit of byte one. If the first bit is:
• 0: bytes 1 and 2 are the actual length of the Tag Value that follows
• 1: the next 7 bits are a binary representation of the number of length bytes that follow
Example 1: If the first two length bytes are ‘0C’, the first bit is a zero (‘00001100’), so the tag data starts
in the next byte and is 12-bytes in length.
Example 2: If the first two length bytes are ‘82’ and are converted to hex (0x82), the first bit is a one
(‘10000010’) and the next 7 bits are ‘0000010’ (decimal 2), so the next two bytes contain the actual tag
data length followed by the tag data.
Tag Length Value
The Tag Length represents the length of the Tag Value that follows, when in hex format. When the Tag
Value is converted to ASCII in the host message, the resulting Tag Value becomes twice as long because
it requires two ASCII bytes to represent a single hex byte. Regardless, the Tag Length field should not
change. It should always contain the original hex length of the Tag Value that follows.
Example: Tag 9F08 is 8 hex bytes in length and is set to (0x41 0x42 0x43 0x44 0x31 0x32 0x33 0x34).
When sending this tag in the host message it must be converted to ASCII. The Tag Length in ASCII is
‘08’ and the Tag Value in ASCII is “4142434431323334”. The Tag Length field in the host message
indicates the Tag Value is 8 bytes in length, but the Tag Value that follows is 16 ASCII bytes.
9F08084142434431323334
Chip Card Data Field Example
The following is an example of a Chip Card Data field containing tags (82, 95, 9A and 5F24). The field is
prefixed with a 3-byte ASCII decimal length (044) followed by one TLV field for each tag being sent.
04482025C00950502000080009A031410285F2403141231
Page 152
EMV/Contactless PAN Sequence Number

The EMV/Contactless PAN Sequence Number is a two byte field containing the PAN Sequence Number
(Tag 5F34) value returned by the chip.
If the chip does not return PAN Sequence Number (Tag 5F34), this field should not be included in the
host message.
Host Message EMV Tags

The following sections outline the EMV tags that should be sent for authorization, reversal, and settlement
request messages as well as the tags that will be returned in the authorization host response message.
Tags are shown in the order they should be sent in the host request message.
CMS EMV BP 00901 EMV Tags should be sent in order
• Merchant Services recommends that EMV tags included in host request messages be sent in the
order; fixed length tags first, in ascending order by tag number, followed by variable length tags in
ascending order by tag number. This is will help resolve issues identified during integration
testing.
Authorization Request EMV Tags

This section outlines the EMV tags (in TLV format) that should be sent in authorization request
messages. Tags are shown in the order they should be sent in in the request message.
CMS EMV BP 00902 Authorization request messages must include all authorization EMV tags
• Merchant Services recommends that authorization request messages include all defined
authorization EMV tags, regardless of the transaction type or card used. If a tag is not required,
the Merchant Services host will ignore it. If a tag has no data, the TLV length must be set and
submitted with the Full Tag Length Value. Example: 9F03 Length 06 Value 000000000000
Authorization Request Message EMV Tags
Tag Element Name Comments
82 AIP Application Interchange Profile
95 TVR Terminal Verification Results
Page 153
9A Terminal The local date that the transaction was performed.

Transaction Date
Format: YYMMDD
9C Transaction Type Indicates the type of financial transaction, represented by the first two
digits of the ISO 8583: 1987 Processing Code.
0x00 = Goods and Services
5F2A Transaction Currency code used for the transaction according to ISO 4217.
Currency Code
840 = US Dollars
9F02 Transaction Contains the actual transaction amount used by the chip when calculating
Amount the cryptogram (amount + cashback + tip + surcharge).
This amount excludes any adjustments (e.g. tips) that were made to the
transaction amount after completion of the original EMV transaction.
Two decimals implied.
9F03 Other Amount Secondary cashback amount.
Mandatory if cashback applies. Zero filled if not supported.
9F09 Terminal Version number assigned by the payment system for the application.
Application
Version Number
9F1A Terminal Country Indicates the country of the terminal, represented according to ISO 3166.
Code
840 = United States
9F1E POS/Terminal A unique and permanent identification number of the chip POS / Terminal
Serial Number assigned by the manufacturer.
Used to track devices regardless of their location.
9F26 Application Cryptogram returned by the card in response to the 1st Generate AC
Cryptogram command
Page 154
9F27 CID Cryptogram Information Data which indicates the type of cryptogram
generated by the chip card.
00 = AAC (declined)
40/50 = TC (approved)
80/90 = ARQC (go online)
9F33 Terminal Indicates the card data input, CVM, and security capabilities of the
Capabilities terminal.
This field must match the value for the EMV kernel configuration being
used for the transaction.
9F34 CVM Results Cardholder Verification Method Results
9F35 Terminal Type Indicates the environment of the terminal, its communications capability,
and its operational control.
used for the transaction
9F36 ATC Application Transaction Counter which is maintained by the chip card.
9F37 Unpredictable Value to provide variability and uniqueness to the generation of a

Number cryptogram.
9F39 POS Entry Mode Indicates the method by which the PAN was entered, according to the first
two digits of the ISO 8583:1987 POS Entry Mode.
9F41 Transaction Counter maintained by the POS/Terminal that is incremented by one for
Sequence each transaction.
Counter
9F53 Transaction Mastercard/Europay code defining the type of transaction or industry

Category Code sector in which the merchant operates.
84 Dedicated File Identifies the name of the DF as described in ISO/IEC 7816-4.

Name
Usually the same as AID (Tag 4F).
Page 155
9F10 Issuer Contains proprietary application data for transmission to the issuer in an
Application Data online transaction.
Some tags hold sensitive data that the card brands dictate must not be passed in authorization messages
as tags within the EMV chip data field. These fields are instead populated in equivalent existing sensitive
data fields within messages. This ensures that this data remains protected by current PCI Compliance
procedures
Sensitive Data Tags
5F24 Application Expiry Date after which the application expires.

Date
• PNS ISO Bit 14: Expiration Date
• UTF Transaction Header
5F34 PAN Sequence Application Primary Account Number (PAN) Sequence Number.
Number
• PNS ISO Bit 23: Card Sequence Number
• UTF "PS" Token
5A PAN Application Primary Account Number
• PNS ISO Bit 2: Cardholder Account Number fields
57 Track 2 Data Track 2 Equivalent Data
• PNS ISO Bit 35: Track 2 Data
Authorization Response EMV Tags

The following tags may be included in host response messages. Tags will only be included if they contain
data.
Page 156
Authorization Response Message EMV Tags
8A Authorization Response code that indicates the approved/declined status of the

Response Code transaction.
This tag must be provided to the kernel. If this tag is not present in the
response message, then the following values should be set in Tag 8A:
‘00’ (0x3030) if the transaction was approved
‘05’ (0x3035) if the transaction was declined
71 Issuer Script Contains proprietary Issuer Script commands to be executed by the chip
Template 1 before the 2nd Generate AC command.
The Issuer Script must be provided to the EMV kernel for both approved
and declined transactions.
72 Issuer Script Contains proprietary Issuer Script commands to be executed by the chip
Template 2 after the 2nd Generate AC command completes.
The Issuer Script must be provided to the EMV kernel for both approved
and declined transactions.
91 Issuer This tag contains the ARPC cryptogram used for online issuer
Authentication authentication.
Data
This tag must be provided to the EMV kernel so that it can be
authenticated by the card.
Reversal EMV Tags

This section outlines the EMV tags (in TLV format) that should be sent in the reversal messages.
CMS EMV BP 00903 Reversal messages should include all reversal EMV tags
• Merchant Services recommends that reversal messages include all defined reversal EMV tags,
regardless of the transaction type or card used. If a tag is not required, the Merchant Services
host will ignore it.
Page 157
Reversal Message EMV Tags

Transaction Date
Format: YYMMDD
digits of ISO 8583: 1987 Processing Code.

Date
Currency Code
840 = US Dollars
Number
Application
Version Number
Page 158
Code
840 = United States
9F1E POS/Terminal A unique and permanent identification number of the chip POS/Terminal
Cryptogram command
00 = AAC (declined)
9F34 CVM Results Cardholder Verification Method Results.
used for the transaction

Number cryptogram.
Page 159
Counter

84 Dedicated File Identifies the name of the DF as described in ISO/IEC 7816-4.

Name
Usually the same as AID (Tag 4F).
9F10 Issuer Application Contains proprietary application data for transmission to the issuer in an
Data online transaction.
Settlement EMV Tags

This section outlines the EMV tags (in TLV format) that should be sent in the settlement messages.
CMS EMV BP 00904 Settlement messages should include all settlement EMV tags
• Merchant Services recommends that settlement messages include all defined settlement EMV
tags, regardless of the transaction type or card used. If a tag is not required, the Merchant
Services host will ignore it.
Settlement Message EMV Tags
8A Authorization Response code that indicates the final approved/declined status of the
Response Code transaction.
‘00’ (0x3030) if the transaction was approved
‘05’ (0x3035) if the transaction was declined
91 Issuer This tag contains the ARPC cryptogram used for online issuer
Authentication authentication.
Data
Page 160

Transaction Date
Format: YYMMDD
digits of ISO 8583: 1987 Processing Code.

Date
Currency Code
840 = US Dollars
Number
Application
Version Number
Code
840 = United States
Page 161
9F1E POS/Terminal A unique and permanent identification number of the chip POS/Terminal
Cryptogram command.
00 = AAC (declined)
9F34 CVM Results Cardholder Verification Method Results.

Number cryptogram.
Counter
Page 162

84 Dedicated File Identifies the name of the DF as described in ISO/IEC 7816-4. Usually the
Name same as AID (Tag 4F).
9F10 Issuer Contains proprietary application data for transmission to the issuer in an
Application Data online transaction.
9F5B Issuer The card records the results of scripts executed because Tag 71 or Tag
Script Results 72 was received in an authorization response message. These results are
sent to the host when the transaction is settled.
Mandatory for settlement if Issuer Script (Tag 71 or Tag 72) was received
from the issuer in an authorization response.
Host Message Examples

The following sections contain host EMV request and response message examples for each of the
Merchant Services supported interfaces.
• PNS ISO
• PNS UTF
• Stratus Online 7.4/ Stratus 120 Byte Batch
Note: In the examples that follow, all PAN values have been blacked out and EMV Tag Numbers have
been highlighted in grey.
PNS ISO Host Message Examples
Example #1: Visa Credit Sale - EFT (1200 & 1210)
This is an example of a Visa Sale transaction.
The following is the request message sent by the EMV POS Solution.
Page 163
ISO Visa Sale Request Message, Raw
ISO Visa Sale Request Message, Formatted
Page 164
The following is the response message returned by the Merchant Services host.
ISO Visa Sale Response Message, Raw
Page 165
ISO Visa Sale Response Message, Formatted
Example #2: Mastercard Authorization (1100 & 1110)
This is an example of a Mastercard Authorization transaction. The transaction is approved, and an Issuer
Script is returned.
Page 166
ISO Mastercard Authorization Request Message, Formatted
Page 167
The following is a response message returned by the Merchant Services host. The response includes an
Issuer Script (Tag 71) that must be sent to the PIN Pad kernel for processing prior to the 2nd Generate
AC.
Page 168
ISO Mastercard Authorization Response Message, Formatted
Example #3: Reversal Advice / Authorization Reversal (1420 & 1430)
The following is the Reversal Advice message sent by the EMV POS Solution.
Page 169
ISO Mastercard Reversal Advice Message, Formatted
Page 170
The following is a response message returned by the Merchant Services host.
ISO Mastercard Authorization Reversal Message, Formatted
UTF Host Message Examples
Example #1: UTF Mastercard Retail Sale with Issuer Script
This is an example of a Mastercard Sale transaction. The transaction is approved, and an Issuer Script is
returned.
Page 171
In the raw trace below, grey text highlights an EMV Tag and a “^” represents an ASCII space (x’20’).
UTF Mastercard Retail Sale Request Message, Raw
UTF Mastercard Retail Sale Request Message, Formatted
Page 172
Page 173
The following is response message returned by the Merchant Services host. The response includes an
Issuer Script (Tag 71) that must be sent to the PIN Pad kernel for processing prior to the 2nd Generate
AC.
UTF Mastercard Retail Sale Response Message, Raw
Page 174
UTF Mastercard Retail Sale Response Message, Formatted
Page 175
Example #2: UTF Visa Retail Sale Request
This is an example of a purchase reversal transaction that is approved by the host.
Page 176
UTF Visa Retail Sale Request Message, Raw
UTF Visa Retail Sale Request Message, Formatted
Page 177
Page 178
The host approves the transaction and sends the following response.
UTF Visa Retail Sale Response Message, Raw
UTF Visa Retail Sale Response Message, Formatted
Page 179
Example #3: UTF Reversal Advice
This is an example of a Reversal Advice transaction that is transmitted to the host.
In the raw trace below, a “^” represents an ASCII space (x’20’).
UTF Visa Reversal Advice Message, Raw
Page 180
UTF Visa Reversal Advice Message, Formatted
Page 181
Stratus Host Message Examples
Example #1: Mastercard Authorization
This is an example of a Mastercard Authorization transaction.
The following is the message sent by the EMV POS Solution.
Stratus Online 7.4 Mastercard Authorization Message, Raw
Page 182
Stratus Online 7.4 Mastercard Authorization Message, Formatted
EMV Receipt Guidelines

EMV Receipt Data
The following table outlines EMV information for transaction receipts. The information shown may be
printed in any order.
The information in the table below identifies the optional and required EMV specific receipt information
requirements.
Page 183
EMV Receipt Information
Field Description
Application Label The chip card application name (i.e. Visa, Mastercard, etc.) used to process the
or Name EMV transaction. The EMV tag value printed depends on the personalization of
the chip:
(REQUIRED)
Application Preferred Name (Tag 9F12) should be printed if possible
If Issuer Code Table Index (Tag 9F11) indicates that Tag 9F12 is stored in an ISO-
8859 character set that is not supported by the printer, then Application Label (Tag
50) should be printed
The Payment brands mandate either the Application Label or the Application
Preferred Name be printed on the receipt
Note: If the Issuer Code Table Index (Tag 9F11) is set to ‘1’, it indicates that the
Application Preferred Name is encoded using the Latin character set (i.e. contains
standard English alphabetic characters).
Card Entry Mode Indicator identifying how the card information was obtained.
(OPTIONAL) • Chip
• Card information read from EMV chip
• Contactless
• Card information read by a contactless reader
• Chip/Swiped
• Fallback swipe (insert was attempted but failed)
• Keyed or Manual
• Manually entered card number and expiry date
• Swiped
• Card swiped (not Fallback, insert was not attempted)
Transaction Total The receipt total line must reflect the final transaction amount including any card
discounts that may have been applied.
(REQUIRED)
Note: If card discounts were applied, this amount may not match the amount
stored in Transaction Amount (Tag 9F02).
Page 184
Field Description
Cardholder Identifies the Cardholder Verification Method (CVM) used for the transaction:
Verification
• If a PIN was entered “Verified by PIN” may be printed
(OPTIONAL) • If NO CVM, “No Signature Required” may be printed
• If signature was electronically captured, the receipt may state as such
Signature If the CVM includes a signature
(REQUIRED) • A signature line must be printed or
• A signature may be captured electronically
EMV Tag Data Several EMV tag values may be printed on the merchant copy of receipts to assist
in problem resolution. These fields must be printed in the order shown and should
(OPTIONAL)
be identified by their tag name. If not printed at the time of the transaction, then it
is recommended that the information be stored for later trouble shooting if needed.
• TVR 95 Terminal Verification Results
• TSI 9B Transaction Status Indicator
• AC 9F26 Application Cryptogram
• ARC 8A Application Response Code
EMV Tag Data The AID is required by EMVCo to be printed on all receipts.
(REQUIRED) • AID 4F Application Identifier
The cardholder account number should be masked and expiration date suppressed on all receipts,
regardless of the card type or payment brand mandate. This applies to both US and Canadian receipts.
The merchant and cardholder receipts need not contain the same information.
Merchant and Cardholder Receipt Requirements
Field Merchant Receipt Cardholder Receipt
Application Label Required Required
Card Entry Mode Recommended Recommended
Transaction Total Required Required
Page 185
Field Merchant Receipt Cardholder Receipt
Cardholder Recommended Recommended

Verification
Signature Line Required (if Signature Not needed

CVM)
EMV Tag Data Recommended Not Recommended
AID Required Required
CMS EMV RQ 01001 Application Name or Label must be printed on the receipt
• Merchant Services requires that Application Preferred Name (Tag 9F12) be printed on the receipt
if it is stored on the chip in a character set supported by the printer. Otherwise, Application Label
(Tag 50) must be printed.
CMS EMV RQ 01002 Transaction amount must be printed on the receipt
• Merchant Services requires that the receipt includes the final transaction amount including card
discounts (if any).
CMS EMV RQ 01003 AID must be printed on the receipt
• Merchant Services requires that all receipts must contain the AID (Application Identifier)
information with the tag value.
Note: Merchant receipts may optionally contain "TVR," "TSI," "AC," "TSI" and "ARC" labels followed by
their tag values. If the optional data is not printed on the original merchant receipt, the data should be
stored to be able to include on a reprint for troubleshooting assistance. The optional EMV labels and tag
values must be printed in the order shown in the table in EMV Receipt Data section.
The receipt is a legal document that represents a transaction that has taken place. The receipt must
identify the financial details of the transaction as well as merchant and terminal information.
Sample EMV receipt layouts have been illustrated below. The exact receipt layout may differ as long as
the EMV requirements (shown above) have been met and the receipt conforms to all guidelines for non-
EMV receipts.
For sample Canadian French receipts see Appendix A.
Page 186
Credit Card (Online Approved with Signature)

The following is an example of a receipt for a credit transaction approved online by the host. The CVM
used was signature and the Track 2 information was obtained from a contactless EMV card.
EMV Receipt Requirements
• Transaction Type (Sale)
Page 187
• Application Preferred Name (Tag 9F12) is present on card in a supported character set so it must
be printed (VISA CREDIT)
• Card Entry Method indicates that card information was obtained from a contactless tap
(Contactless)
• Application PAN (Tag 5A) must be masked and printed (************8106)
• The final authorized transaction amount must be printed (75.01)
• EMV Information must be printed in the order shown and identified by the tag names:
o AID (A0000000031010), Required
o TVR (0000008000), Optional
o TSI (E800), Optional
o AC (0123456789ABCDEF), Optional
o ARC (00), Optional
• Cardholder Verification Method was “Signature” so a Signature Line must be printed
EMV Receipt Best Practices
• Merchant and Cardholder receipt copies should be identical except for the receipt copy indicator
Credit Card (Online Approved with PIN)

The following is an example of a receipt for a credit purchase transaction approved online by the host.
The CVM used was online PIN and card track data was obtained by reading the EMV chip. Additionally,
the Application Preferred Name was not present on the card in a character set supported by the printer.
Page 188
• Application Preferred Name (Tag 9F12) is not on the chip or present in an unsupported character
set, so the Application Label (Tag 50) must be printed (Visa Credit)
Page 189
• Card Entry Method indicates card was inserted and card information was read from the contact
chip (Chip)
o TSI (F800), Optional
o AC (0123456789ABCDEF), Optional
o ARC (00), Optional
• Transaction is approved so the host approval code must be printed (123456)
• Cardholder Verification Method. A PIN was entered so “Verified by PIN” must be printed
Credit Card (Online Approved through Fallback)

The following is an example of a receipt for a credit transaction approved online by the host. The card had
a chip present Service Code (2xx or 6xx) but there was a chip read error, so the card was swiped, and
the transaction was completed as a Technical Fallback transaction.
Page 190
• Application Preferred Name (9F12) and Application Label (Tag 50) cannot be obtained from chip
so the BIN table name is printed (VISA)
• Track 2 PAN must be masked and printed
Page 191
• Card Entry Method indicates that card information was obtained by swiping the card after a failed
chip read (Chip/Swiped)
• Card was a fallback swipe, so a signature line is printed
• EMV Information section (AID, TVR, CVR, TSI and ARC) is not printed as the chip was not used
Credit Card (Offline Declined)

The following is an example of a receipt for a credit transaction declined offline by the EMV chip. The
CVM used was Signature and the Track 2 PAN was obtained by reading the EMV chip.
Page 192
• Application Preferred Name (Tag 9F12) printed (VISA CREDIT)
chip (Chip)
Page 193
o TSI (E800), Optional
o AC (0123456789ABEDEF), Optional
o ARC (Z1), Optional
• Cardholder Verification Method. Not printed as the transaction was declined
• EMV Offline Data block (i.e. Tag 50, Tag 5F2A, etc.) is printed in the order shown using the labels
shown
Page 194
EMV Report Guidelines

EMV reports are useful to track and reprint EMV transactions (including associated EMV tag values), to
verify the EMV configuration and to track EMV card usage and failure rates:
• Merchant Services must have a way to confirm that the production terminal configuration matches
the configuration that was tested and that all data (e.g. CA Public Keys) are current and accurate
• For problem determination the last transaction EMV tag values and terminal configuration are
required
• The merchant requires a way to track EMV card acceptance and fallback rates
Note: The card associations track fallback rates. It is in Merchant Services and the merchant’s best
interest to keep fallback rates as low as possible.
EMV Transaction Report

The EMV Transaction Report shows the final EMV data element values for both approved and declined
transactions. This is a report that, at a minimum, should be available for the last transaction processed.
Merchant Services recommends that the report be available for all transactions in the current batch. This
report is particularly helpful for chip offline declines as it provides valuable information not available
elsewhere.
The following sample shows the recommended report format. Additional information may be printed if
desired.
Page 195
CMS EMV BP 01101 EMV Transaction Report should be available for last transaction
• Merchant Services recommends that the EMV POS Solution includes an EMV Transaction Report
that prints the EMV data element values. At a minimum, this report should be available for the last
transaction processed regardless of whether the transaction was approved or declined. It is
preferred that this report be available for all transactions in the current batch.
CMS EMV BP 01102 EMV Transaction Report includes data element name and tag number
Page 196
• Merchant Services recommends that the EMV Transaction Report show both the data element
name and the tag number (if assigned) for each field.
CMS EMV BP 01103 EMV Transaction Report information should be stored in journal
• Merchant Services recommends that the EMV Offline Decline information be stored in the system
journal (when available) and retained for six months. This will aid in resolving cardholder inquires
relating to why an offline transaction was declined.
EMV Statistics Report

Merchant Services recommends that the EMV POS Solution includes an EMV Statistics Report that prints
EMV statistics accumulated since the last batch close. This will aid in troubleshooting the POS
acceptance device.
The following sample report shows some EMV statistics that should be considered for this report. Other
statistics may be added at the client’s discretion.
Note: The statistic counts should reset to zero after each successful settlement.
CMS EMV BP 01104 EMV Statistics report is recommended
• Merchant Services recommends that the EMV POS Solution includes an EMV Statistics Report to
shows EMV statistics accumulated since the last batch close.
Page 197
Technical Fallback Reports

Merchant Services recommends that the EMV POS Solution includes two fallback reports to monitor
Technical Fallback percentages:
• Clerk Technical Fallback Report. Identifies clerks that have a high incidence of fallback
transactions
• PIN Pad Technical Fallback Report. Identifies PIN Pads that have a high incidence of fallback
transactions
A high number of Technical Fallback transactions are a sign of a problem. Having Technical Fallback
reports available makes it possible to identify if the issue is related to a specific clerk that may require
additional training or a PIN Pad that may require servicing.
CMS EMV BP 01105 EMV Technical Fallback reports are recommended
• Merchant Services recommends that the EMV POS Solution includes Technical Fallback reports
to identify clerks and PIN Pads with high Technical Fallback rates. The card brands also monitor
fallback rates, so it is a best practice to keep them as low as possible.
EMV Clerk Technical Fallback Report

An EMV report that identifies the percentage of Technical Fallback transactions by clerk will help identify
personnel who may need additional training. The report should only identify the clerks that have a
Technical Fallback percentage over a defined threshold.
Page 198
This report may be created by a store controller or back office system and contain statistics for multiple
terminals. In this case the ‘Term ID’ is not required and should be replaced with a site identifier.
PIN Pad Technical Fallback Report

An EMV report that identifies the percentage of Technical Fallback transactions by PIN Pad will help
identify hardware that requires servicing. The report should only identify the PIN Pads that have a
Technical Fallback percentage over a defined threshold percentage.
Note: This report may be created by a store controller or back office system and include statistics for
multiple terminal IDs. In this case the ‘TID’ line is not required and should be replaced with a site
identifier. If created for a single terminal ID, the report would generally only list one PIN Pad unless the
PIN Pad was replaced during the period being printed.
POS Entry Mode Report

The POS Entry Mode report identifies how card information is being captured. This provides a view of the
type of cards being used by cardholders and the cardholders preferred method of payment.
Page 199
CMS EMV BP 01106 POS Entry Mode Report is recommended
• Merchant Services recommends that the EMV POS Solution includes a POS Entry Mode Report.
This report provides good insight into how cardholder data is being obtained.
EMV Configuration Report

The EMV Configuration Report identifies all the EMV parameters required to be configured for the
terminal. It is mandatory that this report be included in all EMV POS Solutions. This must be a restricted
report with limited or supervisor access. The report can be printed local to the device or optionally at a
store or server level. The report must be device or terminal specific.
Page 200
Page 201
Page 202
Page 203
Page 204
Note: For a definition of the report field names refer to the EMV and Contactless Parameters section (see
EMV Contact and Contactless Parameters section).
CMS EMV RQ 01101 EMV Configuration Report is mandatory
• Merchant Services requires that all EMV POS Solutions include an EMV Configuration Report.
Page 205
EMV Public Key Load Report

The EMV CA Public Key Load report is used to validate that the Certificate of Authority Public Keys
(CAPK) loaded by the EMV POS Solution are current and accurate. It is mandatory that this report be
included in all EMV POS Solutions. This must be a restricted report with limited or supervisor access. The
report can be printed local to the device or optionally at a store or server level. The report must be device
or terminal specific.
Page 206
Note: Each card association may have up to six active CA Public Keys at any time. Therefore, the RID /
Key Index / Key Modulus / Key Exponent section will repeat up to six times per card association.
CMS EMV RQ 01102 EMV Public Key Load Report is mandatory
• Merchant Services requires that all EMV POS Solutions include an EMV Public Key Load Report.
Page 207
EMV Contact and Contactless Data

Elements
EMV Contact and Contactless Data Elements
Definitions
Note: The information in this chapter has been extracted from the EMV 4.3 Book 3 Application
Specification.
The following table defines the EMV and contactless data elements and for each element provides the
tag number, data length, format, and description. The format of each element is defined as follows:
Value Description
an Alphanumeric
an x Alphanumeric of fixed length ‘x’
an x-y Variable length alphanumeric with a minimum length ‘x’ and a maximum length ‘y’
ans Alphanumeric Special data elements that contain a single character per byte (refer to
EMVCo Book4 Annex B)
b Binary
cn Compressed Numeric
(similar to BCD but left justified and padded with trailing hexadecimal ‘F’s)
nx Numeric of length ‘x’
n x-y Variable length numeric with a minimum length of ‘x’ and a maximum length of ‘y’
When the length defined for the data object is greater than the length of the actual data, the following
rules apply for each data element:
• ‘n’ is right justified and padded with leading hexadecimal zeroes.
• ‘cn’ is left justified and padded with trailing hexadecimal ‘F’ (0xF).
Page 208
• ‘a’, ‘an’ or ‘ans’ are left justified and padded with trailing hexadecimal zeroes.
When data is moved from one entity to another (e.g. card to terminal), it will always be passed in order of
high order to low order, regardless of how it is internally stored. The same rule applies when
concatenating data.
Data Element Names for EMV Contact and Contactless
Name Description Source Format Tag Length
Acquirer Identifier Uniquely identifies the Terminal n 6-11 ‘9F01’ 6

acquirer within each
payment system.
Additional Terminal Indicates the data input and Terminal b ‘9F40’ 5

Capabilities output capabilities of the
terminal.
Amount, Authorized Authorized amount of the Terminal b ‘81’ 6

(Binary) transaction (excluding
adjustments).
Amount, Authorized Authorized amount of the Terminal n 12 ‘9F02’ 6

(Numeric) transaction (excluding
adjustments).
Referred to in this document

as “Transaction Amount”.
Amount, Other (Binary) Secondary amount Terminal b ‘9F04’ 6

associated with the
transaction representing a
cashback amount.
Amount, Other (Numeric) Secondary amount Terminal n 12 ‘9F03’ 6

associated with the
transaction representing a
cashback amount.
Referred to in this document

as “Other Amount”.
Page 209
Amount, Reference Authorized amount Terminal b ‘9F3A’ 4

Currency expressed in the reference
currency.
Application Cryptogram Cryptogram returned by the ICC b ‘9F26’ 8

ICC in response to the
GENERATE AC command.
Application Currency Code Indicates the currency in ICC n3 ‘9F42’ 2

which the account is
managed according to ISO
4217.
Application Currency Indicates the implied ICC n1 ‘9F44’ 1

Exponent position of the decimal point
from the right of the account
represented according to
ISO 4217.
Application Default Action Indicates actions for the ICC ICC b ‘9F52’ 4
to take for certain exception
conditions.
Application Discretionary Issuer or payment system ICC b ‘9F05’ 1-32

Data specified data relating to the
application.
Application Effective Date Date from which the ICC n6 ‘5F25’ 6

application may be used. YYMMDD
Application Expiration Date Date after which application ICC n6 ‘5F24’ 3

expires. YYMMDD
Application File Locator Indicates the location (SFI, ICC Var. ‘94’ <= 252
(AFL) range of records) of the
AEFs related to a given
application.
Page 210
Application Identifier (AID)– Identifies the application as ICC b ‘4F’ 5-16

ICC described in ISO/IEC 7816-
5.
Application Identifier (AID)– Identifies the application as Terminal b ‘9F06’ 5-16

Terminal described in ISO/IEC 7816-
5.
Application Interchange Indicates the capabilities of ICC b ‘82’ 2

Profile the card to support specific
functions in the application.
Application Label Mnemonic associated with ICC an 1-16 ‘50’ 1-16

the AID according to
ISO/IEC 7816-5.
Application Preferred Preferred mnemonic ICC an 1-16 ‘9F12’ 1-16

Name associated with the AID.
Application Primary Valid cardholder account ICC Cn ‘5A’ <= 10

Account Number (PAN) number.
<= 19
Application Primary Identifies and differentiates ICC n2 ‘5F34’ 1

Account Number (PAN) cards with the same PAN.
Sequence Number
Application Priority Indicates the priority of a ICC b ‘87’ 1

Indicator given application or group of
applications in a directory.
Page 211
Application Reference 1-4 currency codes used ICC n3 ‘9F3B’ 2-8

Currency between the terminal and
the ICC when the
Transaction Currency Code
is different from the
Application Currency Code;
each code is 3 digits
according to ISO 4217.
Application Selection For an application in the ICC Terminal At the -- var

Indicator to be supported by an discretion
application in the terminal, of the
the Application Selection terminal.
Indicator indicates whether
This data
the associated AID in the
is not
terminal must match the AID
sent
in the card exactly, including
across
the length of the AID or only
the
up to the length of the AID in
interface.
the terminal. There is only
one Application Selection
Indicator per AID supported
by the terminal.
Application Reference Indicates the implied ICC n1 ‘9F43’ 1-4

Currency Exponent position of the decimal point
from the right of the amount,
for each of the 1-4 reference
currencies represented
Page 212
Application Selection Flag This field is used by ICC b ‘DF62’ 2-32

Canadian issuers if they
want their application to be
displayed for a particular
service. Also known as the
“Canadian Flag”.
Application Transaction Counter maintained by the ICC b ‘9F36’ 2

Counter (ATC) application in the ICC
(incrementing the ATC is
managed by the ICC).
Application Usage Control Indicates issuer's specified ICC b ‘9F07’ 2

restrictions on the
geographic usage and
services allowed for the
application.
Application Version Version number assigned by ICC b ‘9F08’ 2

Number (ICC) the payment system for the
application.
Application Version Version number assigned by Terminal b ‘9F09’ 2

Number (Terminal) the payment system for the
application.
Authorization Code Value generated by the Issuer an 6 ‘89’ 6

issuer for an approved
transaction.
Authorization Response Code that defines the Issuer/ an 2 ‘8A’ 2

Code disposition of a message.
Terminal
Page 213
Authorization Response Cryptogram generated by Issuer b N/A 4 or 8

Cryptogram (ARPC) the issuer and used by the
card to verify that the
response came from the
issuer.
This is part of Issuer

Authentication Data (Tag
91).
Available Offline Spending A calculated field used to ICC n 12 ‘9F5D’ 6

Amount allow the reader to print or
display the amount of offline
spend available on the card.
The card will not allow this
tag to be included in a
record to be read by the
reader or in the response to
GPO unless this tag is
personalized with a value of
1.
Card Additional Processes Indicates card processing ICC b ‘9F68’ 4

(Visa) requirements and
preferences.
Card Authentication Contains the fDDA Version ICC b ‘9F69’ var. 5-

Related Data (Visa) Number and Card 16
Unpredictable Number.
Byte 1: fDDA Version

Number
Byte 2 - 5 : Card
Unpredictable Number
Page 214
Card CVM Limit (Visa) If present, indicates that ICC n 12 ‘9F6B’ 6

when the card and reader
currencies match and a
contactless transaction
exceeds this value, a CVM
is required by the Card.
Card Risk Management List of data objects (tag and ICC b ‘8C’ <= 252
Data Object List 1 (CDOL1) length) to be passed to the
ICC in the first GENERATE
AC command.
Card Risk Management List of data objects (tag and ICC b ‘8D’ <= 252
Data Object List 2 (CDOL2) length) to be passed to the
ICC in the second
Page 215
Card Transaction Qualifiers Used to indicate to the ICC b ‘9F6C’ 2

(Visa) device which CVMs are
requested by the card.
Byte 1
bit 8 1 = Online PIN

Required
bit 7 1 = Signature Required
bit 6 1 = Go Online if Offline

Data Authentication fails and
Reader is online capable.
bit 5 1 = Terminate if Offline

Data Authentication fails and
Reader supports contact
VSDC.
bits 4-1 RFU
Byte 2
bits 8-1 RFU
Cardholder Name Indicates cardholder name ICC ans 2-26 ‘5F20’ 2-26
Cardholder Name Indicates the whole ICC ans 27- ‘9F0B’ 27-45
Extended cardholder name when 45
greater than 26 characters
using the same coding
convention as in ISO 7813.
Cardholder Verification Identifies a method of ICC b ‘8E’ <= 252

Method (CVM) List verification of the cardholder
supported by the
application.
Page 216
Cardholder Verification Indicates the results of the Terminal b ‘9F34’ 3

Method (CVM) Results last CVM performed.
Certification Authority A check value calculated on Terminal b -- 20

Public Key Check Sum the concatenation of all
parts of the Certification
Authority Public Key (RID,
Certification Authority Public
Key Index, Certification
Authority Public Key
Modulus, Certification
Authority Public Key
Exponent) using SHA-1.
Certification Authority Value of the exponent part Terminal b -- 1 or 3

Public Key Exponent of the Certification Authority
Public Key.
Certification Authority Identifies the certification ICC b ‘8F’ 1

Public Key Index authority's public key in
conjunction with the RID.
Certification Authority Identifies the certification Terminal b ‘9F22’ 1

Public Key Index authority's public key in
conjunction with the RID.
Certification Authority Value of the modulus part of Terminal B -- NCA (<=

Public Key Modulus the Certification Authority 248)
Public Key.
Command Template Identifies the data field of a Terminal b ‘83’ var.

command message.
Cryptogram Information Indicates the type of ICC b ‘9F27’ 1

Data cryptogram and the actions
to be performed by the
terminal.
Page 217
Cardholder Exclusive Data Contains data for ICC b ‘9F7C’ var. <=
(CED) (Visa) transmission to the Issuer in 32
MSD transactions with a
cryptogram. Cardholder
Exclusive Data is both an
implementation and Issuer
option.
Inclusion of the Cardholder

Exclusive Data in online
messages is an option for
MSD readers compliant to
this specification.
Cardholder Exclusive Data
will be updateable via an
Issuer script command.
CVC3 (Track1) The CVC3TRACK1 is a 2-byte ICC b ‘9F60’ 2

(Mastercard) cryptogram returned by the
card in the response to the
COMPUTE
CRYPTOGRAPHIC
CHECKSUM command.
CVC3 (Track2) The CVC3TRACK2 is a 2-byte ICC b ‘9F61’ 2

(Mastercard) cryptogram returned by the
card in the response to the
COMPUTE
CRYPTOGRAPHIC
CHECKSUM command.
Data Authentication Code An issuer assigned value ICC b ‘9F45’ 2

that is retained by the
terminal during the
verification process of the
Signed Static Application
Data.
Page 218
DDCARD, TRACK1 If Track 1 Data is present, Terminal ans -- var <=

DDCARD,TRACK1 contains 56
a copy of the discretionary
data field of Track 1 Data as
returned by the card in the
file read using the READ
RECORD command during
a PayPass. Magstripe
transaction (i.e. without UN
(Numeric), ATC,
CVC3TRACK1 and nUN
included).
DDCARD, TRACK2 DDCARD,TRACK2 contains ans -- var <= 8

a copy of the discretionary
data field of Track 2 Data as
returned by the card in the
file read using the READ
RECORD command during
a PayPass. Magstripe
transaction (i.e. without UN
(Numeric), ATC,
CVC3TRACK2 and nUN
included).
Dedicated File (DF) Name Identifies the name of the ICC b ‘84’ 5-16
DF as described in ISO/IEC
7816-4. Usually the same as
the AID.
Default Dynamic Data DDOL to be used for Terminal b -- var.

Authentication Data Object constructing the INTERNAL
List (DDOL) AUTHENTICATE command
if the DDOL in the card is
not present.
Page 219
Default Transaction TDOL to be used for Terminal b -- var.

Certificate Data Object List generating the TC Hash
(TDOL) Value if the TDOL in the
card is not present.
Directory Definition File Identifies the name of a DF ICC b ‘9D’ 5 -16

(DDF) Name associated with a directory.
Directory Discretionary Issuer discretionary part of ICC var. ‘73’ var. <=
Template the directory according to 252
ISO/IEC 7816-5.
Dynamic Data List of data objects (tag and ICC b ‘9F49’ <= 252
Authentication Data Object length) to be passed to the
List (DDOL) ICC in the INTERNAL
AUTHENTICATE command.
Enciphered Personal Transaction PIN enciphered Terminal b -- 8

Identification Number (PIN) at the PIN Pad for online
Data verification or for offline
verification if the PIN Pad
and IFD are not a single
integrated device.
File Control Information Issuer discretionary part of ICC var. ‘BF0C’ <= 222
(FCI) Issuer Discretionary the FCI.
Data
File Control Information Identifies the data object ICC var. ‘A5’ var.
(FCI) Proprietary Template proprietary to this
specification in the FCI
template according to
ISO/IEC 7816-4.
File Control Information Identifies the FCI template ICC var. ‘6F’ <= 252
(FCI) Template according to ISO/IEC 7816-
4.
Page 220
Form Factor Indicator (FFI) Indicates the form factor of ICC b ‘9F6E’ 4
(Visa) the consumer payment
device and the type of
contactless interface over
which the transaction was
conducted. The Form Factor
Indicator is an Issuer option.
If present on the card it must
be present in the
authorization message.
Third Party Data The Third Party Data ICC b ‘9F6E’ var 5-32
(Mastercard) contains proprietary
information from a third
party. If present in the
contactless card, the Third
Party Data is returned in the
File Control Information
Template.
Third Party Data can

communicate the Device
Type to the terminal even
when there is no proprietary
data.
Third Party Data (Voyager) The Third Party Data ICC b ‘9F6E’ var 5 -
contains proprietary 32
information from a third
party. If present in the
contact or contactless card,
the Third Party Data is
returned in the File Control
Information Template.
Page 221
ICC Dynamic Number Time-variant number ICC b ‘9F4C’ 2 -8

generated by the ICC, to be
captured by the terminal.
Integrated Circuit Card ICC PIN Encipherment ICC b ‘9F2D’ NI

(ICC) PIN Encipherment Public Key certified by the
Public Key Certificate issuer.
Integrated Circuit Card ICC PIN Encipherment ICC b ‘9F2E’ 1 or 3

(ICC) PIN Encipherment Public Key Exponent used
Public Key Exponent for PIN encipherment.
Integrated Circuit Card Remaining digits of the ICC ICC b ‘9F2F’ NPE − NI
(ICC) PIN Encipherment PIN Encipherment Public + 42
Public Key Exponent Key Modulus.
Integrated Circuit Card ICC Public Key certified by ICC b ‘9F46’ NI

(ICC) PIN Encipherment the issuer.
Public Key Remainder
Integrated Circuit Card ICC Public Key Exponent ICC b ‘9F47’ 1 to 3

(ICC) Public Key Certificate used for the verification of
the Signed Dynamic
Application Data.
Integrated Circuit Card Remaining digits of the ICC ICC b ‘9F48’ NPE − NI
(ICC) Public Key Public Key Modulus. + 42
Remainder
Interface Device (IFD) Unique and permanent Terminal an 8 ‘9F1E’ 8

Serial Number serial number assigned to
the IFD by the manufacturer.
Page 222
Issuer Action Code–Default Specifies the issuer's ICC b ‘9F0D’ 5

conditions that cause a
transaction to be rejected if
it might have been approved
online, but the terminal is
unable to process the
transaction online.
Issuer Action Code–Denial Specifies the issuer's ICC b ‘9F0E’ 5

conditions that cause the
denial of a transaction
without attempt to go online.
Issuer Action Code–Online Specifies the issuer's ICC b ‘9F0F’ 5

conditions that cause a
transaction to be transmitted
online.
Issuer Application Data Contains proprietary ICC b ‘9F10’ <= 32

application data for
transmission to the issuer in
an online transaction.
Issuer Authentication Data Data sent to the card for Issuer b ‘91’ 8-16
online issuer authentication.
Issuer Code Table Index Indicates the code table ICC n2 ‘9F11’ 1
according to ISO 8859 for
displaying the Application
Preferred Name.
Issuer Country Code Indicates the country of the ICC n3 ‘5F28’ 2

issuer according to ISO
3166.
Page 223
Issuer Country Code Issuer Country Code (alpha ICC a2 ‘5F55’ 2

(Alpha 2) 2 format) used as part of the
Candidate List editing for US
Common Debit AIDs.
Issuer Country Code Issuer Country Code (alpha ICC a3 ‘5F56’ 3

(Alpha 3) 3 format).
Issuer Identification Tag is used as part of the ICC b ‘42’ 3

Number (IIN or BIN) Candidate List editing for US
Common Debit AIDs. The
acronym IIN may be used
interchangeably with BIN.
Issuer Public Key Issuer public key certified by ICC b ‘90’ NCA
Certificate a certification authority.
Issuer Public Key Exponent Issuer public key exponent ICC b ‘9F32’ 1-3
used for the verification of
the Signed Static Application
Data and the ICC Public Key
Certificate.
Issuer Public Key Remaining digits of the ICC b ‘92’ NI − NCA

Remainder Issuer Public Key Modulus. + 36
Issuer Script Command Contains a command for Issuer b ‘86’ <= 261
transmission to the ICC.
Issuer Script Identifier Identification of the Issuer Issuer b ‘9F18’ 4

Script.
Issuer Script Results Indicates the result of the Terminal b ‘9F5B’ var.
card script processing.
Page 224
Issuer Script Template 1 Contains proprietary issuer Issuer b ‘71’ var.

data for transmission to the
ICC before the second
Issuer Script Template 2 Contains proprietary issuer Issuer b ‘72’ var.

data for transmission to the
ICC after the second
Issuer URL The URL provides the ICC ans ‘5F50’ var.
location of the Issuer’s
Library Server on the
Internet.
Language Preference 1-4 languages stored in ICC an 2 ‘5F2D’ 2-8

order of preference, each
represented by 2
alphabetical characters
Example:
en=English
es=Spanish
fr=French
Last Online Application ATC value of the last ICC b ‘9F13’ 2

Transaction Counter (ATC) transaction that went online.
Register
Page 225
Lower Consecutive Offline Issuer-specified preference ICC b ‘9F14’ 1

Limit for the maximum number of
consecutive offline
transactions for this ICC
application allowed in a
terminal with online
capability.
Magstripe Application Version number assigned by ICC b ‘9F6C’ 2

Version Number the payment system for the
(Mastercard) specific PayPass. Magstripe
functionality of the
application.
Magstripe Application Version number assigned by Terminal b ‘9F6D’ 2

Version Number the payment system for the
(Mastercard) specific PayPass. Magstripe
functionality of the
application.
Maximum Target Value used in terminal risk Terminal -- -- --

Percentage to be used for management for random
Biased Random Selection transaction selection.
Merchant Category Code Classifies the type of Terminal n4 ‘9F15’ 2

business being done by the
merchant, represented
according to ISO 8583:1993
for Card Acceptor Business
Code.
Merchant Identifier When concatenated with the Terminal ans 15 ‘9F16’ 15

Acquirer Identifier, uniquely
identifies a given merchant.
Page 226
Message Type Indicates whether the batch Terminal n2 -- 1

data capture record is a
financial record or advice.
Page 227
MSD Offset (Visa) • Specifies the offset from ICC b ‘9F67’ 1

the beginning of Track 2
Equivalent Data (Tag ‘57’) to
the first digit/nibble of the
dCVV.
• Implementations may
support updating of the MSD
Offset via an Issuer Script
command. If the MSD Offset
is not personalized or
personalized with a value of
zero, Track 2 Equivalent
Data (Tag ‘57’) will be
returned exactly as it was
personalized.
• Personalizing the MSD

Offset with a value greater
than zero indicates that the
dCVV and ATC will be
calculated and inserted into
Track 2 Equivalent Data for
MSD transactions without a
cryptogram.
• If the implementation
supports insertion of the
ATC in Track 2 Equivalent
Data for qVSDC and MSD
transactions, the high-order
bit of the MSD Offset is used
to activate this functionality:
bit 8
1 = Insert ATC into Track 2

Equivalent Data for all
qVSDC and MSD
transactions
Page 228

bits 7-1
1 = Offset from the

beginning of Track2
Equivalent Data to the first
digit of the CVV placeholder
PayPass–Magstripe Indicates for each AID Terminal -- -- --

Indicator whether the PayPass.
Magstripe profile is
supported or not by the
PayPass reader. Its value is
implementation specific.
Personal Identification Secret key of a symmetric Terminal -- -- --

Number (PIN) Pad Secret algorithm used by the PIN
Key Pad to encipher the PIN and
by the card reader to
decipher the PIN if the PIN
Pad and card reader are not
integrated.
PIN Try Counter Number of PIN tries ICC b ‘9F17’ 1

remaining.
POS Entry Mode Indicates the method by Terminal n2 ‘9F39’ 1

which the PAN was entered,
according to the first two
digits of the ISO 8583:1987
POS Entry Mode.
Processing Options Data Contains a list of terminal ICC b ‘9F38’ var.

Object List (PDOL) resident data objects (tags
and lengths) needed by the
ICC in processing the GET
PROCESSING OPTIONS
command.
Page 229
Service Code Service code as defined on ICC n3 ‘5F30’ 2

Tracks 1 and 2.
Short File Identifier (SFI) Identifies the SFI to be used ICC b ‘88’ 1
in the commands related to
a given AEF or DDF. The
SFI data object is a binary
field with the three high
order bits set to zero.
Signed Dynamic Digital signature on critical ICC b ‘9F4B’ NIC

Application Data application parameters for
dynamic data authentication.
Signed Static Application Digital signature on critical ICC b ‘93’ NI

Data application parameters for
static data authentication.
Static Data Authentication List of tags of primitive data ICC -- ‘9F4A’ var.
Tag List objects defined in this
specification whose value
fields are to be included in
the Signed Static or
Dynamic Application Data.
Target Percentage to be Value used in terminal risk Terminal -- -- --

used for Random Selection management for random
transaction selection.
Terminal Action Code– Specifies the acquirer’s Terminal b -- 5

Default conditions that cause a
transaction to be rejected if
it might have been approved
online, but the terminal is
unable to process the
transaction online.
Page 230

Denial conditions that cause the
denial of a transaction
without attempt to go online.

Online conditions that cause a
transaction to be transmitted
online.
Terminal Capabilities Indicates the card data Terminal b ‘9F33’ 3

input, CVM, and security
capabilities of the terminal.
Terminal Country Code Indicates the country of the Terminal n3 ‘9F1A’ 2

terminal, represented
Terminal Contactless Floor Indicates the transaction Terminal n 12 -- 6

Limit (Visa, Mastercard) amount limit for the related
AID above which
transactions must be
authorized online.
Terminal Contactless Indicates the transaction Terminal n 12 -- 6

Transaction Limit (Visa, amount limit for the related
Mastercard) AID above which the
selection of the AID on the
card is not allowed. It is
permitted to attempt the
transaction over another
interface.
Page 231
Terminal CVM Required If a contactless transaction Terminal n 12 -- 6

Limit (Visa, Mastercard) exceeds this value, a CVM
is required by the Reader.
Online PIN and Signature

are CVMs defined for Visa.
Online PIN, Signature and

NO CVM are CVMs defined
for Mastercard.
Terminal Contactless Floor Indicates for the related AID Terminal -- -- --

Exceeded Flag if the Terminal Contactless
(Mastercard) Floor Limit is exceeded.
Terminal Contactless Indicates for the related AID Terminal -- -- --

Transaction Limit if the Terminal Contactless
Exceeded Flag Transaction Limit is
(Mastercard) exceeded.
Terminal CVM Required Indicates for the related AID Terminal -- -- --

Limit Exceeded Flag if the Terminal CVM
(Mastercard) Required Limit is exceeded.
Terminal Floor Limit Indicates the floor limit in the Terminal b ‘9F1B’ 4
terminal in conjunction with
the AID.
Terminal Identification Designates the unique Terminal an 8 ‘9F1C’ 8

location of a terminal at a
merchant.
Terminal Risk Management Application-specific value Terminal b ‘9F1D’ 1-8

Data used by the card for risk
management purposes.
Page 232
Terminal Transaction Indicates reader capabilities, Terminal b ‘9F66’ 4

Qualifiers requirements, and
preferences to the card.
Byte 1
8 '1' – Contactless
magstripe (MSD) supported
'0' – Contactless
magstripe (MSD) not
supported
7 '1' – Contactless VSDC

supported
'0' – Contactless VSDC

not supported
6 '1' – Contactless qVSDC

supported
'0' – Contactless qVSDC

not supported
5 '1' – Contact VSDC (EMV

chip) supported
'0' – Contact VSDC (EMV

chip) not supported
4 '1' – Reader is Offline

Only
'0' – Reader is Online

Capable
3 '1' – Online PIN supported
'0' – Online PIN not

supported
2 '1' – Signature supported
'0' – Signature not

supported
Page 233

1 – RFU
Byte 2
8 '1' – Online cryptogram

required
'0' – Online cryptogram

not required
7 '1' – CVM required
'0' – CVM not required
6-1 – RFU
Byte 3
8-1 – RFU
Byte 4
8-1 – RFU
Terminal Type Indicates the environment of Terminal n2 ‘9F35’ 1

the terminal, its
communications capability,
Terminal Verification Status of the different Terminal b ‘95’ 5

Results functions as seen from the
terminal.
Threshold Value for Biased Value used in terminal risk Terminal -- -- --

Random Selection management for random
transaction selection.
Page 234
Track 1 Data The Track 1 Data may be ICC ans ‘56’ var. <=
present in the file read using 76
(Mastercard)
the READ RECORD
command during a
PayPass. Magstripe
transaction. The PayPass
reader copies the required
digits of the UN (Numeric),
CVC3TRACK1, ATC and
nUN into the discretionary
data field of the Track 1
Data and stores the
modified Track 1 Data in the
Data Record to be sent to
the terminal.
Track 1 Number of ATC The value of NATCTRACK1 ICC b ‘9F64’ 1

Digits (NATCTRACK1) represents the number of
digits of the ATC to be
included in the discretionary
Data.
Track 1 Discretionary Data Discretionary part of Track 1 ICC an ‘9F1F’ var.

according to ISO/IEC 7813.
Page 235
Track 2 Equivalent Data Contains the data elements ICC b ‘57’ <= 40
of the Track 2 according to
n, <= 40
ISO/IEC 7813, excluding
b
start sentinel, end sentinel
and LRC, as follows: n4
Primary Account Number n3
Field Separator (hex ‘D’) n, var.
Expiration Date (YYMM)
Service Code
Discretionary Data (defined

by individual payment
systems)
Pad with hex ‘F’ if needed to

ensure whole bytes.
Track 2 Data (Mastercard) The Track 2 Data is present ICC b ‘9F6B’ var. <=
in the file read using the 19
READ RECORD command
during a PayPass.
Magstripe transaction. The
PayPass reader copies the
required digits of the UN
(Numeric), CVC3TRACK2,
ATC and nUN into the
discretionary data field of
the Track 2 Data and stores
the modified Track 2 Data in
the Data Record to be sent
to the terminal.
Page 236
Track 2 Bitmap for CVC3 PCVC3TRACK2 indicates to ICC b ‘9F65’ 2

(PCVC3TRACK2)(Mastercard) the PayPass reader the
positions in the discretionary
Data where the qTRACK2
CVC3TRACK2 digits must
be copied.
Track 2 Bitmap for UN and PUNATCTRACK2 indicates ICC b ‘9F66’ 2

ATC (PUNATCTRACK2) to the PayPass reader the
(Mastercard) positions in the discretionary
Data where the nUN UN
(Numeric) digits and
tTRACK2 ATC digits must
be copied.
Track 2 Number of ATC The value of NATCTRACK2 ICC b ‘9F67’ 1

Digits (NATCTRACK2) represents the number of
digits of the ATC to be
included in the discretionary
Data.
Transaction Amount Clearing amount of the Terminal n 12 -- 6

transaction, including tips
and other adjustments.
Transaction Certificate Result of a hash function Terminal b ‘98’ 20

(TC) Hash Value specified in Book 2, Annex
B3.1 of the EMVCo
Specifications.
Page 237
Transaction Certificate List of data objects (tag and ICC b ‘97’ var. <=
Data Object List (TDOL) length) to be used by the 252
terminal in generating the
TC Hash Value.
Transaction Currency Code Indicates the currency code Terminal n3 ‘5F2A’ 2

of the transaction according
to ISO 4217.
Transaction Currency Indicates the implied Terminal n1 ’5F36’ 1

Exponent position of the decimal point
from the right of the
transaction amount
represented according to
ISO 4217.
Transaction CVM Data object used to indicate Terminal -- -- --

(Mastercard) to the terminal the outcome
of the CVM Selection
function. Possible values
are:
• NO CVM
• Signature
• Online PIN
The coding of the value is

implementation specific.
Transaction Date Local date that the Terminal n6 ‘9A’ 3

transaction was authorized. YYMMDD
Page 238
Transaction Outcome Data object used to indicate Terminal -- -- --

to the terminal the outcome
(Mastercard)
of the transaction
processing. Possible values
are:
• Approved. The PayPass

reader is satisfied that
the transaction is
acceptable with the
selected card application
and wants the
transaction to be offline
approved.
• Online Request. The

PayPass reader has
found that the transaction
requires an online
authorization.
• Declined. The PayPass

reader has found that the
transaction is not
acceptable with the
and wants the
transaction to be offline
declined.
• Try Another Interface.

The PayPass reader is
unable to complete the
transaction with the
but knows that another
interface (e.g. contact or
magstripe) may be
available.
Page 239
• End Application. The

PayPass reader
experienced an
application error (e.g.
missing data)
• The coding of the value

is implementation
specific.
Transaction Personal Data entered by the Terminal b ‘99’ var.

Identification Number (PIN) cardholder for the purpose
Data of the PIN verification.
Transaction Reference Code defining the common Terminal n3 ‘9F3C’ 2

Currency Code currency used by the
terminal in case the
Transaction Currency Code
is different from the
Application Currency Code.
Transaction Reference Indicates the implied Terminal n1 ‘9F3D’ 1

Currency Exponent position of the decimal point
from the right of the
transaction amount, with the
Transaction Reference
Currency Code represented
Transaction Sequence Counter maintained by the Terminal n 4-8 ‘9F41’ 2-4

Counter terminal that is incremented
by one for each transaction.
Transaction Status Indicates the functions Terminal b ‘9B’ 2

Information performed in a transaction.
Transaction Time Local time that the Terminal n6 ‘9F21’ 3

transaction was authorized. HHMMSS
Page 240
Transaction Type Indicates the type of Terminal n2 ‘9C’ 1

financial transaction,
represented by the first two
digits of ISO 8583:1987
Processing Code.
Unpredictable Number Value to provide variability Terminal b ‘9F37’ 4

and uniqueness to the
generation of a cryptogram.
Unpredictable Number The UDOL is the DOL that ICC b ‘9F69’ var.
Data Object List (UDOL) specifies the data objects to
be included in the data field
(Mastercard)
of the COMPUTE
CRYPTOGRAPHIC
CHECKSUM command. The
UDOL must at least include
the UN (Numeric). The
UDOL is not mandatory for
the card. There will always
be a Default UDOL,
including as its only entry
the tag and length of the UN
(Numeric) (Tag '9F6A').
Unpredictable Number Unpredictable number Terminal n ‘9F6A’ 8

(Numeric) (Mastercard) generated by the PayPass
reader during a PayPass.
Magstripe Transaction. The
UN (Numeric) is passed to
the card in the data field of
the COMPUTE
CRYPTOGRAPHIC
CHECKSUM command.
The (8-nUN) most significant

digits must be set to zero.
Page 241
Upper Consecutive Offline Issuer-specified preference ICC b ‘9F23’ 1

Limit for the maximum number of
consecutive offline
transactions for this ICC
application allowed in a
terminal without online
capability.
VLP Available Funds (Visa) A counter that may be ICC n 12 ‘9F79’ 6

decremented (for LV or
CTTA the funds may be
added to CTTA) by the
Amount Authorized when an
offline low value qVSDC
transaction takes place.
VLP Funds Limit (Visa) Value to which VLP ICC n 12 ‘9F77’ 6

Available Funds is reset.
VLP Reset Threshold If the Amount Authorized is ICC n 12 ‘9F6D’ 6

(Visa) greater than VLP Available
Funds minus this threshold,
the card requests online
processing.
VLP Single Transaction Limit for a single ICC n12 ‘9F78’ 6

Limit (Visa) transaction.
Page 242
Reference Materials
Note: Some of the information is extracted from the EMV 4.3 specification.
Refer to Appendix B Reference.
Page 243
EMV Implementation Tandem Supplemental Guide EMV Testing Parameters
EMV Testing Parameters

Amex Integration Testing Parameters
Amex Credit Contact Testing Parameters
Tag Description Amex
9F35 Terminal Type Kernel config
9F33 Terminal Capabilities Kernel config
9F40 Additional Terminal Capabilities Kernel config
9F15 Merchant Category Code Assigned by Acq
9F06 Application Identifier (AID) A00000002501
Default AID Label American Express Credit
9F1A Terminal Country Code 840
5F2A Transaction Currency Code 840
5F36 Transaction Currency Exponent 2
Default DDOL 9F3704
97 Default TDOL -
TAC, Default DC 50 FC 98 00
TAC, Denial 00 10 00 00 00
TAC, Online DE 00 FC 98 00
9F1B Terminal Floor Limit (EMV) 0.00*
Page 244
EMV Random Selection 0.00*

Threshold
EMV Random Selection 99

Maximum %
EMV Random Selection Target 99

%
Partial Name Selection Flag Y
Allow Fallback Flag Y*
Allow PIN Bypass N
9F09 Application Version Number 0x0001

(Prim.)
9F09 Application Version Number -

(Sec.)
* Downloaded as part of the Merchant Services EMV Parameter Download
Amex Credit Contactless Testing Parameters

TAC, Default DC 50 FC 98 00
TAC, Denial 00 10 00 00 00
TAC, Online DE 00 FC 98 00
Contactless Floor Limit 0.00
Contactless CVM Required Limit 10.00
Contactless Transaction Limit 15.00
Page 245
Enable ExpressPay MSD Y
Enable ExpressPay EMV Y
UnionPay via Discover Integration Testing

Parameters
UnionPay Credit and Debit Contact Testing
Parameters
Tag Description UnionPay Credit UnionPay Debit
9F35 Terminal Type Kernel config Kernel config
9F33 Terminal Capabilities Kernel config Kernel config
9F40 Additional Terminal Capabilities Kernel config Kernel config
9F15 Merchant Category Code Assigned by Acq Assigned by Acq
9F06 Application Identifier (AID) A000000333010102 A000000333010101
Default AID Label UnionPay CREDIT UnionPay DEBIT
9F1A Terminal Country Code 840 840
5F2A Transaction Currency Code 840 840
5F36 Transaction Currency Exponent 2 2
Default DDOL 9F3704 9F3704
97 Default TDOL N/A N/A
TAC, Default D8 40 00 A8 00 D8 40 00 A8 00
TAC, Denial 00 10 00 00 00 00 10 00 00 00
Page 246
TAC, Online D8 40 04 F8 00 D8 40 04 F8 00
9F1B Terminal Floor Limit (EMV) 0.00* 0.00*
EMV Random Selection 000 000

Threshold

Maximum %
EMV Random Selection Target 99 99

%
Partial Name Selection Flag Y Y
Allow Fallback Flag Y Y
Allow PIN Bypass Y Y
Acquirer ID Assigned by Acq Assigned by Acq
9F09 Application Version Number 0x0020 0x0020

(Prim.)

(Sec.)
*Downloaded as part of the Merchant Services EMV Parameter Download
UnionPay Credit and Debit Contactless Testing

Parameters
Contactless Floor Limit 0.00 0.00
Page 247
Contactless CVM Required Limit $250 CAD in $250 CAD in Canada

Canada
$100 USD in the US
$100 USD in the
US
Contactless Transaction Limit 99999999999 99999999999
9F66 Terminal Transaction Qualifier Terminal Terminal
UnionPay Quasi Credit and US Common Contact

Testing Parameters
Tag Description UnionPay Quasi Credit UnionPay US Common
9F40 Additional Terminal Kernel config Kernel config

Capabilities
9F06 Application Identifier A000000333010103 A000000333010108

(AID)
Default AID Label UnionPay QUASICREDIT UnionPay COMMON
5F2A Transaction Currency 840 840

Code
5F36 Transaction Currency 2 2

Exponent
Page 248
97 Default TDOL N/A N/A
TAC, Default D8 40 00 A8 00 D8 40 00 A8 00
TAC, Denial 00 10 00 00 00 00 10 00 00 00
TAC, Online D8 40 04 F8 00 D8 40 04 F8 00
9F1B Terminal Floor Limit 0.00* 0.00*

(EMV)

Threshold

Maximum %

Target %
Partial Name Selection Y Y

Flag
9F09 Application Version 0x0020 0x0020

Number (Prim.)
9F09 Application Version 0x0020 0x0020

Number (Sec.)
Page 249
UnionPay Quasi Credit and US Common Contactless

Testing Parameters
Contactless CVM $250 CAD in Canada $250 CAD in Canada

Required Limit
$100 USD in the US $100 USD in the US
Contactless Transaction 99999999999 99999999999

Limit
9F66 Terminal Transaction Terminal Terminal

Qualifier
Page 250
Debit Network Alliance Integration Testing

Parameters
Debit Network Alliance Debit Contact Testing
Parameters
Tag Description DNA Debit
Default AID Label DNA Debit
Default DDOL 9F3704
97 Default TDOL -
TAC, Default FC 50 AC A0 00
TAC, Denial 00 00 00 00 00
TAC, Online FC 50 BC F8 00
Page 251

Threshold

Maximum %

%
Allow PIN Bypass N

(Prim.)

(Sec.)
Debit Network Alliance Debit Contactless Testing

Parameters
TAC, Default N/A
TAC, Denial N/A
TAC, Online N/A
Contactless Floor Limit N/A
Contactless CVM Required Limit N/A
Page 252
Contactless Transaction Limit N/A
Discover Integration Testing Parameters

Discover Contact Testing Parameters
Tag Description Discover Credit Discover US Debit
Default AID Label Discover Credit Discover Debit
97 Default TDOL
TAC, Default DC 00 00 20 00 DC 00 00 20 00
TAC, Denial 00 10 00 00 00 00 10 00 00 00
TAC, Online FC E0 9C F8 00 FC E0 9C F8 00
9F1B Terminal Floor Limit (EMV) 0.00* 0.00*
Page 253

Threshold

Maximum %
EMV Random Selection Target 99 99

%

(Prim.)

(Sec.)
Discover Contactless Testing Parameters

Contactless Floor Limit 0.00 -
Contactless CVM Required Limit 20.00 -
Contactless Transaction Limit 100.00 -
Terminal Transaction Qualifier Defined by HW Vendor -
Page 254
Interac Integration Testing Parameters

Interac Debit Contact Testing Parameters
The Interac EMV AID is only permitted for Canadian POS solutions. US POS solutions are not coded to
support Interac AID. Interac transactions through US POS solutions, where the presented Interac card
supports Visa Debit, process as EMV using the Visa Global AID. If the Interac card does not support Visa
debit, then the Interac card must be processed by magnetic stripe.
Tag Description Interac
Default AID Label Interac
Default DDOL 9F3704
97 Default TDOL -
TAC, Default FC 50 F8 A8 F0
TAC, Denial 10 10 58 00 00
TAC, Online FC F8 E4 B8 70
9F1B Terminal Floor Limit (EMV) 0.00**
Page 255
EMV Random Selection 0.00**

Threshold

Maximum %

%
Allow Fallback Flag Y**
Allow PIN Bypass N

(Prim.)

(Sec.)
**Downloaded as part of the Merchant Services EMV Parameter Download
Interac Debit Contactless Testing Parameters

TAC, Default 00 00 00 00 00
TAC, Denial 00 00 00 00 00
TAC, Online 00 00 00 00 00
Merchant Type Indicator 03
Terminal Option Status E0 00
Contactless Floor Limit $100.00
Page 256
Contactless Receipt Required $50.00

Limit
Contactless Transaction Limit $80.00
JCB Integration Testing Parameters

JCB Credit Contact Testing Parameters
Tag Description JCB
Default AID Label JCB Credit
Default DDOL 9F3704
97 Default TDOL -
TAC, Default FC 60 24 A8 00
TAC, Denial 00 10 00 00 00
TAC, Online FC 60 AC F8 00
Page 257
Tag Description JCB

Threshold

Maximum %

%
Allow PIN Bypass N

(Prim.)

(Sec.)
JCB Credit Contactless Testing Parameters

Tag Description US Region Canada region
Contactless CVM Required Limit 20.00 100.00
Contactless Transaction Limit 100.00 -
Page 258
Mastercard Integration Testing Parameters

Mastercard Credit Contact Testing Parameters
Tag Description Mastercard Credit
9F53 Transaction Category Code ‘R’
Default AID Label Mastercard Credit
Default DDOL 9F3704
97 Default TDOL 9F02065F2A029A039C0195059F3704
TAC, Default FC 50 B8 A0 00
TAC, Denial 00 00 00 00 00
TAC, Online FC 50 B8 F8 00

Threshold
Page 259

Maximum %

%
Allow PIN Bypass N

(Prim.)

(Sec.)
Mastercard Credit Contactless Testing Parameters

TAC, Default FC 50 80 88 00
TAC, Denial 00 00 00 00 00
TAC, Online FC 50 80 88 00
Enable MChip Y
Enable MStripe Y
9F1B Contactless Floor Limit 10.00
Contactless CVM Required Limit 25.00
Contactless Transaction Limit 50.00
Page 260
9F33 Contactless Terminal Capabilities Kernel config

CVM Req
9F33 Contactless Terminal Capabilities Kernel config

CVM NotReq
Mastercard Debit Contact Testing Parameters

Tag Description International Maestro US Maestro
9F35 Terminal Kernel config Kernel config

Type
9F33 Terminal Kernel config Kernel config

Capabilities
9F40 Additional Kernel config Kernel config

Terminal
Capabilities
9F15 Merchant Assigned by Acq Assigned by Acq

Category
Code
9F53 Transaction ‘R’ ‘R’

Category
Code
9F06 Application A0000000043060 A0000000042203

Identifier
(AID)
Default AID Maestro DEBIT MASTERCARD

Label
9F1A Terminal 840 840

Country
Code
Page 261
5F2A Transaction 840 840

Currency
Code
5F36 Transaction 2 2
Currency
Exponent
Default 9F3704 9F3704

DDOL
97 Default 9F02065F2A029A039C0195059F3704 9F02065F2A029A039C0195059F3704

TDOL
TAC, FC 50 BC A0 00 FC 50 BC A0 00
Default
TAC, Denial 00 00 00 00 00 00 00 00 00 00
TAC, Online FC 50 BC F8 00 FC 50 BC F8 00
9F1B Terminal 0.001 0.00*

Floor Limit
(EMV)
EMV 0.001 0.00*

Random
Selection
Threshold
EMV 99 99
Random
Selection
Maximum %
Page 262
EMV 99 99
Random
Selection
Target %
Partial Y Y
Name
Selection
Flag
Allow Y1 Y*
Fallback
Flag
Allow PIN N N
Bypass
9F09 Application 0x0002 0x0002

Version
Number
(Prim.)
9F09 Application - -
Version
Number
(Sec.)
Mastercard Debit Contactless Testing Parameters

Tag Description International US Maestro
Maestro
TAC, Default FC 50 BC A0 FC 50 BC A0 00
00
Page 263
Tag Description International US Maestro

Maestro
TAC, Denial 00 00 00 00 00 00 00 00 00 00
TAC, Online FC 50 BC F8 FC 50 BC F8 00
00
Enable MChip Y Y
Enable MStripe Y Y
Contactless Transaction Limit 0.00 0.00
Contactless Terminal Capabilities Kernel config Kernel config

CVM Req
Contactless Terminal Capabilities Kernel config Kernel config

CVM NotReq
Visa Integration Testing Parameters

The Visa parameters are used for ChaseNet.
Visa Credit Contact Testing Parameters

Tag Description Visa Credit Visa Electron
Page 264
Default AID Label Visa Credit Visa Electron
97 Default TDOL 9F0206 9F0206
TAC, Default DC 40 00 A8 00 DC 40 00 A8 00
TAC, Denial 00 10 00 00 00 00 10 00 00 00
TAC, Online DC 40 04 F8 00 DC 40 04 F8 00
9F1B Terminal Floor Limit (EMV) 0.00* 0.00
EMV Random Selection 0.00* 0.00

Threshold
EMV Random Selection Maximum 99 99

%
EMV Random Selection Target % 99 99
Allow Fallback Flag Y* Y
Allow PIN Bypass N Y
9F09 Application Version Number 0x008C 8C

(Prim.)
9F09 Application Version Number 0x0096 96

(Sec.)
Page 265
Visa Credit Contactless Testing Parameters

TAC, Default DC 40 00 A8 00 DC 40 00 A8 00
TAC, Denial 00 10 00 00 00 00 10 00 00 00
TAC, Online DC 40 04 F8 00 DC 40 04 F8 00
Contactless Transaction Limit 0.00 0.00
9F66 Visa TTQ Terminal Terminal
Visa Debit Contact Testing Parameters

Tag Description Debit Visa Interlink US Common Debit
International
9F35 Terminal Type Kernel config Kernel config Kernel config
9F33 Terminal Capabilities Kernel config Kernel config Kernel config
9F40 Additional Terminal Kernel config Kernel config Kernel config

Capabilities
9F15 Merchant Category Assigned by Acq Assigned by Acq Assigned by Acq

Code
9F06 Application Identifier A0000000031010 A0000000033010 A0000000980840

(AID)
Default AID Label VISA DEBIT INTERLINK US DEBIT
9F1A Terminal Country 840 840 840

Code
Page 266

International
5F2A Transaction Currency 840 840 840

Code
5F36 Transaction Currency 2 2 2

Exponent
Default DDOL 9F3704 9F3704 9F3704
97 Default TDOL 9F0206 9F0206 9F0206
TAC, Default DC 40 00 A8 00 DC 40 00 A8 00 DC 40 00 A8 00
TAC, Denial 00 10 00 00 00 00 10 00 00 00 00 10 00 00 00
TAC, Online DC 40 04 F8 00 DC 40 04 F8 00 DC 40 04 F8 00
9F1B Terminal Floor Limit 0.00* 0.00* 0.00*

(EMV)
EMV Random 0.00* 0.00* 0.00*

Selection Threshold
EMV Random 99 99 99
Selection Maximum
%
EMV Random 99 99 99
Selection Target %
Partial Name Y Y Y
Selection Flag
Allow Fallback Flag Y* Y* Y*
Allow PIN Bypass N N N
9F09 Application Version 0x008C 0x008C 0x008C

Number (Prim.)
Page 267

International
9F09 Application Version 0x0096 0x0096 0x0096

Number (Sec.)
Visa Debit Contactless Testing Parameters

International
TAC, Default DC 40 00 A8 00 DC 40 00 A8 -
00
TAC, Denial 00 10 00 00 00 00 10 00 00 00 -
TAC, Online DC 40 04 F8 00 DC 40 04 F8 -
00
Contactless Floor 0.00 0.00 -

Limit
Terminal CVM 0.00 0.00 -

Required Limit
Contactless CVM 0.00 0.00 -

Required Limit
9F66 Visa TTQ Terminal Terminal Terminal
Page 268
Wright Express Integration Testing

Parameters
Wright Express Credit Contact Testing Parameters
Tag Description Wright Express Credit
Default AID Label Wright Express Credit
Transaction Currency Exponent
Default DDOL 9F3704
Default TDOL Not Required
TAC - Default BC 50 FC 80 00
TAC, Denial 00 00 00 00 00
TAC, Online BC D0 FC 98 00
9F1B Terminal Floor Limit (EMV) 0.00
Page 269
Tag Description Wright Express Credit
EMV Random Selection Threshold 0.00
EMV Random Selection Maximum %
EMV Random Selection Target %
Partial Name Selection Flag
Allow Fallback Flag Y
9F09 Application Version Number (Prim.) 0x0002
9F09 Application Version Number (Sec.)
Voyager Integration Testing Parameters

Voyager Credit Contact Testing Parameters
Tag Description Voyager Credit
9F06 Application Identifier (AID) A0000000049999,

A0000000049999C00016
Default AID Label Voyager Credit
Page 270
Tag Description Voyager Credit
Transaction Currency Exponent 2
Default DDOL 9F3704
Default TDOL Not Required
TAC - Default FE 50 BC 80 00
TAC, Denial 00 00 00 00 00
TAC, Online FE 50 BC 98 00
9F1B Terminal Floor Limit (EMV) 0.00
EMV Random Selection Threshold 0.00
EMV Random Selection Maximum %
EMV Random Selection Target %
Allow Fallback Flag Y
9F09 Application Version Number (Prim.) 0x0002
9F09 Application Version Number (Sec.)
Page 271
EMV Implementation Tandem Supplemental Guide Appendix
Appendix
List of appendices
Appendix A Glossary
Appendix B Reference
• Answer to Reset
• ASCII Chart
• BCD to ASCII Conversion
• Canadian Processing
• EMV Chip Commands
• EMV Reference Tools
Appendix A Glossary
Abbreviations
Term Description
AAC Application Authentication Cryptogram
ABM Automated Banking Machine
AC Application Cryptogram
ADA Application Default Action
ADF Application Dedicated File
ADVT Acquirer Device Validation Tool Kit.
AEIPS American Express Integrated Circuit Card Payment Specification
Page 272
Term Description
AFL Application File Locator
AID Application Identifier
AIP Application Interchange Profile
APDU Application Protocol Data Unit
API Application Program Interface
ARC Authorization Response Code
ARPC Authorization Response Cryptogram
ARQC Authorization Request Cryptogram
ASF Application Selection Flag
ASI Application Selection Indicator
ATC Application Transaction Counter
ATM Automated Teller Machine
ATR Answer To Reset
AUC Application Usage Control
BCD Binary Coded Decimal
BER Basic Encoding Rules
BIN Bank Identification Number
CA Certificate Authority
CAA Card Action Analysis
CAD Card Acceptance Device
CAM Card Authentication Method
Page 273
Term Description
CAP Card Authentication Program
C-APDU Command. Application Protocol Data Unit
CAPK Certificate Authority Public Key
CAPK File Certificate Authority Public Key File
CAT Cardholder Activated Terminal
CCC Compute Cryptographic Checksum
CCD Common Core Definitions
CCRT Chip Compliance Reporting Tool
CDA Combined Dynamic Data Authentication/Generate AC
CDET Contactless Device Evaluation Toolkit
CDOL1 Card Data Object List 1
CDOL2 Card Data Object List 2
Checksum Checksum
CIAC Card Issuer Actions Codes
CID Cryptogram Information Data
CLA Class Byte of the Command Message
CLF Contactless Frontend
CNP Card Not Present
CPA Common Payment Application
CPLC Card Production Life Cycle
CPS Card Personalization Specification
Page 274
Term Description
CPV Card Personalization Validation
CRL Certificate Revocation List
CRM Card Risk Management
CRT Chinese Remainder Theorem
CSI Card Status Indicator
CSU Card Status Update
C-TPDU Command Transport Protocol Data Unit
CTQ Card Transaction Qualifiers
CTTAL Cumulative Total Transaction Amount Limit
CTTAUL Cumulative Total Transaction Amount Upper Limit
CV Rule Card Verification Rule
CVC-1 Card Verification Code
CVC-2 Card Verification Code 2
CVC-3 Card Verification Code 3
CVM Cardholder Verification Method
CVN Cryptogram Version Number
CVR Card Verification Results
CVV-1 Card Verification Value 1
CVV-2 Card Verification Value 2
dCVV Dynamic Card Verification Value
DDA Dynamic Data Authentication
Page 275
Term Description
DDF Directory Dedicated File
DDOL Dynamic Data Object List
DES Data Encryption Standard
DF Dedicated File
DHS Dynamic Host Service
DKI/KDI Derivation Key Index/Key Derivation Index
DOL Data Object List
DPA Dynamic Passcode Authentication
D-PAS D-Payment Application Specification
DUKPT Derived Unique Key Per Transaction
EEPROM Electronically Erasable Programmable Read Only Memory
EF Elementary File
EMV Europay, Mastercard, Visa
ENC Encryption
EPOS Electronic Point Of Sale
ETEC Easy Test Cards (Mastercard test card suite)
FCI File Control Information
fDDA Fast Dynamic Data Authentication
FID Field Identifier
GPO Get Processing Options
GSM Global System for Mobile Communication
Page 276
Term Description
GSMA GSM Association
HSM Hardware Security Module
IA Issuer Authentication
IAC Issuer Action Codes
IAD Issuer Application Data
ICC Integrated Chip Card
iCVV Integrated Card Verification Value
IDD Issuer Discretionary Data
IDN ICC Dynamic Number
IFD Interface Device
IIN Issuer Identification Number
INS Instruction Byte of the Command Message
ISO International Organization for Standardization
IWK Issuer Working Key
KEK Key Encryption Key
Lc Length of data being transmitted.
LCOL Lower Consecutive Offline Limit
LCOTA Lower Cumulative Offline Transaction Amount
Le Maximum length of data expected in response.
LMK Local Master Key
LOATC Last Online Application Transaction Counter
Page 277
Term Description
LRC Longitudinal Redundancy Check
MAC Message Authentication Code
MCC Merchant Category Code
MDK Master DES Key
MF Master File
MII Major Industry Identifier
MSI Magnetic Stripe Image
MSD/MSR Magnetic Stripe
M-TIP Mastercard Terminal Integration Process
NFC Near Field Communication
NATC Number of ATC Digits
P1 Parameter 1
P2 Parameter 2
P2PE Point to Point Encryption
PAN Primary Account Number
PCB Protocol Control Byte
PCI Payment Card Industry
PCI-DSS Payment Card Industry Data Security Standard
PCI-PTS Payment Card Industry PIN Terminal Security
PCVC3 Position of CVC3
PDOL Processing Data Object List
Page 278
Term Description
PED PIN Entry Device
PEK PIN Encryption Key
PIN Personal Identification Number
PIN Block Personal Identification Number Block
PIX Proprietary Application Identifier Extension
PK Public Key
PKI Public Key Infrastructure
POS Point of Sale
PPSE Proximity Payment System Environment
PSE Payment System Environment
PTC PIN Try Counter
PTL PIN Try Limit
PTS Program POS Terminal Security Evaluation Program
PUNATC Position of the UN and the ATC
PVT Personalization Validation Tool
PVV PIN Verification Value
qVSDC Quick Visa Smart Debit Credit
R-APDU Response. Application Protocol Data Unit
RFID Radio Frequency Identification
RFU Reserved for Future Use
RID Registered Identification Number
Page 279
Term Description
RSA Rivest-Shamir-Adleman
SAD (SSAD) (Static) Signed Application Data
SAF Store and Forward
SDA Static Data Authentication
SDAD Signed Dynamic Application Data.
SFI Short File Indicator
SHA -1 Secure Hashing Algorithm
SPED Secure PIN Entry Device
STIP Stand-in Process
SVC Service Code
SW1 Status Byte 1
SW2 Status Byte 2
SWP Single Wire Protocol
TAA Terminal Action Analysis
TAC Terminal Action Code
TAL Terminal Application Layer
TC Transaction Certificate
TCI Terminal Check for Implementation
TDES Triple Data Encryption Standard
TDOL Transaction Certificate (TC) Data Object List
TIP Terminal Integration Process
Page 280
Term Description
TLV Tag/Length/Value
TPDU Transport Protocol Data Unit
TQM Terminal Quality Management
TRM Terminal Risk Management
TSI Terminal Status Information
TTQ Terminal Transaction Qualifiers
TVR The Terminal Verification Result
UCOL Upper Consecutive Offline Limit
UCOTA Upper Cumulative Offline Transaction Amount
UDOL UN Data Object List.
UDK Unique DES Key
UICC Universal Integrated Circuit Card
UN Unpredictable Number
VIS Visa ICC Specification
VLP Visa Low Value Payment
VSDC Visa Smart Debit Credit
ZMK Zone Master Key
Page 281
Terms
Term Description
Application AAC is an Application Cryptogram type generated by the chip application in

Authentication response to the Generate AC command (First or Second) sent by the CAD.
Cryptogram An AAC is generated to indicate that the transaction should be declined.
Automated Banking ABM is an unattended, cardholder-operated device used to dispense or

Machine deposit cash and conduct other cardholder operated services (also known
as Automated Teller Machine).
Application Cryptogram AC is a generic term given to describe an application cryptogram such as

TC, AAC, ARQC and ARPC.
Application Default ADA is the Visa and Amex proprietary data element indicating issuer-
Action specified action for the ICC to take for certain exception conditions.
This data element is required for Issuer Authentication checks, offline PIN
verification checks, new card checks and Issuer Script processing checks. If
this data element is not present, the ICC behaves as if the value is all
zeroes.
Application Dedicated ADF contains application specific data for a specific AID (also see DF).
File
Acquirer Device ADVT is the tool kit used for end-to-end Visa contact transaction certification
Validation Tool Kit of deployed EMV devices. ADVT is the Visa brand level certification which
follows the device’s previous EMV level 1 (Hardware) and EMV level 2
(EMV kernel) certifications completed by the device vendor. This test suite is
supported by the Collis and ICC Solutions testing tools.
American Express AEIPS is the EMV test suite used for Amex EMV contact transaction
Integrated Circuit Card certification of deployed EMV devices. This test suite is supported by the
Payment Specification Collis and ICC Solutions testing tools.
Application File Locator AFL identifies the location and number of application records that contain
data that must be read by the CAD to conduct a transaction. In addition to
the location and number of records the AFL also indicates which data
elements have been signed by the issuer as part of the SDA process.
Page 282
Term Description
Application Identifier AID identifies the scheme and type of application(s) present on an ICC. The
AID is made up of two fields, the Registered ID (RID) which identifies the
scheme and the Proprietary Application Identifier Extension (PIX) which
identifies the application type. ICCs and CADs use AIDs to determine which
applications are mutually supported, as both the ICC and the CAD must
support an AID to initiate a transaction. Both ICCs and CADs may support
multiple AIDs.
Application Interchange AIP contains details of the ICC’s capabilities to support specific security
Profile functions in the application (e.g. SDA/DDA/CDA, Cardholder Verification
etc.).
Application Protocol APDU is the command message sent from the interface device (in the CAD)
Data Unit and the response message returned by the ICC to the interface device.
Application Program API is a specification defining the communication protocol and commands
Interface used to interact with a device.
Authorization Response ARC is a two digit code generated by the issuer and sent to the CAD to
Code approve, decline, or refer a transaction. The most used ARC consists of
online approval (00), online decline (05) and referral (01). The CAD is
prohibited to alter the ARC from the issuer. The CAD can generate an ARC
in the following exception conditions:
Y1=Offline Approved
Z1=Offline Declined
Y3=Unable to go online (offline approved)
Z3=Unable to go online (offline declined)
Authorization Response ARPC is a cryptogram used for a process called Online Issuer
Cryptogram Authentication (IA). The ARPC is the issuer’s (or scheme in STIP)
authorization response cryptogram signed with a DES key. This cryptogram
is generated by the issuer in response to the Authorization Request
Cryptogram (ARQC) and is sent to the ICC in the authorization response
message. The ICC will validate the ARPC to confirm that the response was
sent by the true card issuer.
Page 283
Term Description
Authorization Request ARQC is a cryptogram used for a process called Online Card
Cryptogram Authentication. The cryptogram is generated by the ICC in response to the
FIRST GENEREATE AC command when the transaction requires online
authorization. It is the ICC, CAD and transaction result data signed with a
DES key. It is sent to the issuer in the authorization or full financial request
message. The issuer will validate the ARQC to ensure that the ICC is
authentic and ICC data was not copied from a skimmed ICC.
Application Selection ASF is used by Interac during the Application Selection process enabling
Flag automatic selection of an application without using the highest API thus
allowing for different priorities between SCD and IDP.
Application Selection ASI indicates whether the associated AID in the CAD must exactly match
Indicator the AID in the ICC (including the length of the AID) or if it can be partially
selected based on the length of the AID specified in the CAD (even though
the card AID might be longer). There is only one Application Selection
Indicator per AID supported by the CAD.
Application Transaction ATC counts the number of transactions processed since the personalization
Counter of the ICC. The ATC increments by 1 when the Get Processing Options
command is issued at the start of each transaction.
Automated Teller Refer to Automated Banking Machine.

Machine
Answer To Reset ATR is sent from the ICC to the CAD (after the supply voltage, the clock and
reset signal) containing various information related to the transmission
protocol supported by the ICC.
Application Usage AUC details the ICC’s processing restrictions. These restrictions relate to
Control the geographical settings (domestic vs international) and the support for
specific services (e.g. cash, cashback, goods and services, etc.).
Binary Coded Decimal BCD is a code that represents decimal digits in a binary format.
Basic Encoding Rules BER are defined in ISO/IEC 8825-1.
Page 284
Term Description
Bank Identification BIN is the first six digits of the PAN and is used to identify the issuer of the
Number card. It is comprised of a Major Industry Identifier (MII) (1st digit) and an
Issuer Identifier (up to 5 digits). The acronym IIN may be used
interchangeably with BIN.
Certificate Authority CA is a trusted central administration that issues, revokes and expires
certificates. A CA is responsible for ensuring that the identity of the user
requesting the certificate is legitimate.
Card Action Analysis CAA involves the analysis of the Card Risk Management (CRM) results and
responding to the CAD with an appropriate cryptogram (TC, AAC or ARQC).
CAA is performed by the ICC after the ICC completes the CRM process and
sets the CVR.
Card Acceptance CAD is any device capable of reading and processing data from a
Device magstripe, ICC (contact or contactless interfaces) or manual entry keyboard
for the purpose of performing a payment transaction.
Card Authentication CAM is the name given to the process of authenticating the ICC, either by
Method the Issuer (if it is on Online CAM) or by the CAD (if it is an Offline CAM).
Candidate List List of AIDs mutually supported by the ICC and EMV POS Solution.
Card Authentication CAP is a One Time Password application created by Mastercard. CAP uses
Program chip cryptography similar to the Mastercard payment application to create a
digital signature which can be authenticated by the Issuer in a CNP
transaction. To use CAP a low cost reader which supports the ability to
enter a PIN is required to generate the One Time Password.
C-APDU Refer to Application Protocol Data Unit.
Certificate Authority CAPK is the RSA Public key assigned by a card brand used by an EMV
Public Key kernel to decrypt chip information signed with a card brand private key.
CAPK File is a file containing the current card brand assigned RSA public
keys, key indexes, and expiry dates. The file is downloaded to the EMV
kernel.
Page 285
Term Description
Cardholder Activated CATs are typically unattended CADs that accept various payment cards.
Terminal This type of CAD is frequently installed at rail ticketing stations, petrol
stations, toll roads, parking garages and other merchant locations. There
are four types of cardholder-activated terminals:
Automated Dispensing Machines / Level 1.
Self-Service Terminals / Level 2.
Limited Amount Terminals / Level 3.
In-flight Commerce (IFC) Terminals / Level 4.
The CAT requirements specify related transaction liability for each CAT type
and maximum allowable transaction amounts as well as authorization,
clearing, chargeback and addendum record requirements.
Compute Cryptographic Refer to Checksum.

Checksum
Common Core CCD defines a common data element content and format for sending ICC
Definitions information between an ICC and the issuer via the acquirer. When CCD is
incorporated into an ICC specification, issuers of multi-branded cards can
achieve the benefits of the common issuer support system.
Chip Compliance CCRT is a Visa web portal that allows an acquirer to load or enter
Reporting Tool certification test results (e.g. from a Visa ADVT certification).
Combined Dynamic CDA is the most secure option for offline CAM as in addition to protection
Data against counterfeit and skimming it also protects against man-in-the-middle
Authentication/Generate attacks. During the CDA process the ICC uses its RSA Private Key to sign a
AC string of data. This string of data includes data produced by the ICC,
indicating the ICC’s decision to approve the transaction, the AC (Application
Cryptogram) and the transaction data.
Contactless Device CDET is the tool kit used for Visa contactless transaction certification of
Evaluation Toolkit deployed EMV devices. This test suite is supported by the Collis and ICC
Solutions testing tools.
Page 286
Term Description
Card Data Object List 1 CDOL1 is the list of TLV data objects (tags / lengths) personalized on the
ICC that are used for the generation of the first cryptogram. The CAD will
send these data object values to the ICC with the First Generate AC
command.
Card Data Object List 2 CDOL2 is the list of TLV data objects (tags / lengths) personalized on to the
ICC that are used for the generation of the final cryptogram. The CAD will
send these data object values to the ICC with the Second Generate AC
command.
Checksum Computed numeric value that represents a data element. Used to ensure
that the data has not been changed.
Card Issuer Actions CIAC specifies the ICC conditions that cause a transaction to be approved
Codes off-line, sent online, or declined if the CAD cannot go online. During card
risk management the ICC makes its decision by comparing the CVR with
the CIAC. There are three groups of CIAC (Denial, Online and Default).
Cryptogram Information CID indicates the type of cryptogram (AAC, TC and ARQC) and the actions
Data to be performed by the CAD (e.g. Advice required and the reason such as;
Service not allowed, PTL exceeded etc.).
Class Byte of the CLA is the first byte of five consecutive bytes that create the header in the
Command Message C-APDU. For this purpose, the CLA serves as the instruction class and may
take any value except 'FF'.
Contactless Frontend CLF is circuitry in the CAD which manages the analogue contactless
communication and the communication protocol layer of the contactless
transmission link to exchange data with the UICC.
Card Not Present CNP transactions are transactions that are conducted over an open network
(e.g. telephone, Internet, mail order) where a physical card is not present
and therefore the MSD or ICC data cannot be obtained and used.
Page 287
Term Description
Common Payment CPA is a CCD-compliant application specification developed by EMVCo.

Application CPA enables a single application implementation to be personalized with
the same data elements and tags, including common Risk Management
controls, for all brands and schemes that support EMV.
Card Production Life CPLC is a Visa proprietary data element that provides auditability for the
Cycle ICC through the use of card life cycle data. It is composed of several data
elements (e.g. Operating system identifier, personalization machine and
date etc.)
CPLC is only used with the VIS 1.4 specs (it has been deleted from the VIS
1.5 specs) and is only supported on Global platform cards.
Card Personalization CPS is a specification that defines the card brand personalization
Specification requirements and chip card rules.
Card Personalization CPV is a process to ensure that a Technical Product (e.g. card chip) has
Validation been personalized in such a manner that it is compliant with the Mastercard
recommendations and mandates.
Certificate Revocation CRL is a list of certificates that have been revoked and therefore, should no
List longer be trusted or used.
Card Risk Management CRM is a process performed by the ICC to determine if the transaction
should be sent online, approved offline or declined offline. The output of the
CRM process is the setting of the CVR which is subsequently used in the
Card Action Analysis.
Cryptogram Numeric value used to validate data integrity. Cryptograms are calculated by
processing and signing specific data elements using a common algorithm.
Cryptograms are generated by the ICC in response to the “Generate AC”
command and by the Issuer in the authorization response message.
Card Status Update CSU contains data sent to the ICC to indicate whether the issuer has
approved or declined a transaction and to identify actions required by the
issuer (e.g. update counters). CSU is transmitted to the card in the Issuer
Authentication Data.
Page 288
Term Description
Card Transaction CTQ is a card value defining what actions will take place at the POS when a
Qualifiers transaction occurs.
Cumulative Total CTTAL is a Visa proprietary tag 9F54 specifying the maximum total amount
Transaction Amount of offline transactions in the designated currency or designated and
Limit secondary currency allowed for the card application before a transaction is
sent online.
Cumulative Total CTTAUL is a Visa proprietary tag 9F5C specifying the maximum total
Transaction Amount amount of offline transactions in the designated currency or designated and
Upper Limit secondary currency allowed for the card application before a transaction is
declined if an online transaction is unable to be performed.
Card Verification Rule CV Rule is a specific cardholder verification method which is part of the
CVM data element that contains the definition of which type of cardholder
verification should be used, under which conditions and the action to take if
the CV Rule is unsuccessful.
Card Verification Code CVC1 is the three digit field coded on the MSR of a Mastercard branded
1 card. The value is generated using TDES from the PAN, expiry date and
Service Code.
Card Verification Code CVC2 is the three digit field printed on the signature panel of a Mastercard
2 branded card. The value is generated using TDES from the PAN, Expiry
Date and Service Code ‘000’. CVC2 is used for CNP to prove the presence
of a legitimate card.
Card Verification Code Also referred to as Dynamic CVC. CVC3 is the process of generating a two
3 byte cryptogram returned by the card in the response to the COMPUTE
CRYPTOGRAPHIC CHECKSUM command. CVC3 is used by Mastercard
for the security of the PayPass contactless MSD application.
Cardholder Verification CVM is a method by which a cardholder is identified during an ICC

Method transaction (e.g. PIN or Signature).
Page 289
Term Description
Cryptogram Version CVN informs the issuer about the algorithm and data used for the
Number Application Cryptogram computation during online transactions (in the
authorization request) and after transaction completion in the clearing
record.
Card Verification CVR is a proprietary data field used to report transaction-processing

Results information to the issuer (e.g. successful PIN validation, previous
transaction information, script results, etc.).
Card Verification Value CVV-1 is the three digit field coded on the MSR of a Visa branded card. The
1 value is generated using TDES from the PAN, expiry date and Service
Code.
Card Verification Value CVV-2 is the three digit field printed on the signature panel of a Visa
2 branded card. The value is generated using TDES from the PAN, Expiry
Date and Service Code. CVV2 is used for CNP to prove the presence of a
legitimate card.
Dynamic Card dCVV is the process of generating a dynamic CVV (using the same
Verification Value algorithm as CVV1 with the addition of the ATC). dCVV is used for security
by the Visa payWave contactless MSD application.
Dynamic Data DDA is an offline CAM option which protects against counterfeit and
Authentication skimming. During the DDA process the ICC uses its RSA Private Key to
sign an UN generated by the CAD.
Directory Dedicated File DDF is an entry point to another ADFsor DDF. Refer to Dedicated File.
Dynamic Data Object DDOL is the list of data objects (tags and lengths) that are personalized on
List the ICC and used to generate the ICC’s RSA digital signature during the
DDA or CDA process. The CAD will send the required data object values
with the Internal Authenticate command.
Data Encryption DES is a cryptography standard defined by the U.S government (NIST).
Standard DES is a symmetric algorithm meaning the keys for each of the
cryptography operations used is the same. DES uses a single length key
which is 16 bytes in length.
Page 290
Term Description
Developer Merchant, integrator, or developer who implements and tests an EMV POS
Solution.
Dedicated File DF in EMV follows the ISO/IEC 7816-4 definition. The DF contains an FCI
and is mapped onto an ADF or a DDF. It may give access to Elementary
Files (EF) and DFs. The DF at the highest level of the card is the Master File
(MF).
Dynamic Host Service DHS is a real time server option whereby clients or vendors can send
requests via IP, with minimal non-critical information, for DHS to determine if
the card is foreign-issued and if so, its supported currency. If eligible for
DCC, the response would contain all the information needed to provide a
choice to the consumer and process the transaction.
Derivation Key Index or DKI is a two digit hexadecimal field located on the card issuer host to
Key Derivation Index identify a set of Master DES keys used to generate cryptograms.
Data Object List DOL is a flexible list of data elements built be the CAD and passed to the
ICC under the ICC’s direction. To minimize processing within the ICC, such
a list is not TLV-encoded but is a single constructed field built by
concatenating several data elements together. Since the elements of the
constructed field are not TLV-encoded, it is imperative that the ICC knows
the format of this field when the data is received.
Dynamic Passcode DPA is based on the Mastercard CAP specification and is used along with a
Authentication One Time Password (see CAP).
D-Payment Application D-PAS is the Discover contactless payment card or device implementation.
Specification Also the name of the Discover EMV smartcard test suite used to certify that
EMV devices can process contact and contactless EMV Discover
transactions. This test suite is supported by the Collis and ICC Solutions
testing tools.
Derived Unique Key Per DUKPT is a key management scheme in which for every transaction a
Transaction unique key is used which is derived from a fixed key.
Page 291
Term Description
Electronically Erasable EEPROM is a type of memory used in ICCs to store all the personalization
Programmable Read data and other dynamic data specific to an ICC application. Data in the
Only Memory EEPROM is retained without power but can only be modified when power is
available.
Elementary File In EMV, EF follows the ISO/IEC 7816-4 definition. The EF is accessed
through a specific DF and consists of one or more records (up to 256 bytes
for each record), identifying where the data is stored. An EF is never used
as an entry point to another file.
Europay, Mastercard, EMV is the Integrated Circuit Card (ICC) Specification for Payment Systems
Visa defines the functionality of credit / debit transaction processing at the CAD
level to ensure correct operation and interoperability.
EMVCo EMVCo is the non-profit organization formed in 1999 between Europay,

Mastercard and Visa that maintains the EMV specifications.
EMV POS Solution Generic term used within this document to describe any integrated or
standalone EMV implementation being developed and tested.
EMV Transaction Type Type of transaction performed. Example: Sale or Return.
Encryption ENC is a process whereby plaintext data is scrambled into data non-
readable to any entity which doesn’t have the key required to unscramble it
(Decryption).
Electronic Point Of Sale EPOS is a Point of Sale device equipped with electronic equipment for
pricing and recording transactions. EPOS are normally installed in large
retailers (e.g. supermarkets).
Easy Test Cards ETEC is a test card used for Mastercard TIP processing. Mastercard ETEC
(Mastercard test card is suitable for any kind of terminal (POS, ATM, integrated-POS and others).
suite) ETEC are used in conjunction with the Mastercard host simulator for
authorizations. The ETEC are grouped into different subsets, each with a
specific objective to test different EMV criteria and terminal applications.
Page 292
Term Description
ExpressPay Amex contactless payment card or device implementation. Also the name of
the EMV test suite used for Amex EMV contactless transaction certification
of deployed EMV devices. This test suite is supported by the Collis and ICC
Fallback Process and rules, or use of, the magnetic-stripe reader of the CAD to
obtain card information when the ICC or EMV PIN Pad is inoperable or no
mutually supported AIDs are found.
File Control Information In EMV, FCI is part of a DF and contains information needed to select the
DF or the subsequent EF under it.
Fast Dynamic Data In most contactless payment environments, quick transaction speeds (one
Authentication second or below) are a business requirement. A DDA method called fDDA is
defined for Visa payWave offline protection against skimming, counterfeit (in
version 00 of fDDA) and man-in-the-middle attacks (in version 01 of fDDA
similar to CDA).
Field Identifier FID identifies a single data field inside various types of host messages.
Floor Limit Maximum transaction amount that can be locally authorized by the merchant
without receiving an authorization from the Issuer.
Get Processing Options GPO is the command sent by the CAD to initiate a transaction within the
ICC application. The ICC application returns the CAD the Application
Interchange Profile (AIP) and the Application File Locator (AFL). Each time
a GPO command is processed the ICC increments the ATC of the
application selected by one.
Hardware Security HSM is a secure, tamper evident device used to securely generate and
Module store keys (symmetric and asymmetric) and for performing cryptographic
functions.
Issuer Authentication IA is the process of authenticating the issuer by the ICC. During the IA
process the ICC will authenticate the issuer by validating the ARPC sent
from the issuer to make sure it has not been changed by any unauthorized
entity along the way.
Page 293
Term Description
Issuer Action Codes IAC is a set of three data fields, IAC denial, IAC online and IAC default,
defined in EMV, for use during Terminal Risk Management processing. IACs
are set by the issuer and loaded on to the ICC during the card
personalization process.
Issuer Application Data IAD contains proprietary application data that is required by the Issuer to be
transmitted as part of the online authorization request.
Integrated Chip Card ICC refers to a plastic card that contains a small electronic chip. Also known
as smartcards or chip cards.
Integrated Card iCVV is an alternate CVV defined for storage on a Visa EMV chip card. It is
Verification Value calculated using a SVC of ‘999’ instead of the SVC encoded on the
magstripe image of the chip. iCVV enables issuers to identify fraudulent use
of ICC data in magstripe read transaction processing.
Issuer Discretionary IDD is the data encoded on magstripe by the issuer.

Data
ICC Dynamic Number IDN is a time-variant number generated by the ICC, to be captured by the
CAD. The first 3-8 bytes of the ICC Dynamic Data must be the
concatenation of the length and the value of the ICC Dynamic Number.
Issuer Identification IIN replaces the previously used Bank Identification Number (BIN). See BIN
Number for more information. The acronym IIN may be used interchangeably with
BIN.
Instruction Byte of the INS is the second byte of 5 consecutive bytes that create the header in the
Command Message C-APDU. Instruction code within the instruction class. The INS is only valid if
the least significant bit is ‘0’ and the most significant nibble is not '6' or '9'.
Interac Association responsible for the development of Canada’s network of two

shared electronic financial services; Shared Cash Dispensing (ABM) and
Interac Direct Payment (debit at point of sale).
Issuer Working Key IWK is a Visa key used exclusively to encrypt/decrypt PIN blocks being sent
between the Issuer and the Visa network.
Page 294
Term Description
JCB via American JCB cards that process through American Express in Canada.
Express
JCB via Discover JCB cards that process through Discover in the US and US Territories.
Key Encryption Key KEK is a key used exclusively to encrypt / decrypt other keys.
Kernel Part of the PIN Pad application that contains all the EMV commands used
between the CAD and ICC and that has been EMV type approved (Level 2).
Lc Length of transmitted data.
Lower Consecutive LCOL is the issuer-specified preference for the maximum number of
Offline Limit consecutive offline transactions allowed for the ICC application, before the
transaction should go online (if terminal has online capabilities).
Lower Cumulative LCOTA is the Transaction Amount. Issuer-specified preference for the
Offline maximum total amount of offline approved transactions in the supported
currency of the application before the transaction should go online (if
terminal has online capabilities).
Le Maximum length of data expected in response.
Local Master Key LMK is the highest level administrative key, generated in the clear by an
HSM. The LMK is used to encrypt all ZMK and application keys (AC, MAC
and ENC keys) used in cryptographic processing by the HSM.
Last Online Application LOATC is a dynamic data field used by the ICC application. It is set equal to
Transaction Counter the ATC after every successful online transaction. The LOATC in
conjunction with the ATC can be used to detect how many offline
transactions have been conducted by the ICC since the last online
transaction.
Longitudinal LRC is a mathematically calculated value at the end of data streams that
Redundancy represents the data that precedes it. LRC is a check used to ensure data
streams have been received exactly as transmitted.
Page 295
Term Description
Message Authentication MAC is a hexadecimal value used to provide data integrity. A MAC is used
Code when transferring data between two systems/entities to ensure the original
data has not been changed. As speed of this operation is critical, TDES is
used as the algorithm to generate the MAC.
Merchant Category MCC is a four-digit number assigned to a business by Visa or Mastercard

Code when the business first starts accepting one of these cards as a form of
payment. The MCC is used to classify the business by the type of goods or
services it provides.
Master DES Key MDK used to derive UDKs which are loaded on to the ICC application
during personalization. There are three types of MDKs: AC, MAC and ENC
keys.
Master File MF is the peak of the hierarchy of the ICC file structure. It contains
information and locations of the Dedicated Files (DF). DFs contain the
actual data files which are called Elementary Files (EF).
Major Industry Identifier MII is the first digit of the card PAN (or BIN / IIN) is the Major Industry
Identifier (MII), which represents the category of the entity which issued the
card.
E.g. Visa uses ‘4’ and Mastercard uses ‘5’ which are both defined as
Banking and Financial categories.
Magnetic Stripe MSD or MSR Strip of magnetic tape, affixed to bank credit and debit cards,
encoded with cardholder identifying information, such as the PAN and card
expiration date, allowing for automated handling of transactions. The bank
card industry standard for magnetic stripes allows three separate tracks of
encoded data.
MSR Fallback Process and rules for the magnetic-stripe reader of the CAD to obtain card
information when the ICC or the EMV PIN Pad are operable but the
Candidate List is empty.
Page 296
Term Description
Mastercard Terminal M-TIP details the Mastercard processes and test cases that acquirers must
Integration Process successfully perform before a terminal can be certified and deployed in a
production environment. This test suite is supported by the Collis and ICC
Near Field NFC is a short-range high frequency wireless communication technology

Communication which enables the exchange of data between devices over a 10 centimeter
(around 4 inches) distance. The technology is a simple extension of the
ISO/IEC 14443 proximity-card standard that combines the interface of a
smartcard and a reader into a single device. An NFC device can
communicate with both existing ISO/IEC 14443 smartcards and readers, as
well as with other NFC devices and is thereby compatible with existing
contactless infrastructure already in use for public transportation and
payment. NFC is primarily aimed at usage in mobile phones.
Point to Point P2PE is a standard for encrypting cardholder data (usually the PAN) to
Encryption protect sensitive data.
Primary Account PAN is the 13 to 19 digit number used to identify a debit cardholder or a
Number credit account number.
PayPass Mastercard contactless payment card or device implementation.
payWave Visa contactless payment card or device implementation.
Payment Card Industry PCI, or sometimes more specifically used to refer to the Payment Card
Industry Security Standards Council (PCI-SSC). An independent council
originally formed by Amex, Discover, JCB, Mastercard and Visa, with the
goal of managing the on-going evolution of the Payment Card Industry Data
Security Standard (PCI-DSS).
Payment Card Industry PCI-DSS is the standard created by PCI-SSC. The standard was created to
Data Security Standard help payment industry organizations that process card payments prevent
credit card fraud through increased controls around data and its exposure to
compromise. The standard applies to all organizations that hold, process or
exchange cardholder information from any card branded with the logo of
one of the card brands.
Page 297
Term Description
Payment Card Industry PCI-PTS is the specification that defines the physical and logical security
PIN Terminal Security requirements for PIN entry devices. Refer to .the PCI Security Standards
Council.
Position of CVC3 PCVC3 is the field that defines the location of the CVC3 in the Track-2 data
for a contactless MSD PayPass transaction.
Processing Data Object PDOL is a list of terminal-related data objects (tags and lengths), requested
List by the ICC, to be transmitted in the GET PROCESSING OPTIONS
command.
PIN Entry Device PED is a secure device used by a consumer to enter their PIN.
PIN Encryption Key PEK is a key used exclusively to encrypt PIN blocks between the various
Issuer card personalization environments (from Issuer host through Data
Preparation to Personalization).
Personal Identification PIN is the 4-12 digit string of numbers entered by the cardholder to provide
Number cardholder verification when specified by the CVM.
Personal Identification When a cardholder enters his PIN, the information is first encoded into a
Number Block plain text PIN block using one of several PIN Block formats defined.
Regardless of which format is used, once the PIN Block has been
constructed, the plain text PIN block can be encrypted using a standard
algorithm (when specified by the CVM).
Proprietary Application PIX is the second segment of the AID used to identify the specific
Identifier Extension application on the ICC. Each brand (e.g. Visa Credit, Cirrus, Plus, Maestro)
under a specific scheme (e.g. Visa, Mastercard, Amex) will normally have a
unique PIX to identify the brand under the specific scheme (scheme is
identified by the RID).
Public Key PK is a key used in RSA that does not have to be kept secret. It is used to
reverse any cryptographic operation that is performed using the Private Key.
The Public Key has a mathematical link to the Private Key which makes
them a key pair.
Page 298
Term Description
Public Key PKI is a set of hardware, software, people, policies, and procedures needed
Infrastructure to create, manage, distribute, use, store and revoke digital certificates. A
PKI is an arrangement that binds PKs with respective user identities by
means of a CA.
Point of Sale POS is a type of terminal which is used to process electronic transactions in
shops, restaurant etc. The POS may process offline or go online for
Authorization by the Issuer/Scheme when processing a transaction.
Proximity Payment PPSE has a fixed name of 2PAY.SYS.DDF01 and contains a directory of all
System Environment the contactless payment applications that exist on the ICC. PPSE is
mandatory in all contactless implementations.
Payment System PSE has a fixed name of 1PAY.SYS.DDF01 and contains a directory of all
Environment the payment applications that exist on the ICC. Although PSE is optional in
EMV it is highly recommended to enhance transaction performance.
PIN Try Counter PTC indicates the number of offline PIN tries remaining. The initial value is
set to the PIN Try Limit (PTL). The PTC is decremented by 1 each time an
incorrect offline PIN is entered. The PTC is reset to the PTL value when a
correct offline PIN is entered, when the PIN is changed or when the PIN is
unblocked by the issuer.
PIN Try Limit PTL is the issuer-specified maximum number of consecutive incorrect offline
PIN tries allowed before the card is blocked.
POS Terminal Security PTS Program is a Mastercard program to enhance the security of
Evaluation Program transactions originating at wireless and IP-enabled POS payment terminals.
The standards introduced require wireless and IP-enabled POS terminals to

support the encryption of transaction data between the terminal and the
acquirer host, using protocols approved by Mastercard.
Personalization PVT is a tool used by Visa and Visa members to ensure that a Technical
Validation Tool Product (e.g. chip card) has been personalized in such a manner that it is
compliant with the recommendations and the mandates of Visa.
Page 299
Term Description
PIN Verification Value PVV is a four digit field coded on the bank card MSR that can be used to
validate the online PIN. The PVV is generated using TDES algorithm using
the last eleven digits of the PAN (excluding the mod 10 check value), a one
digit PIN Verification Key Index (number 1-6) positioned before the PVV on
the MSR and the four left most digits of the PAN.
Quick Visa Smart Debit qVSDC is part of the Visa contactless payment specification.
Credit
Reserved for Future RFU represents space for a field that may be used in the future for new
Use functionality.
Registered Identification RID is the first part of the AID used to identify the scheme (e.g. Visa,
Number Mastercard, etc.).
Rivest-Shamir-Adleman RSA is an asymmetric algorithm used for cryptography named after its three
inventors.
(Static) Signed SAD (SSAD) is a digital signature generated from critical card data elements
Application Data and personalized on the ICC.
The SAD is validated by the terminal during the SDA process.
Store and Forward SAF is a process used when a single host transaction message is used (i.e.
Host Capture) and the transaction has been completed offline (i.e. between
the ICC and CAD). The transaction is “stored” locally and then “forwarded”
to the host before settlement occurs.
Static Data SDA is an option for offline CAM which protects against counterfeit attacks.
Authentication During the SDA process the terminal will validate the SAD to ensure the
information on the ICC has not been changed since the ICC was
personalization by the Issuer.
Short File Indicator SFI used to identify a file in the commands related to an application
Elementary File (EF). The SFI data object is a binary field with its three high-
order bits set to zero.
Page 300
Term Description
Secure Hashing SHA-1A is the secure hashing algorithm designed for use with the digital
Algorithm signatures. The SHA-1 algorithm output is always 20 bytes in length.
Signature Fallback Fallback of offline PIN to signature as the CVM for a particular ICC
transaction. The ability of an ICC to perform signature fallback is indicated in
the ICC’s CVM list.
It is important not to confuse Signature Fallback with MSR Fallback or

Technical Fallback.
Secure PIN Entry SPED is used by cardholders to securely enter their PIN in privacy. SPEDs
Device safeguard the PIN from the time the cardholder enters the number through
its processing in the POS system by encrypting the PIN before it leaves the
SPED.
Stand-in Process STIP is the process where a third party entity stands in to authorize an
online electronic bank transaction on behalf of the Issuer.
Page 301
Term Description
Service Code SVC is the three digit code that follows the expiry date on Track 2. In EMV it
is used to identify the technology supported by payment card being swiped
(e.g. chip, MSR). The values for the three digits are as follows:
First Digit:
1: International interchange OK
2: International interchange, use IC (chip) where feasible
5: National interchange only except under bilateral agreement
6: National interchange only except under bilateral agreement, use IC (chip)

where feasible
7: No interchange except under bilateral agreement (closed loop)
9: Test
Second Digit:
0: Normal
2: Contact issuer via online means
4: Contact issuer via online means except under bilateral agreement
Third Digit:
0: No restrictions, PIN required
1: No restrictions
2: Goods and services only (no cash)
3: ATM only, PIN required
4: Cash only
5: Goods and services only (no cash), PIN required
6: No restrictions, use PIN where feasible
7: Goods and services only (no cash), use PIN where feasible
Terminal Action TAA is a step that follows the completion of TRM and the setting of the TVR
Analysis the CAD will perform the TAA which involves the CAD analyzing the TRM
processes and requesting the appropriate cryptogram (AAC, ARQC or TC).
Page 302
Term Description
Terminal Action Code A set of three data fields, TAC Denial, TAC Online and TAC Default, defined
in EMV, for use during the Terminal Risk Management processing. TACs
are set by the schemes and must be loaded per AID to each CAD that
process EMV transactions. Merchants should receive the TACs from their
Acquirer.
Tag Method used to exchange information with the EMV chip. Each EMV Tag is
assigned a Tag Number denoting the type of information it contains.
Transaction Certificate TC is an Application Cryptogram type generated by the chip application in

response to a Generate AC command sent by the CAD. A TC is only
generated when the ICC wishes to approve the transaction.
Terminal Check for TCI is the test suite used for JCB EMV contact transaction certification of
Implementation deployed EMV devices.
Triple Data Encryption TDES is a sophisticated implementation of DES, in which the procedure for
Standard encryption is the same but repeated three times. First, the DES key is
broken into three sub keys. Then the data is encrypted with the first key, the
result decrypted with the second key and finally encrypted again with the
third key. Triple DES offers much stronger encryption than DES. TDES uses
a double length key which is 32 bytes in length.
Transaction Certificate TDOL is a CDOL may request a TC Hash Value to be included in the
(TC) Data Object List command data of a GENERATE AC command. The TDOL is a list of the
data objects the CAD should use to generate the TC Hash Value. The ICC
may contain the TDOL, however there should also be a default TDOL in the
CAD, specified by the payment system, for use in cases where the TDOL is
not present in the ICC.
Technical Fallback The process and rules relating to using the magnetic-stripe reader of the
CAD to obtain card information if the ICC or the EMV PIN Pad is inoperable.
Terminal Integration TIP is a key testing process designed and mandated by Mastercard to test
Process the CAD, its intermediate connections and the interface with the acquirer
host system, in conditions that are as close as possible to its final
production environment.
Page 303
Term Description
Tag/Length/Value TLV is a variable length data format that uses a label (tag) to uniquely
identify a field followed by its field value length and then the field value.
Terminal Quality TQM is the Mastercard program that provides assurance to acquirers that
Management devices they certify are consistent with the card interface module approved
by EMVCo. The TQM process ensures that the smart card and contactless
hardware interfaces are EMV Level 1 compliant.
Terminal Risk TRM is a process performed by the CAD to determine if the transactions
Management should be sent online, approved offline or declined offline. The output of the
TRM is the setting of the TVR that is subsequently used in the TAA.
Terminal Status TSI identifies the functions performed by a CAD during transaction
Information processing (e.g. offline data authentication, CVM, CRM, TRM etc.).
Terminal Verification TVR is an EMV tag containing the status of several different EMV checks
Result performed by the PIN Pad kernel or the EMV POS Solution.
Upper Consecutive UCOL is the issuer-specified preference for the maximum number of
Offline Limit consecutive offline transactions allowed for the ICC application, before a
transaction must be approved online. Once this value is reached no offline
transactions are allowed for that application until an online transaction is
approved.
Upper Cumulative UCOTA is the issuer-specified preference for the maximum total amount of
Offline Transaction offline approved transactions, in the supported application currency, before
Amount a transaction must be sent online. Once this amount is reached no offline
transactions are allowed for that application until an online transaction is
approved.
UN Data Object List UDOL is a proprietary Mastercard PayPass tag.
Unique DES Key UDK is a unique key derived using the MDK, PAN and PAN Sequence
Number. The UDKs are loaded onto the ICC application during
personalization. There are three types of UDKs: AC, MAC and ENC keys.
Page 304
Term Description
Universal Integrated UICC is the smart card used in GSM network mobile terminals. The UICC
Circuit Card ensures the integrity and security of personal data. The UICC will typically
contain a few hundred kilobytes of personal data.
Unpredictable Number UN is a value used to provide variability and uniqueness when generating a
cryptogram or during an encryption process.
When used in the CAM process the PIN Pad generates the UN.
When used for offline encrypted PIN the UN is generated by the chip
application.
UnionPay or UnionPay UnionPay cards that process through the Discover network in the US and
via Discover Canada.
Visa ICC Specification VIS is the Visa specific implementation of EMV credit / debit applications on
an ICC. The specification is often referred to as VSDC.
Visa Smart Debit Credit VSDC is an EMV based ICC application specified by Visa. In many cases
this is often used to refer to the VIS specifications.
Zone Master Key ZMK is a high level administrative key established manually between two
entities using key custodians under split knowledge. Once the ZMK is
exchanged it can be used to transfer secret data (e.g. keys) between the
two entities.
Appendix B Reference
Answer to Reset
Basic ATR for T=0 Cards Only
Character Value Remarks
TS ‘3B’ or ‘3F’ Indicates direct or inverse convention
T0 ‘6x’ TB1 to TC1 present; x indicates the number of historical bytes present
TB1 ‘00’ VPP not required
Page 305
TC1 ‘00’ to ‘FF’ Indicates the amount of extra guard time required
Basic ATR for T=1 Cards Only
TS ‘3B’ or ‘3F’ Indicates direct or inverse convention
T0 ‘Ex’ TB1 to TD1 present; x indicates the number of historical bytes present
TB1 ‘00’ VPP not required
TC1 ‘00’ to ‘FF’ Indicates the amount of extra guard time required
TD1 ‘81’ TA2, TB2 and TC2 absent; TD2 present; T=1 to be used
TD2 ‘31’ TA3 and TB3 present; TC3 and TD3 absent; T=1 to be used
TA3 ‘10’ to ‘FE’ Returns IFSI, which indicates initial value for information field size for
ICC and IFSC of 16-254 bytes
TB3 m.s. nibble ‘0’ – BWI = 0 to 4 CWI = 0 to 5

‘4’ l.s. nibble ‘0’
– ‘5’
TCK Check character
ASCII Chart
Dec Bin Hex Char Dec Bin Hex Char Dec Bin Hex Char
00 00000000 00 NUL 44 00101100 2C , 88 01011000 58 X
01 00000001 01 SOH 45 00101101 2D - 89 01011001 59 Y
02 00000010 02 STX 46 00101110 2E . 90 01011010 5A Z
03 00000011 03 ETX 47 00101111 2F / 91 01011011 5B [
04 00000100 04 EOT 48 00110000 30 0 92 01011100 5C \
Page 306
05 00000101 05 ENQ 49 00110001 31 1 93 01011101 5D ]
06 00000110 06 ACK 50 00110010 32 2 94 01011110 5E ^
07 00000111 07 BEL 51 00110011 33 3 95 01011111 5F _
08 00001000 08 BS 52 00110100 34 4 96 01100000 60 `
09 00001001 09 HT 53 00110101 35 5 97 01100001 61 a
10 00001010 0A LF 54 00110110 36 6 98 01100010 62 b
11 00001011 0B VT 55 00110111 37 7 99 01100011 63 c
12 00001100 0C FF 56 00111000 38 8 100 01100100 64 d
13 00001101 0D CR 57 00111001 39 9 101 01100101 65 e
14 00001110 0E SO 58 00111010 3A : 102 01100110 66 f
15 00001111 0F SI 59 00111011 3B ; 103 01100111 67 g
16 00010000 10 DLE 60 00111100 3C < 104 01101000 68 h
17 00010001 11 DC1 61 00111101 3D = 105 01101001 69 i
18 00010010 12 DC2 62 00111110 3E > 106 01101010 6A j
19 00010011 13 DC3 63 00111111 3F ? 107 01101011 6B k
20 00010100 14 DC4 64 01000000 40 @ 108 01101100 6C l
21 00010101 15 NAK 65 01000001 41 A 109 01101101 6D m
22 00010110 16 SYM 66 01000010 42 B 110 01101110 6E n
23 00010111 17 ETB 67 01000011 43 C 111 01101111 6F o
24 00011000 18 CAN 68 01000100 44 D 112 01110000 70 p
Page 307
25 00011001 19 EM 69 01000101 45 E 113 01110001 71 q
26 00011010 1A SUB 70 01000110 46 F 114 01110010 72 r
27 00011011 1B ESC 71 01000111 47 G 115 01110011 73 s
28 00011100 1C FS 72 01001000 48 H 116 01110100 74 t
29 00011101 1D GS 73 01001001 49 I 117 01110101 75 u
30 00011110 1E RS 74 01001010 4A J 118 01110110 76 v
31 00011111 1F US 75 01001011 4B K 119 01110111 77 w
32 00100000 20 SP 76 01001100 4C L 120 01111000 78 x
33 00100001 21 ! 77 01001101 4D M 121 01111001 79 y
34 00100010 22 " 78 01001110 4E N 122 01111010 7A z
35 00100011 23 # 79 01001111 4F O 123 01111011 7B {
36 00100100 24 $ 80 01010000 50 P 124 01111100 7C |
37 00100101 25 % 81 01010001 51 Q 125 01111101 7D }
38 00100110 26 & 82 01010010 52 R 126 01111110 7E ~
39 00100111 27 ' 83 01010011 53 S 127 01111111 7F DEL
40 00101000 28 ( 84 01010100 54 T
41 00101001 29 ) 85 01010101 55 U
42 00101010 2A * 86 01010110 56 V
43 00101011 2B + 87 01010111 57 W
Page 308
BCD to ASCII Conversion

Some data returned by the EMV kernel is in BCD (Binary Coded Decimal) format. This data may have to
be converted to ASCII prior to being sent to the host.
To convert BCD to ASCII involves taking each binary digit or “nibble” and adding hexadecimal (0x30) to it.
The resulting ASCII field will be twice the length of the BCD field if all of the digits are used.
The following example illustrates the process:
1. Amount Authorized (Tag 9F02) is six bytes in length and contains:
a. ’00 00 00 01 23 45’ (BCD)
2. Isolate the 12 binary digits and add 0x30 to each one to obtain the equivalent ASCII digits
3. The resulting field is 12 bytes in length. Expressed as hexadecimal it is:
a. ‘0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x31 0x32 0x33 0x34 0x35’ (Hex)
b. ‘000000012345’ (ASCII)
Canadian Processing
Interac Account Selection Prompting
When processing a Canadian Interac card, the cardholder must be prompted to select the account type
the funds should be debited from. The Account Selection prompt must be presented in the cardholder
language after Amount Confirmation and before PIN Entry.
Interac Account Selection Prompting
Account English Short Name French Short Name*
Chequing CHQ CHQ
Savings SAV EP
*EMV POS Solutions deployed in Canada must support displaying the Interac Account Selection Prompt
in French
Page 309
Canadian Language Requirements specific to Interac

EMV POS Solutions being deployed in Canada must:
1. Support both English and French
2. Perform cardholder prompting in the preferred cardholder language (see Cardholder Language
Selection section)
3. Print the cardholder receipt in the preferred cardholder language (see Sample Approved Receipt.
French section)
CMS EMV RQ 01601 Canadian EMV POS Solutions must support French cardholder prompting
• Merchant Services all EMV POS Solutions deployed in Canada support French prompting and
that cardholder prompting be performed in the cardholder’s preferred language (English/French).
CMS EMV RQ 01602 Canadian EMV POS Solutions must support French receipt printing
• Merchant Services requires that all EMV POS Solutions being deployed in Canada support
French receipt printing and that the cardholder receipt be printed in the cardholder’s preferred
language (English/French).
Sample Approved Receipt - French
The following is an example of a receipt for a credit EMV purchase transaction approved online by the
host. The CVM used was online PIN and the card track data was obtained by reading the EMV chip.
Page 310
• Transaction Type (Achat)
• Application Preferred Name (Tag 9F12) is on the chip in a supported character set, so it is printed
(VISA)
Page 311
chip (CHIP)
o AID (A0000000031010)
o TVR (0000008000)
o TSI (F800)
o AC (0123456789ABCEDF)
o ARC (00)
• Cardholder Verification Method. A PIN was entered so “VERIFIE EN NIP” must be printed
• Merchant and Cardholder receipt copies should be identical with the exception of the receipt copy
indicator
Sample Declined Receipt - French
The following is an example of a receipt for a credit EMV purchase transaction declined online by the
host. The CVM used was Signature and the Track 2 PAN was obtained by reading the EMV chip.
Page 312
• Transaction Type (Achat)
• Application Preferred Name (Tag 9F12) is on the chip in a supported character set, so it is printed
(VISA)
chip (CHIP)
Page 313
o AID (A0000000031010)
o TVR (0000008000)
o IAD (06010A03A40002)
o TSI (E800)
o ARC (05)
• Transition was declined so Cardholder Verification Method is not printed
• Merchant and Cardholder receipt copies should be identical with the exception of the receipt copy
indicator
Interac Application Selection

For Interac card processing the Application Selection process differs slightly from the process used for
other US domestic debit cards:
1. Credit / Debit Selection and US Debit Processing is not performed (see Credit / Debit Selection
2. Application Selection Flag “Canadian Flag” processing must be performed
Application Selection Flag “Canadian Flag” (Tag DF62) Processing
EMV POS Solutions supporting Interac must support Application Selection Flag (ASF) processing. This
processing is performed after Implicit / Explicit Application Selection has completed and before Final
Selection begins.
During Application Selection Flag processing, the EMV POS Solution must check for the presence of the
Issuer Country Code (Tag 5F56) and the Application Selection Flag (Tag DF62) in either of the following
locations:
1. When the card and EMV POS Solution both support the Payment System Environment (PSE):
a. Check the optional Directory Discretionary Template (Tag 73) of an Application Definition
File (ADF) directory entry in the Payment System Directory
2. Otherwise:
Page 314
a. Check the optional File Control Information (FCI) Issuer Discretionary Template (Tag
BF0C) of the ADF
If the Application Selection Flag (Tag DF62) is not present, and the Candidate List contains more than
one mutually supported application, then the Candidate List must be presented to the cardholder for
Application Selection.
The Application Selection Flag (Tag DF62) is be interpreted as follows:
“Canadian” Application Selection Flag (Tag DF62)
Byte Usage Format Value
Byte 1 ABM Binary Bit 8 = 1: Use as Primary application at ABM
Bit 7 = 1: Use as Secondary application at ABM
Bit 6 = 1: RFU
Byte 2 ABM Binary Bit 8 = 1: Use as Primary application at POS
Bit 7 = 1: Use as Secondary application at POS
Bit 6-1: RFU
Byte 3 RFU
This interpretation of the Issuer Country Code and Application Selection Flag occurs after the list of
mutually supported applications has been built. The EMV POS Solution must then interrogate the card for
the presence of the ASF and Issuer Country Code to create two sub-lists; a Primary sub-list and a
Secondary sub-list.
Step 1 Creating Application Sub-lists
• If Tag 5F56 is not present, the PIN Pad adds the application (AID) to the Primary sub-list
• If Tag 5F56 is not present but Tag DF62 is present, the PIN Pad adds the application to Primary
sub-list
• If Tag 5F56 is present for the application in question and value does not equal “CAN”, the PIN
Pad adds application to Primary sub-list
• If Tag 5F56 is present and is equal to “CAN”, the PIN Pad interrogates the chip card for the
presence of Tag DF62Application Selection Flag
Page 315
Step 2 Creating Application Sub-lists
If the ASF data element is present, the PIN Pad will use it to determine if the application is intended for
use as Primary Application, a Secondary Application or if it should not be used. This is determined by the
ASF Byte 2 value.
Application Selection Flag (Tag DF62) Byte 2 Interpretation
Bit 8 Bit 7 Value
0 0 Application ignored, not added to Primary or Secondary sub-list
1 0 Add application to Primary sub-list
0 1 Add application to Secondary sub-list
1 1 Add application to Primary sub-list
Application Selection Scenarios
The following table outlines the various Application Selection Flag scenarios.
Application Selection Scenarios
Scenario Tag 5F56 Tag DF62 Byte 1 Tag DF62 Byte 2 (POS) POS Candidate
Issuer (ABM) Application Application Selection List
Country Code Selection Flag Flag
1 “CAN” Bit 8 = 1 Bit 8 = 1 Primary sub-list
2 “CAN” All zeroes Bit 8 = 1 Primary sub-list
3 “CAN” All zeroes Bit 7 = 1 Secondary sub-

list
4 “CAN” Bit 8 = 1 All zeroes N/A
5 Not Present Present Present Primary sub-list
6 Not “CAN” N/A N/A Primary sub-list
Page 316
Once the mutually supported applications have been categorized as Primary and Secondary, the PIN Pad
will present one of the lists for Application Selection and cardholder confirmation.
1. If the Primary sub-list is not empty, the Primary sub-list is presented.
2. If the Primary sub-list is empty, but the Secondary sub-list is not empty, the Secondary is
presented.
3. If both the Primary and Secondary sub-lists are empty, the transaction must be terminated.
Note: If during selection the sub-list being presented (Primary or Secondary) becomes empty (e.g. all
applications in the sub-list are blocked), the transaction must be terminated.
Automatic Application Selection
If there is only one mutually supported application in the sub-list being used, the PIN Pad checks Bit-8 of
the Application Priority Indicator (Tag 87) for that application to see if cardholder confirmation is required.
If Bit-8 is:
• ‘0’. The application is selected automatically and cardholder confirmation is not required
• ‘1’. Cardholder confirmation is required to select the application
Note: If there is only one mutually-supported application, the EMV POS Solution must check the
Cardholder Approval Indicator (Tag 87 bit-8) to determine if Cardholder Application Confirmation is
required. For more information on this process see Cardholder Application Confirmation section.
Canadian Debit Transaction Set

This section defines the Canadian debit transaction set supported by Merchant Services and specifies
how the transactions are identified for each of the host interfaces:
• PNS ISO
• UTF
• Stratus Online / Stratus Batch (not supported)
Note: Interac EMV AID is only permitted with Canadian POS solutions at this time. US POS solutions
must not be coded to support the Interac AID until further notice from Merchant Services. Interac
transactions originated through US POS solutions, where the presented Interac card supports Visa Debit,
Page 317
will process as EMV using the Visa Global AID. Interac cards that do not support Visa Debit must
continue to be processed by magnetic stripe.
Canadian Debit Transaction Set
Transaction ISO ISO UTF UTF Stratus Stratus Batch

* **
Type (TCS) (HCS)** (TCS)* (HCS) Online (TCS)*
(TCS)*
Auth Only N/A Pre-Auth N/A Pre-Auth N/A N/A

30
1200
(Future)
Sale N/A 1200 N/A 27 N/A N/A
Sale N/A 1200 N/A 28 N/A N/A

w/Cashback
Processing
Code =
099700
Prior Sale / N/A 1200 N/A 31 N/A N/A

Completion
Processing (Future)
Code =
179700
(Future)
Offline N/A 1200 N/A 36 Sale N/A N/A

Posting
Processing 37 Return
Code =
119700
Return / N/A 1200 N/A 29 N/A N/A

Refund
Processing
Code =
209700
Page 318
Transaction ISO ISO UTF UTF Stratus Stratus Batch

* **
Type (TCS) (HCS)** (TCS)* (HCS) Online (TCS)*
(TCS)*
Void / N/A 1400 N/A 44 Void N/A N/A

Merchant Sale
Reversal
**Host Capture System
Interac Cashback Processing

When performing an Interac transaction with cashback the following rules apply:
1. Transaction Amount (Tag 9F02) must include the total amount (Sale Amount + Cashback
Amount)
2. Other Amount (Tag 9F03) must be present and set to zeroes.
EMV Chip Commands

Note: The information in this chapter has been extracted from the EMV 4.3 Book 3 Application
Specification.
This section contains commands that can be sent to the chip for processing. The commands are sent in
Application Protocol Data Unit (APDU) format consisting of a mandatory four byte header followed by a
conditional variable length body.
The APDU command format is as follows.
Mandatory Header Conditional Body
CLA; INS; P1; P2 Lc; Data; Le
Where:
• CLA. Class Byte of the Command Message
• INS. Instruction Byte of Command Message
Page 319
• P1. Parameter 1
• P2. Parameter 2
• Lc. Length of command Data field
• Data. Command data
• Le. Maximum length of expected data returned (when set to zero 256 bytes may be returned)
Note: The CLA, INS, P, P2, Lc, Data and Le values have been provided for each of the commands
described in the sections below.
The APDU response format is as follows.
Body Trailer
Data SW1; SW2
Where:
• Data. Response Data
• SW1. Status Byte 1
• SW2. Status Byte 2
For a list of the SW1/SW2 status bytes see EMV Response Codes (SW1 SW2) section.
Application Block
The APPLICATION BLOCK command is a post-issuance command that invalidates the currently selected
application.
Following the successful completion of an APPLICATION BLOCK command:
• An invalidated application will return the status bytes SW1 SW2 = '6283' (‘Selected file
invalidated’) in response to a SELECT command.
• An invalidated application will return only an Application Authentication Cryptogram (AAC) as AC

in response to a GENERATE AC command.
Page 320
APPLICATION BLOCK Command Values
Code Value
CLA '8C' or '84'; coding according to the secure messaging specified in Book 2
INS '1E'
P1 '00'; all other values are RFU
Lc Number of data bytes
Data Message Authentication Code (MAC) data component
Coding according to the secure messaging specified in Book 2
Le Not present
Application Unblock
The APPLICATION UNBLOCK command is a post-issuance command that rehabilitates the currently
selected application. Following the successful completion of an APPLICATION UNBLOCK command, the
restrictions imposed by the APPLICATION BLOCK command are removed.
APPLICATION UNBLOCK Command Values
Code Value
INS '18'
Data Message Authentication Code (MAC) data component; coding according to the secure
messaging specified in Book 2
Le Not present
Page 321
Card Block
The CARD BLOCK command is a post-issuance command that permanently disables all applications in
the ICC, including applications that may be selected implicitly. Following the successful completion of a
CARD BLOCK command, all subsequent SELECT commands will return the status bytes SW1 SW2 =
'6A81' (‘Function not supported’) and perform no other action.
CARD BLOCK Command Values
Code Value
INS '16'
Data Message Authentication Code (MAC) data component; coding according to the secure
messaging specified in Book 2
Le Not present
External Authenticate
The EXTERNAL AUTHENTICATE command is used to request the ICC to verify a cryptogram returned
by the issuer after going online.
EXTERNAL AUTHENTICATE Command Values
Code Value
CLA '00'
INS '82'
P1 '00'
P2 '00'
Page 322
Code Value
Lc 8-16
Data Issuer Authentication Data
Le Not present
EXTERNAL AUTHENTICATE Response Codes
Code Value
6300 Indicates “Issuer authentication failed”
9000 Indicates the command was successfully executed
Generate AC
The GENERATE AC command sends transaction-related data to the ICC, which computes and returns a
cryptogram.
GENERATE AC Command Values
Code Value
CLA '80'
INS 'AE'
P1 Reference control parameter (see below)
P2 '00'
Lc Var.
Data Transaction-related data
Le '00'
GENERATE AC Reference Control Parameter
0 0 AAC
Page 323
0 1 TC
1 0 ARQC
1 1 RFU
X RFU
0 CDA signature not requested
1 CDA signature requested
X X X X RFU
The data field of the response message consists of a TLV coded data object. The coding of the data
object will be according to one of the following two formats.
• Format 1. The data object returned in the response message is a primitive data object with tag
equal to '80'. The value field consists of the concatenation without delimiters (tag and length) of
the value fields of the data objects specified in the table below:
Value Presence
Cryptogram Information Data (CID) M
Application Transaction Counter (ATC) M
Application Cryptogram (AC) M
Issuer Application Data (IAD) O
• Format 2. The data object returned in the response message is a constructed data object with
tag equal to '77'. The value field may contain several TLV coded objects, but will always include
the Cryptogram Information Data, the Application Transaction Counter and the cryptogram
computed by the ICC (either an AC or a proprietary cryptogram). The utilization and interpretation
of proprietary data objects which may be included in this response message are outside the
scope of these specifications. Format 2 will be used if the response is being returned in a
signature as specified for the CDA function described in section 6.6 of Book 2. The required data
elements for the response are shown in the appropriate tables in that section.
Page 324
Coding of Cryptogram Information Data
0 0 AAC
0 1 TC
1 0 ARQC
1 1 AAR
X X Payment brand specific
0 No advice required
1 Advice required
X X X Reason/advice/referral code
0 0 0 No information given
0 0 1 Service not allowed
0 1 0 PIN Try Limit exceeded
0 1 1 Issuer Authentication failed
1 X X RFU
Get Challenge
The GET CHALLENGE command is used to obtain an unpredictable number from the ICC for use in a
security-related procedure. The challenge will be valid only for the next issued command.
GET CHALLENGE Command Values
Code Value
CLA '00'
INS '84'
P1 '00'
Page 325
Code Value
P2 '00'
Lc Not present
Data Not present
Le '00'
Get Data
The GET DATA command is used to retrieve a primitive data object not encapsulated in a record within
the current application. The usage of the GET DATA command is limited to the retrieval of the following
primitive data objects:
• ATC (Tag 9F36)
• Last Online ATC Register (Tag 9F13)
• PIN Try Counter (Tag 9F17)
• Log Format (Tag 9F4F)
GET DATA Command Values
Code Value
CLA '80'
INS 'CA'
P1 P2 '9F36', '9F13', '9F17' or '9F4F'
Lc Not present
Data Not present
Le '00'
Get Processing Options

The GET PROCESSING OPTIONS command initiates the transaction within the ICC. The ICC returns the
Application Interchange Profile (AIP) and the Application File Locator (AFL).
Page 326
GET PROCESSING OPTIONS Command Values
Code Value
CLA '80'
INS 'A8'
P1 '00'
P2 '00'
Lc Var.
Data Processing Options Data Object List (PDOL) related data
Le '00'
The coding of the data object will be according to one of the following two formats.
equal to '80'. The value field consists of the concatenation without delimiters (tag and length) of
the value fields of the AIP and the AFL. The coding of the data object returned in the response
message is shown below:
'80' Length Application Interchange Profile Application File Locator
tag equal to '77'. The value field may contain several TLV coded objects but always includes the
AIP and the AFL. The utilization and interpretation of proprietary data objects which may be
included in this response message are outside the scope of these specifications.
o The AIP specifies the application functions that are supported by the application in the
ICC
o The AFL consists of the list, without delimiters, of files and related records for the
currently selected application
Internal Authenticate
The INTERNAL AUTHENTICATE command initiates the computation of the Signed Dynamic Application
Data by the card using all of the following:
Page 327
• Challenge data sent from the terminal
• ICC data
• A relevant private key stored in the card
INTERNAL AUTHENTICATE Command Values
Code Value
CLA '00'
INS '88'
P1 '00'
P2 '00'
Lc Length of authentication-related data
Data Authentication-related data
Le '00'
The ICC returns the Signed Dynamic Application Data to the terminal.
The data field of the response message consists of a TLV coded data object. The coding of the data
object will be according to one of the following two formats:
equal to '80'. The value field consists of the value field of the Signed Dynamic Application Data.
tag equal to '77'.The value field may contain several TLV coded objects but always includes the
Signed Dynamic Application Data. The utilization and interpretation of proprietary data objects
which may be included in this response message are outside the scope of these specifications.
Note: To ensure that the INTERNAL AUTHENTICATE command response data length is within the 256
byte limit, the length of the Signed Dynamic Application Data plus the length of the TLV encoded optional
data (if present) will remain within the limits as specified in Book 2 Annex D.
Page 328
PIN Change/Unblock
The PIN CHANGE/UNBLOCK command is a post-issuance command. Its purpose is to provide the issuer
the capability either to unblock the PIN or to simultaneously change and unblock the reference (offline)
PIN.
PIN CHANGE/UNBLOCK Command Values
Code Value
INS '24'
P1 '00'
P2 00=Unblock the reference (offline) PIN by resetting the PIN Try Counter to the PIN Try
Limit. There is no PIN update, since the PIN CHANGE/UNBLOCK command does not
contain a new PIN value
01=reserved for each payment scheme
02=reserved for each payment scheme
Data Enciphered PIN data component, if present and MAC data component; coding
(according to the secure messaging specified in Book 2)
Le Not present
Upon successful completion of the command, the card will perform the following functions:
• The value of the PIN Try Counter will be reset to the value of the PIN Try Limit
• If requested, the value of the reference PIN will be set to the new PIN value
If PIN data is transmitted in the command it will be enciphered for confidentiality.
Note: The reference (offline) PIN, stored within the card, is the PIN associated with the application and is
the one the card uses to check the Transaction PIN Data transmitted within the VERIFY command.
Page 329
Read Record
The READ RECORD command reads a file record in a linear file. The response from the ICC consists of
returning the record.
READ RECORD Command Values
Code Value
CLA '00'
INS 'B2'
P1 Record Number
P2 Reference control parameter (see below)
Lc Not present
Data Not present
Le '00'
READ RECORD Reference Control Parameter
X X X X X SFI
1 0 0 P1 is a record number
The data field of a successful READ RECORD command response message contains the record read.
For SFIs in the range 1-10, the record is a TLV constructed data object and is coded as shown below:
‘70’ Length Record Template
Select
The SELECT command is used to select the ICC PSE, DDF or ADF corresponding to the submitted file
name or AID.
Page 330
SELECT Command Values
Code Value
CLA '00'
INS 'A4'
P1 Reference Control Parameter (see below)
P2 Selection Options (see below)
Lc '05'–'10'
Data File Name
Le '00'
SELECT Reference Control Parameter (P1)
0 0 0 0 0
1 Select by Name
0 0
SELECT Command Options Parameter (P2)
0 0 First or only occurrence
1 0 Next occurrence
The data field of the response message contains the FCI specific to the selected PSE, DDF or ADF. No
additional data elements will be present in the FCI template (Tag 6F) returned in the SELECT command
response, other than those contained in template 'BF0C'. Data elements present in templates '6F' or
'BF0C' that are not expected or understood by the terminal, because the terminal does not support any
issuer-specific processing, will be ignored.
Page 331
SELECT Response Message Data Field (FCI) of the PSE
Tag level Tag level Tag level 3 Tag level 4 Value Presence
1 2
6F FCI Template M
84 DF Name M
A5 FCI Proprietary Template M
88 SFI of the Directory M

Elementary File
5F2D Language Preference O
9F11 Issue Code Table Index O
BF0C FCI Issuer Discretionary Data O
XXXX One or more additional O

proprietary data elements
(Tag
from an application provider,
constructed
issuer, or IC card supplier or
according to
EMV-defined tags that are
Book 3, Annex
specifically allocated to
B)
'BF0C'
SELECT Response Message Data Field (FCI) of the DDF
1 2
6F FCI Template M
84 DF Name M
Page 332
1 2
88 SFI of the Directory M

Elementary File

(Tag
constructed
according to
Book 3, Annex
B)
'BF0C'
SELECT Response Message Data Field (FCI) of the ADF
1 2
6F FCI Template M
84 DF Name M
50 Application Label M
87 Application Priority Indicator O
9F38 PDOL O
5F2D Language Preference O
9F11 Issuer Code Table Index O
9F12 Application Preferred Name O
Page 333
1 2
9F4D Log Entry O

(Tag
constructed
according to
Book 3, Annex
B)
'BF0C'
Verify
The VERIFY command initiates in the ICC the comparison of the Transaction PIN Data sent in the data
field of the command with the reference PIN data associated with the application. The method of
comparison is proprietary to the application in the ICC.
The VERIFY command applies when the Cardholder Verification Method (CVM) chosen from the CVM
List is an offline PIN.
VERIFY Command Values
Code Value
CLA '00'
INS '20'
P1 '00'
P2 Qualifier of the Verify Reference Data (see below)
Lc Var.
Data Transaction PIN Data
Le Not present
Page 334
VERIFY Reference Data (P2)
0 0 0 0 0 0 0 0 As defined in ISO/IEC 7816-4
1 0 0 0 0 0 0 0 Plaintext PIN, see below
1 0 0 0 0 X X X Reserved for future use
1 0 0 0 1 0 0 0 Enciphered PIN
1 0 0 0 1 0 X X Reserved for future use
1 0 0 0 1 1 X X Reserved for future use
1 0 0 1 X X X X Reserved for future use
The plaintext offline PIN block will be formatted as follows:
C N P P P P P/F P/F P/F P/F P/F P/F P/F P/F F F
Where:
C = Control Field (4 bits ‘0010’)
N = Length of PIN (4 to 12) (4 bits)
P = PIN Digit (4 bits)
F = Hex ‘F’ for padding (4 bits ‘1111’)
EMV Response Codes (SW1 SW2)

EMV Response Codes (SW1 SW2)
SW1 Description
SW2
61 xx xx = the number of response bytes still available. Use GET_RESPONSE (C0) to access
this data.
Page 335
SW1 Description
SW2
62 00 No information given
62 81 Returned data may be corrupted
62 82 EOF reached before end of data
62 83 Selected file invalided (Application Blocked)
62 84 Bad file control information format
62 85 Selected file in termination state
62 86 No input data available from a sensor on the card
63 81 File filled up with last write
63 Cx Counter value is x
64 00 Execution error
64 01 Immediate response required by the card
65 01 Memory failure, problem writing to EEPROM
65 81 Error, memory failure
66 xx Security error
67 xx Check error
68 81 Logical channel not supported
68 82 Secure messaging not supported
Page 336
SW1 Description
SW2
69 81 Command incompatible with file structure
69 82 Security status not satisfied
69 83 Authentication method blocked
69 84 Reference data not usable
69 85 Conditions of use not satisfied
69 86 Command not allowed (no current EF)
69 87 Expected secure messaging data objects missing
69 88 Incorrect secure messaging data objects
6A 00 No information given
6A 80 Incorrect parameters in the command data field
6A 81 Card Blocked / Function not supported
6A 82 File or application not found
6A 83 Record not found
6A 84 Not enough memory space in the file
6A 85 Inconsistent with TLV structure
6A 86 Incorrect parameters P1-P2
6A 87 N inconsistent with parameters P1-P2
6A 88 Referenced data or reference data not found (exact meaning depending on the command)
6A 89 File already exists
Page 337
SW1 Description
SW2
6A 8A DF name already exists
6B 00 Wrong parameters P1-P2
6C xx Wrong L field; SW2 encodes the exact number of available data bytes
6D 00 Instruction code not supported or invalid
6E 00 Class not supported
6F 00 No precise diagnosis
90 00 Success, no further qualification
EMV Reference Tables

The following tables are provided as reference material to assist in understanding the EMV processes.
Application Interchange Profile (Tag 82)

Application Interchange Profile (Tag 82), Byte 1
0 Reserved for future use
1 Static data authentication supported
1 Dynamic data authentication supported
1 Cardholder verification supported
1 Perform Terminal Risk Management
1 Issuer authentication supported
1 Combined DDA/AC supported
Page 338
Application Interchange Profile (Tag 82), Byte 2
Application Priority Indicator (Tag 87)

Application Priority Indicator (Tag 87), Byte 1
1 Application cannot be selected without cardholder

confirmation
0 Application can be selected without confirmation of

the cardholder.
0 0 0 Reserved for future use
0 0 0 0 No Priority Assigned
X X X X Order in which the application is to be listed or

selected.
Ranging from 1-15, with 1 being the highest priority
Page 339
Application Usage Control (Tag 9F07)

Application Usage Control (Tag 9F07), Byte 1
1 Valid for domestic cash transactions
1 Valid for international cash transactions
1 Valid for domestic goods
1 Valid for international goods
1 Valid for domestic services
1 Valid for international services
1 Valid at ATMs
1 Valid at terminals other than ATMs
Application Usage Control (Tag 9F07), Byte 2
1 Domestic cashback allowed
1 International cashback allowed
Page 340
Cardholder Verification Rule (part of CVM List)

Cardholder Verification Rule, Byte 1
0 Fail cardholder verification if CVM unsuccessful
1 Apply succeeding CVR if CVM unsuccessful
0 0 0 0 0 0 Fail CVM processing
0 0 0 0 0 1 Plain text PIN verification performed by ICC
0 0 0 0 1 0 Enciphered PIN verified online
0 0 0 0 1 1 Plain text PIN verification performed by ICC and signature

(paper)
0 0 0 1 0 0 Enciphered PIN verification performed by ICC
0 0 0 1 0 1 Enciphered PIN verification performed by ICC and

signature (paper)
0 X X X X X Reserved for future use by the EMV specification
Range 000110-011101
0 1 1 1 1 0 Signature (paper)
0 1 1 1 1 1 No CVM required.
1 0 X X X X Reserved for future use by the EMV specification
Range 100000-101111
Range 110000-111110
Page 341
Cardholder Verification Rule, Byte 2
Value Meaning
00 Always
01 If unattended cash
02 If not unattended cash and not manual cash and not purchase with cashback
03 If terminal supports the CVM
04 If manual cash
05 If purchase with cashback
06 If transaction is in the application currency and is under ‘x’ value
07 If transaction is in the application currency and is over ‘x’ value
08 If transaction is in the application currency and is under ‘y’ value
09 If transaction is in the application currency and is over ‘y’ value
0A-7F Reserved for future use
80-FF Reserved for use by individual payment schemes
Cardholder Verification Method Results (Tag 9F34)

Cardholder Verification Method Results (Tag 9F34), Byte 1
0 Fail cardholder verification if CVM unsuccessful
1 Apply succeeding CVR if CVM unsuccessful
0 0 0 0 0 0 Fail CVM processing
0 0 0 0 0 1 Plain text PIN verification performed by ICC
Page 342
0 0 0 0 1 0 Enciphered PIN verified online
0 0 0 0 1 1 Plain text PIN verification performed by ICC and

signature (paper)
0 0 0 1 0 0 Enciphered PIN verification performed by ICC
0 0 0 1 0 1 Enciphered PIN verification performed by ICC and

signature (paper)
0 X X X X X Reserved for future use by the EMV specification
Range 000110-011101
0 1 1 1 1 0 Signature (paper)
0 1 1 1 1 1 No CVM required
Range 100000-101111
Range 110000-111110
1 1 1 1 1 1 This value is not available for use
Value Meaning
00 Always
01 If cash or cashback
02 If not cash or cashback
03 If terminal supports the CVM
Page 343
Value Meaning
06 If transaction is in the application currency and is under ‘x’ value
07 If transaction is in the application currency and is over ‘x’ value
08 If transaction is in the application currency and is under ‘y’ value
09 If transaction is in the application currency and is over ‘y’ value
Value Meaning
00 Unknown (e.g. for signature)
01 Failed (e.g. Offline PIN)
02 Successful (e.g. Offline PIN)
Card Verification Results (included in Tag 9F10)

The following Card Verification Results (CVR) definition is as per the EMVCo CCD specifications. Specific
card brand definitions will differ.
Card Verification Results, Byte 1
X X Application Cryptogram Type returned in 2nd

GENERATE AC
0 0 AAC
0 1 TC
1 0 2nd GENERATE AC Not Requested
1 1 Reserved for future use
X X Application Cryptogram Type returned in 1st

GENERATE AC
Page 344
0 0 AAC
0 TC
1 0 ARQC
1 1 Reserved for future use
1 CDA Performed
1 Offline DDA Performed
1 Issuer Authentication Not Performed
1 Issuer Authentication Failed
X X X X Low Order Nibble of PIN Try Counter
1 Offline PIN Verification Performed
1 Offline PIN Verification Performed and PIN Not

Successfully Verified
1 PIN Try Limit Exceeded
1 Last Online Transaction Not Completed
1 Lower Offline Transaction Count Limit Exceeded
1 Upper Offline Transaction Count Limit Exceeded
1 Lower Cumulative Offline Amount Limit Exceeded
1 Upper Cumulative Offline Amount Limit Exceeded
Page 345
1 Issuer-discretionary bit 1
X X X X Number of Issuer Script commands containing secure

messaging processed
1 Issuer Script Processing Failed
1 Offline Data Authentication Failed on Previous

Transaction
1 Go Online on Next Transaction was Set
1 Unable to Go Online
Page 346
Cryptogram Information Data (Tag 9F27)

Cryptogram Information Data (Tag 9F27)
X X Application Cryptogram Type returned in 2nd

GENERATE AC
0 0 AAC
0 1 TC
1 0 ARQC
1 1 AAR
0 0 Payment System specific cryptogram
0 No Advice Required
1 Advice Required
X X X Reason/advice/referral code
0 0 0 No information given
0 0 1 Service not allowed
0 1 0 PIN Try Limit Exceeded
0 1 1 Issuer Authentication Failed
Terminal Capabilities (Tag 9F33)

Terminal Capabilities (Tag 9F33), Byte 1
1 Manual Key Entry
Page 347
1 Magnetic Stripe
1 IC with Contacts
1 Plain text PIN for ICC verification
1 Enciphered PIN for online verification
1 Signature (paper)
1 Enciphered PIN for offline verification
1 NO CVM
1 Static data authentication
1 Dynamic data authentication
Page 348
1 Card capture
1 Combined DDA/AC supported
Additional Terminal Capabilities (Tag 9F40)

Additional Terminal Capabilities (Tag 9F40), Byte 1
1 Cash
1 Goods
1 Services
1 Cashback
1 Inquiry
1 Transfer
1 Payment
1 Administrative
Page 349
1 Numeric keys
1 Alphabetic and special character keys
1 Command keys
1 Function keys
1 Print, attendant
1 Print, cardholder
1 Display, attendant
Page 350
1 Display, cardholder
1 Code table 10
1 Code table 9
1 Code table 8
1 Code table 7
1 Code table 6
1 Code table 5
1 Code table 4
1 Code table 3
1 Code table 2
1 Code table 1
Terminal Verification Results (Tag 95)

Terminal Verification Results (Tag 95), Byte 1 (Offline Data Authentication)
1 Off-line data authentication not performed
1 Off-line static data authentication failed
1 ICC data missing
Page 351
1 Card appears on terminal exception file
1 Off-line dynamic data authentication failed
1 Combined DDA/AC generation failed
1 SDA selected
Terminal Verification Results (Tag 95), Byte 2 (Processing Restrictions)
1 ICC and terminal have different application versions
1 Expired application
1 Application not yet effective
1 Requested service not allowed for card product
1 New card
Terminal Verification Results (Tag 95), Byte 3 (Cardholder Verification)
1 Cardholder verification failed
1 Unrecognized CVM.
1 PIN try limit exceeded
1 PIN entry required. PIN Pad not present or not

working.
Page 352
1 PIN entry required. PIN Pad present but PIN was not
entered.
1 Online PIN entered
Terminal Verification Results (Tag 95), Byte 4 (Terminal Risk Management)
1 Transaction exceeds floor limit
1 Lower consecutive off-line limit exceeded
1 Upper consecutive off-line limit exceeded
1 Transaction selected randomly for online processing
1 Merchant forced transaction online
Terminal Verification Results (Tag 95), Byte 5 (Transaction Completion)
1 Default TDOL used
1 Issuer authentication was unsuccessful
1 Script processing failed before final generate AC
1 Script processing failed after final generate AC
Page 353
Transaction Status Indicator (Tag 9B)

Transaction Status Indicator (Tag 9B), Byte 1
1 Offline data authentication performed
1 Cardholder verification performed
1 Card risk management performed
1 Issuer authentication performed
1 Terminal risk management performed
1 Script processing performed
Transaction Status Indicator (Tag 9B), Byte 2
Page 354
Page 355

EMV Implementation Tandem Supplemental Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EMV Implementation Tandem Supplemental Guide

Uploaded by

Copyright:

Available Formats

EMV Implementation

Tandem Supplemental Guide

Copyright © 2023 JPMorgan Chase & Co. All rights reserved.

Effective upon publication

UPI CVM limits

o UnionPay Credit and Debit Contactless Testing Parameters

o UnionPay Quasi Credit and US Common Contactless Testing Parameters

Effective upon publication

UnionPay brand name

• Throughout the document, updated CUP references to UnionPay via Discover.

Tandem Supplemental Guide .................................................................................................................... 1

Version 3.6.0.0 .......................................................................................................................................... 3

Version 3.5.0.0 .......................................................................................................................................... 3

EMVCo LLC ............................................................................................................................................. 11

EMV Terminal Configurations.................................................................................................................. 11

Fully Integrated ECR Solution ............................................................................................................. 12

Partially Integrated ECR Solution ........................................................................................................ 13

Semi-Integrated ECR Solution ............................................................................................................. 15

Standalone POS Solution with Internal PIN Pad ................................................................................. 16

Standalone POS Solution with External PIN Pad ................................................................................ 17

Safetech Encryption ................................................................................................................................ 18

Safetech Tokenization ............................................................................................................................. 19

EMV and Contactless Solution Components .......................................................................................... 19

Merchant Services Supported Configurations ......................................................................................... 20

Development and Testing........................................................................................................................ 32

Technical Profile Questionnaire .............................................................................................................. 38

Technical Support .................................................................................................................................... 41

Development Host Connection Information ............................................................................................. 41

Integration Testing Process ..................................................................................................................... 41

Integration Testing Process ................................................................................................................. 42

Card Brand Certification .......................................................................................................................... 45

Post Rollout Re-Test ............................................................................................................................... 47

EMV Contact and Contactless Test Tools ............................................................................................... 48

Collis Merchant Test Suite ................................................................................................................... 49

ICC Solutions Test Suite Bundles for Certification .............................................................................. 52

Integrated Solution Validation ................................................................................................................. 54

EMV Benefits ........................................................................................................................................... 55

EMV Capability Enablement or Disablement .......................................................................................... 55

Online versus Offline EMV Transactions ................................................................................................. 55

EMV Transaction Steps ........................................................................................................................... 56

EMV Credit Transaction Set ................................................................................................................ 58

EMV Debit Transaction Set ................................................................................................................. 59

Transaction Processing ........................................................................................................................... 60

Sale Transactions ................................................................................................................................ 60

Authorization or Pre-Authorization Transactions ................................................................................. 60

Incremental Authorization .................................................................................................................... 61

Balance Inquiry Transactions .............................................................................................................. 62

Quick Service Transactions ................................................................................................................. 62

Contactless Benefits ............................................................................................................................ 64

MSD vs EMV Grade............................................................................................................................. 64

Contactless Card Schemes ................................................................................................................. 64

EMV Contactless Transaction Sets ..................................................................................................... 65

EMV Transaction Flow ............................................................................................................................ 67

Full EMV Transaction Flow .................................................................................................................. 67

Partial EMV Transaction Flow ............................................................................................................. 73

Contactless Transaction Flow .............................................................................................................. 76

Chip Processing Guidelines .................................................................................................................... 78

Tender Processing ............................................................................................................................... 78

EMV Transaction Initiation ................................................................................................................... 82

Chip Read Flow ................................................................................................................................... 83

Fallback Processing ............................................................................................................................. 86

Read Data Records ............................................................................................................................. 98

Cardholder Language Selection .......................................................................................................... 99

Cardholder Prompting ........................................................................................................................ 100