Visa TADG

Transaction Acceptance Device Guide
Version 2.0
Effective: March 2011
© 2005 – 2011 Visa. All Rights Reserved
Visa Public
This document is provided as a supplemental guide and tool to be used in conjunction with
Visa Operating Regulations; it is proprietary to Visa. The information in this document is
provided on an “as is”, “where is” basis, “with all faults” known and unknown to the
maximum extent permitted by applicable law, Visa explicitly disclaims all warranties,
express or implied, regarding this guide, including any implied warranty of merchantability,
fitness for a particular purposes, and non-infringement.
© 2005 – 2011 Visa International Service Organization. All Rights Reserved
Effective: March 2011
Visa Public
Table of Contents
List of Tables.............................................................................. 10
Chapter 1 Overview ................................................................... 14

1.1 Audience ................................................................................... 14
1.2 Scope ........................................................................................ 14
1.3 Compliance Documents and Devices....................................... 15
1.4 VEPS Best Practices ................................................................ 16
1.5 Terminology .............................................................................. 16
Chapter 2 Transaction Acceptance Environments................. 18

2.1 Attended POS Devices ............................................................. 18
2.1.1 Integrated POS Systems .............................................. 18
2.1.2 Standalone POS Devices ............................................. 18
2.1.3 Multilane POS Devices ................................................. 19
2.1.4 Shared Display and Separate Display Devices ............ 19
2.2 Unattended Cardholder Activated Terminals............................ 19
2.3 Automated Teller Machines ...................................................... 20
2.4 Self-Service Card Dispensing Kiosks ....................................... 20
2.5 Card Readers............................................................................ 21
2.5.1 Contactless Readers..................................................... 21
2.6 Processing Options and Host or Device Capture ..................... 22
2.7 Acquirer Stand-In ...................................................................... 23
2.8 Deferred Authorization .............................................................. 23
2.9 Partial Authorization.................................................................. 24
Chapter 3 General Acceptance................................................. 25

3.1 Primary Account Number Recognition and Processing............ 25
3.2 Expiration Date ......................................................................... 25
3.3 Account Selection ..................................................................... 25
3.4 Multiple Languages................................................................... 26
3.5 Device Messages...................................................................... 26
3.6 Transaction Receipts ................................................................ 29
3.7 Consumer Data on Receipts and Displays ............................... 29
3.8 Transaction Cancellation .......................................................... 29
3.9 Card Data in Online Message................................................... 30
Visa Public Page 1

3.10 Cash Back Identification and Processing ................................. 30

3.11 Transaction Speed.................................................................... 31
3.12 Unattended Cardholder Activated Transactions ....................... 31
3.13 Automated Teller Machines ...................................................... 32
3.14 Readers..................................................................................... 32
3.15 Visa Easy Payment Service...................................................... 32
Chapter 4 Magnetic Stripe Acceptance ................................... 34

4.1 Card Acceptance Methods........................................................ 34
4.2 Magnetic Stripe Data Processing ............................................. 34
4.3 Service Codes........................................................................... 34
4.4 VEPS Requirements ................................................................. 36
Chapter 5 Contact Chip Acceptance........................................ 37

5.1 Contact Chip Card Processing ................................................. 37
5.2 Card Insertion ........................................................................... 37
5.2.1 Chip Read ..................................................................... 38
5.2.2 Fallback Acceptance for Chip Read Failures................ 39
5.2.3 Merchant Override of Chip Read .................................. 39
5.2.4 Support for 19-Digit PANs............................................. 40
5.2.5 Device Messages.......................................................... 40
5.2.6 Historical Bytes ............................................................. 40
5.3 Application Selection................................................................. 40
5.3.1 Application Identifiers.................................................... 41
5.3.2 Transaction Routing...................................................... 42
5.3.3 Regional and Domestic Applications ............................ 43
5.3.4 V PAY............................................................................ 43
5.3.5 Cardholder Application Selection.................................. 43
5.3.6 Application Label and Application Preferred Name ...... 45
5.3.7 Multiple Languages....................................................... 45
5.4 Initiate Application Processing.................................................. 46
5.5 Read Application Data .............................................................. 46
5.5.1 Tags .............................................................................. 47
5.6 Processing Restrictions ............................................................ 47
5.7 Offline Data Authentication ....................................................... 47
5.8 Cardholder Verification ............................................................. 48
5.8.1 CVM List Processing Exceptions.................................. 49
5.8.2 Last PIN Try Message .................................................. 49
5.9 Terminal Risk Management...................................................... 50
Visa Public Page 2

5.9.1 Terminal Floor Limits .................................................... 50

5.9.2 Random Transaction Selection..................................... 50
5.10 Terminal Action Analysis........................................................... 53
5.10.1 Terminal Action Codes and Issuer Action Codes ......... 53
5.10.2 Online-Only Devices ..................................................... 54
5.11 Online Processing..................................................................... 54
5.11.1 Cash back Identification................................................ 55
5.12 Completion................................................................................ 55
5.12.1 Online-Authorized Transactions ................................... 58
5.12.2 Acquirer Stand-In .......................................................... 58
5.12.3 Acquirer Forced Settlement .......................................... 59
5.12.4 Deferred Authorization .................................................. 59
5.12.5 Authorization Response Cryptogram Consideration .... 60
5.12.6 Offline-Authorized Transactions ................................... 60
5.12.7 Declined Transactions .................................................. 60
5.12.8 Offline Declined ATM Transactions .............................. 61
5.13 Transaction Conclusion ............................................................ 61
5.14 Considerations for Industry-Specific Transaction Types .......... 62
5.14.1 Pre-Authorizations ........................................................ 62
5.14.2 Incremental Authorizations ........................................... 62
5.14.3 Sale Completion............................................................ 63
5.14.4 Status Check and Account Number Verification........... 63
5.14.5 Refunds......................................................................... 63
5.14.6 Reversals ...................................................................... 64
5.14.7 Referral ......................................................................... 65
5.14.8 Cancellation .................................................................. 65
5.14.9 Cryptogram Generation in Multi-Currency Scenarios... 65
5.15 EMV Transactions in Specific Industries .................................. 66
5.15.1 Hotels ............................................................................ 66
5.15.2 Fuel/Petrol Dispensing.................................................. 68
5.15.3 Mobile Top-Up .............................................................. 68
5.15.4 Forced Acceptance for On-Board Transactions ........... 68
5.15.5 Restaurants................................................................... 69
5.16 Non-EMV Transactions using EMV Functionality..................... 69
5.17 VEPS Transactions................................................................... 70
5.18 Lower Voltage Card Migration .................................................. 70
Chapter 6 Contactless Acceptance.......................................... 71
Visa Public Page 3

6.1 MSD .......................................................................................... 71

6.2 qVSDC ...................................................................................... 72
6.2.1 Fast Dynamic Data Authentication (fDDA) ................... 72
6.3 Global Interoperability ............................................................... 73
6.4 Processing Overview ................................................................ 73
6.4.1 Processing Prior to Enabling the Contactless Interface 74
6.4.2 Discovery Processing ................................................... 75
6.4.3 Application Selection..................................................... 75
6.4.4 Initiate Application Processing...................................... 75
6.4.5 Read Application Data (Conditional)............................. 75
6.4.6 Card Read Complete .................................................... 76
6.4.7 Processing Restrictions (Conditional)........................... 76
6.4.8 Offline Data Authentication (Conditional)...................... 76
6.4.9 Cardholder Verification (Conditional)............................ 76
6.4.10 Online Processing (Conditional) ................................... 76
6.4.11 Completion.................................................................... 77
6.4.12 Issuer Update Processing............................................. 77
6.5 Reader Interface Guidelines ..................................................... 77
6.5.1 Contactless Transaction States .................................... 78
6.5.2 User Interface Recommendations ................................ 78
6.5.3 Visual Indication............................................................ 79
6.5.4 Audio Indication ............................................................ 79
6.5.5 Display Messages......................................................... 79
6.6 VCPS Processing for Industry Specific Transactions............... 80
6.6.1 Pre-Authorizations ........................................................ 80
6.6.2 Sale Completion............................................................ 81
6.6.3 Status Check and Account Number Verification........... 81
6.6.4 Refunds......................................................................... 81
6.6.5 Reversals ...................................................................... 82
6.6.6 Cancellations ................................................................ 82
6.6.7 Referrals........................................................................ 83
6.6.8 VCPS Transactions using Magnetic-Stripe Data.......... 83
6.6.9 Non-VPCS Transactions Using VCPS Functionality .... 83
6.7 Other Processing Considerations for VCPS ............................. 83
6.7.1 Forcing a CVM .............................................................. 83
6.7.2 Premature Card Removal ............................................. 84
6.7.3 Gratuities....................................................................... 84
6.7.4 Placement of Contactless Readers .............................. 84
Visa Public Page 4

6.7.5 VEPS Transactions....................................................... 84
Chapter 7 Security Characteristics .......................................... 86

7.1 Cardholder Verification Methods .............................................. 86
7.2 Signature................................................................................... 87
7.3 Personal Identification Number................................................. 87
7.3.1 PIN Length and Character Set...................................... 87
7.3.2 Online PIN..................................................................... 88
7.3.3 Offline PIN..................................................................... 88
7.3.4 PIN Entry Bypass.......................................................... 89
7.4 Requirements for Cardholder Verification Methods.................. 90
7.5 PIN Entry Devices..................................................................... 90
7.5.1 Keyboard Layout........................................................... 91
7.5.2 Chip-Reading Device Requirements for PEDs ............. 92
7.5.3 PED Testing Requirements .......................................... 92
7.6 Key Management...................................................................... 92
7.6.1 Symmetric Key Management........................................ 93
7.6.2 Asymmetric Key Management...................................... 93
7.6.3 Obtaining VSDC CA Public Keys.................................. 93
7.6.4 Loading VSDC CA Public Keys .................................... 94
7.6.5 Removal of VSDC CA Public Keys............................... 94
7.6.6 Expired VSDC CA Public Keys..................................... 94
7.6.7 Revoked VSDC CA Public Keys................................... 94
7.6.8 Managing VSDC CA Public Keys Distribution .............. 94
7.6.9 Issuer and ICC Keys ..................................................... 95
7.7 Data Security ............................................................................ 96
7.7.1 Cardholder Data Security.............................................. 96
7.7.2 Payment Application Data Security .............................. 96
7.8 Card Verification Value 2 .......................................................... 97
Chapter 8 Device Management Systems................................. 98

8.1 EMV Functions.......................................................................... 98
8.2 Data Elements .......................................................................... 98
8.2.1 VSDC CA Public Keys .................................................. 98
8.2.2 Terminal Action Codes.................................................. 99
8.2.3 Application Identifiers.................................................... 99
8.2.4 Random Transaction Selection Parameters ................. 99
8.2.5 Floor Limits ................................................................. 100
8.2.6 Application Version Number ....................................... 100
Visa Public Page 5

8.3 EMV Functionality Considerations.......................................... 100

8.3.1 Mandatory Functionality for EMV Devices.................. 100
8.4 Contactless Chip Considerations............................................ 101
Chapter 9 Acquirer Considerations ....................................... 102

9.1 Electronic Signature Capture Devices .................................... 102
9.2 PIN Storage ............................................................................ 102
9.3 Deploying EMV-Compliant Devices........................................ 102
Chapter 10 Data Element Considerations ............................. 104

10.1.1 Application PAN Sequence Number........................... 104
10.1.2 IFD Serial Number ...................................................... 104
10.1.3 Issuer Application Data ............................................... 104
10.1.4 Application Cryptogram and Card Authentication....... 105
10.1.5 Issuer Authentication Data.......................................... 105
10.2 Recovery for Offline Transactions .......................................... 105
10.3 Application Performance Consideration ................................. 105
10.4 Acquirer Device Validation Toolkit .......................................... 106
10.4.1 ADVT and EMVCo Approval....................................... 106
10.4.2 ADVT and Expired EMV Approvals ............................ 107
10.4.3 Future ADVT Requirements........................................ 107
10.5 Card Expiration Date Processing............................................ 107
10.6 Fallback Processing................................................................ 107
10.6.1 Acquirer Stand-In Processes ...................................... 108
Chapter 11 Considerations for EMV Approval...................... 110

11.1 EMV Level 1............................................................................ 110
11.2 EMV Level 2............................................................................ 110
11.3 EMVCo Approvals................................................................... 110
11.4 Testing Recommendations ..................................................... 111
11.5 Kernel Modularization ............................................................. 111
Appendix A Track 1 Data Specifications ............................ 112

A.1 Track 1 Content Requirements............................................... 112
A.2 Record Format ........................................................................ 113
A.2.1 Character Set.............................................................. 114
A.3 Encoding Examples ................................................................ 118
A.4 Data Element Descriptions ..................................................... 122
A.4.1 Cardholder Name Usage Examples ........................... 125
Visa Public Page 6

A.4.2 Service Code Usage ................................................... 131
Appendix B Track 2 Data...................................................... 139

B.1 Track 2 Content Requirements............................................... 139
B.1.1 Magnetic Stripe Encoding Requirements ................... 139
B.2 Record Format ........................................................................ 140
B.3 Character Set.......................................................................... 140
B.4 Encoding Examples ................................................................ 143
B.5 Data Element Descriptions ..................................................... 145
B.5.1 Service Code Usage ................................................... 151
Appendix C Global ATM Requirements .............................. 158

C.1 Acquirer Participation Requirements ...................................... 158
C.1.1 Physical Security Requirements ................................. 158
C.1.2 Processing Requirements........................................... 158
C.1.3 Card Verification Value Service .................................. 158
C.1.4 Minimum Cash Disbursement Requirements ............. 159
C.1.5 PIN Support ................................................................ 159
C.1.6 Technology Requirements .......................................... 159
C.1.7 Track 2 ........................................................................ 159
C.1.8 Retrieval Reference Number ...................................... 159
C.1.9 Service Codes............................................................. 160
C.1.10 Expiration Dates.......................................................... 160
C.1.11 Account Numbers ....................................................... 160
C.1.12 Card Acceptance ........................................................ 160
C.1.13 ATM Access Restrictions ............................................ 161
C.1.14 Screen Message Requirements ................................. 161
C.1.15 Acquirer Timeouts....................................................... 161
C.1.16 Support for Dip Readers at ATMs............................... 162
C.1.17 ATM Card Readers and PIN ....................................... 162
C.1.18 Account Selection ....................................................... 162
C.1.19 Transaction Receipt Requirements ............................ 163
C.1.20 EMV Data Requirements ............................................ 164
C.2 Transaction Exceptions........................................................... 165
C.2.1 Reversals .................................................................... 165
C.2.2 Misdispense ................................................................ 165
C.2.3 Card Retention............................................................ 165
C.2.4 Issuer-Requested Card Retention .............................. 166
C.2.5 Erroneous ATM Card Retention ................................. 166
Visa Public Page 7

C.3 Regional Differences............................................................... 166

C.3.1 Participation Requirements......................................... 166
C.3.2 Physical Security Requirements ................................. 166
C.3.3 Processing Requirements........................................... 166
C.3.4 Minimum Cash Disbursement Requirements ............. 166
C.3.5 PIN Support ................................................................ 166
C.3.6 Technology Requirements, Track 2............................ 167
C.3.7 ATM Access Restrictions ............................................ 167
C.3.8 Account Selection ....................................................... 167
C.3.9 Transaction Receipt Requirements ............................ 167
C.3.10 Misdispense ................................................................ 167
Appendix D Device Performance for EMV Transactions... 168

D.1 Device Factors Influencing Transaction Duration................... 168
D.1.1 Cryptographic Factors................................................. 168
D.1.2 Communications Speed to Cards ............................... 169
D.1.3 Application Optimization ............................................. 169
D.2 Process Overlap: Multitasking or Interleaving ........................ 170
D.3 Speed of the Device................................................................ 171
D.4 Card Interaction ...................................................................... 171
D.5 Type of Programming Language Used................................... 171
D.6 Device and Application Architectures ..................................... 171
D.7 Application Development Considerations ............................... 171
D.8 Transaction Receipt Requirements ........................................ 172
D.9 Retail Environment.................................................................. 172
Appendix E EMV Tag to VisaNet Data Element Mapping.. 173

E.1 EMV Tag to VisaNet Data Element Mapping Table ............... 173
Appendix F Placement of Contactless Readers ................ 181

F.1 Compliance With Local Regulatory Requirements ................. 181
F.2 Proximity to RFID and Antitheft Devices................................. 181
F.3 Proximity to Transmitting Devices .......................................... 181
F.4 Susceptibility to Electromagnetic Interference........................ 182
F.5 Contactless Card Readers Mounted on Motor Vehicles......... 182
F.6 Proximity to Metallic Material .................................................. 182
F.7 Proximity of Multiple Readers ................................................. 182
F.8 Proximity to EMV-Compliant Contact Chip Devices ............... 183
Visa Public Page 8

Appendix G Application Selection ...................................... 184

G.1 General Application Selection................................................. 184
G.1.1 Visa Multi-Application Cards ....................................... 184
G.1.2 Routing and Use of Chip Data .................................... 186
G.1.3 POS with Separate Merchant and Customer Displays186
G.1.4 POS with Shared Merchant and Customer Display.... 188
G.1.5 Restricted use of the Cancel key ................................ 188
G.1.6 Display of Application Name(s)................................... 189
G.1.7 Receipts ...................................................................... 189
G.2 Application Selection for POS and UCAT............................... 190
G.2.1 Choosing an Application ............................................. 190
G.2.2 TAD Display ................................................................ 194
G.2.3 Selection on touch screen and FDK devices .............. 196
G.2.4 Displaying a selected application................................ 197
G.3 Exemptions ............................................................................. 199
G.4 DCC Selection Overview ........................................................ 201
Appendix H Reference Materials ......................................... 202
Appendix I Acronyms and Glossary.................................. 204
Visa Public Page 9

List of Tables
Table 3-1: Transaction Scenarios and Device Messages .............................. 27
Table 5-1: Random Transaction Selection Values ......................................... 52
Table 6-1: Summary of Possible Reader and Card interactions .................... 73
Table 6-2: Contactless Transaction States..................................................... 78
Table 6-3: Contactless Display Messages ..................................................... 80
Table A-1: Track 1 Record Format ............................................................... 114
Table A-2: Track 1 Character Set ................................................................ 115
Table A-3: Field 1—Start Sentinel ................................................................ 122
Table A-4: Field 2—Format Code................................................................. 122
Table A-5: Field 3—Primary Account Number (PAN)................................... 122
Table A-6: Field 4—Separator ...................................................................... 123
Table A-7: Field 5—Cardholder Name ...................................................... 123
Table A-8: Field 6—Separator .................................................................... 126
Table A-9: Card Expiration Date................................................................... 126
Table A-10: Field 8—Service Code ............................................................ 127
Table A-11: Service Code Digit Value Descriptions ..................................... 128
Table A-12: Valid Service Codes by Card Product Platform ....................... 131
Table A-13: Field 9—PIN Verification ........................................................... 133
Table A-14: Field 10—Discretionary Data .................................................... 133
Table A-15: Matrix for Discretionary Data Field........................................... 135
Table A-16: Field 11—Visa-Reserved .......................................................... 136
Table A-17: Field 11.1—Card Verification Value (CVV) ............................... 136
Table A-18: Field 11.2—Authorization Control Indicator .............................. 137
Table A-19: ACI Values ................................................................................ 137
Table A-20: Field 12—End Sentinel ............................................................. 138
Table A-21: Field 13—Longitudinal Redundancy Check (LRC) ................... 138
Table B-1: Track 2 Record Format ............................................................... 140
Table B-2: Track 2 Character Set ................................................................ 141
Table B-3: Field 1—Start Sentinel ................................................................ 145
Table B-4: Field 2—Primary Account Number (PAN).................................. 146
Table B-5: Field 3—Separator ..................................................................... 146
Table B-6: Field 4—Card Expiration Date ................................................... 147
Table B-7: Field 5—Service Code ................................................................ 148
Visa Public Page 10

Table B-8: Service Code Digit Value Descriptions ....................................... 149

Table B-9: Valid Service Codes by Card Product Platform ......................... 151
Table B-10: Field 6—PIN Verification .......................................................... 153
Table B-11: Field 7—Discretionary Data ...................................................... 155
Table B-12: Field 8—End Sentinel .............................................................. 156
Table B-13: Field 9—Longitudinal Redundancy Check (LRC) ..................... 157
Table E-1: EMV/VisaNet Data Elements and Tags ...................................... 174
Visa Public Page 11

List of Figures
Figure 5-1: Sample Transaction Flow Diagram .............................................. 57
Figure 6-1: Sample Contactless Transaction Flow Diagram .......................... 74
Figure 7-1: ATM Keyboard Layout.................................................................. 91
Figure 6-2: POS PIN Pad Layout.................................................................... 91
Figure A-1: Letter K Bit Sequence Pattern ................................................... 114
Figure A-2: Example: Encoding With PIN Verification Data Field ................ 118
Figure A-3: Encoding With PIN Verification Data Field ................................ 119
Figure A-4: Encoding With Discretionary Data Field .................................... 120
Figure A-5: Encoding With PIN Verification and Discretionary
Data Fields............................................................................. 121
Figure A-6: Cardholder Name Usage Example 1 ........................................ 125
Figure A-7: Cardholder Name Usage Example 2 ......................................... 125
Figure A-10: Cardholder Name Usage Example 5 ....................................... 125
Figure A-11: Cardholder Name Usage Example 6 ....................................... 126
Figure A-12: PIN Verification Field .............................................................. 135
Figure B-1: Encoding With PIN Verification, Discretionary Data and CVV .. 143
Figure B-2: Encoding With Discretionary Data ............................................. 144
Figure B-3: Encoding With PIN Verification and Discretionary Data ............ 145
Figure B-4 PIN Verification Field ................................................................ 154
Figure B-5: Discretionary Data Field............................................................. 156
Figure G-1: Sample Transaction Flow Diagram ........................................... 185
Figure G-2: Merchant Display, Customer Choosing Application .................. 187
Figure G-3: Merchant Display, Application Chosen...................................... 187
Figure G-5: Cardholder Selection Display .................................................... 187
Figure G-6: Four Options.............................................................................. 188
Figure G-4: Terminal Display Indicating Customer Choice .......................... 188
Figure G-7: Receipt with Application Identified............................................. 189
Figure G-9: Multiple Mutually Supported Applications,
Function Keys Enabled .......................................................... 191
Figure G-10: Allocation of Numbers to Applications..................................... 191
Figure G-11: Application Display Examples ................................................. 192
Visa Public Page 12

Figure G-12: 5 Applications Display Example .............................................. 192

Figure G-13: Column Display ....................................................................... 193
Figure G-14: Multiple Mutually Supported Applications Available,
Affirmation and Correction Keys Enabled.............................. 193
Figure G-15: Multiple Mutually Supported Applications................................ 194
Figure G-16: Legible Layout ......................................................................... 195
Figure G-17: Scroll and Select Layouts ........................................................ 195
Figure G-18: Numeric Scroll and Select Examples ...................................... 196
Figure G-19: Multiple Mutually Supported Applications................................ 197
Figure G-20: 2 Mandatory Prompts .............................................................. 197
Figure G-21: Two Screens with PIN Prompts............................................... 198
Figure G-22: Dynamic Currency Conversion (DCC) Selection Diagram...... 201
Visa Public Page 13

Chapter 1 Overview
The increasingly global nature of the payment card industry is creating new requirements to
ensure the interoperability of cards and devices. Interoperability is the cornerstone of Visa
brand acceptance and a driving force behind Visa’s long-standing commitment to work with
financial institutions, merchants, vendors, and third-party organizations to create the global
infrastructure needed to meet these challenges.
The Transaction Acceptance Device Guide is intended to provide vendors, merchants,

acceptance device deployers, and acquirers or their agents with an overview of the
requirements for devices that accept Visa magnetic stripe, contact chip and contactless
transactions. Transaction acceptance devices can be operated directly by an acquirer or
under the terms of a merchant or acquirer agent agreement.
This document assists vendors in designing devices that meet industry and Visa specific
standards.
1.1 Audience
This guide is intended for:
 Vendors who are developing, integrating or testing transaction acceptance devices to

support acceptance of Visa cards
 Acquirers and merchants creating requirements for transaction acceptance devices
 Acquirers, merchants, and device deployers creating, developing or testing an

infrastructure for acceptance
This document is available to the public on the Visa website (www.visa.com/tadg). With the
publication of this document, the previously published Chip Card Acceptance Device
Reference Guide and Implementing EMV at the ATM documents are obsolete and have
been removed from www.visa.com.
1.2 Scope
The focus throughout this document is on device requirements for vendors, merchants, and
acquirers to help ensure compliance with the Visa requirements for card-present
transactions, along with the best practices for implementation. This document assumes a
basic knowledge of magnetic stripe processing, the EMV™ (a trademark owned by EMCO
LLC) contact chip specifications and the Visa Contactless Payment Specification. The
recommendations for contact chip and contactless processing should be read in
conjunction with the appropriate specifications.
This document refers to requirements that apply in most countries. Specific countries,
however, may have local laws or Visa requirements that apply to their market. Devices
deployed must adhere to all applicable global and local requirements.
Visa Public Page 14

This document contains references to the Visa International Operating Regulations and the
Visa Europe Operating Regulations. It does not, however, replicate all the device
requirements from the Visa International Operating Regulations or the Visa Europe
Operating Regulations nor does it include requirements from other regional operating
regulations.
This document does not address card-not-present transactions, acquirer roles and
responsibilities, acquirer-to-VisaNet messaging (except in a few instances for clarification),
nor device-to-acquirer messaging (which is outside Visa’s scope) nor the use of consumer
devices.
This document applies to devices operating under a merchant agreement, such as point-of-
service (POS) equipment, or under an acquiring contract, such as an automated teller
machine (ATM). Portions of this document may also be useful to developers of issuer-
operated or cardholder-owned devices.
1.3 Compliance Documents and Devices

To facilitate market requirements while ensuring global interoperability, devices accepting
Visa cards must comply with the following documents:
 The Visa Operating Regulations consisting of:
 Visa International Operating Regulations and the applicable regional operating

regulations for countries in Visa Inc. (available at www.visa.com)
 Visa Europe Operating Regulations for countries in Visa Europe
 Payment Technology Standards Manual (see Appendix A for the Visa standards for
tracks 1 and 2 of the magnetic stripe)
 Transaction Acceptance Device Requirements (see Appendix B)
 Global ATM Member Guide (see Appendix C for the device-specific requirements for
ATMs)
NOTE: Additional reference documentation is provided in Appendix H.
Devices accepting Visa EMV-compliant contact chip cards must comply with the EMV
Integrated Circuit Card Specifications for Payment Systems (the EMV specifications), which
are maintained by EMVCo on www.emvco.com.
Devices accepting personal identification numbers (PINs) must comply with the Payment
Card Industry (PCI) PIN Transaction Security (PTS) Point of Interaction (POI) Modular
Security Requirements at https://www.pcisecuritystandards.org/ and the Visa PCI PIN
Security Requirements on www.visa.com/pinsecurity.
Visa Public Page 15

Requirements for devices that accept contactless transactions (Visa payWave) may be
found in the Visa Contactless Payment Specification available by license agreement from
partnernetwork@visa.com. Device vendors servicing the European region should also refer
to the Visa Europe Contactless Terminal Requirements and Implementation Guide which
can be obtained by contacting Visa Europe on contactlessVE@visa.com. Best practices
relating to contactless devices can also be found in the Visa Contactless Payment
Specification – User Interface Guide which can be obtained from Visa representatives.
1.4 VEPS Best Practices

Best practices relating to the Visa Easy Payment Service (VEPS) can be found in the Visa
Easy Payment Service – Acquirer Program Guide which can be obtained from a Visa
representative.
Best practices relating to payment acceptance for retail petroleum merchants can be found
in the Visa Payment Acceptance Best Practices for Retail Petroleum Merchants which can
be obtained from a Visa representative.
Risk management best practices for prepaid programs that will utilize a self-service kiosk
can be found in the Prepaid Product Risk Management Best Practices which can also be
obtained from a Visa representative.
In addition to complying with these documents, markets can customize their programs
beyond these minimum requirements through adoption of the optional functions through
proprietary processing. Proprietary processing, however, must not interfere with global
interoperability.
1.5 Terminology
The following terms are used in this guide:
 Visa Operating Regulations—The operating regulations in the merchant’s or

acquirer’s country. This includes the Visa International Operating Regulations, the Visa
Europe Operating Regulations, regional operating regulations, and any country-specific
operating regulations.
 Acquirer—Includes acquirers and their agents, such as an acquirer processor.
 Card—Any Visa-approved form factor that can be used to initiate a Visa payment
transaction.
 Device—A transaction acceptance device.
 Chip card and chip card device--EMV contact chip cards and devices.
 Contactless card and contactless card device—Contactless chip cards and devices
that comply with the Visa Contactless Payment Specification.
Additional terms and definitions may be found in the Glossary at the end of this guide.
Acronyms and their definitions may also be found in a section at the end of this guide.
Visa Public Page 16

Visa Public Page 17

Chapter 2 Transaction Acceptance Environments

This chapter describes the three types of transaction acceptance devices referred to in this
document: attended POS devices, unattended cardholder activated terminal (UCATs), and
Automated Teller Machines (ATMs). There is also reference to other device reader
peripherals. This chapter also describes various authorization processing methods used in
different markets.
2.1 Attended POS Devices

Attended POS devices can be described in three categories: integrated POS systems,
standalone POS devices, and multilane POS devices. While these devices may support a
variety of functions, the requirements in this document focus only on payment functionality.
2.1.1 Integrated POS Systems

The term integrated POS refers to systems where the component used to process payment
card transactions in card-present retail environments is just one part of a wide array of
functionality. Other functions fall into the general categories of plan, buy, track, and sell and
may include:
 Product code scanning, product lookup, and sales tax calculation
 Inventory management and item tracking
 Customer preference, coupon, and frequent shopping programs
 Security and staff tracking
 Accounting
Integrated POS can be as complicated as a state-of-the-art retail workstation or as simple
as a basic till with an integrated card reader.
2.1.2 Standalone POS Devices

Compared to integrated POS systems, a standalone POS device serves the single purpose
of authorizing and clearing payment card transactions. Other names for standalone devices
include electronic POS devices (although this also refers to integrated systems) or
electronic data capture devices.
A standalone POS device is usually not connected to a merchant’s electronic cash register;
rather, it connects directly to a host processor. For slightly larger merchants, the standalone
device may be added to a cash register as a plug-in or stand beside device.
Visa Public Page 18

2.1.3 Multilane POS Devices

The term multilane is often used to describe the multiple checkout lanes found in large
mass merchandise or grocery stores. A multilane configuration consists of multiple
payment devices tied to one or more controllers. The controller provides messaging
between the store and the host processor for services (for example, authorization,
reporting, or inventory management). Each checkout location generally supports all the
functions required for transacting business, including card acceptance.
The three most common types of multilane configurations are stand-beside or physically
separated systems, semi-integrated or logically integrated systems, and fully integrated or
physically integrated systems.
 In stand-beside or physically separated systems, the card payment function is separate

from in-store operations.
 In the most common semi-integrated configuration, the transaction acceptance device

connects directly to the integrated POS device and runs on a local area network linked
to the payment controller.
 In the fully integrated configuration, the store’s system controls all the components, and
the integrated POS platform physically incorporates the transaction acceptance device.
2.1.4 Shared Display and Separate Display Devices

Attended devices may have a shared display or a separate display which is used for both
the customer and the merchant to carry out the transaction. Which device is used at a
merchant is dependent on the device itself and the merchant environment.
Devices with a shared display only have a single display that is shared by the merchant
and the customer during the transaction process.
Devices with a separate display have a dedicated display for the merchant and one for the
customer. These typically comprise a fixed enclosure for the merchant terminal and a
tethered PIN pad with a dedicated display for the customer.
In general and unless specifically stated all requirements and best practices apply to both
types of devices. There are specific requirements relating to application selection which
vary depending on whether the device has a shared or a separate display. These are
covered in more details in chapter 5.
2.2 Unattended Cardholder Activated Terminals

In this document, the term Unattended Cardholder Activated Terminal (UCAT) refers to an
acceptance device managed by a merchant that dispenses goods or services, at which the
card and cardholder are present, but the functions and services are provided without the
assistance of an attendant to complete the transaction at the device. Cardholder verification
and authorization of such transactions occurs electronically, if required. These devices
include cardholder activated fuel pumps, self-service vending units, and self-service
payment devices in parking garages.
Visa Public Page 19

Devices that support cash dispensing and provide goods and services must comply with
the operating regulations appropriate to the transaction. While dispensing cash, they must
adhere to the ATM operating regulations. While dispensing goods or services, they must
adhere to the operating regulations for unattended purchases. Although unattended
devices may dispense goods and services as well as cash, transactions involving a
purchase with cash back are not allowed. In other words, an unattended device may
dispense either cash or goods and services in a single transaction but not both.
Information on UCATs that dispense scrip is not addressed because the Visa Operating
Regulations prohibit Visa card products from being used for scrip transactions. (Scrip is a
two-part paper receipt redeemable for goods, services, or cash.)
Attended cardholder activated terminals such as self-checkout terminals in supermarkets

are not considered UCATs and therefore are not required to meet UCAT requirements.
2.3 Automated Teller Machines

Automated Teller Machines (ATMs), also known as Automated Banking Machines (ABMs)
or cash machines, are unattended devices that dispense cash and accept online PINs.
These devices may be simple, limited-capability cash dispensers or advanced-function
ATMs with color screen graphics, sophisticated applications, and a range of business
functions. ATMs may support additional financial-related functions, such as balance
inquiries, account transfers, and prepaid card. In certain countries they may also provide
customer PIN change facilities.
2.4 Self-Service Card Dispensing Kiosks

Self-service card dispensing kiosks allow consumers the convenience to purchase and/or
reload a Visa prepaid card. Cards dispensed via kiosks are restricted to limited use, non-
personalized cards; for example, gift cards or temporary general purpose cards. Other
functions of a kiosk could include the ability to check a card balance or pay bills. The
purchase of Visa cards at a kiosk may be completed with various forms of tender: cash,
credit or debit cards. Visa prepaid cards sold at a kiosk will be expected to meet all existing
Visa requirements including the following:
 Visa Operating Regulations including but not limited to Agent Registration, Risk
Management, General Card Acceptance, and Unattended Acceptance Terminal
requirements
 Visa Prepaid Products Program Guidelines
 PCI PIN Security Requirements*
 PCI POS PIN Entry Device Security Requirements*
 PCI Encrypting PIN Pad (PED) Security Requirements*
 Visa Global Physical Security Validation Requirements for Data Preparation,

Encryption Support and Fulfillment Card Vendors
Visa Public Page 20

 Payment Card Industry Data Security Standards (PCI DSS) including the Payment
Application Data Security Standard (PA – DSS)
*Required for PIN accepting kiosks – for more information go to www.visa.com/pin.
All kiosk implementations must be supported by a comprehensive maintenance plan for

upkeep of the devices. The plan must include, at a minimum, the following:
 Inventory management and restocking of the machine to ensure adequate stock
 Troubleshooting of the device if not operating properly; i.e., machine is out of order, not
dispensing cards, not taking bills or payment, not issuing a receipt, etc.
 Available contact information for consumer inquiries
 Retailer training for consumer inquiries

Additional risk management best practices for prepaid programs that will utilize a self-
service kiosk can be found in the Prepaid Product Risk Management Best Practices.
2.5 Card Readers

Card readers are available in a number of form factors. A reader may support multiple
technologies (for example, magnetic stripe and contactless), may be dedicated to one
technology, and may extend an existing reader to support a new acceptance technology.
The basic configurations are:
 Fully integrated reader—Delivered by vendors as part of a POS system
 Fully integrated reader module—Module plugged into an existing reader to extend

functionality (often to support new technology)
 Peripheral reader —Plugs into POS system; usually contains all functionality needed
to support an acceptance technology
In some cases, reader functionality may be integrated into the PIN pad.
2.5.1 Contactless Readers

There are specific requirements for contactless readers. More details are provided in
Chapter 6. There are two scenarios in which a reader is typically used for a contactless
transaction:
 As a reader (also called a dongle or Proximity Coupling Device (PCD)) separated from,
but communicating with, a POS device.
 As a reader integrated into a POS device.

The term contactless reader covers both scenarios unless explicitly stated otherwise. It is
not intended to imply in which physical component (the reader or the POS device) a
specific action is performed.
Visa Public Page 21

2.6 Processing Options and Host or Device Capture

Transactions may be processed using batch clearing or real-time processing. The method
used is dependent on the acceptance environment, the acquirer capabilities and local
requirements. The transaction data may be captured either at the device or at the acquirer
host.
NOTE: Visa documentation often refers to batch clearing and real-time processing as VIP
Authorization and VIP Full Service, respectively.
Batch clearing (sometimes referred to as batch processing) involves the exchange of data
twice and is often referred to a dual message processing. In dual-message processing, the
authorization occurs at the time of the purchase or cash disbursement transaction using
one message, and the transaction is cleared later using another message. These clearing
messages are usually gathered into a batch for POS devices. The batch is then sent to the
acquirer as part of end-of-day (or end-of-cycle) processing. Non-batched systems may
simply submit a series of clearing advices based on their transaction logs prior to end of
day (or end of cycle). Device-capture and acquirer host-capture systems typically use dual-
message processing.
Real-time processing involves all transaction data flowing online. Where the final amount is
known at the time of authorization, the same online message also provides the issuer with
all the information required to clear the transaction and post it to the cardholder’s account.
Real time processing is often referred to as single message processing.
Real time processing merchants, particularly those in travel and entertainment segments,
may use an authorization message (0100) followed by a sales completion (0220 or 0320)
rather than a full financial message (0200). In these cases, the considerations are very
similar to dual-message merchants.
Environments such as fuel retailing, where the final amount is generally not known at the
time of authorization, typically use batch clearing. Those that choose to use real-time
processing will undertake a status check (for a single unit of currency) followed by a
clearing message when the full amount is known. Unlike batch clearing, this clearing
message can be sent as soon as the full amount is known.
With device-capture systems, the device combines the authorization response with the data
from the authorization request to create the clearing message. In an acquirer host-capture
system, the host retains a copy of the authorization coming from the device before sending
the request for authorization and uses the data along with the authorization response to
create the clearing message. A device attached to a host-capture system may have a
shadow (copy) of the clearing batch, but the shadow is only for informational or error
recovery purposes.
For devices using host capture, all transactions appear to be single message because the
acquirer is responsible for generating the clearing message.
Although single-message systems typically use full financial messages, they may also use
an authorization followed by a clearing advice.
Visa Public Page 22

Merchants in the United States also have the option of using Visa’s Real Time Clearing
(RTC) service which facilitates transactions through the use of pre-authorizations followed
by a sales completion to complete the transaction. Further details regarding RTC can be
obtained from Visa U.S.A. representatives.
For chip transactions that are authorized offline or magnetic stripe transactions that are
under the floor limit, only a clearing message—whether single- or dual-message, device- or
host-capture—is transmitted.
2.7 Acquirer Stand-In

Transactions above the Visa floor limit or chip transactions where the chip card requests an
online authorization (by returning an ARQC), are normally sent online to the issuer for
authorization. In some markets, however, acquirers may choose to stand in for
authorizations in their host system or in the device. The device displays an appropriate
message to indicate that the transaction is being completed and that the goods or services
are being provided to the cardholder.
Acquirer stand-in (also called authorization truncation) may be done because the acquirer
or the device temporarily does not have a connection (communications failure) or the
amount is over the floor-limit and the device has no online capability. The acquirer is liable
for these transactions in the event that they are charged back for no authorization. Deferred
Authorization is a preferred approach to these situations.
Section 5.12.2, Acquirer Stand-In, provides further details regarding acquirer stand-in in a
chip environment.
2.8 Deferred Authorization

Deferred authorization occurs when an online authorization is performed after the card is
no longer available. The time delay may be brief, such as for a temporary communications
failure or where the merchant simply wishes to speed processing. The time delay may be
extended, as when a ferry is out of range of shore, for in-flight sales, or when the device
does not have online capability (for example, unattended kiosks where the transactions are
offloaded nightly to a server and submitted in batches). Merchants performing deferred
should complete authorizations within 24 hours of the transaction.
This type of transaction may be referred to as store and forward, but that term has a
specific and unrelated meaning in the Visa Operating Regulations. The term deferred
authorization, therefore, is used in this document to describe this type of transaction.
NOTE: The requirements relating to processing deferred authorizations originating from

contact chip cards differs to that of magnetic stripe. Section 5.12.4 Deferred Authorization
outlines the requirements relating to contact chip cards.
Visa Public Page 23

2.9 Partial Authorization

Partial Authorizations occur when the issuer returns an authorization approval for an
amount which is less than the transaction amount requested by the merchant. This may
happen if the cardholder balance is not sufficient to allow the transaction for the full
amount. Partial authorizations are useful for retail petroleum merchants (i.e. service or
petrol stations) which dispense goods via automated fuel pumps.
Where devices support partial authorizations the device must be able to reset the amount
of the purchase to the amount approved by the issuer.
The device or acquirer must submit the authorized amount from the partial authorization
response as the Authorized Amount in the clearing transaction. The actual amount for the
goods or services dispensed after receiving the partial authorization is submitted as the
settlement amount in the Source Amount field in the clearing transaction.
If the approved amount is not fully dispensed as goods or services, an authorization

reversal must be issued for the remaining amount. Alternatively if the transaction is cleared
for an amount that is greater than the authorized amount in the partial authorization, the
issuer has a right to chargeback for the amount exceeding the partial authorization amount.
Visa Public Page 24

Chapter 3 General Acceptance

This chapter provides an overview of the general transaction acceptance device
requirements and best practices that apply to both magnetic stripe, contact chip and
contactless devices.
3.1 Primary Account Number Recognition and Processing

A device accepting Visa and Visa Electron cards must accept all 16-digit primary account
numbers (PANs) that contain a valid Visa-assigned bank identification number (BIN). An
ATM accepting Plus cards must accept PANs up to 19 digits that contain a valid BIN
registered with the Visa Plus program. The full PAN must be transmitted to the acquirer.
While the great majority of 16-digit Visa cards will pass modulus-10 checking, acquirers
and merchants should be aware that some valid 19-digit debit cards may not pass
modulus-10 checking. It is recommended that modulus-10 checking not be performed,
particularly if both debit and credit are accepted.
In some countries, merchants may have installed account-number-verifying POS devices to

aid in detecting counterfeit cards. These devices read the PAN from the magnetic stripe
and compare the last four digits of the PAN to the key-entered last four digits of the
embossed or printed PAN. This is not recommended for devices that accept contact or
contactless chip transactions because chip cards may support multiple payment
applications (each with a unique PAN), of which only one PAN may appear on the front of
the card.
3.2 Expiration Date

Because Visa does not impose a global upper limit for expiration dates on Visa cards, POS
devices should not validate expiration dates for non-expired cards.
ATMs must not return or decline a transaction based on the expiration date. They must
accept the transaction even if the card has expired and route the transaction online for
issuer authorization.
Device vendors and deployers should ensure devices are tested with a wide variety of
dates prior to production rollout.
3.3 Account Selection

Certain countries have defined rules for the selection of an account at the POS via the use
of soft keys or dedicated keys. The rules associated with the routing of these transactions
and their use is defined according to local regulations and is not mandated by Visa.
Account selection allows cardholders to select one of multiple sources of funds associated
with the card or selected payment application at the time of the transaction.
If the merchant or acquirer offers account selection, Visa recommends that it offer a full
range of options:
Visa Public Page 25

 Checking or current account
 Savings account
 Credit line account

Account selection at the POS or ATM is likely to be used only where multiple accounts are
connected with a single credit or debit PAN. Account selection at the ATM may also extend
to lines of credit associated with a Plus-only application. Visa does not require that account
selection be supported.
It should be noted that account selection as described in this section is different to the EMV
Application Selection process which is covered in more detail in Chapter 5.
3.4 Multiple Languages

Depending on the geographic location, devices may need to communicate in multiple
languages to help merchants improve customer service and profitability. Support for
multiple languages and characters on the device’s display for PIN entry or cardholder
application selection is recommended for all devices.
3.5 Device Messages

Device messages are displayed to let the merchant or cardholder know the status of a
transaction and what action, if any, to take next. To ensure clear and effective transaction
messages, vendors should follow a few basic principles. These principles help guide
networks and vendors to maintain clarity in their device messages through both language
translation and message-length constraints.
Basic principles related to device messages include:
 The message displayed must clearly instruct the merchant or cardholder on what action
to take.
 Where the message is based on an issuer response, the message should clearly
communicate the meaning of the response.
 The transaction currency as well as the amount should be displayed to the customer
prior to PIN entry (if applicable). The cardholder should be prompted to confirm the
transaction currency and amount; PIN entry is an acceptable method of confirmation. If
PIN entry is requested before the transaction amount is known for throughput reasons,
an explicit amount confirmation message should be displayed to the cardholder once
the amount is known.
 The message displayed must clearly indicate the status of the transaction. Transaction
status is defined by one of five basic conditions or events:
 The transaction is approved

 The transaction is declined
 The transaction is referred
Visa Public Page 26

 The requested service is not available

 The transaction experienced an error
Once the status of the transaction is determined, the device must be able to communicate
the next action. Clear instructions are especially important when an error occurs and the
transaction is terminated. Error messages for chip transactions should be closely aligned
with messages for magnetic stripe transactions. Messages for magnetic stripe transactions
should be upgraded if they do not already meet these principles.
Table 3-1 contains a list of transaction scenarios and recommendations as to how

messages should be displayed. Some scenarios apply only to contact chip or magnetic
stripe transactions, while others apply to both. Suitable national terminology should be used
to ensure that cardholders and merchants are not confused. A literal translation of the
messages noted below may lead to messages not being clear to the cardholder.
Table 3-1: Transaction Scenarios and Device Messages (1 of 2)

Scenario Visa Recommended Message
Device prompts for merchant or cardholder to ENTER AMOUNT
enter amount
Device prompts for cardholder to enter PIN ENTER PIN
Device prompts for cardholder to enter PIN or ENTER PIN OR PRESS ENTER TO BYPASS
bypass PIN entry (terminal supports PIN
bypass)
Incorrect PIN entered INCORRECT PIN, RE-ENTER PIN
PIN try limit exceeded during current INCORRECT PIN
transaction
(Transaction proceeds to conclusion)
Inoperable PIN pad ERROR; PIN PAD INOPERATIVE
Modulus-10 check fails for key-entered ENTER AGAIN
transaction*
Merchant or cardholder removes card before CARD REMOVED TOO SOON; TRY AGAIN
the transaction is completed
Transaction is declined DECLINED
Transaction is approved APPROVED
Transaction is referred CALL BANK FOR AUTHORIZATION
Device temporarily unable to go online (and UNABLE TO AUTHORIZE. PLEASE TRY
offline chip approval not supported) LATER/CONTACT YOUR CALL CENTER
Device temporarily unable to go online (and UNABLE TO AUTHORIZE. PLEASE TRY
offline chip approval not supported) LATER/CONTACT YOUR CALL CENTER
Network unavailable to authorize a transaction UNABLE TO AUTHORIZE; TRY AGAIN
above the floor limit (for example, if issuer is
unavailable and Visa stand-in processing is not
available)
*Should not be performed for 19 digit cards.
Visa Public Page 27

Table 3-1: Transaction Scenarios and Device Messages (1 of 2)

Scenario Visa Recommended Message
Requested function allowed by the acquirer but SERVICE NOT SUPPORTED
not supported by the issuer (for example,
balance inquiry)
Chip read problem at a device that supports CHIP ERROR, USE MAG STRIPE
fallback
Chip read problem at a device that does not CHIP ERROR; CARD TYPE NOT
support fallback SUPPORTED
EMV chip card inserted into non-EMV chip UNABLE TO PROCESS; USE MAG STRIPE
device (such as a domestic purse application
reader)
Non-EMV chip card inserted into EMV chip USE MAG STRIPE
device
Device with chip functionality not activated and CHIP ERROR; USE MAG STRIPE
with separate readers for chip and magnetic
stripe
Device not able to accept chip card because of CARD TYPE NOT SUPPORTED, USE MAG
no match on the Application Identifier STRIPE
Device supports cardholder application TRY AGAIN

selection but transaction cannot be performed
(Application should be removed from selection
with selected application
process before new list presented to
cardholder)
Device prompts for cardholder application SELECT APPLICATION TO BE USED, or
selection or cardholder confirmation
USE xxxxxxxx? YES/NO?
(where xxxxxxxx is the Application Label or
Application Preferred Name)
Device does not support cardholder CARD TYPE NOT SUPPORTED
confirmation but all mutually supported chip
applications require cardholder confirmation
NOTE: These recommendations assume a small display. Developers for devices with
larger displays should take advantage of the ability to provide more information, using
these recommendations as a guide.
There are also specific requirements relating to the user interface of devices for use with
multi-application chip cards. These are outlined in more detail in Chapter 5 and are in
addition to the messages noted in Table 3-1.
Certain Visa regions also have specific requirements relating to what is displayed to the
cardholder for a contactless transaction and specific requirements for terminal displays.
Given the faster nature of a contactless transaction other forms of messaging such as LED
indicators and sound queues are used.
Visa Public Page 28

For further information regarding the messaging and best practices relating to the user
interface for devices accepting contactless transactions, refer to the Visa Contactless
Payment Specification – User Interface Guidelines or refer to local Visa contacts for
specific regional requirements.
3.6 Transaction Receipts

A merchant must provide a cardholder with a handwritten or printed receipt at the
completion of the transaction, except for certain transactions such as contactless
transactions and small ticket transactions. Upon cardholder request merchants are required
to provide receipts for contactless transactions and small ticket transactions that qualify
under the Visa Easy Payment Service (VEPS) program.
The Visa Operating Regulations specify receipt requirements, including those for manual
receipts, electronic receipts, travel and entertainment, dynamic currency conversion, and
aggregated transactions. There are also specific requirements relating to transactions that
qualify under VEPS. In the instance where a multi-application card has been used, the
application used must also be identified in the receipt by printing the application preferred
name if available and if not then the application label.
Although most authorizations occur electronically, occasionally merchants need to

authorize transactions over the telephone as a result of issuer referrals, network problems,
or system outages. Devices that print cardholder transaction receipts should also provide
the capability to enter an authorization code (for example, via a keypad). These devices
should also include the authorization code in the electronic transaction capture file for later
batch clearing.
3.7 Consumer Data on Receipts and Displays

The Visa Operating Regulations require that at least four digits of the PAN on the
cardholder transaction receipt must be disguised or suppressed. It is strongly
recommended that all but the last four positions of the PAN on the cardholder transaction
receipt be suppressed on receipts or displays.
NOTE: The Payment Card Industry Data Security Standard (PCI DSS) requirement 3.3
states Mask PAN when displayed (the first six and last four digits are the maximum
number of digits to be displayed).
Certain countries, such as the United States, may also have legal restrictions on PAN and
expiration date printing on cardholder transaction receipts and displays. For U.S.A. based
merchants, POS devices must not print either the PAN (except for the last four digits) or the
expiration date on the cardholder transaction receipt.
3.8 Transaction Cancellation

Devices should enable a cardholder or merchant to cancel a transaction in progress at any
time. The device generates a receipt for a canceled transaction when required by local law.
Visa Public Page 29

3.9 Card Data in Online Message

The device must always transmit the full, unmodified contents of the magnetic stripe data or
the Track 2 Equivalent Data in the contact or contactless chip to the acquirer. The device
should not construct the data in the magnetic stripe field in the online authorization
message based on the individual data elements in the magnetic stripe or chip. The device
should also ensure that if a transaction is processed as magnetic stripe, the track data used
in the transaction is read from the magnetic stripe and correspondingly, if a transaction is
processed as chip, the track data used should be read from the chip.
Track 2 is the preferred data to be used for magnetic-stripe transactions, and may be
required in some countries. Track 2 should also be used for chip transactions.
Because the data on the chip may differ from the data on the magnetic stripe, the POS
Entry Mode Code field (V.I.P. Field 22) in the online authorization message that indicates
the source of the track data (magnetic stripe or chip) must be accurate to avoid
unnecessary declines.
3.10 Cash Back Identification and Processing

Where the Visa Operating Regulations and local laws in a country allow cash back with a
purchase (in certain countries the term cash back or cash-back is used), the cash back
amount must be uniquely identified in the authorization and clearing messages from the
total transaction amount. The authorization message contains the total transaction amount
(purchase plus cash back) in Amount, Transaction (V.I.P. Field 4) and the cash back
amount in Other Amounts (V.I.P. Field 61.1). All cash back transactions require an online
authorization (zero floor limit).
Devices supporting cash back must be configured to meet all of Visa’s cash back
requirements including in some instances local requirements.
Devices must be able to:
 Enable cash back functionality, i.e. switch on cash back flag for EMV kernel.
 Capture cash back amount and populate it in the authorization message

The device must be able to give the merchant the capability to key in purchase and cash
back amounts separately (The authorization amount is for the total amount – purchase plus
cash back). An end-of-day batch from terminals must identify cash back amounts so
merchants can reconcile with their cash drawers.
Devices must be able to handle special conditions relating to cash back such as:
 A response that the cash back service is not available to the cardholder.
 A response that the cash back amount is more than the maximum cash back amount
agreed for the country. (In this case, the merchant could retry the transaction for a
smaller cash back amount, or for the purchase amount only.)
 A response that the cash back amount is equal to the total transaction amount. (This is
not allowed)
Visa Public Page 30

Certain special conditions will require different actions by the merchant. Merchants may
need to work with their acquirers to determine appropriate point of sale procedures.
There are specific requirements relating to how a chip transaction which includes a cash
back component is processed. Further details are included in Chapter 5.
3.11 Transaction Speed

Rapid authorization enhances the cardholder experience while providing reduced
transaction and queue times for the merchant. Online authorizations can be optimized
through implementation of fast communication technologies (such as always-on or
broadband). The benefits of customer satisfaction and higher throughput can offset
additional communication costs in many cases. See Appendix D, Device Performance for
EMV Transactions.
Speed requirements for contactless transactions are more stringent due to the convenience
and speed factor associated with them. The Visa requirement is for the transaction time not
to exceed 500 milliseconds based upon the interaction between the card and the reader,
beginning at the first card response during Discovery Processing and concluding at Card
Read Complete. This excludes any additional time required for an online authorization or
processing for offline data authentication. See Chapter 6 for further information regarding
contactless requirements.
3.12 Unattended Cardholder Activated Transactions

Unattended Cardholder Activated Terminals or UCATs must be able to read the card data
electronically and provide a transaction receipt. A UCAT must inform the cardholder that a
receipt is available upon request if it is not provided automatically.
The Visa Operating Regulations define a transaction performed at a UCAT as falling into
one of three categories:
 Under-floor with no CVM: Where transactions are below the floor limit, the transaction
is not authorized, and cardholder verification is not performed. Transactions using
these devices must not be performed for magnetic stripe transactions initiated from
either Visa or Visa Electron cards with a Service Code containing a 2 in the second
position, indicating that online authorization is required. This type of transaction is
allowed only in some countries and only for a very limited number of merchant
categories.
 Authorized with no PIN: Where the transactions are authorized, and cardholder
verification is not performed.
 Authorized with PIN: Where the transactions are authorized, and PIN entry is
performed.
A UCAT may support all three categories provided that the device adheres to the
Cardholder Verification Method (CVM) requirements appropriate to each transaction type.
For more information, refer to the operating regulations for the location of the merchant.
Visa Public Page 31

3.13 Automated Teller Machines

All ATM transactions must be transmitted electronically to the issuer. Transactions must not
be approved offline but may be declined offline based on processing restrictions from a
contact chip card.
ATMs should be able to display messages in multiple languages. The messages should be
able to indicate the type of currency dispensed.
An ATM cash disbursement must be processed as a Visa transaction when either a Visa or
Visa Electron card is used or as a Plus transaction when either a Plus, Visa, or Visa
Electron card is used at a Plus-only ATM.
A transaction must be canceled if network problems or system outages occur.
If an authorization request has been sent and cash was not disbursed, a reversal must be
sent.
Appendix C, Global ATM Requirements, contains additional ATM requirements extracted

from the Global ATM Member Guide.
3.14 Readers
A reader that supports multiple interfaces, such as contact chip and contactless, should
ensure that the operation of one interface does not interfere with the operation of another.
In particular, when processing via the contact chip interface, the radio frequency (RF) field
of the contactless interface should be powered down prior to initiating the contact chip
transaction. Simply disabling the logical function but leaving the field active may interfere
with proper functioning of dual-interface cards.
NOTE: There are different criteria for Visa payWave merchants depending on whether the
merchant is a U.S.A. or non-U.S.A. merchant. Check with a Visa representative for
further details.
3.15 Visa Easy Payment Service

Visa Easy Payment Service (VEPS) is the new global name for the No Signature Required
(NSR) program and Small Ticket Transaction program as defined outside the United
States.
VEPS streamlines the merchant acceptance procedures by removing certain requirements

such as the need for cardholder verification and generation of receipts unless requested by
the cardholder.
VEPS is targeted at low value transactions under certain limits. These limits vary in
different countries and regions. It is important for device vendors to check with their local
Visa representative on specific requirements and qualifying criteria that may apply. To
qualify for VEPS a merchant must be a Visa payWave merchant or in one of the eligible
Merchant Category Codes (MCCs).
Visa Public Page 32

Further details on how VEPS affects magnetic stripe, contact and contactless chip
acceptance are provided in the following chapters. For further information regarding VEPS
refer to the Visa Easy Payment Service – Acquirer Program Guide or contact a Visa
representative.
Visa Public Page 33

Chapter 4 Magnetic Stripe Acceptance

This chapter provides an overview of the requirements for a transaction acceptance device
that accepts magnetic stripe cards.
4.1 Card Acceptance Methods

A device accepts a magnetic stripe card through one of the following methods:
 Swipe or slide
 Swipe and park
 Dip
 Insert (for motorized readers)

NOTE: A motorized reader with card retention capability may be needed to support
requirements to capture cards
The cardholder or merchant may be required to interact with the device before it can accept
the card. For example, the cardholder may be required to press a function key to select the
application or the card type.
When a card is presented at a magnetic-stripe-only device, the device should always

attempt to read the magnetic stripe. If the magnetic stripe cannot be read, key entry
procedures may be used at the point of service unless disallowed under the Visa Operating
Regulations or prohibited by local law.
4.2 Magnetic Stripe Data Processing

A device that accepts magnetic stripe transactions must:
 Read a magnetic stripe that conforms to Appendix A, Tracks 1 and 2 Data

Specifications
 Not erase or alter any magnetic encoding on a card
 Transmit all data encoded on either track 1 or 2 of the magnetic stripe to the acquirer
 Be able to distinguish the magnetic stripe containing Visa payment data from other
proprietary magnetic stripe data on a card (for devices with multiple reader heads)
4.3 Service Codes

The Service Code on the magnetic stripe indicates the circumstances under which the card
can be accepted (for example, international transactions, domestic-only transactions, ATM-
only transactions). The code also defines requirements for processing a transaction with
the card (for example, chip enabled, PIN required, or always authorize).
Visa Public Page 34

A device with online capability must either read and act upon the Service Code value on a
card’s magnetic stripe or send the transaction online to the issuer for authorization. Offline-
only devices must both read and act upon the Service Code value.
When reading a card via the magnetic stripe reader, contact chip capable devices must
examine the Service Code on the magnetic stripe to determine if the card is chip enabled
(2xx or 6xx). If the Service Code indicates that the card is chip enabled, the device must
prompt the cardholder or merchant to insert the card into the contact chip reader, unless
operating under fallback conditions.
Service Codes 5xx and 6xx indicate that the magnetic stripe is restricted to domestic use
only. The device, however, does not necessarily know in which country the card was issued
and is not required to do so.
For transactions processed using data read from the magnetic stripe, Service Codes
requiring online authorization (x2x) must be respected regardless of floor limit. Offline-only
devices, or a device that is temporarily unable to send a transaction online, cannot
authorize the transaction when the card’s magnetic stripe is encoded with an x2x Service
Code. A merchant could however complete the transaction by obtaining a voice
authorization.
A device that supports a PIN pad should use the Service Codes relating to PIN entry (xx0
and xx6) to determine if a PIN should be requested prior to initiating the online
authorization. If an x06 (PIN if PIN pad present) or x20 (PIN required) Service Code is read,
the device should request PIN entry and transmit the transaction online. If the device is
unable to process the transaction online, it should process the transaction as normal for an
x06 Service Code or reject the transaction for an x20 Service Code.
NOTE: When discussing Service Codes, references to PIN mean online PIN. An offline-
PIN-only PIN pad (which is to be used for contact chip transactions) is considered PIN
pad not present when evaluating the applicability of Service Codes. Also, if the
acceptance device does not support PIN for Visa and Visa Electron, even if PIN is
supported for other acceptance marks, the PIN pad is considered not present.
POS devices processing transactions for amounts under the floor limit should ensure that
the Service Code is not xx3, ATM only.
If the device does not recognize the Service Code, the transaction must be submitted for
online authorization if the device has online capability. Offline-only devices or a device that
temporarily cannot authorize a transaction should reject a transaction when the device
does not recognize the Service Code or the merchant may be liable for certain
chargebacks.
Magnetic-stripe transactions submitted into clearing without online authorization are subject
to chargeback for Service Code violation if the Service Code was ignored.
For a description of the Service Code and the valid values for Visa cards, see Appendix A,
Tracks 1 and 2 Data Specifications.
Visa Public Page 35

4.4 VEPS Requirements

VEPS transactions that are completed with a magnetic stripe card must be authorized
online and contain a valid authorization code. The data transmitted in the authorization
message must be full and unaltered with a POS Entry Mode of 90.
Visa Public Page 36

Chapter 5 Contact Chip Acceptance

This chapter provides an overview of the requirements and recommendations for an EMV
compliant contact chip transaction acceptance device that accepts Visa contact chip cards.
This chapter describes the processing steps for simple retail transactions and cash
disbursements for EMV contact chip transactions. It also contains Visa recommendations
for industry-specific transaction types.
5.1 Contact Chip Card Processing

To complete a contact chip transaction, a contact chip card and contact chip device engage
in a series of processing steps:
1. Card insertion
2. Application selection
3. Initiate application processing
4. Read application data
5. Processing restrictions
6. Offline data authentication
7. Cardholder verification
8. Terminal risk management
9. Terminal action analysis
10. Online processing
11. Completion
12. Transaction conclusion
All steps except the last one are documented in the EMV and VIS specifications. To fully
understand each of the steps, this chapter should be read in conjunction with these
specifications.
5.2 Card Insertion

A contact chip device must be able to accept a chip card through one of the following
methods:
 Dip (and leave in)
 Insertion (for motorized readers)
 Swipe and park
Visa Public Page 37

NOTE: Swipe and park consists of a magnetic-stripe swipe reader that guides the card
into a chip-reading station at the end of the swipe. Generally, there is a mechanism to
hold the card stable in the chip-reading station.
The cardholder or merchant may be required to interact with the device before it can accept
the card. For example, the cardholder may be required to press a function key to select the
application or the account type. The device must then be able to establish contact by
activating the chip and reading the available applications.
Sections 5.2.1 through 5.2.6 discuss service code and fallback processing, merchant
override of chip reading, support for 19-digit PANs, device messages, and historical bytes
in the answer to reset.
5.2.1 Chip Read

When a card is presented, the device should always check for the presence of a contact
chip. This may be done by reading the chip directly or by reading the Service Code on the
magnetic stripe to determine if the card is contact chip enabled (2xx or 6xx). If the Service
Code indicates the card is contact chip enabled, the device must proceed to read the chip
or prompt the cardholder or merchant to insert the card into the chip reader. The device
must not perform any further magnetic stripe processing unless the chip or chip reader are
inoperative or the transaction is a non-EMV transaction. (For example, in some markets,
refunds may not be implemented using EMV functionality.)
Devices must not at any stage cross check data in the chip against the magnetic stripe.
There may be instances where specific data elements stored in both may actually differ due
to personalization differences or other reasons. Alternatively there may be a secondary
application in the chip which will not match with the magnetic stripe.
An acquirer or merchant may install a contact chip device before the acquirer or merchant
is capable or ready to accept chip transactions. Country or regional rules may require that
all new devices be capable of reading contact chip cards, including processing support by
both the merchant and acquirer. In such situations, the chip functionality, including the
requirement to examine and act upon the 2xx or 6xx Service Codes, must not be activated
until the acquirer and merchant are ready to accept chip transactions.
Before performing any other processing of the magnetic stripe data, the device must either
process the transaction using the chip data or check the Service Code to determine if a
chip is present and use the chip data accordingly. This is particularly important for devices
such as ATMs, which may read both the magnetic stripe and the chip data when the card is
inserted.
Devices with readers that support more than one interface, such as mechanized readers
that support both contact chip and magnetic stripe, must ensure that only data appropriate
to the transaction is used. For contact chip transactions, all data elements used must be
read from the chip. Data from one interface may not match equivalent data from another
interface and should not be compared. For example, the PAN read from the chip may be
different from the PAN on the magnetic stripe.
Visa Public Page 38

Some chip cards are intended for processing only via the chip and may not have fully
functional magnetic stripes (a magnetic stripe may be needed for some types of motorized
readers to operate properly). These magnetic stripes may be encoded with nonfunctional
information, such as a PAN with all zeroes, but contain a valid Service Code (2xx or 6xx)
and expiration date (see Section 5.3.1, Application Identifiers).
It should be noted that there is no requirement for devices to check the Service Code
contained in the chip (either in Tag 5F30 or Tag 57) as part of the EMV processing.
5.2.2 Fallback Acceptance for Chip Read Failures

Contact chip devices must contain logic that allows the transaction to be completed by
reading the magnetic stripe when the transaction cannot be completed by reading the chip
(the chip or chip reader is inoperable). This function is called fallback. It must be supported
unless fallback is disallowed by the Visa Operating Regulations or prohibited by local law.
Device vendors should contact their local Visa representative for further information
regarding local or regional rules governing fallback.
In countries that do not allow fallback, the transaction is terminated if the Service Code is
2xx or 6xx and the chip read was not successful. If the Service Code is 1xx or 5xx and the
chip read was not successful, this is not considered a fallback transaction and can be
completed even if fallback is not allowed in that country. This could occur if the chip does
not support a Visa payment application. For example, the chip may contain only a loyalty or
health care application.
Devices should attempt to retry reading the chip three times prior to falling back to reading
the magnetic stripe. If feasible, devices with motorized readers should attempt to restage
the card in the chip-reading station or retract and re-land the chip contacts to complete the
transaction.
Fallback transactions are processed as described in Chapter 4, Magnetic Stripe

Acceptance, for magnetic stripe transactions, with the exception that all fallback
transactions must be authorized online. Fallback transactions must also contain the correct
VisaNet data elements, indicating a magnetic stripe read transaction using a chip card at a
chip terminal, so issuers are able to correctly identify them and process accordingly.
Further details regarding the required data elements can be found in Chapter 9.
If the magnetic stripe cannot be read, key entry procedures may be used at the point of
service unless disallowed under Visa Operating Regulations or prohibited by local law.
These transactions must also be authorized online. Key entry should only be used as a
measure of last resort and only if fallback to magnetic stripe is not possible.
Because performing a fallback transaction circumvents the improved security offered by

chip, issuers may choose to decline these transactions based on their individual risk
policies.
5.2.3 Merchant Override of Chip Read

Contact chip devices that accept Visa chip cards must not allow the cardholder or merchant
to override the requirement for a chip read by manually prompting the device to read data
from the card’s magnetic stripe. Data from the magnetic stripe must be used only to
perform the transaction if the chip or chip reader is inoperable.
Visa Public Page 39

5.2.4 Support for 19-Digit PANs

Both Visa Operating Regulations and the EMV specifications require that all contact chip
devices that accept Visa and Visa Electron cards must support variable-length PANs up to
and including 19 digits. The device is not required to transmit the 19 digit PAN to the
acquirer and the acquirer is not required to transmit the 19-digit PAN to VisaNet, unless
explicitly mandated, such as for Plus transactions. If the acquirer does not support 19-digit
PANs and a 19-digit PAN is read from the chip, the device should indicate that the card
type is not supported and end the transaction.
5.2.5 Device Messages

The EMV specifications require messages to be displayed on the screen of the device. The
messages or their equivalent meaning are intended to ensure consistency in what is
displayed by the device and the PIN entry device. Chip display messages are included in
Table 3-1.
5.2.6 Historical Bytes

Some contact chip cards have values in the historical bytes that are returned to the device
in the answer to reset. Although the EMV specifications describe the format of these bytes,
their use is outside the scope of the specifications, and there is no cross-industry definition
for their usage. It is strongly recommended that devices do not use information from
historical bytes in processing; for example, attempting to use these bytes for access to
legacy chip applications. Although such processing may be successful for domestically
issued cards at domestic devices, nondomestic issuers (or card vendors) may define the
same values in the historical bytes for different purposes. This could lead to cards being
rejected or being processed incorrectly because at this stage in processing the transaction,
devices may be unable to determine if a card is domestic or non-domestic.
5.3 Application Selection

When a multi-application card is presented the device determines which payment
applications are supported by both the card and the device. If more than one application is
mutually supported by the card and the device, then the device must not automatically
select an application and use it to conduct a transaction independent of cardholder input
(that is, automatic selection is not allowed).
A device must enable the cardholder to choose which application to use. All mutually
supported Visa payment applications available must be displayed to the cardholder and the
device must proceed with the one chosen by the cardholder.
The only exceptions allowing automatic selection are:
 Contactless transactions
 Transactions on devices that are currently exempted by Visa Rules from use of a PIN
Entry Device (PED).
NOTE: Such exempted devices may include road and bridge tolls, some vending
machines and UCAT in parking environments.
Visa Public Page 40

 Transactions involving cards which Visa agrees can have their own specific rules for
Application Selection. This may be by commercial agreement with Visa or by Visa’s
acceptance of local industry standards or local commercial arrangements between
issuers and acquirers (e.g. co-badging with domestic debit schemes). This generally
occurs when a non-Visa AID represents the same account as the Visa AID in a
particular domestic environment or commercial setting. As the two AIDs refer to the
same application, presenting a choice would lead to confusion. See Appendix I for
examples. .
NOTE: Even exempted devices should allow the cardholder to choose the application to
be used if it’s practical to do so.
A device should not discriminate in favor of any one of the available options, except as
stipulated by the cardholder or by issuer-specified chip parameters. If the Visa Operating
Regulations allow, under a domestic agreement the device may have a means not
described in the EMV specifications to locate proprietary applications in the chip or to
eliminate specific applications from consideration.
Visa requires support for cardholder application selection at ATMs.
If no application can be selected, the device should display a CARD TYPE NOT
SUPPORTED message and fall back to magnetic stripe processing where permitted. Chip
display messages are described in Table 3-1.
For POS and UCAT devices, if PIN entry is required, then following selection of the
application, the device must display the application name at the PIN entry step if it has
sufficient display capacity to do so. This acts as acceptance or confirmation of the
application choice by the cardholder. Alternatively if the transaction does not involve PIN
entry, the receipt will display the application that was selected as per the requirements in
Section 3.6 Transaction Receipts.
The EMV Application Selection Indicators supported in the device for Visa Application
Identifiers (AIDs) must indicate support for partial name selection.
When building the list of mutually supported applications, devices must include all common
applications in the final list except in certain conditions specified in the Visa Operating
Regulations. .
Further information including the requirements relating to Application Selection is included

in the Appendix G, Requirements and Best Practices.
5.3.1 Application Identifiers

A contact chip device must contain the appropriate Visa AIDs. The AID consists of two
components:
 Registered Application Identifier (RID—Represents the payment scheme. Visa’s RID is

A000000003.
 Proprietary Application Identifier Extension (PIX)—Represents the application. The

international PIXs for Visa card products are:
 Visa Debit or Visa Credit—1010
Visa Public Page 41

 Visa Electron—2010
 Plus—8010
The international Visa AIDs (RID and PIX) are:
 Visa Debit/Credit (Commonly referred to as Visa AID).—A0000000031010
 Visa Electron—A0000000032010
 Plus—A0000000038010
Additional digits may be appended to the end of a card’s AID if the card has multiple
applications with the same AID (for example, the card supports both Visa Debit and Visa
Credit). Because the Application Selection Indicators for AIDs must indicate support for
partial name selection, the device is able to select all applications with the same AID.
Devices must not simply use the RID with partial name selection to select applications,
because this can result in the selection of an application not supported by the device. A
number of domestic-only Visa applications have been defined that use the Visa RID with a
PIX defined for that application.
Visa contact chip devices contain the Visa Debit/Credit AID. Many Visa merchants with
online capability accept Visa Electron cards without displaying specific signage. All POS
contact chip devices that contain the Visa Debit/Credit AID, therefore, must also contain the
Visa Electron AID, unless a merchant specifically excludes this application.
All ATMs accepting Visa, Visa Electron, and/or Plus, must support the Visa Debit/Credit,
Visa Electron, and Plus AIDs. ATMs that accept Plus chip cards but not Visa or Visa
Electron chip cards must still support all three AIDs, as a Visa or Visa Electron card
registered with the Plus network will likely not contain the Plus AID. Visa’s routing
requirements are not based on AID, as described in Section 5.3.2 Transaction Routing.
5.3.2 Transaction Routing

Routing or processing of transactions is normally determined in the same manner as it is
for magnetic stripe transactions, which is primarily through the use of BIN tables. Generally
AIDs should not be used to determine routing. For example, data from a card may be
accessed using a Visa AID, but the transaction could be routed to the Plus network. An
example is a Visa/Plus card (containing only the Visa Debit/Credit AID) presented at a
Plus-only ATM. The device should also ensure that the routing is undertaken using the BIN
of the application selected in the instance that the card was a multi-application card which
means that the routing should only occur once the application has been selected.
It is very important to ensure routing decisions are not negatively affected by chip
processing. Acquirers and device vendors must ensure that both Visa and Plus routing
function normally for chip-initiated transactions. This includes transactions initiated for chip
cards that contain only the Plus AID (non-Visa cards that are enrolled to use Plus such as
proprietary cards).
There are no EMV or Visa chip card processing requirements that assume the transaction
is routed over a particular network. All information needed to process the transaction is
carried in the message.
Visa Public Page 42

5.3.3 Regional and Domestic Applications

Depending on the country in which it is located, the device may also need to support Visa
regional or domestic AIDs.
5.3.4 V PAY
Visa Europe has a chip-only, PIN-based debit card program called V PAY, which has a
unique AID. The V PAY card program was created by Visa Europe for use within Europe. V
PAY cards are being issued by banks and accepted by merchants and ATMs throughout
Europe
Visa accepting EMV compliant chip devices that currently support Visa and Visa Electron
card products as well as PIN do not need to be updated to begin accepting V PAY cards.
Acceptance within Europe is provided at EMV-compliant chip devices through the inclusion
of the Visa Electron AID on the cards. Devices supporting Visa Electron must include the
Visa Electron AID to provide this acceptance. ATMs must provide support for V PAY cards
using only the Visa Electron AID and must not include the V PAY AID.
EMV-compliant chip devices that currently support PIN, but do not currently support Visa
Electron products, need only add the V PAY AID (A0000000032020) to begin accepting V
PAY cards.
Devices accepting V PAY must accept PANs up to 19 digits that contain a valid BIN
registered with the V PAY program. These devices must be capable of transmitting the 19-
digit PANs to the acquirer and, in turn, the acquirer must be capable of transmitting the full
PAN to VisaNet in the authorization and clearing messages.
V PAY cards are intended for processing only via the chip, unless co-badged with Plus or
other payment brands. As a result, V PAY cards may not have fully functional magnetic
stripes. In such event, these magnetic stripes are encoded with nonfunctional information,
such as a PAN with all zeroes, but contain a valid Service Code and expiration date.
Devices such as ATMs will not be able to use the PAN in the magnetic stripe to process V
PAY transactions.
5.3.5 Cardholder Application Selection

Visa recommends that devices support cardholder application selection, which allows
cardholders either to:
 Select or confirm their preferred application for a transaction when multipayment cards
are presented, or
 Confirm the use of an application for which cardholder confirmation is required
Visa Public Page 43

Cardholder application selection has been implemented to date in one of two ways:
 Menu—A device that supports cardholder application selection may use a menu to
display all available applications to the cardholder and prompt the cardholder to select
one. If the transaction cannot be performed with the selected application, the device
should display a TRY AGAIN message and display the remaining mutually supported
applications.
 Single name—A device that supports cardholder application selection may display one
application name at a time, which the cardholder may accept or reject. If rejected, the
device then displays the next application name, continuing through the list of common
applications until the cardholder has selected one or rejected all of them.
Either of the above methods satisfies the card application requirement for confirmation
required as indicated in the Application Priority Indicator. (The Application Priority Indicator
determines the priority of a given application or group of applications in a directory and
whether the application requires cardholder confirmation.)
Visa is currently in the process of introducing new rules relating to application selection and
the introduction of these will vary between different regions. It is essential that device
vendors and acquirers confirm local requirements relating to application selection with their
Visa representatives.
The new rules requires that if more than one application is mutually supported by the card
and the device, the device must enable the cardholder to choose which application to use
and not automatically select an application unless the device is exempted from having to
support application selection.
It is recommended that for POS transactions, amount entry should be performed before the
application is selected. The amount should be the final amount including gratuities and any
other charges to be paid.
NOTE: Exemptions include surcharges (if permitted) which may be disclosed before or
after application selection or cash back (if supported and permitted) which may require
application selection to be performed first.
For devices with a separate cardholder and merchant display, the application names for
choice should be displayed only to the cardholder and not to the merchant (In some Visa
regions this is a requirement). The device should also not allow the merchant to choose the
application on behalf of the cardholder. While the customer is choosing the application, the
merchant display should inform the merchant that this is happening. As soon as the
cardholder has completed selection, the application should be identified to the merchant.
The cardholder must not be permitted to use the cancel key as part of the process for
selecting an application and during this process it must only be used to terminate the
transaction.
During the selection process, if present in the card, the application preferred name must be
presented to the cardholder. Otherwise if not present or if the character set of the preferred
name is not supported by the device, the application label must be displayed. A similar
requirement applies to printing of the application name on the receipt.
Visa Public Page 44

Further details regarding application selection, including recommendation relating to the

flow of screens in the selection process can be found in Appendix G, Application Selection
Requirements and Best Practices.
If there is only one application in common between the device and card or if a domestic
arrangement is in place to use only a particular application for domestic cards, cardholder
application selection is not necessary unless the application requires cardholder
confirmation. However it is important that the name of the selected application is displayed
if PIN entry is required. If PIN entry is not required, the selected application should still be
included in the receipt as described in Section 3.5, Device Messages. This is because the
cardholder may not know which application has been selected, for example if an application
on the card has been blocked without the cardholder’s knowledge.
5.3.6 Application Label and Application Preferred Name

Contact chip devices are required to support the character set used by the Application
Label, i.e. ISO/IEC8859. If the device supports the character set used for the Application
Preferred Name, the Application Preferred Name must be used instead of the Application
Label and is displayed in the selected character set. This allows for the display of the
Application Preferred Name in a local language.
It can be helpful to have both the Application Preferred Name and Application Label
presented to the cardholder. This reinforces to the cardholder that either application name
is applicable to this application and prepares the traveling cardholder for times when only
the Application Label is displayed due to language constraints.
The formats of the Application Label and Application Preferred Name allow spaces in these
data elements. The device must display all characters of the Application Label or
Application Preferred Name. If the Application Label or Application Preferred Name
contains an invalid character, this character must be displayed if the device is able to
display it. If the device is unable to display the invalid character, it must display a space
instead. Devices must not reject cards with spaces or invalid characters in these data
elements.
5.3.7 Multiple Languages

Devices may offer the cardholder a choice of languages to be used. Devices have
traditionally offered a menu of all languages supported by the device and have allowed the
cardholder to select the language to be used for subsequent messages.
A chip card may contain a Language Preference data object (accessed when the
application selection process begins), which contains up to four languages in order of
preference. Use of EMV functionality for language selection allows the device to shift
quickly to a language most familiar to the cardholder.
At the beginning of the transaction, a device using EMV functionality to support multiple
languages must compare the card’s Language Preference with the languages supported in
the device. If matches are found, the matching language with the highest preference must
be used in the messages displayed to the cardholder. If no match is found and the device
supports more than one language, the device must allow the cardholder to select the
preferred language at the beginning of the transaction if it has the means for allowing such
selection.
Visa Public Page 45

A chip card may contain more than one cardholder language option. Depending on the
geographic location, devices may need to be capable of recognizing and communicating in
multiple languages. Support for multiple languages and character sets is recommended for
all devices. Local requirements may affect the display of languages.
5.4 Initiate Application Processing

Once an application is selected, the device sends the GET PROCESSING OPTIONS
command to the card to request that the card indicates the data to be used for that
application and its supported functions. The device also provides any information requested
by the card as indicated by the Processing Data Object List (PDOL) sent in the application
selection response. If the PDOL indicated that the transaction amount is to be included in
the GET PROCESSING OPTIONS command, obtaining the transaction amount must
precede the Initiate Application Processing for attended POS devices. UCATs and ATMs
may either obtain the transaction amount or put zeroes in that field.
Account selection generally follows application selection for many ATMs and for those
countries supporting account selection at the point of service; (see Section 3.3, Account
Selection). Although the process for account selection is not part of the EMV specifications,
EMV has defined an optional data element called Account Type. Using this data element,
the device can send the cardholder’s account selection to the card. A card typically
requests this information in the PDOL.
5.5 Read Application Data

The device reads the data indicated by the card in the response to the GET PROCESSING
OPTIONS command and uses the supported function list in the Application Interchange
Profile (AIP) to determine whether to perform the following functions:
 Offline data authentication (optional in certain cards)
 Cardholder verification (Visa cards are required to support this function)
 Terminal risk management (devices must always perform this function regardless of the
application’s AIP settings unless they are offline-only or online-only devices. See
Section 5.9, Terminal Risk Management for more information)
 Issuer authentication using the EXTERNAL AUTHENTICATE command (optional in

cards)
Visa Public Page 46

5.5.1 Tags
The data retrieved by the device during this step are identified by tags. The EMV
specifications define the tags for the data elements defined in these specifications.
There may also be payment system specific tags, issuer-specific tags, and private tags
agreed upon by multiple issuers. To process private tags, a device must have the data
required to identify the scope of a private tag, that is, whether it has meaning for the
transaction. If the device message format supports a generic EMV data field, such as Field
55 in an ISO message, the private data tag should be included in that field so that it may be
sent to the issuer. If the data element and logic required to identify the scope of the private
tag are not correct or available, the device ignores the private tag.
5.6 Processing Restrictions

The device must perform the processing restrictions check based on data provided by the
chip to determine whether the transaction should be allowed.
The device must check whether the expiration date and, if present, the effective date for the
card has been reached. These conditions are later evaluated based on card and device
settings to determine the transaction outcome.
ATMs must not return or decline a transaction based on expiration date. They must accept
the transaction even if the card has expired and must route the transaction for issuer
authorization unless the card is set to decline offline. Note that if the ATM is performing
Terminal Action Analysis, a setting in the Issuer Action Codes may cause an offline decline.
The Application Usage Control field may be set by an issuer to limit or enable a card’s use
for certain transactions, for example, domestic or international, cash, goods or services, or
cash back. The device checks the Application Usage Control received from the card to see
if the transaction type is allowed.
The two Application Usage controls “If goods” and “If services” should be treated as
equivalent. A transaction for domestic goods or services is allowed if either a valid control
for domestic goods or domestic services (or both) is set; the same is true for international
goods and international services.
5.7 Offline Data Authentication

Offline data authentication enables authentication of a payment application for offline
transactions. The three types of offline authentication are:
 Static data authentication (SDA)—A counterfeit protection method that ensures a set
of static data obtained from the valid issuer has not been modified since initial
personalization onto the card. SDA support is required for all contact chip devices with
offline capability.
Visa Public Page 47

 Dynamic data authentication (DDA)—Offers a higher level of data authentication

than SDA, providing protection against both counterfeiting and the replaying of copied
data (comparable to magnetic stripe data skimming). DDA support is required for all
contact chip devices with offline capability.
 Combined DDA/Generate Application Cryptogram (CDA)—Combines DDA with the

generation of a card’s Application Cryptogram to assure card validity. Support of CDA
in devices may be needed in some countries, as this process has been implemented in
specific markets. CDA is intended to protect offline transactions where there is
significant opportunity for interception of chip-to-device communications.
Visa does not support the use of offline data authentication at ATMs because the use of the
Authorization Request Cryptogram (ARQC) in the online authorization message provides
protection equivalent to the dynamic forms of offline data authentication.
All Visa cards that support DDA or CDA are required to support the Dynamic Data
Authentication Data Object List (DDOL), which contains the list of device data elements the
device must send to the card in the command requesting a dynamic signature. If a DDOL is
not received from the card, the device must use its Default DDOL. The Default DDOL must
contain only the tag and length for the Unpredictable Number. No other data objects may
be referenced in the Default DDOL.
Visa Europe has mandated the use of DDA from January 2011 and other regional
variations requiring migration from SDA to DDA may exist. It is important for device vendors
to consult with their local Visa representative to confirm regional requirements.
5.8 Cardholder Verification

Cardholder verification is used to evaluate whether the person presenting the card is the
legitimate cardholder. The CVMs that may be supported by a contact chip device for a chip
transaction are:
 Offline plaintext PIN
 Offline enciphered PIN
 Online PIN
 Offline plaintext PIN and signature
 Offline enciphered PIN and signature
 Signature
 No CVM Required
 Fail CVM Processing

All contact chip devices that support offline enciphered PIN must also support offline
plaintext PIN.
Visa Public Page 48

The device uses a CVM List from the card to determine the type of verification to be
performed. The CVM List establishes a priority of CVMs to be used relative to the
capabilities of the device and characteristics of the transaction. The CVM List may contain
a CVM called Fail CVM Processing.
Sections 5.8.1 and 5.8.2 discuss processing exceptions for the CVM List and the LAST PIN
TRY display message. (See Table 3-1 for display message information.) Additional CVM
considerations are discussed in Chapter 7, Security Characteristics.
5.8.1 CVM List Processing Exceptions

Devices need to support an appropriate minimum level of cardholder verification, as
determined by Visa or by local law, even when the card does not support CVM processing,
no CVM List is present, or the last CVM processed in the CVM List is No CVM Required. If
CVM processing does not result in the required CVM, the device may additionally perform
the CVM designated in the Visa Operating Regulations or in local law for the device and
transaction type. If the Visa Operating Regulations or local laws require that signature,
offline PIN, or online PIN be performed, the device may print a signature line on the receipt
or request a PIN, as appropriate.
Alternatively, if the terminal determines that CVM Processing has failed (as an example
where the cardholder is unable to enter a PIN but the CVM list only supports PIN entry) and
the transaction is sent online and the issuer responds with an approval, it is recommended
that the device prints a signature line on the receipt and the terminal prompts the merchant
to request a signature. Although the acquirer has no liability for the transaction, given the
issuer has approved it, the collection of a signature will reduce the grounds for any potential
future disputes.
One example is that Visa requires online PINs for ATMs and online or offline PIN for certain
types of transactions at UCATs, regardless of the CVM List. In these cases, the ATM or
UCAT will request PIN.
If the Visa Operating Regulations or local laws do not require a particular CVM, merchants
should allow CVM processing to determine the CVM to be used. The Visa Operating
Regulations prohibit requesting PIN unless specified in the chip’s CVM List or as noted
above.
Transactions that qualify under the VEPS program do not require cardholder verification
with the exception of transactions at chip card devices in certain countries where
cardholder verification is still required.
5.8.2 Last PIN Try Message

When the device determines that an offline PIN is to be entered, the device must either
prompt for PIN entry or check the PIN Try Counter. If the PIN Try Counter contains a value
of 1 indicating one remaining PIN try, the device should display the Visa proprietary
message of LAST PIN TRY.
Visa Public Page 49

5.9 Terminal Risk Management

Prior to sending an authorization decision to the card, the device determines whether
terminal risk management must be performed.
Online-capable devices (i.e. are capable of both offline and online processing) must
support terminal risk management and perform terminal risk management for Visa chip
cards, regardless of the parameters in the card. (The EMV specifications allow for cards
that do not require terminal risk management.) The two mandatory risk management
checks for online-capable devices are: terminal floor limits and random transaction
selection.
5.9.1 Terminal Floor Limits

Terminal floor limits are transaction amounts above which an online authorization should be
performed. Acquirers use the Visa Operating Regulations for the country and merchant
type to determine the appropriate floor limit.
Online-capable devices must perform floor limit checking on all transactions. If card
parameters indicate that the transaction must be processed online, the device must attempt
to send the transaction online regardless of the floor limit, and the transaction may be
declined if the device cannot obtain an online authorization.
Because countries may implement different floor limits for chip and magnetic stripe
transactions, devices should be capable of supporting both. Alternatively, devices could
have an effective zero floor limit for magnetic stripe transactions by forcing all magnetic
stripe transactions online (only where the magnetic stripe floor limit is zero) and use a floor
limit for chip transactions.
Floor limits for magnetic stripe transactions are not applicable for fallback transactions,
since all fallback transactions are zero floor limit. If magnetic stripe fallback transactions are
unable to be processed online, paper voucher or key entry processing is permitted with
voice authorization. If a magnetic stripe fallback transaction cannot be authorized, it must
be terminated.
An acquirer or merchant may have business reasons for setting a different floor limit value
from that published by Visa. Setting the device’s floor limit value higher than that published
by Visa creates a liability for the merchant and acquirer. In this document, floor limit values
are assumed to be set to the values published by Visa in its operating regulations.
5.9.2 Random Transaction Selection

Random selection of transactions for online processing must be supported. This
functionality protects against fraudulent cards designed to operate exclusively offline.
All online-capable devices must randomly select below-floor-limit transactions for online
processing. The values used in this selection are determined per country, balancing two
goals:
 Preventing fraudsters from predicting a device’s online behavior and exploiting the floor
limit
Visa Public Page 50

 Providing appropriate opportunities for transactions to be approved offline, depending

on issuer-determined card controls
There are two types of random selection:
 Random selection—A certain percentage, between 0 and 99 percent, of below-floor-

limit transactions is sent online.
 Biased random selection—A formula is used to determine whether the transaction

goes online. This formula increases the probability of online authorization the closer the
transaction amount is to the floor limit.
Selection Factors
Random transaction selection is based on three factors:
 Target percentage for random selection—(a value between 0 and 99). This value
determines the approximate percentage of transactions below the threshold value that
the device sends online for authorization. It also determines the minimum percentage
of above-threshold transactions to be sent online. Setting the target percentage to zero
turns off random transaction selection.
 Threshold value for biased random selection—(a value between 0 and the value of
the floor limit). Below this threshold, transactions are subject to random selection;
above it, to biased random selection. If this value is zero, all transactions would be
evaluated by biased random selection; if set to the floor limit, biased random selection
would not be used (only random selection).
 Maximum target for biased random selection—(a value between 0 and 99, equal to
or greater than target percentage for random selection). This value is used to weight
the above-threshold selection criteria to increase the percentage of selected
transactions as the transaction value approaches the floor limit. The higher a value, the
more likely that the transaction will go online.
Random Transaction Selection Process
Random transaction selection is performed as follows:
1. The device generates a random number between 1 and 99.

2. If the transaction amount is less than the threshold value for biased random selection,
random selection is used. If the device-generated number is higher than the target
percentage value, the transaction may be approved offline if card controls permit. (The
card, using its own parameters, may require that the transaction to be sent online for
authorization.)
3. If the transaction amount is less than the threshold value for biased random selection,
random selection is used. If the device-generated number is lower than or equal to the
target percentage value, the device sends the transaction online for authorization. If
online processing is unavailable, the transaction may be approved offline by the card if
the card controls permit.
Visa Public Page 51

4. If the transaction amount is greater than or equal to the threshold value for biased
random selection, the transaction is subject to biased random selection. Here the
nearer the transaction amount is to the floor limit, the greater the likelihood that the
device will select the transaction for online authorization. The target percentage for
random selection sets the minimum percentage selected by this method, and the
maximum target percentage for biased random selection determines the maximum
percentage of transactions selected for online authorization by biased selection.
To summarize, assuming a random distribution of transaction amounts:
 All above-floor-limit transactions will go online for authorization.
 Below the floor limit and below the threshold, the target percentage of transactions will
be sent online.
 Below the floor limit and above the threshold, transactions will be increasingly likely to
go online the closer they are to the floor limit. This probability will be capped by the
maximum target percentage.
The examples below are based on a market using the values shown in Table 5-1.
Table 5-1: Random Transaction Selection Values

International Domestic
Chip floor limit €0 €100
Threshold value for biased N/A €40
random selection
Target percentage for random N/A 20%
selection
Maximum target percentage N/A 50%
for biased random selection
N/ANot applicable
Assuming that the device has generated a random number of 25 for this transaction, the
following points provide examples of the result:
 International transaction amount =15. Because there is a zero floor limit for
international transactions, the transaction is selected for online processing.
 Domestic transaction amount = 15. Because the transaction amount (15) is both below
the floor limit (100) and the threshold value for biased random selection, random
selection is performed. The terminal random number (25) is compared to the target
percentage for random selection (20) and, because the random number is higher, the
transaction is not selected for online processing.
 Domestic transaction amount = 60. Because the transaction amount (60) is below the
floor limit but above the threshold value for biased random selection (40), biased
random selection is performed. The following calculations are performed:
1. A ratio, or bias, is determined: (transaction amount – threshold value)/(floor limit –
threshold value) =(60 – 40)/(100 – 40) = 20/60 = 1/3
Visa Public Page 52

2. The incremental percentage to be biased is determined: (maximum target % for

biased random selection – target % for random selection) = (50 – 20) = 30
3. The biased incremental percentage is calculated: (incremental percentage * ratio)
= (30 * 1/3) = 10
4. A weighted target is created: (target % for random selection + biased incremental
percentage) = (20 + 10) = 30. This weighted target (30) is greater than the device’s
random number of 25, so the transaction is selected for online processing.
 Domestic transaction amount = 150. Because this is above the floor limit, the
transaction is not subjected to random selection. It is selected for online processing by
the device’s floor-limit checking function.
5.10 Terminal Action Analysis

The device uses the results of previous processing steps together with the device and card
rules to determine whether a transaction should be approved offline, sent online for
authorization, or declined offline. After determining the disposition of the transaction, the
device requests an Application Cryptogram from the card, corresponding to the transaction
disposition:
 Transaction Certificate (TC)—Offline approval
 Authorization Request Cryptogram (ARQC)—Online authorization
 Application Authentication Cryptogram (AAC)—Offline decline

In the Request Application Cryptogram step, the device issues the card a GENERATE
APPLICATION CRYPTOGRAM (AC) command. The device indicates if CDA is to be
performed.
Section 5.10.1 discusses the details of terminal action analysis processing. Section 5.10.2
discusses the unique requirements for online-only devices.
5.10.1 Terminal Action Codes and Issuer Action Codes

Terminal Action Codes (TACs) are the device-based rules for terminal action analysis. TAC
values are mandated by Visa and must be supported by offline-capable devices. There are
three types of TACs: TAC—Denial, TAC—Online, and TAC—Default. Appendix B,
Transaction Acceptance Device Requirements, contains the required values for these
TACs.
Issuer Action Codes (IACs) are the card-based rules that the device uses during terminal
action analysis. IAC values are set by the issuer. There are three types of IACs: IAC—
Denial, IAC—Online, and IAC—Default.
Visa Public Page 53

5.10.2 Online-Only Devices

An online-only device always attempts to go online with the authorization request, unless
declined offline due to IAC—Denial settings. During IAC—Denial and TAC—Denial
processing, if a Terminal Verification Results (TVR) bit is set and the corresponding IAC—
Denial and TAC—Denial bits are set, the device declines the transaction. The only relevant
TAC setting for a transaction at an online-only device is “Service not allowed”.
An online-only device may perform or omit IAC—Online and TAC—Online processing and
IAC—Default and TAC—Default processing. For IAC—Online and TAC—Online
processing, if performed, the only relevant TVR setting for an online-only device is
“Transaction value exceeds the floor limit”. Because the floor limit is set to zero, the
transaction always goes online and all other values in TAC—Online or IAC—Online are
irrelevant.
The IAC—Default and TAC—Default processing, if performed, always causes a transaction

to be declined if an online authorization could not be performed.
Visa strongly recommends that online-only devices omit the IAC—Online and TAC—Online
processing and request an ARQC after IAC—Denial and TAC—Denial processing. If
unable to go online, the device should request an AAC and notify the cardholder that the
service cannot be performed due to communication failure. The device should not perform
the IAC—Default and TAC—Default processing. The TAC values do not need to be present
if the associated processing is omitted.
5.11 Online Processing

The ARQC must be included in the authorization message. The issuer validates the ARQC
to ensure that the card is valid and can use the results in its authorization decision. Visa
can also validate the ARQC on behalf of the issuer in the instance where the issuer host is
unavailable or the issuer does not have the internal capability to undertake the validation.
The ARQC uses dynamic transaction data to provide high protection levels against
counterfeit and skimming. To facilitate validation of the ARQC, the device must send the
same data in the online authorization that was sent to the card in the first GENERATE AC
command. Failure to comply could lead to failures in the card authentication process and
unnecessary declines.
If a category of transactions must be authorized online due to market or the Visa Operating
Regulations, the device should set the “Transaction exceeds floor limit” bit in the TVR to 1.
An example is where the market requires that particular types of transactions (for example,
purchase with cash back) be authorized online.
The merchant can deploy a variety of techniques to ensure that a particular transaction or a
particular category of transactions (for example, purchase with cash back) is authorized
online. Transactions sent online because of merchant automated processes should not
have any TVR bits set as part of that process.
Setting the “Merchant forced transaction online” bit is reserved for situations where the
clerk explicitly forces a transaction online, such as for suspicious behavior. Support for a
facility to force the transaction online, as described in the EMV specifications, is optional
and not mandatory and may be determined by acquirer or local requirements.
Visa Public Page 54

Merchants and acquirers should not indicate that a PAN was found in a terminal exception
file except when a formal arrangement with affected issuers is in place. Specifically, the
TAC condition “The PAN is on the terminal exception file” should be evaluated as true only
if the PAN was placed in the terminal exception file under the formal arrangement. PANs
extracted from the Visa Exception File for this use are considered compliant with this
requirement.
Appendix E, EMV Tag to VisaNet Data Element Mapping, provides information to help
vendors and acquirers understand the chip data required in messages sent between
devices and acquirers and between acquirers and VisaNet.
5.11.1 Cash back Identification

Visa allows cash back to be provided with a purchase at the point of service for domestic
transactions, under certain conditions. Current Visa rules do not allow cash back to be
provided on credit cards or when the cardholder has selected to use a credit facility (as
opposed to a credit card which is linked to a debit account). Where permitted, a device
must send the cash back amount to the card when requested and then send the following
cryptogram data to the acquirer for inclusion in the online message:
 Cryptogram Amount (V.I.P. Field 147, EMV Tag 9F02)—The total of the purchase
amount plus the cash back amount
 Cryptogram Cashback Amount (V.I.P. Field 149, EMV Tag 9F03)—The cash back
amount
If the transaction involves cash back, the Cryptogram Cashback Amount must be present
and included in the ARQC algorithm. If the transaction does not involve cash back, the
ARQC is calculated with a zero cash back amount.
5.12 Completion
Completion closes the processing of a chip transaction. The card and device perform final
processing to complete the transaction.
When the online authorization is successfully completed, the device issues a final
GENERATE AC command to the card to request additional card analysis and a final
Application Cryptogram. To determine the type of cryptogram to request from the card, the
device uses the Authorization Response Code received from the issuer in the online
authorization response as follows:
 If the Authorization Response Code is 00, 10, or 11 indicating that the issuer has
approved the transaction, the device requests the approval cryptogram (TC).
 If the Authorization Response Code is 01 or 02 indicating that the issuer has requested
a referral, the device should request the decline cryptogram (AAC).
 If the Authorization Response Code does not contain the above-mentioned values
indicating approval or referral, the transaction is considered to be declined by the
issuer, and the device requests an AAC.
Visa Public Page 55

The card uses the transaction disposition, issuer authentication results, and issuer-encoded
rules to determine whether to return a TC or an AAC.
Although devices are not required to retain the cryptogram (TC or AAC) for online-approved
transactions at single-message or host-capture devices, the device must request the final
cryptogram to allow the chip card to complete issuer authentication to avoid unnecessary
online requests during subsequent POS transactions. A reversal must be generated for
approved transactions that are subsequently declined by the card.
NOTE: After generating an ARQC, generating a TC causes the offline counters in the
card to be reset (if issuer authentication is successfully completed). Not requesting a TC
could cause a subsequent online request to be generated prematurely
For terminal-capture devices, if the transaction was approved either online or offline, the
device transmits the TC and the related cryptogram data in the clearing message.
If during processing, the EMV specifications require the device to terminate the transaction,
the device needs to display a message to the cardholder and merchant indicating why the
transaction cannot be completed and that the card should be removed.
If the transaction is declined offline, the device cannot force the transaction online in an
attempt to get an approval. Declined transactions are further discussed in Section 5.12.7,
Declined Transactions.
Figure 5-1 illustrates a sample transaction flow including all the various steps described in
the previous sections.
Visa Public Page 56

Figure 5-1: Sample Transaction Flow Diagram

KEY
Card Terminal
Mandatory SELECT
process Command/
List of Supported Response Application Selection
Applications READ RECORD
Mandatory Command/Response
process w/
optional Supported Functions GET PROCESSING
Initiate Application
steps & Pointers to OPTIONS
Processing
Application Data Command/Response
Optional READ RECORD

Provide Application Read Application
process Commands/
Records Data
Responses
INTERNAL AUTHENTICATE Offline Data

Generate Dynamic 1 Authentication
1 - if DDA Cryptogram
Command/Response SDA or DDA
2 - If Offline
Enciphered
PIN
3 - Optional for Processing
Offline PIN Restrictions
4 -- If Offline PIN
Generate Unpred.
Number GET CHALLENGE Command/Response2
These steps PIN Try Counter GET DATA Command/Response3
Cardholder
Verification
can be
performed Validate PIN VERIFY Command/Response4
in any order Last Online

Application GET DATA Terminal Risk
Transaction Counter Command/Response Management
(ATC) Register
GENERATE APPLICATION Terminal Action

CRYPTOGRAM Command Analysis
Perform Card Action

Analysis & generate GENERATE APPLICATION Online
Application CRYPTOGRAM Response Transaction?
Cryptogram
Online Processing
N
EXTERNAL
Validate ARPC
AUTHENTICATE Issuer Authentication
Cryptogram
Command/Response
GENERATE
Perform final checks
APPLICATION
& generate final Completion
CRYPTOGRAM
cryptogram
Command/Response
Issuer-to-Card Script
Issuer-to-Card Script
Apply Script Commands/
Processing
Responses
Visa Public Page 57

5.12.1 Online-Authorized Transactions

Single-message full financial and host-capture transactions contain the ARQC in the
financial/clearing message. Device-capture transactions contain the TC in the clearing
message. For most ATM transactions, whether single- or dual-message, the clearing
message contains the ARQC and not the TC. In most dual-message ATM implementations,
the acquirer host captures the authorization response from the issuer to create the clearing
message and does not have access to the final TC (similar to host-capture point of
service). If the ARQC is used in the clearing message a valid authorization code is
required.
Devices operating in a single-message or host-capture environment should ensure a TC is

generated for approved transactions. Although not needed for clearing, generating a TC
ensures that cards do not request unnecessary online approvals on subsequent
transactions and also provides liability protection for acquirers.
Generally, the TC is discarded in single-message or host-capture environments. However,

some countries may require retention of the TC and define the appropriate advice
messages needed for transmission of the TC.
Device-capture acquirers use the ARQC for the authorization and the TC for the clearing
message.
Many data elements used for Application Cryptogram generation are likely to be different
between the authorization message and the clearing message. It is critical to use the data
elements associated directly with the cryptogram included in the message. Besides the
cryptogram itself (ARQC or TC), the following elements are also likely to differ:
 Card Verification Results (CVR) (the cryptogram type is updated as well as the issuer
authentication results)
 TVR (updated with the issuer authentication results)
 Amount, Authorized (in some cases, such as partial approvals and travel and
entertainment transactions, the amount in the authorization may differ from the final
amount in clearing)
 Unpredictable Number (devices may use a new Unpredictable Number for each
cryptogram generation; the Unpredictable Number sent in the clearing message must
be the one used for the cryptogram sent in the clearing message)
5.12.2 Acquirer Stand-In

If the card generates an ARQC to indicate that the transaction must be sent online, but the
acquirer is unable to communicate to the issuer and wants the disposition of the transaction
to be decided by the card and the device, the acquirer causes the device to indicate that
the transaction was unable to go online. If the second Application Cryptogram is a TC, the
transaction is approved. If the second Application Cryptogram is an AAC, the transaction is
declined. An acquirer may decide to override the decline decision and clear the transaction
at its own liability. Because the transaction was not authorized, the issuer may charge
back these transactions if either they cannot collect from the cardholder or the cardholder
disputes the transaction.
Visa Public Page 58

To accomplish this, the acquirer may either set up the device to override a decline under
certain conditions or send an indication to the device to override if a particular transaction is
declined. When this occurs, the device does not display a decline message but displays
another message determined by the acquirer, the consumer receives the goods or
services, and the transaction is cleared.
The device should request a TC, and the card will respond with either a TC (indicating that
the transaction is approved offline) or an AAC (indicating that the transaction is declined
offline).
 If the card generates a TC, the acquirer should use this TC and its associated data
elements for the clearing message. (The transaction is approved, and the acquirer
retains protection.)
 If the card generates an AAC, and the acquirer elects to clear the transaction, the
transaction must be cleared with the AAC and its associated data elements. (The
transaction is not approved, and the acquirer submits the transaction into clearing at its
own liability.)
It is recommended that the device checks the results of Offline Data Authentication prior to
approving the transaction and submitting it for clearing. However, if most cards in the
country do not support Offline Data Authentication, the merchant may decide not to support
Acquirer Stand-In, or may elect to accept the additional risk in the interest of customer
satisfaction.
NOTE: A preferable approach is to use the ARQC to perform a deferred authorization.
5.12.3 Acquirer Forced Settlement

In certain circumstances such as when the transaction is above floor limit but the terminal is
unable to go online, the acquirer may elect to clear a transaction even if Terminal Action
Analysis indicates that an AAC is requested in the second GENERATE AC. In this case the
card will return an AAC and the transaction is cleared with the AAC and its associated data
elements. The transaction is cleared at the acquirer’s liability.
approving the transaction and submitting it for clearing. However, if most cards in the
country do not support Offline Data Authentication, the merchant may decide not to support
Acquirer Forced Settlement, or may elect to accept the additional risk in the interest of
customer satisfaction.
NOTE: A preferable approach is to use the ARQC to perform a deferred authorization.
5.12.4 Deferred Authorization

Deferred authorization is where an online authorization is performed after the card is no
longer available as discussed in Section 2.7, Deferred Authorization.
Visa Public Page 59

This is accomplished by the device requesting an ARQC. The device then informs the card
that it cannot go online and requests a TC, obtaining either a TC or AAC. Later, the device
uploads a batch of authorization requests that include the ARQCs for those transactions
that received AACs and clearing records for those transactions that received TCs. The
acquirer submits the authorization requests, some of which are approved online. The
acquirer formats and submits a clearing record for each approved transaction, using the
ARQC for online approved transactions and the TC for offline approved transactions.
approving the transaction and submitting it for deferred authorization. However, if most
cards in the country do not support Offline Data Authentication, the merchant may decide
not to support deferred authorization, or may elect to accept the additional risk in the
interest of customer satisfaction.
5.12.5 Authorization Response Cryptogram Consideration

Issuers may generate an Authorization Response Cryptogram (ARPC) as part of the
response message to allow the card to validate that it was generated by the legitimate
issuer. This is known as Issuer Authentication. If the ARPC fails validation the card may
decline a transaction that was approved online. In this situation EMV requires that online
data-capture devices generate a reversal.
Issuer authentication may fail for a variety of reasons including issuer host processing
errors or acquirers modifying the data received from the issuer before it is passed to the
device. The process of determining what happens if issuer authentication fails is
determined solely by the settings in the card and the device should only follow the
indications from the card.
5.12.6 Offline-Authorized Transactions

Offline chip authorization may occur when a transaction amount is under the floor limit or
the transaction is offline only. In these cases, the card generates a TC, which is included in
the clearing message along with its associated data. The device generates a Y1 or Y3
Authorization Response Code indicating an approval for inclusion in the clearing message
(see Appendix E, EMV Tag to VisaNet Data Element Mapping, for a description of these
codes).
For online authorized transactions, an Authorization Code is included in the authorization

response, which is printed on the transaction receipt and sent in the clearing message.
Authorization Codes for offline-authorized chip transactions are left to the acquirer’s
discretion. Visa recommends that Authorization Codes for offline transactions be shown on
the receipt in the CHPxxx format where xxx can be set to any value by the acquirer or
device.
5.12.7 Declined Transactions

Where the authorization response received by a device indicates a decline, the merchant
should be informed on the device display that the transaction has been declined. For the
display to the cardholder, the term NOT AUTHORIZED may be preferred.
Visa Public Page 60

Authorization responses indicating a decline may contain an Issuer Script to be acted on by

the card. If so, the Issuer Script must be processed.
In a few countries, for auditing purposes, declined transactions are delivered along with the
clearing batch to the acquirer (though the declines might not be forwarded to the issuer). In
other countries, declines may simply be deleted from the device.
5.12.8 Offline Declined ATM Transactions

In certain instances an ATM may decline a transaction offline rather than send it online.
This may happen is if the issuer has set the IAC-Denial bit corresponding to Service Not
Allowed and the AUC in the card is set as to not allow the card to be used at an ATM. In
this case the ATM will request an AAC in the first GENERATE AC command resulting in a
decline transaction.
5.13 Transaction Conclusion

Transaction conclusion, as described here, is not part of the EMV or VIS specifications for
the processing of contact chip transactions. It should not be confused with transaction
completion, which is a required step.
Transaction conclusion may be viewed as the point in the process where the device has
gathered all the data necessary to process the transaction. It may also be viewed as the
point in the dialogue between cardholder and device where goods or services are either
exchanged for payment or the transaction is terminated. Evidence of transaction conclusion
is usually the generation of a receipt—a record (paper or electronic) that confirms the
exchange of goods or services for payment. For device-capture systems, the device adds
the transaction data to the current batch.
The device should send the same data in the batch data capture message that was sent to
the card in the GENERATE AC command immediately preceding the creation of the batch
data capture message. For example, when a tip is added to the transaction amount at the
end of the transaction, both the amount used in the GENERATE AC command and final
amount should be sent in the clearing message.
The chip card must remain in the chip card reader until the last EMV transaction step,
including Issuer Script processing, is completed. The cardholder and merchant experience
here is different compared to a magnetic stripe transaction, where the merchant may swipe
the card and immediately return it to the cardholder. To reinforce this behavior, once the
EMV transaction has ended and is approved, the device should display a message
instructing the cardholder or merchant to remove the card. Merchant staff should ensure
that they do not remove the card before the message is displayed otherwise the transaction
may fail.
If the card is removed before the transaction is complete (that is, the TC or AAC has not
been received from the card), the transaction must always be terminated. If an online
authorization has taken place, a reversal message should be sent. (If a decline response
has been received, it is not necessary to send a reversal.)
Visa Public Page 61

If a card is removed after the second cryptogram generation but before Issuer Script
processing, the transaction is considered complete and transaction disposition is
unchanged. To mitigate this, the device must not display a message indicating that the
transaction has been approved or declined until after the completion of Issuer Script
Processing. However a script failure should not result in a declined or reversed transaction.
5.14 Considerations for Industry-Specific Transaction Types

The EMV specifications address the use of EMV functions for simple retail transactions and
cash disbursements, which are described in Sections 5.1 through 5.13. EMV functionality
for other financial and nonfinancial transactions is discussed further in Recommendations
for EMV Processing for Industry-Specific Transaction Types, available at www.emvco.com.
This section contains additional Visa recommendations for these transaction types.
Generally, chip transactions should flow similarly to magnetic stripe transactions. In many
cases, the Visa Operating Regulations for chip transactions are no different from those for
magnetic stripe transactions. In some cases, change is unavoidable, such as the display of
a cardholder application selection menu when the chip supports more than one application
or the introduction of a new CVM.
Transactions where either the card or the device has not completed all required
components of EMV processing, including generating an Application Cryptogram, are not
EMV transactions. This includes any transaction where data such as a PAN and expiration
date are extracted and used to complete the transaction.
5.14.1 Pre-Authorizations
A pre-authorization is when an authorization takes place before the final amount is
determined. Pre-authorizations are subject to payment system rules but normally will be
EMV transactions. Note that in certain environments, any estimated amount is likely to be
the maximum dispensable value of goods or services.
5.14.2 Incremental Authorizations

Where the final amount will exceed or is likely to exceed the amount of the pre-
authorization, a further incremental authorization may be obtained. The incremental
authorization will be for the difference between the original pre-authorization and the actual
or estimated final amount. A merchant may process as many incremental authorizations as
are necessary to ensure the authorized amount is greater than the final transaction amount.
Market practice or payment system rules may allow variances above the pre-authorized
amount for specific transaction scenarios.
Incremental authorizations are usually manual or key entered and are not EMV
transactions. The original chip data obtained during pre-authorization should not be
resubmitted during incremental authorizations. No chip data (except the PAN and expiry
date) nor the full track 2 data should be stored or used for this purpose. Merchants can
store the card’s PAN and expiry date in order to perform incremental authorizations, as
allowed by the Payment Card Industry Data Security Standard (PCI DSS) and card system
rules.
Visa Public Page 62

If the card is present, the incremental authorization can be chip-read, and should be
conducted as described in Section 5.14.1, Pre-Authorizations.
5.14.3 Sale Completion

A sale completion is the financial settlement of a previously authorized transaction, often
where the cardholder and card are no longer present. The final transaction amount may
differ from the authorized amount, usually within a range defined by the market.
NOTE: Typically an online authorization for an estimated amount is used for travel and
entertainment where the final amount is not known. Check the Visa rules for the specific
country and T&E category.
The POS Entry Mode Code for a sale completion should be set to “chip read” only if either
of the following conditions occurs:
 The original online authorization contains a cryptogram and all of the chip data
elements used to create the cryptogram.
 The cryptogram and all of the chip data elements used to create the cryptogram from
the offline authorization are included with the sale completion. The original offline
authorization is not submitted into clearing.
Transactions should not be identified as “chip read” unless all mandatory chip functions are
performed, including reading all of the required chip data. Transactions identified as chip
read, but with incomplete chip data, may be declined or returned from Visa.
5.14.4 Status Check and Account Number Verification

A status check is an online authorization for a single currency unit. In some markets, status
checks are used as authorizations for automated fuel dispensing, implicitly allowing up to a
set amount to be used during completion. Status checks must be sent online because the
chip does not have any mechanism to recognize the implicit value of this special
transaction. The use of status checks is limited to automated fuel dispensing.
Account number verification is an online authorization for a zero amount. It can be used to
validate that the card used to pay for services in advance of delivery or to make a
reservation is authentic. Account number verification may be used to reset cumulative
offline counters for those customers that have exceeded their offline limits without requiring
those customers to make a purchase or withdrawal in order to get an online authorization.
In a card-present environment, EMV functions such as dynamic offline data authentication

(DDA or CDA) may be sufficient for card validation.
5.14.5 Refunds
A refund occurs when the cardholder is credited with the value of returned goods or mis-
performed services. Both full and partial refunds of the original transaction may be
performed. A refund consists only of a clearing message.
Visa Public Page 63

It is strongly recommended that refunds for chip cards be performed by following the
normal EMV transaction flow to obtain the Track 2 Equivalent Data field from the chip. If
this field is not present on the chip, the device should obtain the contents of the PAN and
expiration date fields instead. Performing Offline Data Authentication (if supported by the
card) and cardholder verifications, as performed for purchases, will help protect the
merchant and acquirer against fraudulent refunds.
If the PDOL indicates that the transaction amount and the transaction type are to be
included in the GET PROCESSING OPTIONS command, it is recommended that the
device send the refunded amount as the transaction amount and the transaction type as
20. If the PDOL indicates the transaction amount, but not the transaction type, is to be
included in the GET PROCESSING OPTIONS command the device should send a zero
transaction amount to the card.
Once the required data (either Track 2 Equivalent Data or PAN and expiration date) is
obtained, the device should then stop the transaction flow. The device must not request a
TC and should request an AAC. The Amount, Authorized must be set to zero. The device
completes refund processing normally using the PAN and expiration date.
If an attempted chip refund fails (for example if the chip cannot be read or chip technology
fails during the transaction) the merchant should re-initiate the refund transaction either by
using the magnetic stripe or by using manual key entry.
NOTE: In some environments, the refund may be sent online. However, it is sent as an
advice to the acquirer and the acquiring host does not forward the message.
5.14.6 Reversals
A reversal should be generated any time an approval is received for an online authorization
request but where the transaction cannot be completed.
In certain circumstances the issuer may have approved the transactions but the card may
override this and decline the transaction. This is primarily due to an Issuer Authentication
failure where the ARPC sent by the issuer in the response message was verified by the
card but failed.
If the market supports reversals, host-capture, SMS and ATM and terminal capture devices
must initiative a reversal message.
If a reversal is required for an Issuer Authentication failure and the following fields are
available, they should be included in the reversal:
 TVR (updated with the issuer authentication results)
 CVR (updated with the issuer authentication results)
 Issuer Script Results (if the original response message from the issuer contained an
issuer script, the issuer script results are provided in this field)
Visa Public Page 64

5.14.7 Referral
A referral is intended as a fraud control tool for Issuers to use when more information is
needed to verify the identity of the cardholder or the validity of the card prior to approving a
transaction. A referral is not a transaction; it is an exception process for a purchase.
When a referral authorization response is received from the card issuer, the terminal should
request an AAC from the card at the second GENERATE AC request. Generation of an
AAC merely completes the EMV transaction flow so that the referral procedure can take
place. The cryptogram produced by the card should be disregarded by the terminal as any
subsequent approval of the transaction is dependent on the outcome of the referral
process.
Depending on the market’s implementation, the referral process will either result in
production of a clearing record linked to the original authorization (in which the ARQC and
related data of that authorization should be included), or more likely it will result in a
completely new transaction taking place generally when the card Issuer has removed the
referral block.
5.14.8 Cancellation
A cancellation occurs when a purchase or sale completion transaction is aborted either
during processing, or after processing. In a dual-message environment cancellation should
only occur before the transaction is cleared to the acquirer.
There are a number of reasons why cancellation may occur, such as an error in the amount
entered by the merchant which the merchant may seek to correct by pressing a cancel
button on the device. Cancellations also occur when a merchant does not approve the
cardholder’s signature.
In all cases, initiation of a cancellation should result in the cessation of processing and
clearing of any data elements.
If the transaction has not reached the point where an ARQC has been requested, the card
can simply be powered off. If an ARQC has been requested and the transaction has been
routed online, then cancellation processing should also generate an authorization reversal.
The transaction should simply be removed from the clearing batch or marked ‘void’.
If the device has received a TC or AAC from the card, the transaction is completed and can
now be cancelled (removed from the batch or marked as void).
It is recommended that the device produce a receipt for the cardholder showing that the
original transaction has been cancelled.
5.14.9 Cryptogram Generation in Multi-Currency Scenarios

Certain devices have dynamic currency conversion capabilities and as such are able to
handle multiple currencies. It is critical that the currency code used in the generation of the
cryptogram (ARQC or TC) is the same as is included in the authorization an clearing
messages (V.I.P. Field 148, EMV Tag 5F2A) and is not altered by any intermediary
networks. A change in the currency code could lead to the issuer declining the transaction
since the cryptogram validation will fail.
Visa Public Page 65

In most scenarios the transaction currency, V.I.P. Field 49, will contain the same value as
the chip data related currency in V.I.P. Field 148, EMV Tag 5F02. However there may be
instances where these differ. The critical aspect is that the chip related field is not
alternated from the currency used to generate the cryptogram.
5.15 EMV Transactions in Specific Industries

Certain industries have quite specific payment requirements besides the traditional
purchase. For each scenario, the presence of a chip card may or may not have an impact
to existing processing requirements. The following sections outline possible changes to
processing when a chip card is used.
Transactions using EMV functions must follow all relevant EMV requirements. If the
transaction is completed through extracting data from the chip (but not following EMV
payment transaction flow), the transaction is considered manually entered.
5.15.1 Hotels
The various activities relating to payments in the hotel industry should be treated as
follows:
 Reservations: This process will not normally involve the card being present or the chip
being read.
 No-shows: Charges for guaranteed reservations (no shows) should not be processed
as chip transactions unless an EMV transaction has been performed at the time of the
reservation.
 Check-in: A pre-authorization is completed at check-in to ensure the card and

cardholder are genuine and to guarantee the funds before the final transaction amount
is known. Market requirements will determine the estimated amount to be used. The
estimated amount should not be displayed to the cardholder to avoid confusion. The
estimated amount is the amount presented to the chip card. If online authorization is
required it is also the amount used to generate the ARQC and also send online in the
authorization message.
 Extended stay or higher than estimated spending: If the estimated amount used for the
pre-authorization is no longer sufficient to cover the estimated final bill, incremental
authorization should be performed. The card does not need to be present and the
authorizations should not include any chip data.
 Express Check-out: It is not necessary to perform a full EMV transaction once the final
transaction amount is known. A sale completion is generated for the final billing amount
and, if chip data is required for clearing, then the chip data from the original pre-
authorization should be included.
 Card present Check-Out: Either of the following two methods for card present check-
out are acceptable:
 A Sales Completion is generated for the final billing amount and, if possible, the
chip data from the original Pre-Authorization should be included (this is similar to
Express Check-Out)
Visa Public Page 66

 If the chip data from the pre-authorization cannot be retrieved and if the market
supports reversals, the recommended method is for the merchant to either
reverse the original pre-authorization and any incremental authorizations; or
alternatively the merchant performs a full EMV transaction (purchase) for the final
billing amount, presenting the data from this transaction in the clearing message.
In either case, the final total amount should be displayed to the cardholder.
 Additional charge after check-out: Any additional charges identified after check-out
should be processed as a separate card not present transaction. The chip data from
the pre-authorization should not be submitted in the clearing record.
Visa Public Page 67

5.15.2 Fuel/Petrol Dispensing

The various activities relating to payments in the fuel/petrol industry should be treated as
follows:
 Unattended petrol environment: For chip transactions it is recommended that a

status check transaction be completed before fuel is dispensed. The status check will
provide authorization protection up to the country limit.
 Pre-authorization: Where estimated authorizations are allowed, and if PIN entry is

required, it is best practice to display the maximum amount that may be dispensed
before the PIN is entered. The value confirmed by the cardholder should be the same
as the amount presented to the chip card and sent online for authorization. An
alternative is to display no amount and a message which reads Enter your PIN. The
maximum transaction amount should be presented to the chip card and sent online for
authorization.
 Sale Completion: When the transaction is completed, that is when the fuel dispensing
is completed, and the final transaction amount is known, a clearing record for the final
amount should be submitted containing the chip data from the pre-authorization.
Single-message environments may require an adjustment to the pre-authorization
amount, particularly if an estimate was used rather than a status check.
5.15.3 Mobile Top-Up

Mobile Top-Ups consist of a standard purchase transaction, sometimes followed by an
advice to the service operator indicating additional service has been purchased. An
example would be the purchase of additional minutes for a mobile phone at an unattended
acceptance device. Unless specifically requested by the service operator, the format of the
advice message should be unaffected by use of a chip card to complete the purchase.
If a top-up transaction is completed with card-on-file data, the transaction is considered

card not present. If the transaction is completed through extracting data from the chip (but
not following EMV payment transaction flow), the transaction is considered manually
entered.
NOTE: Only PAN and expiry date should be stored, never full track 2 data.
5.15.4 Forced Acceptance for On-Board Transactions

In some environments where online authorizations are not normally available, such as
aircrafts and ferries, an attended terminal may have functionality allowing an attendant to
override the decline (AAC) returned by the ICC if the terminal requests for an approval (TC)
during the 2nd Generate AC command. If this occurs, the merchant may put the AAC into
the clearing message to indicate that the transaction was declined by the chip (most likely
due to card's risk management settings). This process is also known as acquirer stand-in
as discussed in Section 5.12.2 Acquirer Stand-In.
Visa Public Page 68

In some situations merchants may need to obtain an authorization before submitting an

item for clearing (a deferred authorization). In this case the ARQC may be used later to
request an online authorization (for example, after the plane lands or the ferry docks), and
the approval code along with the ARQC may be put into the subsequent clearing message.
To reduce the risk of fraudulent transactions, it is recommended that an attendant force

acceptance only if Cardholder Verification and Offline Data Authentication are successful
as described in Section 5.12.4, Deferred Authorization.
5.15.5 Restaurants
Any gratuities (or tips) should be added to the transaction amount before the EMV
transaction starts and the final billing amount is presented to the cardholder during the
transaction and before the cardholder is asked to enter a PIN (if required).
Alternatively, a gratuity may be added after authorization, of up to 20% of the base

transaction amount, to the authorized amount prior to clearing. Vendors should consult with
their local Visa representative if there are local regulations which may prohibit or restrict
this.
5.16 Non-EMV Transactions using EMV Functionality

Non-EMV transactions using EMV functionality refer to transactions that are commonly
employed to support the retail or cash disbursement environment but do not directly result
in the purchase of goods or services or in the disbursement of cash. EMV functions that
extract information or request identification or authentication can be readily used to
complete these transactions.
EMV functions can be used for the following purposes:
 Information—To obtain information, a device can use the application selection, the
initiate application processing, and the read application data functions.
 Verification—To verify the identity of the cardholder, the device can use any of the
CVMs as defined in the CVM List.
 Authentication—To check the authenticity of the payment application, the device can
use the offline data authentication function as part of offline processing or allow the
issuer to validate the payment application using the ARQC as part of online processing.
(For example, by using Account Number Verification.)
 Card management—Issuer Script processing may be used for card management,

such as updating PINs.
Non-EMV transactions should be completed by an AAC. The only exceptions to this are
PIN change and PIN unblock transactions, which may result in a TC.
NOTE: An AAC generated for a non-EMV transaction simply indicates completion and is
not a decline.
Visa Public Page 69

Transactions using EMV functions must follow all relevant EMV requirements. EMV
functions should be executed in the same order as for EMV transactions, that is, non EMV
transactions using EMV functionality should follow the EMV transaction flow. If the
transaction is completed through extracting data from the chip (but not following EMV
payment transaction flow), the transaction is considered manually entered.
Refunds and balance inquiries are examples of a non-EMV transaction using EMV
functionality.
5.17 VEPS Transactions

Transactions that qualify under the VEPS program have specific requirements that device
vendors need to ensure they provide.
VEPS transactions must be online of offline authorized. Online transactions must contain a
valid authorization code while offline approved transactions must indicate offline approval
with an authorization response code of Y1 or Y3.
Chip data must be provided unaltered in the authorization message or in the clearing
message for offline approved transactions and identified by a POS Entry Mode 05.
Unless not allowed by country requirements, VEPS transactions do not require cardholder
verification. Device vendors and acquirers need to setup devices to only indicate support
for No CVM Required CVM on transactions equal or below to the VEPS country amount
limit. One option for managing this type of processing is via an EMV selectable kernel.
Certain countries which support chip and PIN terminal still require the use of a PIN for
VEPS transactions. Device vendors and acquirers should consult with their local Visa
representative on local requirements.
5.18 Lower Voltage Card Migration

The release of low-voltage and multi-voltage payment cards will have minimal impact on
the design of devices in the short term. The voltage of a device determines the voltage at
which a card must be able to operate. For example, 3-volt (V) cards must be able to
operate in 5V devices as well as 3V devices, such as cell phones and personal digital
assistants (PDAs).
Although cards supporting 5V, 3V, and 1.8V may be issued, cards supporting 5V and 3V
are readily available, and the initial focus will thus be to migrate all devices to support 5V
and 3V. Chip devices that only support 5V (or the 5V component of multi-voltage devices)
must continue to be type approved against the EMV specifications until all cards are
converted to 5V, 3V, and 1.8V.
At present all card acceptance devices need only support 5V cards. Devices supporting 3V
operation will be permitted beginning end of fourth quarter 2013. EMVCo does not have
any plans at this stage to phase out 5V only terminals.
For further information visit the EMVCo website.
Visa Public Page 70

Chapter 6 Contactless Acceptance

This chapter provides an overview of the requirements and recommendations for devices
that are compliant to VCPS and process Visa payWave transactions.
Visa offers two ways to conduct payment over the contactless interface:
 Magnetic stripe contactless payment (Magnetic Stripe Data, MSD)
 quick Visa Smart Debit/Credit (qVSDC).

The two approaches to contactless payment are briefly introduced in the following sections.
This chapter also describes the processing steps for a contactless transactions and Visa
recommendations relating to contactless readers (dongle, card reader or other terminal
device).
6.1 MSD
The MSD contactless transaction operates under magnetic stripe payment service rules
according to Visa Operating Principles and Regulations.
MSD offers a magnetic stripe payment service using Track 2 Equivalent Data acquired from
the chip (or Track 1 constructed from data acquired from the chip) over the contactless
interface.
MSD operates under magnetic stripe payment rules, and offers the following additional risk
management features:
 MSD Legacy offers the Dynamic Card Verification Value (dCVV), as defined by VCPS.
MSD Legacy is defined in this specification to support backwards compatibility with
VCPS 1.4.2 cards and readers.
 MSD CVN17 offers an EMV strength application cryptogram.

To meet the agreed requirements for global interoperability, the MSD path supports
Cryptogram Version Number 17. It has been agreed that a migration from dCVV to
Cryptogram Version Number 17 will take place for MSD readers, and that MSD readers will
support Cryptogram Version Number 17. An MSD market is not a full data market, and
Cryptogram Version Number 10 and Cryptogram Version Number 18 are not supported in
these markets.
While not EMV-compliant, MSD uses EMV methodology for selecting applications,
initializing transaction processing, and reading records to obtain the application data. MSD
uses a subset of EMV commands and requirements. MSD does not require that all
mandatory EMV data elements be present in the card.
NOTE: Magnetic Stripe Image (MSI) is sometimes confused with MSD. MSI is EMV-
compliant, and is the minimum implementation of VIS. MSI is not allowed as a
contactless magnetic stripe solution.
Visa Public Page 71

6.2 qVSDC
qVSDC is based on EMV concepts and uses the existing Visa systems and rules of
operation.
qVSDC reduces the reader to card processing time by minimizing the number of
commands and responses that must be exchanged between the reader and the card. It
offers an offline quick low value (LV) payment feature, offline data authentication, and
online card authentication using the current Cryptogram Version Number 10, the minimized
Cryptogram Version Number 17, or Cryptogram Version Number 18.
qVSDC uses the EMV methodology for selecting applications, initializing transaction
processing, and reading records to obtain the application data. qVSDC uses a subset of
EMV commands and requirements. The GET PROCESSING OPTIONS command
response uses EMV Format 2, but is not fully EMV-compliant because it does not always
contain the AFL.
qVSDC does not require that all mandatory EMV data elements be present in the card or if
present, that they be included in the card data that is read.
Streamlined qVSDC is a simplified, online-only version of qVSDC which eliminates some of

the internal card decision making steps. From the perspective of the device however, a
streamlined qVSDC transaction is similar to regular qVSDC and there are no additional
requirements.
6.2.1 Fast Dynamic Data Authentication (fDDA)

qVSDC offers support for Offline Data Authentication using fDDA and is compliant with
EMV in this processing, with the following exceptions:
 Generation of the dynamic signature is initiated by the GET PROCESSING OPTIONS

command. The INTERNAL AUTHENTICATE command is not used and no DDOL is
used.
 The results of fDDA are not provided online to the issuer within the TVR or protected by
the online authorization or clearing cryptograms.
Using card and reader dynamic data, fDDA validates that card data has not been
fraudulently altered and that the card is genuine and has not been created from skimmed
data. In addition to signing the (reader) Unpredictable Number, which is signed in most
EMV contact chip applications, fDDA also signs additional transaction dynamic data. The
Amount, Authorized, Transaction Currency Code, and (card) Unpredictable Number are all
signed using fDDA.
To optimize processing power and reduce transaction times, the fDDA dynamic signature is
generated during the GET PROCESSING OPTIONS command, rather than generating the
dynamic signature at the end of the transaction when the card may be moving away from
the reader Radio Frequency (RF) field.
Visa Public Page 72

6.3 Global Interoperability

Contactless global interoperability is achieved by requiring cards to support both MSD and
qVSDC, and readers to support either MSD or qVSDC. Specific regional requirements may
require support of both MSD and qVSDC in the reader.
Table 6-1 describes the possible scenarios for global interoperability for contactless cards
and readers.
Table 6-1: Summary of Possible Reader and Card interactions
Reader Configuration Card (supports qVSDC and MSD)
Method Selected
qVSDC-only qVSDC
MSD-only MSD
qVSDC and MSD qVSDC
6.4 Processing Overview

This section provides an overview of a VCPS transaction. Functions are mandatory unless
specified otherwise. Refer to VCPS document for further details. Figure 6-1 is a diagram of
a typical contactless transaction noting both MSD and qVSDC steps. Functions noted as
Conditional are functions that are followed if the various conditions relating to the function
are met. Functions that are noted as Optional are those which may be enabled at the
discretion of the acquirer or due to market requirements.
Visa Public Page 73

Figure 6-1: Sample Contactless Transaction Flow Diagram
6.4.1 Processing Prior to Enabling the Contactless Interface

To minimize the duration in which the card must remain within the reader RF field, the
reader may obtain the transaction amount and perform some risk management checks
prior to prompting for card presentment.
Reader processing is performed prior to powering on the contactless interface and

prompting for card presentment.
Visa Public Page 74

6.4.2 Discovery Processing

Discovery Processing is performed by the reader to poll for the presence of contactless
cards that may have entered the reader’s RF field.
6.4.3 Application Selection

Application Selection is performed immediately after activation of the contactless card, and
is the process of determining which of the applications that are supported by both the card
and reader will be used to conduct the transaction. This process is performed in two steps:
1. The reader builds a candidate list of mutually supported applications. This process is
modeled after the [EMV] Directory Selection Method, except that support for the
Directory Selection Method is mandatory for readers (and cards), and the Proximity
Payment Systems Environment (PPSE) is used in place of the Payment System
Environment (PSE).
2. A single application from the candidate list is identified and selected to process the
transaction.
The response message from the card includes the Processing Options Data Object List
(PDOL), to identify the reader data needed to perform Initiate Application Processing.
6.4.4 Initiate Application Processing

During Initiate Application Processing, the reader signals to the card that transaction
processing is beginning. The reader accomplishes this by sending the GET PROCESSING
OPTIONS command to the card. When issuing this command, the reader supplies the card
with any data elements requested by the card in the PDOL.
The contactless path(s) that are mutually supported by the card and reader are determined,
and a contactless path (qVSDC or MSD) is chosen to process the transaction. Subsequent
transaction processing is performed according to the requirements of the contactless path
chosen.
Initiate Application Processing is where the card performs Card Action Analysis,
(conditionally) generates the Application Cryptogram, (conditionally) generates the
signature for Offline Data Authentication, and returns card application data.
6.4.5 Read Application Data (Conditional)

Read Application Data is performed if the Application File Locator was returned by the card
during Initiate Application Processing.
During Read Application Data, the reader reads the remaining card application data
necessary to process the transaction. Note that in VCPS, the card may return application
data during Initiate Application Processing and Read Application Data.
Visa Public Page 75

6.4.6 Card Read Complete

During Card Read Complete, the reader indicates to the cardholder that exchange of data
between the reader and the card is complete, and the card may be removed from the
reader field.
The reader determines whether all mandatory data elements for the transaction were
returned by the card, and whether any redundant primitive data elements were returned by
the card. Primitive data elements are redundant if more than one occurrence of the
primitive data element was returned by the card during Initiate Application Processing and
Read Application Data.
The reader terminates the transaction if any mandatory data elements were not returned or
redundant primitive data elements were returned.
For MSD transactions, subsequent transaction processing is outside the scope of this
specification.
6.4.7 Processing Restrictions (Conditional)

Processing Restrictions is implemented for readers supporting any of the Processing
Restriction checks.
During Processing Restrictions, the reader checks the application expiration date,
application usage, and may check whether the card application is on the Terminal
Exception File.
6.4.8 Offline Data Authentication (Conditional)

Offline Data Authentication is implemented for readers supporting offline transactions, and
is performed for card requested offline transactions.
During Offline Data Authentication, the reader verifies the dynamic signature returned by
the card and authenticates the data from the card.
6.4.9 Cardholder Verification (Conditional)

Cardholder Verification is implemented for readers implementing qVSDC. During
Cardholder Verification, the reader determines the Cardholder Verification Method to be
performed (if any).
6.4.10 Online Processing (Conditional)

Online Processing is implemented for qVSDC readers supporting online transactions, as
well as MSD readers.
Visa Public Page 76

During Online Processing, the reader sends an authorization request to the issuer host.
Online Processing allows the issuer host to review and authorize or decline transactions
using the issuer’s host based risk management parameters. In addition to performing
traditional online fraud and credit checks, host authorization systems can perform online
card authentication using the card-generated cryptogram. The issuer may also perform
online card authentication with a Transaction Certificate type application cryptogram when
Offline Data Authentication has failed, an option that is configured by the issuer on their
cards.
6.4.11 Completion
Completion is performed by the reader to conclude transaction processing. The reader
indicates to the cardholder the outcome of the transaction.
6.4.12 Issuer Update Processing

Issuer Update Processing is an implementation and acquirer-merchant option for readers
implementing qVSDC. If supported by both card and reader, Issuer Update Processing is
performed when the authorization response message contains Issuer Authentication Data
and/or an Issuer Script Template.
NOTE: Issuer Update Processing is an optional feature that is not currently available.
During Issuer Update Processing, the card application may be updated by the issuer
through use of the EXTERNAL AUTHENTICATE command to perform issuer
authentication to (re)set risk management counters and indicators, and/or through the
application of issuer script commands.
The cardholder is instructed to present their card once more, and Issuer Update Processing
is performed to update risk management counters and indicators on the card, and/or to
update card data elements.
6.5 Reader Interface Guidelines

Since contactless cards are generally new to the market it is important that the process of
the cardholder presenting their card for use at the merchant is made as easy and intuitive
as possible. To avoid confusion is it also important to have a consistent way to inform the
cardholder about when and where to present their card and also when to remove it.
The sections below provide some best practices on how to design a reader user interface
that will provide a consistent consumer experience. Certain regions will also have specific
user interface requirements and it is important to contact the local Visa representatives to
confirm local or regional requirements in this regard.
The best practices outlined in this section are noted in greater detail in the Visa Contactless
Payment Specification – Use Interface Guidelines which is a licensed document which can
be obtained from Visa.
Visa Public Page 77

6.5.1 Contactless Transaction States

A contactless transaction will generally have six different states with regard to actual card
and reader interaction with each state having a unique attribute. These are summarized in
Table 6-2
Table 6-2: Contactless Transaction States
STATE NAME DESCRIPTION
Not Ready The reader may be powered up but it is not connected to a terminal. This
state applies to peripheral readers capable of two way communication with
a terminal.
Idle The reader is ready for use, its powered and connected (for peripheral
readers) but is not ready to initiate communication with the card.
Ready to Read The reader is attempting to initiate communication with the card. This
means the pre-processing stage has been finalized
(Present Card)
Processing Indicates that the reader is in the process of communicating with the card
that has been presented.
Card Read and Completed All application interaction between the card and reader has been
Successfully completed successfully. The card may be removed
(Remove Card)
Processing Error An unrecoverable error has occurred and the reader does not have
sufficient information to conduct a transaction
Depending on the requirements and nature of the implementation some readers, such as
for vending machines, there may be scenarios where some of the states are not required.
Similarly for scenarios where the transaction is very fast, such as in mass-transit
implementations, there may not be a need to display the Processing state to the cardholder
but move directly to the Remove Card state.
It is important that the Remove Card state is communicated to the cardholder as quickly as
possible, immediately after all the necessary card information has been received by the
reader. This ensures that the overall cardholder experience is a fast transaction which is a
key benefit of contactless.
6.5.2 User Interface Recommendations

Since contactless transactions are conducted primarily by the cardholder, the user interface
of contactless readers should provide an intuitive and natural way for cardholders to use
their card.
Visa’s recommendation is for contactless readers to have a visual indication and an audible
indication to assist the cardholder.
Visa Public Page 78

6.5.3 Visual Indication

The visual indication should consist of either a set of four clearly visual status indicators (for
example, LEDs) or a display (for example, LCD) that allows a graphical representation of
the four visual indicators. The visual indicators should represent the status of the
contactless payment application and should be clearly visible to the cardholder when the
card has been presented and the card read is in progress.
Regional requirements may specify the colors and other details regarding the visual
indicators and these should be confirmed with regional Visa representatives.
It is recommended that the cardholder interface contain both LEDs and a display but at
least one should be present on the Contactless Acceptance Device.
In the case where the display is being used to display the status indicators, it is
recommended that a minimum of three lines are present to allow the display of the status
indicators in the top line followed by two lines for cardholder messages.
As a minimum any display should be capable of displaying two lines of sixteen 8x5 dot
matrix low resolution characters.
Further details are specified in the Visa Contactless Payment Specification – User Interface
Guidelines. Additional regional requirements should also be consulted.
6.5.4 Audio Indication

There are in principle only two audio indications, a success tone and an alert tone. When
implemented, the reader (or terminal) should be capable of sounding tones at a level that
will be clearly audible in the intended operational environment, taking into account other
background noise in the intended operational environment.
6.5.5 Display Messages

The set of messages described in Table 6-3 may be used for the contactless interface and
may be used in the language preference of the cardholder of the reader.
Regional requirements may require different messaging and it is important to ensure

regional requirements are consulted prior to rolling out contactless readers.
Visa Public Page 79

Table 6-3: Contactless Display Messages
MESSAGE DEFINITION
PROCESSING ERROR Displayed when a generic non-recoverable error has occurred.
REMOVE CARD or Display prompts the cardholder to remove the card
PLEASE REMOVE CARD
WELCOME Used when the reader is in an idle state awaiting activation
PRESENT CARD This message is displayed when the reader has been activated
and is ready to communicate with a card
PROCESSING Displayed when the transactions is being processed
CARD READ OK Displayed when the reader has read all necessary information
and the card can be removed
PLEASE REMOVE CARD
PLEASE INSERT OR SWIPE CARD This message may be used when the conditions for a contactless
transaction are not satisfied and the transaction needs to be
continued using a contact chip or magnetic stripe interface
PLEASE PRESENT ONE CARD ONLY Displayed in the case when the reader has detected more than
one card
6.6 VCPS Processing for Industry Specific Transactions

The following sections provide some guidelines and best practices on how to handle
specific industry transaction scenarios where a contactless card is used at a contactless
device. Appendix E provides data mapping information between the EMV data elements
mentioned in these sections and the VisaNet (V.I.P. and BASE II) messages
6.6.1 Pre-Authorizations
If an authorization takes place before the final amount is determined, then it is known as a
pre-authorization; pre-authorizations are subject to scheme rules but normally will be VCPS
transactions. The amount presented to the card in the GET PROCESSING OPTIONS
command of a pre-authorization should be an estimated amount and should be the same
amount and currency that is sent to the card Issuer in the authorization request message (if
required). MSD merchants may present a zero for the Cryptogram Amount, while using the
estimated amount in the authorization message itself. Note that in unattended
environments, this estimated amount is likely to be the maximum dispensable value of
goods or services.
Visa Public Page 80

The Pre-Authorization process will perform all the VCPS functions and the online request
message (if generated) should contain all the appropriate contactless chip data elements.
The card and device interact in an identical fashion to the Purchase process, including
CVM processing. The appropriate contactless chip data elements from both the Pre-
Authorization request and response should be retained for the Sale Completion transaction.
These elements include the TC or ARQC. The full track 2 data should not be retained (in
line with Payment Card Industry Data Security Standard (PCI DSS)) but the PAN and
expiry date will be required. If a pre-authorization is performed without the card being
present the introduction of VCPS has no impact and existing practices should continue.
6.6.2 Sale Completion

A Sale Completion is the financial settlement of a previously pre-authorized transaction,
often where the cardholder and card are no longer present.
The final transaction amount may differ from the pre-authorized amount, usually within a
range defined by the market. The retained contactless chip data elements from the
associated Pre-Authorization transaction, including all fields needed to validate the
cryptogram, should be populated into the clearing message. It is recommended that the
authorization approval code from the original pre-authorization response message (as
opposed to those obtained from incremental authorizations) be used in this message as
this code will generally be for the highest value.
The Sale Completion will contain an ARQC for online approved transactions or a TC for
offline approved transactions.
NOTE: In a few circumstances, a transaction will be forced online after a TC was

generated. If the transaction is subsequently approved, the TC is used for clearing
6.6.3 Status Check and Account Number Verification

In a card present environment, VCPS functions such as Offline Data Authentication (fDDA,
if supported by the card application) can be used to validate a card against the possibility of
counterfeit. However, offline validation will not protect against lost and stolen, nor can it
ensure that funds are available.
Status Checks have traditionally also been used to validate that the card used to make a
reservation, or to pay for goods in advance of delivery, is authentic. In a card present
environment, VCPS functions such as Offline Data Authentication (fDDA, if supported by
the card application) should be sufficient to ensure a card is not counterfeit – that is, a non-
VCPS transaction should be used and a status check may no longer be necessary. Except
where specifically allowed, if an online validation is desired, an Account Number
Verification transaction should be used, rather than a status check.
6.6.4 Refunds
The recommended method for performing a contactless refund is to start a contactless
transaction and follow the normal VCPS transaction flow in order to obtain the Track 2
Equivalent Data field from the contactless chip. An ARQC should be requested.
Visa Public Page 81

MSD merchants may present a zero for the Cryptogram Amount, while qVSDC merchants
should use the refund amount. If the PDOL indicates that the transaction type is to be
included in the GET PROCESING OPTIONS command, the terminal should send the
transaction type as '20'.
Once the terminal has read the Track 2 Equivalent Data information from the contactless
chip, the subsequent decision of the contactless chip to approve or decline the transaction
is not relevant. Therefore, merchant systems should be able to process the refund
irrespective of the cryptogram produced by the card (ARQC or AAC). The decision to
approve or decline the refund should be made by the acquirer or merchant in the same way
as for magnetic stripe.
If an attempted contactless refund fails (for example, if the contactless chip cannot be read
or contactless technology fails at some point in the transaction), the merchant should re-
initiate the refund transaction either by using the magnetic stripe or by using PAN Key
Entry.
6.6.5 Reversals
Reversals are a function of the transaction network or of the device application and do not
require interaction with the card for generation of the reversal message itself.
The authorization reversal is an online message indicating the amount (the difference
between the authorized amount and the dispensed amount) that is to be credited back to
the cardholder’s account. No contactless chip data needs to be included in the
authorization reversal.
In the settlement message, the cryptogram amount should contain the original estimated
authorization amount, while the transaction amount should reflect the dispensed goods
amount. In a single-message system, the original transaction will contain the estimated
amount and the contactless chip data (including ARQC)
6.6.6 Cancellations
Cancellations may occur when a purchase or sale completion is aborted during processing
or after processing and may occur due to a number of reasons. In all cases, initiation of a
cancellation should result in the cessation of processing and clearing of any data elements.
If the transaction has not reached the point where an application cryptogram has been
requested, the card reader can simply be powered off.
If an ARQC has been requested and the transaction has been routed on-line, then
cancellation processing should also generate an authorization reversal. The transaction
should simply be removed from the clearing batch or marked void.
If the device has received a TC or AAC from the card, the transaction is completed and can
now be cancelled (removed from the batch or marked as void).
Visa recommends that the device produce a receipt for the cardholder showing that the
original transaction has been cancelled.
Visa Public Page 82

6.6.7 Referrals
A referral is intended as a fraud control tool for Issuers to use when more information is
needed to verify the identity of the cardholder prior to approving a transaction. A Referral is
not a transaction; it is an exception process for purchase.
Depending on the market’s implementation, the referral process will either result in
production of a clearing record linked to the original authorization (in which the ARQC and
related data of that authorization should be included), or more likely will result in a
completely new transaction taking place.
6.6.8 VCPS Transactions using Magnetic-Stripe Data

payWave transactions performed as defined in the VCPS 1.4.2 specifications are referred
to as MSD Legacy transactions. MSD Legacy transactions are processed identically to
magnetic-stripe-read transactions, with the exception that the POS Entry Mode is set to 91,
and the Terminal Capability Indicator is set to 5 (contact support, may support contactless)
or 8 (supports contactless, does not support contact). All other data and processing is
identical to magnetic-stripe read.
NOTE: VCPS 2.x products may perform MSD Legacy transactions to be backwards
compatible with VCPS 1.4.2 products that are already deployed or issued.
6.6.9 Non-VPCS Transactions Using VCPS Functionality

Similar to contact chip and EMV, it is possible to use VCPS functionality to undertake non-
VCPS transactions. These transactions will use the VCPS functionality to obtain
information from the card (such as the card number) and to also verify the validity of the
card for identification purposes.
Various VCPS functions can be used in this case including Application Selection, Initiate
Application Processing, Read Application Data, Online Processing and Issuer Update
Processing.
Transaction Amounts for these transactions should be set to zero and there are no clearing
records. Non-VCPS transactions using VCPS functionality should follow the VCPS
transaction flow and follow all relevant VCPS requirements.
POS balance enquiries and POS deposits are examples of non-VCPS transactions using
VCPS functionality.
6.7 Other Processing Considerations for VCPS

The following sections address other processing considerations for VCPS.
6.7.1 Forcing a CVM

Where a POS device is allowed to force a particular CVM method, such as for unattended
Cardholder Activated Terminals using a PIN or POS devices in a small ticket program, the
device will need to ensure the card does not unnecessarily reject the transaction.
Visa Public Page 83

This can be accomplished by indicating in byte 1 of the Terminal Transaction Qualifiers

(TTQ) that both Online PIN and Signature is supported, and in byte 2 that CVM is not
required. A new setting in byte 3 of the TTQ should also indicate that the contactless reader
can accept a Consumer Device CVM.
The VCPS specifications provide more detail on the use of the TTQ.
6.7.2 Premature Card Removal

If the card is removed before the transaction is complete (i.e., the transaction has not
reached Card Read Complete step), then the current transaction data is discarded and the
reader returns to Discovery Processing.
6.7.3 Gratuities
It is recommended that any gratuity is added to the transaction amount before the VCPS
transaction starts. This will ensure that the final billing amount is both presented to the card
during the transaction and displayed to the cardholder at the time of PIN entry (if required).
6.7.4 Placement of Contactless Readers

Visa has developed a set of recommendations as general guidance for the placement of
contactless card reading devices in a merchant retail environment. They are intended to
provide guidance to expedite contactless card reader integration into a merchant POS
environment and ensure efficient operation. Refer to Appendix F, Placement of Contactless
readers for more details.
6.7.5 VEPS Transactions

Transactions that qualify under the VEPS program have specific requirements that device
vendors need to ensure they provide.
VEPS transactions must be online of offline authorized. Online transactions must contain a
valid authorization code while offline approved transactions must indicate offline approval
with an authorization response code of Y1 or Y3.
Chip data must be provided unaltered in the authorization message or in the clearing
message for offline approved transactions and identified by a POS Entry Mode 07 (for
qVSDC) or POS Entry Mode 91 (for MSD).
For MSD transactions where the transaction is equal or below VEPS limit, the device
should bypass cardholder verification and complete the transaction without a CVM.
For qVSDC transactions in countries where the VEPS limit is the same as the Visa
payWave CVM limit, the acquirer should configure the qVSDC Reader CVM Limit so that all
qVSDC transactions (domestic and international) equal or below the VEPS limit are
processed as VEPS without the need for cardholder verification and receipt (unless
requested by the cardholder).
A similar approach can be taken for qVSDC transactions where the local Visa payWave
CVM limit is higher than the VEPS limit.
Visa Public Page 84

Alternatively acquirers may configure the reader with two Reader CVM limits, one for
domestic transactions that is set to be the same as the Visa payWave CVM limit and
another for international transactions that is configured so that international qVSDC
transactions equal to or below the VEPS limit are processed as VEPS transactions without
the need for cardholder verification and receipt (unless requested by the cardholder).
Device vendors and acquirers should consult with their local Visa representative for the
best approach in their region.
Visa Public Page 85

Chapter 7 Security Characteristics

This chapter provides an overview of security requirements for PIN entry devices (PEDs)
and key management. Devices must be able to ensure the security of sensitive data, such
as cardholder PINs and secret keys for symmetric algorithms, and to ensure the integrity of
public keys for asymmetric algorithms.
Appendix B, Transaction Acceptance Device Requirements, contains Visa’s requirements

for PIN entry. For more information on security characteristics and requirements, see
www.visa.com/pinsecurity and www.pcisecuritystandards.org
7.1 Cardholder Verification Methods

The CVMs that may be supported by a card device are:
 Signature (magnetic stripe, contact chip and contactless chip)
 Offline plaintext PIN (contact chip only)
 Offline enciphered PIN (contact chip only)
 Offline plaintext PIN and signature (contact chip only)
 Offline enciphered PIN and signature (contact chip only)
 Online PIN (magnetic stripe, contact chip and contactless chip)
 No CVM Required (magnetic stripe, contact chip and contactless chip)

Cards and devices may also agree on a higher level of CVM than the minimum. The Visa
Operating Regulations concerning the level of cardholder verification required for certain
types of transactions (for example, manual cash or quasi-cash) apply regardless of whether
the transaction is initiated from a chip or magnetic stripe.
The Visa Operating Regulations allow some transactions to be performed without

cardholder verification under certain conditions. This includes Visa payWave transactions
where depending on local requirements, a CVM may not be required at al or only required
for transactions above certain locally agreed limit.
Transactions under the VEPS program can also be performed without the need for
cardholder verification. Merchants that qualify to participate in VEPS need to take steps to
ensure their terminal do not request a cardholder verification method (i.e. signature or PIN)
for qualifying transactions.
Visa Public Page 86

7.2 Signature
All attended devices must support signature. Where a PIN has not been entered, the
device must print a receipt with a line for the cardholder’s signature, unless the Visa
Operating Regulations allow an exception, such as for VEPS transactions. Alternatively
devices may allow for an electronic signature to be collected (using a touch screen and a
pen-like device or stylus to write the signature) if allowed by local regulations and Visa
operating rules. The merchant is required to compare the signature on the receipt with that
on the signature panel of the card. If the two signatures match, the cardholder’s identity has
been correctly verified.
NOTE: A contact chip card may require both PIN and signature for a given transaction.
If the transaction is verified and approved via a PIN, the terminal should print “Verified by
PIN” or “PIN Verified” in place of the signature line. However in the instance where the
selected CVM is a combination of offline PIN and signature, the device may print in addition
to the PIN verification message a signature line for the cardholder’s signature. Alternative
the merchant may collect the signature anywhere on the receipt.
7.3 Personal Identification Number

PIN verification is performed by verifying the PIN entered at the point of transaction, either
online by the issuer or offline using a chip card.
When the PIN is to be verified online, the PIN is entered, encrypted, transmitted, translated,
and verified against reference PIN data available in the issuer’s processing center. If the
PINs match, the cardholder’s identity has been correctly verified.
When the PIN is to be verified offline, the PIN that is entered is compared to the reference
PIN stored on the card’s chip. If the two PINs match, the cardholder’s identity has been
correctly verified.
Certain markets allow the merchant or cardholder to direct the terminal to bypass PIN
entry. Depending on the issuer settings in the chip card, the cardholder will be prompted to
provide another form of verification, generally signature or the transaction may be declined.
The PIN requirements in this chapter apply only to VisaNet interchange transactions. Client
financial institutions may develop and comply with their own standards for PINs used in On-
Us transactions.
NOTE: Chip devices must use the PAN received from the chip application and not that
encoded on the magnetic stripe when building PIN blocks.
Sections 7.3.1 through 7.3.3 discuss requirements for PIN length and character set and
online and offline PINs verification.
7.3.1 PIN Length and Character Set

The minimum PIN length is 4 digits. ATMs and POS PEDs must be able to accept online
PINs of 46 digits. An ATM acquirer conducting business in the U.S.A. must be able to
accept and transmit online PINs that are 412 digits long.
Visa Public Page 87

PEDs may visually indicate that a digit has been entered, such as with an asterisk (*). This
visual indication should occur for each digit entered by the cardholder. For example, a PED
should not display only four asterisks when six digits have been entered. Similarly, if
audible tones are used, the tone should be generated each time that a digit is entered. The
PIN character set is 09.
7.3.2 Online PIN

For devices such as ATMs and POS devices where online PIN is supported, the PIN must
be protected immediately upon entry by encryption in accordance to ISO 9564 and must be
processed as specified in the Visa PCI PIN Security Requirements manual and protected
as specified in the PCI PTS POI Modular Security Requirements.
Online PIN entry may occur at any point in the user interface flow prior to online
processing; the encrypted PIN may remain in the encrypting PIN pad (EPP) until needed
for online processing.
Devices that support online PIN entry should be constructed so that any tampering with the
device stops it from working.
The process of entering an online PIN is outside the scope of EMV processing. The use of
a CVM that is not required by the card but is required by the Visa Operating Regulations
should have no effect on the TVR. If the result of CVM List processing is “Cardholder
verification was not successful”, the corresponding bit should still be set in the TVR.
Similarly, the “Online PIN entered” bit should not be set even when Visa Operating
Regulations require that an online PIN be requested. For example, an ATM always
requests an online PIN regardless of CVM List preferences.
When a device indicates that it is PIN capable, this refers to online PIN capability for Visa
products. If a device supports only offline PIN or supports only online PIN for a domestic
payment scheme, the device should not define itself as PIN capable.
NOTE: Unless the device is capable of supporting online PIN for a Visa transaction, V.I.P.
Field 22, Position 3 (PIN Entry Capability), in the VisaNet authorization message should
be set to indicate that the device cannot accept and forward a PIN. This is also relevant
to Service Code processing as discussed in Section 4.3, Service Codes
7.3.3 Offline PIN

When a device supports offline PIN verification, a cardholder-entered PIN is compared to a
reference PIN stored in a secure location on the card’s chip, which then returns a pass or
fail indicator to the device. This indicator is one of many used to determine whether the
transaction can be approved or declined offline or must be sent online for authorization.
The offline PIN must be processed as specified in the EMV specifications and the Visa PCI
PIN Security Requirements manual and protected as specified in the PCI PTS POI Modular
Security Requirements.
Visa Public Page 88

Offline PIN verification may occur in one of two ways:
 Plaintext offline PIN—The chip reader sends the PIN to the chip as plaintext.
 Enciphered offline PIN—Either the secure component in the device (for example, the
chip reader) or the PIN pad itself enciphers the PIN, using an authenticated encryption
public key from the chip. The enciphered PIN is sent to the chip, where the PIN is
deciphered using the private key from the chip.
The EPP and the chip reader are either integrated into a single device or configured as two
separate devices, (for example, using an external EPP). In addition, depending on device
design, the PIN entered may either travel directly from the EPP to the chip reader within a
secure environment or travel indirectly (via a tethered cable if some distance is involved) to
the chip reader.
When the EPP and the chip reader are integrated and the PIN travels directly from the EPP
to the reader within a protected environment as defined in ISO 9564-1, the PIN does not
need to be encrypted at the point of entry.
When the environment from the PIN pad to the chip reader is unprotected (for example, via
a tethered cable or a lengthy travel path), the EPP must immediately either encrypt the PIN
at the point of entry using a Triple Data Encryption Standard (TDES) key or encipher the
PIN using an appropriate RSA public key from the chip, before sending the PIN to the chip
reader. This allows protection of the PIN during transport.
For offline plaintext PIN, the EPP encrypts the entered PIN using TDES, sends the
encrypted PIN to the chip reader, which decrypts the encrypted PIN and sends the PIN to
the chip as plaintext.
For offline enciphered PIN, one of two situations occurs.
 The chip reader extracts the ICC public key and sends it to the EPP. The EPP
enciphers the entered PIN using the RSA public key and sends the enciphered PIN to
the chip reader. The chip reader sends the RSA-enciphered PIN to the chip.
 The EPP encrypts the entered PIN using TDES and sends the encrypted PIN to the
chip reader. The chip reader decrypts the encrypted PIN using TDES and then
enciphers it using the appropriate RSA public key from the chip.
All contact chip devices placed in service that support offline enciphered PIN must also
support offline plaintext PIN. It is strongly recommended that devices supporting offline PIN
support both plaintext and offline enciphered PIN.
Offline PIN is not allowed for ATMs, which must support and transmit only online PINs.
7.3.4 PIN Entry Bypass

If a PIN is required for entry as indicated in the card‘s CVM List, an attended POS device
with an operational PIN pad may have the capability to bypass PIN entry before or after
several unsuccessful PIN tries. This prevents a genuine cardholder who does not
remember the PIN from having to keep entering incorrect PINs until the PIN is blocked in
order to continue with the transaction.
Visa Public Page 89

If this occurs, the device shall consider this CVM unsuccessful, and shall continue
cardholder verification processing in accordance with the card‘s CVM List.
When PIN entry has been bypassed for one PIN-related CVM, it may be considered
bypassed for any subsequent PIN-related CVM during the current transaction.
It should be noted that certain countries do not allow PIN bypass and device vendors
should ensure their devices comply with local requirements.
7.4 Requirements for Cardholder Verification Methods

Visa CVM requirements for the devices discussed in this document are as follows:
 An attended POS device must support signature. It may support online PIN, offline
plaintext PIN, offline enciphered PIN, and combination CVMs. An attended POS
contact chip device must support No CVM Required, if no other CVMs are supported.
An attended POS magnetic stripe device may support No CVM Required under certain
circumstances for magnetic stripe transactions, (for example, small ticket transactions).
 An ATM must support online PIN as it’s only CVM.
 A UCAT must support No CVM Required, unless it requires PIN for all transactions.
 A UCAT may support PIN for all transactions. For a chip transaction, the PIN supported
may be online PIN, offline plaintext PIN, or offline enciphered PIN. For a magnetic
stripe transaction, the PIN must be the online PIN. All other CVMs are not applicable
for these transactions.
NOTE: Support for offline enciphered PIN requires that the device also support offline
plaintext PIN. Some countries require support for both types of offline PIN.
 Support for PIN bypass at attended POS devices is optional and is dependent on
market requirements.
7.5 PIN Entry Devices

A PED is any device used by a cardholder to enter a PIN. It may have other functions. For
a contact chip device, it may contain an EMV kernel.
If a device is configured with an external PED, the application needs to ensure that the
PED is always connected to the device and is functional. The application must detect
detachment or failure of the PIN functionality in the external device and respond
appropriately.
A PED that supports online PIN, offline encrypted PIN, or offline plaintext PIN where the
PED and chip reader are not integrated must contain an Encrypting PIN PAD (EPP) used
for entering a cardholder PIN. The PED and EPP may be integrated, as in some
standalone POS devices, or the EPP may be just one component of a PED, as in an ATM.
Sections 7.5.1 through 7.5.3 discuss the keyboard layout for PIN pads, chip-reading device
requirements for PEDs, and PED testing requirements.
Visa Public Page 90

7.5.1 Keyboard Layout

An ATM keyboard should conform to the numeric layout shown in Figure 6-1. When Roman
characters are used, the alphabetic character layout is recommended because cardholders
may use alphabetic characters as an aid to remembering the PIN.
Figure 7-1: ATM Keyboard Layout
The POS PINpad’s numeric layout should conform to the layout illustrated in Figure 6-2.
The words “Clear” and “Enter” can be stated in the local language. The alphabetic
characters are recommended but not required. Visa recommends using yellow for the
Clear key and green for the Enter key.
Figure 6-2: POS PIN Pad Layout
Visa Public Page 91

7.5.2 Chip-Reading Device Requirements for PEDs

Contact chip devices should be capable of accepting a PIN for verification of Visa
transactions. At a minimum, chip devices must be equipped with a port that can support a
PED if the devices do not have a PED present.
If a PED is present and active, the chip device must use a PIN pad that meets Visa
requirements. It must also act on the CVM List, except as specified in the Visa Operating
Regulations.
Support for PIN may not be required in situations where interaction between a device and
cardholder is inherently impractical, (for example, road tolls and transit applications). Some
countries may have other specific exceptions. For information on exceptions in a specific
country, contact the appropriate regional Visa representative.
If the design of the device requires that parts of the device be physically separated, (for
example, the PED is not integrated into the device) and any cardholder instructions or
processing data pass between the separate parts, there must be equal levels of protection
between the different parts that make up the device.
When a device has a PIN pad that is not used for chip transactions (for example, if it
processes only magnetic-stripe-based domestic debit transactions), the EMV Terminal
Capabilities data element should indicate that the device does not support offline or online
PIN.
7.5.3 PED Testing Requirements

Visa requires testing of PEDs against the PCI PIN Transaction Security (PTS) security
requirements if they are used in the acceptance of Visa card products with offline PIN or
online PIN verification. PEDs and EPPs must undergo a physical and logical security
evaluation performed at a PCI recognized test laboratory.
For information on PCI PIN entry device security requirements, see www.visa.com/PIN and
www.pcisecuritystandards.org/security_standards/ped
7.6 Key Management

Key management plays an essential role in integrating the components of a working
security architecture. It provides critical security support to ensure the integrity of all
cryptographic processes involved in card life cycle and transaction processing. The security
of data is dependent upon the prevention of disclosure and unauthorized modification,
substitution, insertion, or deletion of keys.
Key management requirements are described in the Visa PCI PIN Security Requirements.
Sections 7.6.1 through 7.6.9 describe the symmetric and asymmetric key management
requirements, the management of Visa Smart Debit/Credit (VSDC) Certification Authority
(CA) Public Keys, and Issuer and ICC keys.
Visa Public Page 92

7.6.1 Symmetric Key Management

PIN confidentiality depends on the implementation of adequate PIN security standards. To
this end, ANSI, ISO, and Visa require migration from the DES algorithm using single length
keys to the TDES algorithm using at least double-length keys.
TDES support is required for any device supporting online PIN as well as for any device
that uses DES encryption to transport a plaintext offline PIN from the PIN pad to the card
reader. As of July 2010 Visa requires that all online PINs (and offline where applicable) be
protected with TDES.
7.6.2 Asymmetric Key Management

It is the acquirer’s responsibility to ensure that VSDC CA Public Keys are loaded or deleted
from devices that support SDA, DDA, CDA, or offline enciphered PIN according to annually
published Visa schedules.
To ensure sufficient levels of support for RSA key backup, key recovery, and key migration,
offline-capable devices must be capable of securely storing six VSDC CA Public Keys and
their associated data elements. A device should enable the secure loading, updating, and
maintenance of the VSDC CA Public Keys. In this context, secure means that the keys
should be protected from unauthorized modification.
While key lengths can be up to 1984 bits, the currently implemented lengths can be found
on the EMVCo website at www.emvco.com. Any participating payment scheme can have
six public keys in force at any time; consequently, devices must have six slots per payment
scheme for keys.
A device must be able to select the corresponding key and algorithm in conjunction with the
RID of the selected application. Planned updates and accelerated key revocations require
that keys be updated in all devices. Post-deployment data integrity must be verified.
Devices must comply with the Visa and EMV requirements for withdrawal and introduction
of the VSDC CA Public Keys.
7.6.3 Obtaining VSDC CA Public Keys

The VSDC CA Public Keys are available for public download from Visa’s website,
www.visa.com/pubkeys. The website contains the VSDC CA Public Keys via a link to an
Adobe format (PDF) document.
Before an acquirer relies on the downloaded information (for example, by loading it onto the
device population), it should check the information with a secondary source. Acquirers may
contact their Visa regional office and request that they send a fax (not e mail) with either
the full VSDC CA Public Keys or a SHA-1 hash of each key.
Another secondary source is Visa Smart Debit/Credit Certification Authority Technical

Requirements. This document contains the current VSDC CA Public Keys, including a
SHA-1 hash digest of each key, and explains how to validate the VSDC CA Public Keys
against a secondary source.
Validating the VSDC CA Public Keys against a secondary source is essential to counter the
risk of the Visa website (or the particular page with the VSDC CA Public Keys) being
compromised (hacked) while an acquirer downloads the keys.
Visa Public Page 93

The acquirer can also use the checks to verify the continued integrity of the VSDC CA
Public Keys while they are stored with the acquirer.
7.6.4 Loading VSDC CA Public Keys

Visa does not mandate specific loading processes for the VSDC CA Public Keys and their
associated data. EMV specifications, however, provide some guidelines on this process.
7.6.5 Removal of VSDC CA Public Keys

Visa, in coordination with other EMVCo payment associations, revokes older keys; that is,
Visa stops creating issuer certificates with them. When all the issuer certificates created
with the revoked root key have expired, the root key is removed from all devices globally.
Acquirers and device vendors should also ensure that any test keys that may have been
loaded to undertake testing prior to production rollout are removed from the device.
7.6.6 Expired VSDC CA Public Keys

Based on developments at EMVCo, Visa periodically reviews and determines the expiration
dates of the VSDC CA Public Keys. Acquirers’ key management must support removal of
expired keys from their devices based on the expiration and removal dates.
A Visa International Member Letter or Visa Business Review is sent to acquirers advising
them of the planned expiration and removal dates. Generally, an 18 month grace period is
provided to assist acquirers in these efforts.
7.6.7 Revoked VSDC CA Public Keys

Visa analyzes and determines if an accelerated or emergency key revocation is required
due to public key attacks. Should this occur, clients are advised of Visa’s findings and
associated procedures. For more information, refer to the EMV specifications.
7.6.8 Managing VSDC CA Public Keys Distribution

To ensure the integrity of the VSDC CA Public Keys as acquirers are distributing them to
their deployed device base, Visa has established the following principles:
 If the keys are being distributed across a communication channel that is not under the
control of an acquirer, the receiving device should be able to authenticate the
communication originating from the acquirer.
Comment: A merchant is considered an authorized agent of the acquirer. Keys distributed
from a point under control of a merchant and across a network managed by the merchant
could eliminate need for authentication of the distribution point. The original communication
from the acquirer to the merchant distribution point, however, should include an
authentication process.
Visa Public Page 94

Devices not on privately managed networks should perform some kind of authentication.
For example, manually updated devices require log in; remotely managed devices need to
validate the device management system. This could be done with a cryptographic
challenge or any reasonable validation method. The proprietary nature of device
management systems and devices will likely result in the use of proprietary validation
systems.
Any time that a key is distributed across an uncontrolled channel when it is not possible to
authenticate the acquirer or authorized agent, it should be validated against an alternate
channel.
Comment: Recipients should always double check the key against a secondary source.
 Valid keys should be delivered to the device in a manner that protects their integrity.
NOTE: The primary purpose of this principle is to ensure that keys are not corrupted or
modified during delivery and to ensure that their integrity is maintained. For example, the
device could validate the key by checking a hash generated from the key such as SHA-1.
Alternatively, the device management system could do the integrity validation using its
own validation technique such as check sum as long as the device management system
completely controls the software updates to the device.
 Ensure that new keys are loaded prior to the effective date.
NOTE: All deployed devices should have new keys prior to cards being circulated. A
manual or automated procedure should be in place to begin deployment of keys in
sufficient time to ensure that all deployed devices accept new cards as they are issued.
 Ensure that expired or revoked keys are removed or disabled within 18 months of
expiration or revocation.
NOTE: As above, a manual or automated procedure should be in place to ensure that all
keys are removed or disabled within 18 months of the expiration date.
 Within a reasonable timeframe, acquirers should be able to determine which VSDC CA

Public Keys are active in each of their devices.
NOTE: Acquirers should be able to report on the status of their installed device base to
assure issuers that cards with new key lengths are accepted and to protect against
attacks based on devices whose expired or revoked keys have not been removed. Visa
strongly recommends that the process be automated.
7.6.9 Issuer and ICC Keys

Issuer and ICC keys, extracted during offline data authentication and enciphered offline PIN
processing, may have lengths up to 1984 bits. Devices must be able to support issuer and
ICC keys that are not based on 8-bit boundaries.
Visa Public Page 95

7.7 Data Security

This section describes the industry security standards for cardholder data and payment
application data.
7.7.1 Cardholder Data Security

When customers offer their cards at the point of service, they want assurance that their
account information is safe. Cardholder data must be protected wherever it resides.
The Payment Card Industry Data Security Standard (PCI DSS) resulted from a cooperative
effort among Visa, MasterCard, American Express, Discover, and JCB to offer a single
approach to safeguarding sensitive data for all card brands. The PCI Security Standards
Council (PCI SSC) owns, maintains, and distributes the PCI Data Security Standard (DSS)
and all its supporting documents. Compliance with the PCI DSS is validated under two
programs: the Cardholder Information Security Program (CISP) for U.S.A.-based entities
(www.visa.com/cisp) and the Account Information Security (AIS) for non-U.S.A.-based
entities. Visa Europe entities can find more information at http://www.visaeurope.com/
aboutvisa/security/ais/, while other non-U.S.A.-based entities can access
http://corporate.visa.com/st/.
It is a requirement of Visa acquirers that they must ensure the compliance of their
merchants and service providers to the PCI standards where they may store, process or
transmit Visa account numbers.
More information can be found at https://www.pcisecuritystandards.org/security_standards/.
7.7.2 Payment Application Data Security

Payment applications must not retain full magnetic stripe data, Card Verification Value
(CVV), Card Verification Value 2 (CVV2), or PIN data and must support a merchant's and
agent’s ability to comply with the PCI DSS. Merchants and agents using vulnerable
payment applications are at heightened risk of compromise attacks. The PCI SSC adopted
Visa’s PCI Payment Application Best Practices and released the standard in April 2008 as
the Payment Application Data Security Standard (PA-DSS).
Visa has introduced compliance mandates for PA-DSS requiring all new merchants to use
payment application software that uses PA-DSS compliant applications or be PCI-DSS
compliant by 1 July 2010. Acquirers must also ensure that their merchants and agents use
PA-DSS compliant payment applications by 1 July 2012. For purposes of the mandates,
payment applications apply only to third-party payment application software that stores,
processes or transmits cardholder data as part of an authorization or settlement of a
payment card transaction. POS devices are an example of this. PA-DSS does not apply to
merchant or agent in-house developed applications, stand-alone hardware terminals or
PEDs. Payment application vendors must validate the conformance of their products to the
PA-DSS. Acquirers should insist that their merchants and agents use compliant
applications and upgrade or patch applications that cause the storage of sensitive
cardholder data to meet the Visa mandates.
More information can be found at www.visa.com and

https://www.pcisecuritystandards.org/security_standards/.
Visa Public Page 96

7.8 Card Verification Value 2

The CVV2 is a card verification tool designed to reduce fraud losses on transactions. It
consists of three digits printed either on the signature panel or on the card to the right of the
signature panel.
Although CVV2 is primarily used for card not present transactions (for example, mail order,
telephone order, electronic commerce), in some countries the CVV2 is also used in card-
present transactions.
Visa Public Page 97

Chapter 8 Device Management Systems

This chapter provides recommended functions to be supported by a device management
system in a chip environment. Device management system architecture should be
sophisticated and flexible enough so that modifications can be made without requiring large
device infrastructure changes. The more supportive and robust a device management
system is, the easier it is to respond to future market needs, new requirements, and the
inevitable change requests.
8.1 EMV Functions

Once a device is deployed, acquirers must not be able to change EMV functionality by
setting or resetting parameters in non-EMV applications. Most EMV functions are
mandatory, and any post-deployment change could affect a device’s interoperability.
The device management system of a device must not allow deletion of mandatory
functions. The system may add or delete optional functions provided that the final
configuration loaded into the device has been EMV-approved.
8.2 Data Elements

Although a complete device management system uses many data elements, only those
that are new for contact chip devices are discussed here. As specified in the Visa Smart
Debit/Credit Member Implementation Guide for Acquirers, the following data elements may
require post-deployment updates: VSDC CA public keys, terminal action codes, application
identifiers, random transaction selection parameters, and floor limits.
8.2.1 VSDC CA Public Keys

VSDC CA Public Keys are used for supporting SDA, DDA, CDA, and enciphered offline
PIN transactions. Device management systems should allow for six VSDC CA Public Keys
Planned changes and accelerated key revocations require that keys be updated in all
devices. Consequently, these data elements should be treated as variable parameters, not
as components of the kernel. Post-deployment data integrity must also be verified. Failure
to load the correct production VSDC CA Public Keys or a newly introduced key will result in
failure to correctly process SDA, DDA or CDA which may lead to a declined transaction
depending on the risk parameters setup in the card or the issuer host.
To ensure effective management of VSDC CA Public Keys, the device management

system should:
 Download keys to devices prior to and after deployment
 Download new keys prior to their effective date
 Remove expired or revoked keys by the Visa published date
 Notify all deployed devices when a key is to be downloaded or removed
Visa Public Page 98

 Distribute keys to deployed devices in a manner that protects their integrity
 Maintain status of keys in deployed devices

Managing keys manually across a large device base can pose significant difficulties. The
device management system should, therefore, automatically notify all affected devices
when a key is to be downloaded or removed. Notification may be done during an
authorization response, a batch upload acknowledgement, an end-of-day response, or an
explicit call by the device management system. Alternatively, devices may regularly contact
the device management system for outstanding updates.
Once notification is received, the device should automatically implement a scheduled

process that results in a timely update of the keys.
The secure distribution of keys to devices is critical to ensure that the keys are not
corrupted during delivery. For example, a device could validate the keys by checking the
SHA-1 hash. Alternatively, the device management system could validate key integrity by
using its own validation technique as a check sum.
For more information on updates and management of public keys, refer to Section 7.6, Key
Management.
8.2.2 Terminal Action Codes

Used in terminal action analysis, TACs are mandatory device data elements with values
defined by Visa and listed in Appendix G, Requirements and Best Practices. They indicate
the action that the device should take based on the TVR.
The device management system should be set up to track settings and update the settings
through downline loads, when appropriate. Merchants must not be able to update TACs.
8.2.3 Application Identifiers

AIDs indicate the card applications that a device can support, such as Visa, Visa Electron,
Plus, or a merchant loyalty program. All contact chip devices that include the Visa
Debit/Credit AID must also include the Visa Electron AID, unless specifically excluded by
the merchant.
8.2.4 Random Transaction Selection Parameters

The parameters for random transaction selection define the percentage and threshold
values used by devices that support both offline and online transactions. They are used
specifically in the random selection of transactions to be sent online for authorization,
independent of transaction characteristics.
For more information on random selection, see Section 5.9.2, Random Transaction
Selection.
Visa Public Page 99

8.2.5 Floor Limits

In conjunction with the Visa-published floor limits for specific country and MCC
combinations, the acquirer may set floor limits for chip and magnetic stripe transactions.
The chip card can request, however, that a transaction to be transmitted online for a
transaction that is under the acquirer-established floor limit.
To provide maximum flexibility, devices and device management systems should support
the following floor limits:
 International floor limit for non-chip transactions
 International floor limit for chip-initiated transactions
 Domestic floor limit for non-chip transactions
 Domestic floor limit for chip-initiated transactions

For more information on floor limits, see Section 5.9.1, Terminal Floor Limits.
8.2.6 Application Version Number

The Application Version Number relates to the version of VIS. It is the version, release, and
modification number in binary of VIS supported by the card. It is recommended that the
terminal Application Version Number match the most current VIS-specified card Application
Version Number at the time the terminal received its EMVCo approval.
The current version of VIS is 1.5.0 which would be coded in binary as ‘0096’. Previous
versions, 1.4.1 (binary ‘008D’) and 1.4.0 (binary ‘008C’) would also be acceptable. Version
1.3.2 (binary ‘0084’) remains valid for older devices.
8.3 EMV Functionality Considerations

Visa recommends the best practices in the following sections for device management
systems.
8.3.1 Mandatory Functionality for EMV Devices

The EMV specifications include mandatory requirements for all devices, classified by
device type. These requirements may vary from device to device, but any individual device
must support the minimum requirements for its type.
To ensure EMV compliance, the device management software should include profiles or
logic validating that all mandatory functions for a device type are active.
8.3.2 Configurable Functions
If an optional function is configurable—that is, if it can be turned on or off—it must be able

to work properly as configured. Software for the function should be identified as
configurable and should be tested and type approved in both on and off modes.
Visa Public Page 100

During vendor quality assurance testing, application kernels that are developed for multiple
device types should be tested by using all EMV scripts for those devices. Comprehensive
quality assurance testing ensures proper support for mandatory and optional functions
across device types.
A device may have one approved kernel that can be configured at installation to provide
only needed functionality. EMV allows one kernel to be tested in multiple configurations.
These kernels are referred to as configurable kernels.
Alternatively, a device may support selectable kernel configurations which means that the
kernel configurations used at a single device may vary based upon characteristics of the
transaction rather than being set at the time of device installation. The selection criteria
logic must be checked to ensure that it selects the correct configuration. All selectable
configurations must be EMV type approved. The configuration should be selected prior to
the issuance of the Get Processing Options command so that the correct device
information can be sent to the card if requested in the PDOL.
Visa’s recommends that acquirers consider the use of selectable kernels as a best practice
since there is the potential for interoperability problems with configurable kernels if they are
not configured correctly at the time of installation.
8.4 Contactless Chip Considerations

Although most of the date elements noted in Section 8.2 are also applicable to contactless
capable devices, there are some additional parameters which are only used for contactless
transactions and which may be updated via a device management system remotely. These
include:
 Terminal Transaction Qualifiers
 Contactless floor limits
 Contactless CVM limits

The principles for handling contactless related elements are the same as those for contact
chip and should be part of the same set of processes where appropriate.

Chapter 9 Acquirer Considerations

This chapter provides a brief discussion of acquirers’ unique responsibilities for chip
infrastructure support to ensure that acquirers support Visa requirements and best
practices for transaction acceptance devices.
9.1 Electronic Signature Capture Devices

An electronic signature capture device enables a merchant to obtain a cardholder’s
signature for a transaction using a touch-sensitive electronic pad instead of a paper
transaction receipt. Electronic signature capture is a growing practice in several countries.
Elsewhere, such as in Visa Europe, CVM-related chargeback protection is not provided
when the signature is electronically captured. Acquirers should check with their regional
Visa office to determine regional requirements.
Effective 15 May 2009, the Visa Operating Regulations require a device that captures
electronic signatures to have proper controls in place to ensure the security of the stored
signatures and other cardholder data in accordance with the PCI DSS. It must also store
and reproduce a signature on only a transaction-specific basis, in relation to the transaction
for which the signature was obtained, and must reproduce a signature only upon specific
written request from the acquirer or in response to a retrieval request.
For more information, see Section 7.7.1, Cardholder Data Security.
9.2 PIN Storage

Any device with a PIN Pad, including a POS device or an ATM system, must not retain any
PIN-related data after an authorization response. Retention of an online PIN block may be
allowed for deferred authorization transactions but only for the minimum time necessary to
complete the transaction.
9.3 Deploying EMV-Compliant Devices

To reduce acceptance problems, device deployers should follow some basic practices:
 When selecting software for devices, determine the EMV kernel identifier and
review the listing of approved kernels at www.emvco.com. The later the version of
specifications and test plan, the less likely that any in-the-field interoperability
problems will arise.
 Only implement software that incorporates kernels based on EMV specifications 4.1
or later, preferably based on the latest specifications. A kernel based on earlier
specifications (3.1.1 or 4.0) is more likely to have problems in the field.
 As interoperability problems are uncovered globally, new testing is put in place at

EMVCo-accredited laboratories. Deployers should plan to refresh the software in
their devices every few years to ensure that they have the latest fixes and
functionality.

 Deployers should consider including language in purchase or lease contracts so

that the device or software vendor will supply updated kernels at no charge, as they
become available, for at least 3 to 5 years.
 Deployers will need to have a means of updating public keys in their EMV devices.
Although this does not happen very often, it should be completed in a timely manner
when needed.
 An automated device management system will make key and software updates
much simpler and quicker to implement. Device management systems will also
facilitate asset management, track errors, and report problem devices. The long-
term benefits of device management systems will generally provide a positive
business case for implementation. See Chapter 8, Device Management Systems,
for a further discussion of recommended functionality.
 With the emergence of new functionality such as authentication methods, deployers

who do not use a flexible format for their device-to-acquiring-host messaging should
plan to migrate to a format based on XML, TLV, or a similar flexible system.

Chapter 10 Data Element Considerations

Considerations for the following data elements are included in this section:
 Application PAN Sequence Number
 Interface Device (IFD) Serial Number
 Issuer Application Data
 Application Cryptogram and Card Authentication
 Issuer Authentication Data
10.1.1 Application PAN Sequence Number

The Application PAN Sequence Number (Tag ‘5F34’) is an EMV data element that issuers
may use to identify a specific card when two or more cards have been issued under a
single PAN. It allows differentiation of multiple cards having the same PAN.
If present in the card, this data must be included in the online authorization message in the
Card Sequence Number field (V.I.P. Field 23). Failure to do so could result in unnecessary
authentication failures.
The format of the Application PAN Sequence Number is described in the EMV and VIS
specifications as 2 decimal digits (2 (n 2)—1 byte of 2 decimal nibbles). Card Sequence
Number is described in the Visa Smart Debit/Credit System Technical Manual as three
decimal digits (3 (n 3) using Binary-Coded Decimal (BCD)—3 decimal nibbles). Card
Sequence Number is right-justified and zero-filled on the left; thus, this field is zero-filled in
the first byte and the Application PAN Sequence Number is placed in the second byte.
During testing and certification of the acquirer’s BASE I, SMS POS, and SMS ATM
systems, Visa regional staff verify the correct handling for both the presence and absence
of the Application PAN Sequence Number and ensure that the field is applied in the correct
format.
10.1.2 IFD Serial Number

Because there is no global standard for the use of the IFD Serial Number (Tag '9F1E’), its
use has resulted in unnecessary declines. To prevent this from happening, VisaNet now
deletes this field from messages prior to sending them to the issuer. Device deployers and
acquirers are, therefore, advised not to supply this optional VisaNet field in authorization
requests.
10.1.3 Issuer Application Data

The acquirer must populate the VisaNet authorization message with the Issuer Application
Data (Tag '9F10') sent from the card. This data should be sent from the acquiring device
through the acquirer to VisaNet without modification. Since different payment schemes
have different lengths and formats for this field, systems should not edit, format or parse
this field.

Acquirers must populate the data in the expanded third bit map in V.I.P. Field 134 (Visa
Discretionary Data—variable length up to 32 bytes, plus length byte) or in V.I.P. Field 55
with the appropriate EMV fields including Issuer Application Data (Tag '9F10'), which can
be up to 32 bytes. The TCR7 of Transaction Code 05 (TC 05) and Transaction Code 07
(TC 07) needs to be populated with Issuer Application Data, bytes 1 through 32, if present.
10.1.4 Application Cryptogram and Card Authentication

The Application Cryptogram data element, which is 8 bytes, is generated by the card and
passed to the device in response to the GENERATE AC command. The issuer checks the
cryptogram (generally an ARQC for online transactions) before authorizing the transaction.
Acquirers should include the cryptogram in the expanded third bit map in V.I.P. Field 136 or
V.I.P. Field 55 (Tag '9F26'). This data must be sent through from the device to the acquirer
and to VisaNet without modification. Systems should not edit, format, or parse this field as it
may lead to the issuer declining the transaction.
Modification or failure to pass the correct fields may result in the cryptogram calculation
failing at the issuer host and the transaction being declined. This includes the Amount
Authorized field (Tag 9F02 in Field 55 or Field 147).
10.1.5 Issuer Authentication Data

The Issuer Authentication Data element, which is 816 bytes (plus length byte), is sent from
the issuer to the card as part of the authorization response.
Acquirers receive this variable-length data in the expanded third bit map in V.I.P. Field 140
or V.I.P. Field 55 (Tag '91'). This data must be sent through the network and the acquirer to
the acquiring device without modification. Systems should not edit, format, or parse this
field.
10.2 Recovery for Offline Transactions

As a best practice, acquirers should ensure that POS devices receive regular maintenance,
such as battery replacement.
If a power failure occurs and the battery in the device is dead, the merchant may need to
manually re-enter information from the receipts of captured transactions. The merchant is
at risk of losing payment for those transactions because the full magnetic stripe or chip
information is not printed on the merchant’s copy of the receipt.
To reduce the size and impact of risk, acquirers should ensure that their devices clear
every day and that merchants are educated accordingly. Use of nonvolatile journaling (in
accordance with PCI DSS requirements) should also be encouraged.
10.3 Application Performance Consideration

A contact chip device must provide fast, efficient processing of chip card transactions.
Much can be gained in transaction time by optimizing the software in the device.

As a best practice, the application transaction time for chip cards should not exceed the
time for the same type of transaction performed online with magnetic stripe cards. Targeted
transaction times may vary for different national markets.
Much of the communication between the device and chip card can take place while waiting
for a manual action from either the cardholder or the merchant. Examples include:
 Initiating a transaction immediately after the card is inserted in the device
 De-energizing the chip after completion of the transaction, instead of waiting for the
receipt to be printed, so that the cardholder can remove the card while the receipt is
being printed
 Processing some or all of the steps concurrently instead of sequentially, (for

example, offline data authentication, processing restrictions, cardholder verification,
and terminal risk management)
For more information see Appendix D, Device Performance for EMV Transactions.
10.4 Acquirer Device Validation Toolkit

Visa recognizes that acquirers and device vendors need a clear and easy way to validate
that their contact chip devices are configured to meet their domestic and regional market
needs and that international chip cards entering their markets experience the same level of
acceptance.
Visa has consequently developed the Acquirer Device Validation Toolkit (ADVT). The
toolkit is a set of test cards and test scripts that acquirers or vendors can use on devices
that have already received EMV Level 1 and Level 2 approval and are configured for
deployment (that is, after the country code, floor limits, and other processing parameters
are set up in the device).
Chip acquirers must use the ADVT on each type of contact chip device if either:
 A new hardware or payment-related configuration is introduced, or
 New payment software is installed
Acquirers that do not comply with this requirement may be subject to fines and penalties as
defined in Visa’s Chip Interoperability Compliance Program or other applicable regional
compliance programs.
10.4.1 ADVT and EMVCo Approval

Use of the ADVT does not preclude the requirement that contact chip device components
be approved by an EMVCo-accredited laboratory. In fact, EMVCo approval is a prerequisite
for a device to be validated by acquirers using the ADVT. Use of the ADVT does not imply
or guarantee that a device is fully compliant with EMV specifications or Visa requirements.

10.4.2 ADVT and Expired EMV Approvals

To encourage the deployment of modern kernels and interface modules (IFMs) that are
less susceptible to interoperability issues, Visa requires that an acquirer must not submit
ADVT testing results to Visa for devices containing kernels and IFMs that have expired.
This rule only applies where the results of ADVT testing are to be made available to Visa.
Other uses of ADVT, such as for internal regression testing, are not affected.
This will not affect deployed devices or the deployment of devices already approved
against ADVT. However, it will prevent the deployment of new and updated device
configurations that use expired hardware or software.
More information on the requirements and rules relating to the ADVT can be found at
www.visa.com/ADVT.
10.4.3 Future ADVT Requirements

Visa may continue to enhance tools and procedures associated with ADVT and will notify
acquirers in advance of such changes. The goal of this strategy is to provide a more
comprehensive end-to-end testing environment and process that enables acquirers to
validate device configurations with the ADVT. For example, the use of host or network
simulators for online transaction validation is key to more efficiently and effectively
validating the acquiring process.
More information on the ADVT can be found at www.visa.com/ADVT.
10.5 Card Expiration Date Processing

Because Visa and Visa Electron cards have no limits on their expiration dates, an acquirer
needs to ensure that transactions are not terminated at the device or rejected by the
acquirer based on the expiration date.
If the cardholder presents an expired card, a merchant must verify the cardholder’s identity
and request authorization regardless of the merchant’s floor limit. If an authorization cannot
be performed, the transaction should be terminated.
If the issuer approves the authorization for an expired card, the merchant should proceed
with the transaction. For contact chip devices, the chip card and device decide how to
proceed.
Acquirers are requested to ensure that, where electronic commerce merchants use drop-
down boxes or other methods to capture card expiration dates, the input of expiration dates
of at least five years from the present date is allowed or that the cardholder is allowed to
type in the year in which the card expires.
10.6 Fallback Processing

Acquirers should establish monitoring procedures to ensure fallback levels are kept to a
minimum. High levels of fallback may indicate problems with a device or alternatively a
need for further merchant education.

Visa has enacted a global monitoring program to identify acquirer-country combinations

with high levels of international, and where applicable domestic, fallback. Acquirers
identified will need to take corrective action.
To monitor fallback rates, acquirers should review transactions which include the fallback
indicators:
 V.I.P. Field 22 [POS Entry Mode]: Value of 02 or 90 (magnetic-stripe read)
 V.I.P. Field 35 [Track 2 equivalent data]: Value of Service Code digit 1 is 2 or 6

(indicating a chip card)
 V.I.P. Field 60.2 [Terminal Entry Capability]: Value of 5 (chip device)
Acquirers may also check V.I.P. Field 60.3 [Chip Condition Code] which provides additional
information relating to the how transactions are being processed at the device and will be
useful in enacting monitoring procedures. However this field should only be used for
analysis purposes and not on a per-transaction basis.
The values of this field may be as follows:
 1—Magnetic stripe Service Code begins with 2 or 6 and the last chip card read at
chip-capable device was either a successful chip read or the transaction was not a
chip transaction.
 2—Magnetic stripe Service Code begins with 2 or 6 and the last chip card read at
chip-capable device was an unsuccessful chip read.
For contact chip transactions, this field should not be present or should contain 0.
If the analysis shows a large number of transactions for a given devices with the value of 2,
this may indicate a problem with the device and the device may need to be upgraded. If the
analysis shows a large number of transactions for a given device with the value of 1, this
could indicate a problem with merchant procedures since the last transaction was a
successful chip transaction. The acquirer should assist the merchant with additional
training.
10.6.1 Acquirer Stand-In Processes

Various country requirements allow for the use of a mechanism whereby if the transaction
is above the terminal floor limit and the terminal is unable to go online, the merchant is able
to accept the transaction. These mechanisms ensure the cardholder is not inconvenienced
and the merchant is able to continue conducting their business.
Two possible approaches to address this scenario are described below. It should be noted
that each of these requires an overall market agreement by participating merchants,
acquirers and issuers including rules regarding liability. The approaches noted below are
variations of acquirer stand-in and forced settlement as described in chapters 3 and 5 and
are included here as possible solutions.

 Forced Settlement: This solution involves the acquirer submitting a chip declined
transaction for settlement. This would have occurred because the card would have
declined the transaction with an AAC (since the transaction is above the floor limit
but the terminal is unable to go online).
The device does not display the decline to the cardholder but it undertakes a check
of various conditions in the TVR and if these conform to an agreed set of
requirements (such as the need for offline card authentication to have passed) the
cardholder is then asked to sign for the transaction and the transaction is processed
for settlement.
 Multi-Kernel or Selectable Kernel Solution: This solution requires the device to

have two kernels, one of which is used in electronic fallback situations. If the
transaction is declined by the card with an AAC because the terminal is unable to
go online, the terminal switches to electronic fallback mode and a second
transaction is initiated (the cardholder is not required to remove the card), this time
where the kernel is offline-only and supports signature. In this instance the card will
check its offline limits and if these are not exceeded the transaction is approved with
a TC. The transaction is submitted for clearing with an Authorization Response
Code of Y1.
Acquirers in markets where chip acceptance is widespread should ensure they are familiar
with local requirements (if any) regarding this issue.
Any acquirer which undertakes an approach as described in this section without prior
agreement of issuers will be liable for any transactions that are disputed by cardholders.

Chapter 11 Considerations for EMV Approval

This chapter provides information to consider for EMV approval. To accept Visa chip
transactions, devices must comply with the most current version of EMV and VIS
specifications and be approved for EMV Level 1 and Level 2 by an EMVCo-accredited
laboratory. Compliance to the latest specification will ensure that the device is able to more
easily satisfy the testing requirements to gain approval.
11.1 EMV Level 1

EMV Level 1 approval is given for the interface module (that is, the chip card reader) rather
than for the device on which it is tested. An interface module consists of the hardware and
software that powers the chip card and supports communication between the device and
the card up to the transport layer. The three main functional components are the
mechanical, electrical, and logical chip card interfaces.
An approved interface module can be used for any device, as long as the interface module
is not modified and can be used with any approved EMV application kernel. It is important
to identify the interface module component separately from the device, using a unique
identifier.
11.2 EMV Level 2

EMV Level 2 approval is not tied to a particular model of a particular type of hardware
platform. The approval letter notes, however, the hardware configuration to be used for
testing.
An application kernel is approved to run on any device that has an approved interface
module and supports the environment used during testing. If the kernel can be used on a
device without recompilation, the kernel retains its EMV approval. EMV Level 2 test cases
are performed only against EMV functions. Acquirer, payment scheme, and national
specifications are not part of EMV testing.
An application provider may simulate any non-EMV functions necessary for the completion
of the test cases, (for example, message formats, communications protocols, device
prompt sequences, or payment scheme settings). These other functionalities, however, do
not necessarily represent the end product because some level of customization may be
required for each acquirer, market, or payment scheme.
Rigorous testing needs to be performed to ensure that customizations and application

changes have no adverse impact on the EMV kernel and functions.
A device must have an interface module that has been approved for EMV Level 1 before its
EMV application kernel can be tested for Level 2.
11.3 EMVCo Approvals

EMVCo has recently introduced a renewal policy requiring all interface modules and
kernels to be re-tested on a regular basis.

An interface module (IFM) approval is valid for 4 years and an application kernel approval
is for 3 years. This validity period applies to static and configurable kernels.
At expiration of the approval, EMVCo evaluates whether the product, either the IFM or the
kernel, demonstrates sufficient conformance to the current EMV specification and may
grant an extension. Interface modules or kernels that do not pass the evaluation will not be
granted an extension and their approval will be considered expired.
EMVCo may also revoke an approval of an IFM or kernel if a significant interoperability

problem arises in the field.
Visa policy relating to device approvals requires that ADVT be only performed on devices
that are EMVCo approved. Acquires should ensure that any new device installations
contain interface modules or kernels that have a current EMVCo approval.
Further information on the EMVCo renewal policy can be found at www.emvco.com
11.4 Testing Recommendations

Vendors should leave the device containing the interface module or application kernel at
the EMVCo-accredited testing laboratory until an approval letter is received from the
EMVCo secretariat. Minor issues found in the testing report can be easily resolved if the
device has remained under control of the testing laboratory. If the device has left the
laboratory, significant re-testing may be required to ensure that no changes have been
introduced since the device left the laboratory.
11.5 Kernel Modularization

Device vendors should adopt a modular approach to design so that minor changes can be
made without the need for major modification.
Recommended modules include:
 Table-driven currency codes
 Drivers for peripherals, such as printers
 Communications and message drivers
 Cardholder and merchant interface, including table-driven prompts and responses

Functions that are outside the scope of the EMV specifications, such as display
functionality, should be outside the kernel so that these functions may be updated without
requiring a kernel update and subsequent re-approval. For example, display messages can
reside in a table outside of the kernel. The EMV module can then indicate simply the table
entry to be used in a particular situation. This allows language modification without
changing the kernel.

Appendix A Track 1 Data Specifications

This appendix describes Visa standards for the contents of Track 1 of the magnetic stripe
and the magnetic stripe image on the integrated chip. Visa requirements conform to ISO
7811 2 and ISO 7813.
A.1 Track 1 Content Requirements

This section provides information about the record format, character set, and data elements
for Track 1. Requirements for the contents of the magnetic stripe conform to ISO 7813. An
issuer must comply with the Track 1 encoding requirements contained in this appendix, as
outlined in the following points:
 The magnetic stripe on a Visa card or Visa Electron card (including Instant Issue and
Prepaid cards) must be encoded on both Track 1 and Track 2, as specified in this
manual.
 Magnetic-stripe data encoding must begin in sequence from the right-hand side of the
card as viewed from the back, with the encoded tracks at the top.
 Service Code values must be encoded on a Visa Card or Visa Electron Card, as
specified in this manual. An issuer may encode its card acceptance policies in the
Service Code field of the magnetic stripe using all valid Service Codes.
 The centerline of the first data bit (start sentinel) to be recorded on the magnetic stripe
must be 7.44mm ± 0.51mm from the right edge of the Visa card or Visa Electron card.
The centerline of the last data bit to be recorded on the magnetic stripe must not
extend closer than 6.93mm from the left edge of the Visa card or Visa Electron card.
 The lead-in to the first data bit and the distance from the last data bit to the end of the
magnetic stripe must be clocking bits (i.e., zeroes).
 Data on the magnetic stripe must be encoded at 210 bits per inch on Track 1 and 75
bits per inch on Track 2, and contain at least the required information in the various
fields as specified in this manual.
 All of the following must conform to ISO 7811 2:
 Physical properties
 Performance characteristics
 Density
 Signal level
 Recording angle tolerances
 Error detection
 Permissible surface variation
 Character sets
 Appearance of the magnetic stripe.

A.2 Record Format

The following points apply to Track 1 record format:
 The PIN Verification Data field is optional for all cards.
 The Discretionary Data field is optional for all cards.
 The Authorization Control Indicator (ACI) in the Visa-Reserved field is optional.

NOTE: A Card Verification Value (CVV) is required in the Visa-Reserved field on all Visa
and Plus cards. CVV is not required on Plus cards.
Track 1 Record Format lists the Track 1 field names and their length. The maximum length
of Track 1 is 79 characters. Refer to Data Element Descriptions for more information.
Table A-1 describes Track 1 Record Format.

Table A-1: Track 1 Record Format

Field Length Field Name
Number
1 1 Start Sentinel
2 1 Format Code
3 12-19 Primary Account Number (PAN)
4 1 Separator
5 226 Cardholder Name
6 1 Separator
7 4 Card Expiration Date
8 3 Service Code
9 0 or 5 PIN Verification Data
Position Length Content
1 1 PIN Verification Key Index (PVK)
2 to 5 4 PIN Verification Value (PVV)
10 Varies* Discretionary Data
**
11 11 Visa-Reserved Field
Position Length Content
1 to 2 2 Zero Fill
3 to 5 3 Card Verification Value (CVV)
6 to 7 2 Zero Fill
8 1 Authorization Control Indicator (ACI)
9 to 11 3 Zero Fill
12 1 End Sentinel
13 1 Longitudinal Redundancy Check (LRC)
*
The length of this field depends on the lengths of fields 3, 5, and 9.
**
The length is always the last 11 positions of track 1, excluding the End Sentinel and Longitudinal Redundancy
Check.
A.2.1 Character Set

The bit-sequence pattern for the letter K is illustrated in Figure A-1.
Figure A-1: Letter K Bit Sequence Pattern

NOTE: bn = bit position number "n". The parity bit is automatically generated and
encoded by the encoding machine.
The encoding equipment must encode the magnetic stripe data of track 1 in accordance
with the bit sequence patterns specified in Figure A-1.
Table A-2 describes the track 1 character set. This table corresponds to the comparable
table in ISO 7811-2.
Data formats to be provided to an encoding machine are specified by the hardware

manufacturer. The encoding device must use odd parity to encode data characters.
Clocking bits for synchronization are not considered as data.
Additionally, an even-parity Longitudinal Redundancy Check (LRC) character must be the

last character in a track record.
Table A-2: Track 1 Character Set (1 of 3)

Binary
Char. 5 4
P 2 2 23 22 21 20
space 1 0 0 0 0 0 0
! 0 0 0 0 0 0 1
“ 0 0 0 0 0 1 0
# 1 0 0 0 0 1 1
$ 0 0 0 0 1 0 0
% 1 0 0 0 1 0 1
& 1 0 0 0 1 1 0
‘ 0 0 0 0 1 1 1
( 0 0 0 1 0 0 0
) 1 0 0 1 0 0 1


Binary
5 4
Char P 2 2 23 22 21 20
* 1 0 0 1 0 1 0
+ 0 0 0 1 0 1 1
, 1 0 0 1 1 0 0
- 0 0 0 1 1 0 1
. 0 0 0 1 1 1 0
/ 1 0 0 1 1 1 1
0 0 0 1 0 0 0 0
1 1 0 1 0 0 0 1
2 1 0 1 0 0 1 0
3 0 0 1 0 0 1 1
4 1 0 1 0 1 0 0
5 0 0 1 0 1 0 1
6 0 0 1 0 1 1 0
7 1 0 1 0 1 1 1
8 1 0 1 1 0 0 0
9 0 0 1 1 0 0 1
: 0 0 1 1 0 1 0
; 1 0 1 1 0 1 1
< 0 0 1 1 1 0 0
= 1 0 1 1 1 0 1
> 1 0 1 1 1 1 0
? 0 0 1 1 1 1 1
@ 0 1 0 0 0 0 0
A 1 1 0 0 0 0 1
B 1 1 0 0 0 1 0
C 0 1 0 0 0 1 1
D 1 1 0 0 1 0 0


Binary
5 4
Char P 2 2 23 22 21 20
E 0 1 0 0 1 0 1
F 0 1 0 0 1 1 0
G 1 1 0 0 1 1 1
H 1 1 0 1 0 0 0
I 0 1 0 1 0 0 1
J 0 1 0 1 0 1 0
K 1 1 0 1 0 1 1
L 0 1 0 1 1 0 0
M 1 1 0 1 1 0 1
N 1 1 0 1 1 1 0
O 0 1 0 1 1 1 1
P 1 1 1 0 0 0 0
Q 0 1 1 0 0 0 1
R 0 1 1 0 0 1 0
S 1 1 1 0 0 1 1
T 0 1 1 0 1 0 0
U 1 1 1 0 1 0 1
V 1 1 1 0 1 1 0
W 0 1 1 0 1 1 1
X 0 1 1 1 0 0 0
Y 1 1 1 1 0 0 1
Z 1 1 1 1 0 1 0
[ 0 1 1 1 0 1 1
\ 0 1 1 1 1 0 0
] 0 1 1 1 1 0 1
^ 0 1 1 1 1 1 0
_ 1 1 1 1 1 1 1

NOTE: This coded character set is identical to the coded character set in ISO/IEC 7811-4
and is derived from ASCII.
A.3 Encoding Examples

This section contains examples of Track 1 encoding.
NOTE: The examples provide a sample format only and should not be followed literally
when encoding Track 1 of the magnetic stripe.
 Encoding with PIN Verification Data Field illustrates encoding with the PIN Verification
Data field. The Visa-Reserved field shows the position of the CVV.
 Encoding with Discretionary Data Field illustrates encoding with the Discretionary Data
field. The Visa-Reserved field shows the position of the CVV.
 Encoding with PIN Verification and Discretionary Data Fields illustrates encoding with
both optional fields. The Visa- Reserved field shows the position of the CVV.
Figure A-2: Example: Encoding With PIN Verification Data Field

10 20 30 40 50 56
MB 4 0 0 0 0 0 1 2 3 4 5 6 2 MP U B L I C J R / J O H N Q . MRM 9 8 0 9 1 0 1 0 0 8 7 6 0 0 0 0 0 0 MM
LRC
Start
Sentinel End
Sentinel
Format
Code CVV
PAN Visa-Reserved
Separator
Surname
Suffix
Surname
Separator
First
Name
Initial
Title
Separator
Title
Expiration
Date
Service
Code
Information to be encoded:

 PAN: 4000 0012 3456 2345 (16 digits)
 Cardholder Name: MR JOHN Q PUBLIC JR
 Expiration Date: 09/98
 Service Code: 101
 PIN Verification Data: 5 (PVKI) and 4321 (PVV)
 Discretionary Data: none
 Visa-Reserved: 11 characters with 876 for the CVV and the remaining positions are
zero-filled
Figure A-3: Encoding With PIN Verification Data Field

10 20 30 40 50 60 64
MB 4 0 0 0 0 0 1 2 3 4 5 6 2 3 4 5 MP U B L I C J R / J O H N Q . MRM 9 8 0 9 1 0 1 5 4 3 2 1 0 0 8 7 6 0 0 0 0 0 0 M
LRC
Start
Sentinel End
Sentinel
Format
Code
CVV
PAN
Visa-Reserved
Separator
PIN Verification
Data
Surname
Suffix
Surname
Separator
First
Name
Initial
Title
Separator
Title
Expiration
Date
Service
Code

Example: Encoding With Discretionary Data Field
 PAN: 4000 0012 3456 2345 (16 digits)
 Cardholder Name: MR JOHN Q PUBLIC JR
 PIN Verification Data: none
 Discretionary Data: 999999999
 Visa-Reserved: 11 characters with 876 for the CVV and the remaining positions are
zero-filled
Figure A-4: Encoding With Discretionary Data Field

10 20 30 40 50 60 68
MB 4 0 0 0 0 0 1 2 3 4 5 6 2 3 4 5 MP U B L I C J R / J O H N Q . MRM 9 8 0 9 1 0 1 9 9 9 9 9 9 9 9 9 0 0 8 7 6 0 0 0 0 0 0 M
LRC
Start
Sentinel End
Sentinel
Format
Code
CVV
PAN
Visa-Reserved
Separator
Discretionary
Data
Surname
Suffix
Surname
Separator
First
Name
Initial
Title
Separator
Title
Expiration
Date
Service
Code

Example: Encoding With PIN Verification Data and Discretionary Data Fields
• PAN: 4000 0012 3456 2345 678 (19 digits)
• Embossed Cardholder Name: MR JOHN Q PUBLIC JR
• Embossed Expiration Date: 09/98
• Service Code: 101
• PIN Verification Data: 5 (PVKI) and 4321 (PVV)
• Discretionary Data: 999999999
• Visa-Reserved Field: 11 characters with 876 for the CVV and the remaining
positions are zero-filled
Figure A-5: Encoding With PIN Verification and Discretionary Data Fields
10 20 30 40 50 60 70 76
MB 4 0 0 0 0 0 1 2 3 4 5 6 2 3 4 5 6 7 8 MP U B L I C J R / J O H N Q . MRM 9 8 0 9 1 0 1 5 4 3 2 1 9 9 9 9 9 9 9 9 9 0 0 8 7 6 0 0 0 0 0 0 M
LRC
Start
Sentinel End
Sentinel
Format
Code
CVV
PAN
Visa-Reserved
Separator
Discretionary
Data
Surname
PIN Verification
Suffix
Data
Surname
Separator
First
Name
Initial
Title
Separator
Title
Expiration
Date
Service
Code

A.4 Data Element Descriptions

This section describes the data elements encoded on Track 1 of the magnetic stripe. Field
1—Start Sentinel describes the Start Sentinel.
Table A-3: Field 1—Start Sentinel
Attributes 1 alphanumeric
Description Indicates the initial data position on the track.
Valid value %
Field 2—Format Code describes the Format Code data element encoded on Track 1 of the
magnetic stripe.
Table A-4: Field 2—Format Code
Description Specifies the format for Track 1 encoding
Valid value B
Field 3—Primary Account Number (PAN) describes the PAN data element encoded on
Track 1 of the magnetic stripe.
Table A-5: Field 3—Primary Account Number (PAN)
Attributes 12 to 19 alphanumerics
Description A series of digits used to identify a customer account or relationship. The first
digits of the Primary Account Number specify the Bank Identification Number
(BIN), which must be unique to the interchange system and network.
Valid value 0 to 9

Field 4—Separator describes the Separator data element encoded on Track 1 of the
magnetic stripe.
Table A-6: Field 4—Separator
Description Indicates the end of a variable-length field such as the PAN field.
Valid value ^ (caret)
Usage The separator used in fields 4 and 6 of the track record is identically defined.
Issuers must encode on Track 1 of the magnetic stripe Cardholder Name data elements as
contained in Field 5—Cardholder Name .
Table A-7: Field 5—Cardholder Name (1 of 2)
Description Cardholder’s name
Valid value Surname:
Hyphen (-) for hyphenated surnames
Suffix (optional)
Surname separator (/)
First name and/or initials
Title separator (.) if a title is to be encoded
Title (optional)
Usage When encoded on the magnetic stripe, the PAN must not include any spaces

Table A-7: Field 5—Cardholder Name (2 of 2)
Usage Two delimiters are used in this field to mark the end of the surname (or
surname and suffix) and to mark the presence of a title: The surname
separator (/) and title separator (.). The format is the same as that specified in
ISO 7813, Identification Cards—Financial Transaction Cards.
ISO 7813 requires: “Minimum encoded data shall be a single alpha

character (as surname) and the surname separator.”
It is recommended that no spaces be encoded between the last character of

the name or title and the beginning of the next field.
It is required to populate the cardholder's name field as it cannot be left blank.

Depending on programs and Issuers, generic cardholder names can be used
whether they are unembossed or embossed.
An embossed Visa card must be personalized with a cardholder name on the

face of the card. An unembossed Visa card or Visa Electron card may be
issued without a cardholder name or generic cardholder identifier. The card
may bear either the cardholder name or the generic identifier on the face of
the card.
If Track 1 on an unembossed Visa flag card does not contain a specific

cardholder name, the generic name VISA CARDHOLDER may be encoded in
this field. In all other respects, the contents of Track 1 of the magnetic stripe
on unembossed cards must be encoded in the same manner as the
requirements for traditional embossed cards.
If Track 1 on a Visa Electron card does not contain a specific cardholder

name, the generic name VISA ELECTRON CARDHOLDER must be encoded
in this field. It is possible that cards issued out of branches may not have the
cardholder name information encoded on Track 1.
For airline ticketing, the customer name is the same as that encoded on the
stripe. Therefore, an airline would identify a passenger by the encoded
surname, with other names and any title used in the order in which they are
encoded, that is, the data following the surname separator (/).
The format of the name on Track 1 allows for a minimum field length of two
positions. The minimum accommodates cases in which a cardholder has a
one-character name. Therefore, the second character must be the surname
separator to mark the end of the surname.
While the formats of encoded names and embossed names will differ, an
issuer should try to keep the content of the encoded and embossed names the
same.

A.4.1 Cardholder Name Usage Examples

In Cardholder Name Usage Example 1, the cardholder’s name is embossed as DR
THOMAS A HARRIS JR. Note that the title separator (.) follows the first name THOMAS
and the initial A.
Figure A-6: Cardholder Name Usage Example 1
H A R R I S J R / T H O M A S A . D R
In Figure A–7, the cardholder’s name is embossed with initials, such as MRS J L YOUNG.
Y O U N G / J L . M R S
In Figure A-8, the cardholder’s name is embossed without a title, such as PAT B SMITH.
No title separator () or title is encoded
S M I T H / P A T B
In Figure A–9, the cardholder’s surname is hyphenated, such as L AL-SHAMARI.
A L - S H A M A R I / L
In Figure A-10, the generic name VISA CARDHOLDER is encoded as follows.
V I S A C A R D H O L D E R /

In Figure A–11, the generic name VISA ELECTRON CARDHOLDER is encoded as follows.
V I S A E L E C T R O N C A R D H O L D E R /
Table A-8 describes the Separator data element encoded on Track 1 of the magnetic
stripe.
Table A-8: Field 6—Separator
Description Indicates the end of a variable-length field such as the PAN field.
Valid value ^ (caret)
Usage The separator used in fields 4 and 6 of the track record is identically defined.
Table A-9 describes the Card Expiration Date data element encoded on Track 1 of the
magnetic stripe.
Table A-9: Card Expiration Date
Attributes 4 numerics in the format: YYMM
Description Year and month after which the card can no longer be used.
Valid value YY must be 00 to 99; MM must be 01 to 12
Usage The YYMM format follows ISO conventions for machine-processable dates. All
cards with a Visa, Visa Electron, or Delta mark must have a finite expiration
date that is no more than 20 years from the date of card issue.
The expiration date on a Visa Card, Visa Electron Card, or Card bearing the
Plus Symbol must not be later than the expiration date of the Issuer's Public
Key, or any security feature containing an expiration date in a Chip, if one is
present on the Card.

Table A-10 describes the Service Code data element encoded on Track 1 of the magnetic
stripe.
Table A-10: Field 8—Service Code
Attributes 3 numerics
Description A sequence of digits that, taken as a whole, defines various services;

differentiates cards used in international or national interchange; designates
PIN requirements; and identifies card restrictions.
Valid value The values allowed are made up of three individual digits: 1, 2, and 3. To be
valid, each digit must be one of the acceptable values listed in Table A-11:
Service Code Digit Value Descriptions. These service code values apply to
Visa card products (Visa, Visa Electron, and Plus cards). Not all combinations
of individually valid digit values result in a valid service code. Also, while a
large number of service codes can be constructed from these values, only
specific service codes are authorized for individual Visa card products.
Table A-12: Valid Service Codes by Card Product Platform describes the
service code values that are currently valid for Visa card products.

Table A-11 describes the Service Code Digit Value data element encoded on Track 1 of the
magnetic stripe.
Table A-11: Service Code Digit Value Descriptions (1 of 3)
Digit Value Description
1 0 Invalid for Visa card products
1 International Card
2 International Card—EMV chip, debit or credit
3 Invalid for Visa card products
5 National use only
6 National use only—EMV chip, debit or credit
2 0 Normal authorization

2 Positive authorization

3 0 PIN required
1 Normal verification
2 Goods and services only
3 ATM only
6 Prompt for PIN if PIN pad present
NOTE: Normal authorization means normal floor limits apply. Positive authorization
means that the transaction must go online, regardless of the merchant floor limit. Note
that this applies only to magnetic stripe read transactions.

A.4.2 Service Code Usage

Only valid service codes assigned by Visa may be used. Valid service codes available for
use in connection with Visa programs are set forth in Valid S below. Visa occasionally
assigns additional service codes as other uses are identified. An issuer, group of issuers, or
country can apply to Visa for the assignment of additional service codes for local, national,
or international usage.
Table A-12: Valid Service Codes by Card Product Platform (1 of 2)
Plus
Visa Co-Branded
Credit & Visa Co-branded Visa Plus with EFT
Service Visa Elec- Visa Check Travel ATM Processor
Code Debit tron Interlink & Interlink Money only Marks
101 Valid Valid
102 Valid
106 Valid Valid
120 Valid1 Valid2 Valid Valid Valid Valid
121 Valid1 Valid
122 Valid1 Valid
123 Valid
126 Valid1 Valid
201 Valid
202 Valid
206 Valid Valid
220 Valid1 Valid2 Valid Valid
221 Valid1 Valid
222 Valid1 Valid

Table A-12: Valid Service Codes by Card Product Platform (2 of 2)
Plus
Visa Co-Branded
Credit & Visa Co-branded Visa Plus with EFT
Service Visa Elec- Visa Check Travel ATM Processor
Code Debit tron Interlink & Interlink Money only Marks
223 Valid
226 Valid1 Valid
501 Valid
502 Valid
506 Valid
521 Valid1 Valid Valid
522 Valid1 Valid
523 Valid
601 Valid
602 Valid
606 Valid
620 Valid1 Valid2
621 Valid1 Valid
622 Valid1 Valid
623 Valid
626 Valid1 Valid

1
Clients that plan to issue embossed Visa Cards with an X2X service code or unembossed Visa Cards should
contact their Visa representative, as there are specific requirements regarding BINs and service codes for
these new programs.
2
Service codes X21 and X26 are recommended for Visa Electron. Issuers that plan to use X20 for Visa
Electron cards should contact their representative. Prior to using any service code ending in zero for Visa
Electron cards, an Issuer must obtain Visa's prior consent.
Table A-13 describes the PIN Verification element encoded on Track 1 of the magnetic
stripe.
Table A-13: Field 9—PIN Verification
Description Information needed to verify a PIN using the Visa PIN Verification Value (PVV)
Valid value Numerics 0 to 9
Position 1: PIN Verification Key Index (PVKI) = 0 or 1 to 6

Position 2 to 5: PIN Verification Value (PVV)
Usage If not needed, the field can be omitted from the stripe.
If the issuer (BIN) uses the PIN Verification Service (PVS) for some, but not all
issued cards, the PIN Verification field (both PVKI and PVV) should be zero-
filled on those cards not using the PVS. If the issuer does not use the PVS for
any cards in a card range, the zero-fill requirement is not needed.
Refer to Chapter 6 for more information on the PVKI and PVV.
Table A-14 describes the discretionary data element encoded on Track 1 of the magnetic stripe.
Table A-14: Field 10—Discretionary Data (1 of 2)
Description Information that the issuer uses for on-us transactions and wants to have
transmitted through the V.I.P. System for inquiries on interchange
transactions.
Visa Fleet Service Purchasing cards with a BIN range of 448450 to 448699
are required to use the last three positions of the discretionary data field to
provide instructions for customized prompts.

Table A-14: Field 10—Discretionary Data (2 of 2)
Valid value Any value in the character ranges 0 to 9 and A to Z, a space, a comma, or a
slash (/).
Visa Fleet Service Purchasing cards.
Position 1: Reserved = 0
Position 2: Service Enhancement Indicator = 0, 1, or 2
Position 3: Service Prompt = 0, 1, 2, 3, 4, or 5
Usage On Track 1, the length of this optional field is based on the lengths of the
Cardholder Name field and on the presence or absence of the PIN Verification
Data field and Fleet Service field.
If the Cardholder Name field contains 26 characters (the maximum allowed),

then 8, 11, 13, or 16 positions are available for discretionary data, as shown in
Table A-15: Matrix for Discretionary Data Field.
Note Track 1 Discretionary Data is defined in EMV and VIS as the discretionary
data portion of the magnetic stripe track 1 according to ISO 7813. However,
the definition of Track 1 Discretionary Data as defined in this manual (Visa
PTSM) is not the same as the definition in ISO 7813.
The Visa PTSM definition of Track 1 Discretionary Data excludes the PVKI,
PVV, and the Visa Reserved field from its definition of Track 1 Discretionary
Data. The Visa PTSM definition of Track 1 Discretionary Data is thus a subset
of the Track 1 Discretionary Data defined by ISO 7813.
The Visa PTSM Track 1 record format has the Service Code followed by the
(optional) 5-digit PVKI and PIN Verification Value (PVV), followed by the
Discretionary Data, followed by the Visa Reserved field, and then followed by
the End Sentinel.
If Track 1 Discretionary Data is personalized:

 For VSDC (i.e., EMV/VIS), it shall be personalized as defined in ISO-7813
(that is, including the PVKI, PVV, and Visa Reserved fields).
 For MSD, it shall be personalized as defined in the Visa PTSM (that is,
excluding the PVKI, PVV, and Visa Reserved fields).

Table A-15 describes the matrix for the Discretionary data field encoded on Track 1 of the
magnetic stripe.
Table A-15: Matrix for Discretionary Data Field
PIN Verification length = 0 PIN Verification length = 5
16-digit PAN 13 8
19-digit PAN 16 11
Figure A–12 illustrates a 16-digit PAN, 26-position name, and 5-position PIN Verification
field.
Figure A-12: PIN Verification Field
10 20 30 40 50 60 70 79
Visa-Reserved
16-Digit (Includes CVV)
PAN
PIN Verification Discretionary
26 Character Data Data
Cardholder (8 Characters)
Name
Discretionary
Data
(13 Characters If
PVKI and PVV Not
Encoded on Track)
When the Cardholder Name field contains fewer than 26 characters, the issuer can
increase the length of the Discretionary Data field by the number of unused positions.
NOTE: At the issuer's option, the Card Verification Value (CVV) located in the Visa-
Reserved field can also be placed in the Discretionary Data field for ease of issuer
verification.

Table A-16 describes the Visa-Reserved data element encoded on Track 1 of the magnetic
stripe.
Table A-16: Field 11—Visa-Reserved
Attributes 11 alphanumerics
Description Last 11 positions of Track 1, excluding the End Sentinel and LRC character.
Track 1 can vary in length depending on the presence or absence of the PIN
Verification Data and Discretionary Data fields. The location of the last 11
positions of the track varies accordingly. See A.3 Encoding Examples for
examples.
This fixed-length, required field is used by Visa for the following subfields:
 11.1 Card Verification Value
 11.2 Authorization Control Indicator
Valid value Positions 1 to 2: zeros
Positions 3 to 5 (CVV): 3 numerics
Position 6 to 7: zeros
Position 8 (ACI): A to Z or zero
Positions 9 to 11: zeros
Table A-17 describes the CVV data element encoded on Track 1 of the magnetic stripe.
Table A-17: Field 11.1—Card Verification Value (CVV)
Attributes 3 numerics (positions 3–5 of the Visa-Reserved field)
Description CVV is required on Track 1 of all Visa, Visa Electron, and Plus cards.
Unique check value calculated from the data encoded in the stripe using a
secure cryptographic process and a key known only to the issuer and Visa.
Once encoded on the stripe, the CVV deters counterfeit card usage by
validating encoded card information during the authorization process. The
algorithm to calculate the CVV is described in Chapter 2 of this manual.
Valid value 0 to 9
When the CVV is first implemented, issuers using Visa verification to verify
CVVs must supply Visa with the expiration date of the card series such that all
cards expiring on or after this date are encoded with the CVV.

Table A-18 describes the Authorization Control Indicator data element encoded on Track 1
of the magnetic stripe.
Table A-18: Field 11.2—Authorization Control Indicator
Attributes 1 alphanumeric (position 8 of the Visa-Reserved field)
Description Used for optional PCAS processing that describes the level of risk and the
issuer's PIN policies associated with the cardholder. The risk levels reflect the
best (lowest) risk to the worst (highest) risk, from A to D, respectively.
Valid value Zero, C, Z, Y, or X. Use zero when an ACI code is not included. If the ACI
code is included, select C, Z, Y, or X as appropriate for the risk level (see
Table A-19: ACI Values).
Table A-19 describes the ACI data element encoded on Track 1 of the magnetic stripe.
Table A-19: ACI Values
ACI Risk Level PIN Policy
C A Optional
Z B Optional
Y C Optional
X D Optional

Table A-20 describes the End Sentinel data element encoded on Track 1 of the magnetic
stripe.
Table A-20: Field 12—End Sentinel
Description Character that follows the final character of data recorded on the track.
Valid value ?
Table A-21 describes the LRC data element encoded on Track 1 of the magnetic stripe.
Table A-21: Field 13—Longitudinal Redundancy Check (LRC)
Attributes 1 character
Description Verification value that ensures that no data has been lost in the stripe-reading
process. The LRC is equivalent to a check digit of the entire track, including
the control characters.
Valid value Any computed value
Usage The LRC character is calculated using the following procedure:
The value of each bit in the LRC character, excluding the parity bit, is defined
such that the total count of 1 bit encoded in the corresponding bit location of
all characters of the data message, including the Start Sentinel, data, End
Sentinel, and LRC characters, is even.
The parity bit in the LRC character is not a parity bit for the individual parity
bits of the data message; it is the parity bit for the LRC character.

Appendix B Track 2 Data

This appendix describes Visa standards for the contents of Track 2 of the magnetic stripe
and the magnetic stripe image on the integrated chip. Visa requirements conform to ISO
811 2 and ISO 7813.
B.1 Track 2 Content Requirements

Requirements for the contents of a magnetic stripe conform to ISO 7813.
B.1.1 Magnetic Stripe Encoding Requirements
 The magnetic stripe on a Visa card or Visa Electron card (including Instant Issue and
Prepaid cards) must be encoded on both Track 1 and Track 2, as specified in this
manual.
 Magnetic stripe data encoding must begin in sequence from the right-hand side of the
card as viewed from the back, with the encoded tracks at the top.
 Service Code values must be encoded on a Visa card or Visa Electron card, as
specified in this manual. An issuer may encode its Card acceptance policies in the
Service Code field of the magnetic stripe using all valid Service Codes.
 The centerline of the first data bit (start sentinel) to be recorded on the magnetic stripe
must be 7.44mm ± 0.51mm from the right edge of the Visa card or Visa Electron card.
The centerline of the last data bit to be recorded on the magnetic stripe must not
extend closer than 6.93mm from the left edge of the Visa card or Visa Electron card.
 The lead-in to the first data bit and the distance from the last data bit to the end of the
magnetic stripe must be clocking bits (i.e., zeroes).
 Data on the magnetic stripe must be encoded at 210 bits per inch on Track 1 and 75
bits per inch on Track 2, and contain at least the required information in the various
fields as specified in this manual.
 All of the following must conform to ISO 7811 2:
 Physical properties
 Performance characteristics
 Density
 Signal level
 Recording angle tolerances
 Error detection
 Permissible surface variation
 Character sets
 Appearance of the magnetic stripe

B.2 Record Format

An Issuer must comply with the Track 2 encoding requirements as contained in this
appendix. Table B-1 displays the Track 2 record format. The maximum length of Track 2 is
40 characters, which must include the Start Sentinel, field separator, End Sentinel, and
Longitudinal Redundancy Check (LRC).
Table B-1: Track 2 Record Format
Field Number Length Field Name
11 1 Start Sentinel
2 12 to 19 Primary Account Number (PAN)
3 1 Separator
4 4 Card Expiration Date
5 3 Service Code
6 0 or 5 PIN Verification Data
7 varies 2 Discretionary Data 3
81 End Sentinel
91 1 Longitudinal Redundancy Check (LRC)
B.3 Character Set
Table B-2 describes the Track 2 character set. This table corresponds to the character set table
in ISO 7811 2, section 10.1.3.
The hardware manufacturer specifies the data formats provided to an encoding machine. The
encoding device must encode data characters using odd parity. Clocking bits for synchronization
are not considered data.
1
Fields 1, 8 and 9 are not sent in online messages but are necessary for magnetic stripe-reading devices.
2
The length depends on the lengths of fields 2 and 6. Refer to section B.5.
3
Contains the 3-digit Card Verification Value (CVV) or optional iCVV on a chip.

An even-parity LRC character must be the last character in a track record.

NOTE: bn = bit position number “n.” Table B–2: Track 2 Character Set.
Table B-2: Track 2 Character Set (1 of 2)
Char.
Binary
P 23 22 21 20
0 1 0 0 0 0
1 0 0 0 0 1
2 0 0 0 1 0
3 1 0 0 1 1
4 0 0 1 0 0
5 1 0 1 0 1
6 1 0 1 1 0
7 0 0 1 1 1
8 0 1 0 0 0

Table B-2: Track 2 Character Set (2 of 2)
Char. Binary
P 23 22 21 20
9 1 1 0 0 1
: 1 1 0 1 0
; 0 1 0 1 1
< 1 1 1 0 0
= 0 1 1 0 1
> 0 1 1 1 0
? 1 1 1 1 1
NOTE: This coded character set is identical to the coded character set in ISO/IEC 7811 6
and is derived from ASCII

B.4 Encoding Examples

This section contains three examples of Track 2 encoding, illustrated in Figures B-1, B-2
and B-3.
 Figure B-1 illustrates encoding with the PIN Verification Data field and the Discretionary
Data field including the CVV in the first three positions of the field. This is an example
of an Interlink mark appearing on a Visa debit card.
 Figure B-2 illustrates encoding without the PIN Verification Data field and with the
Discretionary Data field containing only the CVV (remainder of the field is truncated).
This example also contains an expiration date of December 2002.
 Figure B-3 illustrates encoding with the PIN Verification Data field and the Discretionary
Data field containing issuer information in the first three positions of the field, followed
by the CVV. This example represents a Track 2 using the maximum allowable position.
NOTE: These examples provide a sample format only and should not be followed literally
when encoding Track 2 of the magnetic stripe.
Example: Encoding With PIN Verification Data, Discretionary Data and CVV.
 PAN: 4000 0012 3456 7892 (16 digits)
 Discretionary Data: 87623456 (first three positions = CVV)
Figure B-1: Encoding With PIN Verification, Discretionary Data and CVV
10 20 30 40
M4 0 0 0 0 0 1 2 3 4 5 6 7 8 9 2 U 9 8 1 2 1 0 1 5 4 3 2 1 8 7 6 2 3 4 5 6 9
LRC
Start
Sentinel End
Sentinel
Discretionary Data
PAN PIN Verification Data
Separator Service Code
Expiration
Date
Example: Encoding With Discretionary Data Field (CVV Only)

• PAN: 4000 0012 3456 7892 (16 digits)
• Expiration Date: 12/02
• Service Code: 120
• PIN Verification Data: none
• Discretionary Data: 876 (CVV only)
Figure B-2: Encoding With Discretionary Data

10 20 30
M4 0 0 0 0 0 1 2 3 4 5 6 7 8 9 2 0 0 2 1 2 1 2 0 8 7 6 5
LRC
Start
Sentinel End
Sentinel
Discretionary Data
(CVV Only)
PAN
Service Code
Separator
Expiration
Date
Example: Encoding With PIN Verification Data and Discretionary Data Fields
 PAN: 4000 0012 3456 7890 122 (19 digits)
 Discretionary Data: 876999 (first three positions = CVV; remaining positions are
truncated; second three positions = issuer information)

Figure B-3: Encoding With PIN Verification and Discretionary Data
B.5 Data Element Descriptions

This section describes the data elements encoded on Track 2. Table B-3 describes the
Start Sentinel.
Table B-3: Field 1—Start Sentinel
Attributes 1 alphanumeric (numeric values only)
Description Indicates the initial data position on the track.
Valid value ; (semicolon)

Table B-4 describes the PAN data element encoded on Track 2 of the magnetic stripe.
Table B-4: Field 2—Primary Account Number (PAN)
Attributes 12 to 19 numerics
Description A series of digits used to identify a customer account or relationship. The first
digits of the Primary Account Number specify the Bank Identification Number
(BIN), which must be unique to the interchange system and network.
Valid value 0 to 9
Usage When encoded on the magnetic stripe, the PAN must not include any spaces
Table B-5 describes the Separator data element encoded on Track 2 of the magnetic
stripe.
NOTE: Use of multiple separators may cause problems in some acquiring systems.
Table B-5: Field 3—Separator
Description Indicates the end of a variable-length field such as the PAN field. Only one
separator is generally positioned on the track.
Valid value = (equal sign)

Table B-6 describes the Card Expiration Date data element encoded on Track 2 of the
magnetic stripe.
Table B-6: Field 4—Card Expiration Date
Attributes 4 numerics in the format YYMM
Description Year and month after which the card can no longer be used
Valid value YY must be 00 to 99
MM must be 01 to 12
Usage The YYMM format follows ISO conventions for machine-processed dates. All
cards with a Visa, Visa Electron, or Delta mark must have a finite expiration
date that is no more than 20 years from the date of card issue.
The expiration date on a Visa Card, Visa Electron Card, or Card bearing the
Plus Symbol must not be later than the expiration date of the Issuer's Public
Key, or any security feature containing an expiration date in a Chip, if one is
present on the Card.

Table B-7 describes the Service Code data element encoded on Track 2 of the magnetic
stripe.
Table B-7: Field 5—Service Code
Attributes 3 numerics.
Description A sequence of digits that, taken as a whole, is used to do the following:
 Define various service attributes

 Differentiate cards used in international or national interchange
 Designate PIN requirements
 Identify card restrictions
Valid value The values allowed are made up of three individual digits: 1, 2, and 3.
To be valid, each digit must be one of the acceptable values listed in

Table B-8. These service code values apply to Visa card products (Visa, Visa
Electron, Plus cards).
Not all combinations of individually valid digit values result in a valid service
code. Also, while a large number of service codes can be constructed from
these values, only specific service codes are authorized for individual Visa
card products. Table B-8 describes the service code values that are currently
valid for Visa card products. Table B-9 and Table B-10 describe the preferred
service codes by card product.
Table B-8 describes the Service Code Digit Value data element encoded on Track 2 of the
magnetic stripe.

Table B-8: Service Code Digit Value Descriptions (1 of 2)
1 0 Invalid for Visa card products
1 International Card
2 International Card—EMV chip, debit or credit
5 National use only
6 National use only—EMV chip, debit or credit
2 0 Normal authorization
2 Positive authorization

Table B-8: Service Code Digit Value Descriptions (2 of 2)
3 0 PIN required
1 Normal verification
2 Goods and services only
3 ATM only
6 Prompt for PIN if PIN pad present
Normal authorization means normal floor limits apply. Positive authorization means that the
transaction must go online, regardless of the merchant floor limit. Note that this applies
only to magnetic stripe read transactions.

B.5.1 Service Code Usage

Visa occasionally assigns additional service codes as other uses are identified. An issuer,
group of issuers, or country can apply to Visa for the assignment of additional service
codes for local, national, or international usage. Table B-9 describes valid service codes by
card product platform.
Table B-9: Valid Service Codes by Card Product Platform (1 of 2)
Visa Plus
Credit Co-Branded
and Co-Branded Visa Plus With EFT
Service Visa Visa Visa Check Travel ATM Processor
Code Debit Electron Interlink and Interlink Money Only Marks
101 Valid Valid
102 Valid
106 Valid Valid
120 Valid1 Valid2 Valid Valid Valid Valid
121 Valid1 Valid
122 Valid1 Valid
123 Valid
126 Valid1 Valid
201 Valid
202 Valid
206 Valid Valid
221 Valid1 Valid
222 Valid1 Valid
223 Valid

Table B-9: Valid Service Codes by Card Product Platform (2 of 2)
Visa Plus
Credit Co-Branded
and Co-Branded Visa Plus With EFT
Service Visa Visa Visa Check Travel ATM Processor
Code Debit Electron Interlink and Interlink Money Only Marks
226 Valid1 Valid
501 Valid
502 Valid
506 Valid
1 2
520 Valid Valid Valid Valid
522 Valid1 Valid
523 Valid
601 Valid
602 Valid
606 Valid
606 Valid
620 Valid Valid2
621 Valid1 Valid
622 Valid
623 Valid
626 Valid1 Valid

1
Clients that plan to issue embossed Visa Cards with an X2X service code or unembossed Visa Cards should
contact their Visa representative, as there are specific requirements regarding BINs and service codes for
these new programs.
2
Service codes X21 and X26 are recommended for Visa Electron. Issuers that plan to use X20 for Visa
Electron cards should contact their representative. Prior to using any service code ending in zero for Visa
Electron cards an Issuer must obtain Visa's prior consent.
Table B-10 describes the PIN Verification Data field encoded on Track 2 of the magnetic
stripe.
Table B-10: Field 6—PIN Verification
Description Used to verify a PIN. Generally called Visa PVV or PIN offset value.
Valid value Numerics 0 to 9
Position 1: PIN Verification Key Index (PVKI) = 0 or 1 to 6
Positions 2–5: PIN Verification Value (PVV)
Usage If not needed, the field can be omitted from the stripe.
If the issuer (BIN) uses the PIN Verification Service (PVS) for some, but not
for all issued cards, the PIN Verification Data field (both PVKI and PVV)
should be zero-filled on those cards not using the PVS. If the issuer does not
use the PVS for any cards in a card range, the zero-fill requirement is not
needed.
Refer to Chapter 6 for more information on the PVKI and PVV.

Figure B-4 illustrates a 16-digit PAN and a 5-position PIN Verification field.
Figure B-4 PIN Verification Field
Table B-11 describes the Discretionary Data element encoded on Track 2 of the magnetic
stripe.

Table B-11: Field 7—Discretionary Data
Up to 17 numerics; remaining digit positions can be three positions for CVV.

Attributes
Includes the Card Verification Value (CVV or iCVV) plus any valid information that the
Description issuer wants to have transmitted in the transactions.
CVV is required on Track 2 of all Visa, Visa Electron, and Plus cards. For chip cards,
either the CVV or iCVV must be encoded in the magnetic stripe image. (The magnetic
stripe image contains the card’s magnetic stripe Track 2 data equivalent.)
Any valid non-control or non-reserved character listed in

Valid value Table B-1.
On Track 2, the maximum length of this optional field is based on the length of the
Usage Primary Account Number (PAN) and on the presence or absence of the PIN
Verification field. Because Discretionary Data fields are optional, they should not be
filled with pad characters solely with the intent to fill all positions on Track 2.
The 3-digit CVV must be encoded in the Discretionary Data field. While Visa
recommends placing the CVV at the start of this field, any three contiguous positions
can be used. Figure B-5 illustrates the recommended placement of the CVV in an 8-
digit Discretionary Data field. iCVV is optional for chip.
Note: If Visa is to provide CVV or iCVV (chip card only) validation for an issuer, the
issuer must provide Visa with the location of the CVV or iCVV (chip card only) on
Track 2 for verification purposes. The issuer describes the location by giving its
displacement from the end of the Service Code field. For example, in Figure B-5, the
displacement is 5. If the PIN Verification field was not encoded on the stripe, the
displacement would be 0. For details on calculating the CVV or iCVV, refer to
Chapter 2.
Note Track 1 Discretionary Data is defined in EMV and VIS as the discretionary data portion
of the magnetic stripe track 1 according to ISO-7813. However, the definition of Track
1 Discretionary Data as defined in this manual (Visa PTSM) is not the same as the
definition in ISO-7813.
The Visa PTSM definition of Track 1 Discretionary Data excludes the PVKI, PVV, and
the Visa Reserved field from its definition of Track 1 Discretionary Data. The Visa
PTSM definition of Track 1 Discretionary Data is thus a subset of the Track 1
Discretionary Data defined by ISO-7813.
The Visa PTSM Track 1 record format has the Service Code followed by the (optional)
5-digit PVKI and PIN Verification Value (PVV), followed by the Discretionary Data,
followed by the Visa Reserved field, and then followed by the End Sentinel.
If Track 1 Discretionary Data is personalized:
 For VSDC (i.e., EMV/VIS), it shall be personalized as defined in ISO-7813 (that is,
including the PVKI, PVV, and Visa Reserved fields).
For MSD, it shall be personalized as defined in the Visa PTSM (that is, excluding the
PVKI, PVV, and Visa Reserved fields).

Figure B-5: Discretionary Data Field
Table B-12 describes the End Sentinel element encoded on Track 2 of the magnetic stripe.
Table B-12: Field 8—End Sentinel
Description Indicates the final data position on the track.
Valid value ? (question mark)

Table B-13 describes the Longitudinal Redundancy Check element encoded on Track 2 of
the magnetic stripe.
Table B-13: Field 9—Longitudinal Redundancy Check (LRC)
Attributes 1 digit 0 to F
Description Verification value that ensures that no data has been lost in the stripe-reading
process. The LRC is equivalent to a check digit of the entire track including the
control characters.
Valid value Any computed value
Usage The LRC character is calculated using the following procedure:
 The value of each bit in the LRC character, excluding the parity bit, is
defined such that the total count of 1 bit encoded in the corresponding bit
location of all characters of the data message, including the Start Sentinel,
data, End Sentinel, and LRC characters, is even.
 The parity bit in the LRC character is not a parity bit for the individual parity
bits of the data message: it is the parity bit for the LRC character.

Appendix C Global ATM Requirements

Appendix C contains device-specific requirements for ATMs excerpted from Chapter 6,
Acquirer Participation Requirements, of the Visa Global ATM Member Guide.
C.1 Acquirer Participation Requirements

An acquirer planning to implement the VSDC program, and all chip-reading devices, must
meet the requirements specified in the Visa Operating Regulations, the EMV Integrated
Circuit Card Terminal Specification for Payment Systems, and the Transaction Acceptance
Device Requirements.
Participation requirements differ in Visa Central Europe, Middle East, and Africa (CEMEA),
and Visa Europe, as specified in Section C.3, Regional Differences.
C.1.1 Physical Security Requirements

The Visa standard is a numeric keypad. The PIN block format and PIN-pad layout must
conform to the Visa requirements specified in the Payment Technology Standards Manual.
Keypad requirements differ in Visa Canada and Visa U.S.A., as specified in Section C.3,
Regional Differences.
C.1.2 Processing Requirements

Acquirers must accept both Visa cards and Plus cards, unless prohibited by law.
Acquirer processing participation requirements differ in Visa Canada, as specified in

Section C.3, Regional Differences.
C.1.3 Card Verification Value Service

All ATM acquirers must participate in the Visa CVV service. All acquirers must submit full,
unaltered track 2 data in an authorization request for a magnetic stripe transaction and
enter the value in V.I.P. Field 22—POS Entry Mode Code to indicate a magnetic stripe
transaction with full, unaltered data.
VSDC acquirers must include Track 2 Equivalent Data read from the chip and enter the
value in V.I.P. Field 22—POS Entry Mode Code to indicate a contact chip transaction.
VisaNet applies the same edit criteria to chip card transactions that are used for magnetic-
stripe-read transactions.
Plus transactions must be submitted with the correct POS Entry Mode Code value
indicating that the data is reliable for CVV checking to occur.

C.1.4 Minimum Cash Disbursement Requirements

An ATM must be able to make a minimum cash disbursement as determined by the
acquirer per day, per cardholder account. An acquirer must allow the cardholder the option
to obtain a minimum cash disbursement as determined by the applicable Visa operating
regulations in a single transaction.
Minimum cash disbursement requirements differ in the Visa Europe region for V PAY as
specified in Section C.3, Regional Differences.
C.1.5 PIN Support

An ATM acquirer must be able to process PINs of four, five, and six digits. At its option, an
ATM acquirer may process PINs up to 12 digits in length.
PINs are required for all ATM transactions. ATMs must support online PIN.
A chip ATM acquirer must ensure that all chip-reading ATMs:
 Support encrypted PIN verified online
 Do not support signature, offline PIN, or No CVM Required

PIN support requirements at ATMs differ for Visa Europe and Visa U.S.A., as specified in
C.1.6 Technology Requirements

An ATM used to obtain authorization through the V.I.P. System must be able to read the
magnetic stripe or chip of a card as specified in the following manuals:
 Payment Technology Standards Manual
 EMV Integrated Circuit Card Terminal Specification for Payment Systems
 Visa Integrated Circuit Card Specifications
C.1.7 Track 2
A magnetic-stripe-reading ATM must read and transmit the entire contents of track 2 of the
card, unaltered.
For chip-initiated transactions, the ATM acquirer must transmit all data elements that create
the EMV online card authorization cryptogram.
Track 2 requirements differ for Visa Europe for V PAY, as specified in Section C.3,
C.1.8 Retrieval Reference Number

An ATM acquirer must generate a retrieval reference number value containing a date
(YDDD) corresponding to the local transaction date (positions 14).

C.1.9 Service Codes

ATMs that read the magnetic stripe must send all transactions online to the issuer for
authorization and must not prevent the acceptance of a card encoded with an unrecognized
Service Code. An ATM acquirer must ensure that all EMV-compliant chip-reading ATMs
examine and act upon Service Codes to recognize EMV-compliant chip cards. Visa and
Plus cards may be encoded with Service Codes as described in the Visa operating
regulations and the V.I.P. System manuals. These codes should not be used to edit or
reject ATM transactions.
C.1.10 Expiration Dates

An ATM acquirer:
 Must not edit expiration dates
 Must not return or decline an ATM transaction based on the expiration date
 Must obtain an authorization response from an issuer for all authorization requests
originating from an expired card
C.1.11 Account Numbers

An ATM and acquirer ATM processing system must be able to accept all valid International
Organization for Standardization (ISO) PANs 1119 digits in length, starting with any digit
from 0 through 9.
An acquirer must not:
 Perform any modulus-10 check digit validation
 Edit the length of the PAN
C.1.12 Card Acceptance

A Visa ATM must accept Visa Electron and Plus cards.

C.1.13 ATM Access Restrictions

An ATM acquirer certified to accept Visa and Visa Electron cards may selectively deny
access to its ATMs if the card presented is issued to residents of the country where the
ATM is located and billed in the local currency.
An ATM with restricted access must display language with the Visa brand mark that
identifies the ATM acquirer and describes card acceptance or the nature of any restrictions.
The ATM must display:
 The names of the issuers whose cards are not accepted
 The cards that the ATM accepts
 Any related restrictions

Screen messages may be used to supplement the information contained on such signage.
Display of the Visa brand mark on ATMs with restricted access requires the prior written
consent of Visa.
No restrictions on the acceptance of Visa TravelMoney cards are permitted.
At the discretion of its Regional Board, an ATM acquirer that accepts Plus cards may
selectively deny access to its ATMs.
Operating regulations for ATM access restrictions differ in Visa Europe, as specified in
C.1.14 Screen Message Requirements

An ATM acquirer may choose the messages displayed at its ATM. Visa recommends that
messages be displayed in at least two languages, one of which is English.
Each ATM must be capable of communicating, at a minimum, the following information:
 CARD INVALID FOR THIS SERVICE
 SERVICE UNAVAILABLE NOW
 INVALID PIN—RE-ENTER
 CARD RETAINED (if card retention is supported by the ATM)
C.1.15 Acquirer Timeouts

Neither an ATM nor an acquirer’s host system may time out a transaction in less than 45
seconds.

C.1.16 Support for Dip Readers at ATMs

Some ATM manufacturers provide the option of dip readers (i.e. the cardholder inserts the
card and then withdraws the card manually). These readers are primarily provided for lower
volume and lower cost models.
The cardholder experience in the magnetic-stripe world for dip readers has been for the
cardholder to dip the card and then remove it before proceeding with the transaction.
Unfortunately when the card is a contact chip card this same process creates problems.
For a chip transaction the card needs to stay in the reader for the duration of the
transaction otherwise it may lead to a fallback scenario.
Acquirers and ATM manufacturers should consider including a different cardholder

message sequence when a chip card is used. After the initial INSERT CARD message is
displayed, once the insertion is detected a message showing PROCESSING. PLEASE
LEAVE CARD IN READER should be displayed to ensure the cardholder does not remove
the card. Once the transaction is complete a PLEASE REMOVE CARD message can be
displayed.
The above messaging will reduce the chances of a transaction terminating early due to
card removal. However acquirers and issuers in markets operating in markets where dip
readers may be present should consider some additional cardholder education regarding
the use of their cards at ATMs.
C.1.17 ATM Card Readers and PIN

If the ATM has a dip type card reader, where the cardholder inserts and then immediately
removes his card to begin a transaction, then the ATM should only allow a single
transaction, after the consumer enters their PIN. Transaction chaining should not be
allowed on dip card reader ATMs. This insures that the ATM does not allow the next
consumer that walks up to the machine to transact on the previous cardholders account.
If the ATM has a motorized reader that when inserted into the ATM, is not returned to the
consumer until the end of the transaction sequence, a single PIN entry can be allowed for
multiple transactions, before returning the card to the consumer, as long as the PIN is sent
to the issuer for PIN verification, prior to any transaction being performed by the consumer.
C.1.18 Account Selection

An acquirer may offer account selection options to Visa, Visa Electron, and Plus
cardholders.
If no account selection is offered, the acquirer must process the transaction with the No
Account Specified value in V.I.P. Field 3—Processing Code of the authorization request.
The issuer has the option of returning a different Processing Code in V.I.P. Field 3 of the
authorization response. It is important to note that a dual-message acquirer may use this
information to print on the customer’s receipt, but must send the original “No account
specified” Processing Code in the BASE II clearing message. Receipt of the “No account
specified” Processing Code is the only time that the issuer has the option to change the
Processing Code in the response message.

If the acquirer offers account selection, Visa recommends that the acquirer provide the full
range of options corresponding to the Processing Codes available. These options are:
 Checking account or current account
 Savings account
 Credit card account

The acquirer must send the Processing Code corresponding to the cardholder’s selection,
unaltered, in the authorization message. In all subsequent messages (that is, reversals,
chargebacks, and so forth), the acquirer must use the same Processing Code as in the
original authorization request.
Additional account selection requirements in Visa U.S.A. are specified in Section C.3,
C.1.19 Transaction Receipt Requirements

An ATM must offer a transaction receipt for each ATM cash disbursement, as specified in
the Visa operating regulations, unless the paper supply is empty or a hardware malfunction
prevents production of a transaction receipt. The transaction receipt must include the
following information:
 ATM acquirer name or name of affiliated or domestic regional network, or both
 ATM street location or location code
 ATM city and country (or province or state, if applicable)
 Transaction amount indicated in transaction currency
 PAN (at least four digits must be truncated or masked)
 Type of account accessed
 Transaction date
 Authorization code
 Transaction type (cash disbursement)

For chip-reading ATMs, the cardholder receipt also contains the AID of the selected
application. If the device supports the character set used for the application Preferred
Name, this should also be printed on the receipt; otherwise the Application Label should be
printed.
The full PAN must not be printed on the transaction receipt. At least four digits must be
truncated or masked. Visa strongly recommends disguising or suppressing all but the last
four positions of the PAN.
If an ATM cannot produce a transaction receipt and has the ability to cancel a transaction
before it dispenses cash, it must allow the cardholder to request this option.

Transaction receipt requirements differ in Visa CEMEA and Visa Europe, as specified in
C.1.20 EMV Data Requirements

An ATM acquirer that processes chip card transactions must:
 Identify the chip-initiated transaction in the authorization and clearing record.
 Use the appropriate value of the POS Entry Mode Code to indicate a contact chip
transaction.
An acquirer must ensure that the chip-initiated transaction contains all data elements that
create the EMV online card authorization cryptogram.
For full details on the required data elements, acquirers should refer to the Visa Smart
Debit/Credit Member Implementation Guide for Acquirers and the Visa Smart Debit/Credit
System Technical Manual, or contact their Visa representative.
In addition, the acquirer must ensure that the EMV-compliant chip-reading device:
 Is capable of reading a magnetic stripe and, before performing any other processing of
the magnetic stripe data, must act on the Service Code to determine if a chip is
present.
 Reads the chip if an EMV-compliant chip is present. The magnetic stripe may be read
first, but the data may be transmitted from the magnetic stripe only if the chip is not
EMV-compliant, if the chip reader is inoperable, if the chip malfunctions at some point
in the transaction, or if the chip cannot be read at all (magnetic stripe fallback).
 Sends transactions online to the issuer for authorization.
 Uses online PIN for the CVM. No offline data authentication or offline PIN processing is
allowed.
 Is capable of sending Issuer Scripts to the card if the issuer sends them in the
authorization response.
 Supports the Visa Debit/Credit, Visa Electron, and Plus AIDs.
 Displays only a list of the card applications that the acquirer can support.

C.2 Transaction Exceptions

The following section describes transaction exceptions that occur while the cardholder is at
the ATM.
C.2.1 Reversals
To ensure that the funds availability or cardholder open to buy is not negatively impacted,
an acquirer must process a reversal in the following situations:
 The ATM fails to dispense any funds following an approval response.
 The cardholder cancels the transaction, or the transaction is canceled for any other
reason after the authorization request has been sent.
 The acquirer does not receive a response to an authorization request prior to a timeout
by the host or ATM.
 The acquirer receives an approval response after it has been timed out by the host or
ATM.
 The transaction is declined by the chip card after an authorization approval has been
received by the ATM. This will only occur if the chip card performs issuer
authentication, which fails, and the card has been personalized to decline transactions
in the event of issuer authentication failure.
In all cases, the reversal amount must be the same as the original transaction amount.
C.2.2 Misdispense
For a misdispense, the ATM acquirer must advise the issuer as follows:
 Single-message ATM acquirers must use an adjustment transaction with a message

reason code to indicate that a misdispense has occurred.
 Dual-message ATM acquirers must process a BASE I ATM confirmation message for
the actual amount dispensed if the misdispense is detected prior to the submission of
the BASE II clearing record. If the error is identified after submission of the clearing
record, the acquirer must reverse the original TC 07 and resubmit a new TC 07 with the
actual dispensed amount.
ATM misdispense processing differs for Visa U.S.A., as specified in Section C.3, Regional
Differences.
C.2.3 Card Retention

An ATM is not required to have the ability to retain cards, but if the ATM is able to retain
cards, it may do so only upon the specific request of the issuer.

C.2.4 Issuer-Requested Card Retention

If a card is legitimately retained, it must be logged under dual custody immediately after
removal from the ATM and rendered unusable. If the card bears a chip, the chip must not
be damaged. If the card is either a Visa or Visa Electron card, it must be returned to the
issuer. An acquirer may collect a handling fee of US $15 for returning the card. This fee can
be collected through the use of a BASE II TC 10 or V.I.P. 0220 advice.
If the card bears only the Plus symbol, the acquirer must dispose of the card after it is
rendered unusable. Handling fees do not apply for Plus-only cards.
C.2.5 Erroneous ATM Card Retention

If a hardware or software failure causes mistaken or accidental card retention, the ATM
acquirer must return the card to the cardholder, if requested, after reviewing positive
cardholder identification and, where possible, comparing the cardholder’s signature to that
on the card signature panel. If the cardholder does not request return of the card within
seven business days, the acquirer must follow the card retention rules specified in this
appendix.
C.3 Regional Differences

This section outlines regional differences.
C.3.1 Participation Requirements

Visa CEMEA and Visa Europe—All newly installed ATMs that accept Visa and Visa
Electron symbol cards must be EMV compliant.
C.3.2 Physical Security Requirements

Visa Canada and Visa U.S.A.—The keypad must be in alphanumeric format.
C.3.3 Processing Requirements

Visa Canada—ATM acquirers certified to accept cards bearing the Plus symbol are granted
a variance and are not required to also accept Visa cards.
C.3.4 Minimum Cash Disbursement Requirements

Visa Europe—V PAY has a minimum cash disbursement amount.
C.3.5 PIN Support

Visa Europe—An ATM acquirer must ensure that all ATMs displaying the V PAY brand
mark:
 Are EMV compliant

 Support online PIN
 Do not support signature, offline PIN, or No CVM Required

Visa U.S.A.—An ATM acquirer must accept and transmit PINs that are 4 through 12
alphanumeric characters long.
C.3.6 Technology Requirements, Track 2

Visa Europe—For non-chip-initiated transactions, if a chip card cannot be read, the ATM
acquirer must complete the transaction as a Plus transaction if Plus data is present on the
magnetic stripe. If the magnetic stripe cannot be read, the transaction must not be
processed.
C.3.7 ATM Access Restrictions

Visa Europe—An ATM displaying the V PAY brand mark must accept all valid V PAY
cards.
C.3.8 Account Selection

Visa U.S.A.—An ATM must offer the following choice of account types and cardholder
services, unless prohibited by local law:
 Cash disbursements—checking, savings, and credit accounts
 Balance inquiries—checking, savings, and credit accounts
 Transfers between accounts—checking and savings accounts
C.3.9 Transaction Receipt Requirements

Visa CEMEA—A participating ATM that does not routinely produce a transaction receipt is
not required to do so. A participating ATM that does produce a transaction receipt is not
required to include the complete PAN on the transaction receipt.
Visa Europe—A participating ATM that does not routinely produce a transaction receipt is
exempt from producing a receipt.
C.3.10 Misdispense
Visa U.S.A.—If a misdispense occurs, an acquirer:
 May, in order to be protected from issuer chargeback rights, process an adjustment

within 10 calendar days of the central processing date of the original transaction by
submitting a transaction that adjusts the cardholder’s account for the amount of the
misdispense.
 Must process an adjustment within 45 calendar days of the central processing date of
the original transaction by submitting a transaction that adjusts the cardholder’s
account for the amount of the misdispense.

Appendix D Device Performance for EMV Transactions

Appendix D discusses various factors that are under the control of the device implementer
(either the application developer or system integrator) to increase the speed of
authorization, thus enhancing the cardholder experience while providing reduced
transaction and queue times for the merchant. The many direct factors that influence
device performance include clock speed, word size, and programming language used.
EMV functionality is only one part of the point-of-service application as a whole. Poorly
executed systems integration can easily overshadow the most efficient EMV kernel. Device
vendors should take into consideration any opportunity to overlap EMV and non-EMV
functions. For example, a dial device may be able to pre-dial while EMV processing is
being completed, particularly if online processing is required, by use of online PIN or
because of terminal risk management.
Online authorizations can be optimized through implementation of fast communication

technologies (such as always-on or broadband). In many cases, the benefits of customer
satisfaction and higher throughput can offset additional communication costs.
The cardholder experience is the final measure of acceptable performance. This

experience is based on the synergy, or lack thereof, of all factors, and no one factor can be
singled out. Vendors who do not produce a device appropriately responsive to a bank or
merchant’s customers are likely to be negatively affected in the market place.
EMVCo has documented best practices in the EMV Optimising Contact Chip Transaction
Times Best Practices, available at www.emvco.com.
D.1 Device Factors Influencing Transaction Duration

A device that supports VSDC cards must provide fast, efficient processing of contact chip
transactions. As a best practice, the application transaction time for VSDC cards should not
exceed the time for the same type of transaction performed online with magnetic stripe
cards. Optimal transaction times for different countries may vary.
D.1.1 Cryptographic Factors

RSA processing is the single largest component of the processing impact of EMV
functionality. Cryptographic efficiency can be achieved with specialized electronics,
whether exponentiation circuitry, dedicated cryptographic Application Specification
Integrated Circuits (ASICs), Security Application Modules (SAMs), or other alternatives.
The cost considerations of these alternatives, however, may drive vendors to attempt RSA
processing in the mainline application within the main processor chip.
In these cases, it is crucial to use efficient algorithms. The specialized knowledge required
to develop such algorithms may make it cost efficient to license the intellectual property
rights to use algorithms developed by specialists in the field. The importance of efficient
RSA operations can be shown by how often the processing is invoked, for example:
 An SDA transaction has two RSA device operations: one with the VSDC CA Public Key
and one with the issuer public key.

 A DDA or CDA transaction has three RSA device operations: one with the VSDC CA
Public Key, one with the issuer public key, and one with the ICC public key. There is
also one ICC operation that uses the ICC private key.
 A DDA and offline enciphered PIN transaction where the same ICC key is used for
enciphered PIN and DDA involves four RSA device operations: one with the VSDC CA
Public Key, one with the issuer public key, and two with the ICC public key. In addition,
two ICC operations use the ICC private key.
 When different ICC keys are used for offline enciphered PIN and DDA, the transaction
has five RSA device operations: one with the VSDC CA Public Key, two with the issuer
public key, and two with ICC public keys. Again, two ICC operations use ICC level
private keys.
Because EMV processing is only a part of the point-of-service application, it may be cost
efficient to have the processing performed by SAMs or co-processors. Co processors
optimized for cryptographic functions can offload a significant amount of the overall
processing demand and may be a more cost-effective alternative to upgrades to the main
processing chip.
RSA cryptography is considerably more demanding than DES processing. Co processors

that are sufficient for DES processing, such as those residing in a tethered PIN pad or
integrated security module, may be inadequate for the RSA components in offline
enciphered PIN processing.
D.1.2 Communications Speed to Cards

The communication speed between a card and a device can impact transaction throughput.
With EMV 3.1.1, this speed is set, but EMV 4.1 allows higher speeds (smaller dividers) and
EMV 4.2 requires this support. Devices should support EMV 4.1 or higher, where possible,
to take advantage of higher throughput.
D.1.3 Application Optimization

The demands of EMV processing, particularly RSA functions, require that efficient coding
techniques be employed. Efficient coding may be one of the most significant factors in
producing responsive applications.
Field experience has shown that applications developed with a primary focus on simply
providing EMV functionality can often be dramatically improved by undertaking an
optimization effort. (Optimization often suffers when code is produced against tight
deadlines.) For EMV functionality, it is important to focus on efficiency of the RSA
algorithm, particularly if it is implemented in software to be executed on the main
processing chip. Because of the mathematical expertise required to develop truly efficient
code, some vendors have found it more cost effective to purchase RSA implementations. In
house developers should be familiar with efficient squaring techniques, as those discussed
in Bruce Schneier’s Applied Cryptography.
It is equally important that the application integrator, combining the EMV kernel with
existing customized applications, pay attention to performance implications.

D.2 Process Overlap: Multitasking or Interleaving

The device application developer must look for opportunities for true multitasking or at least
for apparent multitasking, such as performing processing while waiting for a manual action
from either the cardholder or the merchant. Effective process interleaving can also have a
significant impact on overall throughput, thus compensating for other deficiencies.
Transactions should be initiated as soon as the card is inserted into the device.
Taking advantage of wait times in one process to work on another process, such as
overlapping SDA or DDA processing with PIN entry, is another important technique for
speeding throughput. Vendors have a long history of exploiting opportunities to overlap
processing. The relative novelty of EMV processing brings new challenges and
opportunities. Pre-printing of receipt headers, pre-dialing of authorization numbers, and
taking advantage of human interactions such as amount and PIN entry continue, however,
to provide opportunities to present the appearance of prompt throughput to the consumer.
The device should also be prepared to take advantage of information in the records
presented by the card as soon as it is available. For example, if the card has the CVM List
as one of the first records read, preparation for CVM processing can begin (prompt for PIN)
and possibly online processing (if online PIN is the mutually supported CVM). Other useful
pieces of data are the PAN (for additional controls based on BIN), issuer’s country code (for
domestic or international considerations), and Application Usage Control (for environmental
restrictions, such as ATM-only applications). Evaluating processing restrictions early in the
flow of records may allow the device to avoid unnecessary processing. The device may
also begin pre-dialing if an online transaction is likely.
Once the appropriate information is read during the read-data phase and at any time prior
to terminal action analysis, the device can process the steps for offline data authentication,
processing restrictions, cardholder verification, and terminal risk management in any order
(see Figure D-1). Multitasking or interleaving can be used to optimize the processing of
these steps.
Certificate extraction should commence as soon as feasible. Application developers in

markets with a high percentage of domestic transactions and relatively few issuers may
want to consider caching extracted certificates. EMV requires that the issuer certificate still
be transferred from the card to the device, but caching can eliminate extraction time. (If a
VSDC CA key is updated, the cache should be emptied.)
A prompt for the PIN can also be used to confirm application selection and transaction
amount.
Transaction amount entry and PIN entry provide two opportunities for processing other
functions such as data authentication.
Switching the power off to the card after completion of the transaction instead of waiting for
the receipt to be printed allows the cardholder to remove the card while the receipt is being
printed. A message should be displayed to the cardholder when the card can be removed.

D.3 Speed of the Device

The processing power of a platform is roughly a combination of the clock speed (usually
expressed in megahertz, or MHz) of the main processor and the data word size (for
example, 8-bit, 32-bit). Sufficient processing power can reduce the criticality of previously
listed factors, such as communication speed and process overlap, but poor coding can
blunt the effect of a fast processor. Increasing the power of the main processing chip can
have significant cost implications and may not necessarily overcome poor application
architecture.
D.4 Card Interaction

Card-processing speed is dependent on the capability of the card and the clocking provided
by the device. All cards must support the range of clock speeds that are defined in EMV.
The clock speed supplied by the device, however, affects card-processing times,
particularly cryptographic processes (such as DDA, CDA, and enciphered PIN). Devices
should provide clocking at the highest allowable speed, currently 5 MHz.
D.5 Type of Programming Language Used

Modern application development is usually based on higher-level programming languages,
such as some variant of C. These languages allow greater programmer productivity, albeit
at some cost in application performance. The difference is usually not important with more
powerful processors.
Assembly languages can create more efficient modules, but they are more difficult to use in
the development and maintenance of applications. On the other hand, assembly languages
may allow lesser-powered processors to achieve acceptable response times.
Some programming languages produce static executables, while others may produce more
flexible interpretive modules. The static modules generally execute more efficiently.
D.6 Device and Application Architectures

Applications that are designed to support integrated POS environments may distribute EMV
processing across servers, tills, and transaction acceptance devices. Efficient processing
demands that sufficient power resides at each point to properly process transactions and
that sufficient communication capacity exists between components to avoid bottlenecks.
Techniques for application development may include pre-coded modules that can be
rapidly assembled into complex applications. This development speed may, however, affect
application performance.
D.7 Application Development Considerations

Other considerations for application development include:
 Project Deadlines—Project deadlines must be realistic. When deadlines for delivery of

new applications are overly ambitious, insufficient time and attention may be paid to the

previously discussed issues. Time must be allocated for both application development
and integration and for optimization efforts.
 Economic Factors—Optimizing a customized application may require additional

development costs, which may be unacceptable to the purchaser.
 Application Integration—The EMV kernel is only one functional area of the overall retail
or banking application. The intensive computation required for RSA processing is a
significant component of overall response time, but it is only one component and it
must be integrated with the overall application.
 International Requirements—Domestic markets may have little use for some features,
such as offline enciphered PIN. Applications that provide acceptable performance for
domestic requirements may not, therefore, be able to support international cards that
request functions not common in the local market. The acquirer or device deployer
needs to make an economic decision regarding provision of optimal support for these
features.
D.8 Transaction Receipt Requirements

To improve printing time, no more data should be printed on a receipt than is required by
Visa operating regulations and local law. The device should print as much of the receipt as
possible prior to completing transaction processing.
Subject to Visa operating regulations and local legislation, receipt printing may be optional,
(for example, under the small ticket program). Eliminating receipt printing, where feasible,
can improve transaction throughput.
NOTE: Receipts must be made available at cardholder request.
D.9 Retail Environment

Performance of an EMV kernel in a laboratory or a vendor’s development setting can only
partially reflect actual performance when the kernel is integrated with a payment application
and deployed in a retail environment. Device deployers are encouraged to set their own
transaction performance requirements and develop concise test scripts that reflect those
requirements. Vendors should demonstrate their ability to meet these requirements with the
application to be deployed in the market.

Appendix E EMV Tag to VisaNet Data Element

Mapping
Appendix E provides data mapping information between the EMV data elements and the
VisaNet (V.I.P. and BASE II) messages. (See the Visa Smart Debit/Credit System
Technical Manual.) It is intended for acquirers and vendors to help them understand the
new chip data required in the device-to-acquirer message and the acquirer-to-VisaNet
message. It may also be used by issuers in upgrading their hosts to support the new data.
For host data capture acquirers (including ATM and single-message acquirers), the
acquirer uses the authorization message to create the clearing message. The mapping of
information from the V.I.P. field to the BASE II field is, therefore, applicable and can be
used in creating the clearing message.
For data capture acquirers, the acquirer does not use the authorization message to create
the clearing message. Rather, the acquirer uses data from the device to create the clearing
message. The values for several of these data elements differ from their counterparts in the
authorization message, including the Card Verification Results, TVR and, in some cases,
the amount (either Cryptogram Amount or Amount, Authorized). The mapping of
information from the EMV/VSDC data element to the BASE II data element is, therefore,
applicable and can be used in creating the clearing message, but the mapping of
information from the V.I.P. field to the BASE II field is not applicable (especially for the
above-mentioned fields).
E.1 EMV Tag to VisaNet Data Element Mapping Table

Table E-1 highlights the following information:
 EMV Data Element—This column contains the name of the data element, as specified
in the EMV and VIS specifications.
 EMV Tag—This column contains the tag associated with the data element, as specified
in the EMV and VIS specifications.
 EMV Origin—This column specifies where the data element comes from (for example,
card or device).
 VisaNet Data Element—This column contains the name of the data element, as
specified in the VisaNet manuals.
 VisaNet Authorization Requirement—This column states whether the data element is

mandatory, optional, or conditional in the authorization message.
 VisaNet Authorization V.I.P. Field—This column outlines the V.I.P. field location for the
data element. For many of the chip data elements, the acquirer, issuer, or both has the
option to support the data element in the third bit map or Field 55. The information is
noted in this column.
 VisaNet Clearing Requirement—This column states whether the data element is

mandatory, optional, or conditional in the clearing message.

 VisaNet BASE II—This column outlines the BASE II field location for the data element.
The data element values must, therefore, not be altered or manipulated because they are
transferred from either the card or the device to the acquirer and then from the acquirer to
VisaNet in the online message. The device vendor must ensure that these data elements
have integrity in the device-to-acquirer message and the acquirer must ensure that they
have integrity in the online message to the issuer.
Table E-1: EMV/VisaNet Data Elements and Tags (1 of 7)
EMV Data VisaNet Authorization V.I.P. Clearing

Element Tag Origin Data Element Requirement Field Requirement BASE II
Amount 9F02 Device Cryptogram Mandatory 147 or Mandatory TCR 5,

Authorized (L 6) (Amount, Amount/ 55 pos.
Authorized Amount 20–31,
without Authorized or TCR
adjustments) (V.I.P.) 7, pos.
87–98
Authorized
Amount
(TCR 5,
BASE II)
Cryptogram
Amount
(TCR 7
BASE II)
NOTES:
 This must be the amount of the transaction, as used by the card to generate the
cryptogram.
 If the acquirer is not participating in Custom Payment Service (CPS), the acquirer can
provide the cryptogram amount (which is the amount used by the card to generate the
cryptogram) in Authorized Amount (TCR 5) or Cryptogram Amount (TCR 7). If both fields
are used, they should contain the same value. From a VisaNet perspective, if both fields
are present, the amount in Cryptogram Amount (TCR 7) is used for cryptogram validation.
If the acquirer is participating in CPS, the acquirer provides the cryptogram amount (which
is the amount used by the card to generate the cryptogram) in Cryptogram Amount (TCR
7). For these transactions, the amount provided in Authorized Amount (TCR 5) is used for
CPS purposes.
 The Amount, Authorized is placed in BASE II TCR 5, positions 2031, when the
cryptogram amount matches the authorized amount and in TCR 7, positions 8798, when
the cryptogram amount differs from the authorized amount. When the TCR 5 field is used
for cryptogram amount, positions 8798 in the TCR 7 are filled with spaces.

EMV Data VisaNet Authorization V.I.P. Clearing

Element Tag Origin Data Element Requirement Field Requirement BASE II
Amount, 9F03 Device Cryptogram Conditional 149 Conditional TCR 1, pos.

Other L6 (based on Cashback or 55 158–166
the cash Amount/
back amount Amount,
of the Other (V.I.P.)
transaction)
Cash back
(BASE II)
NOTE: Only applicable if the POS transaction is for purchase with cash back.
Application 9F26 Card Cryptogram/ Mandatory 136 Mandatory TCR 7, pos.
Cryptogram (L 8) Application or 55 49–64
Cryptogram
NOTE: The cryptogram is generated by the card and passed to the device in response to the GENERATE AC
command.
Application 82 Card Application Mandatory 13 or Mandatory TCR 7, pos.
Interchange (L 2) Interchange 55 45–48
Profile Profile
Application 5F34 Card Card Conditional 23 Conditional TCR 7, pos.
PAN (L 1) Sequence 7–9
Sequence Number
Number (L 2)
NOTES:
 If this tag is present on the card, the device must forward it to the acquirer in the device-to-acquirer
message and the acquirer must forward it to the issuer in the acquirer-to-VisaNet message unaltered.
 The Card Sequence Number must match what was received from the card or cryptogram validation fails.
Application 9F36 Card Application Mandatory 13 or Mandatory TCR 7, pos.

Transaction (L 2) Transaction 55 41–44
Counter Counter

VisaNet
EMV Data Data Authorization V.I.P. Clearing
Element Tag Origin Element Requirement Field Requirement BASE II
Authorization 8A Issuer (for Response Mandatory 39 Mandatory TCR 5,

Response online Code pos. 35–
Code authorizations) 36
Device (for
offline
authorizations)
NOTES:
 If the transaction is online authorized, the issuer provides the authorization response in V.I.P. Field 39. The
acquirer forwards the information to the device via Tag ‘8A’.
 If the transaction is offline authorized, the device provides the authorization decision to the acquirer in the
clearing message. The acquirer formats this information in the BASE II clearing message in the TCR 5. It
contains one of the following values:
 Y1 = Offline approved
 Y3 = Unable to go online; offline approved
 Other values include:
 Z1 = Offline declined
 Z3 = Unable to go online; offline declined
 Z1 and Z3 are not generally provided on clearing transactions as they represent declines.
Issuer 9F10 Card Issuer Mandatory 134 Mandatory Byte 1, pos.
Application (32 bytes Application or 55 117118;
Data of data for Data Bytes 23,
a total of pos. 6568;
33 bytes) Bytes 47,
pos. 7986;
Bytes 816,
pos.
101116;
Bytes
1732, pos.
119150
NOTES:
 The format of the Issuer Application Data may vary by card, but this is transparent to the acquirer.
 In authorization messages, expanded third bit map acquirers send the entire contents of the Issuer Application
Data as provided by the card in V.I.P. Field 134, which has been expanded to 33 bytes (1 byte length byte and
up to 32 bytes of data).
Issuer 91 Issuer Issuer Conditional 140 n/a n/a
Authenti- (L8–16) Authenti- or 55
cation Data cation Data
NOTES:
 If present in the response, it is present in the authorization response to the acquirer and the acquirer must
include it in the device-to-acquirer message.
 The content of the Issuer Authentication Data is transparent. It should be passed, as is, to the device. No
format conversion from EBCDIC to ASCII is required.

VisaNet
Issuer Script 9F5B Device (based Issuer Conditional 143 Conditional TCR 7,
1 Results on the results of Script or 55 pos. 159–
(L var.) applying the Results 168
issuer script)
NOTES:
 This data element is present only in reversals (0400) or clearing messages when there is an Issuer Script. It is
not present in authorization messages (0100/0200). The device sends this tag when there is a reversal.
 Reversal—If the issuer provides any Issuer Scripts in the response along with an approval authorization
response but the card overrides the issuer’s authorization with a decline, a reversal must be generated. The
reversal must contain the Issuer Script results if the authorization response contained any Issuer Scripts.
 Clearing—If the issuer provides Issuer Script in the response and the transaction is approved, the script results
must be provided to the issuer in the clearing message.
 If there is no reversal or clearing message from the device, Issuer Script Results are not provided by this tag.
The results of script processing are sent in the next online authorization in the Card Verification Results in Tag
‘9F10’, byte 4.
Issuer Script 71 (L var.) Issuer Issuer Conditional 142 n/a n/a
Template 1 Script or 55
NOTES:
 The issuer may provide this information in the response when applicable. The issuer provides Tag ‘71’ or ‘72’
(not both).
 If present in the response, the acquirer must forward it to the device in the device-to-acquirer message.
Issuer Script 72 (L var.) Issuer Issuer Conditional 14 or n/a n/a
Template 2 Script 55
NOTES:
 The issuer may provide this information in the response when applicable. The issuer provides Tag ‘71’ or ‘72’
(not both).
 If present in the response, the acquirer must forward it to the device in the device-to-acquirer message.

VisaNet
POS Entry 9F39 Device POS Entry Mandatory 22 Mandatory TCR 0,

Mode Mode Code pos. 162–
(V.I.P.) 163
POS Entry
Mode
(BASE II)
NOTE:
 Valid values are:
 01 – Manually entered PAN (customer present)
 02 – Magnetic stripe read and CVV may be unreliable (normally used only if full magnetic stripe cannot be
transmitted)
 05 – Chip transaction
 07 – Contactless using qVSDC rules
 08 – Manually entered PAN (mail order/telephone order/e-commerce)
 90 – Magnetic stripe read (full magnetic stripe transmitted in message)
 91 – Contactless using MSD rules
 95 – Chip transaction and CVV may be unreliable (normally used only VisaNet when it detects certain errors)
Chip n/a Device Chip Optional 60.3 Optional TCR 1,

Condition Condition pos. 167
Code Code
NOTES:
 For magnetic-stripe-read transactions, the valid values in this field are:
 0—Not applicable; subsequent subfields in V.I.P. Field 60 are present.
 1—Magnetic stripe Service Code begins with 2 or 6 and the last chip card read at chip-capable device was
either a successful chip read or the transaction was not a chip transaction.
 2—Magnetic stripe Service Code begins with 2 or 6 and the last chip card read at chip-capable device was an
unsuccessful chip read.
 For contact chip transactions, this field should not be present or should contain 0.
Terminal 9F33 Device Terminal Mandatory 130, Mandatory TCR 7,
Capabilities Capability or pos. 16–21
(L 3) Profile
55

VisaNet
Terminal 9F1A Device Terminal Mandatory 145 Mandatory TCR 7,

Country (L 2) Country or 55 pos. 22–
Code Code 24
Terminal n/a Device or Terminal Mandatory 60.2 Mandatory TCR 0,
Entry acquirer Entry pos. 158
Capability Capability
(V.I.P.)
POS
Terminal
Capabilities
(BASE II)
NOTE: The VisaNet chip value is to be used only if the device is capable of reading and processing the contact chip
data.
Terminal 9A (L 3) Device Terminal Mandatory 146 Mandatory TCR 7,
Transaction Transaction or 55 pos. 10–
Date Date/ 15
Transaction
Date
Terminal 95 (L 5) Device Terminal Mandatory 131 Mandatory TCR 7,
Verification (populated Verification or 55 pos. 69–
Results based on the Results 78
results of each
transaction)
Transaction 5F2A (L Device Authori- Mandatory 148 Mandatory TCR 5,
Currency 2) zation or 55 pos. 32–
Code Currency 34
Code/
Cryptogram
Currency
Code/
Transaction
Currency
Code
Transaction 9C (L 1) Device (based Cryptogram Mandatory 144 Mandatory TCR 7,
Type on the type of Transaction or 55 pos. 5–6
transaction) Type/
Transaction
Type
Unpredict- 9F37 Device Unpredict- Mandatory 132 Mandatory TCR 7,
able Number (L 4) able or 55 pos. 33–
Number 40

VisaNet
n/a n/a n/a Card Mandatory 60.7 n/a n/a

Authenticati
on
Reliability
Indicator
NOTE: Acquirers need to populate this subfield with the appropriate value indicating the integrity of
the cryptogram data.
n/a n/a n/a VSDC Mandatory 60.6 n/a n/a
Transaction
Indicator
NOTE: Acquirers need to populate this field correctly in either V.I.P. Field 55 or in the expanded third bit map.
Acquirers need to populate this field correctly in either V.I.P. Field 55 or in the expanded third bit map.

Appendix F Placement of Contactless Readers

Appendix F contains recommendations developed by Visa as general guidance for the
placement of contactless card reading devices in a merchant retail environment. These
recommendations are based on laboratory tests conducted on behalf of Visa and industry
best practices. They are intended to provide guidance to expedite contactless card reader
integration into a merchant POS environment and ensure efficient operation.
Where available, Visa has provided specific guidelines and placement recommendations.
Merchants should consult with their acquirers, Visa representatives, contactless card
reader manufacturers, and installation technicians to determine the optimal implementation
in their retail environments. There may be additional specific domestic and regional
placement recommendations and requirements. Merchants and acquirers are advised to
consult with their Visa representatives.
NOTE: If a device is to accept Visa contactless cards, the contactless device must be
tested by a Visa-recognized laboratory and receive an approval from Visa prior to its
placement in a merchant retail environment. Merchants should, in general, consult with
their acquirers and contactless card reader manufacturers to determine the current
approval status of their contactless card readers. See www.visa.com/industryservices for
lists of contactless card readers as they are approved.
F.1 Compliance With Local Regulatory Requirements

The contactless card reader must comply with all local market legal regulations ranging
from electromagnetic emissions to consumer privacy.
F.2 Proximity to RFID and Antitheft Devices

The contactless card reader should be placed so that it is not affected by radio frequency
identification (RFID) readers or antitheft devices. Many factors influence RF interference,
so that testing under a variety of conditions during deployment is advised. If feasible,
placing the reader at least 200 centimeters (80 inches) away from an antitheft RFID device
is recommended.
F.3 Proximity to Transmitting Devices

Active transmitting devices (for example, mobile telephones, personal digital assistants,
and pagers) can disrupt a contactless transaction if it is very close to a contactless card
while the card is attempting to communicate with a contactless card reader.
If the cardholder presents the contactless card while holding an active transmitting device
in the same hand, the transaction may be adversely impacted. The remediation is for the
cardholder to move the active transmitting device away from the contactless card and
reader and re-present the contactless card. A label or placard may be placed near a
contactless card reader to advise cardholders not to place an active transmitting device
close to a contactless card while it is communicating with a contactless card reader.

F.4 Susceptibility to Electromagnetic Interference

The contactless card reader should not be placed in close proximity to electrically powered
equipment that can generate electromagnetic interference or static electricity, (for example,
personal computers, lighted displays, cooking appliances, or refrigeration equipment).
To protect contactless cards from problems at the point of service, Visa recommends that:
 The POS device and contactless card reader power supplies are fitted with transient
arrestor devices for protection from power surges.
 As protection against interference, contactless card readers should not be placed near
equipment that switches inductive loads such as electrical distribution junctions.
 All electrically powered devices in use near a contactless card reader, (for example,
cash registers), should be regularly tested to ensure proper electrical grounding and
that there are no loose electrical connections or unshielded cables.
 Equipment that is improperly grounded or has exposed wiring could generate

electromagnetic interference, which could adversely impact the operation of a
contactless payment transaction.
F.5 Contactless Card Readers Mounted on Motor Vehicles

A contactless card reader that is mounted on a motor vehicle should be positioned away
from high voltage vehicle components such as ignition coils, ignition wires, and lamp relays.
The card reader power supply should be from an auxiliary source with voltage
filtering/smoothing. This protects the contactless card reader from potential interference
and ensures the efficient performance of the contactless payment transaction.
This recommendation applies to any deployment scenarios involving motor vehicles,

including buses or trains. Close proximity to a vehicle’s electrical systems or unshielded
internal electrical wiring, (for example, direct placement over the electrical system), could
have a negative impact on a contactless card reader's operation. Merchants should consult
with their acquirers, Visa representatives, contactless card reader manufacturers, and
installation technicians to determine possible sources of transaction interference.
F.6 Proximity to Metallic Material

Metallic material positioned between a contactless card and a contactless card reader may
prevent the card and reader from communicating. Visa recommends that the space in
between the card and reader should be clear of metallic material.
F.7 Proximity of Multiple Readers

Merchants should place contactless card readers at least 30 centimeters (12 inches) away
from each other. In retail locations where counter space is limited, the magnetic field of
multiple readers in close proximity may overlap, thus disrupting the contactless transaction
when a single contactless card is presented.

F.8 Proximity to EMV-Compliant Contact Chip Devices

Merchants should place the contactless card reader at least 15 centimeters (6 inches)
away from the EMV-compliant contact chip device (primarily for nonintegrated devices).
NOTE: Terminal and reader manufacturers should shield the part of the device that
contains the contactless card reader from the part of the device that reads the contact
chip card (for devices where the contactless reader is integrated in the EMV-compliant
contact chip device).

Appendix G Application Selection

This appendix outlines requirements and best practices for application section for
transaction acceptance devices.
G.1 General Application Selection

General application selection requirements and best practices include cardholder choice of
application, display of the selected application, routing and use of chip data, amount entry
prior to application selection and merchant interfaces.
G.1.1 Visa Multi-Application Cards

Requirement: Cardholder choice of application
If more than one application is supported by both the card and the device, the device must
not automatically select an application and use it to conduct a transaction independent of
cardholder input. Automatic selection is not allowed.
A device must enable the cardholder to choose which application to use. All mutually
supported Visa payment applications available must be displayed to the cardholder and the
device must proceed with the one chosen by the cardholder.
The only exceptions which allow automatic selection are:
 Contactless transactions
 Transactions on devices that are currently exempted by Visa Rules from use of a PIN
Entry Device (PED).
NOTE: Exempted devices may include road and bridge tolls, some vending machines
and UCAT in parking environments
 Transactions involving cards which Visa agrees can have their own specific rules for
Application Selection. This may be by commercial agreement with Visa or by Visa’s
acceptance of local industry standards or local commercial arrangements between
issuers and acquirers (e.g. co-badging with domestic debit schemes). See Section G.3,
Exemptions Allowing Card Specific Rules for Application Selection, for further details.
Requirement: Display of the selected application (POS and UCAT only)
If PIN entry is required, then following selection of the application, the device must display
the application name at the PIN entry step if it has sufficient display capacity to do so. This
acts as acceptance or confirmation of the application choice by the cardholder.
NOTE: If the transaction does not involve PIN entry, the receipt requirement described in
section G.1.10 will ensure that the cardholder is aware of which application has been
used.
Best practice: Cardholder choice whenever possible (POS and UCAT only)

Devices that are exempted by Visa rules from the use of a PED should enable the
cardholder to choose the application to be used, if possible. Figure G-1 illustrates the
application selection process.
NOTE: For devices supporting Dynamic Currency Conversion (DCC) or supporting

account selection as required in some markets, see Figure G-22.
Figure G-1: Sample Transaction Flow Diagram

G.1.2 Routing and Use of Chip Data

Requirement: Application selection must precede routing
The steps of application selection (choice of payment function) and selection of

routing/processing network must be separated. Application selection must be performed
prior to selection of the routing/processing network to be used.
NOTE: Application/Card schemes used and routing/processing network used may be

different.
Requirement: Use of chip data
When a chip is present on a card and the device supports chip, the transaction must be
processed via the chip: the application to be used and the routing decisions must not be
taken using information obtained from the magstripe but using information obtained from
the chip.
G.1.3 POS with Separate Merchant and Customer Displays

Requirement: No selection facility for merchant
The merchant interface must not allow the merchant to choose the application.
NOTE: A merchant may execute a choice on behalf of the cardholder if the cardholder
needs special assistance.
Requirement: Application choice not presented on merchant display
The Application Name(s) for choice must be presented only on the cardholder display and
not on the merchant display.

Best Practice: Feedback to merchant during selection
While the customer is choosing an application, the merchant display should inform the
merchant that this is happening. Suitable national terminology should be used to ensure
clarity. Figure G-2 provides an example.
Figure G-2: Merchant Display, Customer Choosing Application
Best Practice: Feedback to merchant after selection
As soon as an application has been selected, the application should be identified to the
merchant. Suitable national terminology should be used to ensure clarity. Figure G-3
provides an example.
Figure G-3: Merchant Display, Application Chosen
Best Practice: Prompt for cardholder choice
Visa recommends a prompt for cardholder choice. If the customer display is of sufficient
capacity, it should clearly indicate when the cardholder is required to choose an application,
with a prompt including either the word SELECT or the word CHOOSE. Suitable national
terminology should be used to ensure clarity. Figure G-5 provides an example.
Figure G-5: Cardholder Selection Display
NOTE: Prompt messages may be enhanced – for example: PLEASE SELECT or

CHOOSE METHOD OF PAYMENT.
This best practice should be weighed against the advantages of presenting the available
applications for choice on as few screens as possible, minimizing the time and effort
required to scroll from one screen to another. For example, if there are four mutually
supported applications to be presented and the display has the capacity to present 4 lines,
the placement of all four applications on a single screen at the expense of a prompt is likely
to provide a more efficient overall transaction flow. Figure G-6 provides an example of four
options without the use of SELECT or CHOOSE.

Figure G-6: Four Options
G.1.4 POS with Shared Merchant and Customer Display

Best Practice: Amount entry prior to application selection
For a POS transaction, amount entry should be performed before the application is
selected. The amount entered should be the final amount including gratuities or other
service charges to be paid for with the card.
Exemptions:
 Surcharges (if permitted) may be disclosed either before or after application selection.
 Cash back (if supported) may require application selection to be performed first.
Best Practice: Indicating the customer’s right to choose
The terminal display should indicate the customer’s right to choose the application. The
screen on which available applications are presented for choice by the cardholder should
be titled to convey to both merchant and customer that it is the cardholder’s choice. This
title should include either the word CUSTOMER or the word CARDHOLDER accompanied
by the word CHOICE as a minimum. Suitable national terminology should be used to
ensure clarity. Figure G-4 provides an example.
Figure G-4: Terminal Display Indicating Customer Choice
If there is enough space, the display should also convey what must be selected. Examples
include: CUSTOMER PAYMENT CHOICE, CARDHOLDER ACCOUNT CHOICE or
CUSTOMER CARD CHOICE.
G.1.5 Restricted use of the Cancel key

Requirement: No usage of the Cancel key for selecting the application
The Cancel (refusal) key is not to be used as part of the process of choosing or selecting
an application, including switching between screens. The Cancel key must only be used to
terminate the transaction.

G.1.6 Display of Application Name(s)

Requirement: Representation of applications
Whenever an application is presented, the Application Preferred Name(s), if present on the

card, must be displayed in accordance with EMV Specifications, or the Application Label(s),
if present, must be displayed in accordance with EMV Specifications.
G.1.7 Receipts
Requirement: Confirming the application used
Whenever a receipt is provided, the application used must be identified. If available on the
card, the Application Preferred Name, in accordance with EMV Specifications, is to be
printed on it. If the name is not available, then the Application Label, in accordance with
EMV Specifications, must be printed. (Exemption: Small ticket or VEPS program limited
receipt content applies).
For example, if the Application Preferred Name is Visa Debit or if there is no Application
Preferred Name (or if the Application Preferred Name uses a character set not supported
by the terminal) and the Application Label is Visa Debit. Figure G-7 provides an example of
a receipt with the application identified.
Figure G-7: Receipt with Application Identified

G.2 Application Selection for POS and UCAT

Selection process implementation for POS and UCAT requirements and best practices
include application choice options, allocation of numbers to applications, arrangement of
displayed information, legible layout, direct activation and chosen application display.
G.2.1 Choosing an Application

Best Practice: Numbering of applications and enabling the numeric keys
NOTE: Not applicable to touch screen or function display keys devices.
When presented to the cardholder, the application name should be accompanied by a

number and the TAD should allow the cardholder to choose the application by use of a key
on the numeric keypad corresponding to the number displayed alongside the application
name.
This method of choosing an application allows fast selection with a single key press - in
comparison, for example, to a scroll and select method that requires two key presses. The
time saved will be of benefit to the acquirer/merchant.
Additionally, it is anticipated that this method will allow as many applications as possible to
be displayed on a single screen since screen space will not be required for instructions on
how to make a selection.
Other methods of selection, including the use of function keys or the use of scroll and
select keys, may additionally be supported (the numeric keys are not to be used to scroll as
this would be confusing).
Figure G-9 shows an example of a device using FDK (function display keys) presented with
a card containing four mutually supported applications. Note that applications can be
selected either by use of the function keys or the numeric keys.

Figure G-9: Multiple Mutually Supported Applications, Function Keys Enabled
Requirement: Allocation of numbers to applications
If application names are accompanied by a number, numbers must be allocated in order of

application priority read from the card, with the highest priority allocated the number 1.
For example, if there are six applications resident on the card and four of these are
supported by the terminal as follows:
Highest Priority Application: Supported Name: Visa Credit
Next Highest Priority Application: Supported Name: Visa Debit
Next Highest Priority Application: Not Supported
Next Highest Priority Application: Supported Name: Visa Charge
Next Highest Priority Application: Not Supported
Next Highest Priority Application: Supported Name: Visa Prepaid
The applications are to be displayed as illustrated in Figure G-10.
Figure G-10: Allocation of Numbers to Applications

Requirement: Presenting all available applications for choice
All mutually supported applications available must be displayed to the cardholder. Without
compromising legibility or the clarity with which information is presented, a device must
present as many of these as possible on one screen, along with appropriate prompts if
these can also be accommodated. Examples are illustrated in Figure G-11.
Figure G-11: Application Display Examples
If all applications cannot be presented on one screen, the device must allow the cardholder
to navigate directly to another screen or screens where the remaining applications are
presented. A clear prompt (using suitable national terminology) must be used to indicate
how to see any choices not visible on the first screen.
Figure G-12 provides an example of screens where there are 5 mutually supported
applications.
Figure G-12: 5 Applications Display Example
When a list of Application Names is presented to the cardholder, it must be in priority order,
as specified by EMV, with the highest priority application listed first.
Requirement: Arrangement of displayed information
The application names are to be arranged in order in accordance with the application
priority indicator read from the card, either:
 In a single column in descending order of priority from top to bottom, or
 In two or more columns where the top of the second or subsequent column is a
continuation of the previous column.

NOTE: All Visa chip cards have a priority sequence assigned to each application.
Figure G-13 illustrates a column display.
Figure G-13: Column Display
Other methods of selection, including the use of touch screens, function keys or the use of
scroll and select keys, may additionally be supported. Figure G-9 shows an example of
more than one mutually supported application available and function keys enabled.
Figure G-14 shows an example of a device that has only sufficient display capacity to
present a single application on one screen. It is presented with a card containing four
mutually supported applications. Each screen includes a prompt for the cardholder to
accept the presented application by pressing an affirmation key (for example, Enter or OK)
and a prompt for the cardholder to reject it and view the next available application by
pressing the correction (Clear) key. The application presented can also be selected by
pressing its associated numeric key.
NOTE: As mandated in section G.1.5, the Cancel key is not to be used as part of the
process of choosing or selecting an application and during this process must only be
used to terminate the transaction.
Figure G-14: Multiple Mutually Supported Applications Available, Affirmation and

Correction Keys Enabled

G.2.2 TAD Display

Best Practice: Number of lines and characters
To support Application Selection, at least 4 lines should be available on the cardholder

display. Since the numeric keypad is common to all PIN entry TADs, this method can be
implemented across all models of terminals to provide cardholders with a consistent
selection experience and eliminate delays that might be caused by a need for the
cardholder to learn new selection methods from one TAD model to another.
Figure G-15 shows an example of a device with a 4 line x 20 character display capacity
with a card containing five mutually supported applications.
Figure G-15: Multiple Mutually Supported Applications

Best Practice: Legible Layout
A free character space should be left between the number and the application name. If the
listed applications are left justified, the number should precede the application name; if right
justified, the number should follow the application name. The aim is to make it as easy as
possible for the cardholder to scan the numbers on a list of applications and enter a choice
using the numeric keypad. Figure G-16 provides an example of a clear screen layout.
Figure G-16: Legible Layout
NOTE: The application name may be up to 16 characters long. Therefore, to provide for a
single digit number and a free character space, a minimum line length of 18 characters is
needed.
Requirement: Clarity of prompts for application selection
If a TAD provides a method of application selection other than the method recommended in
Section G.2.1.1, and G.2.2.1 then clear prompts must be provided for the cardholder to
guide the selection process (for example, in terms of which keys are to be pressed to make
a selection).
For example, if the cardholder is required to choose an application using a scroll and select
method, then the keys to be used to achieve this must be identified either by displayed
prompts or by designation of the keys themselves. Figure G-17 provides an example of
scroll and select layouts.
Figure G-17: Scroll and Select Layouts

However, to provide a consistent selection experience across all models of terminals,

applications should be numbered and numeric keys enabled to allow the cardholder to
select an application directly using the numeric keypad, irrespective of (or in addition to)
other methods of selection offered. For the examples in Figure G-17, this would provide a
dual interface allowing either scroll and select or selection using the numeric keypad.
Figure G-18 provides examples of scroll and select using the numeric keypad.
Figure G-18: Numeric Scroll and Select Examples
G.2.3 Selection on touch screen and FDK devices

Best Practice: Direct activation
Devices equipped with touch screen technology or with a Function Display Key (FDK)
interface should present all available applications on a menu (or more than one menu if
necessary) enabling the cardholder to directly activate his or her preferred application
without the need for further user input to confirm that choice.
Even where touch screen or FDK methods of selection are used, the cardholder could also
be offered the alternative of application selection using the numeric keypad. This provides
consistency of selection experience across device models, which should increase speed at
checkout. An example of this was shown in Figure G-9.
Function Display Keys (FDK) are soft keys arranged in a vertical column to the side of the
screen in such a way that their operation can be associated with on-screen legends or
designations horizontally aligned with them. Both FDK and touch screen technology
potentially offer very efficient methods of application selection since a cardholder choice
can be registered with a single touch. Maturing technology, the falling cost of screens and
the rapid growth in use of touch screen technology on consumer devices such as mobile
phones, may all contribute to a growth of these types of user interface on devices.

G.2.4 Displaying a selected application

Requirement: Displaying the selected application with PIN entry
On Selection of the Application, if the device has sufficient display capacity, it must present
the following information on one screen:
 Name of the selected application
 Amount of transaction and currency
 PIN entry prompt

This requirement applies if there is more than one mutually supported application available
or if there is only one mutually supported application available. Figure G-19 provides an
example of more than one mutually supported application available.
Figure G-19: Multiple Mutually Supported Applications
Figure G-9 and Figure G-14 provide other examples.
If more than one mutually supported application is available but the device does not have
sufficient display capacity to present confirmation of the selected application then it must
present the following information on one screen upon selection of the application:.
 Amount of transaction and currency
 PIN entry prompt

Figure G-20 provides an example of 2 mandatory prompts.
Figure G-20: 2 Mandatory Prompts

Figure G-15 shows an example of a screen flow for a device where more than one mutually
supported application is available and the affirmation and clear keys are enabled.
Best Practice: Displaying the selected application with PIN entry on a 2 line display
If only one mutually supported application is available (in which case, no choice is offered
to the cardholder) and the device does not have sufficient display capacity to present
confirmation of this application then it should present the following information on two
alternating screens as soon as the application is selected:
 Screen 1: the total amount and currency of the transaction together with the pin entry
prompt
 Screen 2: the name of the selected application together with the PIN entry prompt.
The two screens should cycle on a suitable timed interval until the first PIN character is
entered. Figure G-21 provides an example of the two screens.
Figure G-21: Two Screens with PIN Prompts
When only one mutually supported application is available and the cardholder therefore
plays no part in application selection, it is particularly important that the name of the
selected application is displayed with PIN entry. This is because the cardholder may not
know which application has been selected such as if an application on the card is blocked
without the cardholder’s knowledge.
If PIN entry is not used, the selected application will be confirmed at receipt production as
mandated in Section G.1.7.

G.3 Exemptions
Exemptions from showing a Visa application for choice may apply when a non Visa AID
represents the same account as the Visa AID in a particular environment or commercial
setting as illustrated in the following examples:
Example 1:
In country X, there is a commercial agreement between a Domestic Scheme (AID=DS) and

Visa allowing transactions to be processed on the domestic scheme when a transaction is
domestic and Visa when the transaction is non-domestic.
If a co-badged card is personalized as follows:
 AID Application Label
 DS1 DS Debit
 DS2 DS Credit
 Visa1 Visa Debit
 Visa2 Visa Credit

At a POS or ATM in country X, where both the DS AID and Visa AID are present, the
device can display only the following choice to the cardholder:
 DS Debit
 DS Credit
Note that the device must still give a choice between all domestic applications available
unless other domestic practices apply.
At a POS or ATM outside of country X where the DS AID is not supported, the device must
display the following choice to the cardholder:
 Visa Debit
 Visa Credit
Example 2:
If a co-badged card is personalized as follows where PL = private label agreed by Visa
 AID Application Label
 PL1 Private Name xxx
 Visa 1 Visa Credit

If a device supports a private label under an agreement with Visa allowing it not to display
Visa applications for choice (for example a commercial card), the device will act as if the
Visa application is not mutually supported and only the private application is. In the
example above, if Visa is treated as not supported, only the private label is supported and
the device will proceed with selecting this application without offering a choice to the
cardholder (see transaction flow in Figure G-1).
At a device where such agreement does not exist, the device either:
 Does not support the private label application, in which case there is only one mutually
supported application, Visa, with which the terminal will process the transaction, or
 Does support the private label application and must offer the cardholder a choice
between that application and the Visa one.

G.4 DCC Selection Overview

Figure G- 22 provides an example of the selection overview diagram for devices supporting
account selection or Dynamic Currency Conversion (DCC).
Figure G-22: Dynamic Currency Conversion (DCC) Selection Diagram

Appendix H Reference Materials

Appendix H provides a list of materials referenced in this document, which incorporates
information from a variety of sources. These materials are publicly available at the following
websites:
 EMV Integrated Circuit Card Specifications for Payment Systems at www.emvco.com
 EMV Optimising Contact Chip Transaction Times Best Practices at www.emvco.com
 PCI PIN Entry Device Security Requirements at www.pcisecuritystandards.org
 Payment Card Industry (PCI) Data Security Standard at www.pcisecuritystandards.org
 Payment Card Industry (PCI)Payment Application Data Security Standard (PA-DSS) at

www.pcisecuritystandards.org
 Visa PCI PIN Security Requirements at www.visa.com/pinsecurity
 Recommendations for EMV Processing for Industry-Specific Transaction Types at

www.emvco.com
EMVCo has documented a number of best practices for devices, which can be found at
www.emvco.com on the Advisories site.
The following materials have controlled availability. (Contact Visa representatives or

partnernetwork@visa.com.)
 Global ATM Member Guide
 Payment Technology Standards Manual
 Transaction Acceptance Device Requirements
 Visa Contactless Payment Specification
 Visa Europe Contactless Terminal Requirements and Implementation Guide
 Visa Integrated Circuit Card Specifications
 Visa International Operating Regulations
 Visa Europe Operation Regulations
 Visa Smart Debit/Credit Certification Authority Technical Requirements
 Visa Smart Debit/Credit Member Implementation Guide for Acquirers
 Visa Smart Debit/Credit System Technical Manual
 Visa U.S.A. Inc. Operating Regulations

 Visa payWave Acquirer Implementation Guide
 Visa Easy Payment Service – Acquirer Program Guide
 Prepaid Product Risk Management Best Practices

Appendix I Acronyms and Glossary

Appendix I contains a list of acronyms, terms, and definitions commonly used to describe
transaction acceptance devices and card readers.
Term Definition
Account Verification A transaction that verifies that an account is valid and in
good standing.
Acquirer A Visa client financial institution that signs a merchant or
disburses currency to a cardholder in a cash disbursement
and, directly or indirectly, enters the resulting transaction
receipt into interchange.
Acquirer Device Validation A set of cards or simulated cards and test scenarios used to
Toolkit (ADVT) validate new or upgraded EMV chip devices.
American National Standards A U.S.A. standards accreditation organization.
Institute (ANSI)
Application Authentication A cryptogram generated by the card at the end of the offline
Cryptogram (AAC) and online declined transactions.
Application Cryptogram A cryptogram generated by the card in response to a
GENERATE AC command.
Application Identifier (AID) A data element that identifies the application, as described
in ISO/IEC 7816-5.
Application Interchange Profile A set of indicators that show the specific functions supported
(AIP) by a chip card account; for example, SDA, DDA, CDA, or
cardholder verification.
Application File Locator (AFL) Application File Locator.
Application Selection Indicator A data element that indicates whether the associated AID in
the device must match the AID in the card exactly, including
the length of the AID, or only up to the length of the AID in
the device.
Application Transaction Counter A counter of the number of transactions processed by the
(ATC) card since the application was put on the card and is used in
device velocity checking.
Automated Dispensing Machine A UCAT that authorizes all transactions and requires PINs
Automated Teller Machine An unattended device that has electronic capability, accepts
(ATM) PINs, and disburses currency or checks.
B Binary representation
CA See Certification Authority.
Candidate List List of applications that are supported by both the card and
the device that is used for the selection of the application to
be used for the transaction.
Card Authentication A means of validating whether a card used in a transaction
is the genuine card issued by the issuer.

Term Definition
Card/Integrated Circuit In general, the term "card" is used to describe the function
performed by the VSDC application on the card or
transaction initiation device. When it is necessary to
distinguish between the chip itself and another card feature
such as the magnetic stripe, the term "integrated circuit"
may be used.
Cardholder Application Process by which the cardholder selects the application to
Selection be used for the transaction.
Cardholder Verification Method Instructions encoded within a chip that define how the
(CVM) authenticity of a cardholder's identity is to be verified.
Cardholder Activated Device A UCAT.
Certification Authority In general, an entity responsible for establishing and
vouching for the authenticity of public keys through issuance
and management of public key certificates.
Cn Compressed numeric—each byte is used to represent two
decimal digits, and the decimal number is padded with
trailing hexadecimal FFs.
Combined DDA/Application A particular way of performing dynamic data authentication,
Cryptogram Generation (CDA) which involves including the Application Cryptogram in the
dynamic signature generated by the ICC.
A type of offline data authentication where the card
combines generation of a cryptographic value (dynamic
signature) for validation by the device with generation of the
Application Cryptogram to ensure that it came from a valid
card.
Contactless A chip transaction where the communication between the
card and the device does not take place over a contact
interface.
Cryptographic Key The numeric value entered into a cryptographic algorithm
that allows the algorithm to encrypt or decrypt a message.
Cryptography The study of mathematical techniques for providing aspects
of information security, such as confidentiality, data integrity,
authentication, and nonrepudiation.
CVM List An issuer-defined list contained within a chip establishing
the hierarchy of preferences for verifying a cardholder's
identity.
Data Authentication Validation that data stored in the ICC has not been altered
since card issuance. See also Offline Data Authentication.
Data Encryption Standard The public domain symmetric key cryptography algorithm of
(DES) the National Institute for Standards and Technology.
Default Dynamic Data The device value used when the card does not pass its own
Authentication Data Object List DDOL to the device.
(Default DDOL)
Derived Unique Key Per A symmetric algorithm encryption technique that uses a
Transaction (DUKPT) unique DES key derived from the previous DES key to
encrypt the PIN for each new transaction.

Term Definition
Digital Signature A transformation of data intended to prove to the data
recipient or also to third parties one or both of the following:
Ownership of a particular secret (typically the private
component of a public key pair) by the originator of the data
The integrity of the data was signed
Dynamic Data Authentication This method ensures that issuer-selected card data
(DDA) elements and transaction-specific dynamic data elements
have not been fraudulently altered and that they come from
a valid card.
Dynamic Data Authentication The card-originated data element that is used for
Data Object List (DDOL) constructing the INTERNAL AUTHENTICATE command.
EMV Integrated Circuit Card Technical specifications developed (jointly by Europay
Specifications for Payment International, MasterCard International, and Visa
Systems International) to provide standards for processing debit and
credit transactions, and ensure global interoperability for the
use of chip technology in the payment industry.
EMVCo EMVCo, LLC, was formed to manage, maintain, and
enhance the EMV Integrated Circuit Card Specifications for
Payment Systems.
Encrypting PIN PAD (EPP) Device used to enter the cardholder’s PIN in a secure
manner and form part of a PIN Entry Device (PED).
File Control Information (FCI) Application information that is provided by the card during
application selection.
Floor Limit A currency amount below which an online authorization is
not required for a single transaction unless a Service Code
is present which requires online authorization. Visa regions
and markets establish floor limits for specific types of
merchants.
IFD Interface device
Integrated Circuit Card (ICC) A card embedded with a chip that communicates information
to a point-of-transaction device.
IFM Interface Module. It is the hardware or chip reader
developed to EMV specifications that provides physical
communication with the chip card.
International Organization of The specialized international agency that establishes and
Standardization (ISO) publishes international technical standards.
Issuer A Visa client financial institution that issues cards and
whose name appears on the card as the issuer (or, for cards
that do not identify the issuer, the financial institution that
enters into the contractual relationship with the cardholder).
Issuer Application Data A data element that contains proprietary application data for
transmission to the issuer in an online transaction.
Issuer Authentication Validation of the issuer by the card to ensure the integrity of
the authorized response.
Kernel A piece of software developed to EMV specifications that
interacts with the chip card and is integrated into the device
application.
Limited Amount Terminal An UCAT that only processes under-floor transactions

Term Definition
N Numeric—each byte is used to represent two decimal digits,
and the decimal number is padded with leading hexadecimal
zeroes
Offline Data Authentication A process whereby the card is validated at the point of
transaction, using RSA public key technology to protect
against counterfeit or skimming. VIS includes two forms:
SDA and DDA.
Offline Enciphered PIN A cardholder verification methodology defined in EMV in
which the cardholder PIN is entered at a POS device,
encrypted there with an ICC public key, and sent to the ICC
where it is validated.
Offline Capable Chip Device A contact chip device that supports both offline and online
processing.
Offline PIN A cardholder verification method where the card verifies a
PIN that is entered by the cardholder; a PIN that is entered
by cardholder that is verified by the card.
Online Capable Chip Device A contact chip device that supports both offline and online
processing.
Partial Name Selection The application selection process where the device AID
uses only a partial name.
Payment Card Industry (PCI) A consortium of payment card industry representatives,
which became formalized as the PCI Security Standards
Council.
Personal Identification Number A personal identification alpha or numeric code that
(PIN) identifies a cardholder in an authorization request originating
at a device with electronic capability.
PIN Entry Device (PED) A secure device that allows cardholders to enter their PINs.
Plus A global ATM network.
Point of Service (POS) The physical location where a merchant or acquirer (in a
face-to-face environment) or a UCAT (in an unattended
environment) completes a transaction receipt.
Primary Account Number (PAN) An issuer-assigned number that identifies a cardholder's
account.
Private Key The private (secret) component of an asymmetric key pair.
The private key is always kept secret by its owner. It may be
used to digitally sign messages for authentication purposes.
Processing Options Data Object Contains a list of a device resident data objects (tags and
List (PDOL) lengths) needed by the card in processing the GET
PROCESSING OPTIONS command.
Proximity Coupling Device The reader/writing device that uses inductive coupling to
(PCD) provide power to the consumer device, such as a
contactless card or a cell phone, and also to control the data
exchange with the consumer device.
Proximity Payments Systems A list of supported Application Identifiers (AIDs), Application
Environment (PPSE) Labels and Application Priority Indicators for applications
that are accessible over the contactless interface.

Term Definition
Public Key The public component of an asymmetric key pair. The public
key is usually publicly exposed and available to users. A
certificate to prove its origin often accompanies it. In RSA,
the public key consists of the public key exponent and the
public key modules.
Public Key Algorithm A cryptographic algorithm that allows the secure exchange
of information and message authentication but that does not
require a shared secret key, through the use of two related
keys—a public key that may be distributed in the clear and a
private key that is kept secret.
Public Key Certificate An asymmetric transformation of the public key by a CA and
intended to prove to the public key recipient the origin and
integrity of the public key.
Public Key Pair The two mathematically related keys, a public key and a
private key, which, when used with the appropriate public
key algorithm, can allow the secure exchange of information
and message authentication, without the secure exchange
of a secret.
RSA A public key cryptosystem developed by Rivest, Shamir, and
Adleman, widely known as RSA. It is used for data
encryption and authentication.
Secure Hash Algorithm (SHA-1) This algorithm is standardized as FIPS 180-2. SHA-1 takes
as input messages of arbitrary length and produces a
20-byte hash value.
Self-Service Terminal A UCAT that authorizes all transactions but does not
support PIN.
Skimming The process of copying sufficient data from a debit, credit, or
ATM card to manufacture a working copy of the card.
Small Ticket Transaction An electronically read authorized transaction at or below a
locally selected limit, presented by a merchant with a
qualified Merchant Category Code, that is conducted in a
face-to-face environment. For the applicable operating
regulations and a list of qualified Merchant Category Codes,
see the Visa operating regulations. See VEPS.
Standard Floor Limit A floor limit that varies by merchant type, as specified in the
Visa operating regulations.
Static Data Authentication A type of offline data authentication where the device
(SDA) validates a cryptographic value placed on the card during
personalization. The validation protects against some types
of counterfeit but does not protect against skimming.
Symmetric Algorithm An algorithm in which the key used for encryption is identical
to the key used for decryption. TDEA is the best known
symmetric encryption algorithm.
Terminal Action Code (TAC) Visa-defined rules in the device which the device uses to
determine whether a transaction should be declined offline,
sent online for an authorization, or declined if online is not
available.

Term Definition
Terminal Floor Limit A data element that indicates the transaction amount equal
to or greater than which the device will send the transaction
online.
Terminal Risk Management Offline checks such as floor limit checks and exception file
checks that are performed by the device.
Terminal Verification Results A set of indicators from the VSDC device, recording the
(TVR) results of offline and online processing. These indicators are
available to issuers in the online message and clearing
transaction.
Track 2 Equivalent Data Image of track 2 from the magnetic stripe that is part of the
card's chip data.
Transaction Acceptance Device A device that accepts and processes Visa, Visa Electron,
(TAD) and/or Plus transactions.
Transaction Acceptance Device A requirement for devices that accept and process Visa,
Requirement (TADR) Visa Electron, and/or Plus transactions.
Transaction Certificate (TC) Cryptogram generated by the card at the end of either an
online or offline transaction.
Transaction Status Information A value that indicates the functions that have been
(TSI) performed in the device.
Transaction Type A data element that indicates the type of financial
transaction, represented by the values of the first two digits
of Processing Code as defined by Visa.
Triple Data Encryption TDEA (sometimes referred to as Triple DES) as defined in
Algorithm (TDEA) ISO/IEC 18033 Information technology—Security
techniques—Encryption algorithms—Part 3: Block ciphers.
Triple Data Encryption Standard The data encryption standard used with a double-length
(TDES) DES key. Sometimes referred to as TDEA or DES3.
Unattended Cardholder A cardholder-operated device that reads, captures, and
Activated Terminal (UCAT) transmits card information in an unattended environment.
Unpredictable Number A value used to provide variability and uniqueness to the
generation of the Application Cryptogram.
Visa Electron A Visa payment program.
Visa Easy Payment Service
Visa Easy Payment Service (VEPS) is the new global name
(VEPS)
for the No Signature Required (NSR) program and Small
Ticket Transaction program as defined outside the United
States.
Visa Integrated Circuit Card Chip card and application specifications developed by Visa
Specification (VIS) for VSDC programs. VIS serves as a companion guide to
the EMV specifications.
Visa Smart Debit/Credit (VSDC) The Visa service offerings for chip-based debit and credit
programs. These services, based on EMV and VIS
specifications, are supported by VisaNet processing, as well
as by Visa Operating Regulations.

Term Definition
VisaNet Integrated Payment The systems and services through which Visa delivers
(V.I.P.) System online financial processing, authorization, clearing, and
settlement services to clients.
VSDC Certification Authority VSDC CA that certifies issuers as participants in VSDC.
Zero Floor Limit A floor limit with a currency amount of zero. Online
authorization is required for all zero-floor-limit transactions.

Visa TADG

Uploaded by

Copyright:

Available Formats

Visa TADG

Uploaded by

Document Information

Original Description:

Original Title

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

Visa TADG

Uploaded by

Copyright:

Available Formats

Transaction Acceptance Device Guide

Effective: March 2011

© 2005 – 2011 Visa. All Rights Reserved

© 2005 – 2011 Visa International Service Organization. All Rights Reserved

Effective: March 2011

Chapter 1 Overview ................................................................... 14

Chapter 2 Transaction Acceptance Environments................. 18

Chapter 3 General Acceptance................................................. 25

Visa Public Page 1

3.10 Cash Back Identification and Processing ................................. 30

Chapter 4 Magnetic Stripe Acceptance ................................... 34

Chapter 5 Contact Chip Acceptance........................................ 37

Visa Public Page 2

5.9.1 Terminal Floor Limits .................................................... 50

Chapter 6 Contactless Acceptance.......................................... 71

Visa Public Page 3

6.1 MSD .......................................................................................... 71

Visa Public Page 4

6.7.5 VEPS Transactions....................................................... 84

Chapter 7 Security Characteristics .......................................... 86

Chapter 8 Device Management Systems................................. 98

Visa Public Page 5

8.3 EMV Functionality Considerations.......................................... 100

Chapter 9 Acquirer Considerations ....................................... 102

Chapter 10 Data Element Considerations ............................. 104

Chapter 11 Considerations for EMV Approval...................... 110

Appendix A Track 1 Data Specifications ............................ 112

Visa Public Page 6

A.4.2 Service Code Usage ................................................... 131

Appendix B Track 2 Data...................................................... 139

Appendix C Global ATM Requirements .............................. 158

Visa Public Page 7

C.3 Regional Differences............................................................... 166

Appendix D Device Performance for EMV Transactions... 168

Appendix E EMV Tag to VisaNet Data Element Mapping.. 173

Appendix F Placement of Contactless Readers ................ 181

Visa Public Page 8

Appendix G Application Selection ...................................... 184

Appendix H Reference Materials ......................................... 202

Appendix I Acronyms and Glossary.................................. 204

Visa Public Page 9

Visa Public Page 10

Table B-8: Service Code Digit Value Descriptions ....................................... 149

Visa Public Page 11

Visa Public Page 12

Figure G-12: 5 Applications Display Example .............................................. 192

Visa Public Page 13

The Transaction Acceptance Device Guide is intended to provide vendors, merchants,

 Vendors who are developing, integrating or testing transaction acceptance devices to

 Acquirers and merchants creating requirements for transaction acceptance devices

 Acquirers, merchants, and device deployers creating, developing or testing an

Visa Public Page 14

1.3 Compliance Documents and Devices

 The Visa Operating Regulations consisting of:

 Visa International Operating Regulations and the applicable regional operating

 Transaction Acceptance Device Requirements (see Appendix B)

Visa Public Page 15

1.4 VEPS Best Practices