VCPS 2.2 Jan2016

Visa Contactless Payment
Specification (VCPS)
Visa Supplemental Requirements
Version 2.2
January 2016
Visa Confidential
Important Information on Confidentiality and Copyright
© 2007-2016 Visa. All Rights Reserved.
Notice: This information is proprietary and CONFIDENTIAL to Visa. It is distributed to Visa

participants for use exclusively in managing their Visa programs. It must not be duplicated,
published, distributed or disclosed, in whole or in part, to merchants, cardholders or any other
person without prior written permission from Visa.
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 THE LICENSED
WORK AND TITLES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT OF THIRD PARTY INTELLECTUAL
PROPERTY RIGHTS.
THE INFORMATION CONTAINED HEREIN IS PROPRIETARY AND CONFIDENTIAL AND MUST BE

MAINTAINED IN CONFIDENCE IN ACCORDANCE WITH THE TERMS AND CONDITIONS OF THE
APPLICABLE LICENSE AGREEMENT OR NDA BETWEEN YOU AND VISA INTERNATIONAL
SERVICE ASSOCIATION AND/OR VISA EUROPE LIMITED.
Note: This document is a supplement of the Visa Core Rules and Visa Product and Service Rules.
In the event of any conflict between any content in this document, any document referenced
herein, any exhibit to this document, or any communications concerning this document, and any
content in the Visa Core Rules and Visa Product and Service Rules, the Visa Core Rules and Visa
Product and Service Rules shall govern and control.
Contents
Visa Contactless Payment Specification: Visa Supplemental Requirements
Contents
Contents ............................................................................................................................................................ iii

Tables ................................................................................................................................................................. ix
Figures................................................................................................................................................................ ix
Requirements .................................................................................................................................................... x
1 Introduction .............................................................................................................................................. 1
1.1 <This section has been deleted>............................................................................................................... 1
1.2 qVSDC – Quick Visa Smart Debit/Credit ................................................................................................. 1
2 General Information ................................................................................................................................ 2
2.1 Audience .............................................................................................................................................................. 2
2.2 Scope .................................................................................................................................................................... 2
2.3 Reference Materials ......................................................................................................................................... 2
3 Terminology and Conventions ............................................................................................................. 4
3.1 Terminology and Notation ........................................................................................................................... 4
3.1.1 Requirement Terminology .................................................................................................................... 4
3.1.2 Reader Processing Terminology ......................................................................................................... 4
3.1.3 Implementation and Support Terminology .................................................................................... 5
3.1.4 Card and Reader Terminology............................................................................................................. 6
3.1.5 “Else” with Parenthesized Text ............................................................................................................. 6
3.1.6 Presence of Data Elements ................................................................................................................... 7
3.1.7 Format of Indicators ................................................................................................................................ 7
3.1.8 Value Representation .............................................................................................................................. 7
3.1.9 Coding of RFU Values in Data Elements .......................................................................................... 7
3.1.10 Flowcharts.................................................................................................................................................... 7
4 Overview of the Contactless Approach .............................................................................................. 9
4.1 Contactless Programs and EMV ................................................................................................................. 9
4.1.1 qVSDC ........................................................................................................................................................... 9
4.1.2 <This section has been deleted> .....................................................................................................10
4.2 qVSDC ................................................................................................................................................................10
January 2016 Visa Confidential iii

Notice: This information is proprietary and CONFIDENTIAL to Visa. It is distributed to Visa participants for use exclusively in managing their Visa
programs. It must not be duplicated, published, distributed or disclosed, in whole or in part, to merchants, cardholders or any other person without
prior written permission from Visa. © 2007-2016 Visa. All Rights Reserved.
Contents
4.3 <This section has been deleted>.............................................................................................................11
4.4 <This section has been deleted>.............................................................................................................11
4.5 Processing Overview .....................................................................................................................................11
4.5.1 Processing Prior to Enabling the Contactless Interface ...........................................................11
4.5.2 Discovery Processing.............................................................................................................................11
4.5.3 Application Selection ............................................................................................................................12
4.5.4 Initiate Application Processing ..........................................................................................................12
4.5.5 Read Application Data (Conditional)...............................................................................................12
4.5.6 Card Read Complete .............................................................................................................................12
4.5.7 Processing Restrictions (Conditional) .............................................................................................13
4.5.8 Offline Data Authentication (Conditional) ....................................................................................13
4.5.9 Cardholder Verification ........................................................................................................................13
4.5.10 Online Processing (Conditional)........................................................................................................13
4.5.11 Completion ...............................................................................................................................................14
4.5.12 Issuer Update Processing (Optional) ...............................................................................................14
4.6 Transaction Timing ........................................................................................................................................16
4.6.1 Timings for Card and Reader Interaction ......................................................................................16
5 Reader Requirements .......................................................................................................................... 17
5.1 Contactless Communication Protocol Requirements.......................................................................17
5.2 General Reader Requirements ..................................................................................................................17
5.2.1 Reader Requirements............................................................................................................................17
5.2.2 qVSDC Reader Requirements ............................................................................................................18
5.2.4 Reader Configuration Requirements...............................................................................................19
5.2.5 Reader Processing Requirements .....................................................................................................20
5.3 Processing Prior to Enabling the Contactless Interface ...................................................................23
5.3.1 Pre-processing Required Check ........................................................................................................23
5.3.2 Reader Preliminary Transaction Processing (Pre-processing) ...............................................23
5.4 Discovery Processing ....................................................................................................................................25
5.5 Application Selection ....................................................................................................................................26
5.5.1 SELECT Command ..................................................................................................................................28
iv Visa Confidential January 2016

Contents
5.5.2 Directory Selection Method using PPSE ........................................................................................28

5.5.3 Final Selection ..........................................................................................................................................29
5.5.4 Dynamic Reader Limits (DRL) Functionality ..................................................................................30
5.5.5 Contactless Application Allowed Check .........................................................................................33
5.6 Initiate Application Processing..................................................................................................................33
5.6.1 GET PROCESSING OPTIONS (GPO) Command............................................................................33
5.6.2 Initiate Application Processing ..........................................................................................................34
5.7 Read Application Data .................................................................................................................................37
5.7.1 READ RECORD Command ...................................................................................................................37
5.7.2 Read Application Data ..........................................................................................................................37
5.8 Card Read Complete .....................................................................................................................................37
5.8.1 Cardholder Messaging .........................................................................................................................38
5.8.2 Mandatory and Redundant Data ......................................................................................................38
5.8.3 Determine Card Transaction Disposition.......................................................................................39
5.9 Processing Restrictions ................................................................................................................................39
5.9.1 qVSDC Path Processing ........................................................................................................................39
5.10 Offline Data Authentication .......................................................................................................................41
5.11 Cardholder Verification ................................................................................................................................42
5.12 Online Processing ..........................................................................................................................................44
5.13 Completion .......................................................................................................................................................45
5.13.2 Transaction Approved...........................................................................................................................46
5.13.3 Transaction Declined .............................................................................................................................46
5.14 Issuer Update Processing ............................................................................................................................46
5.14.1 Issuer Update Commands ...................................................................................................................47
5.14.2 Issuer Update Processing ....................................................................................................................47
6 Card Requirements ............................................................................................................................... 50
January 2016 Visa Confidential v

Contents
6.1 Contactless Communication Protocol Requirements.......................................................................50
6.2 General Card Requirements .......................................................................................................................50
6.2.1 Card Requirements ................................................................................................................................50
6.2.2 Card Personalization Requirements ................................................................................................52
6.3 Application Selection ....................................................................................................................................54
6.3.1 SELECT Command ..................................................................................................................................54
6.3.2 Proximity Payment System Environment (PPSE) .........................................................................55
6.3.3 Personalization Requirements ...........................................................................................................55
6.4 Initiate Application Processing..................................................................................................................56
6.4.1 GET PROCESSING OPTIONS (GPO) Command............................................................................58
6.4.2 Processing Options Data Object List (PDOL) Requirements ..................................................58
6.4.3 Contactless Transaction Hierarchy ...................................................................................................60
6.4.4 Card Action Analysis – qVSDC Path Processing ..........................................................................60
6.5 Read Application Data .................................................................................................................................78
6.5.1 READ RECORD Command ...................................................................................................................78
6.6 Issuer Update Processing ............................................................................................................................79
6.6.1 Issuer Update Commands ...................................................................................................................79
6.6.2 Issuer Authentication Processing .....................................................................................................79
6.6.3 Issuer Script Processing........................................................................................................................86
A Fast Dynamic Data Authentication (fDDA) .................................................................................... 89
A.1 Dynamic Signature Generation .................................................................................................................90
A.2 Dynamic Signature Verification ................................................................................................................91
B <This appendix has been deleted> ................................................................................................. 93
C Cryptogram Versions ........................................................................................................................... 94
C.1 Cryptogram Version Number 10('0A')....................................................................................................94
C.2 Cryptogram Version Number 17('11') ....................................................................................................94
C.3 Cryptogram Version Number 18('12') and '22' ...................................................................................94
C.4 Cryptogram Version Number 12('0C'), '2C', and 50('32') through 59('3B') ..............................95
D VCPS Data Elements ............................................................................................................................. 96
D.1 Data Element Descriptions .........................................................................................................................96
vi Visa Confidential January 2016

Contents
D.2 Data Element Tags ...................................................................................................................................... 175

E Issuer Discretionary Data Options .................................................................................................. 179
E.1 Issuer Discretionary Data Options ........................................................................................................ 179
E.2 Personalization for IDD ............................................................................................................................. 179
E.3 MAC Calculation .......................................................................................................................................... 181
E.4 Padding for IDD MAC Generation ........................................................................................................ 182
E.5 Issuer Application Data Personalization Example ........................................................................... 182
F <This appendix has been deleted> ............................................................................................... 184
G Commands and Secure Messaging ................................................................................................ 185
G.1 GET DATA Command-Response APDUs ............................................................................................ 185
G.2 GET PROCESSING OPTIONS (GPO) Command-Response APDUs ............................................ 185
G.3 READ RECORD Command-Response APDUs ................................................................................... 187
G.4 SELECT Command-Response APDUs .................................................................................................. 187
G.5 ISSUER UPDATE COMMANDS................................................................................................................ 189
G.6 Secure Messaging ....................................................................................................................................... 191
H Streamlined qVSDC ............................................................................................................................ 192
H.1 Streamlined Functionality for qVSDC .................................................................................................. 192
H.2 Streamlined qVSDC Requirements ....................................................................................................... 192
H.3 Streamlined qVSDC Card Action Analysis.......................................................................................... 193
I Dual-Interface Contactless and Contact Cards ........................................................................... 196
I.1 Contactless and Contact Interfaces ...................................................................................................... 196
I.2 Processing Options Data Object List (PDOL) .................................................................................... 196
I.3 Reset of Offline Counters using VIS ..................................................................................................... 197
I.4 Data Accessibility ........................................................................................................................................ 198
I.5 Application Capabilities ............................................................................................................................ 199
I.6 Issuer Update Processing ......................................................................................................................... 200
I.7 DDA and fDDA ............................................................................................................................................. 200
J Reader-Terminal Data ....................................................................................................................... 202
K Online Messages and Clearing Records ........................................................................................ 204
K.1 <This section has been deleted>.......................................................................................................... 204
January 2016 Visa Confidential vii

Contents
K.2 qVSDC Acquirers ......................................................................................................................................... 204
L Transaction Logging .......................................................................................................................... 207
M Issuer Application Data (IAD) and Card Verification Results (CVR) Formats ...................... 209
Glossary ......................................................................................................................................................... 213
viii Visa Confidential January 2016

Tables
Tables
Table 6–1: Minimum PDOL Content ................................................................................................................59

Table 6–2: qVSDC GPO Response Data ..........................................................................................................75
Table A–1: Terminal Dynamic Data for input to DDA hash algorithm.................................................90
Table A–2: ICC Dynamic Number for input to DDA hash algorithm ....................................................91
Table C–1: Data Elements included in Cryptogram Version Number 17............................................94
Table D–1: VCPS Data Elements ...................................................................................................................... 101
Table D–2: Data Element Tags ......................................................................................................................... 175
Table E–1: IDD Options ...................................................................................................................................... 180
Table E–2: MAC Calculation ............................................................................................................................. 181
Table G–1: SELECT Response Message Data Field (FCI) of the PPSE................................................. 188
Table G–2: SELECT Response Status Word.................................................................................................. 189
Table J–2: qVSDC Transactions....................................................................................................................... 202
Table K–3: Acquirers Supporting qVSDC ..................................................................................................... 204
Table M–1: IAD Formats ...................................................................................................................................... 209
Table M–2: CVR Formats ..................................................................................................................................... 210
Figures
Figure 4–1: Sample Transaction Flow ................................................................................................................15

Figure 5–1: Application Selection Using Directory Selection Method ..................................................27
Figure 5–2: Initiate Application Processing (Reader) ...................................................................................35
Figure 5–3: Issuer Update Processing (Reader) .............................................................................................48
Figure 6–1: Initiate Application Processing (Card)........................................................................................57
Figure 6–2: EXTERNAL AUTHENTICATE Processing (Card) ........................................................................80
Figure 6–3: Issuer Script Command Processing (Card) ...............................................................................86
Figure A–1: Fast DDA (fDDA) qVSDC Example ...............................................................................................92
January 2016 Visa Confidential ix

Requirements
Requirements
Req 4.1 (Transaction Timing)................................................................................................................ 16

Req 5.1 <This requirement has been deleted> ............................................................................... 17
Req 5.3 (Offline-capable Readers) ...................................................................................................... 17
Req 5.4 (Receipts) .................................................................................................................................... 17
Req 5.5 (POS Supports Multiple Interfaces) ..................................................................................... 18
Req 5.5A (POS Supports Multiple Interfaces – Data Segregation) ................................................ 18
Req 5.6 (qVSDC Message Requirements).......................................................................................... 18
Req 5.7 (qVSDC Messages – FFI and CED) ........................................................................................ 18
Req 5.7A (qVSDC – Token Data) ............................................................................................................. 19
Req 5.8 (Interrupted Card Read) ......................................................................................................... 19
Req 5.14 (Issuer Update Processing and Online Capability) .......................................................... 20
Req 5.15 (qVSDC Transactions with Amount Zero) .......................................................................... 20
Req 5.18 (Purchase Transactions) .......................................................................................................... 20
Req 5.19 (Manual Cash Transactions)................................................................................................... 20
Req 5.20 (Refund Transactions) ............................................................................................................. 21
Req 5.21 (Form Factor Indicator) ........................................................................................................... 21
Req 5.22 (Unpredictable Number) ........................................................................................................ 21
Req 5.23 (Unrecoverable [EMV CL PAYMENT] Book D Error) ........................................................ 22
Req 5.24 (Cardholder Messaging) ......................................................................................................... 22
Req 5.25 (Erroneous Data)....................................................................................................................... 22
Req 5.26 (Pre-processing Performed) .................................................................................................. 23
Req 5.27 (No Pre-processing Performed) ........................................................................................... 23
Req 5.28 (Amount, Authorized) ............................................................................................................. 24
Req 5.29 (Reader Unpredictable Number) .......................................................................................... 24
Req 5.30 (Contactless Application Not Allowed)............................................................................... 24
x Visa Confidential January 2016

Requirements
Req 5.31 (Status Check) ........................................................................................................................... 24
Req 5.32 (Amount, Authorized of Zero Check) .................................................................................. 24
Req 5.33 (Amount, Authorized of Zero Check) .................................................................................. 25
Req 5.34 (Reader Contactless Transaction Limit (RCTL) Check) .................................................... 25
Req 5.35 (Reader CVM Required Limit Check) ................................................................................... 25
Req 5.36 (Reader Contactless Floor Limit Check) .............................................................................. 25
Req 5.37 (Power On Contactless Interface)......................................................................................... 25
Req 5.38 (Request Card) .......................................................................................................................... 26
Req 5.39 (Collision).................................................................................................................................... 26
Req 5.40 (Power Off Contactless Interface) ........................................................................................ 26
Req 5.41 (SELECT Command) ................................................................................................................. 28
Req 5.42 (DF Names) ................................................................................................................................ 28
Req 5.43 (PPSE) .......................................................................................................................................... 28
Req 5.44 (SELECT PPSE) ............................................................................................................................ 28
Req 5.45 (FCI Issuer Discretionary Data Processing) ........................................................................ 29
Req 5.46 (Empty FCI at qVSDC-Enabled Reader) .............................................................................. 29
Req 5.47 (Building the Candidate List) ................................................................................................. 29
Req 5.48 (Candidate List – Empty)......................................................................................................... 29
Req 5.49 (Candidate List – Single Application) .................................................................................. 29
Req 5.50 (Candidate List – Multiple Applications) ............................................................................ 30
Req 5.51 (Select Application).................................................................................................................. 30
Req 5.52 (Reader Risk Parameters) ....................................................................................................... 31
Req 5.53 (Reader Limit Sets) ................................................................................................................... 31
Req 5.54 (Application Program ID) ....................................................................................................... 32
Req 5.55 (Contactless Application Not Allowed)............................................................................... 33
Req 5.56 (GPO Command) ...................................................................................................................... 33
Req 5.57 (Format 2) ................................................................................................................................... 33
Req 5.58 (Recognized and Unrecognized Data) ................................................................................ 34
Req 5.59 (PDOL in SELECT Response)................................................................................................... 35
Req 5.60 (Issue GPO Command) ............................................................................................................ 36
Req 5.61 (GPO Response SW1 SW2) .................................................................................................... 36
January 2016 Visa Confidential xi

Requirements
Req 5.63 (READ RECORD Command) ................................................................................................... 37
Req 5.64 (Application File Locator) ....................................................................................................... 37
Req 5.65 (Card Read Complete Cardholder Messaging) ................................................................. 38
Req 5.66 (Card Read Complete) ............................................................................................................. 38
Req 5.67 (Mandatory Data) ..................................................................................................................... 38
Req 5.68 (Redundant Data) ..................................................................................................................... 38
Req 5.69 (Cryptogram Information Data) ........................................................................................... 39
Req 5.70 (Cryptogram Type Transaction Disposition) ..................................................................... 39
Req 5.74 (Application Expired Check) .................................................................................................. 40
Req 5.75 (Terminal Exception File Check) ........................................................................................... 40
Req 5.76 (Application Usage Control – Manual Cash Transactions) ............................................ 40
Req 5.77 (Application Usage Control – Cashback Transactions) ................................................... 41
Req 5.78 (fDDA Verification)................................................................................................................... 42
Req 5.79 (CTQ Not Returned by Card) ................................................................................................. 43
Req 5.80 (CTQ Returned by Card) ......................................................................................................... 43
Req 5.81 (CVM Required and CVM Not Performed) ........................................................................ 44
Req 5.82 (qVSDC Online Authorization) .............................................................................................. 45
Req 5.83 (qVSDC Online Processing Performed) .............................................................................. 45
Req 5.84 (qVSDC Online Processing Not Performed) ...................................................................... 45
Req 5.85 (Cardholder Messaging for Approved)............................................................................... 46
Req 5.86 (Cardholder Messaging for Declined) ................................................................................. 46
Req 5.87 (Do Not Reattempt Transaction) .......................................................................................... 46
Req 5.88 (EXTERNAL AUTHENTICATE Command) ............................................................................ 47
Req 5.89 (Issuer Scripts) ........................................................................................................................... 47
Req 5.90 (Prompt for Card) ..................................................................................................................... 48
Req 5.91 (SELECT Application) ............................................................................................................... 49
Req 5.92 (EXTERNAL AUTHENTICATE Command) ............................................................................ 49
Req 5.93 (Issuer Script Commands) ...................................................................................................... 49
Req 5.94 (Second Tap Completed) ........................................................................................................ 49
Req 6.1 (Atomic Commands)................................................................................................................ 50
Req 6.2 (Counter Overflow) .................................................................................................................. 50
Req 6.3 (Dual-Interface Contactless and Contact Cards) .............................................................. 51
xii Visa Confidential January 2016

Requirements
Req 6.4 (Commands Restricted by Interface)................................................................................... 51
Req 6.5 (qVSDC Path Support)............................................................................................................. 51
Req 6.6 (Cryptogram Version Number) ............................................................................................. 51
Req 6.7 (Application Permanently Blocked) ..................................................................................... 52
Req 6.9 (Offline-capable Cards) ........................................................................................................... 52
Req 6.10 (Transaction Logging) ............................................................................................................. 52
Req 6.11 (qVSDC Support) ...................................................................................................................... 53
Req 6.12 (Application Interchange Profile) ......................................................................................... 53
Req 6.14 (Low Value Checks) .................................................................................................................. 53
Req 6.15 (CVV and iCVV) ......................................................................................................................... 54
Req 6.16 (SELECT Command) ................................................................................................................. 54
Req 6.17 (Accepting the SELECT Command) ...................................................................................... 54
Req 6.18 (Application Blocked) .............................................................................................................. 55
Req 6.19 (PPSE) .......................................................................................................................................... 55
Req 6.20 (PPSE Personalization) ............................................................................................................ 55
Req 6.21 (PPSE Personalization – Application Priority Indicator) ................................................. 55
Req 6.22 (AID Personalization)............................................................................................................... 56
Req 6.23 (GPO Command) ...................................................................................................................... 58
Req 6.24 (PDOL Parsing) .......................................................................................................................... 58
Req 6.25 (PDOL Tags and Lengths) ....................................................................................................... 58
Req 6.26 (qVSDC Transaction Processing) .......................................................................................... 60
Req 6.27 (Initialization of Simple Internal Indicators) ...................................................................... 61
Req 6.28 (Initialization of Matching Currency Indicator) ................................................................ 61
Req 6.29 (Initialization of International Transaction Indicator) ..................................................... 62
Req 6.30 (Initialization of Contact Chip Supported Indicator)....................................................... 62
Req 6.31 (Initialization of Issuer Update Processing Supported Indicator)................................ 62
Req 6.32 (Initialization of Card Transaction Qualifiers) ................................................................... 63
Req 6.33 (Initialization of Issuer Application Data) .......................................................................... 63
Req 6.34 (Initialization of Cryptogram Information Data) .............................................................. 63
Req 6.35 (Application Blocked Check) ................................................................................................. 63
January 2016 Visa Confidential xiii

Requirements
Req 6.36 (PIN Tries Exceeded Check) ................................................................................................... 64
Req 6.37 (Refunds and Credits Check) ................................................................................................. 64
Req 6.38 (Reader Requires an Online Cryptogram Check) ............................................................. 64
Req 6.39 (CVM Required Check) ............................................................................................................ 64
Req 6.40 (Determine Common CVM) ................................................................................................... 65
Req 6.41 (Low Value Check) .................................................................................................................... 66
Req 6.42 (Low Value AND CTTA Check) .............................................................................................. 67
Req 6.43 (No Low Value Check Supported) ........................................................................................ 67
Req 6.44 (International Transaction Not Allowed Check) ............................................................... 68
Req 6.45 (International Transaction Not Allowed Offline Check) ................................................. 68
Req 6.46 (Consecutive Transaction Limit International Check) ..................................................... 68
Req 6.47 (Contactless Transaction Count)........................................................................................... 69
Req 6.48 (Decline if Online Required Check) ...................................................................................... 69
Req 6.48A (Reset Online Preferred by Card Indicator)........................................................................ 69
Req 6.49 (Decline)...................................................................................................................................... 70
Req 6.50 (Switch Interface) ..................................................................................................................... 71
Req 6.52 (Contactless Transaction Counter Updates) ...................................................................... 71
Req 6.53 (Online) ....................................................................................................................................... 71
Req 6.54 (Tearing Protection - Offline Approval Request) ............................................................. 72
Req 6.55 (Low Value Counter Updates) ............................................................................................... 73
Req 6.56 (Low Value AND CTTA Counter Updates) .......................................................................... 73
Req 6.57 (Consecutive Transaction Counter International Counter Update)............................. 73
Req 6.58 (Contactless Transaction Counter Update) ........................................................................ 73
Req 6.59 (Offline) ....................................................................................................................................... 73
Req 6.63 (READ RECORD Command) ................................................................................................... 78
Req 6.64 (Last Record) .............................................................................................................................. 78
Req 6.65 (Last Record - Commit Data Elements and Indicators) .................................................. 78
Req 6.66 (Issuer Update Commands) ................................................................................................... 79
Req 6.67 (One EXTERNAL AUTHENTICATE Command Per ATC Value) ....................................... 81
Req 6.68 (Last Contactless Application Cryptogram Valid Indicator) .......................................... 81
Req 6.69 (EXTERNAL AUTHENTICATE Processing: CVN 10 and CVN 17).................................... 81
xiv Visa Confidential January 2016

Requirements
Req 6.70 (Issuer Authentication Counter and Indicator Resets).................................................... 81
Req 6.71 (Approval Counter and Indicator Resets) .......................................................................... 82
Req 6.72 (Generate ARPC) ....................................................................................................................... 82
Req 6.73 (Issuer Authentication Results) ............................................................................................. 83
Req 6.74 (CSU Processing) ...................................................................................................................... 83
Req 6.75 (CSU and ADA Counter Controls) ........................................................................................ 84
Req 6.76 (Update Counters).................................................................................................................... 85
Req 6.77 (Issuer Authentication Successful) ....................................................................................... 85
Req 6.77A (Increment Non-Cyclic Issuer Script Command Counter) .............................................. 86
Req 6.78 (Last Contactless Application Cryptogram Valid Indicator) .......................................... 87
Req 6.79 (MAC Verification).................................................................................................................... 87
Req 6.80 (Issuer Script Reset of CTTA) ................................................................................................. 87
Req 6.81 (Issuer Script Reset of VLP Available Funds) ..................................................................... 87
Req 6.82 (Issuer Script Command Result) ........................................................................................... 88
Req D.1 (Data Element Requirements) ............................................................................................... 96
Req G.1 (GPO Responses) .................................................................................................................... 186
Req G.2 (Data Elements in GPO Responses) ................................................................................... 186
Req G.3 (Additional Data Elements in GPO Responses) .............................................................. 186
Req G.4 (Secure Messaging)................................................................................................................ 191
Req H.1 (Streamlined qVSDC) ............................................................................................................. 192
Req H.2 (Initialization of Card Transaction Qualifiers) ................................................................. 193
Req H.3 (Initialization of Issuer Application Data) ........................................................................ 193
Req H.4 (Initialization of Cryptogram Information Data) ............................................................ 193
Req H.5 (Application Blocked Check) ............................................................................................... 193
Req H.6 (CVM Required Check) .......................................................................................................... 194
Req H.7 (Determine Common CVM) ................................................................................................. 194
Req H.8 (Online) ..................................................................................................................................... 195
Req I.1 (Contactless and Contact Interfaces) ................................................................................ 196
Req I.1A (Contactless SELECT) ............................................................................................................. 196
Req I.2 (PDOL) ....................................................................................................................................... 196
Req I.3 (VIS CTCI) .................................................................................................................................. 197
Req I.4 (Records Restricted by Interface) ....................................................................................... 198
January 2016 Visa Confidential xv

Requirements
Req I.5 (Transaction Log Records Restricted by Interface) ........................................................ 198
Req I.6 (Application Internal Data Elements) ................................................................................ 198
Req I.7 (Contactless Functionality Disabled) ................................................................................. 199
Req I.8 (Restrict Reset of Contactless Functionality Disabled Bit) ........................................... 199
Req K.3 (Track 2) .................................................................................................................................... 206
Req K.4 (Primary Account Number and Expiration Date) ........................................................... 206
Req M.1 (Issuer Application Data (IAD) Formats)........................................................................... 209
xvi Visa Confidential January 2016

1 Introduction
1 Introduction
New technology is presenting Visa with opportunities to provide enhanced payment services.
One such new technology is the ability to communicate between two entities, for instance a
card and a reader, over a contactless interface.
New technology also brings challenges and changes to existing business and technical
environments. To ensure consistent cardholder experience and prevent transactions from
being interrupted, it is crucial that the time in which the cardholder holds the payment card
close to the reader (i.e. when the card is in the field) be as minimal as possible.
1.1 <This section has been deleted>
1.2 qVSDC – Quick Visa Smart Debit/Credit
qVSDC uses EMV commands and constructs whenever possible, to utilize issuer and acquirer
investment in EMV. It compresses multiple EMV commands into as few commands as possible
to save time and allow cryptographic operations to be done up front as opposed to later when
the card is leaving the field. It features:
• An online transaction with online card authentication.
• An online transaction with online card authentication and offline data authentication.
• An offline transaction with offline data authentication and a clearing cryptogram for below
floor limit transactions, and an option of restricting offline transaction values using low
value limits.
The requirements for qVSDC are defined in this document.
January 2016 Visa Confidential 1

2 General Information
2.1 Audience
This document is intended for clients, Visa regions, and vendors for use in Visa contactless
programs.
2.2 Scope
This specification describes the globally interoperable contactless solution. It addresses the
requirements for:
• qVSDC
• Reader or card application-level requirements that are not covered in [VIS], as well as
differentiation from contact card or contact device requirements in the Visa Core Rules and
Visa Product and Service Rules
Contactless VSDC and MSD are no longer supported in this specification.
Requirements for physical characteristics, power and signal interfaces, initialization, collision
detection, and transmission protocols are specified in [EMV CL PAYMENT] Book D.
Any additional requirements beyond those specified in [EMV CL PAYMENT] are addressed in
this document.
2.3 Reference Materials
The following documents are referenced in this specification.

[EMV] EMV ICC Specifications for Payment Systems, Version 4.3, November 2011.
Integrated Circuit Card Specifications for Payment Systems.
[EMV ASRPD] EMV Specification Update Bulletin No. 175.
Application Selection Registered Proprietary Data.
[EMV CL PAYMENT] EMV Contactless Specifications for Payment Systems, Version 2.5, March
2015
Book A: Architecture and General Requirements
Book B: Entry Point Specification
Book C-3: Kernel 3 Specification
Book D: EMV Contactless Communication Protocol Specification
2 Visa Confidential January 2016

[EMV CPS] EMV Card Personalization Specification, Version 1.1, July 2007. EMV Card
Personalization Specification (EMV CPS); latest version available on
EMVCo.com
EMV Specification Update Bulletins; latest version available on EMVCo.com
[EMV Tokenisation] EMV Payment Tokenisation Specification; latest version available on

EMVCo.com
[ISO 639] ISO/FDIS 639-1. Codes for the Representation of Names and Languages
(Alpha-2 code).
[ISO 3166] ISO 3166. Codes for the Representation of Names and Countries.
[ISO 4217] ISO 4217. Codes for the Representation of Currencies and Funds.
[ISO 7811] ISO/IEC 7811. Identification Cards – Recording Technique.

[ISO 7813] ISO/IEC 7813. Identification Cards – Financial Transaction Cards.
[ISO 7816-4] ISO/IEC 7816-4. Identification Cards – Integrated Circuit Cards with Contacts
– Part 4: Interindustry Commands for Interchange.
[ISO 7816-5] ISO/IEC 7816-5. Identification Cards – Integrated Circuit Cards with Contacts
– part 5: Numbering System and Registration Procedure for Application
Identifiers.
[ISO 8583] ISO 8583. Financial transaction card originated messages – Interchange
message specifications
[ISO 8859] ISO/IEC 8589. Information Processing – 8-bit Single-Byte Coded Graphic
Character Sets.
[ISO 14443] ISO/IEC 14443. Identification cards – Contactless integrated circuit(s) cards –
Proximity cards
Part 1: Physical characteristics
Part 2: Radio frequency interface power and signal interface
Part 3: Initialization and anticollision
Part 4: Transmission protocol
[VIS] Visa Integrated Circuit Card Specification, Version 1.6, January 2016 –
Provides technical details related to VIS transactions and functions
performed by the chip card.
[VSDC PERSO] VSDC Personalization Specification, Version 2.1, January 2016 – Guide to
personalization of VSDC applications using the Common Personalization
approach described in [EMV CPS].
[VPTSM] Visa Payment Technology Standards Manual – Describes the standards

applied to PINs, CVV techniques, management of cryptographic keys, and
Track 1 and Track 2 for both magnetic stripe and chip.

3 Terminology and Conventions

Many of the definitions, acronyms, and notations in this document are new with contactless
technology or are based on contact chip technology (EMV). This document assumes a level of
familiarity with both contactless technology and EMV. For those who are less familiar, this
explanation of terms and conventions is placed early in the document for your reference.
3.1 Terminology and Notation
This specification uses the following terminology and notations.
3.1.1 Requirement Terminology
The terminology for requirements is as follows:

• use of the word “shall” denotes a mandatory requirement
• use of the word “should” denotes a recommendation
• use of the word “may” denotes an optional feature
For presence of tags in the commands and responses, the following notation is used:
• M: Mandatory tag – shall always be present, otherwise the reader terminates the transaction
• R: Required tag – shall always be present, but the reader does not terminate the transaction
if the tag is not returned
• C: Conditional tag – shall be present under certain conditions, but the reader does not
terminate the transaction if the tag is not returned.
• O: Optional tag – may or may not be present
3.1.2 Reader Processing Terminology
The following phrases are used in this specification to indicate that the reader should stop the
current contactless application, unless explicitly indicated otherwise.
• “Terminate the transaction”: Stop the current application. Subsequent reader processing is
outside the scope of this specification. Contact your Visa regional representative for the
requirements applicable for your region.
• “Power(s/ing) off the contactless interface”: Stop the current application, and stop
generating the RF Field (in order to put the PICC into the POWER-OFF state as defined in
[EMV CL PAYMENT] Book D). Subsequent reader processing is outside the scope of this

specification. Contact your Visa regional representative for the requirements applicable for
your region.
• “Switch interface(s)”: Stop the current application, power off the contactless interface, and (if
another interface is supported) advise the cardholder that the transaction should be
attempted over another reader/terminal interface. When switching to another interface, the
transaction amount shall be known by the reader-terminal and the merchant shall not be
required to reenter the transaction amount.
Note: When the reader is required to power off the contactless interface, it shall do so
immediately and shall not perform an [EMV CL PAYMENT] Book D Removal unless explicitly
stated otherwise. (An [EMV CL PAYMENT] Book D Removal is performed to ensure that the PICC
has been removed from the PCD field)
3.1.3 Implementation and Support Terminology
The following terminology is used in this specification to describe the implementation and
configuration requirements for card and reader functionality:
• Implementation-Mandatory: Card or reader shall implement this functionality.
• Implementation-Conditional: Card or reader shall implement this functionality if the defined
conditions are met. Conditions vary based on the functionality in question.
• Implementation-Optional: Card or reader may implement this functionality, at the discretion
of the implementer.
• Issuer-Mandatory (for card) or Acquirer-Merchant-Mandatory (for reader): Issuer or acquirer-
merchant shall enable this functionality.
• Issuer-Conditional (for card) or Acquirer-Merchant-Conditional (for reader): Issuer or
acquirer-merchant shall enable this functionality if the defined conditions are met.
Conditions vary based on the functionality in question.
• Issuer-Optional (for card) or Acquirer-Merchant-Optional (for reader): Issuer or acquirer-
merchant may enable this functionality, at their discretion.
The card and reader functionality defined in this specification are Implementation-Mandatory,
except where explicitly stated otherwise. This specification may also explicitly reiterate that
specific functionality is Implementation-Mandatory to avoid potential ambiguity.
When used to describe requirements and conditions for card or reader functionality, the
following terminology may be used:
• “Implement(ed)”: Card or reader is capable of performing the functionality. The phrase
"implement support for" may also be used.
• “Enable(d)”: Card or reader functionality has been activated (i.e. turned on).
• "Disable(d)": Card or reader functionality has been deactivated (i.e. turned off).

• “Support(ed)”: Card or reader functionality is both implemented and issuer/acquirer-
merchant enabled.
3.1.4 Card and Reader Terminology
3.1.4.1 Reader
The word reader is used in this specification for the merchant device communicating with the
card.
The use of this word is not intended to dictate any specific implementation. Specifically there
are two scenarios in which typically a reader is used for a contactless transaction:
• Either as a reader (also called a dongle or PCD) separated from, but communicating with, a
POS device.
• Or as a reader integrated into a POS device.
No required implementation shall be implied from this specification perspective.
The word reader in this specification will therefore cover 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.
3.1.4.2 Card
The word card is used in this specification for the consumer device that contains the
contactless payment application communicating with a payment reader.
The term card ordinarily implies a typical credit card-sized payment card, but in this
specification it indicates any type of consumer device that can operate over a contactless
interface; for instance, a key fob.
3.1.5 “Else” with Parenthesized Text
Parenthesized text following the statement “Else” is provided as supplemental information, and
does not denote a condition that must be satisfied.
Ex. If Condition, then the card shall…
Else (Text), the card shall…
In the example above, the parenthesized “(Text)” is merely supplemental information, and does
not constitute a condition that must be satisfied.

3.1.6 Presence of Data Elements
If a card condition evaluates a data element that is not present, then the specific condition
referencing the data element shall evaluate to FALSE, unless explicitly stated otherwise. For
card requirements or statements with multiple conditions, all other conditions in the
requirement or statement are unaffected and evaluated as normal.
If a card action is to be performed on a data element that is not present, then the specific
action is not performed. For requirements where multiple actions are to be taken, all other
actions in the set are unaffected and performed as normal.
3.1.7 Format of Indicators
Although the indicators used in this specification are explicitly assigned the values of 0 or 1,
the format of these internal indicators within an implementation is at the discretion of the
implementer.
Performance and security considerations should both be weighed when deciding on the
implementation of internal indicators.
3.1.8 Value Representation
0 to 9 10 decimal digits. Decimal numbers are not enclosed in quotation marks.

'0' to '9' and 'A' to 'F' 16 hexadecimal characters
xb, xxb Binary values. Bit values are appended with the character “b” (e.g. 1b and
0000b).
Bits within a byte are numbered from right to left, where the low-order bit
(bit 1) is the rightmost bit and the high-order bit (bit 8) is the leftmost bit.
‘Bit Name’ The bit defined as “Bit Name” within a data element. Bit names are
enclosed in single curly quotation marks.
3.1.9 Coding of RFU Values in Data Elements
Values in data elements marked as RFU (Reserved for Future Use) shall be set to zero, and both
the reader and card shall not; act on, operate on, or verify RFU data.
Coding of data marked as RFU shall follow the same rules as defined in [EMV] Book 3
section 6.3.6.
3.1.10 Flowcharts
Flowcharts are used to provide a high-level illustration of the processing. The flowcharts may
be simplified to illustrate a concept, and may not include all the steps that are performed.
Implementations are not required to strictly follow the flowcharts, and are instead required to
comply with the requirements in the related text. In the case of a discrepancy between the
flowchart and the related text, the text shall take precedence.
Please notify Visa of any discrepancies at [email protected] so that they can be evaluated
and clarified as appropriate.

4 Overview of the Contactless Approach

The approach to contactless payment processing uses existing infrastructure while
acknowledging that contactless payment is being targeted for new markets where quick
transactions are a business requirement.
4.1 Contactless Programs and EMV
While patterned on EMV, all of Visa’s contactless implementations have the following
differences:
• Level 1 (contact versus contactless technology)
• Mandatory use of the PPSE
qVSDC is based on [EMV] card and terminal application specifications. [EMV] constructs,
commands, data elements, and functionality are utilized where possible. Contactless VSDC and
MSD are no longer supported in this specification.
qVSDC is a contactless path under a single Visa AID. Card application processing is determined
by the path within the Visa application (a single AID).
Note: For dual-interface cards supporting VIS, VIS is supported in the same application under the
same single Visa AID. When using the contact interface, path determination is not performed and
VIS processing is used.
4.1.1 qVSDC
To minimize the interaction time between the card and the reader, qVSDC readers support
Reader Preliminary Transaction Processing (Pre-processing). The Amount, Authorized (tag
'9F02') is obtained and transaction-based risk management is performed before requesting
that the card be presented and initiating card discovery.
To further decrease transaction time, qVSDC moves the following risk management features to
an earlier point in the transaction (Initiate Application Processing):
• Card risk management
• Online card authentication
• Offline card authentication
• Cryptogram generation
For online transactions without an AFL, no commands are necessary after the application has
been selected, other than the GET PROCESSING OPTIONS command.
For offline transactions (and online transactions with an AFL), additional data is read using the
READ RECORD command.
4.1.2 <This section has been deleted>
4.2 qVSDC
Contactless interaction is defined by the amount of time the cardholder can reasonably and
consistently hold the card in position. qVSDC, which is based on EMV concepts and uses the
existing Visa systems and rules of operation, addresses this human requirement while
protecting the investments already made in the chip (EMV) infrastructure.
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 one of the Cryptogram Versions listed in Appendix C Cryptogram
Versions.
In addition to a full qVSDC path incorporating all of the Card Action Analysis described in
section 6.4, a streamlined version of qVSDC Card Action Analysis is specified to offer simplified
qVSDC online-only implementations. Details on supporting qVSDC streamlined functionality
are found in Appendix H.
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.
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 GPO 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 GPO command, rather than generating the dynamic signature at the end
of the transaction when the card may be moving away from the reader RF field.
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.
[VIS] counters and indicators, other than those specified in this document, are not impacted
during qVSDC processing.
4.5 Processing Overview
This section provides an overview of a VCPS transaction. This is followed by a transaction flow
showing the order in which these functions are performed and the commands sent by the
reader to the card. Functions are mandatory unless specified otherwise.
4.5.1 Processing Prior to Enabling the Contactless Interface
Reader processing performed prior to powering on the contactless interface and prompting
for card presentment.
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.
4.5.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.

4.5.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 PPSE is used in place of the
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.
4.5.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 Processing Options Data Object List (PDOL).
Initiate Application Processing is where the card performs Card Action Analysis, generates the
Application Cryptogram, (conditionally) generates the signature for Offline Data
Authentication, and returns card application data.
4.5.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.
4.5.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 all mandatory data elements were not returned or
redundant primitive data elements were returned.
4.5.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 PAN is on the Terminal Exception File.
4.5.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.
4.5.9 Cardholder Verification
During Cardholder Verification, the reader determines the Cardholder Verification Method to
be performed (if any).
4.5.10 Online Processing (Conditional)
Online Processing is implemented for readers supporting online transactions. Online

Processing is performed when online processing is required for the transaction.
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.

4.5.11 Completion
Completion is performed by the reader to conclude transaction processing. The reader

indicates to the cardholder the outcome of the transaction.
4.5.12 Issuer Update Processing (Optional)
Issuer Update Processing is an implementation and acquirer-merchant option for readers. 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.
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.

Figure 4–1: Sample Transaction Flow
Reader Card
KEY Processing Prior to

Enabling the
Contactl ess Interface
Mandatory
Contactless Interface En abled
Process
Discov ery Processing

Card Presented for P OS Payment
Conditional
Process SELECT PPSE
Command/Response List of Supported
Application Selection
SELECT AID Applications
Command/Response
Optional
Process Det ermine Path,
Perform Card Acti on
Init iate Appli cation GET PROCESSING OPTIONS Analysis, Perform
Processing Command/Response Cryptography, and
Card in RF Return Appli cation
Field Data
READ RECOR D Provide Appli cation

Read Appl ication Data
Commands/Responses Records
Card May Be Removed Fro m Reader RF Field

Card Read Complete
Processing R estricti ons
Offline Data
Authentication
Cardhol der Verification
Online Processing
Completion
Card Represented fo r Issue r Upda te Pro cessing (Optiona l)
SELECT AID Command/Response

Validat e ARPC
Issuer Update
EXTERNAL AUTHENTICATE Command/Response Cryptogram and/or
Processing
Apply Issuer Script
Issuer-to-Card Script Commands/Responses

4.6 Transaction Timing
Business needs dictate that the “card-in-field” time for contactless transactions is to be
minimized. “Card-in-field” time is the duration in which the cardholder is required to keep their
card in the reader RF field for a contactless transaction.
4.6.1 Timings for Card and Reader Interaction
Req 4.1 (Transaction Timing)
qVSDC transaction times shall not 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. Of the 500 milliseconds, the time used by
the card shall not exceed 400 milliseconds, and the time used by reader shall not exceed 100
milliseconds.
This time does not include the time required to go online for an authorization or for the
qVSDC reader to validate a dynamic signature for offline data authentication.
Please contact your Visa regional representative for any additional performance requirements
that may be applicable for your region.

5 Reader Requirements
VCPS readers shall be implemented either as defined in this specification, or as defined in
[EMV CL PAYMENT] Book A, Book B, Book C-3 (Kernel 3), and Book D.
The reader functionality and requirements defined in this specification are Implementation-
Mandatory, except where explicitly stated otherwise.
5.1 Contactless Communication Protocol Requirements
Reader requirements for the contactless communication protocol are specified in [EMV CL
PAYMENT] Book D.
Req 5.1 <This requirement has been deleted>
5.2 General Reader Requirements
This section defines general reader requirements that may be applicable across multiple
functions of the VCPS transaction flow.
5.2.1 Reader Requirements
Req 5.3 (Offline-capable Readers)
Offline-capable readers shall support fDDA.
Req 5.4 (Receipts)
Receipts are not detailed in this specification, however the following applies:
Readers shall provide receipts as required by the Visa Core Rules and Visa Product and Service
Rules.

Req 5.5 (POS Supports Multiple Interfaces)
For POS devices capable of accepting transactions over multiple interfaces, all permitted
interfaces should be made available to the merchant/cardholder to perform a transaction.
However, to prevent interference between the contact chip and contactless interfaces, the
reader shall always power down the contactless interface prior to the POS device resetting
the card to initiate a contact chip transaction. The contactless interface shall remain powered
down for the duration of the transaction conducted over the contact chip interface.
Req 5.5A (POS Supports Multiple Interfaces – Data Segregation)
For POS devices capable of accepting transactions over multiple interfaces, the transaction
data shall be from a single interface and data shall not be mixed across interfaces.
• For contact chip transactions (POS Entry Mode indicates a contact chip read), the value of
all card-originated data used for the transaction shall be as read from the contact chip
interface.
• For contactless chip transactions (POS Entry Mode indicates a contactless chip read), the
value of all card-originated data used for the transaction shall be as read from the
contactless chip interface.
• For physical magnetic stripe transactions (POS Entry Mode indicates a physical magnetic
stripe read), the value of all card-originated data used for the transaction shall be as read
from the magnetic stripe interface.
5.2.2 qVSDC Reader Requirements
When the qVSDC-enabled reader is idle, the contactless interface should not be powered
unless the reader also supports non-Visa functionality requiring the field to be energized.
While the operation of non-Visa functionality is outside the scope of this specification, it is
recommended that the same principle should be applied, and that the contactless interface
should be powered down when the reader is idle.
Req 5.6 (qVSDC Message Requirements)
Data requirements for qVSDC online messages and clearing records shall be as specified in
Appendix K.2.
Req 5.7 (qVSDC Messages – FFI and CED)
The reader shall make the Form Factor Indicator and Customer Exclusive Data available for
inclusion in messages to the acquirer (when returned by the card application).

Please check with your Visa regional representative regarding the required support for these
data elements in acquirer messaging.
Req 5.7A (qVSDC – Token Data)
The reader shall support output of the following data object (when returned by the card
application), for possible use by the merchant and transmission to the acquirer:
• Payment Account Reference (PAR, tag '9F24')
Note: The above data object is not normally included in messages to the acquirer, but readers
must be capable of outputting the data object when returned by the card application.
Req 5.8 (Interrupted Card Read)
If a contactless transaction is in progress (and Read Application Data has not been
completed) when a contact chip transaction is initiated, then the reader shall switch
interfaces.
Design consideration should be given to placement of the contactless reader relative to other
card interfaces. The contactless reader should not be placed such that it is frequently
activated when cardholders attempt to use other interfaces.
5.2.4 Reader Configuration Requirements
This section defines some of the configuration requirements for readers. Configuration of the
reader shall conform to these requirements, but the reader need not enforce configuration
requirements.
5.2.4.1 Reader Configuration Requirements

Req 5.14 (Issuer Update Processing and Online Capability)
If Issuer Update Processing is supported by reader (TTQ byte 3 bit 8 is 1b), then the reader
shall support online processing (TTQ byte 1 bit 4 is 0b).
Req 5.15 (qVSDC Transactions with Amount Zero)
qVSDC transactions shall either be sent online or conducted over another interface when the
Amount, Authorized is zero.
Reader Risk Parameters are configured in the qVSDC-enabled reader to enforce this
requirement.
5.2.4.2 <This section has been deleted>
5.2.5 Reader Processing Requirements
Req 5.18 (Purchase Transactions)
Implementation-Conditional: Implementation support for the purchase of goods and services

is implementation-mandatory. However, the associated cashback functionality is
implementation-conditional on reader support for cashback.
For transactions to purchase goods or services, with or without cashback, the qVSDC-enabled
reader shall use:
• Transaction Type '00'.
• Amount, Authorized shall be the sum of the purchase amount and the cashback amount
(if present and known).
• Amount, Other shall be the cashback amount (if present and known).
Note: Acquirers-merchants may wish to use a different Terminal Transaction Qualifiers (TTQ)
value and different Reader Risk Parameters for purchase transactions with cashback than is
used for purchase transactions without cashback. The reader should allow the acquirer-
merchant to configure the TTQ and Reader Risk Parameters for purchase transactions with
cashback independently from purchase transactions without cashback.
Req 5.19 (Manual Cash Transactions)
Implementation-Conditional: This functionality shall be implemented if the reader supports

manual cash transactions.

For manual cash transactions, the qVSDC-enabled reader shall use:
• Amount, Authorized shall be the transaction amount.
Note: Acquirers-merchants may wish to use a different Terminal Transaction Qualifiers (TTQ)
value and different Reader Risk Parameters for manual cash transactions than is used for
purchase transactions (with or without cashback). The reader should allow the acquirer-
merchant to configure the TTQ and Reader Risk Parameters for manual cash transactions
independently from purchase transactions.
VCPS transactions directly result in the purchase of goods or services and/or in the
disbursement of cash. Refunds and credits are commonly employed to support the retail or
cash disbursement environment, but do not directly result in the purchase of goods or
services, nor in the disbursement of cash. VCPS functionality can be used to support refunds
and credits, and shall comply with the following requirement for the Transaction Type and
Amount, Authorized values used. However, all other reader processing for refunds and credits
is outside the scope of this specification.
Req 5.20 (Refund Transactions)

refunds/credits.
For refunds and credits, the qVSDC-enabled reader shall use:
• Amount, Authorized shall be the refunded/credited amount.
Note: An AAC returned by the card application for refunds and credits simply indicates
completion of card action analysis, and should not be treated as a "decline" of the refund.
Req 5.21 (Form Factor Indicator)
If the Form Factor Indicator (FFI) is returned by the card application, then the qVSDC-enabled
reader shall replace FFI byte 4 bits 4-1 with the value 0000b (indicating that the transaction
was conducted using [ISO 14443]) prior to making the FFI available for inclusion in messages
to the acquirer.
Req 5.22 (Unpredictable Number)
If the reader is to return to Discovery Processing after card presentment, then the reader shall
discard any previously generated (Reader-Terminal) Unpredictable Number and shall

generate a new (Reader-Terminal) Unpredictable Number for use in subsequent transaction
processing.
Req 5.23 (Unrecoverable [EMV CL PAYMENT] Book D Error)
If an unrecoverable [EMV CL PAYMENT] Book D error occurs during an application command

(e.g. unrecoverable time-out error) followed by a Reset as defined in [EMV CL PAYMENT]
Book D, then the reader shall discard the current transaction data and shall return to
Discovery Processing.
[EMV CL PAYMENT] Book D errors are defined in the [EMV CL PAYMENT] Book D Definitions
section.
Req 5.24 (Cardholder Messaging)
For contactless transactions, the reader (or terminal) shall clearly communicate to the
cardholder and merchant:
• Present the card
• The progress of the transaction
• The outcome of the transaction – approve, decline, or terminate
Recommended cardholder messages and indications for various transaction states are
defined in [EMV CL PAYMENT] Book A.
The qVSDC-enabled reader may display the Amount, Authorized (tag '9F02') when prompting
for a card to be presented.
If the card provides the Available Offline Spending Amount, then the qVSDC-enabled reader
may display this when it indicates a successful card read and may print it on the transaction
receipt.
Note: This specification indicates when communication with the cardholder and merchant
occurs, but does not specify the means of communication. User interface requirements are
specified on a regional basis.
Req 5.25 (Erroneous Data)
It is the responsibility of the issuer to ensure that data in the card is formatted correctly, and
no format checking other than that specifically defined is required on the part of the reader.
However, if in the course of normal processing the reader recognizes that data is incorrectly
formatted, then the reader shall terminate the transaction unless otherwise specified.
Incorrectly formatted data includes, but is not limited to, the bulleted list provided in [EMV]
Book 3 section 7.5.

5.3 Processing Prior to Enabling the Contactless Interface
In order to minimize the time that the card must be in the field, qVSDC-enabled readers
supporting variable transaction amounts perform processing prior to powering on the
contactless interface and prompting for card presentment.
5.3.1 Pre-processing Required Check
Req 5.26 (Pre-processing Performed)
Reader Preliminary Transaction Processing (Pre-processing), as described in section 5.3.2,

shall be performed by qVSDC-enabled readers supporting variable transaction amounts. The
reader contactless interface shall not be powered on until Pre-processing has been
completed.
Req 5.27 (No Pre-processing Performed)
If Pre-processing is not performed, then the reader shall immediately power on the
contactless interface and proceed to Discovery Processing. The reader shall generate the
(Reader-Terminal) Unpredictable Number.
If the transaction amount is not a predefined value or has not been obtained, then the reader
shall use a value of all zeros for the Amount, Authorized.
5.3.2 Reader Preliminary Transaction Processing (Pre-processing)
Implementation-Conditional: Pre-processing shall be implemented for readers that implement

variable transaction amounts. All Reader Risk Parameter Checks shall be implemented. Pre-
processing shall be performed for qVSDC-enabled readers supporting variable transaction
amounts.
The qVSDC-enabled reader performs Pre-processing to obtain the transaction amount and
perform reader risk management. The result of reader risk management is the setting of
appropriate bits in the Terminal Transaction Qualifiers (TTQ), and determination of whether the
contactless interface is to be powered on. Modification of TTQ bits during Pre-processing is
transient, and shall not affect the TTQ value obtained for subsequent transactions.
For devices where the transaction amount is a fixed value, TTQ bit settings are already known
and need not be determined on a transaction by transaction basis.

5.3.2.1 Pre-processing Data Initialization
Req 5.28 (Amount, Authorized)
The reader shall obtain the Amount, Authorized (tag '9F02').

Note: For transactions with cashback, the Amount, Authorized is the sum of the purchase
amount and the cashback amount.
Req 5.29 (Reader Unpredictable Number)
The reader shall generate the (Reader-Terminal) Unpredictable Number (tag '9F37').
Req 5.30 (Contactless Application Not Allowed)
The Contactless Application Not Allowed indicator and TTQ byte 2 bits 8-7 are transient
values, and reset to 0 at the start of Pre-processing.
5.3.2.2 Reader Risk Parameters Checking
Acquirer-Merchant-Optional: If Pre-processing is implemented, then the acquirer-merchant

shall have the capability to enable and disable each individual reader risk parameter check
defined below.
Req 5.31 (Status Check)
The default setting for this check shall be disabled.

If the Amount, Authorized is a single unit of currency (that is, if a Status Check is being
requested), then the reader shall indicate Online Cryptogram Required (set TTQ byte 2 bit 8
to 1b).
Note: Use of status checks is limited to automated fuel dispensing environments.
Req 5.32 (Amount, Authorized of Zero Check)
If the Amount, Authorized is zero, an online-capable reader shall have the following
configurable options (at most one option may be enabled at a time):
• Option 1 – Indicate Online Cryptogram Required (set TTQ byte 2 bit 8 to 1b).
• Option 2 – Set the Contactless Application Not Allowed indicator for Visa AIDs to 1.
The default behavior is Option 1, but devices shall be capable of being configured to use
Option 2 instead.

Req 5.33 (Amount, Authorized of Zero Check)
If the Amount, Authorized is zero, then an offline-only reader shall set the Contactless
Application Not Allowed indicator for Visa AIDs to 1.
Req 5.34 (Reader Contactless Transaction Limit (RCTL) Check)
If the Amount, Authorized is greater than or equal to the Reader Contactless Transaction
Limit, then the reader shall set the Contactless Application Not Allowed indicator for Visa
AIDs to 1.
Note: It is strongly recommended that the Reader Contactless Transaction Limit Check be
disabled. Visa rules may require that this limit be disabled, with limited exceptions for specific
acceptance environments.
Req 5.35 (Reader CVM Required Limit Check)
If the Amount, Authorized is greater than or equal to the Reader CVM Required Limit, then
the reader shall indicate CVM Required (set TTQ byte 2 bit 7 to 1b).
Req 5.36 (Reader Contactless Floor Limit Check)
If the Amount, Authorized is greater than either the Reader Contactless Floor Limit or (if the
Reader Contactless Floor Limit is not present) the applicable Terminal Floor Limit (tag '9F1B'),
then the reader shall indicate Online Cryptogram Required (set TTQ byte 2 bit 8 to 1b).
5.3.2.3 Power On Contactless Interface
Req 5.37 (Power On Contactless Interface)
Upon successful completion of Reader Pre-processing, the reader shall power on the
contactless interface and shall proceed to Discovery Processing.
However, if the Contactless Application Not Allowed indicator (or equivalent indicator) is 1
for all reader supported applications, then the reader may leave the contactless interface
powered off and may switch to another interface.
5.4 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.

Req 5.38 (Request Card)
The reader shall request that the card be presented and shall perform polling and collision
detection as defined in [EMV CL PAYMENT] Book D.
Req 5.39 (Collision)
If multiple contactless payment cards are simultaneously detected prior to application

selection, then the reader shall indicate this condition to the cardholder and shall request
placement of a single payment card.
Req 5.40 (Power Off Contactless Interface)
qVSDC-enabled readers shall support powering off the contactless interface for the following
situations:
• Upon merchant command. For example, to cancel the transaction.
• After a pre-defined timeout period.
5.5 Application Selection
1. The reader builds a candidate list of mutually supported applications.
transaction.
Figure 5–1: Application Selection Using Directory Selection Method briefly outlines reader
processing to perform Application Selection using the Directory Selection Method.

Figure 5–1: Application Selection Using Directory Selection Method
Reader Card
Begin Application SELECT command SELECT response for
Selection with PPSE filename the PPSE
SELECT response
SW1 SW2 =
‘9000’?
N Y
Any Directory
Process (next)
Entries in FCI Y
Directory Entry
IDD?
N ADF Name matches

AID in reader (full or
partial)?
Out-of-scope Y N
Remove application Add application to

from candidate list candidate list
More Directory
Choose application
N Entries in FCI
from candidate list
IDD?
Empty Indicate error to

Y
candidate list? cardholder
Out-of-scope
N
Single
application in
Y
the candidate
list?
N
Multiple applications
in candidate list. SELECT command with SELECT response for
Determine highest ADF of the application the AID
priority application
SW1 SW2 =
N SELECT response
‘9000’?
Y
Y
Application Program
Reset Contactless
Dynamic ID returned by card
Application Not Allowed
Reader Limits Y and matches reader Y
Indicator and TTQ
supported? supported Application
transient bits
Program ID?
N
N
Perform Reader Risk
Contactless
Parameters Checking
Application Not
using Reader Limit Set
Allowed Indicator
for the matching
= 1?
Application Program ID
N
End Application
Selection

5.5.1 SELECT Command
To facilitate Application Selection, support for the SELECT command is required.
Req 5.41 (SELECT Command)
The reader shall support the SELECT command, as defined in Appendix G of this specification.
Req 5.42 (DF Names)
The reader shall support DF Names (AIDs) (tag '4F') up to the full 16 byte maximum length.
5.5.2 Directory Selection Method using PPSE
The construction of the candidate list is modeled after the [EMV] Directory Selection Method,
except that support for the Directory Selection Method is mandatory for readers (and cards),
and the PPSE is used in place of the PSE.
The use of proprietary selection methods is not precluded, but is outside the scope of this
specification. Users of proprietary selection methods should be aware of the potential negative
impact on performance introduced by any increase in the number of commands. The
proprietary selection method also needs to deal with the complexity of priorities amongst all
available brands and applications. If the proprietary selection method is unsuccessful and the
Directory Selection Method using the PPSE is to be used, this may require that the reader
power off the contactless interface.
Req 5.43 (PPSE)
The reader shall support the Directory Selection Method using the PPSE, as defined in this
section.
The reader shall perform the following procedure to determine the application to be selected:
Req 5.44 (SELECT PPSE)
The reader shall, using the SELECT command, select the PPSE with a file name of
'2PAY.SYS.DDF01'.
If the reader receives SW1 SW2 = '9000' in response to the SELECT command, then the
reader shall continue processing.
Else (reader receives SW1 SW2 ≠ '9000'), reader processing is outside the scope of this
specification.

Req 5.45 (FCI Issuer Discretionary Data Processing)
Beginning with the first Directory Entry (tag '61'), the reader shall sequentially process each
Directory Entry (tag '61') from the FCI Issuer Discretionary Data (tag 'BF0C').
Req 5.46 (Empty FCI at qVSDC-Enabled Reader)
If there is no Directory Entry (tag '61') in the FCI Issuer Discretionary Data (tag 'BF0C'), then
reader processing is outside the scope of this specification.
Req 5.47 (Building the Candidate List)
The reader shall examine the ADF Name (tag '4F') of each Directory Entry (tag '61').
If the ADF Name (tag ‘4F’) in the Directory Entry (tag ‘61’) matches an AID in the reader, then
the reader shall add the application to the candidate list. The application information added
to the candidate list shall include the ADF Name (tag ‘4F’) and the Application Priority
Indicator (tag ‘87’, if present).
The ADF Name (tag ‘4F’) matches an AID in the reader if:
• The ADF Name has the same length and value as the AID (full match)
• or the ADF Name begins with the entire AID (partial match).
If the ADF Name (tag ‘4F’) is not coded according to [EMV] Book 1 section 12.2.1, then the
reader shall ignore the Directory Entry.
5.5.3 Final Selection
Once the reader determines the list of mutually supported applications, it shall perform the
following procedure to select an application.
Req 5.48 (Candidate List – Empty)
If there are no mutually supported applications in the candidate list, then the reader shall
indicate an error to the cardholder. Subsequent processing is outside the scope of this
specification.
Req 5.49 (Candidate List – Single Application)
If there is only one mutually supported application in the candidate list, then the reader shall
select the application.

Req 5.50 (Candidate List – Multiple Applications)
If multiple applications are supported in the candidate list, then:

• The reader shall select the application with the highest priority.
• Applications with an Application Priority Indicator (tag '87', bits 4-1) value of 0000b, or no
Application Priority Indicator (tag '87') at all, are considered to be of (equal) lowest
priority.
• In the case of multiple candidates with equal priority, the candidates shall be selected in
the order listed in the PPSE.
Req 5.51 (Select Application)
The reader shall send the SELECT command with the ADF Name (tag '4F') of the selected
application. If the selected application is not a Visa AID, then subsequent reader processing is
outside the scope of this specification.
reader shall:
• If Issuer Update Processing is supported by the reader, then the reader shall commit the
full ADF Name (AID) of the selected application to memory, for possible use during Issuer
Update Processing.
• Continue processing the transaction.
Else (reader receives SW1 SW2 ≠ '9000'), the reader shall remove the application from the
candidate list and shall return to the beginning of Final Selection processing.
5.5.4 Dynamic Reader Limits (DRL) Functionality
Implementation-Optional: Implementers may implement support for DRL functionality for

qVSDC readers.
Acquirer-Merchant-Optional: If implemented, DRL functionality shall be acquirer-merchant

configurable to be enabled or disabled. If enabled, the acquirer-merchant shall be able to
configure the number of Application Program IDs to use.
DRL functionality allows the reader to apply different Reader Limit Sets for different card
applications (even if they have the same AID), allowing the reader to vary Reader Risk
Parameters on a transaction by transaction basis.
For example, a reader may apply one set of Reader Risk Parameters for domestic Visa credit
applications, and apply another set of Reader Risk Parameters for international Visa credit
applications.

The Application Program Identifier (Application Program ID) is a Visa proprietary card
application data element that identifies the Reader Risk Parameters applicable to the selected
application. The reader examines the Application Program ID returned by the card in the
SELECT response and applies the corresponding Reader Risk Parameters.
If DRL functionality is enabled, then the qVSDC-enabled reader performs DRL processing to
determine the Reader Risk Parameters (see section 5.3.2.2) to use for the selected application.
5.5.4.1 Reader Limit Set
The value of limits used in Reader Risk Parameters checking, and whether individual checks are
enabled or disabled, are specified in a Reader Limit Set. The Reader Limit Set indicates whether
each of the individual checks are enabled or disabled, and the value of the limit when the
corresponding check is enabled.
Req 5.52 (Reader Risk Parameters)
Each Reader Limit Set shall allow the acquirer-merchant to configure the following Reader
Risk Parameters:
• Status Check – Configurable to indicate whether this check is enabled or disabled.
• Amount, Authorized of Zero Check – Configurable to indicate whether this check is
enabled or disabled. If enabled, configurable to indicate whether Option 1 or Option 2 is
to be used.
• Reader Contactless Transaction Limit Check – Configurable to indicate whether this check
is enabled or disabled, and the value of this limit when enabled.
• Reader CVM Required Limit Check – Configurable to indicate whether this check is
enabled or disabled, and the value of this limit when enabled.
• Reader Contactless Floor Limit Check – Configurable to indicate whether this check is
enabled or disabled, and the value of this limit when enabled.
Req 5.53 (Reader Limit Sets)
The reader shall support a default Reader Limit Set, to be used when no matching Application
Program ID (or no Application Program ID at all) is returned in the SELECT response. The
default Reader Limit Set contains the Reader Risk Parameters used during Reader Preliminary
Transaction Processing (Pre-processing).
In addition to support for the default Reader Limit Set, the reader shall implement support
for a minimum of 4 unique Application Program IDs and 4 corresponding Reader Limit Sets.
Implementations may optionally support more than 4 Application Program IDs and
corresponding Reader Limit Sets.

5.5.4.2 Dynamic Reader Limits (DRL) Processing
DRL Processing is performed to determine the Reader Limit Set applicable to the selected
application. When a matching Application Program ID is returned by the card application, the
reader replaces the results of Reader Risk Parameters Checking that used the default Reader
Limit Set (performed during Pre-processing) with the results of Reader Risk Parameters
Checking using the matching Reader Limit Set.
If DRL functionality is supported, the reader shall perform the following procedure:
Req 5.54 (Application Program ID)
The reader examines the Application Program ID returned in the SELECT response to
determine which Reader Limit Set to apply.
The card Application Program ID matches an Application Program ID in the reader if:
• The card Application Program ID has the same length and value as the reader Application
Program ID (full match)
• or the card Application Program ID begins with the entire reader Application Program ID
(partial match)
If no Application Program ID is returned or the Application Program ID does not match any
reader supported Application Program ID, then the reader shall use the results of Reader
Preliminary Transaction Processing (Pre-processing) and proceed with the Contactless
Application Allowed Check (section 5.5.5).
Else (the Application Program ID matches one or more supported reader Application
Program IDs), the reader shall:
• Reset the Contactless Application Not Allowed indicator to 0 and the transient bits of the
TTQ (byte 2 bits 8-7) to 0b.
• Perform Reader Risk Parameters Checking using the Reader Limit Set that corresponds to
the longest matching reader Application Program ID. Reader Risk Parameters Checking is
performed as defined in section 5.3.2.2.
• Proceed with the Contactless Application Allowed Check (section 5.5.5).
Note: Readers should not be configured with multiple instances of the same Application Program
ID value.
Note: If not precluded by reader support for other payment systems, some reader processing
performed during Dynamic Reader Limits Processing may be performed during Reader
Preliminary Transaction Processing (Pre-processing). To minimize the processing performed while
the card is in the reader field, it is recommended that readers perform Reader Risk Parameters
Checking for each supported Application Program ID during Pre-processing. The value of the
Contactless Application Not Allowed indicator and the TTQ are then stored for each Application

Program ID, and used by the reader if the corresponding Application Program ID is returned by
the card application.
5.5.5 Contactless Application Allowed Check
Implementation-Conditional: This section shall be supported if Pre-processing is supported.
The reader examines the Contactless Application Not Allowed indicator to determine whether
the selected application is allowed to transact over the contactless interface.
Req 5.55 (Contactless Application Not Allowed)
If the Contactless Application Not Allowed indicator is 1, then the reader shall remove the
application from the candidate list and return to the beginning of Final Selection processing.
Else (the Contactless Application Not Allowed indicator is 0), the reader shall continue
processing the transaction.
5.6 Initiate Application Processing
During Initiate Application Processing, the reader issues the GET PROCESSING OPTIONS (GPO)
command to the card, and includes any data that the card has requested in the PDOL during
Application Selection. Application data necessary to process the transaction is returned by the
card application during Initiate Application Processing, and may also be returned during Read
Application Data.
5.6.1 GET PROCESSING OPTIONS (GPO) Command
To facilitate Initiate Application Processing, support for the GPO command is required.
Req 5.56 (GPO Command)
The reader shall support the GET PROCESSING OPTIONS (GPO) command, as defined in
Appendix G of this specification.
Data Object List (DOL) coding is performed according to [EMV] Book 3 section 5.4. Readers
shall be able to provide the value of reader data elements (defined in Appendix D) requested
by the card application.
Req 5.57 (Format 2)
Readers shall support GPO responses in [EMV] Format 2, as defined in Appendix G of this
specification.
Req 5.58 (Recognized and Unrecognized Data)
The reader shall store all recognized data elements read, whether mandatory or optional, for
later use in transaction processing. Data elements that are not recognized by the reader (that
is, their tags are unknown by the reader) may be ignored and do not need to be stored.
Note: As the card application may return application data in both the GPO response and in
records, the reader does not check for the presence of mandatory data elements until Card Read
Complete. For example, although the card is required to return the Issuer Application Data in the
GPO response (amongst other data elements), the reader is required to be able to handle
receiving these data elements regardless of whether they're returned in the GPO response or in a
READ RECORD response.
5.6.2 Initiate Application Processing
Figure 5–2: Initiate Application Processing (Reader) briefly outlines reader processing to
perform Initiate Application Processing.

Figure 5–2: Initiate Application Processing (Reader)
Reader Card
Begin Initiate
Application Processing
PDOL not returned in

SELECT response or TTQ GET PR OCES SING
tag not present in N: GET PR OCES SING OPTION S command OPTION S processing
PDOL?
Y Remove application Return to Final

from candidate list Selection
GET PR OCES SING OPTION S response
SW1 SW2 = Complete Initiate

Y
‘9000’? Application Processing
SW1 SW2 =
Y Switch Interface
‘6984’?
SW1 SW2 = Remove application Return to Final

Y
‘6985’? from candidate list Selection
Display message,
SW1 SW2 = power down CL Return to Discovery
Y
‘6986’? interface, and wait Processing
1000ms – 1500ms
N Terminate transaction
Prior to initiating the transaction with the card, the reader checks the SELECT response for the
presence of the Processing Options Data Object List (PDOL, tag '9F38'), and for the presence of
the Terminal Transaction Qualifiers (TTQ, tag '9F66') tag in the PDOL.
Req 5.59 (PDOL in SELECT Response)
If either of the following is true:

• the PDOL (tag '9F38') is not present in the SELECT response
• or TTQ tag '9F66' is not present in the PDOL
Then the reader shall remove the application from the candidate list and return to the
beginning of Final Selection processing.

Note: The reader does not perform any processing based on the length of reader-terminal data
elements requested by the card application in the PDOL. For example, the length of the TTQ
requested by the card application in the PDOL has no impact on reader processing.
The reader shall perform the following procedure to initiate the transaction with the card.
Req 5.60 (Issue GPO Command)
The reader shall issue the GET PROCESSING OPTIONS (GPO) command. The command data
field is a data object coded according to the PDOL provided by the card, preceded by the
Command Template tag and length.
Req 5.61 (GPO Response SW1 SW2)
If the reader receives SW1 SW2 = '9000' in response to the GPO command, then the reader
shall continue Initiate Application Processing.
Else, if the reader receives SW1 SW2 = '6984' in response to the GPO command, then the
reader shall switch interfaces.
reader shall remove the application from the candidate list and shall return to the beginning
of Final Selection processing.
reader shall:
• Indicate to the cardholder to refer to their payment device for further instructions and
immediately power down the contactless interface.
Note: SW1 SW2 = '6986' is not returned by cards compliant to this specification. However,
reader behavior is defined in this specification to support consumer payment devices that are
capable of informing the cardholder of the subsequent action to take. For example, the
consumer payment device may be a mobile handset capable of instructing the consumer of
the action to take.
• After a duration of between 1000ms and 1500ms, the reader shall power up the
contactless interface and return to Discovery Processing. Any message displayed to the
cardholder shall continue to be displayed during the subsequent Discovery Processing.
Else (SW1 SW2 does not match any of the above), the reader shall terminate the transaction.

5.7 Read Application Data
The reader performs Read Application Data if an Application File Locator (AFL) was returned
during Initiate Application Processing, and proceeds to Card Read Complete if an AFL is not
returned.
During Read Application Data, the reader uses the READ RECORD command to retrieve the
card data necessary to process the transaction.
5.7.1 READ RECORD Command
Req 5.63 (READ RECORD Command)
The reader shall support the READ RECORD command, as defined in Appendix G of this
specification.
5.7.2 Read Application Data
The reader shall perform the following procedure to read the card application data.
Req 5.64 (Application File Locator)
If the Application File Locator (AFL, tag '94') is returned during Initiate Application Processing,
then the reader shall perform Read Application Data as specified in [EMV] Book 3,
section 10.2.
If the Application File Locator (AFL, tag '94') was not returned during Initiate Application
Processing, then the reader shall proceed to Card Read Complete.
5.8 Card Read Complete
After Read Application Data has been completed, the reader indicates to the cardholder that
card read is complete, and the cardholder should remove their card from the reader’s RF field.
The reader checks the application data returned by the card to ensure that all mandatory data
for the transaction has been returned, and that redundant primitive data was not returned.
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 shall perform the procedure described in this section for Card Read Complete.
5.8.1 Cardholder Messaging
Req 5.65 (Card Read Complete Cardholder Messaging)
The reader shall indicate to the cardholder and merchant that card read is complete and that
the card may be removed, but that the transaction is still in progress.
Note: As with all cardholder indication and messaging requirements, this cardholder indication
may vary per regional requirements. For example, indication that the card read is complete
may consist simply of activating indicator lights with an audible beep. Contact your Visa
regional representative for additional guidance on cardholder indication and messaging
requirements for your region.
Req 5.66 (Card Read Complete)
The reader shall power off the contactless interface and continue processing the transaction.
Powering off the contactless interface in this requirement does not include stopping the
current application.
5.8.2 Mandatory and Redundant Data
The reader examines application data returned by the card during Initiate Application
Processing and Read Application Data to determine whether all mandatory data elements were
returned, and whether redundant primitive data elements were returned.
Req 5.67 (Mandatory Data)
The reader shall ensure that all mandatory data elements are returned by the card.
If any mandatory data elements are not present for the applicable path, then the reader shall
terminate the transaction.
Note: Mandatory data elements are identified in the Requirement column of Table D–1.
Req 5.68 (Redundant Data)
Redundant primitive data elements are not permitted.

If the reader encountered more than one occurrence of a single primitive data element while
reading data from the card during Initiate Application Processing and Read Application Data,
then the reader shall terminate the transaction.

5.8.3 Determine Card Transaction Disposition
5.8.3.1 qVSDC Path Processing
The reader shall perform the procedure defined in this section for qVSDC transactions.
Req 5.69 (Cryptogram Information Data)
If the Cryptogram Information Data (CID) is not returned by the card, then the reader shall:
• Construct the CID and initialize it with a value of '00'.
• Set CID bits 8-7 to the value of Issuer Application Data byte 5 bits 6-5 using identical bit
settings.
Note: Issuer Application Data byte 5 contains Card Verification Results (CVR) byte 2, indicating
the cryptogram type.
Req 5.70 (Cryptogram Type Transaction Disposition)
The reader examines the Cryptogram Information Data (CID) to determine the cryptogram
type (TC, ARQC, or AAC).
If an Application Authentication Cryptogram (AAC) is returned by the card, then the reader
shall set the Decline Required by Reader Indicator to 1.
If an Authorization Request Cryptogram (ARQC) is returned by the card or Online Cryptogram
Required by the reader (TTQ byte 2 bit 8 is 1b), then the reader shall set the Online Required
by Reader Indicator to 1.
If the cryptogram type cannot be determined (TC, ARQC, or AAC), then the reader shall set
the Decline Required by Reader Indicator to 1.
5.8.3.2 <This section has been deleted>
5.9 Processing Restrictions
The reader performs Processing Restrictions to determine whether there are restrictions for the
transaction. The reader checks the application expiration date, application usage, and may
check whether the card application PAN is on the Terminal Exception File.
5.9.1 qVSDC Path Processing

Req 5.74 (Application Expired Check)
Implementation-Conditional: The Application Expired Check shall be implemented for readers

supporting offline transactions.
This check shall be performed if a Transaction Certificate (TC) is returned by the card
application.
If the Terminal Transaction Date (local to the reader-terminal) is greater than the Application
Expiration Date (or the Application Expiration Date is not returned by the card application),
then the application has expired and the reader shall examine the Card Transaction Qualifiers
(CTQ) to determine further processing:
• If ‘Go Online If Application Expired’ indicated by card (CTQ byte 1 bit 4 is 1b), then the
reader shall set the Online Required by Reader Indicator to 1.
Else, the reader shall set the Decline Required by Reader Indicator to 1.
Req 5.75 (Terminal Exception File Check)
Implementation-Optional: Terminal Exception File checking is an implementation option.

Acquirer-Merchant-Optional: If implemented, then the Terminal Exception File Check shall be
acquirer-merchant configurable to be enabled or disabled.
This check shall be performed if a Transaction Certificate (TC) is returned by the card
application.
If the Application PAN is present on the Terminal Exception File, then the reader shall set the
Decline Required by Reader Indicator to 1.
Req 5.76 (Application Usage Control – Manual Cash Transactions)

manual cash transactions.
Acquirer-Merchant-Optional: If implemented, then this processing restriction shall be
acquirer-merchant configurable to be enabled or disabled for manual cash transactions.
This check shall be performed for manual cash transactions.
• Issuer Country Code matches the Terminal Country Code and the card application is ‘Valid
for domestic (manual) cash transactions’ (AUC byte 1 bit 8 is 1b)
• Issuer Country Code does not match the Terminal Country Code and the card application
is ‘Valid for international (manual) cash transactions’ (AUC byte 1 bit 7 is 1b)

Then the manual cash transaction is allowed and the reader continues processing the
transaction.
Else (application is not valid for the manual cash transaction, or Issuer Country Code or AUC
is not returned by the card application), the reader shall examine the Card Transaction
Qualifiers to determine further processing:
• If ‘Switch Interface for (manual) Cash Transactions’ supported by card (CTQ byte 1 bit 3 is
1b), then the reader shall switch to another interface.
Else (‘Switch Interface for (manual) Cash Transactions’ not supported by card or CTQ not
returned), the reader shall set the Decline Required by Reader Indicator to 1.
Req 5.77 (Application Usage Control – Cashback Transactions)

transactions with cashback.
Acquirer-Merchant-Optional: If implemented, then this processing restriction shall be
acquirer-merchant configurable to be enabled or disabled for cashback transactions.
This check shall be performed for transactions with cashback.
• Issuer Country Code matches the Terminal Country Code and ‘Domestic cashback
allowed’ by card application (AUC byte 2 bit 8 is 1b)
• Issuer Country Code does not match the Terminal Country Code and ‘International
cashback allowed’ by card application (AUC byte 2 bit 7 is 1b)
Then the transaction with cashback is allowed and the reader continues processing the
transaction.
Else (application is not valid for the transaction with cashback, or Issuer Country Code or AUC
is not returned by the card application), the reader shall examine the Card Transaction
Qualifiers to determine further processing:
• If ‘Switch Interface for Cashback Transactions’ supported by card (CTQ byte 1 bit 2 is 1b),
then the reader shall switch to another interface.
Else (‘Switch Interface for Cashback Transactions’ not supported by card or CTQ not
returned), the reader shall set the Decline Required by Reader Indicator to 1.
5.10 Offline Data Authentication
Offline Data Authentication is performed by the reader to verify the dynamic signature and
authenticate the data from the card.

Implementation-Conditional: Offline Data Authentication shall be implemented for readers

supporting offline transactions. Offline Data Authentication is performed for card requested
offline transactions.
The reader shall perform the procedure defined in this section for qVSDC transactions if the
Online Required by Reader Indicator is 0 and the Decline Required by Reader Indicator is 0.
Req 5.78 (fDDA Verification)
The reader shall verify the fDDA dynamic signature according to [EMV] and the definition of
fDDA in Appendix A.
If either fDDA fails or the reader is unable to perform fDDA, then the reader shall examine the
Card Transaction Qualifiers (CTQ) to determine further processing:
• If ‘Go Online If ODA Fails’ indicated by card (CTQ byte 1 bit 6 is 1b) and Online supported
by reader, then the reader shall set the Online Required by Reader Indicator to 1 and
continue processing the transaction.
Else, if ‘Switch Interface If ODA Fails’ indicated by card (CTQ byte 1 bit 5 is 1b) and EMV
contact chip supported by reader, then the reader shall switch to another interface. For
this case, the reader is aware that contact chip is supported, and shall explicitly indicate
that the contact chip interface is to be used.
Else (neither of the above or CTQ not returned), the reader shall set the Decline Required
by Reader Indicator to 1 and continue processing the transaction.
5.11 Cardholder Verification
The reader determines if a Cardholder Verification Method (CVM) is to be performed. The

CVMs that may be supported for VCPS are Online PIN, Consumer Device CVM, and Signature.
Note: A Consumer Device CVM is a CVM performed on, and validated by, the consumer's
payment device, independent of the reader.
Implementation-Mandatory: Cardholder Verification shall be implemented for qVSDC-enabled

readers.
Acquirer-Merchant-Optional: The acquirer-merchant shall be able to enable and disable the

supported CVMs. However, support for the Consumer Device CVM shall be enabled (TTQ byte
3 bit 7 is 1b).

The reader shall perform the procedure defined in this section for qVSDC transactions if the
Decline Required by Reader Indicator is 0.
Req 5.79 (CTQ Not Returned by Card)
If the reader requires a CVM and the Card Transaction Qualifiers (CTQ, tag '9F6C') is not
returned by the payment application:
• A reader that supports Signature, in addition to any other CVMs, shall acquire a signature
for the transaction.
• A reader that supports only the Consumer Device CVM and Online PIN shall perform
Online PIN and set the Online Required by Reader Indicator to 1.
• A reader that supports only the Consumer Device CVM shall set the Decline Required by
Reader Indicator to 1.
Note: Reader support for the Consumer Device CVM is mandatory, as is indication of its
support in the Terminal Transaction Qualifiers. In addition to supporting the Consumer Device
CVM, the reader may optionally be configured to support Online PIN and/or Signature.
Req 5.80 (CTQ Returned by Card)
If the CTQ (tag '9F6C') is returned by the payment application, then the reader shall examine
the CTQ (in the order specified below) to determine the CVM to be performed:
• If Online PIN Required by card (CTQ byte 1 bit 8 is 1b) and Online PIN supported by
reader, then the reader shall perform Online PIN and set the Online Required by Reader
Indicator to 1. The reader shall not examine the remaining CTQ bits for CVM processing.
Else (Online PIN not required or not supported), if Consumer Device CVM Performed by
card (CTQ byte 2 bit 8 is 1b), then:
̵ If the Card Authentication Related Data was returned during the transaction, then:
• If Card Authentication Related Data bytes 6-7 match CTQ bytes 1-2 (respectively),
then CVM processing is complete and the reader shall not examine the remaining
CTQ bits for CVM processing.
Else (Card Authentication Related Data bytes do not match CTQ bytes), the reader
shall set the Decline Required by Reader Indicator to 1. CVM processing is complete
and the reader shall not examine the remaining CTQ bits for CVM processing.
Note: If the Card Authentication Related Data returned by the card is less than 7
bytes in length, then Card Authentication Related Data bytes 6-7 cannot match CTQ
bytes 1-2.

Else (Card Authentication Related Data was not returned during the transaction), if the
cryptogram type is an ARQC, then CVM processing is complete and the reader shall not
examine the remaining CTQ bits for CVM processing.
Else (Card Authentication Related Data was not returned during the transaction and
cryptogram type is not an ARQC), the reader shall set the Decline Required by Reader
Indicator to 1. CVM processing is complete and the reader shall not examine the
remaining CTQ bits for CVM processing.
Note: For qVSDC online requests, the payment application response does not normally
contain the Card Authentication Related Data. Consequently, the reader cannot ensure
that the CTQ is verifiably unaltered after transmission by the payment application.
However, the issuer may examine CVR byte 2 bit 3 to determine whether a Consumer
Device CVM was successfully performed.
Else (Neither Online PIN required nor Consumer Device CVM performed), if Signature
Required (CTQ byte 1 bit 7 is 1b) and the reader supports Signature (TTQ byte 1 bit 2
is 1b), then the reader shall acquire a signature for the transaction.
Else (None of the above), a common CVM was not indicated in the CTQ and a CVM is not
performed.
Note: Cardholder Verification processing to determine the CVM to perform for the transaction,
if any, is performed in this section. However, actual performance of the CVM need not take
place during this point in the transaction (e.g. acquiring a signature for the transaction).
Req 5.81 (CVM Required and CVM Not Performed)
If the reader requires a CVM and a CVM will not be performed, then the reader shall set the
Decline Required by Reader Indicator to 1.
5.12 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.
Implementation-Conditional: Online Processing shall be implemented for qVSDC readers

supporting online transactions.
The reader shall perform the processing defined in this section for qVSDC transactions if the
Online Required by Reader Indicator is 1 and the Decline Required by Reader Indicator is 0.

Req 5.82 (qVSDC Online Authorization)
The reader shall send an online authorization request message to the acquirer. The minimum
data requirements for qVSDC online messages are specified in Appendix K.2.
5.13 Completion
Req 5.83 (qVSDC Online Processing Performed)
When Online Processing is performed and an authorization response message is received,

the reader shall examine the authorization response message to determine subsequent
processing.
If all of the following are true:
• Issuer Update Processing supported by reader
• and Issuer Update Processing supported by card (CTQ returned by card and CTQ byte 2
bit 7 is 1b)
• and Issuer Authentication Data or Issuer Script Template(s) received in authorization
response message
Then the reader shall proceed with Issuer Update Processing.
Else, the reader shall proceed with Transaction Approved (section 5.13.2) or Transaction
Declined (section 5.13.3) based upon the authorization response.
Req 5.84 (qVSDC Online Processing Not Performed)
When Online Processing is not performed (or performed and an authorization response
message is not received), the reader shall examine internal reader transaction disposition
indicators to determine subsequent processing.
If Online Required by Reader Indicator is 1 or Decline Required by Reader Indicator is 1, then
the reader shall proceed with Transaction Declined (section 5.13.3).
Else (neither Online nor Decline Required), the reader shall proceed with Transaction
Approved (section 5.13.2).

5.13.2 Transaction Approved
Req 5.85 (Cardholder Messaging for Approved)
The reader shall indicate to the cardholder and merchant that the transaction has been
approved.
If the Available Offline Spending Amount (AOSA) is returned by the card, then readers that
support displaying or printing the AOSA shall do so.
The reader is only required to print the AOSA in this situation when a receipt is provided.
5.13.3 Transaction Declined
Req 5.86 (Cardholder Messaging for Declined)
The reader shall decline the transaction and indicate to the cardholder and merchant that the
transaction has been declined.
If the Available Offline Spending Amount (AOSA) is returned by the card, then readers that
support displaying or printing the AOSA shall do so.
The reader is only required to print the AOSA in this situation when a receipt is provided.
Req 5.87 (Do Not Reattempt Transaction)
The reader shall not attempt to perform the transaction over another interface.
5.14 Issuer Update Processing
Implementation-Optional: Issuer Update Processing is an implementation option for readers

implementing qVSDC, and if supported, shall meet the requirements of both sections 5.14.1
and 5.14.2.
Acquirer-Merchant-Optional: If implemented, support for Issuer Update Processing is acquirer-

merchant optional. Reader support for Issuer Update Processing is indicated to the card by
setting ‘Issuer Update Processing supported’ by reader (TTQ byte 3 bit 8 to 1b).
If supported, Issuer Update Processing is conditionally performed for qVSDC Path Processing
(see section 5.13.1).

5.14.1 Issuer Update Commands
To facilitate Issuer Update Processing, support for the EXTERNAL AUTHENTICATE command
and issuer script processing is required.
Req 5.88 (EXTERNAL AUTHENTICATE Command)
When it is supported, the reader shall implement the EXTERNAL AUTHENTICATE command,
as defined in Appendix G.5 of this specification.
Req 5.89 (Issuer Scripts)
When it is supported, the reader shall implement Issuer Script processing according to [EMV]
Book 3 section 10.10, and [EMV] Book 4 section 6.3.9, except for the following:
• Unlike [EMV], Issuer Script Templates with tag '71' or '72' are processed and issued by the
reader in the same manner. There is no GENERATE AC command, and Issuer Script
Templates with tag '71' and '72' are both processed during Issuer Update Processing.
• No processing is performed on the Transaction Status Information (TSI) or Terminal
Verification Results (TVR).
5.14.2 Issuer Update Processing
The reader performs Issuer Update Processing as defined in this section.
Figure 5–3: Issuer Update Processing (Reader) briefly outlines reader processing to perform
Issuer Update Processing.

Figure 5–3: Issuer Update Processing (Reader)
Reader Card
Begin Issuer Update

Processing
Prompt for card SELECT command with SELECT response for

presentment ADF of the application the AID
SW1 SW2 =
‘9000’? SELECT response
Issuer EXTERNAL
Authentication Y: EXTERNAL AUTHENTICATE command AUTHENTICATE
Data received? processing
Issuer Script
Template(s)
EXTERNAL AUTHENTICATE response
received?
N
Send (next) issuer Issuer script
script command Issuer script command
processing
Any more SW1 SW2 =

issuer script Y ‘9000’, ‘62xx’, Issuer script response
commands? or ‘63xx’?
Indicate transaction N
outcome to
cardholder
End Issuer Update

Processing
The reader shall perform the following procedure to perform Issuer Update Processing.
Req 5.90 (Prompt for Card)
The reader shall prompt the cardholder to (re)present their contactless card for Issuer Update
Processing, and Discovery Processing shall be performed as specified in section 5.4.
If the reader powers off the contactless interface as described in Req 5.40 (Power Off
Contactless Interface), then the reader shall proceed to Req 5.94 (Second Tap Completed).

Req 5.91 (SELECT Application)
The reader shall issue a SELECT command specifying the full ADF Name (AID) of the
contactless card application from the previous transaction. This AID will have been previously
committed to memory by the reader.
reader shall continue processing.
Else (reader receives SW1 SW2 ≠ '9000'), the reader shall return to Prompt for Card.
Req 5.92 (EXTERNAL AUTHENTICATE Command)
If Issuer Authentication Data was received in the authorization response message, then the
reader shall issue an EXTERNAL AUTHENTICATE command using the Issuer Authentication
Data received.
Note: The reader does not perform processing based on the card response to the EXTERNAL
AUTHENTICATE command. The reader continues Issuer Update Processing regardless of the
SW1 SW2 value returned by the card.
Req 5.93 (Issuer Script Commands)
The reader issues issuer script command(s) if an Issuer Script Template was received in the
authorization response. Issuer Script Templates shall follow Issuer Script Template 1 or 2, and
an Issuer Script Template may have multiple issuer script commands.
In this version of the specification, at most one Issuer Script Template is supported in the
response message. However, readers shall parse all Issuer Script Templates received and issue
the corresponding issuer script commands.
The reader shall parse each Issuer Script Template to retrieve each issuer script command,
and shall transmit the commands to the card one by one.
If the response to an issuer script command is not SW1 SW2 = '9000', '62xx', or '63xx', then
the reader shall not send any further issuer script commands and shall discontinue Issuer
Script Command(s) processing.
Req 5.94 (Second Tap Completed)
The reader shall indicate to the cardholder the transaction outcome based on the issuer
authorization response, regardless of the results of Issuer Update Processing.
If the Available Offline Spending Amount (AOSA) was returned by the card (during Initiate
Application Processing or Read Application Data), then readers that support displaying or
printing the AOSA shall not do so.

6 Card Requirements
6 Card Requirements
The card functionality and requirements defined in this specification are Implementation-
Mandatory, except where explicitly stated otherwise.
6.1 Contactless Communication Protocol Requirements
Card requirements for the contactless communication protocol are specified in [EMV CL
PAYMENT] Book D.
6.2 General Card Requirements
This section defines general card requirements that may be applicable across multiple
functions of the VCPS transaction flow.
qVSDC is based on [EMV] card and terminal application specifications. [EMV] constructs,
commands, data elements, and functionality are leveraged where possible.
6.2.1 Card Requirements
Req 6.1 (Atomic Commands)
The card shall process each command as a single atomic operation. Commands shall be
processed in their entirety or not at all, with the following exception(s):
• Incrementing the Application Transaction Counter (ATC) shall be immediate and
irreversible.
• Resetting the Last Contactless Application Cryptogram Valid Indicator to 0 shall be
immediate and irreversible.
Req 6.2 (Counter Overflow)
Counters shall not be incremented above their maximum possible value (an overflow) and
shall not be decremented below zero.
If increment of a counter would result in an overflow, then the application shall set the
counter to the maximum possible value.
If decrement of a counter would result in a value less than zero, then the application shall set
the counter to a value of zero.

6 Card Requirements
For the evaluation of conditions, if incrementing a counter would result in an overflow or
decrementing a counter would cause a negative value to be used for the comparison, then
the result of the comparison shall be that velocity checking counters were exceeded.
Req 6.3 (Dual-Interface Contactless and Contact Cards)
Dual-interface contactless and contact cards supporting both [VCPS] and [VIS] shall
implement the functionality and requirements for dual-interface cards defined in Appendix I
Dual-Interface Contactless and Contact Cards.
Req 6.4 (Commands Restricted by Interface)
This requirement is only applicable after the card application has been personalized.
The card application shall only support and process commands received over the contactless
interface if they are explicitly defined in Appendix G.
If a command is received over an unsupported interface (for that command), then the card
application shall respond with an error SW1 SW2 ('6A81' is recommended).
Req 6.5 (qVSDC Path Support)
The following GPO responses shall be issuer configurable to be enabled or disabled:

• qVSDC Offline GPO Response (if offline implemented): see Table 6–2 using Condition
column "Offline (with ODA)"
• qVSDC Online with ODA GPO Response: see Table 6–2 using Condition column "Online
(with ODA)"
• qVSDC Online/Decline without ODA GPO Response: see Table 6–2 using Condition
column "Online and Decline (without ODA)"
If Card Action Analysis results in a transaction disposition with a disabled GPO response, then
the card application shall not perform the processing for the transaction disposition and shall
respond to the GPO command with error SW1 SW2 = '6985'.
Req 6.6 (Cryptogram Version Number)
The qVSDC path shall implement support for Cryptogram Version Number 10, Cryptogram
Version Number 17, and Cryptogram Version Number 18. The qVSDC path may implement
support for Cryptogram Version Number '22' and/or additional proprietary cryptograms at
implementer discretion. The Cryptogram Version to be used for cryptogram generation shall
be issuer configurable, and indicated by the issuer in the Cryptogram Version Number of the
Issuer Application Data returned for qVSDC transactions.

6 Card Requirements
Req 6.7 (Application Permanently Blocked)
If incrementing the ATC results in the ATC reaching its maximum value, then the application
shall be permanently blocked as follows:
• APPLICATION UNBLOCK shall be permanently disabled. The APPLICATION UNBLOCK
command is defined in Appendix G.5.2.
• All applications linked to this application for application blocking shall also be
permanently blocked, and APPLICATION UNBLOCK shall be permanently disabled for
those linked applications. Applications may have been linked as defined in [VIS].
• Cryptographic operations shall be disabled.
• The application shall respond to the SELECT command with SW1 SW2 = '6283' (indicating
application blocked).
• The application shall respond to the GET PROCESSING OPTIONS command with error SW1
SW2 = '6985', which permits another application to be selected.
Req 6.9 (Offline-capable Cards)
Offline-capable cards shall support fDDA.
Req 6.10 (Transaction Logging)
Implementation-Optional: Implementation of transaction logging is at implementer

discretion.
Issuer-Optional: If transaction logging is implemented, the issuer shall be able to enable and
disable transaction logging.
Card applications may support transaction logging as defined in Appendix L.
Due to the increase in application processing times when transaction logging is used, it is
strongly recommended that issuers not enable transaction logging.
6.2.2 Card Personalization Requirements
6.2.2.1 Card Personalization Specifications
[EMV CPS] is recommended for all contactless implementations.
[VSDC PERSO] defines the Common Personalization requirements for VCPS.

6 Card Requirements
6.2.2.2 Card Personalization Requirements
This section defines some of the personalization requirements for card applications.
Personalization of the card application shall conform to these requirements, but the card
application need not enforce personalization requirements.
Req 6.11 (qVSDC Support)
Cards shall be personalized to support qVSDC.

The following GPO responses shall be enabled:
• qVSDC Offline GPO Response (if offline supported)
• qVSDC Online/Decline without ODA GPO Response
Enabling of the qVSDC Online with ODA GPO Response is an issuer option.
Note: As defined in [EMV CPS] Section 7.9.1, when DGI '9207' is used to enable qVSDC, a
combination of AIP and CAP bit settings are used to configure whether or not the qVSDC
Online with ODA GPO Response is enabled. When DGI '9115', '9116', and/or '9117' are used to
enable qVSDC, the presence (or lack) of DGI '9117' is used to configure whether or not the
qVSDC Online with ODA GPO Response is enabled.
Req 6.12 (Application Interchange Profile)
The Application Interchange Profile (AIP) returned for the qVSDC path shall:
• Indicate MSD is not supported by card (AIP byte 2 bit 8 is 0b).
• If fDDA supported by card, then indicate ‘DDA is supported’ by card (AIP byte 1 bit 6
is 1b).
• Indicate that the AIP is for a 'Contactless transaction' (AIP byte 2 bit 6 is 1b).
Req 6.14 (Low Value Checks)
The card shall not be personalized to support both the Low Value Check (CAP byte 1 bit 8
is 1b) and the Low Value AND CTTA Check (CAP byte 1 bit 7 is 1b).

6 Card Requirements
6.2.2.3 Card Personalization Options
Req 6.15 (CVV and iCVV)
The CVV present in the magnetic stripe shall not be personalized in the track data on the
chip. It is recommended that the iCVV be used in the track data returned for qVSDC
transactions.
The iCVV was developed for contact chip to prevent the skimming of track data from the chip
and using it to make a magnetic stripe card. Using the iCVV for track data for contactless
transactions serves the same purpose.
6.3 Application Selection
1. The reader builds a candidate list of mutually supported applications.
transaction.
The Application Selection procedure performed by the reader is defined in section 5.5
Application Selection.
6.3.1 SELECT Command
To facilitate Application Selection, support for the SELECT command is required.
Req 6.16 (SELECT Command)
The card shall support the SELECT command, as defined in Appendix G of this specification.
Req 6.17 (Accepting the SELECT Command)
The card shall accept a SELECT command using the AID, whether or not that command was
immediately preceded by a SELECT of the PPSE.

6 Card Requirements
Req 6.18 (Application Blocked)
If the selected application is blocked (application blocked or application permanently

blocked), then the Status Word in response to the SELECT command shall be SW1 SW2 =
'6283'.
6.3.2 Proximity Payment System Environment (PPSE)
To facilitate Application Selection using the Directory Selection Method, support for the PPSE
is required.
Req 6.19 (PPSE)
The card shall support the Proximity Payment System Environment (PPSE). The PPSE is a DDF
with the name '2PAY.SYS.DDF01' that contains a list of the applications supported by the card
over the contactless interface.
The File Control Information (FCI) in the response to the SELECT of the PPSE is defined in
Appendix G.4.
Req 6.20 (PPSE Personalization)
The PPSE shall be personalized on all contactless cards using the file name ‘2PAY.SYS.DDF01’.
The AIDs of the contactless financial applications on the card shall be provided in response to
SELECT of the PPSE within the FCI.
Req 6.21 (PPSE Personalization – Application Priority Indicator)
If more than one contactless application is personalized on the card, then the Application
Priority Indicator (tag ’87) shall be personalized in the PPSE Directory Entry (tag ‘61’) for each
application.
Note: It is recommended that, whenever possible, only one application should be listed in the FCI
of the PPSE in order to meet timing requirements. If more than one application is required, the
number of applications should be kept to a minimum.
6.3.3 Personalization Requirements
In addition to the personalization requirements for the PPSE, this section describes (some) of
the personalization requirements that may impact Application Selection processing.

6 Card Requirements
Req 6.22 (AID Personalization)
The AID shall have a minimum length of 7 bytes if a single contactless application is
supported.
If multiple contactless applications with the same Visa AID are supported, a minimum length
of 8 bytes shall be personalized to allow for an extension to differentiate between them. For
example:
• A0 00 00 00 03 10 10 01
• A0 00 00 00 03 10 10 02
6.4 Initiate Application Processing
The card processes the GET PROCESSING OPTIONS command, determines the processing
path, performs issuer risk management checks, and responds to the reader with application
data to process the transaction.

6 Card Requirements
Figure 6–1: Initiate Application Processing (Card) briefly outlines card application Initiate
Application Processing.
Figure 6–1: Initiate Application Processing (Card)
Reader Card
qVSDC
Begin Initiate sup ported b y N
GET PR OCES SING OPTION S command
Application Processing reader?
qVSDC Card Action

Analysis
GPO response
Initialize data SW1 SW2 = ‘6985’
Application Blocked
ch eck
PIN Tries Exceeded

Check
Refunds and Cred its

Check
Reader Indicators
Check
Cardhold er
Verification Method
(CVM) Check
Domestic Velocity
Checkin g
Internation al Velocity
Checkin g
Con tactless
Transaction Coun ter
Velocity Checking GET PR OCES SING OPTION S
response
Reader Functionality
Check
Transaction
Decline processing
Disposition – Y
and GPO response
Offline Decline?
Transaction
GPO response
Disposition – Y
SW1 SW2 = ‘6984’
Switch In terface?
Transaction
Disposition – Online processing an d
Y
Online Approval GPO response
Req uest?
Offline proces sing and

N
GPO response
End Initiate Application

Processing

6 Card Requirements
6.4.1 GET PROCESSING OPTIONS (GPO) Command
Req 6.23 (GPO Command)
The card shall support the GET PROCESSING OPTIONS (GPO) command, as defined in
Appendix G of this specification.
6.4.2 Processing Options Data Object List (PDOL) Requirements
qVSDC does not use the CDOLs, DDOL, or default DDOL from [EMV]. Instead, the card requests
all reader-terminal data necessary for card processing in the PDOL.
The card requests the Terminal Transaction Qualifiers so that it can determine terminal
capabilities and requirements for the transaction. Additional data elements may be requested
in support of cryptogram generation, fDDA signature generation, velocity checks, and
transaction logging.
The PDOL for the contactless interface contains tags necessary to process the qVSDC
transaction, and may include tags other than those described in this specification as the
minimum required. Issuers should balance the benefits of requesting additional data in the
PDOL against the impact the additional data transfer and processing will have on transaction
performance.
The minimum content of the PDOL required for qVSDC is dependent on the Cryptogram
Version Number supported (17 or 10/18/'22' or proprietary cryptogram) and whether the card
supports offline qVSDC transactions.
The minimum content for the PDOL described in this section is shown as a function of the
Cryptogram Version Number and whether or not the qVSDC path is offline capable. However,
additional data may be required in the PDOL for other card processing. For example, the
Terminal Country Code tag and length may be necessary in the PDOL to support velocity
checks using the terminal country code.
Req 6.24 (PDOL Parsing)
The card application shall be capable of parsing the GPO command message data field to
retrieve the reader data elements requested by the card in the PDOL. The reader data
elements requested by the card in the PDOL are used in subsequent transaction processing.
Req 6.25 (PDOL Tags and Lengths)
In addition to the tags and lengths defined as the minimum required, the card application
shall allow for the personalization of additional tags (and corresponding lengths) in the
PDOL.
6 Card Requirements
For example, the additional tags may be used in support of card velocity checks and
transaction logging.
Additional reader-terminal data elements requested by the card application in the PDOL and
not used during card processing are ignored by the card.
Note: For dual-interface cards, a different PDOL may be personalized for the contact interface,
as defined in Appendix I.2.
6.4.2.2 Minimum PDOL Content
The minimum PDOL content, as a function of the Cryptogram Version Number and offline
capability of the card application, is shown in the following table.
A "" mark indicates that the tag and length of the data element is required in the PDOL.
Table 6–1: Minimum PDOL Content
Tag Length Data Element Name CVN17 Online CVN17 Offline CVN10 and
Only Enabled CVN18 and
CVN'22'
'9F66' 4 bytes Terminal Transaction

  
Qualifiers (TTQ)
'9F02' 6 bytes Amount, Authorized   
'9F03' 6 bytes Amount, Other 
'9F1A' 2 bytes Terminal Country Code 
'95' 5 bytes Terminal Verification


Results (TVR)
'5F2A' 2 bytes Transaction Currency

 
Code
'9A' 3 bytes Transaction Date 
'9C' 1 bytes Transaction Type 
'9F37' 4 bytes Unpredictable Number   
Note: Req 6.37 (Refunds and Credits Check) requires the Transaction Type.
Additional tags may be personalized in the PDOL, but issuers should be aware that VCPS
readers may not contain all [EMV] terminal data elements. The reader processes unknown tags
according to [EMV] Data Object List processing rules.

6 Card Requirements
6.4.3 Contactless Transaction Hierarchy
In order to determine whether it should proceed with the transaction, the card determines
whether the reader supports qVSDC.
Req 6.26 (qVSDC Transaction Processing)
If qVSDC is supported by the reader (TTQ byte 1 bit 6 is 1b), then the card shall proceed with
qVSDC transaction processing.
Else (No Matching Contactless Transaction Path), the card shall respond to the GPO
command with error SW1 SW2 = '6985' (indicating that the reader should attempt to select
another application).
6.4.4 Card Action Analysis – qVSDC Path Processing
The card performs qVSDC Card Action Analysis to determine its transaction disposition and
responds to the GPO command accordingly. Checks and processing are performed in the order
shown.
Implementations are not required to strictly follow the processing described in this section, so
long as they behave in a way that is indistinguishable (seen as a black box responding to the
command) from the behavior described.
The following card internal indicators are set during qVSDC Card Action Analysis based on
processing and issuer risk management parameters. After completing card risk management
processing checks, the internal indicators are evaluated to determine the card’s transaction
disposition. The card internal indicators are initialized at the start of qVSDC Card Risk
Management Processing.
Transaction Disposition Indicators:

• Decline Required by Card Indicator
• Switch Interface Required by Card Indicator
• Online Required by Card Indicator
• Online Preferred by Card Indicator
Other Indicators:
• Matching Currency Indicator
• International Transaction Indicator
• Contact Chip Supported Indicator
• Issuer Update Processing Supported Indicator
• Last Contactless Application Cryptogram Valid Indicator

6 Card Requirements
6.4.4.1 qVSDC Card Risk Management Processing
The card performs qVSDC risk management checks to determine its transaction disposition.
Initialization of Data
Prior to performing qVSDC risk management checks, the card initializes the value of its internal
data elements.
Note: Explicit initialization of some card internal data elements listed in this section may not be
necessary, if the transient nature of those internal data elements results in their already being
initialized to zero.
Req 6.27 (Initialization of Simple Internal Indicators)
The card shall:

• Reset the Decline Required by Card Indicator to 0.
• Reset the Switch Interface Required by Card Indicator to 0.
• Reset the Online Required by Card Indicator to 0.
• Reset the Online Preferred by Card Indicator to 0.
• Reset the Last Contactless Application Cryptogram Valid Indicator to 0.
Req 6.28 (Initialization of Matching Currency Indicator)
The card compares the Transaction Currency Code with 1) the Application Currency Code,
and with 2) the Conversion Currency Codes in the Currency Conversion Parameters. The
transaction is a matching currency transaction if the Transaction Currency Code matches the
Application Currency Code, or matches any of the Conversion Currency Codes in the
Currency Conversion Parameters.
If the Transaction Currency Code matches the Application Currency Code, then the card shall
set the Matching Currency Indicator to 1 and shall set the Amount, Approximated to the
value of the Amount, Authorized.
Else (the Transaction Currency Code does not match the Application Currency Code), if the
Transaction Currency Code matches any of the Conversion Currency Codes in the Currency
Conversion Parameters, then the card shall:
• Set the Matching Currency Indicator to 1.
• The card shall calculate the (approximate) value of the transaction in the application
currency using the Currency Conversion Factor associated with the matching Conversion
Currency Code, and shall set the Amount, Approximated to that calculated value.
Note: For an example of the conversion calculation, please see [VIS] section 11.4.3.9.
6 Card Requirements
Else (neither of the above is true), the card shall reset the Matching Currency Indicator to 0.
Note: If the Transaction Currency Code and/or Application Currency Code are not present, then
the condition evaluates to FALSE. Recall that if a card condition evaluates a data element that is
not present, then the condition evaluates to FALSE. See section 3.1.6 Presence of Data Elements.
This particular check is only explicitly noted to remind the reader of this convention, and it is
not noted again for subsequent card application conditions and actions.
Req 6.29 (Initialization of International Transaction Indicator)
Transactions where the Transaction Currency Code does not match the Application Currency
Code or any of the supported Conversion Currency Codes are international transactions.
Additionally, the issuer may configure the application such that transactions where the
Terminal Country Code does not match the Issuer Country Code are also international
transactions.
• Matching Currency Indicator is 0
• ‘Include country code in determining international transactions’ supported by card (CAP
byte 2 bit 8 is 1b) and the Terminal Country Code does not match the Issuer Country Code
Then the card shall set the International Transaction Indicator to 1.
Else, the card shall reset the International Transaction Indicator to 0.
Req 6.30 (Initialization of Contact Chip Supported Indicator)
If both of the following are true:

• ‘Card Prefers Contact Chip’ supported by card (CAP byte 1 bit 2 is 1b)
• and EMV contact chip supported by reader (TTQ byte 1 bit 5 is 1b)
Then the card shall set the Contact Chip Supported Indicator to 1.
Else, the card shall reset the Contact Chip Supported Indicator to 0.
Req 6.31 (Initialization of Issuer Update Processing Supported Indicator)
If Issuer Update Processing supported by card (CAP byte 2 bit 5 is 1b) and Issuer Update
Processing supported by reader (TTQ byte 3 bit 8 is 1b), then the card shall set the Issuer
Update Processing Supported Indicator to 1.
Else, the card shall reset the Issuer Update Processing Supported Indicator to 0.

6 Card Requirements
Req 6.32 (Initialization of Card Transaction Qualifiers)
The card shall reset CTQ byte 1 bits 8-7 to 00b (indicating Online PIN Not Required and
Signature Not Required) and CTQ byte 2 bit 8 to 0b (indicating CDCVM Not Performed).
Req 6.33 (Initialization of Issuer Application Data)
The card shall set CVR bytes 2-4 to '80 00 00' (indicating Second GENERATE AC not
requested) and, if present, CVR byte 5 to '00'. CVR byte 1 is Unchanging and does not change
from transaction to transaction.
• If CDCVM supported by card (CAP byte 3 bit 4 is 1b), then the card shall set the CVR
'CDCVM successfully performed' bit(s) to 1b.
Note: In IAD Format 2 there are two 'CDCVM successfully performed' bits in the CVR, and
the card must set both bits to 1b.
• If the card supports IAD Format 2 and the ADA ‘Secure Messaging uses EMV Session key-
based derivation’ bit is 1b, then the card shall set the CVR ‘Secure Messaging uses EMV
Session key-based derivation’ bit to 1b.
If the card supports Issuer Update Processing (CAP byte 2 bit 5 is 1b), then the card shall:
• Set CVR byte 3 bit 4 to the value of the Issuer Authentication Failure Indicator.
• Set CVR byte 4 bit 4 to the value of the Issuer Script Failure Indicator.
• Set CVR byte 4 bits 8-5 to the value of the Issuer Script Command Counter using identical
bit settings.
• If the reader supports Issuer Update Processing (TTQ byte 3 bit 8 is 1b), then the payment
application shall indicate that both the payment application and reader support Issuer
Update Processing (set Issuer Discretionary Data Identifier bit 8 to 1b).
Note: Setting of the Issuer Discretionary Data Identifier (IDD ID) is only performed if the IDD
ID is personalized.
Req 6.34 (Initialization of Cryptogram Information Data)
The card shall reset the Cryptogram Information Data (CID) to '00'.
Application Blocked
Req 6.35 (Application Blocked Check)
If the application is blocked, then the card shall set the Decline Required by Card Indicator
to 1.

6 Card Requirements
Note: Processing of the GPO command is not performed if the application is permanently
blocked. See Req 6.7 (Application Permanently Blocked).
PIN Tries Exceeded
Req 6.36 (PIN Tries Exceeded Check)

• PIN Tries Exceeded Check supported by card (CAP byte 1 bit 4 is 1b)
• and PIN Try Counter (tag '9F17') is zero
Then the card shall:
• Set CVR byte 3 bit 7 to 1b (PIN Try Limit Exceeded).
• If the Contact Chip Supported Indicator is 1, then the card shall set the Switch Interface
Required by Card Indicator to 1.
Else, the card shall set the Online Required by Card Indicator to 1.
Refunds and Credits
Req 6.37 (Refunds and Credits Check)
If the Transaction Type is '2x' (Refunds/Credits), then the card shall set the Decline Required
by Card Indicator to 1.
Reader Indicators
Req 6.38 (Reader Requires an Online Cryptogram Check)
If Online Cryptogram required by reader (TTQ byte 2 bit 8 is 1b), then the card shall set the
Online Required by Card Indicator to 1.
Cardholder Verification Method (CVM)
The card determines if a CVM is required for the transaction. A CVM is required for the
transaction if either the card or reader require a CVM.
Req 6.39 (CVM Required Check)

• CVM Required by reader (TTQ byte 2 bit 7 is 1b)

6 Card Requirements
• Domestic transaction (International Transaction Indicator is 0) and Amount, Approximated
is greater than the Card CVM Limit
Then a CVM is required for the transaction, and the card shall determine the common CVM
to be performed.
Req 6.40 (Determine Common CVM)
If a CVM is required for the transaction, then the card shall attempt to select a common CVM
supported by both itself and the reader, as defined in this requirement. If there is more than
one CVM supported by both the card and the reader, the selected CVM is chosen based on
the following defined CVM hierarchy: 1) Online PIN, 2) (Contact Chip) Offline PIN, 3) CDCVM,
or 4) Signature.
Note: ‘(Contact Chip) Offline PIN’ is not a CVM used for contactless transactions, but is instead
used to permit issuer preference to switch to a contact chip transaction when a CVM is required.
Note: Cards personalized to support CDCVM will always consider CDCVM to have been
successfully performed. For example, this behavior may be desired for cards that only activate
the contactless interface after on-card verification has been successfully performed, or where
cardholder verification is performed "out-of-band" by the issuer.
• Online PIN supported by reader (TTQ byte 1 bit 3 is 1b)
• and either of the following is true:
̵ Domestic transaction (International Transaction Indicator is 0) and Online PIN
supported by card for domestic transactions (CAP byte 3 bit 8 is 1b)
̵ International transaction (International Transaction Indicator is 1) and Online PIN
supported by card for international transactions (CAP byte 3 bit 7 is 1b)
• Indicate Online PIN Required (set CTQ byte 1 bit 8 to 1b).
• Set the Online Required by Card Indicator to 1.
Else, if both of the following are true:
• (Contact Chip) Offline PIN supported by reader (TTQ byte 2 bit 6 is 1b)
• and (Contact Chip) Offline PIN supported by card (CAP byte 3 bit 6 is 1b)
Then the card shall set the Switch Interface Required by Card Indicator to 1.
• CDCVM supported by reader (TTQ byte 3 bit 7 is 1b)
• and CDCVM supported by card (CAP byte 3 bit 4 is 1b)

6 Card Requirements
• Indicate CDCVM Performed (set CTQ byte 2 bit 8 to 1b).
• Set the Online Required by Card Indicator to 1.
• Signature supported by reader (TTQ byte 1 bit 2 is 1b)
• and Signature supported by card (CAP byte 3 bit 5 is 1b)
Then the card shall indicate Signature Required (set CTQ byte 1 bit 7 to 1b)
Else (no common CVM between card and reader), the card shall set the Switch Interface
Domestic Velocity Checking

This set of checks shall be performed for domestic transactions (International Transaction
Indicator is 0) and Online Required by Card Indicator is 0.
Req 6.41 (Low Value Check)
This check shall be performed if the Low Value Check is supported by the card (CAP byte 1
bit 8 is 1b).
If any of the following is true:
• Amount, Approximated is greater than VLP Available Funds
• or Amount, Approximated is greater than VLP Single Transaction Limit
• Set CVR byte 3 bit 6 to 1b (Exceeded velocity checking counters).
Else, if Amount, Approximated is greater than or equal to VLP Available Funds minus VLP
Reset Threshold, then the card shall:
Else, if the Issuer Update Processing Supported Indicator is 1, then the card shall set the
Else, if the CAP 'Card Prefers Online' bit is 1b, then the card shall set the Online Preferred

6 Card Requirements
Req 6.42 (Low Value AND CTTA Check)
This check shall be performed if the Low Value AND CTTA Check is supported by the card
(CAP byte 1 bit 7 is 1b).
If any of the following is true:
• Amount, Approximated is greater than CTTA Funds
• or Amount, Approximated is greater than VLP Available Funds
• or Amount, Approximated is greater than VLP Single Transaction Limit
Else, if any of the following is true:
• Amount, Approximated is greater than the Cumulative Total Transaction Amount Limit
(CTTAL) minus the Cumulative Total Transaction Amount (CTTA)
• or Amount, Approximated is greater than or equal to VLP Available Funds minus VLP
Reset Threshold
Req 6.43 (No Low Value Check Supported)
If neither of the low value checks is supported (CAP byte 1 bits 8-7 are 00b), then the card
shall set the Online Required by Card Indicator to 1.
International Velocity Checking
This set of checks shall be performed for international transactions (International Transaction
Indicator is 1).

6 Card Requirements
Req 6.44 (International Transaction Not Allowed Check)
If international transactions are not allowed (CAP byte 2 bit 7 is 1b), then the card shall:
Else, the card shall set the Decline Required by Card Indicator to 1.
Req 6.45 (International Transaction Not Allowed Offline Check)
If offline international transactions are not allowed (CAP byte 1 bit 3 is 0b), then the card
shall:
• If Online supported by reader (TTQ byte 1 bit 4 is 0b), then the card shall set the Online
Else, if the Contact Chip Supported Indicator is 1, then the card shall set the Switch
Interface Required by Card Indicator to 1.
Else, the card shall set the Decline Required by Card Indicator to 1.
Req 6.46 (Consecutive Transaction Limit International Check)
This check shall be performed for international transactions (International Transaction

Indicator is 1) and Online Required by Card Indicator is 0.
If the Consecutive Transaction Counter International (CTCI) is greater than or equal to the
Consecutive Transaction International Upper Limit (CTIUL), then the card shall:
Else, if the Consecutive Transaction Counter International (CTCI) is greater than or equal to
the Consecutive Transaction Counter International Limit (CTCIL), then the card shall:

6 Card Requirements
Contactless Transaction Counter Velocity Checking
Req 6.47 (Contactless Transaction Count)
If the Contactless Transaction Counter (CLTC) is greater than or equal to the Contactless
Transaction Counter Upper Limit (CLTCUL), then the card shall:
Else, if the Contactless Transaction Counter (CLTC) is greater than or equal to the Contactless
Transaction Counter Lower Limit (CLTCLL), then the card shall:
6.4.4.2 Reader Functionality Check
This section contains checks to determine whether the possible transaction outcome indicated
by the transaction disposition indicators should be revised, based on supported reader
functionality.
Offline-Only Reader
This check shall be performed if the Reader is Offline-Only (TTQ byte 1 bit 4 is 1b).
Req 6.48 (Decline if Online Required Check)
If the Online Required by Card Indicator is 1, then the card shall set the Decline Required by
Card Indicator to 1.
Req 6.48A (Reset Online Preferred by Card Indicator)
Reset the Online Preferred by Card Indicator to 0.

6 Card Requirements
6.4.4.3 Transaction Disposition
At the completion of qVSDC risk management processing checks, the card shall examine its
internal indicators to determine the transaction disposition. The hierarchy of transaction
dispositions is shown in sequence below, and the card transaction disposition shall be the first
transaction disposition where the corresponding indicator is set.
As specified in Req 6.5, if Card Action Analysis results in a transaction disposition with a
disabled GPO response, then the card does not perform the processing for the transaction
disposition defined below and instead responds with error SW1 SW2 = '6985'.
Transaction Disposition – (Offline) Decline
The card shall perform the following processing if the Decline Required by Card Indicator is 1.
Req 6.49 (Decline)
The card shall:

• Indicate Application Authentication Cryptogram (AAC) returned (set CVR byte 2 bits 6-5
to 00b and set CID bits 8-7 to 00b).
• Increment the Application Transaction Counter (ATC) by one. The ATC shall be
incremented prior to the performance of any cryptographic operations.
If incrementing the ATC results in the ATC reaching its maximum value, then the
application shall be permanently blocked, Req 6.7 (Application Permanently Blocked), and
shall respond to the GPO command with error SW1 SW2 = '6985'.
• Construct the Issuer Application Data. If an Issuer Discretionary Data Option Identifier
(IDDO ID) is supported (see Appendix E), the IDD shall be constructed and the MAC
generated (if applicable).
• Generate the AAC type Application Cryptogram and set the Last Contactless Application
Cryptogram to the value of the generated Application Cryptogram.
• Set the Last Contactless Application Cryptogram Valid Indicator to 1.
• Construct and send the GPO response in [EMV] Format 2 with the data shown in Table 6–2
using Condition column "Online and Decline (without ODA)".
Transaction Disposition – Switch Interface
The card shall perform the following processing if the Switch Interface Required by Card
Indicator is 1.

6 Card Requirements
Req 6.50 (Switch Interface)
The card shall respond to the GPO command with error SW1 SW2 = '6984' (indicating that
the reader should switch to another interface).
Transaction Disposition – Online (Approval Request)
The card shall perform the following processing if the Online Required by Card Indicator is 1 or
the Online Preferred by Card Indicator is 1.
Note: Req 6.51 has been deleted. Consequently, the card commits the data elements updated in
this section to persistent memory at the conclusion of GPO command processing.
Req 6.52 (Contactless Transaction Counter Updates)
If ‘Count qVSDC online transactions’ is supported by card (CAP byte 1 bit 6 is 1b), then the
card shall increment the Contactless Transaction Counter (CLTC) by one.
Req 6.53 (Online)
The card shall:

• Indicate Authorization Request Cryptogram (ARQC) returned (set CVR byte 2 bits 6-5
to 10b and set CID bits 8-7 to 10b).
• If the card is capable of performing fDDA and all of the following are true:
̵ the card supports fDDA for Online Authorizations (AIP byte 1 bit 6 is 1b for the qVSDC
"Online (with ODA)" GPO response)
̵ and ODA for Online Authorizations supported by card (CAP byte 2 bit 6 is 0b)
̵ and ODA for Online Authorizations supported by reader (TTQ byte 1 bit 1 is 1b)

6 Card Requirements
Then the card shall construct the Card Authentication Related Data and generate the
Signed Dynamic Application Data (tag '9F4B'). The Signed Dynamic Application Data shall
be generated as defined in Appendix A.
Note: ODA for Online Authorizations is neither used at nor supported by readers compliant
to this specification. However, card functionality is included in this specification to allow for
its potential use in acceptance environments where ODA for Online Authorizations is
desired.
• Generate the ARQC type Application Cryptogram and set the Last Contactless Application
• If ODA for Online Authorizations supported by reader (TTQ byte 1 bit 1 is 1b) and the
qVSDC Online with ODA GPO Response is supported (per Req 6.11), then construct and
send the GPO response in [EMV] Format 2 with the data shown in Table 6–2 using
Condition column "Online (with ODA)".
Else, construct and send the GPO response in [EMV] Format 2 with the data shown in
Table 6–2 using Condition column "Online and Decline (without ODA)".
Transaction Disposition – Offline (Approval Request)
If none of the transaction disposition indicators above indicate that another transaction
disposition is required, the card shall request offline approval processing.
Although Req 6.54 (Tearing Protection - Offline Approval Request) involves processing for the
READ RECORD command, it is presented here as it has significant impact to processing of the
GPO command for offline requested transactions. Card and reader communications for offline
requested transactions are not complete until the last record has been read, thus the data
elements updated in this section shall not be committed until the last record has been read. As
a consequence, there exists the possibility for transaction tearing even after the GPO response
has been sent. The Tearing Protection requirement in this section attempts to minimize the
impact of tearing by not committing updated card data elements until the final READ RECORD
response is sent.
Req 6.54 (Tearing Protection - Offline Approval Request)
The card shall not commit the data elements updated in this section (Transaction Disposition
– Offline Approval Request) to persistent memory until immediately prior to sending the
READ RECORD response for the last record, with the exception of the Application Transaction
Counter (as increment of the ATC is effective immediately). The last record is indicated by the
Application File Locator.

6 Card Requirements
If updated data elements have not been committed to persistent memory, then the transient
value of these data elements shall be discarded if the card receives another GPO command or
the contactless communication session ends (e.g. the card loses power).
Note: When a data element value is returned in the Issuer Application Data (due to an Issuer
Discretionary Data Option), the (updated) transient value is used.
Req 6.55 (Low Value Counter Updates)

• International Transaction Indicator is 0
• and Low Value Check supported by card (CAP byte 1 bit 8 is 1b)
Then the card shall decrement the VLP Available Funds by the Amount, Approximated.
Req 6.56 (Low Value AND CTTA Counter Updates)

• International Transaction Indicator is 0
• and Low Value AND CTTA Check supported by card (CAP byte 1 bit 7 is 1b)
• Increment the Cumulative Total Transaction Amount (CTTA) by the Amount,
Approximated.
• Decrement the VLP Available Funds by the Amount, Approximated.
Req 6.57 (Consecutive Transaction Counter International Counter Update)
If the International Transaction Indicator is 1, then the card shall increment the Consecutive
Transaction Counter International (CTCI) by one.
Req 6.58 (Contactless Transaction Counter Update)
If ‘Count qVSDC offline transactions’ is supported by card (CAP byte 2 bit 4 is 0b), then the
card shall increment the Contactless Transaction Counter (CLTC) by one.
Req 6.59 (Offline)
The card shall:

• Indicate Transaction Certificate (TC) returned (set CVR byte 2 bits 6-5 to 01b and set CID
bits 8-7 to 01b).

6 Card Requirements
• Construct the Card Authentication Related Data and generate the Signed Dynamic
Application Data (tag '9F4B'). The Signed Dynamic Application Data shall be generated as
defined in Appendix A.
• Generate the TC type Application Cryptogram and set the Last Contactless Application
• Construct and send the GPO response in [EMV] Format 2 with the data shown in Table 6–2
using Condition column "Offline (with ODA)".

6 Card Requirements
6.4.4.4 qVSDC Path Processing GPO Response
This section describes the qVSDC GPO Response data.
A number of the data elements shown in the qVSDC GPO response may be returned in either the GPO response or in a record, at
issuer discretion. For the purposes of reduced transaction times, it is recommended that these data elements be returned in the
GPO response unless they are part of the static data to be signed. However, if there is insufficient space in the GPO response to
return all the data elements, then it will be necessary to return some of the data elements in records.
Additional application data may be returned in records, as personalized by the issuer.
Note: Although VCPS compliant readers are required to be able to handle receiving additional data elements in the GPO response
even if they are not explicitly listed in the table below, it is recommended that issuers do not personalize any additional data elements
in the GPO response beyond what is shown in the table below, in order to avoid potential interoperability issues with older readers.
Note: Readers compliant to this specification do not perform Offline Data Authentication (ODA) for qVSDC transaction disposition
Online and Decline, hence record data is not needed to complete the transaction.
Table 6–2: qVSDC GPO Response Data
Tag Data Element Length Condition
Online Online and Decline Offline

(with ODA) (without ODA) (with ODA)
'77' Response Message Template var.

Format 2
'82' Application Interchange 2 bytes Always Always Always

Profile (AIP)
'94' Application File Locator var. Always If returning record data Always
(AFL)
'57' Track 2 Equivalent Data var. up to Shall be returned in either the Always Shall be returned in either the
19 bytes GPO response or in a record. GPO response or in a record.

Notice: This information is proprietary and CONFIDENTIAL to Visa. It is distributed to Visa participants for use exclusively in managing their Visa programs. It must not be duplicated, published, distributed or
disclosed, in whole or in part, to merchants, cardholders or any other person without prior written permission from Visa. © 2007-2016 Visa. All Rights Reserved.
6 Card Requirements
Tag Data Element Length Condition
Online Online and Decline Offline

(with ODA) (without ODA) (with ODA)
'5F20' Cardholder Name var. 2- 26 May be returned in either the May be returned in either the May be returned in either the
bytes GPO response or in a record. GPO response or in a record. GPO response or in a record.
'5F34' Application PAN 1 byte May be returned in either the May be returned in either the May be returned in either the
Sequence Number (PSN) GPO response or in a record. GPO response or in a record. GPO response or in a record.
'9F10' Issuer Application Data var. up to Always Always Always

(IAD) 32 bytes
'9F26' Application Cryptogram 8 bytes Always Always Always
'9F27' Cryptogram Information 1 byte Always Always Always

Data (CID)
'9F36' Application Transaction 2 bytes Always Always Always

Counter (ATC)
'9F4B' Signed Dynamic Nic bytes If the SDAD is generated by Never If the SDAD is generated by
Application Data (SDAD) the application, then it shall be the application, then it shall be
returned in either the GPO returned in either the GPO
response or in a record. response or in a record.
'9F5D' Available Offline 6 bytes The AOSA shall be returned in the GPO response if all of the following are true:
Spending Amount (AOSA) • Return AOSA supported by card (CAP byte 1 bit 1 is 1b)
• and the Transaction Currency Code matches the Application Currency Code
'9F6C' Card Transaction 2 bytes If using CTQ functionality If using CTQ functionality If using CTQ functionality
Qualifiers (CTQ)
'9F6E' Form Factor Indicator 4 bytes Shall be returned in either the Shall be returned in either the Shall be returned in either the
(FFI) GPO response or in a record. GPO response or in a record. GPO response or in a record.
'9F7C' Customer Exclusive Data var. up to May be returned in either the May be returned in either the May be returned in either the
(CED) 32 bytes GPO response or in a record. GPO response or in a record. GPO response or in a record.

6 Card Requirements

6 Card Requirements
6.5 Read Application Data
During Read Application Data, the reader uses the READ RECORD command to retrieve the
card data necessary to process the transaction. The card receives the READ RECORD command
from the reader and returns the requested record.
6.5.1 READ RECORD Command
To facilitate Read Application Data, support for the READ RECORD command is required.
Req 6.63 (READ RECORD Command)
The card shall support the READ RECORD command, as defined in Appendix G of this
specification.
The card shall support the personalization and return of the Card Authentication Related
Data (tag '9F69') and Signed Dynamic Application Data (tag '9F4B') in records, as
personalized by the issuer. Unlike the other data elements normally returned in records, the
value of these data elements are conditionally generated by the card application for each
transaction.
Req 6.64 (Last Record)
The card shall be capable of knowing when the last record is read. The last record is indicated
by the Application File Locator (AFL).
For transactions where fDDA is performed, the Card Authentication Related Data (tag '9F69')
shall be generated and present in the last record, prior to responding to the READ RECORD
command for the last record.
The Card Authentication Related Data contains the (card) Unpredictable Number, generated
by the card prior to generation of the Signed Dynamic Application Data.
Note: The card will not know whether the reader successfully received the final READ RECORD
response. This means that tearing is still possible and if it occurs, it will negatively affect the
available offline balance. The time window for such an occurrence has been minimized. The
reader may still decline the transaction if the expiration date or offline data authentication
checks fail, but this should rarely occur for genuine cards.
Req 6.65 (Last Record - Commit Data Elements and Indicators)
The card application shall commit the data elements updated in section 6.4.4.3 to persistent
memory immediately prior to sending the READ RECORD response for the last record.

6 Card Requirements
6.6 Issuer Update Processing
Implementation-Optional: Issuer Update Processing is an implementation option.
Issuer-Optional: If implemented, support for Issuer Update Processing is issuer optional. Card
support for Issuer Update Processing is indicated by setting CAP byte 2 bit 5 to 1b. ‘Card
supports Issuer Update Processing at the POS’ is indicated in CTQ byte 2 bit 7.
Note: As there is no GPO command issued during Issuer Update Processing, the Authorization
Response Cryptogram (ARPC) and issuer script MAC(s) are generated by the issuer using the ATC
returned during Initiate Application Processing (and sent in the online message).
Note: Card applications that support Issuer Update Processing can process issuer update
commands regardless of the setting of CAP byte 2 bit 5. This bit is used simply to indicate to the
card application that Issuer Update Processing is supported to allow for the card application to
set the appropriate indicators and CVR bits, and does not control whether the card application
can process issuer update commands.
6.6.1 Issuer Update Commands
If the card application supports Issuer Update Processing, support for the Issuer Update
commands is required:
Req 6.66 (Issuer Update Commands)
The card shall support the Issuer Update commands, as defined in Appendix G.5 of this
specification.
6.6.2 Issuer Authentication Processing
Upon receipt of the EXTERNAL AUTHENTICATE command, the card shall process the command
according to the procedure defined in this section.
Figure 6–2: EXTERNAL AUTHENTICATE Processing (Card) briefly outlines card application
Issuer Authentication processing when the EXTERNAL AUTHENTICATE command is received.

6 Card Requirements
Figure 6–2: EXTERNAL AUTHENTICATE Processing (Card)
Reader Card
EXTE RNAL AUTHENT IC ATE Last Contactless
Begin EXTER N AL EXTER N AL AU THEN TICA TE command previously Application
N N
AU THEN TICA TE command received for ATC Cryptogram Valid
value? Indicator = 0?
EXT AUTH response

Y
SW1 SW2 = ‘6985’
CVN10 Cryptogram
or CVN17 Version
Number?
CVN18 or CVN22
Generate a cryptogram Generate a cryptogram

from the ARC and the Last from the CSU and the Last
Contactless Application Contactless Application
Cryptogram Cryptogram
Generated Generated
EXT AUTH response
cryptogram = N N cryptogram =
SW1 SW2 = ‘6300’
ARPC? ARPC?
Y Y
Set/reset counters and Set/reset counters and

indicators indicators
Perform Card U pdates

ARC = 00, 10, or
Processing U sing Verified
11?
CSU
Set/reset velocity N Perform Counter Updates

counters Processing U sing Verified
CSU
EXT AUTH response

SW1 SW2 = ‘9000’
“CSU Created by P roxy for
Use ADA counter the Issuer” and “Us e Default
Y
controls Update Counters in ADA if
CSU generated by proxy”?
Use CSU counter

controls
“Set Offline
Set velocity counters to Counters to
Y
their upper limits Upper Offline
Limits”?
EXTER N AL AU THEN TICA TE
response N
“Reset Offline
Reset velocity counters
Y Counters to
to zero
Zero”?
End EXTER N AL EXT AUTH response

N
AU THEN TICA TE SW1 SW2 = ‘9000’

6 Card Requirements
6.6.2.1 EXTERNAL AUTHENTICATE Conditions
To determine whether processing of the EXTERNAL AUTHENTICATE command should be

performed, the card determines if an EXTERNAL AUTHENTICATE command was previously
received for the transaction, and examines the Last Contactless Application Cryptogram Valid
Indicator.
Req 6.67 (One EXTERNAL AUTHENTICATE Command Per ATC Value)
The card shall permit at most one EXTERNAL AUTHENTICATE command per ATC value. If an
EXTERNAL AUTHENTICATE command was previously received for the ATC value, then the
card shall:
• Set the Issuer Authentication Failure Indicator to 1.
• Discontinue processing the command and respond with SW1 SW2 = '6985'.
Req 6.68 (Last Contactless Application Cryptogram Valid Indicator)
If the Last Contactless Application Cryptogram Valid Indicator is 0, then the card shall:
6.6.2.2 Cryptogram Version Number 10 and Cryptogram Version Number

17
The card shall perform the procedure specified in this section for Cryptogram Version
Number 10 and Cryptogram Version Number 17.
Req 6.69 (EXTERNAL AUTHENTICATE Processing: CVN 10 and CVN 17)
The card shall process the EXTERNAL AUTHENTICATE command and issue the response
according to [VIS] section 12.4.3, with the following exception(s):
• The Last Contactless Application Cryptogram shall be used instead of the “ARQC returned
in the first GENERATE AC response...”
• The algorithm is applicable to CVN17 (in addition to CVN10).
Req 6.70 (Issuer Authentication Counter and Indicator Resets)
Prior to responding to the EXTERNAL AUTHENTICATE command, the card application shall
determine whether the following counters and indicators are to be updated.

6 Card Requirements
If Issuer Authentication is successfully performed, then the card application shall update the
following counters and indicators:
• Issuer Authentication Failure Indicator to 0.
• If ‘Issuer Script Command Counter is cyclic’ (ADA byte 3 bit 2) is 0b, then the card shall
reset the Issuer Script Command Counter to zero.
• Issuer Script Failure Indicator to 0.
• Last Successful Issuer Update ATC Register to the value of the ATC.
Req 6.71 (Approval Counter and Indicator Resets)
Prior to responding to the EXTERNAL AUTHENTICATE command, the card application shall
determine whether the following counters and indicators are reset.
• Issuer Authentication is successfully performed
• and Authorization Response Code is 00, 10, or 11 (Issuer approval)
Then the card shall update the following indicators and counters:
• Last Online ATC Register to the value of the ATC.
• If ‘Do not reset VLP Available Funds during Issuer Authentication Processing’ (ADA byte 2
bit 1) is 0b, then the card shall set the VLP Available Funds to the VLP Funds Limit.
• If ‘Do not reset CTTA during Issuer Authentication Processing’ (ADA byte 2 bit 2) is 0b,
then the card shall reset the Cumulative Total Transaction Amount (CTTA) to zero.
• Consecutive Transaction Counter (CTC) to zero.
• Consecutive Transaction Counter International (CTCI) to zero.
• Contactless Transaction Counter (CLTC) to zero.
6.6.2.3 Cryptogram Version Number 18 and '22'
The card shall perform the procedure specified in this section for Cryptogram Version
Number 18 and (if implemented) Cryptogram Version Number '22'.
Req 6.72 (Generate ARPC)
The card shall:

• Parse out the Authorization Response Cryptogram (ARPC) included in the Issuer
Authentication Data for support of Cryptogram Version Number 18 ('12') and Cryptogram
Version Number '22' ('22').

6 Card Requirements
• Generate an ARPC using the ARPC algorithm defined in [VIS] for Cryptogram Version
Number 18 and Cryptogram Version Number '22', with the following exceptions:
̵ The Last Contactless Application Cryptogram is used instead of the ARQC.
̵ The CSU is received in the EXTERNAL AUTHENTICATE command instead of the second
GENERATE AC command.
̵ The Proprietary Authentication Data (conditionally included as part of the input data) is
received in the EXTERNAL AUTHENTICATE command instead of the second GENERATE
AC command.
Req 6.73 (Issuer Authentication Results)
Compare the generated ARPC to the ARPC received in the Issuer Authentication Data of the
EXTERNAL AUTHENTICATE command.
If the generated ARPC and the ARPC received in the EXTERNAL AUTHENTICATE command data
are the same, then Issuer Authentication is considered successful and the card shall:
• If ‘Issuer Script Command Counter is cyclic’ (ADA byte 3 bit 2) is 0b, then the card shall
reset the Issuer Script Command Counter to zero.
• Set the Issuer Script Failure Indicator to 0.
• If CSU 'Issuer approves online transaction' bit is 1b, then the card shall set the Last Online
ATC Register to the value of the ATC.
• Set the Last Successful Issuer Update ATC Register to the value of the ATC
• Continue processing the command.
Else (Issuer Authentication unsuccessful), the card shall:

• Indicate that Issuer Authentication failed by responding to the EXTERNAL AUTHENTICATE
command with SW1 SW2 = '6300'.
Req 6.74 (CSU Processing)
After successful Issuer Authentication for Cryptogram Version Number 18 or Cryptogram

Version Number '22', the card has verified that the CSU received in Issuer Authentication
Data is valid.
The indicators in the CSU are used to update the card as follows:
• If Card Block indicated (CSU byte 2 bit 7 is 1b), then the card shall be blocked as described
in Appendix G.5.3.

6 Card Requirements
• If Application Block indicated (CSU byte 2 bit 6 is 1b), then the application shall be blocked
as described in Appendix G.5.1.
• If 'Update PIN Try Counter' indicated (CSU byte 2 bit 5 is 1b), then:
̵ If the value in the ‘PIN Try Counter’ bits of the verified CSU is greater than the PIN Try
Limit, then the application shall set the PIN Try Counter to the value of the PIN Try
Limit.
̵ If the value in the ‘PIN Try Counter’ bits of the verified CSU is less than or equal to the
PIN Try Limit:
• If the implementation is capable of setting the PIN Try Counter to the value in the
‘PIN Try Counter’ bits of the verified CSU, then the application shall set the PIN Try
Counter to the value in the ‘PIN Try Counter’ bits of the verified CSU.
• Otherwise, the application shall set the PIN Try Counter to the value of the PIN Try
Limit.
Note: If an implementation is capable of setting the PIN Try Counter to any value between
zero and the PIN Try Limit (0 < value < PIN Try Limit), it must be capable of setting the PIN
Try Counter to every possible value between zero and the PIN Try Limit. Issuers should only
set the ‘PIN Try Counter’ bits of the CSU to a value that their cards are capable of
supporting.
• If ‘Set Go Online On Next Transaction’ indicated (CSU byte 2 bit 4 is 1b), then the card
shall set the Go Online On Next Transaction Indicator to 1.
Else (CSU byte 2 bit 4 is 0b), the card shall set the Go Online On Next Transaction Indicator
to 0.
Req 6.75 (CSU and ADA Counter Controls)
The card examines the ‘CSU Created by Proxy for the Issuer’ bit in the CSU and the ‘Use
Default Update Counters in ADA if CSU is generated by a proxy’ in the Application Default
Action (ADA) to determine which of the data elements are used to control the update of
counters.
If ‘CSU Created by Proxy for the Issuer’ (CSU byte 2 bit 3 is 1b) and ‘Use Default Update
Counters in ADA if CSU is generated by a proxy’ (ADA byte 4 bit 8 is 1b), then the card shall
update the counters according to the ADA Default Update Counters (the “counter control” is
ADA byte 4 bits 7-6).
Else, the card shall update the counters according to the CSU Update Counters (the “counter
control” is CSU byte 2 bits 2-1).

6 Card Requirements
Req 6.76 (Update Counters)
The card examines the appropriate counter control, as specified in Req 6.75, to determine
whether counters and indicators should be updated, and how they’re to be updated.
If ‘Set velocity-checking counters to Upper Limits’ indicated (counter control has the value
01b), then the card shall update the counters to the value of the associated upper limit as
follows:
bit 1) is 0b, then the card shall reset the VLP Available Funds to zero.
then the card shall set the Cumulative Total Transaction Amount (CTTA) to the Cumulative
Total Transaction Amount Upper Limit (CTTAUL).
• Consecutive Transaction Counter (CTC) to Consecutive Transaction Counter Upper Limit
(CTCUL).
• Consecutive Transaction Counter International (CTCI) to Consecutive Transaction
International Upper Limit (CTIUL).
• Contactless Transaction Counter (CLTC) to Contactless Transaction Counter Upper Limit
(CLTCUL).
If ‘Reset velocity-checking counters to zero’ indicated (counter control has the value 10b),
then the card shall reset the counters as follows:
bit 1) is 0b, then the card shall set the VLP Available Funds to the VLP Funds Limit.
then the card shall reset Cumulative Total Transaction Amount (CTTA) to zero.
• Consecutive Transaction Counter (CTC) to zero.
• Consecutive Transaction Counter International (CTCI) to zero.
• Contactless Transaction Counter (CLTC) to zero.
Note: The ‘Add transaction to velocity-checking counters’ counter control is not supported for
Issuer Update Processing. The transaction parameters necessary to determine the appropriate
counters to update may not be known by the card during Issuer Update Processing.
Req 6.77 (Issuer Authentication Successful)
After Issuer Authentication has been successfully completed and CSU processing performed,
the card shall indicate that Issuer Authentication was successful by responding to the
EXTERNAL AUTHENTICATE command with SW1 SW2 = '9000'.

6 Card Requirements
6.6.3 Issuer Script Processing
Issuer script commands are processed by the card application as defined in this section.
Figure 6–3: Issuer Script Command Processing (Card) briefly outlines card application issuer
script processing when an issuer script command is received.
Figure 6–3: Issuer Script Command Processing (Card)
Reader Card
Begin Issuer Script

Command Issuer script command
Last Contactless
Issuer script response Application
Y
SW1 SW2 = ‘6985’ Cryptogram Valid
Indicator = 0?
Secure
Issuer script response
N messaging
SW1 SW2 = ‘6987’
present?
MAC
N successfully
SW1 SW2 = ‘6988’
validated?
Process issuer script

command

Command
N processing
successful?
Respond with issuer

Set/reset counters
script command
and indicators
processing result
End Issuer Script

Command
Upon receipt of an issuer script command, the card shall process the command according to
the procedure shown below.
Req 6.77A (Increment Non-Cyclic Issuer Script Command Counter)
When the Issuer Script Command Counter (ISCC) is non-cyclic, the card shall implement one
of the following: 1) increment the ISCC upon receipt of an issuer script command containing
secure messaging (as defined in the latter part of this requirement), or 2) increment the ISCC
after successful performance of the issuer script command (as defined in Req 6.82).

6 Card Requirements
If all of the following are true:
• the ISCC is not cyclic (ADA byte 3 bit 2 is 0b)
• and the issuer script command received contains secure messaging
• and the card is implemented to increment the non-cyclic Issuer Script Command Counter
upon receipt of an issuer script command containing secure messaging
Then the card shall increment the Issuer Script Command Counter by one.
Req 6.78 (Last Contactless Application Cryptogram Valid Indicator)
If the Last Contactless Application Cryptogram Valid Indicator is 0, then the card shall:
Req 6.79 (MAC Verification)
The card shall perform secure messaging and validate the MAC sent in the secure message,
as defined in Appendix G.6.
If MAC validation is successful, then the card shall perform the issuer script command.
Else (an error occurred during validation of the MAC), the card shall:
• Discontinue processing the command and respond with SW1 SW2 = '6987' or SW1 SW2 =
'6988':
̵ The card should respond with SW1 SW2 = '6987' if the MAC is missing.
̵ The card should respond with SW1 SW2 = '6988' if the MAC is incorrect.
Req 6.80 (Issuer Script Reset of CTTA)
If ‘Do not reset CTTA during Issuer Authentication Processing’ supported by card (ADA byte 2
bit 2 is 1b) and a PUT DATA command updating the Cumulative Total Transaction Amount
Limit (CTTAL) is successfully performed, then the card shall reset the Cumulative Total
Transaction Amount (CTTA) to zero.
Req 6.81 (Issuer Script Reset of VLP Available Funds)
If ‘Do not reset VLP Available Funds during Issuer Authentication Processing’ supported by
card (ADA byte 2 bit 1 is 1b) and a PUT DATA command updating the VLP Funds Limit is

6 Card Requirements
successfully performed, then the card shall reset the VLP Available Funds to the VLP Funds
Limit.
Req 6.82 (Issuer Script Command Result)
If the card is able to successfully validate the MAC and successfully perform the issuer script
command, then the card shall:
• If the Issuer Script Command Counter is cyclic (ADA byte 3 bit 2 is 1b) or the card is
implemented to increment the non-cyclic Issuer Script Command Counter after successful
performance of an issuer script command, then the card shall increment the Issuer Script
Command Counter by one.
Note: When the Issuer Script Command Counter (ISCC) has a value of 'F', the resulting value
of the ISCC after it is incremented by one is dependent on whether the ISCC is cyclic (ADA
byte 3 bit 2). If the ISCC is cyclic, then incrementing the ISCC by one cycles the value back to
'0'. Otherwise (the ISCC is not cyclic), incrementing the ISCC by one results in the same value
of 'F'.
• Set the Last Online ATC Register to the value of the ATC.
• Set the Last Successful Issuer Update ATC Register to the value of the ATC.
• Respond indicating the issuer script processing result.
Else (Issuer Script command processing is unsuccessful), the card shall:
• Respond indicating the issuer script processing result.

A Fast Dynamic Data Authentication (fDDA)

In most contactless payment environments, quick transaction speeds are a business
requirement. A method of dynamic data authentication, called fDDA (based on DDA as defined
in [EMV]) is therefore defined for offline protection against skimming.
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 GPO command, rather than generating the dynamic signature at the end
of the transaction when the card may be moving away from the reader field.
The card uses the PDOL to request data from the terminal for fDDA. The card receives the
requested data from the reader in the GPO command. The card uses these terminal data
elements, along with card data, to create the dynamic signature.
The AFL returned in the GPO points to records containing the RSA certificates and data related
to fDDA. Once the last record is read by the reader, the card need no longer remain in the
field. The reader then validates the dynamic signature for fDDA. If the validation process fails,
the transaction is declined offline, sent online for authorization, or terminated, dependent on
issuer preference (as indicated in the CTQ).
In order to accommodate the possibility of new fDDA algorithms and inputs, the card data
element fDDA Version Number (part of tag '9F69') is defined to identify the fDDA version used
by the card. The fDDA Version Number is returned by the card and used by the reader to
determine the fDDA version algorithm to perform. In this version of the specification, only
fDDA version '01' is defined and supported.
For cards compliant to this version of the specification, only fDDA version '01' is allowed.
For readers compliant to this version of the specification, only fDDA version '01' is allowed.
For fDDA version '01', the card includes the (Terminal) Unpredictable Number; Amount,
Authorized; and Transaction Currency Code received from the reader in the PDOL, combined
with the card ATC and Card Authentication Related Data into the calculation of the dynamic
signature.
Note: The Static Data Authentication Tag List (tag '9F4A') is supported as defined in [EMV]
Book 3 section 10.3 and [EMV] Book 2 section 6 for fDDA processing.

A.1 Dynamic Signature Generation
The concatenation of data and generation of the dynamic signature will be in accordance with
[EMV] Book 2 section 6.5.1 Step #2, with the following exception(s):
• For online authorization requests (ARQC), the Signed Data Format input to the DDA hash
algorithm ([EMV] Book 2 Table 15) shall be the value '95'. The Signed Data Format of '95'
distinguishes the dynamic signature returned for an online authorization request from the
dynamic signature returned for an offline authorization request (where Signed Data Format
'05' is used).
• For offline approval requests (TC), the Signed Data Format input to the DDA hash algorithm
([EMV] Book 2 Table 15) shall continue to be the value '05'.
The Terminal Dynamic Data elements are not specified in the DDOL (as the DDOL is not a
recognized data element for qVSDC). The Terminal Dynamic Data referenced in [EMV] Book 2
Table 15 shall consist of the concatenation of the data elements specified in Table A–1 in the
order specified. fDDA fails if any of the data elements required to support fDDA is missing.
Prior to including the Card Authentication Related Data in the Terminal Dynamic Data, the card
shall generate and include the (card) Unpredictable Number and CTQ in the Card
Authentication Related Data.
Note: If the CTQ is not personalized, then a value of zeros is used in the Card Authentication
Related Data.
The ICC Dynamic Number referenced in the paragraph after [EMV] Book 2 Table 15 shall
consist of the data element value specified in Table A–2.
Table A–1: Terminal Dynamic Data for input to DDA hash algorithm
Tag Data Element Length Data Source
9F37 Unpredictable Number 4 bytes Terminal
9F02 Amount, Authorized 6 bytes Terminal
5F2A Transaction Currency Code 2 bytes Terminal
9F69 Card Authentication Related Data var. Card

Table A–2: ICC Dynamic Number for input to DDA hash algorithm
Tag Data Element Length Data Source
9F36 Application Transaction Counter (ATC) 2 bytes Card
A.2 Dynamic Signature Verification
To verify the fDDA dynamic signature, the reader-terminal shall first retrieve the Certification
Authority Public Key Index, as specified in [EMV] Book 2 section 6.2.
Retrieval of the Issuer Public Key shall then be performed by the reader-terminal in accordance
with [EMV] Book 2 section 6.3.
Retrieval of the ICC Public Key shall be performed by the reader-terminal in accordance with
[EMV] Book 2 section 6.4.
Verification of the dynamic signature shall then be performed by the reader-terminal in

accordance with [EMV] Book 2 section 6.5.2, with the following exception(s):
• The Terminal Dynamic Data elements input to the hash algorithm shall be as specified in
Table A–1 instead of being specified in the DDOL (as the DDOL is not a recognized data
element for qVSDC). The terminal may treat the tags specified in Table A–1 as default
DDOLs for fDDA version '01'.
Note: The Card Authentication Related Data is variable length. The reader shall use the full
Card Authentication Related Data returned by the card for dynamic signature verification.
In any of the following cases, fDDA shall fail:

• Application Interchange Profile (AIP) indicates that DDA is not supported by the card (AIP
byte 1 bit 6 is 0b).
Note: Readers compliant to this specification do not perform fDDA dynamic signature
verification for card application online approval requests.
• fDDA is supported and data required to support fDDA is missing.
• The version of fDDA requested by the card is not supported by the reader. fDDA v01 is the
only supported version of fDDA in this specification.
• The dynamic signature is using a Signed Data Format that is not '05'.
Note: Although card application behavior is specified to be capable of returning a dynamic

signature generated using a Signed Data Format of '95', this behavior is not intended to be used
at standard POS acceptance environments. Readers compliant to this specification shall use
Signed Data Format '05' only (and not Signed Data Format '95') when verifying the dynamic
signature.

Figure A–1: Fast DDA (fDDA) qVSDC Example
DDA-capable qVSDC-capable
Acquirer 10 qVSDC reader 1-8 contactless card
9 supports fDDA
1. Reader SELECTs PPSE. 2. Card responds with single Visa

AID.
3. Reader SELECTs Visa AID. 4. Card responds requesting:

• Terminal Transaction
Qualifiers (tag '9F66')
• Unpredictable Number (tag
'9F37')
• Amount, Authorized (tag
'9F02')
• Transaction Currency Code
(tag '5F2A')
• Other tags not related to
fDDA
5. Reader issues GET PROCESSING 6. Card responds with:
OPTIONS providing: • Dynamic signature
• Tag '9F66' indicating qVSDC • AFL listing records related to
only Offline Data Authentication
• Tag '9F37' Unpredictable (fDDA)
Number • Other data not related to
• Tag '9F02' Amount, fDDA
Authorized
• Tag '5F2A' Transaction
Currency Code
• Other card requested data
not related to fDDA
7. Reader reads records indicated 8. Card provides RSA certificates
in AFL. and data to validate hash of
static data along with Card
Authentication Related Data in
response to the last READ
RECORD.
Card may leave the field.
9. Reader validates dynamic

signature.
10. If fDDA fails, the transaction is
declined, switched to another
interface, or sent online
depending on issuer settings.

<This appendix has been deleted>
B <This appendix has been deleted>

C Cryptogram Versions
C.1 Cryptogram Version Number 10('0A')
Cryptogram Version Number 10 shall be as defined in [VIS] Appendix D, with the following
exception(s):
• Reader-terminal data objects input to the cryptographic algorithm are requested by the
card in the Processing Options Data Object List (PDOL).
[VIS] Appendix D defines the input parameters, keys, and algorithms associated with the
generation of the cryptogram for Cryptogram Version Number 10.
C.2 Cryptogram Version Number 17('11')
Cryptogram Version Number 17 uses the same algorithm and parameters as Cryptogram
Version Number 10, but differs in that it does not support all of the data elements required for
Cryptogram Version Number 10. Table C–1 lists the data elements in the required order for
Cryptogram Version Number 17.
Table C–1: Data Elements included in Cryptogram Version Number 17
Data from Input by

Tag Data Element Terminal Card
'9F02' Amount, Authorized 
'9F37' Unpredictable Number 
'9F36' Application Transaction Counter (ATC) 
'9F10' Issuer Application Data (IAD) Byte 5 

Only byte 5 of the IAD is used for CVN17 cryptogram generation.
Though only IAD byte 5 is signed, the entire IAD shall be present
in messages.
Note: IAD byte 5 is CVR byte 2.
C.3 Cryptogram Version Number 18('12') and '22'
Cryptogram Version Number 18 and Cryptogram Version Number '22' shall be as defined in
[VIS] Appendix D, with the following exception(s):

[VIS] Appendix D defines the input parameters, keys, and algorithms associated with the
generation of the cryptogram for Cryptogram Version Number 18 and Cryptogram Version
Number '22'.
C.4 Cryptogram Version Number 12('0C'), '2C', and 50('32')

through 59('3B')
CVN12, CVN'2C', and CVN50 through 59 have been made available to designate issuer
proprietary cryptogram processing.
CVN12 and CVN50 through CVN59 are supported for IAD Format 0/1/3. CVN'2C' is supported
only for IAD Format 2.
These CVNs shall be as defined in [VIS] Appendix D, with the following exception(s):

D VCPS Data Elements

This appendix defines the data elements used in this specification for financial transaction
interchange and their mapping onto data objects.
D.1 Data Element Descriptions
Table D–1 lists the data elements used in VCPS.
Req D.1 (Data Element Requirements)
Readers and cards shall comply with the requirements, where specified and applicable, in
Table D–1.
D.1.2 Name
The Name column lists the name of the data element, and also includes the following:
• Format (F) of the data element. The [EMV] defined supported formats are as follows:
- n (numeric)
- cn (compressed numeric)
- b (binary or bit string)
- an (alphanumeric)
- ans (alphanumeric special)
• Tag (T) of the data element in hexadecimal. Tags in the range 'DF00' – 'DFFE' are context
specific data elements that only define the corresponding data element when contained in
the listed template tag. This is shown as “DFxx in BFxx”, where 'DFxx' represents the context
specific data element, and 'BFxx' represents the template tag containing the context specific
data element.
The meaning assigned to a context-specific tag in one template will be different from the
meaning assigned to the same context-specific tag in another template.
Note: A data element that is defined with both a primitive tag and a context specific primitive
tag within a template tag shall reference the same underlying value regardless of the tag
used. The data element value shall be personalizable, updateable, and accessible using either
tag, subject to the specific restrictions for the data element.
• Length (L) of the data element in bytes. The value of the length is shown in decimal. When
the length defined for the data object is greater than the length of the actual data, the
following rules apply:

- A data element in format n is right-justified and padded with leading hexadecimal
zeros
- A data element in format cn is left-justified and padded with trailing hexadecimal 'F's
- A data element in format an is left-justified and padded with trailing hexadecimal zeros
- A data element in format ans is left-justified and padded with trailing hexadecimal
zeros
When data is moved from one entity to another (for example, card to reader), it shall always
be passed in order from high order to low order, regardless of how it is internally stored.
The same rules apply when concatenating data.
• Source (S) of the data element, indicated as “Card”, “Reader”, or “Issuer”.
• Dual Interface (D) indicates that for cards also supporting VIS, the data element is not
supported for VIS (“–”), shared with VIS (“Shared”), exclusive/separate between VCPS and
VIS (“Exclusive”), or is not applicable ("N/A"). Data elements that are issuer configurable to
be either Exclusive or Shared (e.g. record data) are indicated as “E or S”.
Note: “Exclusive” indicates that the data element can be configured separately. This does not
preclude the data element from being configured with the same value.
D.1.3 Requirement
The Requirement column lists the requirements for the data element:
• Mandatory – The data element must always be present and provided to the reader if the
source is the card. If the data element is not received by the reader, then the reader
terminates the transaction.
• Required – The data element must always be present, but the reader does not terminate the
transaction if the data element is not present.
• Conditional – The data element is necessary under the conditions specified.
• Optional – The data element is optional.
D.1.4 Update Capability, Issuer Update, Retrieval, Secret
This column lists the Update Capability (UC), Issuer Update (IU), Retrieval (R), and Secret data
requirements for data elements that have the card as the source. The following sections further
describe the values for each of these fields.
Update Capability (UC)
The Update Capability (UC) entry in this column categorizes card-sourced data into the
following classifications:
• Unchanging—The data element value is set before the first transaction (either by
personalization of a starting value, or to a default value) and shall not change.

• Modifiable—The data element value is set before the first transaction (either by
personalization of a starting value, or to a default value) and the value it contains at the end
of one transaction is the value retained for use during the subsequent transaction. The value
may only be modified post-issuance using an issuer update, as identified in the Issuer
Update (IU) entry listed in this column.
• Persistent—The data element value is set before the first transaction (either by
may only be modified as part of transaction processing (for example, to indicate events that
have occurred during the current transaction which may be used in processing subsequent
transactions), and shall not be modified using any issuer script command.
• Dynamic—The data element value is set before the first transaction (either by
may be modified post-issuance either as part of transaction processing or using an issuer
update, as identified in the Issuer Update (IU) entry listed in this column.
• Transient—The data element value is reset at the beginning of a transaction, and the value
set in one transaction is not retained for the subsequent transaction. The value is modified
during transaction processing to indicate events that have occurred during the current
transaction.
Data elements classified as unchanging or persistent may be included as part of an issuer script
command to update a record or larger data element which contains the data element and is
allowed to be updated. However, the value of the unchanging or persistent data element after
update of the record or larger data element shall be the same as the value before the update.
The application is not required to enforce this restriction, it is a requirement on the issuer
script command sent to the application.
For example, the Issuer Application Data may be updated by a PUT DATA command, but the
value of the CVN and DKI after the update shall be the same as the value before the update.
Similarly, the record that contains the Application Expiration Date may be updated, but the
value of the Application Expiration Date after the update must be the same as the value before
the update.
Issuer Update
The Issuer Update (IU) entry in this column shows whether update of the data element is
allowed using an Issuer Update, the command to be used for the update, and any conditions
on the support for update.
The following values are used to indicate support for update of data elements:

• N/A—indicates that the specification does not define a mechanism to update the data
element with an Issuer Update (for example, the data element does not have a tag).
However, update of the data element with an Issuer Update is allowed.
• N—indicates update of the value of the data element with an Issuer Update is not allowed.
Note: The data element may be included as part of an update to a record or larger data
element that is allowed to be updated. However, the value of this data element after update of
the record or larger data element shall be the same as the value before the update. The
application is not required to enforce this restriction, it is a requirement on the issuer script
command sent to the application.
• CSU—indicates that update of the data element is allowed using the functionality
associated with the Card Status Updates data element included in the Issuer Authentication
Data for CVN18 and CVN'22'.
• PIN CHANGE/UNBLOCK—indicates that update of the data element is allowed using the
PIN CHANGE/UNBLOCK command.
• PUT DATA—indicates that update of the data element is allowed using the PUT DATA
command.
• UPDATE RECORD—indicates that update of the data element is allowed using the UPDATE
RECORD command.
Implementations are not required to support Issuer Update of application internal data
elements returned in the GPO response. Implementations are not precluded from supporting
Issuer Update of application internal data elements returned in the GPO response, but support
for any such mechanism is outside the scope of this specification.
Retrieval
The Retrieval (R) entry in this column shows whether the data element may be retrieved by the
reader and the command to be used for the retrieval. If “(SD)” follows the retrieval command,
then the data element shall be retrieved only by special devices and not by readers during
financial transactions. If the column is blank for a data element, support for retrieval of the
data element is optional.
The following values are used to indicate support for retrieval of data elements:
• N/A—indicates that the specification does not define a mechanism to retrieve the data
element (for example, the data element does not have a tag). However, retrieval of the data
element is allowed.
• N—indicates retrieval of the value of the data element shall not be allowed.
• GET DATA—indicates that retrieval of the data element is allowed using the GET DATA
command. The GET DATA command is not used during financial transactions in this version
of the specification.

• GET DATA (SD)—indicates that retrieval of the data element using the GET DATA
command at special devices shall be supported for use in card approval testing,
personalization validation, and investigation of potential interoperability issues.
Note: The card application is not required to distinguish between the GET DATA command
used by readers during financial transactions and the GET DATA command used by special
devices. From a card application perspective, there is no difference between the GET DATA
and GET DATA (SD) designations.
• GET PROCESSING OPTIONS (GPO)—indicates that the data element may be retrieved as
part of the data sent in the response to the GET PROCESSING OPTIONS command.
• READ RECORD—indicates that retrieval of the data element is allowed using the READ
RECORD command.
• SELECT—indicates that the data element may be retrieved as part of the data sent in the
response to the SELECT command.
Secret Data
Data elements identified as Secret in this column shall be stored securely within the card for
each application in one or more proprietary internal files. These data elements shall never be
retrievable by a reader or any outside source and shall never be updated. The following data
elements are secret:
• Unique DEA Key A and Unique DEA Key B
• Data Encipherment DEA Key A and Data Encipherment DEA Key B
• MAC DEA Key A and MAC DEA Key B
• ICC Private Key

Table D–1: VCPS Data Elements
Name (Format;
Tag; Length;
Source; Path; Update Capability; Issuer
Dual Interface) Requirement Description Update; Retrieval; Secret Values
Amount, Required Visa proprietary data element used UC: Transient When the Transaction Currency Code matches a
Approximated in qVSDC Card Action Analysis. IU: N Conversion Currency Code in the Currency
F: n 12 Conversion Parameters, the card application
R: N
calculates the (approximate) value of the
T: –
transaction using the associated Currency
L: 6 Conversion Factor and stores the resulting value
S: Card in the Amount, Approximated.
D: – When the Transaction Currency Code matches
the Application Currency Code, the Amount,
Approximated has the same value as the
Amount, Authorized.
Amount, Required Authorized amount of the N/A

Authorized transaction (including Amount,
(Numeric) Other and excluding adjustments).
F: n 12
T: 9F02
L: 6
S: Reader
D: N/A
Amount, Other Conditional Secondary amount associated with N/A

(Numeric) If cashback the transaction representing a
F: n 12 supported cashback amount.
T: 9F03
L: 6
S: Reader
D: N/A

Name (Format;
Tag; Length;
Amounts Data Conditional Visa proprietary data template that UC: Dynamic The following context-specific tags are defined
Template If supported for contains the TLV-coded values for IU: PUT DATA in this specification for the Amounts Data
F: b VIS and Low the CTTA, CTTAL, and CTTAUL. Template:
R: GET DATA (SD)
T: BF58 Value AND CTTA 'DF11' – CTTA
Check supported 'DF21' – CTTAL
L: var.
S: Card 'DF31' – CTTAUL
D: Shared
Application Conditional Visa proprietary data element UC: Dynamic Byte 1

Capabilities If Application indicating card application IU: PUT DATA bit 8: 1 = Contactless Functionality Disabled
F: b 16 Capabilities capabilities.
R: GET DATA (SD) bit 7: 1 = Restrict reset of Contactless
T: DF01 in BF5B functionality For data element usage, see Functionality Disabled bit
supported Appendix I.
L: 2 bits 6-1: RFU (000000)
S: Card Byte 2
D: Shared RFU ('00')
Application Mandatory Cryptogram returned by the card in UC: Transient

Cryptogram (AC) response to the GPO command. IU: N
F: b 64 R: GPO
T: 9F26
L: 8
S: Card
D: Exclusive

Name (Format;
Tag; Length;
Application Conditional Visa proprietary data element UC: Unchanging

Currency Code If currency code indicating the currency in which the IU: N
F: n 3 restrictions or amount is managed according to
R: GET DATA (SD)
currency code [ISO 4217].
T: 9F51
velocity checks
L: 2
supported
S: Card
D: Shared
Application Conditional Visa Proprietary data element UC: Modifiable Byte 1

Default Action If Application indicating issuer-specified action for IU: PUT DATA bits 8-1: Not used for VCPS
(ADA) Default Action the card to take for certain
R: GET DATA (SD) Byte 2
F: b 32 functionality conditions.
bits 8-3: Not used for VCPS
T: 9F52 supported Applications shall accept
personalization of 4 bytes of data bit 2: 1 = Do not reset CTTA during Issuer
L: 6 Authentication processing.
for the ADA. In the case of ADA
S: Card personalization only providing a 4 Note: CTTA is reset to zero during Issuer Script
D: Shared byte value, the application shall processing if PUT DATA to CTTAL is successful.
store a 6 byte value for the ADA bit 1: 1 = Do not reset VLP Available Funds
consisting of the 4 bytes of during Issuer Authentication processing.
personalized data, left justified, and
Note: VLP Available Funds is reset to VLP
padded on the right with '0000'. A
Funds Limit during Issuer Script processing if
PUT DATA to the ADA must send a
PUT DATA to VLP Funds Limit is successful.
6 byte updated value. The
application responds to a GET DATA – continues –
for the ADA with a 6 byte value.

Name (Format;
Tag; Length;
Application Byte 3
Default Action Note: Support for the functionality associated
(ADA) with byte 3 bits 8-6 is conditional on support for
(continued) transaction logging.
bit 8: 1 = Do not include offline approval
requested transactions in the transaction log
bit 7: 1 = Do not include online approval
requested transactions in the transaction log
bit 6: 1 = Include offline declined transactions
in the transaction log
bit 5: 1 = Reset VLP Available Funds to VLP
Funds Limit when Offline PIN successfully
verified
bit 4: Not used for VCPS
bit 3: 1 = Issuer Script MAC Chaining
supported
Note: If issuer scripts commands are supported,
it is highly recommended that byte 3 bit 2 be
set to 1b so that only successful issuer script
commands are counted.
bit 2: 1 = Issuer Script Command Counter is
cyclic
Note: Support for the functionality associated
with byte 3 bit 1 is conditional on support for
[VIS], and allows [VIS] and VCPS applications to
count international transactions using the same
single counter.
bit 1: 1 = CTCI also counts non-matching
country code transactions

Name (Format;
Tag; Length;
Application Byte 4
Default Action Note: Support for the functionality associated
(ADA) with byte 4 bits 8-6 is conditional on support for
(continued) Issuer Update Processing and Cryptogram
Version Number 18 or '22'.
bit 8: 1 = Use Default Update Counters in ADA
if CSU is generated by a proxy
bits 7-6: Default Update Counters
00 = Do not update velocity-checking
counters
01 = Set velocity-checking counters to
Upper Limits
10 = Reset velocity-checking counters to
zero
11 = Not used for VCPS
bit 5: 1 = Padding method '80' supported
bit 1: RFU(0)
– continues –

Name (Format;
Tag; Length;
Application Byte 5
Default Action bits 8-5: RFU (0000)
(ADA)
(continued)
bit 1: 1 = Secure Messaging uses EMV Session
key-based derivation
Note: Support for the functionality associated
with ADA Byte 5 bit 1 is conditional on support
of IAD Format 2 and Issuer Scripting. If the
application does not support IAD Format 2 or
does not support Issuer Scripts, this bit is RFU
(0). The functionality associated with ADA Byte
5 bit 1 is described in [VIS].
Byte 6: RFU ('00')
Application See entry for "Application Identifier"

Definition File (tag '4F').
(ADF) Name
Application Conditional Date after which the card UC: Unchanging

Expiration Date If fDDA supported application expires. IU: N
F: n 6 YYMMDD For transactions where Offline Data R: READ RECORD
T: 5F24 Authentication is performed, the
Application Expiration Date is
L: 3
returned.
S: Card
For transactions where Offline Data
D: E or S Authentication is not performed, the
Application Expiration Date does
not need to be returned.

Name (Format;
Tag; Length;
Application File Conditional Indicates the location (SFI, range of UC: Unchanging For each file to be read, the Application File
Locator (AFL) If returning record records) of the AEFs related to a IU: N Locator contains the following four bytes:
F: var. data for the given application. Byte 1:
R: GPO
T: 94 transaction As with all data elements returned bits 8-4 = SFI
in the GPO response, the card
L: var. up to 252 The Update Capability and bits 3-1 = 000
application supports personalization
S: Card of different AFL data elements for Update of the AFLs for VCPS Byte 2: First (or only) record number to be read
D: Exclusive use in the following GPO responses: may not be the same as the for that SFI (never equal to zero)
AFLs for VIS. Byte 3: Last record number to be reader for that
• qVSDC Offline GPO Response (if
offline implemented) SFI (shall be greater than or equal to byte 2)
• qVSDC Online with ODA GPO Byte 4: Number of consecutive records involved
Response in authentication of static data, starting with
• qVSDC Online/Decline without record number in byte 2 (may range from zero
ODA GPO Response to the value of the third byte minus the value of
the second byte + 1)
Application Mandatory The ADF Name identifies the UC: Unchanging The Visa RID is 'A000000003'.
Identifier (ADF application as described in IU: N The global Visa AIDs are:
Name) [ISO 7816-5]. The AID is made up of
R: SELECT 'A0000000031010': Visa Debit or Credit
F: b 40-128 the Registered Application Provider
Identifier (RID) and the Proprietary 'A0000000032010': Visa Electron
T: 4F
Identifier Extension (PIX). 'A0000000033010': Interlink
L: 5-16
'A0000000038010': PLUS
S: Card
D: Shared

Name (Format;
Tag; Length;
Application Required Identifies the application as N/A

Identifier (AID) described in [ISO 7816-5].
F: b 40-128
T: 9F06
L: 5-16
S: Reader
D: N/A

Name (Format;
Tag; Length;
Application Mandatory Indicates the capabilities of the card UC: Unchanging Byte 1
Interchange to support specific functions in the IU: N bit 8: RFU (0)
Profile (AIP) application.
R: GPO bit 7: 1 = SDA is supported (for online
F: b 16 VCPS readers shall not act on AIP authorizations)
T: 82 bit settings that are not supported
The Update Capability and Note: This bit indicates that a variant of SDA
for VCPS or that are Reserved for
L: 2 Update of the AIPs for VCPS may be supported when the card returns offline
Future Use (RFU).
S: Card may not be the same as the authentication data for online authorizations
As with all data elements returned (see the "Signed Static Application Data" entry
D: Exclusive AIPs for VIS.
in the GPO response, the card in this data dictionary). This variant of SDA
application supports personalization cannot be used for offline authorization
of different AIP data elements for requests.
use in the following GPO responses:
bit 6: 1 = DDA is supported
• qVSDC Offline GPO Response (if
offline implemented)
• qVSDC Online with ODA GPO
Response bit 3: Not used for VCPS
• qVSDC Online/Decline without bit 2: Not used for VCPS
ODA GPO Response bit 1: Not used for VCPS
Byte 2
bit 8: 1 = MSD is supported
bit 7: 1 = Mobile handset
bit 6: 1 = Contactless transaction
bits 5-1: RFU (00000)

Name (Format;
Tag; Length;
Application Conditional Visa proprietary data template that UC: Dynamic The following context specific tags are defined
Internal Data If Application contains Visa proprietary context IU: PUT DATA in this specification for the Application Internal
Template Capabilities specific tags for application internal Data Template:
R: GET DATA (SD)
F: b supported data. 'DF01' – Application Capabilities
T: BF5B
L: var.
S: Card
D: –
Application Label Optional Mnemonic associated with AID UC: Unchanging

F: ans 1-16 * according to [ISO 7816-5]. Used in IU: N
application selection. Application
T: 50 R: SELECT
Label is optional in the File Control
L: 1-16 Information (FCI) of an Application
S: Card Definition File (ADF) and optional in
D: E or S an ADF directory entry for VCPS.
* (special
characters limited
to spaces)
Application Optional Preferred mnemonic associated with UC: Unchanging

Preferred Name the AID. IU: N
F: ans 1-16 R: SELECT
T: 9F12
L: 1-16
S: Card
D: E or S

Name (Format;
Tag; Length;
Application Conditional Valid cardholder account number. UC: Unchanging If the value of the Application PAN does not
Primary Account If fDDA supported For transactions where Offline Data IU: N match the account number in Track 2 Equivalent
Number (PAN) Authentication is performed, the Data (tag '57'), the reader shall terminate the
R: READ RECORD
F: var. up to cn 19 Application PAN is returned. transaction.
T: 5A For transactions where Offline Data

L: var. up to 10 Authentication is not performed, the
Application PAN does not need to
S: Card
be returned.
D: E or S
Application Optional Identifies and differentiates card UC: Unchanging Note: Although this field is optional in the card,
Primary Account applications with the same PAN. IU: N if it is present in the card it is sent in online
Number messages. If it is not sent in online messages, the
R: GPO, READ RECORD
Sequence value is assumed to be '00' for key derivations.
Number (PSN)
F: n 2
T: 5F34
L: 1
S: Card
D: E or S
Application Conditional Indicates the priority of a given UC: Unchanging bit 8: Not used for VCPS
Priority Indicator If multiple application or group of applications IU: N bits 7-5: RFU (000)
F: b 8 contactless in a directory.
R: SELECT bits 4-1:
T: 87 payment
0000 = No priority assigned
applications on
L: 1 xxxx = Order in which the application is to be
card
S: Card selected, ranging from 1 to 15, with 1 being
D: E or S the highest priority

Name (Format;
Tag; Length;
Application Required Visa proprietary data element UC: Unchanging Byte 1:

Program identifying the Application Program IU: N bits 8-5:
Identifier ID of the card application.
R: SELECT 0000b = Visa global use
(Program ID) The Application Program ID is
0001b = US
F: b 40-128 returned in the FCI Issuer
Discretionary Data of the SELECT 0010b = Canada
T: 9F5A
response (tag 'BF0C'). 0011b = VE
L: var. 5-16
qVSDC readers that support 0100b = AP
S: Card
Dynamic Reader Limits (DRL) 0101b = LAC
D: – functionality examine the
0110b = CEMEA
Application Program ID to
determine the Reader Limit Set to bits 4-1: Visa regional discretion
apply. Bytes 2-3:
Numeric currency code per [ISO 4217], left
padded with a leading '0'.
Bytes 4-5:
Numeric country code per [ISO 3166], left
padded with a leading '0'.
Bytes 6-16:
Visa regional discretion
Application Program ID byte 1 bits 4-1 and
bytes 6-16 are assigned at the discretion of each
Visa region.

Name (Format;
Tag; Length;
Application Optional Market-proprietary data that may UC: Unchanging The value field of the Application Selection
Selection be required by local regulatory IU: N Registered Proprietary Data follows the
Registered authority to offer specific services following format:
R: SELECT
Proprietary Data based on this information, as ID1, L1, V1, ID2, L2, V2,…
(ASRPD) defined in [EMV ASRPD].
Where
F: b The Application Selection
• IDn is a two byte Proprietary Data Identifier,
T: 9F0A Registered Proprietary Data may be
registered by EMVCo. IDs have no structure
returned by the card during
L: var. (they are not BER-TLV tags), and may appear
Application Selection – that is, it
S: Card in any order within the ASRPD.
may be present in one or both of
D: E or S the following: • Ln is the length of the value field coded in 1
byte (0 to 255).
• In any Directory Entry (tag '61')
• Vn is the value field. Its content is
within the FCI of the PPSE.
proprietary and format is out of scope of
• In the FCI Issuer Directory
EMVCo.
Discretionary Data (tag 'BF0C')
within the FCI of the ADF. See [EMV ASRPD] for additional information.
Use of the Application Selection

Registered Proprietary Data by the
reader is optional and proprietary,
and is outside the scope of this
specification.

Name (Format;
Tag; Length;
Application Mandatory Count of the number of transactions UC: Persistent Implementations may support personalizing the
Transaction initiated since personalization. IU: N ATC with an initial value. Initial value is zero
Counter (ATC) Maintained by the application in the unless optionally personalized to an initial
R: GET DATA (SD), GPO
F: b 16 card. starting value.
T: 9F36 The ATC is incremented by 1 each time a

transaction is performed.
L: 2
If the ATC reaches its maximum value, then the
S: Card
application is permanently blocked as specified
D: Shared in Req 6.7 (Application Permanently Blocked).

Name (Format;
Tag; Length;
Application Conditional Indicates issuer-specified UC: Modifiable Byte 1

Usage Control If supporting AUC restrictions on the geographic IU: UPDATE RECORD bit 8: 1 = Valid for domestic (manual) cash
(AUC) check for manual usage and services allowed for the transactions
R: READ RECORD
F: b 16 cash or cashback card application. bit 7: 1 = Valid for international (manual) cash
T: 9F07 transactions
L: 2 bits 6-3: Not used for VCPS
S: Card bit 2: 1 = Valid at ATMs
D: E or S Note: The AUC ‘Valid at ATMs’ bit is used to
indicate whether the card application supports
contact chip ATM transactions. The equivalent
configurable bit setting for contactless chip
ATM transactions is found in the Card
Transaction Qualifiers (CTQ) byte 1 bit 1.
bit 1: RFU (0)
Byte 2
bit 8: 1 = Domestic cashback allowed
bit 7: 1 = International cashback allowed
bits 6-1: RFU (000000)
Note: Application Usage Control restrictions for
"domestic" and "international" transactions are
determined (by the reader) by comparing the
Issuer Country Code to the Terminal Country
Code.

Name (Format;
Tag; Length;
Authorization Conditional Non zero value generated by the N/A

Code If Issuer Update issuer for an approved transaction.
F: ans 6 * Processing
T: 89 supported
L: 6 (From issuer, not

passed to card)
S: Issuer
D: –
* (special
characters limited
to spaces)
Authorization Conditional Indicates the transaction disposition N/A Codes generated by the issuer are as indicated
Response Code If Issuer Update of the transaction received from the in [ISO 8583]:1987.
(ARC) Processing issuer for online authorizations. • 00, 10, or 11 indicates an issuer approval.
F: an 2 supported • 01 or 02 indicates an issuer referral.
T: 8A • An ARC other than the ones listed above
L: 2 indicates an issuer decline.
S:Issuer/Reader The following codes are generated by the
reader-terminal for the following conditions:
D: –
• Y1 = Offline approved
• Z1 = Offline declined
• Y3 = Unable to go online (offline approved)
• Z3 = Unable to go online (offline declined)

Name (Format;
Tag; Length;
Available Offline Optional Visa proprietary data element UC: Transient Inclusion of this data element in the GPO
Spending indicating the remaining amount IU: N response is permitted if CAP byte 1 bit 1 is 1b.
Amount (AOSA) available to be spent offline. Note: Inclusion of the AOSA value in the Issuer
R: GPO
F: n 12 The AOSA is a calculated field used Discretionary Data is configured using the IDD
T: 9F5D to allow the reader to print or Options (as defined in Appendix E), and is not
display the amount of offline spend dependent on the setting of CAP byte 1 bit 1.
L: 6
that is available on the card. The Available Offline Spending Amount shall be
S: Card
calculated as follows:
D: Shared
If ‘Low Value Check supported’ by card (CAP
byte 1 bit 8 is 1b), then
AOSA = VLP Available Funds.
Else, If ‘Low Value AND CTTA Check
supported’ by card (CAP byte 1 bit 7 is 1b):
AOSA = CTTA Funds
Else, AOSA = CTTAL – CTTA
If the AOSA cannot be calculated or is a
negative value, then the card shall return the
AOSA as a value of all zeros.

Name (Format;
Tag; Length;
Card Additional Required * Indicates card processing UC: Modifiable Byte 1

Processes (CAP) requirements and preferences. IU: PUT DATA bit 8: 1 = Low Value Check supported
F: b 32 * Card Additional R: GET DATA (SD) bit 7: 1 = Low Value AND CTTA Check
T: 9F68 Processes is not supported
L: 4 required to be bit 6: 1 = Count qVSDC online transactions
personalized for
S: Card bit 5: 1 = Streamlined qVSDC supported
Streamlined
D: Shared qVSDC bit 4: 1 = PIN Tries Exceeded Check supported
bit 3: 1 = Offline international transactions are
allowed
bit 2: 1 = Card Prefers Contact Chip
Note: Byte 1 bit 2 is used to indicate that the
card application prefers contact chip
transactions (at contact chip capable devices) to
reset risk management parameters or when a
contactless transaction is not possible.
bit 1: 1 = Return Available Offline Spending
Amount (AOSA)
Byte 2
bit 8: 1 = Include country code in determining
international transactions
bit 7: 1 = International transactions are not
allowed
bit 6: 1 = Disable Offline Data Authentication
(ODA) for Online Authorizations
bit 5: 1 = Issuer Update Processing supported
– continues –

Name (Format;
Tag; Length;
Card Additional bit 4: 1 = Do not count qVSDC offline

Processes transactions
(continued) 0 = Count qVSDC offline transactions
bit 3: 1 = Card Prefers Online
bits 2-1: RFU (00)
Byte 3
bit 8: 1 = Online PIN supported for domestic
transactions
bit 7: 1 = Online PIN supported for
international transactions
bit 6: 1 = (Contact Chip) Offline PIN supported
bit 5: 1 = Signature supported
bit 4: 1 = CDCVM supported
bits 3-1: RFU (000)
Byte 4
RFU ('00')

Name (Format;
Tag; Length;
Card Conditional Contains the fDDA Version Number, UC: Unchanging (byte 1) Byte 1: fDDA Version Number ('01')
Authentication If fDDA supported Card Unpredictable Number, and Transient (bytes 2-7) Byte 2-5: (Card) Unpredictable Number
Related Data Card Transaction Qualifiers.
IU: N Byte 6-7: Card Transaction Qualifiers
F: b For transactions where fDDA is
R: READ RECORD In this version of the specification, the Card
T: 9F69 performed, the Card Authentication
Authentication Related Data personalized on
Related Data is returned in the last
L: var. 5-16 the card has a length of 7 bytes, and is
record specified by the Application
S: Card personalized with the value:
File Locator for that transaction.
D: – '01 00 00 00 00 00 00'
It is recommended to be
personalized at the end of the Card Authentication Related Data bytes 2-7 are
record, as implementations may replaced with the (Card) Unpredictable Number
require it to be the last data and Card Transaction Qualifiers values during
element in the record. VCPS transaction processing.
Card CVM Limit Optional Visa proprietary data element UC: Modifiable Note: Visa recommends that this data element
F: n 12 indicating that for domestic IU: PUT DATA not be personalized nor used. If the data element
contactless transactions where this must be personalized, it is recommended that it
T: 9F6B R: GET DATA (SD)
value is exceeded, a CVM is be personalized to its maximum possible value.
L: 6 required by the card.
S: Card Online PIN and Signature are the
D: – CVMs supported by cards compliant
to this specification.

Name (Format;
Tag; Length;
Card Status Optional Indicates the disposition of the N/A Byte 1

Update (CSU) Passed from the transaction and requested updates bit 8: 1 = Proprietary Authentication Data
F: b 32 issuer through the to the card, received from the included
reader issuer.
T: – bits 7-5: RFU (000)
The CSU is only used if Issuer
L: 4 bits 4-1: PIN Try Counter
Authentication is performed and
S: Issuer passes. Byte 2
D: – If ‘Set velocity-checking counters to bit 8: 1 = Issuer approves online transaction
Upper Limits’ will be used by the bit 7: 1 = Card block
issuer (CSU byte 2 bits 2-1 are 01b), bit 6: 1 = Application block
then the issuer shall personalize the
bit 5: 1 = Update PIN Try Counter
upper limits for the supported
velocity checks. bit 4: 1 = Set Go Online On Next Transaction
Note: The ‘Set Go Online On Next Transaction’
bit is used by dual-interface cards, and does not
impact VCPS transaction disposition processing.
bit 3: 1 = CSU generated by proxy for the
issuer
bits 2-1: Update Counters
00 = Do not update offline counters
01 = Set velocity-checking counters to
Upper Limits
10 = Reset velocity-checking counters to
zero
11 = Not used for VCPS
Byte 3:
RFU ('00')
Byte 4:
Issuer discretionary (or '00')

Name (Format;
Tag; Length;
Card Transaction Conditional In this version of the specification, UC: Modifiable (byte 1 bits 6-1, Byte 1
Qualifiers (CTQ) If CVM supported used to indicate to the device the byte 2 bits 7-1) bit 8: 1 = Online PIN Required
F: b 16 card CVM requirements, issuer Transient (byte 1 bits 8-7,
or if issuer CTQ bit 7: 1 = Signature Required
preferences, and card capabilities. byte 2 bit 8)
T: 9F6C preferences bit 6: 1 = Go Online if Offline Data
L: 2 supported IU: PUT DATA Authentication Fails and Reader is online
S: Card or if Issuer Update R: GET DATA (SD), GPO capable.
Processing at the bit 5: 1 = Switch Interface if Offline Data
D: –
POS supported Authentication fails and Reader supports
contact chip.
bit 4: 1 = Go Online if Application Expired
bit 3: 1 = Switch Interface for (manual) Cash
Transactions
bit 2: 1 = Switch Interface for Cashback
Transactions
bit 1:
1 = Not valid for contactless ATM
transactions
0 = Valid for contactless ATM transactions
Byte 2
bit 8: 1 = CDCVM Performed
bit 7: 1 = Card supports Issuer Update
Processing at the POS
bits 6-1: RFU (000000)

Name (Format;
Tag; Length;
Card Required Visa proprietary data element UC: Unchanging (byte 1) See Table M–2.
Verification indicating the exception conditions Transient (bytes 2-4)
Results (CVR) that occurred during the current
Transient (byte 5, if
F: b 32 or 40 and previous transaction.
present)
Transmitted to the reader in the
T: part of 9F10 IU: N
Issuer Application Data.
L: 4 or 5 R: GPO
S: Card
D: Shared
Cardholder Optional Indicates cardholder name UC: Unchanging For some markets, including the cardholder
Name according to [ISO 7813]. IU: N name on the card will bring up privacy issues as
F: ans 2-26 it can be read along with the PAN information.
R: GPO, READ RECORD
The issuer should take precautions and
T: 5F20
investigate this situation before personalizing
L: 2-26 tag '5F20' or including the cardholder’s real
S: Card name in tag '5F20'.
D: E or S It is strongly recommended that this data
element not be personalized with the
cardholder’s real name, and that a generic
cardholder name should instead be
personalized.
Certificate Conditional Payment system public key used for N/A Value generated by Visa and loaded to terminal
Authority Public If fDDA supported dynamic data authentication. by acquirer. Six Visa public keys shall be
Key supported.
F: b
T: –
L: –
S: Reader
D: N/A

Name (Format;
Tag; Length;
Certificate Conditional A check value calculated on the N/A

Authority Public If fDDA supported concatenation of all parts of the
Key Check Sum Certificate Authority Public Key (RID,
F: b Certificate Authority Public Key
Index, Certificate Authority Public
T: –
Key Modulus, Certificate Authority
L: 20 Public Key Exponent) using SHA-1.
S: Reader
D: N/A
Certificate Conditional Value of the exponent part of the N/A

Authority Public If fDDA supported Certificate Authority Public Key.
Key Exponent
F: b
T: –
L: 1 or 3
S: Reader
D: N/A
Certificate Conditional Identifies the Certificate Authority’s UC: Unchanging Values assigned by Visa.
Authority Public If Offline Data public key in conjunction with the IU: N
Key Index (PKI) Authentication RID for use in offline data
R: READ RECORD
F: b 8 supported authentication.
T: 8F
L: 1
S: Card
D: E or S

Name (Format;
Tag; Length;
Certificate Conditional Identifies the Certificate Authority’s N/A Values assigned by Visa.
Authority Public If fDDA supported public key in conjunction with the
Key Index (PKI) RID for use in offline static and
F: b 8 dynamic data authentication.
T: 9F22
L: 1
S: Reader
D: N/A
Certificate Conditional Value of the modulus part of the N/A

Authority Public If fDDA supported Certificate Authority Public Key.
Key Modulus
F: b
T: –
L: NCA (up to 248)
S: Reader
D: N/A
Command Required Identifies the data field of a N/A

Template command message.
F: b
T: 83
L: var.
S: Reader
D: N/A

Name (Format;
Tag; Length;
Consecutive Conditional Visa proprietary data element UC: Dynamic

Transaction If supported for specifying the number of IU: CSU, PUT DATA
Counter (CTC) VIS and Issuer consecutive offline transactions that
R: GET DATA (SD)
F: b 8 Update have occurred for the card
Processing application since the last time a
T: DF11 in BF56
supported transaction went online.
L: 1
This data element is not used
S: Card during VCPS transactions, and is
D: Shared included in this appendix only
because it may be reset during
Consecutive Conditional Visa proprietary data element UC: Dynamic Initialized to zero unless optionally personalized
Transaction If international specifying the number of IU: CSU, PUT DATA to a starting value. Incremented by 1 each time
Counter velocity checks consecutive offline international an international transaction is approved offline
R: GET DATA (SD)
International supported transactions that have occurred for by the card application.
(CTCI) the card application since the last
F: b 8 time a transaction went online and
Issuer Authentication requirements
T: DF11 in BF57
were met.
L: 1
This counter is not used in VCPS
S: Card transaction processing (i.e. is
D: Shared considered as not present in the
application) unless the application
has been personalized to support
international velocity checks.

Name (Format;
Tag; Length;
Consecutive Conditional Issuer-specified preference for the UC: Modifiable

Transaction If supported for maximum number of consecutive IU: PUT DATA
Counter Limit VIS and Issuer offline transactions allowed for this
R: GET DATA (SD)
(CTCL) Update card application before the card
F: b 8 Processing requires online processing.
T: 9F58 and supported This data element is not used

DF21 in BF56 during VCPS transactions, and is
included in this appendix only
L: 1
because it is referenced in this
S: Card specification.
D: Shared
Consecutive Conditional Issuer-specified preference for the UC: Modifiable

Transaction If supported for maximum number of consecutive IU: PUT DATA
Counter Upper VIS and Issuer offline transactions allowed for this
R: GET DATA (SD)
Limit (CTCUL) Update card application before the card
F: b 8 Processing requires online processing.
T: 9F59 supported This data element is not used
and DF31 in BF56 during VCPS transactions, and is
included in this appendix only
L: 1
because it may be used during
S: Card Issuer Update Processing.
D: Shared

Name (Format;
Tag; Length;
Consecutive Conditional Visa proprietary data element UC: Modifiable

Transaction If international indicating issuer-specified IU: PUT DATA
International velocity checking preference for the maximum
R: GET DATA (SD)
Upper Limit using CTIUL number of consecutive offline
(CTIUL) supported international transactions allowed
F: b 8 before the transaction is declined
offline if it cannot be processed
T: 9F5E and DF31
online.
in BF57
L: 1
S: Card
D: Shared
Consecutive Conditional Visa proprietary data element UC: Modifiable

Transaction If international specifying the maximum number of IU: PUT DATA
Counter velocity checks consecutive offline international
R: GET DATA (SD)
International supported transactions allowed for that card
Limit (CTCIL) application before a transaction is
F: b 8 requested to go online.
T: 9F53 and DF21

in BF57
L: 1
S: Card
D: Shared

Name (Format;
Tag; Length;
Contact Chip Required Visa proprietary internal indicator UC: Transient This indicator is a transient value, initialized to a
Supported used during qVSDC Card Action IU: N value of 0 at the beginning of the transaction.
Indicator Analysis. Indicates that a contact 1 = Contact chip transaction preferred by card
R: N
F: – chip transaction is preferred by the and supported by reader
T: – card and EMV contact chip is
L: – supported by the reader.
S: Card
D: –
Contactless Required Visa proprietary internal indicator N/A This indicator is a transient value, initialized to a
Application Not used during reader transaction value of 0 at the beginning of the transaction.
Allowed processing. Indicates that the 1 = Visa contactless application not allowed
Indicator transaction cannot be conducted
F: – with a Visa application.
T: –
L: –
S: Reader
D: N/A
Contactless Conditional Visa proprietary data template that UC: Dynamic The following context specific tags are defined
Counters Data If contactless contains Visa proprietary context IU: PUT DATA in this specification for the Contactless Counters
Template velocity checking specific tags for contactless Data Template:
R: GET DATA (SD)
F: b (using any of the counters and their associated limits. 'DF11' – CLTC
T: BF55 counters in this 'DF21' – CLTCLL
template) is
L: var. 'DF31' – CLTCUL
supported
S: Card 'DF41' – VLP Single Transaction Limit
P: Q 'DF51' – VLP Available Funds
D: Shared 'DF61' – VLP Reset Threshold
'DF71' – VLP Funds Limit

Name (Format;
Tag; Length;
Contactless Conditional Visa proprietary data element UC: Dynamic Initialized to zero unless optionally personalized
Transaction If contactless specifying the number of qVSDC IU: CSU, PUT DATA to a starting value. Incremented by 1 each time
Counter (CLTC) transaction count offline transactions that have a qVSDC offline transaction occurs. The CAP
R: GET DATA (SD)
F: b 8 velocity checks occurred since the last time a may be configured to cause the CLTC to also
supported transaction went online and Issuer increment when a qVSDC online transaction
T: DF11 in BF55
Authentication requirements were occurs, and may be configured to not increment
L: 1 met. The CAP may be configured to when a qVSDC offline transaction occurs.
S: Card cause the CLTC to also increment
D: Shared when a qVSDC online transaction
occurs, and may be configured to
not increment when a qVSDC offline
transaction occurs.
This counter is not used in VCPS
transaction processing (i.e. it is
considered as not present in the
application) unless the application
contactless transaction count
velocity checks.
Contactless Conditional Visa proprietary data element UC: Modifiable

Transaction If contactless specifying the maximum number of IU: PUT DATA
Counter Lower transaction count qVSDC transactions allowed before
R: GET DATA (SD)
Limit (CLTCLL) velocity checks the card requests contact chip for
F: b 8 supported the transaction (if supported) or
online processing for the
T: DF21 in BF55
transaction (if supported), and
L: 1 proceeds offline if not.
S: Card
D: Shared

Name (Format;
Tag; Length;
Contactless Conditional Visa proprietary data element UC: Modifiable

Transaction If contactless specifying the maximum number of IU: PUT DATA
Counter Upper transaction count qVSDC transactions allowed before
R: GET DATA (SD)
Limit (CLTCUL) velocity checks the card requests contact chip for
F: b 8 supported the transaction (if supported) or
T: DF31 in BF55
transaction(if supported), and
L: 1 declines the transaction if neither is
S: Card supported.
D: Shared
Conversion Conditional Visa proprietary data element in the UC: Modifiable

Currency Code If currency Currency Conversion Parameters IU: PUT DATA
F: n 3 conversion is to data element that identifies an
R: GET DATA (SD)
be performed alternate currency to be converted
T: part of 9F73
(using the corresponding Currency
L: 2 Conversion Factor) to the
S: Card designated currency in which the
D: Shared account is managed (Application
Currency Code) according to
[ISO 4217].
Counters Data Conditional Visa proprietary data template that UC: Dynamic The following context specific tags are defined
Template If dual-interface contains Visa proprietary context IU: PUT DATA in this specification for the Counters Data
F: b card application specific tags for contact counters Template:
R: GET DATA (SD)
and contact and their associated limits. 'DF11' – CTC
T: BF56
velocity checking 'DF21' – CTCL
L: var.
(using any of the
S: Card 'DF31' – CTCUL
counters in this
D: Shared template)
supported

Name (Format;
Tag; Length;
Cryptogram Required Indicates the type of cryptogram UC: Transient bits 8–7
Information Data (TC, ARQC, or AAC) returned by the IU: N 00 = AAC
(CID) card and the actions to be
R: GPO 01 = TC
F: b 8 performed by the reader.
10 = ARQC
T: 9F27
11 = RFU
L: 1
bits 6-5: RFU (00)
S: Card
D: N/A
Cryptogram Required Visa proprietary data element UC: Modifiable Values assigned by Visa.
Version Number indicating the version of the IU: N/A The left nibble of the byte indicates the format
F: b 8 Application Cryptogram algorithm of Issuer Application Data.
R: GPO
used by the application.
T: part of 9F10 The only values supported in this version of
Transmitted in the Issuer
L: 1 VCPS are:
Application Data.
S: Card '0A' = Cryptogram Version Number 10
D: E or S '0C' = Cryptogram Version Number 12

'11' = Cryptogram Version Number 17
'12' = Cryptogram Version Number 18
'22' = Cryptogram Version Number '22'
'2C' = Cryptogram Version Number '2C'
'32' – '3B' = Cryptogram Version Number 50
through 59

Name (Format;
Tag; Length;
Cumulative Total Conditional Visa proprietary data element UC: Dynamic Initialized to zero unless optionally personalized
Transaction If Low Value AND specifying the cumulative total IU: CSU, PUT DATA to a starting value. Incremented by the Amount,
Amount (CTTA) CTTA Check amount of offline domestic Approximated each time a domestic transaction
R: GPO (if included in the IDD
F: n 12 supported transactions in the designated is approved offline by the card application.
as specified in Appendix E)
currency (Application Currency Reset to zero after Issuer Authentication
T: DF11 in BF58
Code or supported Conversion requirements are met.
L: 6 Currency Codes) for the card
S: Card application since the last completed
D: Shared online transaction where Issuer
Authentication requirements were
met.
Cumulative Total Conditional Calculated value indicating the UC: Transient Equal to the Cumulative Total Transaction
Transaction If Low Value AND amount of offline funds available to IU: N Amount Upper Limit minus the Cumulative Total
Amount Funds CTTA Check spend in the Cumulative Total Transaction Amount (CTTAUL - CTTA).
R: N/A
(CTTA Funds) supported Transaction Amount. If the Cumulative Total Transaction Amount
F: n 12 Upper Limit is not present, equal to the
T: – Cumulative Total Transaction Amount Limit
minus the Cumulative Total Transaction Amount
L: 6
(CTTAL - CTTA).
S: Card
D: –

Name (Format;
Tag; Length;
Cumulative Total Conditional Visa proprietary data element UC: Modifiable

Transaction If Low Value AND specifying the maximum total IU: PUT DATA
Amount Limit CTTA Check amount of offline domestic
R: GET DATA (SD), GPO (if
(CTTAL) supported transactions in the designated
included in the IDD as specified
F: n 12 currency (Application Currency
in Appendix E)
Code or supported Conversion
T: 9F54 and
Currency Codes) allowed for the
DF21 in BF58
card application before a
L: 6 transaction is forced to go online.
S: Card
D: Shared
Cumulative Total Optional Visa proprietary data element UC: Modifiable

Transaction If Low Value AND specifying the maximum total IU: PUT DATA
Amount Upper CTTA Check amount of offline transactions in the
R: GET DATA (SD)
Limit (CTTAUL) supported designated currency or supported
F: n 12 conversion currency codes for the
card application before a
T: 9F5C and
transaction is declined after an
DF31 in BF58
online transaction is unable to be
L: 6 performed.
S: Card Personalization of the CTTAUL is
D: Shared strongly recommended if the Low
Value AND CTTA check is
supported.

Name (Format;
Tag; Length;
Currency Conditional Visa proprietary data element in the UC: Modifiable Byte 1
Conversion If currency Currency Conversion Parameters IU: PUT DATA bits 8-5: Number of positions the decimal
Factor conversion is to data element. The Currency separator shall be shifted from the right to
R: GET DATA (SD)
F: n 8 be performed Conversion Factor specifies a obtain the factor.
decimal value used in the
T: part of 9F73 bits 4-1: The first digit of the currency
conversion algorithm to convert an
L: 4 conversion factor
amount in the currency identified by
S: Card the corresponding Conversion Bytes 2-4
D: Shared Currency Code to the designated The remaining six digits of the currency
currency in which the application is conversion factor
managed.
This rate is an approximation and
should be limited to two significant
digits.
Currency Conditional Visa proprietary data element UC: Modifiable Bytes 1–2: Conversion Currency Code 1
Conversion If currency specifying the currency code and IU: PUT DATA Bytes 3–6: Currency Conversion Factor 1
Parameters conversion is to conversion factor for converting an
R: GET DATA (SD) Bytes 7–8: Conversion Currency Code 2
F: n be performed amount in an alternate currency to
an approximate value in the Bytes 9–12: Currency Conversion Factor 2
T: 9F73
designated currency in which the Bytes 13–14: Conversion Currency Code 3
L: var. up to 30 account is managed. Bytes 15–18: Currency Conversion Factor 3
S: Card Conversion Parameters contains Bytes 19–20: Conversion Currency Code 4
D: Shared one or more sets consisting of a
Bytes 21–24: Currency Conversion Factor 4
Conversion Currency Code and an
associated Currency Conversion Bytes 25–26: Conversion Currency Code 5
Factor. Applications that support Bytes 27–30: Currency Conversion Factor 5
Currency Conversion shall be able
to support up to five alternate
currencies.

Name (Format;
Tag; Length;
Customer Optional Contains data for transmission to UC: Modifiable Customer Exclusive Data, if personalized,
Exclusive Data the issuer. IU: PUT DATA, UPDATE consists of one or more Issuer elements. Each
(CED) RECORD element in the CED consists of a 1-byte Visa
F: b proprietary Identifier, a 1-byte length, and a
R: GET DATA (SD), GPO, READ
value. The Identifiers currently defined for the
T: 9F7C RECORD
CED are:
L: var. up to 32
'01' – Issuer Proprietary Data
S: Card
'02' through 'FF' – RFU
D: –
Data Conditional Visa proprietary data element UC: Unchanging

Encipherment If dual-interface containing an 8-byte DEA key used IU: N
DEA Key A card application to support Issuer Script processing
R: N
F: b 64 where PIN when enciphered data is contained
updates in an Issuer Script Command.
T: –
supported and Data Encipherment DEA Key A is Secret
L: 8
Issuer Update used for encipherment and Data
S: Card Processing Encipherment DEA Key B is used for
D: Shared supported decipherment.
The derivation key methodology for
unique DEA keys is described in
[VIS] Appendix D.7.

Name (Format;
Tag; Length;
Data Conditional Visa proprietary data element UC: Unchanging

Encipherment If dual-interface containing an 8-byte DEA key used IU: N
DEA Key B card application to support Issuer Script processing
R: N
F: b 64 where PIN when enciphered data is contained
updates in an Issuer Script Command.
T: –
supported and Data Encipherment DEA Key A is Secret
L: 8
Issuer Update used for encipherment and Data
S: Card Processing Encipherment DEA Key B is used for
D: Shared supported decipherment.
[VIS] Appendix D.7.
Decline Required Required Visa proprietary internal indicator UC: Transient This indicator is a transient value, initialized to a
by Card Indicator used during Qvsdc Card Action IU: N value of 0 at the beginning of GPO processing.
F: – Analysis. Indicates that the card 1 = Offline decline required by card
R: N
T: – requires the transaction to be
L: – declined offline.
S: Card
D: –
Decline Required Required Visa proprietary internal indicator N/A This indicator is a transient value, initialized to a
by Reader used during transaction processing value of 0 at the beginning of the transaction.
Indicator to indicate that internal reader 1 = Offline decline required by reader
F: – processes have indicated that the
T: – transaction should be declined.
L: –
S: Reader
D: N/A

Name (Format;
Tag; Length;
Dedicated File Required Identifies the name of the DF as UC: Unchanging

(DF) Name described in [ISO 7816-4]. IU: N
F: b 40-128 R: SELECT
T: 84
L: 5-16
S: Card
D: Shared
Derivation Key Required Visa proprietary data element UC: Modifiable Value assigned by the issuer.
Index (DKI) identifying to the issuer the IU: N/A
F: b 8 appropriate issuer’s derivation key
R: GPO
to derive the card’s unique DEA
T: part of 9F10
keys for online card and issuer
L: 1 authentication. (The DKI is not used
S: Card by the card.)
D: Shared Passed as part of the Issuer
Application Data.
Directory Entry Mandatory Contains one or more data objects UC: Unchanging
F: var. relevant to an application directory IU: N
entry according to [ISO 7816-5].
T: 61 R: SELECT
L: var.
S: Card
D: Exclusive

Name (Format;
Tag; Length;
fDDA Version Conditional Contains the version number for the UC: Unchanging '01' = fDDA Version Number 1
Number If fDDA supported fDDA version supported by the card IU: N
F: b 8 R: READ RECORD
T: part of 9F69
L: 1
S: Card
D: –
File Control Mandatory Issuer discretionary part of the FCI. UC: Unchanging
Information (FCI) IU: N
Issuer
R: SELECT
Discretionary
Data
F: var.
T: BF0C
L: var. up to 222
S: Card
D: E or S
File Control Mandatory Identifies the data objects UC: Unchanging

Information (FCI) proprietary to [EMV] in the FCI IU: N
Proprietary Template according to [ISO 7816-4].
R: SELECT
Template
F: var.
T: A5
L: var.
S: Card
D: E or S

Name (Format;
Tag; Length;
File Control Mandatory Identifies the FCI template UC: Unchanging

Information (FCI) according to [ISO 7816-4]. IU: N
Template
R: SELECT
F: var.
T: 6F
L: var. up to 252
S: Card
D: E or S

Name (Format;
Tag; Length;
Form Factor Required Indicates the form factor of the UC: Modifiable Byte 1: Consumer Payment Device Form Factor
Indicator (FFI) consumer payment device and the IU: PUT DATA, UPDATE bits 8-6: Form Factor Indicator Version
F: b 32 type of contactless interface over RECORD Number
which the transaction was
T: 9F6E R: GET DATA (SD), GPO, READ All values not currently defined are RFU.
conducted. This information is made
L: 4 RECORD Defines the meaning of Form Factor Indicator
available to the issuer host.
S: Card byte 1 bits 5-1, byte 2, and byte 3. The
Please check with your Visa regional
definition of FFI byte 1 bits 5-1, byte 2, and
D: – representative regarding which form
byte 3 are based on the Form Factor Indicator
factors are supported for your
Version Number, and those definitions may
region.
vary for each Form Factor Indicator Version
Number.
001 = Form Factor Indicator (FFI) Version
Number 1
bits 5-1: Consumer Payment Device Form
Factor
All values not currently defined are RFU.
The definitions listed below are for FFI version
#1.
00000 = Standard card
Card conforming to the physical
dimensions for an ID-1 card type, as
specified in [ISO 7811], regardless of its
transactional capabilities (e.g. magstripe,
contact chip, contactless).
– continues –

Name (Format;
Tag; Length;
Form Factor Byte 1, bits 5-1, continued

Indicator (FFI) 00001 = Mini-card
(continued) Physical card form factor, but of reduced
physical dimensions (height and width)
from an ID-1 card type.
00010 = Non-card Form Factor
Non-card form factor that is contactless-
only that is not described by one of the
other consumer payment device form
factors.
Examples: Key fobs, rings, and stickers
00011 = Consumer mobile phone
00100 = Wrist-worn device
Non-card form factor presented to the
reader, which is worn on the wrist.
Examples: Watches, wristbands, bracelets.
– continues –

Name (Format;
Tag; Length;
Form Factor Byte 2: Consumer Payment Device Features (for

Indicator (FFI) FFI Version #1)
(continued) bit 8: 1 = Passcode Capable
The Consumer Payment Device has the
capability to protect financial transactions
with a Passcode. This is separate from the
PIN used during the financial transaction.
bit 7: 1 = Signature Panel
The Consumer Payment Device has a
signature panel.
bit 6: 1 = Hologram
The Consumer Payment Device has a
hologram.
bit 5: 1 = CVV2
The Consumer Payment Device has CVV2, as
defined in the Visa Payment Technology
Standards Manual.
bit 4: 1 = Two-way Messaging
The Consumer Payment Device is able to
exchange identifying information between
the issuer and consumer, other than over the
interface used for payment. The method and
means of this communication is at the
discretion of the issuer.
bit 3: 1 = Cloud Based Payment Credentials
bit 2: 1 = Biometric Cardholder Verification
Capable
– continues –

Name (Format;
Tag; Length;
Form Factor bit 1: RFU (0)

Indicator (FFI) Byte 3 (for FFI Version #1)
(continued) RFU ('00')
Byte 4: Payment Transaction Technology
bits 8-5: RFU (0000)
bits 4-1: Payment Transaction Technology
All values not currently defined are RFU.
0000 = Proximity: Contactless interface using
[ISO 14443] (including NFC)
0001 = Not used in VCPS
Go Online On Conditional Visa proprietary data element UC: Modifiable Set to 1 if the ‘Set Go Online On Next
Next Transaction If dual-interface indicating that subsequent VIS IU: CSU Transaction’ bit of the last verified CSU was set
Indicator card application transactions should request online to 1b.
R: N
F: – supporting Issuer processing. Reset to 0 if the ‘Set Go Online On Next
T: – Update This indicator is used in VIS, and is Transaction’ bit of the last verified CSU was set
Processing and not evaluated in determining VCPS to 0b.
L: –
supporting transaction dispositions. The "Go
S: Card CVN18 or CVN'22' Online On Next Transaction
D: Shared Indicator" is included in this
specification as it may be set and
reset during Issuer Update
Processing.

Name (Format;
Tag; Length;
Integrated Conditional Private key part of the ICC public UC: Unchanging The card shall implement support for ICC key
Circuit Card (ICC) If fDDA supported key pair used for fast dynamic data IU: N sizes up to and including 1408-bits. Card
Private Key authentication. support for larger ICC key sizes is at
R: N
F: b This data element may take various implementer discretion.
T: – forms, such as a modulus and secret

exponent or Chinese Remainder Secret
L: NIC
Theorem coefficients.
S: Card
D: Shared
Integrated Conditional ICC Public Key certified by the UC: Modifiable

Circuit Card (ICC) If fDDA supported issuer. IU: UPDATE RECORD
Public Key It is strongly recommended that the R: READ RECORD
Certificate Certificate Expiration Date (from the
F: b ICC Public Key Certificate) match the
T: 9F46 Application Expiration Date.
L: NI
S: Card
D: E or S
Integrated Conditional ICC Public Key Exponent used for UC: Unchanging A value of '03' is recommended for performance
Circuit Card (ICC) If fDDA supported the verification of the Signed IU: N reasons.
Public Key Dynamic Application Data.
R: READ RECORD
Exponent
F: b
T: 9F47
L: 1 or 3
S: Card
D: E or S

Name (Format;
Tag; Length;
Integrated Conditional Digits of the ICC Public Key UC: Modifiable

Circuit Card (ICC) If fDDA supported Modulus which do not fit within the IU: UPDATE RECORD
Public Key and entire public ICC Public Key Certificate. R: READ RECORD
Remainder key does not fit
F: b into certificate
T: 9F48
L: NIC – NI + 42
S: Card
D: E or S
International Conditional Visa proprietary data template that UC: Dynamic The following context specific tags are defined
Counters Data If international contains Visa proprietary context IU: PUT DATA in this specification for the Counters Data
Template velocity checking specific tags for international Template:
R: GET DATA (SD)
F: b (using any of the counters and their associated limits. 'DF11' – CTCI
T: BF57 counters in this 'DF21' – CTCIL
template) is
L: var. 'DF31' – CTIUL
supported
S: Card
D: Shared
International Conditional Visa proprietary data element UC: Transient This indicator is a transient value, set or reset at
Transaction If domestic and indicating whether the transaction is IU: N the beginning of GPO processing.
Indicator international domestic or international, based on 1 = International transaction
R: N
F: – restrictions currency code, and may also take
0 = Domestic transaction
T: – supported into account the country code
L: – (configured by the issuer in Card
or
Additional Processes).
S: Card If domestic and
D: – international
velocity checks
supported

Name (Format;
Tag; Length;
Issuer Mandatory Contains proprietary application UC: See individual IAD If the Issuer Discretionary Data is personalized
Application Data data for transmission to the Issuer components with the Issuer Discretionary Data Identifier (IDD
F: b in an online transaction. IU: N/A ID) and IDD Length as described in Appendix E,
This version of VCPS supports the the application includes the IDD ID followed by
T: 9F10 R: GPO
following Issuer Application Data the values of the following data elements in the
L: var. up to 32 Issuer Discretionary Data (see Issuer
(IAD) formats:
S: Card Discretionary Data Identifier for defined values).
• IAD Format 0/1/3
D: E or S The Issuer Application Data for contactless must
• IAD Format 2
be the same as the Issuer Application Data for
Refer to Appendix M for a complete contact chip, except the CVN values may be
description of the IAD Formats. different to allow contactless to use a different
cryptogram version. However, both must use
the same IAD Format (that is, both use IAD
Format 0/1/3 or both use IAD Format 2).

Name (Format;
Tag; Length;
Issuer Optional Issuer data transmitted to card for N/A Note: For CVN18 and CVN'22', the optional
Authentication Passed from the Issuer Authentication. Proprietary Authentication Data is only
Data issuer through The Issuer Authentication Data supported for Field 55 issuers. The use of
F: b 64-128 the reader consists of the following for Proprietary Authentication Data is beyond the
Cryptogram Version scope of this specification.
T: 91
Number 10 ('0A') and Cryptogram Note: For CVN18 and CVN'22', third bit map
L: 8-16
Version Number 17 ('11'): issuers may send the 2-byte ARPC Response
S: Issuer Code (following the CSU) as part of Issuer
• ARPC – first 8 bytes
D: – Authentication Data sent in the online response,
• ARPC Response Code – 2 bytes
but the ‘Proprietary Authentication Data
immediately following ARPC
included’ bit of the CSU shall be set to 0b, and
the ARPC Response Code shall not be processed
The Issuer Authentication Data as optional Proprietary Authentication Data
consists of the following for when generating the ARPC.
Cryptogram Version Number 18
('12') and Cryptogram Version
Number '22' ('22'):
• ARPC – first 4 bytes
• CSU – 4 bytes immediately
following ARPC
• optional Proprietary
Authentication Data – 1-8 bytes
immediately following CSU

Name (Format;
Tag; Length;
Issuer Conditional Visa proprietary data element UC: Persistent 1 = Issuer Authentication was performed and
Authentication If Issuer Update indicating that Issuer Authentication IU: N failed
Failure Indicator Processing was performed and failed.
R: N
F: – supported
T: –
L: –
S: Card
D: Shared
Issuer Code Table Conditional Indicates the code table according UC: Unchanging Values are:
Index If Application to [ISO 8859] for displaying the IU: N 01 = [ISO 8859], Part 1
F: n 2 Preferred Name is Application Preferred Name. R: SELECT 02 = [ISO 8859], Part 2
T: 9F11 personalized
03 = [ISO 8859], Part 3
L: 1 04 = [ISO 8859], Part 4
S: Card 05 = [ISO 8859], Part 5
D: E or S 06 = [ISO 8859], Part 6
07 = [ISO 8859], Part 7
08 = [ISO 8859], Part 8
09 = [ISO 8859], Part 9
10 = [ISO 8859], Part 10
Issuer Country Conditional Indicates the country of the issuer, UC: Unchanging Shall match the value of tag '9F57'.
Code If Application represented according to [ISO IU: N
F: n 3 Usage Control is 3166].
R: READ RECORD
T: 5F28 supported
L: 2
S: Card
D: E or S

Name (Format;
Tag; Length;
Issuer Country Conditional Visa proprietary data element UC: Unchanging Shall match the value of tag '5F28'.
Code If country code indicating the country of the issuer, IU: N
F: n 3 restrictions represented according to
R: GET DATA (SD)
supported [ISO 3166].
T: 9F57
L: 2
S: Card
D: Shared

Name (Format;
Tag; Length;
Issuer Optional Visa proprietary data element UC: Transient (bit 8) Bit 8 is a dynamic value and initialized to a value
Discretionary indicating the format of the Modifiable (bits 7-1) of 0b at the beginning of GPO processing.
Data Identifier optional issuer discretionary data bit 8: 1 = Indication to the issuer that card and
IU: N/A
(IDD ID) transmitted in the Issuer Application reader support Issuer Update Processing
Data. R: GPO
F: b 8 bits 7-5: RFU (000)
T: part of 9F10 See Appendix E for additional
bits 4-1: IDD Option ID: Identifies the contents
information on usage of the IDD ID.
L: 1 in the remaining bytes of issuer discretionary
Note: IAD Format 2 only supports data:
S: Card
IDD ID Option '0'.
D: Shared '0' = Issuer-defined static data
'1' = VLP Available Funds
Note: IDD Option ID '1' will not be supported
in future versions of the specification. Issuers
should instead use IDD Option ID '3'.
'2' = CTTA
Note: IDD Option ID '2' will not be supported
in future versions of the specification. Issuers
should instead use IDD Option ID '4'.
'3' = VLP Available Funds followed by CTTA
'4' = CTTA followed by CTTAL
'5' = AOSA
'6' = AOSA followed by Last Successful Issuer
Update ATC Register followed by Issuer Script
Command Counter
'7'-'F' = RFU

Name (Format;
Tag; Length;
Issuer Public Key Conditional Issuer’s public key certified by a UC: Modifiable
Certificate If Offline Data certificate authority for use in offline IU: UPDATE RECORD
F: b Authentication data authentication.
R: READ RECORD
T: 90 supported
L: NCA
S: Card
D: E or S
Issuer Public Key Conditional Issuer public key exponent used for UC: Unchanging A value of '03' is recommended for performance
Exponent If Offline Data the verification of the ICC Public Key IU: N reasons.
F: b Authentication Certificate.
R: READ RECORD
T: 9F32 supported
L: 1 or 3
S: Card
D: E or S
Issuer Public Key Conditional Portion of the Issuer Public Key UC: Modifiable
Remainder If Offline Data Modulus which does not fit into the IU: UPDATE RECORD
F: b Authentication Issuer PK Certificate.
R: READ RECORD
T: 92 supported and
entire public key
L: NI – NCA + 36
does not fit into
S: Card certificate
D: E or S

Name (Format;
Tag; Length;
Issuer Script Conditional Visa proprietary data element that UC: Persistent bits 4–1: Number of Issuer Script Commands
Command If Issuer Update indicates the number of Issuer IU: N processed.
Counter (ISCC) Processing Script Commands processed by the If the ISCC is not cyclic, then a value of 'F' is
R: GPO
F: b 4 supported card application. equivalent to 15 or more Issuer Script
T: – The ISCC may be configured to be a Commands. When the ISCC is not cyclic, the
cyclic counter by setting ‘Issuer card application either 1) increments the ISCC
L: –
Script Command Counter is cyclic’ upon receipt of an issuer script command
S: Card (ADA byte 3 bit 2 to 1b). If the ISCC containing secure messaging, or 2) increments
D: Shared is cyclic, then the ISCC is never the ISCC after successful performance of an
reset, and counts from 0 (0000b) to issuer script command.
15 (1111b), after which it cycles If the ISCC is cyclic, then incrementing the ISCC
back to 0 (0000b). when it has a value of 'F' cycles it back to '0'.
If issuer scripts commands are Ex. 'F' + 1 = '0'
supported, it is highly
When the ISCC is cyclic, the card application
recommended that the ISCC be
increments the ISCC after successful
configured as a cyclic counter and
performance of an issuer script command.
that only successful issuer script
commands are counted.
Issuer Script Conditional Visa proprietary data element that UC: Persistent 1 = Issuer Script processing failed on a previous
Failure Indicator If Issuer Update indicates whether Issuer Script IU: N transaction
F: – Processing processing failed on a previous
R: N
T: – supported transaction.
L: –
S: Card
D: Shared

Name (Format;
Tag; Length;
Issuer Script Optional May be sent in authorization N/A

Identifier From issuer to response from issuer when
F: b 32 reader. Not response contains Issuer Script.
passed to card. Assigned by the issuer to uniquely
T: 9F18
identify the Issuer Script.
L: 4
S: Issuer
D: –

Name (Format;
Tag; Length;
Issuer Script Conditional Indicates the results of Issuer Script N/A Byte 1(Issuer Script Result):
Results If Issuer Update processing. bits 8-5: Result of the Issuer Script processing
F: b Processing When the reader-terminal performed by the reader:
T: 9F5B supported transmits this data element to the '0' = Issuer Script not performed
acquirer, in this version of VCPS, it
L: var. '1' = Issuer Script processing failed
is acceptable that only byte 1 is
S: Reader transmitted, although it is '2' = Issuer Script processing successful
D: N/A preferable for all five bytes to be bits 4-1: Sequence number of the Issuer
transmitted. Script Command:
'0' = Not specified
'1'–'E' = Sequence number 1-14
'F' = Sequence number 15 or above
Bytes 2-5 (Issuer Script Identifier):
Issuer Script Identifier received by the reader,
if available; zero filled if not available.
Mandatory if more than one Issuer Script
Template was received by the reader-
terminal.
Bytes 1-5 are repeated for each Issuer Script
Template processed by the reader-terminal,
although in this version of VCPS, only one
Issuer Script Template may be transmitted in
the response message.

Name (Format;
Tag; Length;
Issuer Script Optional Contains proprietary issuer data for N/A [EMV] specifies that terminals and networks
Template 1 Passed from transmission to the card. must support a total length for all issuer scripts
F: b issuer through The format of the Issuer Script in an online response of up to 128 bytes.
reader Template is shown in [EMV] Book 3 Issuers may send longer issuer scripts only
T: 71
section 10.10. when the issuer knows that longer issuer
L: var. scripts are supported by all entities
S: Issuer transporting the script back to the card.
D: –
Issuer Script Optional Contains proprietary issuer data for N/A [EMV] specifies that terminals and networks
Template 2 Passed from transmission to the card. must support a total length for all issuer scripts
F: b issuer through The format of the Issuer Script in an online response of up to 128 bytes.
reader Template is shown in [EMV] Book 3 Issuers may send longer issuer scripts only
T: 72
section 10.10. when the issuer knows that longer issuer
L: var. scripts are supported by all entities
S: Issuer transporting the script back to the card.
D: –
Issuer Update Required Visa proprietary internal indicator UC: Transient This indicator is a transient value, reset at the
Processing used during qVSDC Card Action IU: N beginning of the transaction.
Indicator Analysis. Indicates that Issuer 1 = Issuer Update Processing supported by
R: N
F: – Update Processing supported by card and reader
T: – card and Issuer Update Processing
L: – supported by reader.
S: Card
D: –

Name (Format;
Tag; Length;
Language Optional 1-4 languages stored in order of UC: Unchanging

Preference preference, each represented by IU: N
F: an 2 2 lower case alphabetical characters
R: SELECT
according to [ISO 639].
T: 5F2D
L: 2-8
S: Card
D: E or S
Last Contactless Conditional Visa proprietary data element UC: Persistent

Application If Issuer Update containing the value of the IU: N
Cryptogram Processing Application Cryptogram generated
R: N
F: b 64 supported during the last VCPS transaction.
T: – This data element is not used in
VCPS transaction processing (i.e. is
L: 8
S: Card application) unless the application
D: Shared has been personalized to support
Last Contactless Conditional Visa proprietary data element UC: Persistent Initialized with a value of 0.
Application If Issuer Update indicating whether the Last IU: N 1 = Last Contactless Application Cryptogram
Cryptogram Processing Contactless Application Cryptogram valid
R: N
Valid Indicator supported is valid for Issuer Update Processing.
0 = Last Contactless Application Cryptogram
F: – This data element is not used in invalid
T: – VCPS transaction processing (i.e. is
L: – considered as not present in the
S: Card application) unless the application
D: Shared

Name (Format;
Tag; Length;
Last Online ATC Conditional ATC value of the last transaction UC: Persistent
Register If Issuer Update that went online and where issuer IU: N
F: b 16 Processing authentication was performed.
R: GET DATA (SD)
T: 9F13 supported
L: 2
S: Card
D: Shared
Last Successful Conditional Visa proprietary data element UC: Persistent Initialized to a value of zeroes.
Issuer Update If Issuer Update containing the ATC value from the IU: N
ATC Register Processing last successful Issuer Update (either
R: GPO (if included in the IDD
F: b 16 supported as a result of Issuer Authentication
as specified in Appendix E)
or issuer scripting).
T: –
L: 2
S: Card
D: Shared
Log Entry Conditional Data element indicating the UC: Unchanging Byte 1: SFI containing the cyclic transaction log
F: b If transaction location (SFI) and the maximum IU: N file.
logging number of transaction log records. Byte 2: Maximum number of records in the
T: 9F4D R: SELECT
supported transaction log file.
L: 2
Note: The value of maximum number of records
S: Card
in the transaction log file is at implementer
D: Shared discretion and ’00’ is not supported.

Name (Format;
Tag; Length;
Log Format Conditional List in tag and length format of UC: Unchanging
F: b If transaction data elements that are logged by IU: N
logging the transaction.
T: 9F4F R: GET DATA (SD)
supported
L: var.
S: Card
D: Shared
Matching Required Visa proprietary data element UC: Transient This indicator is a transient value, set or reset at
Currency indicating whether the transaction is IU: N the beginning of GPO processing.
Indicator matching currency or non-matching 1 = Matching currency transaction
R: N
F: – currency.
0 = Non-matching currency transaction
T: – Transactions are considered
L: – matching currency when the
S: Card Transaction Currency Code matches
the Application Currency Code, or
D: –
matches any of the supported
Conversion Currency Codes.
Merchant Name Required Indicates the name and location of N/A

and Location (at reader) the merchant. The reader shall
F: ans return the value of the Merchant
Name and Location when requested
T: 9F4E
by the card in a Data Object List.
L: var.
S: Reader
D: N/A

Name (Format;
Tag; Length;
Message Conditional Visa proprietary data element UC: Unchanging

Authentication If Issuer Update containing an 8-byte DEA key used IU: N
Code (MAC) DEA Processing to support Issuer Script processing,
R: N
Key A supported and to generate the MAC for Issuer
F: b 64 Discretionary Data Options.
or
T: – In the triple DES algorithm, the MAC Secret
Issuer
DEA Key A is used for encipherment
L: 8 Discretionary Data
and the MAC DEA Key B is used for
S: Card Options requiring
decipherment.
MAC'ing
D: Shared The derivation key methodology for
supported
[VIS] Appendix D.7.
Message Conditional Visa proprietary data element UC: Unchanging

Authentication If Issuer Update containing an 8-byte DEA key used IU: N
Code (MAC) DEA Processing to support Issuer Script processing,
R: N
Key B supported and to generate the MAC for Issuer
F: b 64 Discretionary Data Options.
or
T: – In the triple DES algorithm, the MAC Secret
Issuer
DEA Key A is used for encipherment
L: 8 Discretionary Data
and the MAC DEA Key B is used for
S: Card Options requiring
decipherment.
MAC'ing
D: Shared The derivation key methodology for
supported
[VIS] Appendix D.7.

Name (Format;
Tag; Length;
Offline Counter Optional Contains initial values for various UC: Unchanging In this version of the specification the length of
Initial Value counters to be set at IU: N the field is 1 byte, indicating the initial value of
F: b personalization time. the Consecutive Transaction Counter
R: GET DATA (SD)
In this version of the specification, International (CTCI).
T: 9F63
only the Consecutive Transaction Note: The Offline Counter Initial Value will not
L: var.
Counter International (CTCI) can be be supported in future versions of the
S: Card initialized during personalization. If specification. Issuers should instead use tag
D: Shared this tag is personalized, the CTCI will 'DF11' in 'Bf57' to initialize the value of the CTCI.
be set to the value indicated.
Online Preferred Required Visa proprietary internal indicator UC: Transient This indicator is a transient value, initialized to a
by Card Indicator used during qVSDC Card Action IU: N value of 0 at the beginning of GPO processing.
F: – Analysis. Indicates that the card
R: N
T: – prefers online processing for the
L: – transaction, but can continue
processing offline if online
S: Card
processing is unavailable.
D: –
Online Required Required Visa proprietary internal indicator UC: Transient This indicator is a transient value, reset at the
by Card Indicator used during qVSDC Card Action IU: N beginning of GPO processing.
F: – Analysis. Indicates that the card
R: N
T: – requires online processing for the
L: – transaction, and will decline offline
if online processing is unavailable.
S: Card
D: –

Name (Format;
Tag; Length;
Online Required Required Visa proprietary internal indicator N/A This indicator is a transient value, initialized to a
by Reader used during transaction processing value of 0 at the beginning of the transaction.
Indicator to indicate that internal reader
F: – processes have indicated that the
T: – transaction requires online
L: – processing.
S: Reader
D: N/A
Payment Optional Uniquely identifies the underlying UC: Unchanging See [EMV Tokenisation].
Account This data element cardholder account to which a IU: N
Reference (PAR) may be present payment token is associated, as
R: READ RECORD
T: 9F24 on cards that defined in [EMV Tokenisation].
S: Card have been

tokenized
D: E or S
* See [EMV
Tokenisation] for
format and length
information.
Personal Conditional Number of PIN tries remaining. UC: Dynamic

Identification If supporting Offline PIN is not supported for IU: CSU, PIN
Number (PIN) offline PIN for VCPS transactions. Data elements CHANGE/UNBLOCK
Try Counter contact chip supporting offline PIN are only R: GET DATA
F: b 8 listed in this appendix because they
T: 9F17 are checked or updated in this
L: 1 specification.
S: Card For additional information on offline
D: Shared PIN and it's associated data
elements, see [VIS].

Name (Format;
Tag; Length;
Personal Conditional Visa proprietary data element UC: Modifiable

Identification If supporting containing the issuer-specified IU: N/A
Number (PIN) offline PIN for maximum number of consecutive
R: N
Try Limit contact chip incorrect PIN tries allowed.
F: b 8 Offline PIN is not supported for
T: – VCPS transactions. Data elements
L: 1 supporting offline PIN are only
S: Card listed in this appendix because they
are checked or updated in this
D: Shared
specification.
For additional information on offline
PIN and it's associated data
elements, see [VIS].
Processing Mandatory List of terminal/reader-related data UC: Unchanging

Options Data objects (tags and lengths) requested IU: N
Object List by the card to be transmitted in the
R: SELECT
(PDOL) GET PROCESSING OPTIONS
F: b command.
T: 9F38
L: var.
S: Card
D: E or S

Name (Format;
Tag; Length;
Reader Conditional Indicates the contactless floor limit N/A

Contactless Floor If Pre-processing of the reader for Visa applications. If
Limit supported the transaction amount is greater
F: n 12 than the Reader Contactless Floor
Limit, then the reader requires
T: −
L: 6 transaction.
S: Reader
D: N/A
Reader Conditional Indicates the contactless transaction N/A

Contactless If Pre-processing limit of the reader for Visa
Transaction Limit supported applications.
F: n 12 If the transaction amount is greater
T: − than or equal to the Reader
Contactless Transaction Limit, then
L: 6
a Visa contactless transaction is not
S: Reader permitted.
D: N/A Switching the transaction over to
another interface is permitted.
Reader CVM Conditional Indicates the CVM limit of the N/A

Required Limit If Pre-processing reader for Visa applications.
F: n 12 supported If the transaction amount is greater
T: − than or equal to the Reader CVM
Required Limit, then the reader
L: 6
requires a CVM for the transaction.
S: Reader
D: N/A

Name (Format;
Tag; Length;
Response Required Contains the data objects (with UC: Transient

Message tags and lengths) returned by the IU: N
Template card in response to a command.
R: GPO
Format 2
F: var.
T: 77
L: var.
S: Card
D: –
Short File Conditional Used in the commands related to UC: Unchanging Values are:
Identifier If returning an application elementary file (AEF) IU: N 1–10: Governed by joint payment systems
F: b 8 record data for to identify the file. The SFI data
R: N/A 11–20: Payment system specific
the transaction object is a binary field with the
T: 88 21–30: Issuer specific
three high-order bits set to zero.
L: 1
S: Card
D: –
Signed Dynamic Conditional Dynamic signature generated by the UC: Transient

Application Data If fDDA supported card and validated by the reader IU: N
(SDAD) during fDDA processing.
R: GPO, READ RECORD
F: b The SDAD is issuer configurable to
T: 9F4B be returned in either the GPO
response or in a record. Issuers
L: NIC
should consider whether there is
S: Card sufficient space in the GPO
D: Exclusive response to accommodate the
SDAD and personalize accordingly.

Name (Format;
Tag; Length;
Signed Static Conditional Static signature generated from UC: Modifiable The calculation of the Signed Static Application
Application Data If ODA for Online critical card data elements and IU: UPDATE RECORD Data is as specified in [EMV] Book 2, with the
F: b Authorizations is personalized on the card. following exception:
R: READ RECORD
T: 93 supported and This variant of the Signed Static • The Signed Data Format to be signed shall
card is not Application Data is not returned by have a value of '93' (instead of '03'). See
L: NI
capable of the card when used at readers [EMV] Book 2 Table 3.
S: Card performing fDDA compliant to this specification, and
D: Exclusive SDA is neither performed nor
Use of a Signed Data Format with value '93'
supported by readers compliant to
prevents the Signed Static Application Data
this specification. The card
from being used in standard POS acceptance
functionality is included in this
environments.
specification only to allow for its
potential use in special acceptance
environments.
Cards that are not capable of
performing fDDA, but support
Offline Data Authentication for
Online Authorizations, use SDA and
this variant of the Signed Static
Application Data.
Static Data Optional Contains list of tags of primitive UC: Unchanging The SDA Tag List may not contain tags other
Authentication data objects whose value fields are IU: N than the tag for Application Interchange Profile
(SDA) Tag List to be included in the ICC Public (AIP).
R: READ RECORD
F: – Key Certificate hash result.
T: 9F4A
L: var.
S: Card
D: E or S

Name (Format;
Tag; Length;
Switch Interface Required Visa proprietary internal indicator UC: Transient This indicator is a transient value, initialized to a
Required by Card used during qVSDC Card Action IU: N value of 0 at the beginning of GPO processing.
Indicator Analysis. Indicates that the card
R: N
F: – requires the transaction be
T: – performed over another interface.
L: –
S: Card
D: –
Terminal Country Required Indicates the country of the terminal N/A

Code represented according to
F: n 3 [ISO 3166].
T: 9F1A
L: 2
S: Reader
D: N/A
Terminal Floor Conditional Indicates the floor limit in the N/A

Limit If Pre-processing terminal.
F: b 32 supported and
T: 9F1B Reader
Contactless Floor
L: 4
Limit is not
S: Reader present
D: N/A

Name (Format;
Tag; Length;
Terminal Required Indicates reader capabilities, N/A Byte 1

Transaction requirements, and preferences to bit 8: 1 = MSD supported
Qualifiers (TTQ) the card.
bit 7: RFU (0)
F: b 32 TTQ byte 2 bits 8-7 are transient
bit 6: 1 = qVSDC supported
T: 9F66 values, and reset to zero at the
beginning of the transaction. All bit 5: 1 = EMV contact chip supported
L: 4
other TTQ bits are static values, and bit 4: 1 = Offline-only reader
S: Reader not modified based on transaction bit 3: 1 = Online PIN supported
D: N/A conditions.
bit 2: 1 = Signature supported
TTQ byte 3 bit 7 shall be set by the
bit 1: 1 = Offline Data Authentication (ODA)
acquirer-merchant to 1b.
for Online Authorizations supported.
Note: Readers compliant to this specification
set TTQ byte 1 bit 1 to 0b.
Byte 2
bit 8: 1 = Online cryptogram required
Note: A qVSDC online-only reader must have
TTQ byte 2 bit 8 set to 1b. It may be coded to
1b or set as a result of device configuration
parameters.
bit 7: 1 = CVM required
bit 6: 1 = (Contact Chip) Offline PIN supported
bits 5-1: RFU (00000)
– continues –

Name (Format;
Tag; Length;
Terminal Byte 3
Transaction bit 8: 1 = Issuer Update Processing supported
Qualifiers (TTQ)
bit 7: 1 = Mobile functionality supported
(continued) (Consumer Device CVM)
bits 6-1: RFU (000000)
Note: Readers compliant to this specification
set TTQ byte 3 bit 7 to 1b.
Byte 4
RFU ('00')
Terminal Required Status of the different functions as N/A Byte 1: Not used for VCPS ('00')
Verification seen from the reader/terminal. Byte 2: Not used for VCPS ('00')
Results (TVR) For qVSDC transactions, all of the Byte 3: Not used for VCPS ('00')
F: b 40 TVR bits sent online to the acquirer
Byte 4: Not used for VCPS ('00')
T: 95 shall be set to 0b.
Byte 5: Not used for VCPS ('00')
L: 5
S: Reader
D: N/A

Name (Format;
Tag; Length;
Track 2 Mandatory Contains the data elements of the UC: Modifiable *

Equivalent Data track 2 according to the [ISO 7813], IU: UPDATE RECORD
F: b excluding start sentinel, end
R: GPO, READ RECORD
sentinel, and LRC, as follows:
T: 57
• Primary Account Number: n, 12
L: var. up to 19
to 19
S: Card
• Field Separator ('D'): b
D: E or S • Expiration Date (YYMM): n 4
• Service Code: n 3
• PIN Verification Field (optional):
n5
• Discretionary Data
• Pad with 'F' if needed to ensure
whole bytes.
Transaction Required Indicates the currency code of the N/A
Currency Code transaction according to [ISO 4217].
F: n 3 The implied exponent is indicated
by the minor unit of currency
T: 5F2A
associated with the Transaction
L: 2 Currency Code in [ISO 4217].
S: Reader
D: N/A
Transaction Date Required Local date that the transaction was N/A
F: n 6 YYMMDD authorized.
T: 9A
L: 3
S: Reader
D: N/A

Name (Format;
Tag; Length;
Transaction Type Required Indicates the type of financial N/A

F: n 2 transaction, represented by the
values of the first two digits of
T: 9C
Processing Code as defined by Visa.
L: 1
S: Reader
D: N/A
Unique DEA Key Required Proprietary Visa data element UC: Unchanging
A containing an 8-byte DEA key used IU: N
F: b 64 for Online Card Authentication,
R: N
Online Issuer Authentication, and
T: –
AC generation.
L: 8 Secret
In triple DES, the Unique DEA Key A
S: Card is used for encipherment and the
D: Shared Unique DEA Key B is used for
decipherment.
[VIS] Appendix D.7.

Name (Format;
Tag; Length;
Unique DEA Key Required Proprietary Visa data element UC: Unchanging
B containing an 8-byte DEA key used IU: N
F: b 64 for Online Card Authentication,
R: N
Online Issuer Authentication, and
T: –
AC generation.
L: 8 Secret
In triple DES, the Unique DEA Key A
S: Card is used for encipherment and the
D: Shared Unique DEA Key B is used for
decipherment.
[VIS] Appendix D.7.
Unpredictable Conditional Contains the card unpredictable UC: Transient

Number (Card) If fDDA supported number generated by the card and IU: N
F: b 32 signed for fDDA.
R: READ RECORD
T: part of 9F69 The Unpredictable Number (Card) is
generated during GPO processing
L: 4
and returned in the last record as
S: Card part of the Card Authentication
D: – Related Data.
Unpredictable Required Value to provide variability and N/A

Number (Reader- uniqueness to the generation of the
Terminal) application cryptogram.
F: b 32
T: 9F37
L: 4
S: Reader
D: N/A

Name (Format;
Tag; Length;
VLP Available Conditional Visa proprietary data element that UC: Dynamic Initialized to a value of zeros.
Funds If Low Value provides a counter that is IU: CSU, PUT DATA Issuers may personalize the VLP Available Funds
F: n 12 Check supported decremented by the transaction with another initial value.
R: GET DATA (SD), GPO (if
amount for qVSDC offline approval
T: 9F79 and DF51 or included in the IDD as specified
requests.
in BF55 If Low Value AND in Appendix E)
This data element is not used in
L: 6 CTTA Check
VCPS transaction processing (i.e. is
S: Card supported
D: Shared application) unless one of the low
value checks is supported.
VLP Funds Limit Conditional Visa proprietary data element that UC: Modifiable
F: n 12 If Low Value provides the issuer limit for the VLP IU: PUT DATA
Check supported Available Funds, and is the value to
T: 9F77 and DF71 R: GET DATA (SD)
which the VLP Available Funds is
in BF55 or
reset.
L: 6 If Low Value AND
S: Card CTTA Check
supported
D: Shared
VLP Reset Optional Visa proprietary data element UC: Modifiable

Threshold specifying the minimum value to IU: PUT DATA
F: n 12 which the VLP Available Funds is
R: GET DATA (SD)
allowed to be decremented before
T: 9F6D and DF61
the card requests online processing.
in BF55
L: 6
S: Card
D: Shared

Name (Format;
Tag; Length;
VLP Single Optional Visa proprietary data element UC: Modifiable

Transaction Limit indicating the maximum amount IU: PUT DATA
F: n 12 allowed for a single qVSDC offline
R: GET DATA (SD)
transaction.
T: 9F78 and DF41
in BF55
L: 6
S: Card
D: –

D.2 Data Element Tags
Table D–2: Data Element Tags
Template Tag Data Element Source
4F Application Identifier (ADF Name) Card
50 Application Label Card
57 Track 2 Equivalent Data Card
5A Application Primary Account Number (PAN) Card
5F20 Cardholder Name Card
5F24 Application Expiration Date Card
5F28 Issuer Country Code Card
5F2A Transaction Currency Code Reader
5F2D Language Preference Card
5F34 Application Primary Account Number Sequence Number Card

(PSN)
61 Directory Entry Card
6F File Control Information (FCI) Template Card
71 Issuer Script Template 1 Issuer
72 Issuer Script Template 2 Issuer
77 Response Message Template Format 2 Card
82 Application Interchange Profile (AIP) Card
83 Command Template Reader
84 Dedicated File (DF) Name Card
87 Application Priority Indicator Card
88 Short File Identifier Card
89 Authorization Code Issuer
8A Authorization Response Code (ARC) Issuer/Reader
8F Certificate Authority Public Key Index (PKI) Card
90 Issuer Public Key Certificate Card
91 Issuer Authentication Data Issuer
92 Issuer Public Key Remainder Card
93 Signed Static Application Data (SAD) Card

94 Application File Locator (AFL) Card
95 Terminal Verification Results (TVR) Reader
9A Transaction Date Reader
9C Transaction Type Reader
9F02 Amount, Authorized (Numeric) Reader
9F03 Amount, Other (Numeric) Reader
9F06 Application Identifier (AID) Reader
9F07 Application Usage Control (AUC) Card
9F0A Application Selection Registered Proprietary Data Card

(ASRPD)
9F10 Issuer Application Data Card
part of 9F10 Card Verification Results (CVR) Card
part of 9F10 Cryptogram Version Number Card
part of 9F10 Derivation Key Index (DKI) Card
part of 9F10 Issuer Discretionary Data Identifier (IDD ID) Card
9F11 Issuer Code Table Index Card
9F12 Application Preferred Name Card
9F13 Last Online ATC Register Card
9F17 PIN Try Counter Card
9F18 Issuer Script Identifier Issuer
9F1A Terminal Country Code Reader
9F1B Terminal Floor Limit Reader
9F22 Certificate Authority Public Key Index (PKI) Reader
9F24 Payment Account Reference (PAR) Card
9F26 Application Cryptogram Card
9F27 Cryptogram Information Data (CID) Card
9F32 Issuer Public Key Exponent Card
9F36 Application Transaction Counter (ATC) Card
9F37 Unpredictable Number (Reader-Terminal) Reader
9F38 Processing Options Data Object List (PDOL) Card
9F46 Integrated Circuit Card (ICC) Public Key Certificate Card
9F47 Integrated Circuit Card (ICC) Public Key Exponent Card

9F48 Integrated Circuit Card (ICC) Public Key Remainder Card
9F4A Static Data Authentication (SDA) Tag List Card
9F4B Signed Dynamic Application Data (SDAD) Card
9F4D Log Entry Card
9F4E Merchant Name and Location Reader
9F4F Log Format Card
9F51 Application Currency Code Card
9F52 Application Default Action (ADA) Card
9F53 Consecutive Transaction Counter International Limit Card

(CTCIL)
9F54 Cumulative Total Transaction Amount Limit (CTTAL) Card
9F57 Issuer Country Code Card
9F58 Consecutive Transaction Counter Limit (CTCL) Card
9F59 Consecutive Transaction Counter Upper Limit (CTCUL) Card
9F5A Application Program Identifier (Program ID) Card
9F5B Issuer Script Results Reader
9F5C Cumulative Total Transaction Amount Upper Limit Card

(CTTAUL)
9F5D Available Offline Spending Amount (AOSA) Card
9F5E Consecutive Transaction International Upper Limit Card

(CTIUL)
9F63 Offline Counter Initial Value Card
9F66 Terminal Transaction Qualifiers (TTQ) Reader
9F68 Card Additional Processes Card
9F69 Card Authentication Related Data Card
part of 9F69 fDDA Version Number Card
part of 9F69 Unpredictable Number (Card) Card
9F6B Card CVM Limit Card
9F6C Card Transaction Qualifiers (CTQ) Card
9F6D VLP Reset Threshold Card
9F6E Form Factor Indicator (FFI) Card
9F73 Currency Conversion Parameters Card
part of 9F73 Conversion Currency Code Card

part of 9F73 Currency Conversion Factor Card
9F77 VLP Funds Limit Card
9F78 VLP Single Transaction Limit Card
9F79 VLP Available Funds Card
9F7C Customer Exclusive Data (CED) Card
A5 File Control Information (FCI) Proprietary Template Card
BF0C File Control Information (FCI) Issuer Discretionary Data Card
BF55 Contactless Counters Data Template Card
BF55 DF11 Contactless Transaction Counter (CLTC) Card
BF55 DF21 Contactless Transaction Counter Lower Limit (CLTCLL) Card
BF55 DF31 Contactless Transaction Counter Upper Limit (CLTCUL) Card
BF55 DF41 VLP Single Transaction Limit Card
BF55 DF51 VLP Available Funds Card
BF55 DF61 VLP Reset Threshold Card
BF55 DF71 VLP Funds Limit Card
BF56 Counters Data Template Card
BF56 DF11 Consecutive Transaction Counter (CTC) Card
BF56 DF21 Consecutive Transaction Counter Limit (CTCL) Card
BF56 DF31 Consecutive Transaction Counter Upper Limit (CTCUL) Card
BF57 International Counters Data Template Card
BF57 DF11 Consecutive Transaction Counter International (CTCI) Card
BF57 DF21 Consecutive Transaction Counter International Limit Card

(CTCIL)
BF57 DF31 Consecutive Transaction International Upper Limit Card

(CTIUL)
BF58 Amounts Data Template Card
BF58 DF11 Cumulative Total Transaction Amount (CTTA) Card
BF58 DF21 Cumulative Total Transaction Amount Limit (CTTAL) Card
BF58 DF31 Cumulative Total Transaction Amount Upper Limit Card

(CTTAUL)
BF5B Application Internal Data Template Card
BF5B DF01 Application Capabilities Card

E Issuer Discretionary Data Options

Implementation-Conditional: Each of the Issuer Discretionary Data Options shall be
implemented based on the following conditions:
• Support for Issuer Discretionary Data Option '0' shall be implemented.
• Support for Issuer Discretionary Data Options '1' through '5' shall be implemented if offline
qVSDC is implemented. IDD Options '1' through '5' are supported for use only with IAD
Format 0/1/3, and not for use with IAD Format 2.
• Support for Issuer Discretionary Data Option '6' shall be implemented if Issuer Update
Processing is implemented. IDD Options '6' is supported for use only with IAD Format 0/1/3,
and not for use with IAD Format 2.
Issuer-Optional: If implemented, use of the Issuer Discretionary Data Options is at issuer

discretion.
E.1 Issuer Discretionary Data Options
In order to permit issuers to more closely track funds at the host, an issuer option was
introduced to allow placement of specific data into the Issuer Discretionary Data portion of the
Issuer Application Data (tag '9F10'). If personalized, the Issuer Discretionary Data is returned as
part of the Issuer Application Data (whenever the Issuer Application Data is returned).
With the exception of the static data option (IDD Option '0'), the IDD Options defined in this
specification include a MAC generated as described in Appendix E.3 to ensure data integrity.
Note: The IDD data is also included in clearing messages for offline approvals.
E.2 Personalization for IDD
Issuer Discretionary Data (IDD), if present, shall be returned following the Visa Discretionary
Data in the Issuer Application Data (tag '9F10').
The Issuer Discretionary Data (IDD) returned varies depending on the option chosen during
personalization as described in Table E–1.

Table E–1: IDD Options
IDD Option Length IDDO ID Amount Field(s) MAC
Issuer-specified 1 to 15 '0' Issuer-specified constant data none

constant data bytes
VLP Available Funds 10 bytes '1' • Value of VLP Available Funds (5 low-order bytes) 4 bytes
Note: IDDO ID '1' will not be supported in future
versions of the specification. Issuers should instead
use IDDO ID '3' or '5'.
Cumulative Total 10 bytes '2' • Value of CTTA (5 low-order bytes) 4 bytes

Transaction Amount Note: IDDO ID '2' will not be supported in future
(CTTA) versions of the specification. Issuers should instead
use IDDO ID '3' or '4'.
VLP Available Funds 15 bytes '3' • Value of VLP Available Funds 4 bytes
and CTTA (5 low-order bytes)
• Value of CTTA (5 low-order bytes)
CTTA and Cumulative 15 bytes '4' • Value of CTTA (5 low-order bytes) 4 bytes
Total Transaction • Value of CTTAL (5 low-order bytes)
Amount Limit (CTTAL)
Available Offline 10 bytes '5' • Value of AOSA (5 low-order bytes) 4 bytes

Spending Amount
(AOSA)
AOSA and Last 14 bytes '6' • Value of AOSA (6 bytes) 4 bytes

Successful Issuer • Value of Last Successful Issuer Update ATC
Update ATC Register Register (2 bytes)
and Issuer Script • Value of Issuer Script Command Counter
Command Counter (1 byte)
Note: The Issuer Script Command Counter used in
IDDO ID '6' is right-justified and left padded
with 0000b to ensure a whole byte.
Note: The IDD Option ID is specified using the low order nibble of the IDD ID byte. The high
order nibble of the IDD ID byte is reserved for other uses. For additional information, see the
“Issuer Discretionary Data Identifier” entry in Table D–1.
The IDD Option ID value is used to choose the type of data to be returned in the Issuer
Discretionary Data field. By default, Issuer Discretionary Data will not be returned. If the issuer
wants to receive Issuer Discretionary Data, the above length byte and identifier byte should be
appended to the tag '9F10' personalization value (following the Visa Discretionary Data).
For example, '0A02' would indicate that a 10-byte IDD should be returned in the Issuer
Application Data, containing the Identifier ('02'), Cumulative Total Transaction Amount (CTTA),
and MAC.

E.3 MAC Calculation
The data to be MACed is the 2-byte Application Transaction Counter (ATC), followed by the
amount fields and padding characters, constructed as follows:
Table E–2: MAC Calculation
IDD
Option Length of
ID Data Block Elements
'1' 8 bytes ATC 2 bytes
VLP Available Funds 5 low-order bytes
padding 1 byte
Cumulative Total Transaction Amount (CTTA) 5 low-order bytes

padding 1 byte
VLP Available Funds 5 low-order bytes

padding 4 bytes
Cumulative Total Transaction Amount Limit (CTTAL) 5 low-order bytes
padding 4 bytes

Available Offline Spending Amount 5 low-order bytes
padding 1 byte
IDD ID 1 byte
AOSA 6 bytes
Last Successful Issuer Update ATC Register 2 bytes
Issuer Script Command Counter 1 byte
padding 4 bytes
The 4-byte MAC is generated using a session key derived from the MAC UDK using the first
method defined in [VIS] Appendix B.4. Computation of the MAC is as illustrated in [VIS] Figure
B-1.

E.4 Padding for IDD MAC Generation
There are two padding methods supported for generation of the IDD MAC.
The first method is similar to the padding method used for CVN 10. This is referred to as the
padding method ‘00’, which adds as many bytes of ‘00’ as necessary to obtain a data block
with a length divisible by eight (see [VIS] Appendix D.3.2, step 3).
The second method is referred to as the padding method ‘80’, which adds one mandatory ‘80’
byte at the end of the data block and as many bytes of ‘00’ as necessary to obtain a data block
with a length divisible by eight. The method is identical to the padding method for [VIS] Secure
Messaging for Integrity and Authentication, as described in [VIS] Appendix B.2.4, step 4.
In order for the card to recognize the padding method chosen by the issuer, the Application
Default Action indicates the padding method to be used when generating the MAC for
inclusion in the Issuer Discretionary Data as follows:
• If ‘Padding method '80'’ is supported (ADA byte 4 bit 5 is 1b), then padding method '80'
shall be used.
• If ‘Padding method '80'’ is not supported (ADA byte 4 bit 5 is 0b), then padding method '00'
shall be used.
E.5 Issuer Application Data Personalization Example
Visa Discretionary Data (Mandatory)
Length: '06'
Value: '010A03000000' (assuming CVN 10)

Issuer Discretionary Data
Length: '0A' (expected amount length when Issuer Application Data

returned)
Value: '02' (ID to request Cumulative Total Transaction Amount

(CTTA))
The TLV for the above example would be as follows:
'9F 10 09
06 01 0A 03000000
0A 02'

The application uses the personalized IDD length and ID ('0A 02') as an indicator to activate
code to supply the Cumulative Total Transaction Amount (CTTA) in the Issuer Discretionary
Data when returning the Issuer Application Data. The personalized length includes the MAC.
When the card responds with Issuer Application Data containing the IDD (with the CTTA value
= '112233445566', and the MAC = '1A2B3C4D'), the TLV for this example would be:
Tag: '9F10'
Length: '12'
Value: '06010A030000000A0222334455661A2B3C4D'

<This appendix has been deleted>
F <This appendix has been deleted>

G Commands and Secure Messaging
G.1 GET DATA Command-Response APDUs
The GET DATA command is used to retrieve primitive and constructed data objects not
encapsulated in a record within the current application. Although this command is not issued
by readers as part of a VCPS transaction, the card application supports this command to
retrieve the data elements listed in Appendix D.1.
The GET DATA command shall be supported as described in [VIS] Appendix C.8, with the
following exception(s):
• [VIS] Appendix C.8.2, differentiating card data retrievable at Special Devices and for financial
transactions, need not be supported. VCPS data objects retrievable by the GET DATA
command are indicated as such in Appendix D.1, regardless of whether the GET DATA is
occurring at a Special Device or for a financial transaction.
G.2 GET PROCESSING OPTIONS (GPO) Command-Response

APDUs
The GET PROCESSING OPTIONS command initiates the transaction within the card application.
As the GET PROCESSING OPTIONS command signals the beginning of a transaction to the
card, the card resets transient data to zero when the command is received.
The GET PROCESSING OPTIONS command shall be supported as described in [VIS] Appendix
C.9, with the following exception(s):
• Data retrievable using the GET PROCESSING OPTIONS command is not as defined in [VIS]
Table C-4.
• The data field returned in the response to the GET PROCESSING OPTIONS command shall
be according to [EMV] Format 2. The AFL is not always included, and the data field may
include additional BER-TLV coded data elements. Inclusion of the AFL is conditional on card
application processing.
Note: For reader vendors without access to [VIS], support for the GET PROCESSING OPTIONS
command is also described in [EMV] section 6.5.8. The exceptions mentioned above also apply to
readers.
Card application processing of the GPO command shall be performed as described in

section 6.4.

The card application consists of three possible (and potentially distinct) GPO responses for
VCPS:
• qVSDC Offline GPO Response (if offline implemented): see Table 6–2 using Condition
column "Offline (with ODA)"
• qVSDC Online with ODA GPO Response: see Table 6–2 using Condition column "Online
(with ODA)"
• qVSDC Online/Decline without ODA GPO Response: see Table 6–2 using Condition column
"Online and Decline (without ODA)"
Note: The qVSDC Online with ODA GPO Response is not returned by the card when used at
readers compliant to this specification. The acceptance environment(s) where those GPO
responses may be returned are outside the scope of this specification. For dual-interface cards,
the GPO response for contact chip transactions is outside the scope of this specification
Req G.1 (GPO Responses)
The card application shall support personalization of each GPO response to return, or not
return, the data elements specified for each GPO response (as shown in the corresponding
tables for each GPO response).
Issuers are required to personalize the data elements to be returned in the GPO response as
required by this specification, but this shall not be enforced by the card application.
Req G.2 (Data Elements in GPO Responses)
A data element may have a different value for each GPO response. The card application shall
support personalization of data elements in a GPO response independently of their
corresponding values in any other GPO response.
For example, the Application File Locator (tag '94') in each GPO response may be
personalized with a different value.
The following data element is an exception to the above requirement:
• Issuer Application Data (tag '9F10') – The IAD value personalized shall be the same for
each GPO response.
Req G.3 (Additional Data Elements in GPO Responses)
In addition to the data elements explicitly defined for each GPO response, the card
application shall support the personalization of additional data elements to be returned in
each GPO response. The additional data elements shall be BER-TLV coded.

Note: The functionality specified by this requirement is reserved for possible payment system
use. Issuers shall only personalize the data elements that are explicitly permitted for each GPO
response.
G.3 READ RECORD Command-Response APDUs
The READ RECORD command reads a file record in a linear file.
The READ RECORD command shall be supported as described in [VIS] Appendix C.13, with the
• Records for application selection, as specified in [EMV] Book 1 section 11.2, need not be
supported.
Note: For reader vendors without access to [VIS], support for the READ RECORD command is
also described in [EMV] Book 3 section 6.5.11. The exceptions mentioned above also apply to
readers.
G.4 SELECT Command-Response APDUs
The SELECT command is used to select an application on the card corresponding to the
submitted file name or AID.
The SELECT command shall be supported as described in [VIS] Appendix C.14, with the
• The selection of an application is described in section 5.5 Application Selection of this
specification.
• PPSE is used in place of the PSE. Table G–1 defines the FCI returned by a successful
selection of the PPSE.
Note: For reader vendors without access to [VIS], support for the SELECT command is also
described in [EMV] Book 1 section 11.3. The exceptions mentioned above also apply to readers.
If any of the templates in the SELECT response contain BER-TLV data elements in addition to
the data elements explicitly defined, the reader shall be able to parse the SELECT response.
Unrecognized data elements for Application Selection are not stored by the reader.

Table G–1: SELECT Response Message Data Field (FCI) of the PPSE
Tag Value Length Presence
'6F' FCI Template var. M
'84' DF Name ('2PAY.SYS.DDF01') '0E' M
'A5' FCI Proprietary Template var. M
'BF0C' FCI Issuer Discretionary Data var. M
'61' Directory Entry var. M
'4F' ADF Name (AID) '05'–'10' M
'50' Application Label '01'–'10' O
'87' Application Priority '01' C1

Indicator
'9F0A' Application Selection var. O

Registered Proprietary Data
'61' Directory Entry var. O
'4F' ADF Name (AID) '05'–'10' C2
'87' Application Priority '01'

C1 and 2
Indicator

'61' Directory Entry var. O
'4F' ADF Name (AID) '05'–'10' C2
'87' Application Priority '01' C1 and 2

Indicator

1 If more than one contactless application is personalized on the card, then an Application Priority Indicator shall be
personalized for each application.
2 Personalized if the corresponding Directory Entry is present.

Table G–2: SELECT Response Status Word
SW1 SW2 Type Condition
'6283' Warning Application blocked
'6A81' Error Card blocked
'6A82' Error Selected file not found
'9000' Normal Successful processing
G.5 ISSUER UPDATE COMMANDS
Implementation-Conditional: Issuer Update commands shall be supported if Issuer Update

Processing is supported.
G.5.1 APPLICATION BLOCK Command-Response APDUs (Issuer Script

Command)
The APPLICATION BLOCK command is a post-issuance command that invalidates the currently
selected application.
The APPLICATION BLOCK command shall be supported as described in [VIS] Appendix C.2,
with the following exception(s):
• Processing of the GENERATE AC command is outside the scope of this specification.
• Following the successful completion of an APPLICATION BLOCK command (either through
Issuer Update Processing or through a [VIS] transaction), an invalidated application shall
return an Application Authentication Cryptogram (AAC) cryptogram type when an
Application Cryptogram is returned in the GPO response.
G.5.2 APPLICATION UNBLOCK Command-Response APDUs (Issuer Script

Command)
The APPLICATIN UNBLOCK command is a post-issuance command that reverses the

Application Block status.
The APPLICATION UNBLOCK command shall be supported as described in [VIS] Appendix C.3.
G.5.3 CARD BLOCK Command-Response APDUs (Issuer Script Command)
The CARD BLOCK command is a post-issuance command that permanently disables all
applications in the card.

The CARD BLOCK command shall be supported as described in [VIS] Appendix C.4.
G.5.4 EXTERNAL AUTHENTICATE Command-Response APDUs
The EXTERNAL AUTHENTICATE command performs Issuer Authentication (by verifying a

cryptogram) and conditionally resets card counters and indicators.
The EXTERNAL AUTHENTICATE command shall be supported as described in [VIS] Appendix

C.5. EXTERNAL AUTHENTICATE command processing is defined in section 6.6.2.
Note: For reader vendors without access to [VIS], support for the EXTERNAL AUTHENTICATE
command is also described in [EMV] section 6.5.4.
G.5.5 PIN CHANGE/UNBLOCK Command-Response APDUs (Issuer Script

Command)
Implementation-Conditional: If Issuer Update Processing supported and offline PIN for dual-
interface card application supported.
The PIN CHANGE/UNBLOCK command is a post-issuance command to unblock the reference

PIN or to simultaneously change and unblock the reference PIN.
The PIN CHANGE/UNBLOCK command shall be supported as described in [VIS] section 14.5.4
and [VIS] Appendix C.11.
G.5.6 PUT DATA Command-Response APDUs (Issuer Script Command)
The PUT DATA command is a post-issuance command that updates specific data objects
stored in the card.
The PUT DATA command shall be supported as described in [VIS] Appendix C.12, with the
• VCPS data elements that may be updated using the PUT DATA command are indicated as
such in Appendix D.1.
G.5.7 UPDATE RECORD Command-Response APDUs (Issuer Script

Command)
The UPDATE RECORD command is a post-issuance command that is used to update a record
in a file with the data provided in the command data field.
The UPDATE RECORD command shall be supported as described in [VIS] Appendix C.15.

G.6 Secure Messaging
Secure messaging for issuer scripts shall be performed as described in [VIS] Appendix B, except
for computation of the MAC, which shall be performed as described in this appendix.
Note: Starting with VCPS 2.2, the referenced version of [VIS] is version 1.6, which introduces a
new secure messaging algorithm.
Req G.4 (Secure Messaging)
Secure messaging for issuer scripts shall be performed as described in [VIS] Appendix B, with
the following exception(s) in [VIS] Appendix B.2.4, step #2, bullet 3:
• The Last Contactless Application Cryptogram shall be used instead of the “last Application
Cryptogram...”
• If Issuer Script MAC Chaining is supported (ADA byte 3 bit 3 is 1b), then the 8-byte value
shall be persistent across communication sessions.
Note: "persistent across communication sessions" means that the 8-byte value is not lost when
the communication session ends. For example, if Issuer Script MAC chaining is supported, after
the first issuer script is applied, it should be possible to remove the card from the RF field, and
then present it again for the next issuer script using a chained MAC, not a MAC generated using
the Last Contactless Application Cryptogram as the 8-byte value.
Issuer script MAC chaining shall be implementation-mandatory and issuer-optional. Use of

issuer script MAC chaining is recommended.

H Streamlined qVSDC
H Streamlined qVSDC
H.1 Streamlined Functionality for qVSDC
Streamlined qVSDC is a simplified, online-only implementation of the card qVSDC path.

Streamlined qVSDC, as specified in this appendix, may be implemented by card manufacturers
for markets where products containing full qVSDC are not needed. Streamlined qVSDC
provides for a simplified, online-only flow through the card qVSDC path, allowing for easier
card implementations and potentially reduced transaction times. Streamlined qVSDC deals
exclusively with the card qVSDC path, and readers are oblivious to whether the card is
processing as full or Streamlined qVSDC. Streamlined qVSDC is not appropriate for all markets
and, as such, vendors planning to implement only Streamlined qVSDC should contact their
regional representatives.
The requirements specified in this section are intended primarily for implementations
containing only Streamlined qVSDC. However, Streamlined qVSDC may also be supported in
full qVSDC implementations, allowing for an issuer option to process qVSDC transactions as
Streamlined qVSDC.
For full qVSDC implementations supporting this option, if CAP byte 1 bit 5 is 1b or if the CAP is
not personalized, then Streamlined qVSDC processing is performed.
H.2 Streamlined qVSDC Requirements
Streamlined qVSDC has the same requirements as full qVSDC, except that an abbreviated form
of qVSDC Card Action Analysis is performed. In addition, some implementation decisions have
been made for Streamlined qVSDC in order to facilitate simple implementations and quick
transactions.
Req H.1 (Streamlined qVSDC)
The card streamlined qVSDC implementation shall conform to the card qVSDC path
requirements specified in section 6, with the following exception(s):
• The qVSDC path shall not support offline processing. The qVSDC Offline GPO Response is
not personalized.
• qVSDC Card Action Analysis shall be performed as defined in this appendix.

H Streamlined qVSDC
H.3 Streamlined qVSDC Card Action Analysis
Streamlined qVSDC shall perform qVSDC Card Action Analysis as defined in this appendix.
The card qVSDC path always returns an online cryptogram in response to the GPO command,
when returning a non-error code Status Word.
H.3.1 qVSDC Card Risk Management Processing
Checks and processing are performed in the order shown. Implementations are not required to
strictly follow the processing described in this section, so long as they behave in a way that is
indistinguishable (seen as a black box responding to the command) from the behavior
described.
Initialization of Data
Req H.2 (Initialization of Card Transaction Qualifiers)
The card shall reset CTQ byte 1 bits 8-7 to 00b (indicating Online PIN Not Required and
Signature Not Required) and CTQ byte 2 bit 8 to 0b (indicating CDCVM Not Performed).
Req H.3 (Initialization of Issuer Application Data)
The card shall set CVR bytes 2-4 to '80 00 00' (indicating Second GENERATE AC not
requested) and, if present, CVR byte 5 to '00'. CVR byte 1 is Unchanging and does not change
from transaction to transaction.
If CDCVM supported by card (CAP byte 3 bit 4 is 1b), then the card shall set the CVR 'CDCVM
successfully performed' bit(s) to 1b.
Note: In IAD Format 2 there are two 'CDCVM successfully performed' bits in the CVR, and the
card must set both bits to 1b.
Req H.4 (Initialization of Cryptogram Information Data)
The card shall reset the Cryptogram Information Data (CID) to '00'.
Application Blocked
Req H.5 (Application Blocked Check)
If the application is blocked, then the card shall discontinue processing the command and
shall respond with SW1 SW2 = '6985'.

H Streamlined qVSDC
Cardholder Verification Method (CVM)
Req H.6 (CVM Required Check)
If CVM Required by reader (TTQ byte 2 bit 7 is 1b), then a CVM is required for the transaction,
and the card shall determine the common CVM to be performed.
Req H.7 (Determine Common CVM)
If a CVM is required for the transaction, then the card shall attempt to select a common CVM
supported by both itself and the reader, as defined in this requirement. If there is more than
one CVM supported by both the card and the reader, the selected CVM is chosen based on
the following defined CVM hierarchy: 1) Online PIN, 2) CDCVM, or 3) Signature.
If the Card Additional Processes (CAP) is personalized, then:
• If both of the following are true:
̵ Online PIN supported by reader (TTQ byte 1 bit 3 is 1b)
̵ and either of the following is true:
• Issuer Country Code matches the Terminal Country Code and Online PIN supported
by card for domestic transactions (CAP byte 3 bit 8 is 1b)
• Issuer Country Code does not match the Terminal Country Code and Online PIN
supported by card for international transactions (CAP byte 3 bit 7 is 1b)
Then the card shall indicate Online PIN Required (set CTQ byte 1 bit 8 to 1b).
̵ CDCVM supported by reader (TTQ byte 3 bit 7 is 1b)
̵ and CDCVM supported by card (CAP byte 3 bit 4 is 1b)
Then the card shall indicate CDCVM Performed (set CTQ byte 2 bit 8 to 1b).
̵ Signature supported by reader (TTQ byte 1 bit 2 is 1b)
̵ and Signature supported by card (CAP byte 3 bit 5 is 1b)
Then the card shall indicate Signature Required (set CTQ byte 1 bit 7 to 1b)
Else (no common CVM between card and reader), the card shall discontinue processing
and respond to the GPO command with SW1 SW2 = '6984'.
Else (the CAP is not personalized), then:
• If Signature is not supported by the reader (TTQ byte 1 bit 2 is 0b), then the card shall
discontinue processing and respond to the GPO command with SW1 SW2 = '6984'.

H Streamlined qVSDC
Else (Signature is supported by the reader), the card shall indicate Signature Required (set
CTQ byte 1 bit 7 to 1b) and shall continue processing the transaction.
H.3.2 Transaction Disposition
Req H.8 (Online)
The card shall:

• Indicate Authorization Request Cryptogram returned (set CVR byte 2 bits 6-5 to 10b and
set CID bits 8-7 to 10b).
• Construct the Issuer Application Data. If an Issuer Discretionary Data Option (IDD Option)
is supported (see Appendix E), it shall be constructed and the MAC generated (if
applicable).
• If the card is capable of performing fDDA and all of the following are true:
̵ the card supports fDDA for Online Authorizations (AIP byte 1 bit 6 is 1b for the qVSDC
"Online (with ODA)" GPO response)
̵ and ODA for Online Authorizations supported by card (CAP byte 2 bit 6 is 0b)
̵ and ODA for Online Authorizations supported by reader (TTQ byte 1 bit 1 is 1b)
Then the card shall construct the Card Authentication Related Data and generate the
Signed Dynamic Application Data (tag '9F4B'). The Signed Dynamic Application Data shall
be generated as defined in Appendix A.
• Generate the Application Cryptogram.
• If ODA for Online Authorizations supported by reader (TTQ byte 1 bit 1 is 1b) and the
qVSDC Online with ODA GPO Response is supported (per Req 6.11), then construct and
send the GPO response in [EMV] Format 2 with the data shown in Table 6–2 using
Condition column "Online (with ODA)".
Else, construct and send the GPO response in [EMV] Format 2 with the data shown in
Table 6–2 using Condition column "Online and Decline (without ODA)".
Note: The Available Offline Spending Amount (tag '9F5D') is not supported for Streamlined
qVSDC.

I Dual-Interface Contactless and Contact Cards

For dual-interface cards that support both [VCPS] and [VIS], this appendix defines additional
requirements for dual-interface cards, and identifies the new functionality required of [VIS] to
address the functionality introduced by [VCPS].
Dual-interface cards shall implement the functionality and requirements defined in this
appendix.
I.1 Contactless and Contact Interfaces
Req I.1 (Contactless and Contact Interfaces)
The card shall not activate the contactless interface if the contact interface is activated.
The card's contact interface should have priority over its contactless interface. If the contactless
interface is active and the contact interface is subsequently activated, the card should
deactivate the contactless interface and activate the contact interface.
Req I.1A (Contactless SELECT)
If the card is configured to not support contactless transactions (that is, none of the
contactless paths on the card are enabled), then the card shall respond to SELECT commands
received over the contactless interface with an error Status Word (SW1 SW2 = '6986' is
recommended).
I.2 Processing Options Data Object List (PDOL)
A card application contains a single PDOL for the contactless interface. For a dual-interface
card, the contact interface may be personalized with a different PDOL or without a PDOL.
Req I.2 (PDOL)
For a dual-interface card, the card application shall be capable of supporting different PDOL’s
based on interface – contact or contactless.

I.3 Reset of Offline Counters using VIS
Counters that are used in VCPS transaction processing are reset either through Issuer Update
Processing or through [VIS] transactions, subject to issuer requirements.
Counter reset with Issuer Update Processing is described and specified in section 6.6.
Counter reset with [VIS] transactions are described and specified in [VIS], and are briefly
summarized in this section.
I.3.1 [VIS] Counter Resets
The [VIS] specification has been revised to reset the counters and indicators shared by VIS and
VCPS, and to reset the counters and indicators used exclusively by VCPS, subject to issuer
requirements for resetting of counters.
In addition, VCPS introduced the ‘Reset VLP Available Funds to VLP Funds Limit when Offline
PIN successfully verified’ (ADA byte 3 bit 5) option. With this option, the VLP Available Funds is
reset to the VLP Funds Limit when the Offline PIN is successfully validated during a VIS
transaction (and other processing requirements are met).
See [VIS] for additional details regarding resetting of counters during VIS transactions.
I.3.2 Consecutive Transaction Counter International
qVSDC transactions where the Transaction Currency Code does not match the Application
Currency Code or any of the supported Conversion Currency Codes are international
transactions. Additionally, the issuer may configure the application such that transactions
where the Terminal Country Code does not match the Issuer Country Code are also
international transactions. Regardless of the issuer configuration to include international
determination based on the country code, the Consecutive Transaction Counter International
(CTCI) may be used to count qVSDC international transactions.
This behavior is unlike [VIS], where two separate counters are used to count non-matching
currency code transactions and non-matching country code transactions. ADA byte 3 bit 1
(‘CTCI also counts non-matching country code transactions’) is introduced to allow for [VIS]
applications to count international transactions using the same single counter.
Req I.3 (VIS CTCI)
If ‘CTCI also counts non-matching country code transactions’ (ADA byte 3 bit 1 is 1b), then
[VIS] transactions shall increment the Consecutive Transaction Counter International (CTCI) for
non-matching country code transactions.

I.4 Data Accessibility
This section outlines the requirements for the accessibility of contact-exclusive data,
contactless-exclusive data, and shared data.
Req I.4 (Records Restricted by Interface)
Records that are only listed in the Application File Locator(s) used for the contactless
interface shall not be accessible over the contact interface.
Records that are only listed in AFL(s) used for the contact interface shall not be accessible
over the contactless interface.
Issuers shall (using the AFLs) be able to configure any record to be accessible over only the
contact interface, only the contactless interface, or both interfaces.
If the record requested by the READ RECORD command is not allowed to be retrieved over
the interface, the card shall respond with an error SW1 SW2 ('6A83' is recommended)
For example, a record present only in the AFL for the qVSDC path shall only be accessible
over the contactless interface, and a record present in the AFL for both qVSDC and VIS shall
be accessible over both the contactless and contact interfaces.
Records that are not listed in any AFL should be accessible over the contact interface and
shall not be accessible over the contactless interface. This excludes transaction log records,
whose accessibility is governed by Req I.5.
Note: This record retrieval restriction by interface is based only on whether the record was
personalized in the AFL for the card paths, regardless of whether or not the AFL was returned by
the card prior to the card application receiving the READ RECORD command.
Req I.5 (Transaction Log Records Restricted by Interface)
Implementation-Conditional: If transaction logging is implemented, then this functionality

shall be implemented.
Transaction log records shall be issuer configurable to be accessible over the contact
interface-only, over the contactless interface-only, or over both interfaces.
Req I.6 (Application Internal Data Elements)
GET DATA:
• [VIS] (Table A-1) defines whether card internal data elements are retrievable by the GET
DATA command over the contact interface.

• VCPS (Table D–1) defines whether card internal data elements are retrievable by the GET
DATA command over the contactless interface.
• Card internal data elements defined in [VIS] but not defined in VCPS shall not be
retrievable by the GET DATA command over the contactless interface.
• Card internal data elements defined in VCPS but not defined in [VIS] should be retrievable
by the GET DATA command over the contact interface.
PUT DATA:
• Card internal data elements defined in VCPS Table D–1 as updatable by the PUT DATA
command shall be updatable by the PUT DATA command received over the contact
interface (if the PUT DATA command is supported for contact and the data elements is
present in the application).
I.5 Application Capabilities
I.5.1 Contactless Functionality
The ‘Contactless Functionality Disabled’ bit (Application Capabilities byte 1 bit 8) is used to
configure whether the dual interface card is permitted to process commands received over the
contactless interface. This bit can be personalized, or set post-issuance using the PUT DATA
issuer script command, to “disable the contactless functionality” of the card.
Req I.7 (Contactless Functionality Disabled)
When ‘Contactless Functionality Disabled’ is 1b, the card application shall discontinue
processing of all commands received over the contactless interface, and shall respond with
an error SW1 SW2 ('6A81' is recommended).
I.5.2 Restrict Reset of Contactless Functionality Disabled Bit to PUT

DATA
Application Capabilities byte 1 bit 7, ‘Restrict reset of Contactless Functionality Disabled bit’,
can be personalized or set post-issuance using the PUT DATA issuer script command to control
the conditions under which the ‘Contactless Functionality Disabled’ bit is reset to 0b.
Req I.8 (Restrict Reset of Contactless Functionality Disabled Bit)
If ‘Restrict reset of Contactless Functionality Disabled bit’ is 0b, then the ‘Contactless
Functionality Disabled’ bit shall be reset to 0b during the next [VIS] transaction where the

card approves the transaction after an online authorization (when Issuer Authentication
requirements are met for [VIS]). See [VIS] Appendix H for further details.
If ‘Restrict reset of Contactless Functionality Disabled bit’ is 1b, then the ‘Contactless
Functionality Disabled’ bit shall only be reset to 0b through the PUT DATA issuer script
command.
Note: Regardless of the setting of the ‘Restrict reset of Contactless Functionality Disabled bit’,
the PUT DATA issuer script command can always be used to change the value of the
‘Contactless Functionality Disabled’ bit.
I.6 Issuer Update Processing
Issuer Update Processing introduces new counters and indicators that must be processed
during [VIS] transactions. For dual-interface cards supporting Issuer Update Processing, the
following counters shall be processed as defined:
• Last Successful Issuer Update ATC Register – During [VIS] transactions, this data element is
set to the value of the ATC when [VIS] Issuer Authentication requirements are met, or when
an issuer script command is successfully processed.
• Last Contactless Application Cryptogram Valid Indicator – If a [VIS] transaction is initiated,
then this indicator shall be set to 0 (during GPO processing).
I.7 DDA and fDDA
The ICC Public Key Certificate used in DDA and fDDA contain a hash of static data from the
card application. However, different static data elements are recommended to be signed for
VCPS and VIS:
• It is recommended that VCPS not sign any static data. Transaction times are reduced if VCPS
does not sign static data, as one fewer record may be returned.
• It is recommended that VIS sign the static data as recommended in [VIS].
Although VIS and VCPS may share the same ICC Public Key Certificate, it is recommended that
VCPS and VIS use different ICC Public Key Certificates, and for the VCPS ICC Public Key
Certificate not to contain the any static data to be authenticated. Transaction times are
reduced since there is less processing.
Even when the hash in the VCPS ICC Public Key Certificate does not contain any static data, the
Application PAN and Application Expiration are still protected. The PAN is verified against the
Application PAN contained in the ICC Public Key Certificate during DDA and fDDA processing
([EMV] Book 2 section 6.4). To prevent altered Application Expiration Dates, it is strongly
recommended that the Certificate Expiration Date (from the ICC Public Key Certificate) match

the Application Expiration Date. The Certificate Expiration Date is then validated during DDA
and fDDA processing ([EMV] Book 2 section 6.4).
Issuers should balance the benefits of using different ICC Public Key Certificates for VIS and
VCPS (reducing transaction times) against the increased complexity of generating and
personalizing two ICC Public Key Certificates.

J Reader-Terminal Data
This appendix outlines the data elements that may need to be communicated from the reader
to the merchant device connected to the acquirer for each transaction path. The data that
needs to be communicated is dependent on the architecture of the reader within the POS
acceptance environment, hence the tables below are intended only to provide guidance. The
tables do not represent a comprehensive list of all data that must be communicated, and many
of the data elements listed below may not need to be communicated at all (depending on
reader-terminal architecture).
Table J–2: qVSDC Transactions
Data Element Tag Condition
POS Entry Mode – Always
Terminal Entry Capability – Always
Track 2 Equivalent Data 57 Always
Application PAN 5A If returned by card
Cardholder Name 5F20 If returned by card
Application Expiration Date 5F24 If returned by card
Transaction Currency Code 5F2A Always
Application PAN Sequence Number 5F34 If returned by card
Application Interchange Profile 82 Always
Terminal Verification Results 95 Always
Transaction Date 9A Always
Transaction Type 9C Always
Amount, Authorized (Numeric) 9F02 Always
Amount, Other (Numeric) 9F03 Always
Issuer Application Data 9F10 Always
Terminal Country Code 9F1A Always
Payment Account Reference (PAR) 9F24 If returned by card
Application Cryptogram 9F26 Always
Cryptogram Information Data 9F27 Always
Application Transaction Counter 9F36 Always
Unpredictable Number (Reader-Terminal) 9F37 Always

Issuer Script Results 9F5B If Issuer Update Processing supported and
issuer scripting performed
Available Offline Spending Amount 9F5D If returned by card
Form Factor Indicator 9F6E If returned by card
Customer Exclusive Data 9F7C If returned by card

K Online Messages and Clearing Records

This appendix outlines the minimum set of data elements the reader-terminal shall make
available to the acquirer for inclusion in online messages and clearing records for VCPS
transactions. The reader-terminal is not prohibited from providing other data, in addition to
the minimum data specified by this appendix.
Regardless of reader-terminal architecture, the acquirer shall be provided the data necessary to
construct online messages and clearing records with the new data specified in this appendix.
The method and means of providing this information to the acquirer is outside the scope of
this specification.
K.1 <This section has been deleted>
K.2 qVSDC Acquirers
K.2.1 Acquirers Supporting qVSDC
This section describes the messaging requirements for acquirers that support qVSDC
transactions.
qVSDC data requirements for online messages and clearing records are the same as for VSDC
contact chip transactions, except for new values in existing fields and new values in chip fields
(as shown in Table K–3).
Table K–3: Acquirers Supporting qVSDC
Data Tag Value
Amount, Authorized 9F02 Always
Amount, Other 9F03 Always
Application Cryptogram 9F26 Always
Application Interchange 82 Always

Profile
Application Transaction 9F36 Always

Counter (ATC)

Data Tag Value
Card Sequence Number 5F34 Conditional

If the Application PAN Sequence Number (PSN) is provided to
the reader by the card, this data must be made available to the
acquirer.
Else (data not provided to the reader by the card), the data is
not made available to the acquirer.
Customer Exclusive Data 9F7C Conditional

If the Customer Exclusive Data (CED) is provided to the reader
by the card, this data may be made available to the acquirer.
See Req 5.7 (qVSDC Messages – FFI and CED).
Form Factor Indicator 9F6E Conditional

If the Form Factor Indicator (FFI) is provided to the reader by
the card, this data may be made available to the acquirer.
See Req 5.7 (qVSDC Messages – FFI and CED).
Issuer Application Data 9F10 Always
POS Entry Mode – Always

A value of 07 for qVSDC transactions.
Terminal Country Code 9F1A Always
Terminal Entry Capability – Always

A value of 5 (for readers that also support VSDC contact chip) or
a value of 8 (for readers that do not also support VSDC contact
chip). Check with your Visa regional representative.
Terminal Verification 95 Always

Results For VCPS transactions, the TVR shall have a value of all zeros
when made available to the acquirer.
Transaction Currency Code 5F2A Always
Transaction Date 9A Always
Transaction Type 9C Always
Unpredictable Number 9F37 Always

(Reader-Terminal)

K.2.2 qVSDC Requirements
The following additional requirements are applicable for qVSDC messages.
Req K.3 (Track 2)
For qVSDC transactions, Track 2 shall be sent online in the authorization.
Req K.4 (Primary Account Number and Expiration Date)
The primary account number and application expiration date used in messaging are retrieved
from Track 2 Equivalent Data.

L Transaction Logging
Implementation-Optional: Implementation of transaction logging is at implementer discretion.
Issuer-Optional: If transaction logging is implemented, the issuer shall be able to enable and
disable transaction logging. Due to the increase in application processing times when
transaction logging is used, it is strongly recommended that issuers not enable transaction
logging.
When transaction logging is supported, it shall be supported as described in [EMV] Book 3

Annex D, with the following exception(s):
• Any reader-terminal data element to be logged shall be requested in the Processing
Options Data Object List (PDOL).
If transaction logging is supported, the SFI containing the transaction log must be in the range
11-30 ('0B' to '1E'). It is recommended that the SFI containing the transaction log be an issuer
configurable value (identified at the time of personalization by the issuer in the Log Entry), but
card implementations may choose to fix the SFI value(s) which are supported for transaction
logging. If the card implementation supports [EMV CPS], then SFI values 13 and 14 ('0D' and
'0E') are reserved for other purposes and cannot be used for transaction logging.
For VCPS transactions, updates to the log occur:

• Immediately prior to the application response to the GET PROCESSING OPTIONS (GPO)
command when an Application File Locator is not returned in the GPO response.
• Immediately prior to the application response to the last READ RECORD command when an
Application File Locator is returned in the GPO response. The last record is indicated by the
Application File Locator.
The default behavior is to log all online and offline approval requested transactions. However,
Application Default Action (ADA) byte 3 includes three bits reserved to control logging of
transactions:
• Do not include offline approval requested transactions in the transaction log.
• Do not include online approval requested transactions in the transaction log.
• Include offline declined transactions in the transaction log.
Recognize that VCPS transaction log information represents the card applications view of the
transaction outcome, which is not necessarily the same as the actual outcome of the
transaction.
Visa recommends only updating the transaction log for the following Transaction Types:

• '00' - Purchase
• '01' - Cash
• '11' - Quasi cash
VIS transactions are logged as defined in [VIS] Appendix I.
Implementations may support an option where log access (that is, reading log records)
requires successful verification of a [VIS] Offline PIN. Visa rules for PIN entry and verification
apply.

M Issuer Application Data (IAD) and Card Verification Results (CVR) Formats
M Issuer Application Data (IAD) and Card Verification

Results (CVR) Formats
This appendix defines two formats of Issuer Application Data (IAD):
• IAD Format 0/1/3
• IAD Format 2 (introduced in VCPS 2.2)
The IAD Format is indicated in the left nibble of the CVN value, and indicates the layout of the
Issuer Application Data, such as the length of the IAD, the format of the CVR, and where to find
the Derivation Key Index (DKI) and Issuer Discretionary Data Option ID.
Req M.1 (Issuer Application Data (IAD) Formats)
Implementation-mandatory: Cards shall implement support for IAD Format 0/1/3.

Implementation-conditional: If CVN'22' is implemented or an issuer proprietary cryptogram
using IAD Format 2 is implemented, then the card shall implement support for IAD Format 2.
Table M–1: IAD Formats
Byte IAD Format 0/1/3 (Current) IAD Format 2 (New in VCPS 2.2)
1 Length of Visa Discretionary Data (= '06') Length (= '1F')
2 DKI CVN
3 CVN DKI
4 CVR byte 1 (= CVR Length = '03') CVR byte 1 (bitmap)
5 CVR byte 2 (bitmap) CVR byte 2 (bitmap – same as for VIS Format 0/1/3)
8 Length of Issuer Discretionary Data (optional) CVR byte 5 (bitmap)
9 Issuer Discretionary Data (optional) (optional: Right Left nibble = RFU

nibble = Issuer Discretionary Data Option ID) Right nibble = Issuer Discretionary Data Option ID
10 Issuer Discretionary Data (optional) Issuer Discretionary Data

Byte IAD Format 0/1/3 (Current) IAD Format 2 (New in VCPS 2.2)
24 --- not available --- Issuer Discretionary Data
Table M–2: CVR Formats
Byte/bit CVR for IAD Format 0/1/3 (Current) CVR for IAD Format 2 (New in VCPS 2.2)
1/8 CVR Length = fixed hex '03' RFU
1/7 RFU
1/6 RFU
1/5 RFU
1/4 RFU
1/3 RFU
1/2 RFU
1/1 RFU
2/8 Cryptogram Type in second GENENERATE AC Cryptogram Type in second GENENERATE AC

00b = Not used for VCPS 00b = Not used for VCPS
01b = Not used for VCPS 01b = Not used for VCPS

2/7 10b = Second GENERATE AC not requested 10b = Second GENERATE AC not requested
11b = RFU 11b = RFU
2/6 Cryptogram Type in GPO Cryptogram Type in GPO

00b = AAC returned in GPO 00b = AAC returned in GPO
01b = TC returned in GPO 01b = TC returned in GPO
2/5 10b = ARQC returned in GPO 10b = ARQC returned in GPO

11b = RFU 11b = RFU
2/4 Not used for VCPS Not used for VCPS
2/3 CDCVM successfully performed CDCVM successfully performed
3/7 PIN Try Limit exceeded PIN Try Limit exceeded
3/6 Exceeded velocity checking counters Exceeded velocity checking counters
3/4 Issuer Authentication failure on last online Issuer Authentication failure on last online
transaction transaction
4/8 Issuer Script Command Counter Issuer Script Command Counter
4/7
4/6
4/5
4/4 Issuer script processing failed on last transaction Issuer script processing failed on last transaction
5/8 --- not available --- RFU

5/2 --- not available --- CDCVM successfully performed
5/1 --- not available --- Secure Messaging uses EMV Session key-based
derivation

Glossary
Glossary
This is a glossary of terms used in this specification; it is not intended as a data dictionary. For
descriptions of data elements, see Appendix D.
0 A BCDE FGHI JKLMNOPQRSTUVWXYZ

Term Definition
0-9
A
a alpha
AAC Application Authentication Cryptogram
AC Application Cryptogram
acquirer A Visa customer that signs a merchant or disburses currency to a

cardholder in a cash disbursement, and directly or indirectly enters the
resulting transaction into interchange.
ADA Application Default Action
ADF Application Definition File
AEF Application Elementary File
AFL Application File Locator
AID Application Identifier
AIP Application Interchange Profile
an alphanumeric
ans alphanumeric special
ANSI American National Standards Institute. A U.S. standards accreditation

organization.
AOSA Available Offline Spending Amount
APDU Application Protocol Data Unit
application A computer program and associated data that reside on an integrated

circuit chip and satisfy a business function. Examples of applications include
payment, stored value, and loyalty.
Application Cryptogram Cryptogram returned by the card in response to the GET PROCESSING
OPTIONS command; one of the following cryptogram types:
TC Transaction Certificate
ARQC Authorization Request Cryptogram
AAC Application Authentication Cryptogram

Glossary
Term Definition
Application Authentication A cryptogram generated by the card application for offline declined
Cryptogram (AAC) transactions.
Application Elementary File A set of data or records in a file that uses a single Short File Identifier (SFI).
ARC Authorization Response Code
ARPC Authorization Response Cryptogram
ARQC Authorization Request Cryptogram
ATC Application Transaction Counter
AUC Application Usage Control
authentication A cryptographic process that validates the identity and integrity of data.
authorization A process where an issuer or a representative of the issuer approves a

transaction.
authorization controls Information in the chip application enabling the card to act on the issuer’s
behalf at the point of transaction. The controls help issuers manage their
below-floor-limit exposure to fraud and credit losses. Also known as offline
authorization controls.
authorization request A merchant’s or acquirer’s request for an authorization.
Authorization Request Cryptogram The cryptogram generated by the card for transactions requiring online
(ARQC) authorization and sent to the issuer in the authorization request. The issuer
validates the ARQC during the Online Card Authentication (CAM) process
to ensure that the card is authentic and that the authorization request was
not created using skimmed data.
Authorization Response Cryptogram A cryptogram generated by the issuer and sent to the card in the
(ARPC) authorization response. This cryptogram is the result of the Authorization
Request Cryptogram (ARQC) and the issuer’s authorization response
encrypted with the Unique Derivation Key (UDK). It is validated by the card
during Issuer Authentication to ensure that the response came from a valid
issuer.
B
b binary
Bank Identification Number (BIN) A 6-digit number assigned by Visa and used to identify a customer or
processor for authorization, clearing, or settlement processing.
BCD Binary Coded Decimal
BER Basic Encoding Rules
Binary Coded Decimal A code for representing decimal digits in a binary format.
byte 8 bits of data.
C
C conditional

Glossary
Term Definition
CA Certificate Authority
CAM Card Authentication Method
Candidate List A list of applications supported by both the card and reader. The Candidate
List is built by the reader during Application Selection.
CAP Card Additional Processes
Card A consumer device containing the Visa contactless payment application.

Note that the consumer device may not be a plastic card, but for the
purposes of this specification, the term card is used to represent the
consumer device.
card authentication A means of validating whether a card used in a transaction is the genuine
card issued by the issuer.
Card Authentication Method (CAM) See Online Card Authentication.
Card Verification Value (CVV) A unique check value encoded on a card’s magnetic stripe and chip to
validate card information during an online authorization.
cardholder An individual to whom a card is issued or who is authorized to use that

card.
cardholder verification The process of determining that the presenter of the card is the valid
cardholder.
Cardholder Verification Method A method used to confirm the identity of a cardholder.

(CVM)
cash disbursement Currency, including travelers checks, paid to a cardholder using a card.
cashback Cash obtained in conjunction with, and processed as, a purchase

transaction.
CDA Combined DDA/Application Cryptogram generation
CDCVM Consumer Device Cardholder Verification Method
CDOL Card Risk Management Data Object List
CED Customer Exclusive Data
Certificate Authority (CA) A trusted central administration that issues and revokes certificates.
Chinese Remainder Theorem A specific format for private RSA keys that makes the signature calculation
faster.
chip An electronic component designed to perform processing or memory

functions.
chip card A card embedded with a chip that communicates information to a point-
of-transaction terminal.
chip-capable A card acceptance device that is designed and constructed to facilitate the
addition of a chip reader/writer.
CID Cryptogram Information Data

Glossary
Term Definition
CLA Class byte of Command Message
clearing The collection and delivery to the issuer of a completed transaction record
from an acquirer.
CLTC Contactless Transaction Counter
CLTCLL Contactless Transaction Counter Lower Limit
CLTCUL Contactless Transaction Counter Upper Limit
cn compressed numeric
Collision Transmission by two or more PICCs in the same PCD energizing field and
during the same time period, such that the PCD is unable to distinguish
from which PICC the data originated.
Combined DDA/Application A type of Offline Data Authentication where the card combines generation
Cryptogram generation (CDA) of a cryptographic value (dynamic signature) for validation by the terminal
with generation of the Application Cryptogram to ensure that the
Application Cryptogram came from the valid card. (Note that CDA is not
supported in qVSDC.)
Consumer Device Proximity Card (PICC) or other chip-capable device (for example, a cell
phone) that is used by consumers to conduct payment.
Contactless Transaction A transaction conducted over the contactless interface according to this
specification.
Contactless Indicator An optional indicator in the last position in the magnetic stripe data on the
chip. A value greater than zero indicates contactless and may be used to
differentiate cards with the same account number.
CPS Card Personalization Specification
cryptogram A value that is the result of data elements entered into an algorithm and
then encrypted. Commonly used to validate data integrity.
cryptographic key The numeric value entered into a cryptographic algorithm that allows the
algorithm to encrypt or decrypt a message.
cryptography The art or science of keeping messages secret or secure, or both.
CSU Card Status Update
CTC Consecutive Transaction Counter
CTCI Consecutive Transaction Counter International
CTCIL Consecutive Transaction Counter International Limit
CTCL Consecutive Transaction Counter Limit
CTCUL Consecutive Transaction Counter Upper Limit
CTIUL Consecutive Transaction International Upper Limit
CTQ Card Transaction Qualifiers
CTTA Cumulative Total Transaction Amount

Glossary
Term Definition
CTTAL Cumulative Total Transaction Amount Limit
CTTAUL Cumulative Total Transaction Amount Upper Limit
CTTA Funds Refers to the value of the Cumulative Total Transaction Amount Upper
Limit (CTTAUL) less the Cumulative Total Transaction Amount (CTTA).
If CTTAUL is not personalized, then refers to the value of the Cumulative
Total Transaction Amount Limit (CTTAL) less the Cumulative Total
Transaction Amount (CTTA).
CVM Cardholder Verification Method
CVN Cryptogram Version Number
CVR Card Verification Results
CVV Card Verification Value
D
data authentication Validation that data stored in the integrated circuit card has not been
altered since card issuance. See also Offline Data Authentication.
Data Encryption Algorithm (DEA) An encipherment operation and an inverse decipherment operation in a
cryptographic system.
Data Encryption Standard (DES) The public domain symmetric key cryptography algorithm of the National
Institute for Standards and Technology.
DDA Dynamic Data Authentication
DDF Directory Definition File
DDOL Dynamic Data Authentication Data Object List
DEA Data Encryption Algorithm
Dedicated File Name Name of file or application as defined in [EMV] and [VIS].
decryption The process of transforming ciphertext into cleartext.
DES Data Encryption Standard
DES key A secret parameter of the Data Encryption Standard algorithm.

DES keys by definition are of odd parity, as indicated in the Federal
Information Processing Standards publication FIPS 46-3.
DF Dedicated file
DF Name Dedicated File Name
digital signature A cryptogram generated by encrypting a message digest (or hash) with a
private key that allows the message content and the sender of the message
to be verified.
Discovery Contactless readers poll for contactless cards. When one or more
contactless cards enter the field of the contactless reader, this is called
discovery.

Glossary
Term Definition
DKI Derivation Key Index
DOL Data Object List
double-length DES Key Two secret 64-bit input parameters each of the Data Encryption Standard
algorithm, consisting of 56 bits that must be independent and random, and
8 error-detecting bits set to make the parity of each 8-bit byte of the key
odd.
DRL Dynamic Reader Limits
Dynamic Data Authentication (DDA) Offline authentication that offers protection against skimming. The card
generates an RSA signature using transaction-specific data for validation by
the terminal.
Dynamic Signature A signature generated by the card using dynamic data from both the card
and the reader. This signature is validated by the reader to prove that the
card is genuine. When used it refers to Signed Dynamic Application Data,
tag '9F4B'.
E
encryption The process of transforming cleartext into ciphertext.
End Sentinel Indicator at the end of Track 1 or Track 2 on the magnetic stripe. It is
followed by the Longitudinal Redundancy Check.
expired card A card on which the embossed, encoded, or printed expiration date has
passed.
F
Fast DDA (fDDA) Leverages DDA as defined in [EMV] and [VIS] specifications. Used in qVSDC
transactions to allow the reader to issue READ RECORD commands to
obtain Dynamic Data Authentication (DDA) related data from the card and
perform the DDA calculations after the card has left the field.
FCI File Control Information
fDDA Fast DDA
FFI Form Factor Indicator
File Control Information Provided in a card response when the card application is selected (using a
SELECT command) by a reader or terminal.
floor limit A currency amount that Visa has established for single transactions at
specific types of merchants, above which online authorization is required.
FWI Frame Wait time Integer
G
GPO GET PROCESSING OPTIONS command

Glossary
Term Definition
Hardware Security Module (HSM) A secure module used to store cryptographic keys and perform
cryptographic functions.
hash The result of a non-cryptographic operation, which produces a unique

value from a data stream.
Hex Hexadecimal
HHMMSS hours, minutes, seconds
HSM Hardware Security Module
I
IA Issuer Authentication
IAD Issuer Application Data
IAuD Issuer Authentication Data
IC integrated circuit
ICC Integrated Circuit Card
iCVV An alternate CVV to be used in the image of the Track 2 Equivalent Data
personalized on the chip.
IDD Issuer Discretionary Data
IDDO Issuer Discretionary Data Option
IEC International Electrotechnical Commission
INS Instruction byte of Command Message
ISO International Organization for Standardization
issuer A Visa customer that issues Visa or Electron cards, or proprietary cards
bearing the PLUS or Visa Electron Symbol.
Issuer Authentication Validation of the issuer by the card to ensure the integrity of the
authorization response. See Authorization Response Cryptogram (ARPC).
Issuer Update An update of the card application and its data elements, counters, or
indicators due to Issuer Update Processing. The Issuer Update may consist
of issuer authentication using the EXTERNAL AUTHENTICATE command
and/or application of issuer script commands.
J
K
key generation The creation of a new key for subsequent use.
key management The handling of cryptographic keys and other related security parameters
during the entire life cycle of the keys, including their generation, storage,
distribution, entry and use, deletion or destruction, and archiving.
L
Glossary
Term Definition
Lc Exact length of data sent by the Terminal Application Layer (TAL) in a Case
3 or 4 command
LD Length of the plaintext data in the Command Data Field
Le Maximum length of data expected by the TAL in response to a Case 2 or 4

command
Longitudinal Redundancy Check Verification value that ensures no data has been lost in the process of
reading the data from the physical magnetic stripe. See the [VPTSM] for
additional information.
LRC Longitudinal Redundancy Check
M
M mandatory
MAC Message Authentication Code
MAC MDK Master Message Authentication Code DEA Key
MAC UDK Unique Message Authentication Code DEA Key
magnetic stripe The stripe on the back of the card that contains the magnetically coded
account information necessary to complete a non-chip electronic
transaction.
Magnetic Stripe Data (MSD) Contactless payment using Track 2 Equivalent Data acquired from the chip,
or Track 1 constructed from data acquired from the chip, operating under
magnetic stripe payment rules.
Magnetic Stripe Image The minimum chip payment service data replicating information in the
magnetic stripe required to process a transaction that is compliant with
EMV. (Not allowed as a contactless magnetic stripe solution.)
Master Derivation Key A double length DES key used to derive card unique keys used in online
card authentication.
MBLI Maximum Buffer Length Index
MCC Merchant Category Code
MDK Master Derivation Key
Merchant Category Code (MCC) A code designating the principal trade, profession, or line of business in
which a merchant is engaged.
message authentication code (MAC) A digital code generated using a cryptographic algorithm which establishes
that the contents of a message have not been changed and that the
message was generated by an authorized entity.
MSI Magnetic Stripe Image
MSD Magnetic Stripe Data

Glossary
Term Definition
multi-application The presence of multiple applications on a chip card (for example,

payment, loyalty, and identification).
N
n numeric
N/A Not Applicable
NCA Length of the Certification Authority Public Key Modulus
NFC Near Field Communication
NI Length of the Issuer Public Key Modulus
nibble The four most significant or least significant bits of a byte of data.
NIC Length of the ICC Public Key Modulus
O
O Optional
ODA Offline Data Authentication
offline approval A transaction that is positively completed at the point of transaction

between the card and terminal without an authorization request to the
issuer.
offline authorization A method of processing a transaction without sending the transaction

online to the issuer for authorization.
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.
VCPS supports Fast Dynamic Data Authentication (fDDA)
offline decline A transaction that is negatively completed at the point of transaction

between the card and terminal without an authorization request to the
issuer.
offline dynamic data authentication A type of Offline Data Authentication where the card generates a
cryptographic value using transaction-specific data elements for validation
by the terminal to protect against skimming. Includes both DDA and CDA.
offline PIN A PIN value stored on the card that is validated at the point of transaction
between the card and the terminal.
offline PIN verification The process whereby a cardholder-entered PIN is passed to the card for
comparison to a PIN value stored secretly on the card.
offline-capable A card acceptance device that is able to perform offline approvals.
offline-only terminal A card acceptance device that is not capable of sending transactions online
for issuer authorization.
online authorization A method of requesting an authorization through a communications

network other than voice to an issuer or issuer representative.

Glossary
Term Definition
Online Card Authentication (CAM) Validation of the card by the issuer to protect against data manipulation
and skimming. See Authorization Request Cryptogram (ARQC).
online PIN A method of PIN verification where the PIN entered by the cardholder into
the terminal PIN pad is DES-encrypted and included in the online
authorization request message sent to the issuer.
online-capable terminal A card acceptance device that is able to send transactions online to the
issuer for authorization.
P
P1 Parameter 1
P2 Parameter 2
PAN Primary Account Number
PAR Payment Account Reference
Path An application path taken based on reader/terminal interface and

capabilities.
The contactless path defined in this specification is qVSDC. Older versions
of VCPS also defined the MSD path.
The VIS path is defined in [VIS], supporting only the contact interface. Card
behavior is uniquely defined based on the path taken.
PCD Proximity Coupling Device
PDOL Processing Options Data Object List
PICC Proximity Card
personalization The process of populating a card with the application data that makes it
ready for use.
PIN Personal Identification Number
PIX Proprietary Application Identifier Extension
PK Public Key
PKI Certificate Authority Public Key Index
plaintext Data in its original unencrypted form.
PLUS A global ATM network
POS Point of Sale
POS Device A terminal which is installed at the point of sale; e.g., credit card reader,
electronic cash register, vending machine.
post-issuance update A command sent by the issuer through the terminal via an authorization
response to update the electronically stored contents of a chip card.
PPSE Proximity Payment Systems Environment
Pre-processing Reader Preliminary Transaction Processing

Glossary
Term Definition
private key As part of an asymmetric cryptographic system, the key that is kept secret
and known only to the owner.
Proximity In this document, refers to contactless technology as described in [EMV CL

PAYMENT] Book D.
Proximity Card (PICC) Identification cards of the card type ID-1 (full size card) operating in
proximity to a coupling device.
Proximity Coupling Device (PCD) The reader/writer device (for example, a dongle) that uses inductive
coupling to provide power to the Consumer Device and also to control the
data exchange with the Consumer Device.
Proximity Payment Systems A list of supported Application Identifiers (AIDs), Application Labels, and
Environment (PPSE) Application Priority Indicators for applications that are accessible over the
contactless interface. This list will be provided by the card in FCI with all
directory entries in the card response to SELECT of the PPSE
('2PAY.SYS.DDF01').
PSE Payment System Environment
PSN Application PAN Sequence Number
public key As part of an asymmetric cryptographic system, the key known to all
parties.
public key cryptographic algorithm A cryptographic algorithm that allows the secure exchange of information,
but does not require a shared secret key, through the use of two related
keys—a public key which may be distributed in the clear and a private key
which is kept secret.
public key pair The two mathematically related keys, a public key and a private key which,
when used with the appropriate public key cryptographic algorithm, can
allow the secure exchange of information, without the secure exchange of
a secret.
purchase transaction A retail purchase of goods or services; a point-of-sale transaction.
PVKI PIN Verification Key Index
PVV PIN Verification Value
Q
quasi-cash transaction A transaction representing a merchant’s sale of items, such as gaming chips
or money orders, that are directly convertible to cash.
quick VSDC (qVSDC) VIS minimized to ensure quick transactions over the contactless interface.
Requirements are described in this document.
qVSDC quick Visa Smart Debit/Credit
qVSDC-enabled Card/reader has implemented qVSDC, and has been

personalized/configured to enable the qVSDC Path.
qVSDC-only Card/reader supports qVSDC and does not support MSD.

Glossary
Term Definition
qVSDC Path For transactions conducted over the contactless interface, the qVSDC Path
is an application path taken by the card which results in card behavior
defined for qVSDC. This path is taken for contactless transactions where
the card and reader both support qVSDC.
The qVSDC Path supports only the contactless interface.
R
R required
RCTL Reader Contactless Transaction Limit
Reader The merchant device communicating with the card.

See section 3.1.4.1 for additional information.
Reader Risk Parameter Reader parameters used to perform reader risk management during
Reader Preliminary Transaction Processing (Pre-processing).
Reader Limit Set An acquirer-merchant configurable combination of Reader Risk Parameters

to be used during Reader Risk Parameters Checking. The acquirer-
merchant is able to enable or disable the individual Reader Risk Parameters
in the Reader Limit Set, and to set the value of any corresponding limits.
receipt A paper record of a transaction generated for the cardholder at the point
of transaction.
RF Radio Frequency
RFU Reserved for Future Use
RID Registered Application Provider Identifier
RSA A public key cryptosystem developed by Rivest, Shamir, and Adleman

(RSA), and used for data encryption and authentication.
S
SAD Signed Static Application Data
SD Special Device
SDA Static Data Authentication
SDAD Signed Dynamic Application Data
secret key A key that is used in a symmetric cryptographic algorithm (that is, DES),
and cannot be disclosed publicly without compromising the security of the
system. This is not the same as the private key in a public/private key pair.
secure messaging A process that enables messages to be sent from one entity to another,
and protects against unauthorized modification or viewing.
session key A temporary cryptographic key computed in volatile memory and not valid
after a session is ended.
SFI Short File Identifier
SHA-1 Secure Hash Algorithm

Glossary
Term Definition
Single Unit of Currency A single unit of currency is one unit of that currency. One dollar U.S.
currency, for example, or one pound in British currency. A transaction
containing a single unit of currency is used at some merchants to indicate a
Status Check on the account.
Start Sentinel Indicator at the beginning of Track 1 or Track 2 on the magnetic stripe.
Static Data Authentication (SDA) A type of Offline Data Authentication where the terminal validates a
cryptographic value placed on the card during personalization. This
validation protects against some types of counterfeit, but does not protect
against skimming.
Status Check An online authorization for a single unit of currency. In some markets,
status checks are used as authorizations for automated fuel dispensing,
implicitly allowing up to a set amount to be used. The use of status checks
is limited to automated fuel dispensing.
Status Word SW1 and SW2, collectively.
SW1 SW2 Status Byte One and Status Byte Two
T
TAC Terminal Action Codes
TAL Terminal Application Layer
TC Transaction Certificate
TLV Tag Length Value
transaction An exchange of information between a cardholder and a merchant or an

acquirer that results in the completion of a financial transaction.
Transaction Certificate An Application Cryptogram generated when accepting a transaction.
Triple DES The data encryption algorithm used with a double-length DES key.
TSI Transaction Status Information
TTQ Terminal Transaction Qualifiers
TVR Terminal Verification Results
U
UDK Unique Derivation Key
UDKA Unique Derivation Key A
UDKB Unique Derivation Key B
Unique Derivation Key A card-unique double-length DES key derived from a master key and used
in online card authentication.
V
VCPS Visa Contactless Payment Specification

Glossary
Term Definition
VCPS Transaction A transaction conducted over the contactless interface in compliance with
this specification.
VIS Visa Integrated Circuit Card Specification
VIS Path For transactions conducted over the contact interface, the VIS Path is an
application path taken by the card which results in card behavior defined
for VIS.
The VIS Path supports only the contact interface.
Visa AID An AID using the Visa Registered Application Provider Identifier (RID,
'A0 00 00 00 03') that has a Proprietary Application Identifier Extension
(PIX) assigned by Visa International.
Visa PIXs:
'1010' – Visa Debit and Visa Credit
'2010' – Visa Electron
'3010' – Interlink
'8010' – PLUS
Regional AIDs using the reserved range of Visa assigned PIXs are
permitted.
Visa Certificate Authority (CA) A Visa-approved organization certified to issue certificates to participants
in a Visa payment service.
Visa Contactless Payment A Visa specification defining requirements for conducting a payment
Specification (VCPS) transaction over a contactless interface.
Visa Smart Debit/Credit (VSDC) The Visa payment service offerings for chip-based debit and credit
programs. These services are supported by VisaNet processing, as well as
by Visa rules and regulations; and are based on EMV and VIS, VCPS, or EMV
Common Core Definitions (CCD) – including Common Payment Application
(CPA) – specifications.
VisaNet The systems and services, including the V.I.P. and BASE II systems, through
which Visa delivers online financial processing, authorization, clearing, and
settlement services to customers.
VLP Visa Low-value Payment
VSDC Visa Smart Debit/Credit
W
X
XOR Exclusive-OR
Y
YDDD Year, day:
Y right-most digit of the year (‘0’–’9’)
DDD Julian day of the year (‘001’–’366’)

Glossary
Term Definition
YYMM Year, month:

YY year (‘00’–’99’)
MM month (‘01’–’12’)
YYMMDD Year, month, day:

YY year (‘00’–’99’)
MM month (‘01’–’12’)
DD day (‘01’–’31’)


VCPS 2.2 Jan2016

Uploaded by

Copyright:

Available Formats

VCPS 2.2 Jan2016

Uploaded by

Document Information

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

VCPS 2.2 Jan2016

Uploaded by

Copyright:

Available Formats

Visa Contactless Payment

© 2007-2016 Visa. All Rights Reserved.

Notice: This information is proprietary and CONFIDENTIAL to Visa. It is distributed to Visa

THE INFORMATION CONTAINED HEREIN IS PROPRIETARY AND CONFIDENTIAL AND MUST BE

Contents ............................................................................................................................................................ iii

January 2016 Visa Confidential iii

iv Visa Confidential January 2016

5.5.2 Directory Selection Method using PPSE ........................................................................................28

January 2016 Visa Confidential v

vi Visa Confidential January 2016

D.2 Data Element Tags ...................................................................................................................................... 175

January 2016 Visa Confidential vii

viii Visa Confidential January 2016

Table 6–1: Minimum PDOL Content ................................................................................................................59

Figure 4–1: Sample Transaction Flow ................................................................................................................15

January 2016 Visa Confidential ix

Req 4.1 (Transaction Timing)................................................................................................................ 16

x Visa Confidential January 2016

January 2016 Visa Confidential xi

xii Visa Confidential January 2016

January 2016 Visa Confidential xiii

xiv Visa Confidential January 2016

January 2016 Visa Confidential xv

xvi Visa Confidential January 2016

1.1 <This section has been deleted>

1.2 qVSDC – Quick Visa Smart Debit/Credit

The requirements for qVSDC are defined in this document.

January 2016 Visa Confidential 1

Contactless VSDC and MSD are no longer supported in this specification.

2.3 Reference Materials

The following documents are referenced in this specification.

2 Visa Confidential January 2016

[EMV Tokenisation] EMV Payment Tokenisation Specification; latest version available on

[ISO 7811] ISO/IEC 7811. Identification Cards – Recording Technique.

[VPTSM] Visa Payment Technology Standards Manual – Describes the standards

January 2016 Visa Confidential 3

3 Terminology and Conventions

3.1 Terminology and Notation

This specification uses the following terminology and notations.

3.1.1 Requirement Terminology

The terminology for requirements is as follows:

3.1.2 Reader Processing Terminology

4 Visa Confidential January 2016

3.1.3 Implementation and Support Terminology

January 2016 Visa Confidential 5

3.1.4 Card and Reader Terminology

No required implementation shall be implied from this specification perspective.

3.1.5 “Else” with Parenthesized Text

Ex. If Condition, then the card shall…

Else (Text), the card shall…

6 Visa Confidential January 2016

3.1.6 Presence of Data Elements

3.1.7 Format of Indicators

3.1.8 Value Representation

0 to 9 10 decimal digits. Decimal numbers are not enclosed in quotation marks.

3.1.9 Coding of RFU Values in Data Elements

8 Visa Confidential January 2016

4 Overview of the Contactless Approach

4.1 Contactless Programs and EMV