Visa Smart Debit/Credit

Acquirer Device Validation Toolkit User Guide

Version 7.0

Publication Date: 31 August 2017

Important Information on Confidentiality and Copyright

© 2004-2017 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.

The trademarks, logos, trade names and service marks, whether registered or unregistered (collectively
the “Trademarks”) are Trademarks owned by Visa. All other trademarks not attributed to Visa are the
property of their respective owners.

Note: This document is not part of the Visa 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 Rules, the Visa Rules
shall govern and control.
 Contents
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Contents
1 Acquirer Device Validation Toolkit (ADVT) User Guide Introduction ...................................................... 1
1.1 Introduction ...................................................................................................................................................................... 1
1.2 Contact Information ...................................................................................................................................................... 2
1.2.1 General Information and Support..................................................................................................................... 2
1.2.2 Ordering Toolkits .................................................................................................................................................... 2
1.3 Summary of Changes introduced in this Version ............................................................................................... 3
1.4 ADVT Support Documentation ................................................................................................................................. 4
1.5 Disclaimer .......................................................................................................................................................................... 5
2 Acquirer Device Validation Toolkit User Guide Overview.......................................................................... 6
2.1 Objective ............................................................................................................................................................................ 6
2.2 Audience ............................................................................................................................................................................ 6
2.3 Document Organization............................................................................................................................................... 6
2.4 ADVT Components ........................................................................................................................................................ 8
2.5 ADVT Usage ...................................................................................................................................................................... 8
2.5.1 ADVT Usage Guidelines ........................................................................................................................................ 9
2.6 New ADVT Version ....................................................................................................................................................... 11
2.7 Scope of ADVT Testing............................................................................................................................................... 11
2.8 Future Enhancements ................................................................................................................................................. 12
2.9 Related Documents ..................................................................................................................................................... 13
2.10 EMVCo Level 3 Framework Compliance .............................................................................................................. 13
3 Test Cases Introduction ..................................................................................................................................... 16
3.1 Pre-requisites ................................................................................................................................................................. 16
3.1.1 Terminal Capabilities............................................................................................................................................ 16
3.1.2 Terminal Log ........................................................................................................................................................... 16
3.1.3 Host Log ................................................................................................................................................................... 17
3.1.4 Visa CA Test Public Keys ..................................................................................................................................... 17
3.1.5 Terminal Action Codes (TACs) .......................................................................................................................... 17
3.1.6 Configured for Operational Use ...................................................................................................................... 17

31 August 2017 Visa Confidential i

 Contents
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

3.1.7 EMVCo Level 1 and 2 Approval ....................................................................................................................... 17

3.2 Instructions...................................................................................................................................................................... 18
3.2.1 Mandatory vs. Conditional Test Cases .......................................................................................................... 18
3.2.2 Self-Administered Tool ....................................................................................................................................... 18
3.2.3 Initially Deployed Terminals .............................................................................................................................. 18
3.2.4 Previously Deployed Terminals ........................................................................................................................ 19
3.2.5 For Information Gathering Purposes Only Tests ....................................................................................... 19
3.2.6 Changes to Terminals .......................................................................................................................................... 19
3.2.7 Decline Responses vs. Other Errors ................................................................................................................ 19
3.2.8 Transaction Amount............................................................................................................................................. 19
3.2.9 PIN-Based Transactions ...................................................................................................................................... 20
3.2.10 ADVT Online Testing............................................................................................................................................ 21
3.2.11 Test Cards................................................................................................................................................................. 22
3.2.12 Simulators ................................................................................................................................................................ 22
3.2.13 Chip Compliance Reporting Tool (CCRT) ..................................................................................................... 23
3.3 Test Case Summary...................................................................................................................................................... 24
4 Test Cases ............................................................................................................................................................. 30
4.1 Test Case 1: Basic VSDC ............................................................................................................................................. 31
4.2 Test Case 2: 19-Digit Account Number ................................................................................................................ 34
4.3 Test Case 3: DDA, OEP, and Issuer Authentication .......................................................................................... 36
4.4 Test Case 4: Terminal Risk Management ............................................................................................................. 38
4.5 Test Case 5: Application Selection ......................................................................................................................... 39
4.5.1 Test Case 5: Expected Results ........................................................................................................................... 41
4.6 Test Case 6: Dual Interface ........................................................................................................................................ 43
4.7 Test Case 7: Terminal Action Codes (TACs) ........................................................................................................ 44
4.8 Test Case 8: Fallback .................................................................................................................................................... 46
4.9 Test Case 9: “Reserved for Future Use” CVM ..................................................................................................... 48
4.10 Test Case 10: CDA......................................................................................................................................................... 50
4.11 Test Case 11: Multiple Applications ....................................................................................................................... 52
4.12 Test Case 12: Proprietary Data and 6-Digit PIN ................................................................................................ 53
4.13 Test Case 13: Long PDOL and Unrecognized Tag ............................................................................................ 55

ii Visa Confidential 31 August 2017

 Contents
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

4.14 Test Case 14: Two Applications and Cardholder Confirmation................................................................... 56

4.15 Test Case 15: DDA with 1984 Certificate ............................................................................................................. 58
4.16 Test Case 16: Plus and Visa Interlink ..................................................................................................................... 60
4.17 Test Case 17: Visa Electron........................................................................................................................................ 62
4.18 Test Case 18: Combination CVM and Visa Fleet Chip..................................................................................... 64
4.19 Test Case 19: Account Number with Padded Fs ............................................................................................... 66
4.20 Test Case 20: No PAN Sequence Number .......................................................................................................... 68
4.21 Test Case 21: PAN Sequence Number of 11 ...................................................................................................... 70
4.22 Test Case 22: 1144-Bit Issuer Public Key.............................................................................................................. 72
4.23 Test Case 23: Single Application/Multiple Features ........................................................................................ 73
4.24 Test Case 24: Multi-application/Multiple Features .......................................................................................... 75
A Visa CA Test Public Keys for VSDC ................................................................................................................. 80
A.1 1152 Bit VSDC TEST Key ............................................................................................................................................. 80
A.2 1408 Bit VSDC TEST Key ............................................................................................................................................. 81
A.3 1984 Bit VSDC TEST Key ............................................................................................................................................. 82
B Terminal Action Codes (TACs)......................................................................................................................... 84
C VSDC Stand-in Processing Conditions .......................................................................................................... 86
D Merchant Terminal Environments .................................................................................................................. 90
D.1 Stand-Alone Terminals (SATs) ................................................................................................................................. 91
D.2 Stand-Alone Terminals (SATs) with Semi-Integrated Functionality .......................................................... 92
D.3 Fully Integrated Environments ................................................................................................................................. 93
E ADVT Testing Use Cases ................................................................................................................................... 96
E.1 Use Cases ......................................................................................................................................................................... 96
E.1.1General Terminal Use Cases ................................................................................................................................... 97
E.1.2Acquirer/Processor Platform Use Cases .......................................................................................................... 100
E.1.3System Integrator and Value-Added Reseller (VAR) Use Cases............................................................. 101
F Acronyms and Glossary................................................................................................................................... 102

31 August 2017 Visa Confidential iii

 Tables
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Tables
Table 1: Summary of Changes Introduced .................................................................................................... 3
Table 2: ADVT Support Documentation ........................................................................................................ 4
Table 1–1: Document Organization ..................................................................................................................... 6
Table 1–2: Scope of ADVT Testing...................................................................................................................... 12
Table 2–1: Test Case Summary ........................................................................................................................... 24
Table 3–1: Test Case 5: Expected Results ..........................................................................................................41
Table A–1: 1152 Bit VSDC Test Key ..................................................................................................................... 80
Table A–2: 1408 Bit VSDC Test Key ..................................................................................................................... 81
Table A–3: 1984 Bit VSDC Test Key .................................................................................................................... 82
Table B–1: Terminal Action Codes (TACs) ........................................................................................................ 84
Table C–1: VSDC Stand-In Processing Conditions ......................................................................................... 86
Table E–1: General Terminal Use Cases ............................................................................................................ 97
Table E–2: Acquirer/Processor Platform Use Cases ..................................................................................... 100
Table E–3: System Integrator and Value-Added Reseller (VAR) Use Cases ........................................... 101
Table F–1: Acronyms ........................................................................................................................................... 102
Table F–2: Glossary .............................................................................................................................................. 105

iv Visa Confidential 31 August 2017

 Figures
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Figures
Figure D–1: Stand-Alone Terminal ........................................................................................................................ 91
Figure D–2: Stand-Alone Terminal (SAT) with Cardholder-Facing Device ................................................. 91
Figure D–3: Stand-Alone Terminal (SAT) with Semi-Integrated Functionality ......................................... 92
Figure D–4: Integrated—POS to Acquirer .......................................................................................................... 93
Figure D–5: Integrated—In-Store Controller (ISC) to Acquirer .................................................................... 93
Figure D–6: Integrated—Regional Network Controller to Acquirer............................................................ 94

31 August 2017 Visa Confidential v

 Figures
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

vi Visa Confidential 31 August 2017

 VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

1 Acquirer Device Validation Toolkit (ADVT) User Guide

Introduction
This chapter provides the following information:
 Introduction to the Acquirer Device Validation Toolkit (ADVT) User Guide
 Contact Information
 Summary of Changes
 ADVT Support Documentation
 Disclaimer

1.1 Introduction

Visa Smart Debit/Credit (VSDC) provides a global chip-based payment service that allows clients to
position themselves strategically and competitively for the future. The program is based on the
underlying specifications developed by EMVCo LLC to ensure that all chip-based debit and credit cards
can be accepted in any EMV chip-reading terminal worldwide.

From an acquiring perspective, chip introduces additional features and complexities to the card
acceptance process. During a chip-based transaction, the card and terminal proceed through a series of
steps to determine the outcome of the transaction. These steps require additional data and processing
capabilities at the terminal level.

The interaction of cards issued in other countries and regions with a terminal deployed in a specific
location can often result in acceptance issues, even though both the cards and terminals would have
been EMV and Payment Scheme approved. These issues may often be the result of an incorrectly
configured terminal, inadequate integration testing, or misunderstandings about EMV and Visa
requirements.

To help ensure that terminals being deployed by acquirers do not unduly contribute to interoperability
problems, Visa has developed the Acquirer Device Validation Toolkit—a set of test cards or simulated
test cards and test cases. The toolkit should be used on new or upgraded EMV terminals to ensure
correct terminal configuration, to assist with Level 3 integration testing, and to ensure that Visa’s
terminal requirements are being met.

In addition to ensuring card acceptance, ADVT can also enable testing of the user interface of live
terminals. This is necessary to make sure that user prompts such as error messages, Application
Selection menus, and PIN Entry messages are appropriate and readily comprehensible to the cardholder
and merchant.

31 August 2017 Visa Confidential 1

 Acquirer Device Validation Toolkit (ADVT) User Guide Introduction
Contact Information

1.2 Contact Information

1.2.1 General Information and Support

Users of the ADVT that require general information on the tool or with support needs should contact
Visa at [email protected]

1.2.2 Ordering Toolkits

Toolkits supporting the ADVT may be obtained by contacting the third-party suppliers of those tools
directly. Visa publishes an ongoing list of confirmed suppliers that support both the card and host
simulation of the ADVT. This list in available by visiting the following link:
https://technologypartner.visa.com/Toolkits/#orderlist
Note #1: beginning with ADVT v7.0 (this version), the set of physical test cards that were previously
provided as an option for ADVT testing will no longer be available to order. Instead, users should access
the list of “Visa Confirmed Third-party Chip Tool Suppliers” on the Visa Technology Partner website for
Card Simulator options offered by the third-party test tool suppliers.
Note #2: Some of the Visa Confirmed Third-party Chip Tool Suppliers also provide physical test card
plastics as a complement to their existing simulation test tools. Users should make enquiries with the
test tool suppliers directly regarding this option.
Note #3: As an alternative to the set of physical test cards previously supplied by Visa to support ADVT
testing, Visa is currently working on an Android-based Mobile solution that will be available later in the
year. More details will be shared on this solution very shortly.

2 Visa Confidential 31 August 2017

 VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

1.3 Summary of Changes introduced in this Version

This section provides an overview of the changes made in this document since its last publication.
Table 1: Summary of Changes Introduced

Section Change Description

Section 2.5.1.1: ADVT Usage: Clarification  On the “Cash-back – Addition of Cash-back

Required functionality” bullet, clarification added
Section 2.10: Level 3 Addition  Add description of Level 3 EMVCo standardization
initiative
Section 3:3: Test Case Remove  Remove all references to Fall-back being optional
Summary – Test Case 8
Section 4: Test Cases Test Cases  Removal of the following test cases: 12, 15, 17, 21,
Removed 22 and 29 and all references to them
 Renumber cards following removals
Section 4: Test Cases New Test Case  Introduction of a new Test Case (# 24)
added
Section 4.2: Test Case 2 Updated  Updated wording to Business Justification
 Updated wording to Pass Criteria/User Validation
Section 4.8: Test Case 8 Updated  Updated wording in the “Objective” section
 Updated wording in the Pass Criteria/User
Validation” section
Section 4.10: Test Case 10 Updated Updated wording to Pass Criteria/User Validation
Section 4.15: Test Case 15 Updated “Note” added within Pass Criteria/User Validation
Section 4.22: Test Case 22 Updated “Note” added within Pass Criteria/User Validation

31 August 2017 Visa Confidential 3

 Acquirer Device Validation Toolkit (ADVT) User Guide Introduction
ADVT Support Documentation

1.4 ADVT Support Documentation

ADVT support documentation now consists of two documents:

 User Guide (this document)
 Card Profiles

The table below provides a description of each document, as well as a definition of the audience to
which each document applies.
Table 2: ADVT Support Documentation

Document Name Description Audience

Acquirer Device Validation This document provides: This document is primarily

Toolkit User Guide (This  An overview of the ADVT including a intended for users of the ADVT,
Document) description of the components and including acquirers, processors,
usage criteria merchants, and third party
service providers on behalf of
 Test cases
acquirers.
 Appendices providing details of the
Visa CA test keys, Terminal Action
Code (TAC) values, VisaNet Stand-in
(STIP) options, an overview of
merchant terminal environments, and
terminal testing use cases.
Acquirer Device Validation This document provides the details This document is intended for
Toolkit Card Profiles required to personalize each of the personalization bureaus and chip
ADVT test cards. tool vendors responsible for
developing ADVT test cards or
simulated/scripted equivalents.

4 Visa Confidential 31 August 2017

 VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

1.5 Disclaimer

The Acquirer Device Validation Toolkit described herein provides a means for a Visa Acquirer (or its
agent) implementing a chip program to test their EMV terminals before deployment. The tests
prescribed herein do not supersede the requirement for the terminals to undergo type approval testing
at an accredited EMVCo laboratory.

The Acquirer Device Validation Toolkit tests must be included in the project plan of the Visa Acquirer’s
migration to EMV, since they provide additional testing and review methods that are particularly
important after the terminal has been re-configured to suit the acquirer’s requirements.

The Acquirer Device Validation Toolkit test cards and test cases are designed to determine whether the
EMV terminal can process certain card profiles that are known to cause acceptance issues. Visa reserves
the right to add or remove tests and test requirements in its sole discretion.

The Acquirer Device Validation Toolkit is provided as a service to Acquirers to help reduce card
acceptance problems. Visa does not warrant the Toolkit or any Toolkit test results for any purpose
whatsoever, and expressly disclaims any and all warranties relating to the Toolkit. No vendor or other
third party may refer to a product, service or facility as “Visa-approved”, nor otherwise state or imply
that Visa has, in whole or part, approved any aspect of a vendor or its products, services or facilities,
except to extent and subject to the terms and restrictions expressly set forth in a written agreement with
Visa or in an approval letter provided by Visa. All other references to “Visa approval” are strictly
prohibited by Visa.

Note: With the announced reunification of Visa Inc. and Visa Europe in June 2016, any references to the
Visa Core Rules and Visa Product and Service Rules in this document apply both to clients in the Europe
region (intra-regional rules), as well as to all other clients and location-specific rules for other Visa
regions.

31 August 2017 Visa Confidential 5

 Acquirer Device Validation Toolkit User Guide Overview
Objective

2 Acquirer Device Validation Toolkit User Guide Overview

This section provides an overview of the Acquirer Device Validation Toolkit and its associated User
Guide (this document).

2.1 Objective

The objective of this document is to define a toolkit that enables Level 3 chip terminal integration
testing. It is intended to provide Visa acquirers with a high level of confidence that the chip terminals
they are deploying will not unduly contribute to interoperability problems.

2.2 Audience

The audience for this document is Visa acquirers, their agent(s), and third-party service providers
responsible for deploying terminals in their marketplace that accept Visa Smart Debit/Credit (VSDC)
cards. It shall not be shared with or distributed to any other parties.

The term acquirer in this document is used generically to represent the entity in the marketplace
responsible for terminal deployment. Depending on the marketplace, it could represent the acquirer,
acquirer processor, merchant, or a third party service provider on behalf of an acquirer or merchant.

2.3 Document Organization

This document contains the following chapters:

Table 2–1: Document Organization

Chapter Title Description

1 Acquirer Device Validation Toolkit This chapter provides background information highlighting
(ADVT) User Guide Introduction the need for the ADVT. It also includes:
 Contact Information
 Summary of Changes
 Disclaimer
2 Acquirer Device Validation Toolkit This chapter provides an overview of the document
(ADVT) User Guide Overview including objective, audience, document organization,
components, usage, scope, and related documents.

6 Visa Confidential 31 August 2017

 Acquirer Device Validation Toolkit User Guide Overview
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Chapter Title Description

3 Test Cases Introduction This chapter introduces the test cases. It includes pre-
requisites that need to be in place before testing can begin
as well as instructions for performing ADVT tests.
4 Test Cases This chapter outlines each ADVT test case, its associated
test card, objective, business justification, applicable
terminal device type, document reference, and pass
criteria/user validation.
Appendix Visa CA Test Public Keys for VSDC This appendix provides the VSDC public test keys that need
A to be loaded into the terminal to support the tests
associated with Offline Data Authentication (ODA) and
Offline Enciphered PIN.
Appendix Terminal Action Codes (TACs) This appendix outlines the Terminal Action Codes (TACs)
B that need to be configured in the terminal to comply with
Visa rules.
Appendix VSDC Stand-in Processing This appendix provides the VSDC Stand-in processing
C Conditions conditions that can be used to provide valuable insight into
the reason that VisaNet Certification Management Service
(VCMS)/Visa Member Test System (VMTS) either approved
or declined an online-initiated transaction.
Appendix Merchant Terminal Environments This appendix provides an overview of some of the most
D commonly configured terminal infrastructures at the
merchant level.
Appendix ADVT Testing Use Cases This appendix provides use cases in a Questions & Answers
E format that address commonly asked questions related to
ADVT usage.
Appendix Acronyms This appendix provides a list of commonly used acronyms
F in this User Guide and in the EMV environment.

31 August 2017 Visa Confidential 7

 Acquirer Device Validation Toolkit User Guide Overview
ADVT Components

2.4 ADVT Components

The ADVT consists of:

 Test Card Simulator— Supplied by third party providers, these tools are confirmed by Visa as
being capable of simulating the images and behaviors of the ADVT card profiles, as defined in the
ADVT Card Profiles document.
 Documentation—Two documents:
- ADVT User Guide (This Document)—A document that outlines each test case, a description
of the test card to be used with each test case, and the expected test results. This document is
used by the acquirer or acquirer’s agent to perform Level 3 chip terminal integration testing.
- ADVT Card Profiles (Separate Document)—A document that outlines the card
personalization requirements for each test card image that can be used by card
personalization bureaus and card simulator vendors to either personalize the physical test
cards or to develop scripts that simulated test card behaviors.
 ADVT Level 3 Test Card Images—A set of XML-formatted machine-readable test card images,
compliant with the EMVCo Level 3-defined format, and representing each of the ADVT card
images and expected behaviors. These images are intended for use in conjunction with EMVCo-
qualified test card simulators.

2.5 ADVT Usage

Important: An acquirer must utilize the ADVT before deploying a new chip acceptance device or after
performing significant upgrades to an existing device.

As described in the Visa Core Rules and Visa Product and Service Rules (formerly Visa International
Operating Regulations) and the Visa Europe Operating Regulations, an acquirer that fails to utilize the
ADVT on a device that later causes a chip interoperability issue, may be subject to fines and penalties
as defined in the Visa Chip Interoperability Compliance Program.

Note: There is no Visa requirement that ADVT testing must be conducted for each merchant location;
however, testing is required for each unique terminal configuration.

Acquirers are required to use the ADVT before initial terminal deployment (including all variations of
hardware, software, and parameter settings) to ensure that the terminal has been set up and configured
correctly. It is expected that acquirers will run each applicable test to gain the full benefit of the ADVT.
When a test result does not match the required outcome (“Expected Results”) of the test, it is anticipated
that the acquirer will work with its technical support team (and Visa, if necessary) to correct the problem.
The acquirer will continue to perform the test until the problem is resolved and the acquirer’s result
matches the Expected Results.

8 Visa Confidential 31 August 2017

 Acquirer Device Validation Toolkit User Guide Overview
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

In addition, since new versions of the ADVT are periodically released by Visa, it is always good practice
for acquirers to use the most recent version on terminals already deployed in the field. This helps to
further minimize potential acceptance problems with those previously deployed terminals.

2.5.1 ADVT Usage Guidelines

This section outlines the scenarios where ADVT usage is:

 Required
 Recommended
 Not Required

Where ADVT usage is required, the latest version of the ADVT shall always be used. If this is not possible
due to upgrade schedules, etc., ADVT users must consult with their Visa representative to determine
regional policies regarding proposed use of an earlier version of the ADVT.

Note: If the device integrator wishes to see the ADVT test results recognized in multiple regions, they
will need to submit a request to Visa. Granting the request is at the sole discretion of Visa, and
may not be allowed under regional policies. If the request is accepted, the compliance report will
be accessible via Chip Compliance Reporting Tool (CCRT). For information on CCRT, refer to
Section 3.2.13: Chip Compliance Reporting Tool.

Refer to Appendix E: ADVT Testing Use Cases for further information.

2.5.1.1 ADVT Usage: Required

This section outlines scenarios where use of the ADVT is required:

 New Device—Deployment of a new EMV card accepting device containing any of the following:
- New EMV kernel
- New version of payment application
- New terminal-to-host message protocol
 Modified Device—Modification or reconfiguration of an existing device to make any of the
following changes:
- Major changes to the EMV-approved kernel (as defined in EMV Bulletin 11 available on
www.emvco.com)
- Changes to the payment component of the terminal application, affecting EMV processing
- Changes to the Cardholder Verification Method (CVM) capabilities
 Merchant/Acquirer Network Architecture Change—Changes to a merchant or acquirer’s
network architecture. For example, in a case where a merchant has switched acquirers, even
though their terminal configuration might remain the same.

31 August 2017 Visa Confidential 9

 Acquirer Device Validation Toolkit User Guide Overview
ADVT Usage

 New Terminal Hardware Model—Introduction of a new model1 of terminal hardware.

 Dynamic Currency Conversion—Introduction of Dynamic Currency Conversion (DCC)
functionality.
 Cash-Back—Addition of cash-back functionality.
(Note: Since Cash-back is a domestic-only service, the intention here is not that ADVT should be
used to perform Cash-back testing (as in most cases there will be a mismatch between the
Terminal Country and Issuer Country Code), but that if the “Cash-back functionality” is added to
the terminal following initial ADVT testing, then ADVT testing should be repeated. )
 Visa Request—As requested by Visa based on evidence of an acceptance or interoperability
problem affecting the device or connectivity to VisaNet.

2.5.1.2 ADVT Usage: Recommended

This section outlines scenarios where use of the ADVT is recommended:

 Acceptance/Interoperability Problem—A strong suspicion by Visa or an acquirer of the presence
of an acceptance or interoperability problem affecting the device or connectivity to VisaNet.
 Minor Modifications—Minor modifications or reconfiguration of existing terminals for any of the
following:
- Change of Language Support
- New communications interface (e.g., from dial-up to high-speed)
- Upgrades or modifications to the acquirer host systems which affect the transmission of chip data
(at a minimum, the ADVT online tests must be performed on at least one EMV chip-reading device;
refer to Section 3.2.10: ADVT Online Testing for further information)

2.5.1.3 ADVT Usage: Not Required

This section outlines scenarios where use of the ADVT is not required:
 Terminal in Same Family—On individual terminals that all fall within the same terminal family
(e.g., payment application, EMV kernel, and chip transaction flows are all the same). Consult with
your terminal supplier to verify that the terminals fall within the same terminal family.
Note: Third party processors implementing “terminals in the same family” for different clients
within the same country or for different clients in a different country are not required to use the
ADVT on these devices.

1
It is possible to have “families” of terminals which are identical from a payment point of view. Here a new “model” is taken
to mean a change which may affect card acceptance. This includes the user interface presented to either the cardholder or
merchant.

10 Visa Confidential 31 August 2017

 Acquirer Device Validation Toolkit User Guide Overview
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

 Currency Code/Country Code Change—Change of supported Currency Code/Country Code on

the same acquirer host platform. If on a different host platform or different protocol, testing is
required.
 Minor EMV Kernel Changes—Minor changes to the EMV-approved kernel (as defined in
EMV Bulletin 11 available on www.emvco.com).
Note: Replacing the Interface Modules (IFM) with another approved module is defined as a minor
change.
 Non-Payment Processing Software Change—Change to software that does not affect payment
processing (e.g., screen layout and report generation on a POS terminal, advertising graphics on
an ATM).
 New Peripheral Device—Addition of a new peripheral device not requiring changes to the
existing code (e.g., a new printer or cash dispenser module).
 Online PIN-Only PIN Entry Device (PED)—Addition of a new Online PIN-only PED.
 Terminal-to-Host Message Protocol Change—Change to the terminal-to-host message
protocol, which does not affect authorization messages.
 CA Public Key Change—Change to CA Public Keys used for Offline Data Authentication (ADVT
testing does not use production keys).
 New Version of ADVT—Introduction of a new version of ADVT by Visa provided the device has
already undergone successful validation using an earlier version of ADVT in accordance with these
guidelines.

2.6 New ADVT Version

On release of a new version of the ADVT, acquirers will be given a six-month grace period to upgrade
to the new version. During this grace period, testing will still be allowed with their existing version of
the ADVT. However, on expiration of the grace period, it is expected that acquirers will have completed
their upgrade to the latest version of the ADVT and results from earlier versions will no longer be
accepted.

Some Visa regional offices, however, may apply stricter policies governing the period by which earlier
versions of the ADVT must be phased out and replaced by the most recent version. Contact your Visa
representative for details.

2.7 Scope of ADVT Testing

This section outlines the scope of ADVT testing comparing it to both acquirer host certification and
EMV-Level 2 testing.

31 August 2017 Visa Confidential 11

 Acquirer Device Validation Toolkit User Guide Overview
Future Enhancements

Table 2–2: Scope of ADVT Testing

Within Scope Out of Scope Explanation

Terminal Testing Acquirer Host The ADVT focuses on helping to ensure terminals deployed
Certification in the field are configured in a way that promotes the best
potential for global interoperability.
While some of the cards in the ADVT are to be used for
online testing, the ADVT is not specifically designated as a
host certification toolkit. Acquirers will continue to perform
host system certification using current procedures. Contact
your Visa representative to obtain the requirements for
acquirer host certification.
Complement to Replacement of It is assumed that acquirers and/or terminal vendors will
EMV Level 2 Testing EMV Level 2 Testing perform these tests on terminals that have already passed
EMV Level 1 and Level 2 testing. ADVT complements EMV
testing to ensure that terminals have been configured
correctly prior to deployment.

2.8 Future Enhancements

The ADVT may be expanded in the future to include additional device and/or online tests.

12 Visa Confidential 31 August 2017

 Acquirer Device Validation Toolkit User Guide Overview
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

2.9 Related Documents

This section lists documents that may be read and/or referred to in conjunction with this document:
 Europay, MasterCard, Visa (EMV) (latest version)
 Visa Core Rules and Visa Product and Service Rules (formerly Visa International Operating
Regulations) (latest version)
 Visa Europe Operating Regulations (latest version)
 Transaction Acceptance Device Requirements (TADR)—Requirements (latest version)
 Transaction Acceptance Device Guide (TADG)—Requirements and Best Practices (latest version)
 EMV Level 3 Testing Framework – Process Enhancements (latest version)
 EMV Level 3 Testing Framework – Implementation Guidelines (latest version)

2.10 EMVCo Level 3 Framework Compliance

Visa, along with the five other EMVCo member Payment Networks, embarked on a series of Level 3
process alignment initiatives that started back in September 2013. Under the leadership of the EMVCo
Level 3 Testing Group (L3TG), various payment networks’ testing processes for the integration of EMV
contact and contactless acceptance devices are currently being aligned. Recent L3TG efforts have led
to the publication of the EMV Level 3 Testing Framework – Process Enhancements and the EMV Level 3
Testing Framework – Implementation Guidelines definition documents, both of which collectively define
standardized methods for L3 test tool development, qualification and usage.

The main impacts of these initiatives on Visa’s ADVT processes will be on:
 The standardized format in which the ADVT Test Cases are being presented (section 4 of this
document)
 The Use Case Q&A’s presented in Appendix E of this document – being consistent across all EMVCo
Payment Networks
 The L3 Card Simulator used by clients to perform ADVT testing – these tools are being enhanced
with a standardized L3 platform, as defined by EMVCo. This approach enables the standardized:
- Provision of Payment Networks’ test requirements in a machine-readable format
- Presentation of an L3 Test Selection Engine (TSE) where clients define their EMV terminal
configuration details. This in turn enables the Card Simulator to systematically determine and
present the applicable test cases for execution
- Determination of the L3 Pass/Fail Results in an automated way, following test case execution,
and subsequently the reporting of those results in a standardized format along with the
supporting Transaction Logs.

31 August 2017 Visa Confidential 13

 Acquirer Device Validation Toolkit User Guide Overview
EMVCo Level 3 Framework Compliance

For more information on EMVCo’s L3TG efforts, or to download any of the relevant documentation,
please visit the EMVCo website at the following link: http://www.emvco.com/approvals.aspx?id=272

14 Visa Confidential 31 August 2017

 Acquirer Device Validation Toolkit User Guide Overview
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

31 August 2017 Visa Confidential 15

 Test Cases Introduction
Pre-requisites

3 Test Cases Introduction

This chapter introduces the test cases. It includes pre-requisites that need to be in place before testing
can begin as well as instructions for performing ADVT tests.

3.1 Pre-requisites

Prior to running the ADVT test cases, acquirers must ensure that the prerequisites in this section are
fulfilled.

3.1.1 Terminal Capabilities

Before beginning any of the tests, it is important to understand the capabilities of your terminal. This
will help you ensure you are performing the tests correctly for your specific device.
 Terminal Type—Determine if your terminal is an Automated Teller Machine (ATM) machine,
stand-alone Point of Sale (POS) device, integrated POS device, or Cardholder Activated Terminal
(i.e., an unattended device).
 Cardholder Verification Methods—Determine the Cardholder Verification Methods that your
terminal supports: Online Personal Identification Number (PIN), Offline Enciphered PIN, Offline
Plaintext PIN, Signature, No CVM Required (this CVM allows you to accept a card without any
verification of the cardholder). This is important since the expected results associated with some of
the tests is specific to the Cardholder Verification Method.
 Offline Data Authentication—Determine if your terminal supports Static Data Authentication
(SDA), Dynamic Data Authentication (DDA), and/or Combined Dynamic Data
Authentication/Generate Application Cryptogram (CDA). This is important since the expected
results associated with some of the tests is specific to Offline Data Authentication.
 Floor Limit—Determine the floor limit of your terminal. For devices with a floor limit, always use
an amount below the floor limit during testing unless the test case description specifically states
that it must go online.
Note: by referencing its Floor Limit there is often an implication that the terminal could be
configured to enable offline capability (i.e. by setting a non-zero floor limit). It should be noted
here that references to Online-only terminals generally imply either (a) a terminal with a Floor
Limit permanently set to zero, or (b) a terminal not supporting a Floor Limit.

3.1.2 Terminal Log

It is very useful to the testing process for the terminal to have the ability to make the values of certain
data objects (such as the Terminal Verification Results (TVR) and Transaction Status Information (TSI))

16 Visa Confidential 31 August 2017

 Test Cases Introduction
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

generated during the transaction available to the tester. This could take the form of a log file or some
means of printing this information on a receipt or displaying it on the screen.

3.1.3 Host Log

In some cases, a log produced through online interaction between the acquiring host and the test system
acting as the Visa network is required.

Since some Visa regions require the submission of transaction logs during ADVT results reporting,
clients should consult with their respective regions on the policies related to log submission.

3.1.4 Visa CA Test Public Keys

During use of the ADVT, terminals that support offline functionality (e.g., Offline Data Authentication,
Offline Enciphered PIN) must be configured with the Visa CA Test Public Keys. These test keys are located
in Appendix A: Visa CA Test Public Keys for VSDC.

Important: Prior to terminal deployment, the acquirer must ensure that the Visa CA Test Public Keys
are removed from the terminals and the production Visa CA Public Keys are installed.

3.1.5 Terminal Action Codes (TACs)

Visa supports one set of TACs for acquirers. The TACs must be loaded into the terminal and acquirers
must ensure that the TAC settings are correct. The TAC settings are provided in Appendix B: TAC
Settings. See also, Transaction Acceptance Device Requirements (latest version).

3.1.6 Configured for Operational Use

The terminals must be configured for operational use. For example, the terminal must include the Visa
Application Identifiers (AIDs) (for Visa Credit/Debit and Visa Electron, where appropriate), terminal
country code, correct date/time, and floor limits.

3.1.7 EMVCo Level 1 and 2 Approval

In accordance with Visa rules, EMV card acceptance devices must be EMV-Compliant and approved by
EMVCo prior to deployment. Both the Level 1 (IFM) and Level 2 (Kernel) approval references must be
valid (not expired) at the time of deployment.

31 August 2017 Visa Confidential 17

 Test Cases Introduction
Instructions

3.2 Instructions

This section provides instructions for using the ADVT.

3.2.1 Mandatory vs. Conditional Test Cases

ADVT 7.0 contains 24 test cases.

Important: All devices must perform all applicable ADVT test cases, with the following exceptions:

Test Case Test Case Description Requirement

4 Terminal Risk Management Only applicable to devices that support Terminal Risk
Management
16 Plus and Interlink Only applicable to devices that support Plus and/or Interlink
17 Visa Electron Only applicable to devices that support Visa Electron
22 1144-Bit Issuer Public Key Only applicable to devices that support SDA

Important: Although all test cases (except for 4, 16, 17 & 22) are mandatory for all devices, their
expected results may differ based on the device’s capabilities. For example, for a test that focuses on
Combined DDA/AC Generation (CDA) (Test Case 10), the expected results differ depending on whether
or not the device supports CDA:
 Devices Supporting CDA—must successfully perform CDA.
 Devices that do not Support CDA—CDA is not applicable but the device must perform a
complete transaction without any errors. This ensures that even though the device does not
support CDA, a card with CDA does not pose any acceptance problems for the device.

3.2.2 Self-Administered Tool

The ADVT is a self-administered tool. Users must work to fix the problems on their own or with the help
of their service providers whenever possible, and only use Visa assistance for problems that cannot be
resolved between the terminal vendor and the acquirer’s technical team.

3.2.3 Initially Deployed Terminals

For terminals being initially deployed, the intent is for acquirers to run each applicable test and make
modifications to the terminal configuration until the terminal meets the expected results of the test.
Acquirers need to run these tests on each terminal type as well as each terminal hardware and/or
software configuration.

18 Visa Confidential 31 August 2017

 Test Cases Introduction
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

After running all tests and making the appropriate terminal configuration modifications, acquirers need
to submit their results to Visa in accordance with the information outlined in Section 3.2.13: Chip
Compliance Reporting Tool.

See “For Information Gathering Purposes Only Tests” for the test scenarios that do not require acquirer
action.

3.2.4 Previously Deployed Terminals

If there is a need to perform ADVT testing on terminals that have already been deployed, acquirers
should run all relevant tests, gather the results, and report them to Visa in accordance with the
information outlined in Section 3.2.13: Chip Compliance Reporting Tool.

3.2.5 For Information Gathering Purposes Only Tests

Occasionally, select test cases in the ADVT may be defined as “for information gathering purposes only.”
If a terminal fails any of these tests, acquirer action to resolve the issue is not always necessary.

However, there may be some instances where Visa strongly recommends an update to the terminal to
comply with the test case. Oftentimes, this is because the functionality, although currently optional, may
later become mandatory; in all cases, the acquirer must submit the test result to Visa.

3.2.6 Changes to Terminals

If changes are made to terminal configuration or settings, the acquirer/tester must re-run the ADVT
tests as described in Section 2.5.1: ADVT Usage Guidelines.

3.2.7 Decline Responses vs. Other Errors

A decline response is different from an error message. In some cases, a decline response by the terminal
is an acceptable outcome of the test case. Error messages, where the terminal is unable to complete the
transaction (e.g., unable to perform a complete EMV transaction from Application Selection to
Completion), are generally unacceptable and can indicate a problem with the terminal or an incorrect
terminal setting/configuration. Testers should not be alarmed if decline responses occur (as long as a
decline is allowed in the expected results) but must investigate error messages (such as “Card Error” and
“Not Accepted” or the equivalent). For further information on these error messages, refer to EMV 4.3,
Book 4 - Section 11.2: Standard Messages.

3.2.8 Transaction Amount

31 August 2017 Visa Confidential 19

 Test Cases Introduction
Instructions

For terminals with offline authorization capability, it is recommended to enter an amount below the
floor limit. Where the test requires an online transaction, an amount above the floor limit should be
entered.

3.2.9 PIN-Based Transactions

For Offline or Online PIN, a PIN value of ‘1234’ must be used, except for Test Case 12, which uses a PIN
of ‘123412’.

Note: When PIN is used for the transaction, the signature line does not need to be printed on the
receipt (if applicable) nor obtained from the cardholder (unless the combination CVM of Offline
PIN and signature applies).

20 Visa Confidential 31 August 2017

 Test Cases Introduction
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

3.2.10 ADVT Online Testing

In this version of the ADVT, 11 test cases (1, 2, 3, 12, 16, 19, 20, 21, 22, 23 and 24) are designated for
online testing. These tests are identified in Table 2-1: Test Case Summary and in Chapter 4: Test Cases.

Note: Although the test cases identified above are specifically designated for ADVT online testing, other
ADVT test cases are not precluded from being completed online. For example, in the case of an Online-
only device, all ADVT test cases will be completed online. Where VCMS or VMTS (see below) is used for
testing the tester may provide a Retrieval Reference Number (RRN) as additional evidence that a
transaction was completed successfully.

This section outlines the requirements for ADVT Online Testing:

 Devices—All online-capable devices must perform these tests. This includes:
- POS devices that support both offline and online transactions
- Zero floor limit POS devices
- ATMs
 Connection to VCMS/VMTS/Test-Host Simulator—Online-capable devices must connect their
device to their test host system and generate transactions through one of the following:
- VisaNet Certification Management Service (VCMS) (for Visa Inc. clients)
- Visa Member Test System (VMTS) (for clients in the European region)
- Visa-confirmed third party supplied test-host simulator which mimics VCMS/VMTS
(refer to Section 3.2.12: Simulators for information on third party test-host simulators)
Note: If a third party supplied test-host simulator is used, a VCMS log is not available for
review.
 Online Card Authentication—Online Card Authentication (i.e., ARQC validation) must be
performed and be successful (Field 44.8 = 2 in the auth response message).
 Retrieval Reference Number (RRN)/Host Logs—Additional requirements for ADVT online
testing (such as providing an RRN or submitting host logs) may apply and, if applicable, must be
submitted in the compliance report via the Chip Compliance Reporting Tool. For information on
CCRT, refer to Section 3.2.13: Chip Compliance Reporting Tool (CCRT).

To help you determine the reason why VCMS/VMTS (or the third party test host simulator)
approved/declined the online transaction, refer to Appendix C: VSDC Stand-in Processing Conditions.

Note: Access to VCMS or VMTS is provided to Visa clients only.

Important: Online-only devices (such as ATMs and U.S. POS devices) must perform the ADVT Online
Testing test cases in addition to all mandatory test cases.

31 August 2017 Visa Confidential 21

 Test Cases Introduction
Instructions

3.2.11 Test Cards

If physical test cards are being used to perform ADVT testing, acquirers must use the applicable test
card provided to run the test case. For convenience, one card is used for each test case with the test
card number matching the test case number (i.e., for Test Case 1, the acquirer will use Test Card 1).

3.2.12 Simulators

Simulators are available to support ADVT testing:

 Card Simulators—As an alternative to using the physical test cards, acquirer can use a Visa-
confirmed third-party vendor supplied card simulator for ADVT testing. Acquirers must execute
each applicable simulated script to run the test cases. Typically, a single script is used for each test
case with the script number matching the test case number (i.e., for Test Case 1, the acquirer will
use simulated card script 1).
 Test-Host Simulator—As an alternative to connecting to VCMS or VMTS for online testing,
acquirers can connect to a Visa-confirmed third party supplied test tool which mimics
VCMS/VMTS.
Important: To allow Visa to review the tests performed with host simulators, acquirers using these
simulators must provide Visa with the host simulator’s log of each ADVT online test. For a list of the
ADVT online test cases, refer to Section 3.2.11: ADVT Online Testing. Acquirers submit the logs to Visa
via the Chip Compliance Reporting Tool (CCRT). Refer to Section 3.2.13 for more information on CCRT.

A list of available Visa-confirmed ADVT card and test-host simulators is posted on the Visa Technology
Partner website under the Product Toolkits section in the document Visa Confirmed Third-Party Chip
Tool Suppliers: https://technologypartner.visa.com/Toolkits/

Note: Card Simulators may not behave in exactly the same manner as the physical test cards (for
example, the CVR bit settings may not represent the disposition of the previous transactions).
However, this has no effect on test case results.

Also, when a host simulator is used, RRN values will not be available.

22 Visa Confidential 31 August 2017

 Test Cases Introduction
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

3.2.13 Chip Compliance Reporting Tool (CCRT)

Once the ADVT test cases have been completed, acquirers need to submit the results to Visa using the
Chip Compliance Reporting Tool (CCRT). CCRT is a web-based tool that allows chip acquirers or their
processors to complete and submit the mandatory compliance reports via a global automated online
system. Hosted on Visa Online (VOL), CCRT is designed in accordance with Visa’s three-tiered
architectural requirements. As such, it provides a high-level of application and data security.

CCRT allows users to:

 Submit new compliance reports.
 Submit logs when using test-host simulators.
 Review and update draft reports.
 Check on the status of pending reports submitted to Visa.
 Track approved reports.
 Upload reports as XML files generated by test tools (thus avoiding the need to retype report
details).

It benefits users by:

 Providing a convenient and secure online solution for ADVT results reporting.
 Reducing potential for errors in manual entry by guiding users to choose from applicable options
and providing mandatory information requirements.
 Allowing the "re-use" of reports as a starting point for new reporting, reducing time spent
completing the reports.
 Supporting online status review and automated management of reports submitted to Visa,
expediting communication between Visa and clients.

For more details on CCRT, contact your Visa representative.

31 August 2017 Visa Confidential 23

 Test Cases Introduction
Test Case Summary

3.3 Test Case Summary

The following table provides:

 Description—a brief description of each test case.
 Mandatory vs. Conditional—whether the test case is mandatory or conditional
(refer to Section 3.2.1: Mandatory vs. Conditional Test Cases for more information).
 ADVT Online Testing—whether the test case is part of ADVT Online Testing
(refer to Section 3.2.10: ADVT Online Testing for more information).

Important:
 Mandatory test cases must be performed on all devices.
 Mandatory test cases may have an ADVT Online Testing component:
- Online-Capable Devices—ADVT Online Testing requirements must be fulfilled by all online-
capable devices.
- Deferred Authorization Devices—ADVT Online Testing requirements may be applicable to
devices supporting Deferred Authorizations.
Table 3–1: Test Case Summary

Test Card Test Case Description Mandatory vs. ADVT Online

Number Conditional (M/C) Testing

1 Basic VSDC—Basic VSDC card personalized with a unique M 

Primary Account Number (PAN) and the card is
personalized to require successful Issuer Authentication on
online transactions.
Note: This Test Case/Card # is unchanged from the previous
document version.
2 19-Digit PAN—Card personalized with a 19-digit PAN. M 
Note: This Test Case/Card # is unchanged from the previous
document version.
3 DDA, OEP, and Issuer Authentication—Card supports the M 
the following:
 Dynamic Data Authentication (DDA) with an 1024-bit
ICC key
 Offline Enciphered PIN (OEP)
 Requires successful Issuer Authentication on online
transactions
Note: This Test Case/Card # is unchanged from the previous
document version.

24 Visa Confidential 31 August 2017

 Test Cases Introduction
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Test Card Test Case Description Mandatory vs. ADVT Online

Number Conditional (M/C) Testing

4 Terminal Risk Management—Card personalized without M

Terminal Risk Management and configured to decline when
the Terminal Floor Limit is Exceeded.
Note: This Test Case/Card # is unchanged from the previous
document version.
5 Application Selection—Multi-application card containing M
five applications, each with a unique suffix and an
Application Preferred Name containing non-ASCII
characters. The first three applications are intentionally
expired to trigger an offline decline, and Applications four
and five both have a unique PAN for transaction
identification.
Note: This Test Case/Card # is unchanged from the previous
document version.
6 Dual Interface—Dual interface card supporting the M
following:
 Contact Interface: An extended length Processing
Options Data Object List (PDOL) (45 bytes) and
Language Preferences (Japanese, Korean, and Chinese)
supported
 Contactless Interface: Supporting both MSD and
qVSDC (CVN 10) contactless transactions
Note: This Test Case/Card # is unchanged from the previous
document version.
7 Terminal Action Codes—Test ensures the Terminal Action M
Codes (TACs) are correctly set up in the terminal.
Note: This Test Case/Card # is unchanged from the previous
document version.
8 Fallback—Card created to allow magnetic stripe Fallback M
testing.
Note: This Test Case/Card # is unchanged from the previous
document version.
9 “Reserved For Future Use” CVM—Card contains an M
unrecognized method code in the CVM List (‘Reserved for
Future Use’) with instructions to apply the next CVM when
the CVM fails.
Note: This Test Case/Card # is unchanged from the previous
document version.

31 August 2017 Visa Confidential 25

 Test Cases Introduction
Test Case Summary

Test Card Test Case Description Mandatory vs. ADVT Online

Number Conditional (M/C) Testing

10 CDA—Card supporting Combined DDA/AC Generation M

(CDA).
Note: This Test Case/Card # is unchanged from the previous
document version.
11 Multiple Applications—Dual interface card supporting the M
following:
 Contact Interface—Three payment applications; First
with unknown Application ID, second with a blocked
application, and the third with a valid application
 Contactless Interface—Supporting both MSD and
qVSDC (CVN 17) contactless transactions
Note: This Test Case/Card # is unchanged from the previous
document version.
12 Proprietary Data and 6-digit PIN—Card contains: M 
 PSE and has proprietary tag data within the PSE
 Proprietary data within the application
 6-digit PIN
Note: This was Test Case/Card # 13 in the previous
document version.
13 Long PDOL and Unrecognized Tag—Card requests a long M
string of data (0x64 bytes) and an unrecognized tag in
Processing Options Data Object List (PDOL).
Note: This was Test Case/Card # 14 in the previous
document version.
14 Two Applications and Cardholder Confirmation—Card M
contains two applications:
 Visa Credit: Requires cardholder confirmation
 Visa Debit: Does not require cardholder confirmation
Note: This was Test Case/Card # 16 in the previous
document version.
15 DDA with 1984 Certificate—Card contains an Issuer M
Public Key Certificate signed by Visa’s 1984-bit CA test key.
Note: This was Test Case/Card # 18 in the previous
document version.

26 Visa Confidential 31 August 2017

 Test Cases Introduction
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Test Card Test Case Description Mandatory vs. ADVT Online

Number Conditional (M/C) Testing

16 Plus and Visa Interlink—Card containing the following: C 

 Visa RID (A00000003) with the Plus PIX (8010) and a (only applicable to
suffix of ‘01’ devices that
support Plus
 Visa RID (A00000003) with the Interlink PIX (3010)
and/or Interlink)
Note: This was Test Case/Card # 19 in the previous
document version.
17 Visa Electron—Card is a Visa Electron card with a unusable C
magnetic stripe. (only applicable to
Note: This was Test Case/Card # 20 in the previous devices that
document version. support
Visa Electron)
18 Combination CVM and Visa Fleet Chip—Card contains: M
 CVM List where the first CVM is the combination CVM
of Signature and Offline PIN
 Visa Fleet Chip (VFC) feature to ensure cards with this
feature can be accepted at standard EMV devices
Note: This was Test Case/Card # 23 in the previous
document version.
19 Account Number with Padded Fs—Card with a 16-digit M 
account number padded with hexadecimal “F’s” up to a
maximum account number length.
Note: This was Test Case/Card # 24 in the previous
document version.
20 No PAN Sequence Number—Card without a PAN M 
Sequence Number.
Note: This was Test Case/Card # 25 in the previous
document version.
21 PAN Sequence Number of 11—Card with a PAN M 
Sequence Number of 11.
Note: This was Test Case/Card # 26 in the previous
document version.
22 1144-Bit Issuer Public Key—Card with an Issuer Public M
Key Certificate based on an 1144-bit Issuer Public Key.
Note: This was Test Case/Card # 27 in the previous
document version.

31 August 2017 Visa Confidential 27

 Test Cases Introduction
Test Case Summary

Test Card Test Case Description Mandatory vs. ADVT Online

Number Conditional (M/C) Testing

23 Single Application/Multiple Features—Card contains a M 

PSE, with an issuer URL in both the PSE and application
data, extra Issuer Application Data in tag 9F 10, an
Application Expiration Date of December 31, 2025, a CVM
List which does not contain Signature, and Cryptogram
Version Number 18 (hex ’12’).
Note: This was Test Case/Card # 28 in the previous
document version.
24 Multi-application/Multiple Features—Card contains a M 
PSE, with two applications, one supporting CVN 10 (hex
’0A’) (Application #1) and the other supporting CVN 22 (hex
’16’) (Application #2). Neither application requires the
return of an ARPC, with Issuer Authentication set to
Mandatory.
Card also supports:
- Application Selection Registered Proprietary Data (tag
9F0A)
- An Online PIN-preferring CVM List
Note: This is a new Test Case/Card.

28 Visa Confidential 31 August 2017

 Test Cases Introduction
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

31 August 2017 Visa Confidential 29

 Test Cases
Test Case Summary

4 Test Cases
This chapter outlines each ADVT test case.

Important: Prior to beginning the tests, be sure to read the following sections:
 Section 3.1: Pre-requisites
 Section 3.2: Instructions
(especially Section 3.2.1: Mandatory and Conditional Test Cases and
Section 3.2.10: ADVT Online Testing)
 Section 3.3: Test Case Summary

These sections contain critical information.

The following information is provided with each test case:

 Test Case Number—The number of the test case.
 Test Case Name—The name of the test case.
 Objective—The objective of the test case.
 Regional Requirement—Whether the test applies to all regions or is specific to sub-set of
regions. (Currently, all of the tests apply to all regions).
 Business Justification—The business reason for the test.
 Pre-requisite—Any specific terminal conditions that apply or configuration requirements needed
for the test case.
 Applicable Terminal Device Type—Indicates the device type that needs to be tested.
 Applicable Terminal Interface—Indicates the interface type that needs to be tested.
 Test Card—A number used to uniquely identify the test card required to execute the test. There is
a one-to-one correlation between the Test Case Number and the Test Card Number
(i.e., Test Case 1 uses Test Card 1).
 Test Evidence to be submitted—Evidence to be submitted with results on completion of the test
case.
Note: in cases where the “Receipt” box is checked, images of receipts may optionally be uploaded
in a PDF to “Additional Upload” function within the CCRT.
 Document Reference—References to the specification or rule that acquirers may refer to for
background information on the test. This information is especially important in the event that the
test fails.
 Pass Criteria/User Validation—The success/failure criteria for the test.

30 Visa Confidential 31 August 2017

 Test Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

4.1 Test Case 1: Basic VSDC

Test Case 1/Test Card 1 (Mandatory; ADVT Online Testing)

Test Case Number: 1 (unchanged from previous version)

Test Case Name: Basic VSDC
Objective: To ensure acceptance of a basic VSDC card. This card contains the most commonly
used VSDC features. It is personalized to require successful Issuer Authentication on
online transactions.
Note: This is a T=0 test card that is personalized without the Payment System
Environment (PSE). If the terminal has difficulty with this test, ensure your terminal can
accept cards supporting the T=0 protocol and personalized without the PSE.
Note: Card contains an Application Label of “Visa Credit” and an Application Preferred
Name of “Credito de Visa.”
Regional Requirement: Mandatory All Regions
ADVT Online Testing Required (see part 1d)
Business Justification: This represents a card containing some of the most commonly used VSDC features. For
this reason, it is important to ensure universal acceptance of this card.
Pre-requisite:
Applicable Terminal ☒POS ☒ATM ☒MPOS
Device Type:
Applicable Terminal ☒Contact ☐Contactless
Interface:
Test Card: 1
Test Evidence to be ☒Receipt (where possible) ☐Card-to-Terminal Interaction Log ☒Host Simulator Log
Submitted:
Document Reference: EMV 4.3, Book 1, Section 12.3.2: Using the Payment Systems Environment
Transaction Acceptance Device Requirements
Pass Criteria/User This test has four parts (1a-1d). Complete the parts that apply to your device as follows:
Validation  1a: All Devices
 1b: Devices that have separate insertion areas for chip and magnetic stripe
 1c: Non-Zero Floor Limit Devices (i.e., devices that have a floor limit)
 1d: ADVT Online Testing (for online-capable and online-only devices)
Important: Please ensure that all applicable cases 1a-d are performed as separate,
consecutive transactions.

31 August 2017 Visa Confidential 31

 Test Cases
Test Case 1: Basic VSDC

Test Case 1/Test Card 1 (Mandatory; ADVT Online Testing)

Pass Criteria/User 1a) All Devices:

Validation (con’t): Device must perform a complete transaction without any error messages. A
complete transaction is defined as the performance of all selected VSDC functions from
Application Selection through to Completion. Error messages (such as Not Accepted or
Card Error) are not acceptable and indicate failure of the test.
Devices Supporting Offline Data Authentication:
For devices supporting SDA, the device log must show that:
 Transaction Status Information (TSI), byte 1, bit 8 = 1 (Offline Data Authentication
was performed)
 TVR, byte 1, bit 8 = 0 (Offline Data Authentication was performed)
 TVR, byte 1, bit 7 = 0 (SDA did not fail)
Application Name and Receipt Requirements:
 If the application name is displayed and the device supports the Issuer Code Table
Index of 01, the device must display the Application Preferred Name of Credito de
Visa. For these devices, the Visa AID (A0000000031010) must be printed on the
receipt and it is strongly recommended that the Application Preferred Name
(Credito de Visa) also be printed on the receipt.
 If the application name is displayed and the device does not support the Issuer
Code Table Index of 01, the Application Label of Visa Credit must be displayed. For
these devices, the Visa AID (A0000000031010) must be printed on the receipt and it
is strongly recommended that the Application Label (Visa Credit) also be printed on
the receipt.
Note: It is a Visa Best Practice to print the application name (either Application
Preferred Name or Application Label depending on support for the Issuer Code Table
Index) on the receipt. Refer to the Transaction Acceptance Device Guide for details.
1b) Devices that Have Separate Insertion Areas for Chip and Magnetic Stripe
Transactions:
Note: This part of the test (1b) is not applicable to Combined Readers such as ATMs
where the card is inserted into a single slot for both chip and magnetic-stripe
transactions.
Attempt to read the card via its magnetic stripe. Ensure that the device prompts the
user to insert the card into the chip reader. This ensures that the device does not allow
functioning EMV chip cards to be processed as magnetic stripe.
1c) Non-Zero Floor Limit Devices (Devices that have a Floor Limit):
Perform an online transaction (above the floor limit) to help ensure that the floor limit
is set up correctly. The device must attempt to send the transaction online:
 TVR, byte 4, bit 8 = 1 (Transaction Exceeds Floor Limit)
Note: You will not be able to perform this test if you do not successfully pass part 1a.

32 Visa Confidential 31 August 2017

 Test Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Test Case 1/Test Card 1 (Mandatory; ADVT Online Testing)

Pass Criteria/User 1d) ADVT Online Testing (Online-Capable or Online-Only Devices including
Validation (con’t): ATMs):
Device must perform an above floor limit transaction to send the transaction online to
VCMS/VMTS/an approved test-host simulator where VCMS/VMTS/approved host
simulator will perform Online Card Authentication. Online Card Authentication must
pass (Field 44.8 = 2).
VCMS/VMTS/approved host simulator will respond with an Issuer Authentication
cryptogram (Authorization Response Cryptogram—ARPC). The device must be able to
receive the cryptogram in the response data and forward it to the card where the
transaction must be approved. If the online transaction results in a decline, the user
has failed the test (indicating that the device either did not forward the cryptogram to
the card or incorrectly forwarded the cryptogram to the card).
The device log must show:
 CVR, byte 2, bit 4 = 0 (Issuer Authentication performed and not failed)
For ADVT Online Testing, additional requirements (such as providing a Retrieval
Reference Number or submitting host logs) may apply and, if applicable, must be
submitted in the compliance report via CCRT.

31 August 2017 Visa Confidential 33

 Test Cases
Test Case 2: 19-Digit Account Number

4.2 Test Case 2: 19-Digit Account Number

Test Case 2/Test Card 2 (Mandatory; ADVT Online Testing)

Test Case Number: 2 (unchanged from previous version)

Test Case Name: 19-Digit Account Number
Objective: To ensure acceptance of a card with a 19-digit account number.
Note #1: Visa Core Rules and Visa Product and Service Rules and Visa Europe
Operating Regulations require new and existing chip reading devices to be able to
read Visa account numbers up to and including 19 digits. This includes ATMs
accepting Plus cards.
Note #2: The Test BIN used on this card is configured not to return an ARPC.
Regional Requirement: Mandatory All Regions
ADVT Online Testing Required
Business Justification: The primary purpose of this test is to determine 19-digit account number acceptance.
In cases where the Acquirer’s acceptance environment is not yet capable of processing
19-digit account numbers, the card may still be used as a “future-proofing” measure
to ensure chip reading device readiness, for when acceptance of 19-digit account
number cards is finally required.
Pre-requisite: n/a
Applicable Terminal ☒POS ☒ATM ☒MPOS
Device Type:
Applicable Terminal ☒Contact ☐Contactless
Interface:
Test Card: 2
Test Evidence to be ☒Receipt (where possible) ☐Card-to-Terminal Interaction Log ☒Host Simulator Log
Submitted:
Document Reference: Visa Core Rules and Visa Product and Service Rules
Visa Europe Operating Regulations
Pass Criteria/User All Devices:
Validation: Ensure the device does not print the Primary Account Number (PAN) followed by an
‘F’ on the receipt. Because the PAN is 19 digits, the PAN field on the chip is padded
with 1 F (per EMV). This ‘F’ must not be printed on the receipt. The device fails this test
if it prints the ‘F’ as part of the PAN on the receipt.

34 Visa Confidential 31 August 2017

 Test Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Test Case 2/Test Card 2 (Mandatory; ADVT Online Testing)

Deferred Authorization Devices:

Device must perform a complete transaction without any error messages. A
complete transaction is defined as the performance of all selected VSDC functions
from Application Selection through to Completion. Error messages (such as Not
Accepted or Card Error) are not acceptable and indicate failure of the test.
Pass Criteria/User ADVT Online Testing (Online-Capable or Online-Only Devices including ATMs):
Validation (con’t): Device must perform an above floor limit transaction to send the transaction online to
a VCMS/VMTS/approved test-host simulator and be approved. If the transaction is
declined or an “invalid card type” is indicated, this is not necessarily indicative of
device failure. It is possible that the acquiring host system is not capable of accepting
19-digit account numbers. If this is the case, please include relevant comments in the
Test Results section of the Chip Compliance Reporting Tool’s (CCRT) compliance
report.

31 August 2017 Visa Confidential 35

 Test Cases
Test Case 3: DDA, OEP, and Issuer Authentication

4.3 Test Case 3: DDA, OEP, and Issuer Authentication

Test Case 3/Test Card 3 (Mandatory; ADVT Online Testing)

Test Case Number: 3 (unchanged from previous version)

Test Case Name: DDA, Offline Enciphered PIN, and Issuer Authentication
Objective: To ensure acceptance of a card that is personalized to require successful Issuer
Authentication on online transactions. Card supports DDA and Offline Enciphered PIN
(OEP).
Regional Requirement: Mandatory All Regions
ADVT Online Testing Required
Business Justification: Since DDA support is required for all contact-chip devices with offline capability, this
test case is intended to verify correct processing of a DDA-supporting card. Also, the
Europe Region mandates that contact cards with offline capability must support DDA.
Pre-requisite:
Applicable Terminal ☒POS ☒ATM ☒MPOS
Device Type:
Applicable Terminal ☒Contact ☐Contactless
Interface:
Test Card: 3
Test Evidence to be ☐Receipt (where possible) ☐Card-to-Terminal Interaction Log ☒Host Simulator Log
Submitted:
Document Reference: EMV 4.3, Book 1, Section 9: Transmission Protocols
Pass Criteria/User Devices that Support Dynamic Data Authentication:
Validation: The device log must show:
 Transaction Status Information (TSI), byte 1, bit 8 = 1 (Offline Data Authentication
was performed)
 TVR, byte 1, bit 8 = 0 (Offline Data Authentication was performed)
 TVR, byte 1, bit 4 = 0 (DDA did not fail)
Devices that Support Offline Enciphered PIN:
The device log must show:
 CVR, byte 2, bit 3 = 1 (Offline PIN Verification performed)
 CVR, byte 2, bit 2 = 0 (Offline PIN Verification did not fail)

36 Visa Confidential 31 August 2017

 Test Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Test Case 3/Test Card 3 (Mandatory; ADVT Online Testing)

Pass Criteria/User Deferred Authorization Devices Devices:

Validation (con’t): Device must perform a complete transaction without any error messages. A
complete transaction is defined as the performance of all selected VSDC functions from
Application Selection through to Completion. Error messages (such as Not Accepted or
Card Error) are not acceptable and indicate failure of the test.
ADVT Online Testing (Online-Capable or Online-Only Devices including ATMs):
Device must perform an above floor limit transaction to send the transaction online to
a VCMS/VMTS/approved test-host simulator where VCMS/VMTS/approved host
simulator will perform Online Card Authentication. Online Card Authentication must
pass (Field 44.8 = 2).
VCMS/VMTS/approved host simulator will respond with an Issuer Authentication
cryptogram (Authorization Response Cryptogram—ARPC). The device must be able to
receive the cryptogram in the response data and forward it to the card where the
transaction must be approved. If the online transaction results in a decline, the user
has failed the test (indicating that the device either did not forward the cryptogram to
the card or incorrectly forwarded the cryptogram to the card).
The device log must show:
 CVR, byte 2, bit 4 = 0 (Issuer Authentication performed and not failed)
For ADVT Online Testing, additional requirements (such as providing a Retrieval
Reference Number or submitting host logs) may apply and, if applicable, must be
submitted in the compliance report via CCRT.

31 August 2017 Visa Confidential 37

 Test Cases
Test Case 4: Terminal Risk Management

4.4 Test Case 4: Terminal Risk Management

Test Case 4/Test Card 4 (Mandatory)

Test Case Number: 4 (unchanged from previous version)

Test Case Name: Terminal Risk Management
Objective: To ensure the terminal correctly performs terminal risk management (specifically Floor
Limit Checking) in accordance with Visa rules, even when the card is not personalized
to support terminal risk management (AIP, Byte 1, Bit 4 = 0).
Note: Card is personalized with ‘Floor Limit Exceeded’ bit set in the Issuer Action Code
– Denial (Byte 4, Bit 8 = 1).
Note: EMV only requires a terminal to perform Terminal Risk Management (TRM) if the
“TRM is to be performed” bit is set in the card’s Application Interchange Profile (AIP).
However, Visa requires that POS terminals must always perform TRM, even when this
AIP bit is not set. Note that this requirement does not apply to online-only devices,
such as ATMs, which are allowed to skip TRM processing.
Regional Requirement: Mandatory All Regions
Business Justification: Visa rules state that Terminal Risk Management should always be performed,
irrespective of whether or not Terminal Risk Management is personalized on the card.
This card is intended to test the terminal’s compliance with this rule.
Pre-requisite:
Applicable Terminal ☒POS ☐ATM ☒MPOS
Device Type:
Applicable Terminal ☒Contact ☐Contactless
Interface:
Test Card: 4
Test Evidence to be ☐Receipt (where possible) ☐Card-to-Terminal Interaction Log ☐Host Simulator Log
Submitted:
Document Reference: EMV 4.3, Book 3, Section 10.6: Terminal Risk Management
Terminal Acceptance Device Guidelines, Sections 5.5 & 5.9
Pass Criteria/User Online-Only Devices That Do Not Support Terminal Risk Management (TRM):
Validation: Not Applicable.
All Other Devices:
The device must decline the transaction offline. An error message, offline approval,
or online approval is not acceptable and indicates failure of the test.

38 Visa Confidential 31 August 2017

 Test Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

4.5 Test Case 5: Application Selection

Test Case 5/Test Card 5 (Mandatory)

Test Case Number: 5 (unchanged from previous version)

Test Case Name: Application Selection
Objective: This test has the following objectives:
 Ensure acceptance of a card that contains multiple (five) applications, each
distinguished by a unique suffix appended to the Visa AID
 Ensure acceptance of a card containing a non-ASCII Application Preferred Name
Regional Requirement: Mandatory All Regions
Business Justification: As multi-application cards become more popular, it is important to ensure that
terminals are able to correctly identify and select appropriate applications on the card
and that the user interface is appropriate for the environment (i.e., the user interface
must not confuse the merchant or the cardholder). According to the Transaction
Acceptance Device Requirements, “Application Selection Indicators for Visa AIDs must
indicate support for Partial selection.”
For cardholder convenience, issuers may choose to have the name of the application
presented to the cardholder for selection in the cardholder’s language (this is the
Application Preferred Name). If the terminal supports the relevant alphabet (“Issuer
Code Table Index”), it will display the Application Preferred Name rather than the
Application Label. Otherwise, the terminal must ignore this feature and display the
application name to the cardholder in the format specified in the Application Label.
Pre-requisite:
Applicable Terminal ☒POS ☒ATM ☒MPOS
Device Type:
Applicable Terminal ☒Contact ☐Contactless
Interface:
Test Card: 5
Test Evidence to be ☒Receipt (where possible) ☐Card-to-Terminal Interaction Log ☐Host Simulator Log
Submitted:
Document Reference: EMV 4.3, Book 1, Section 12.3.1: Matching Terminal Applications to ICC Applications
EMV 4.3, Book 1, Section 12.4: Final Selection
EMV 4.3, Book 4, Section 11.1: Language Selection
EMV 4.3, Book 4, Section 11.3: Application Selection
Transaction Acceptance Device Requirements

31 August 2017 Visa Confidential 39

 Test Cases
Test Case 5: Application Selection

Test Case 5/Test Card 5 (Mandatory)

Pass Criteria/User Terminal must perform a complete VSDC transaction without error. A complete
Validation: transaction is defined as the performance of all selected VSDC functions from
Application Selection through to Completion. Error messages (such as Not Accepted or
Card Error) are not acceptable and indicate failure of the test.
Refer to Table 3-1: Test Case 5 Expected Results for details.
Specific Card Conditions: Card contains five applications (3 x Visa Credit and 2 x Visa Debit) each with a unique
suffix appended to the AID:
 Application #1—Visa Credit is the first priority application. It contains an
Application Preferred Name in Cyrillic code (i.e., Виса Кредит 1) and an Issuer Code
Table Index of 05. This application is expired (i.e. its Application Expiration Date is
personalized with 31 December 2005) and its IAC – Denial is set to decline
transactions based on the expired application.
 Application #2—Visa Debit is the second priority application. It contains an
Application Preferred Name in Cyrillic code (i.e., Виса Дебет 1) and an Issuer Code
Table Index of 05. This application is expired (i.e. its Application Expiration Date is
personalized with 31 December 2005) and its IAC – Denial is set to decline
transactions based on the expired application.
 Application #3—Visa Credit is the third priority application. It contains an
Application Preferred Name in Cyrillic code (i.e., Виса Кредит 2) and an Issuer Code
Table Index of 05. This application is expired (i.e. its Application Expiration Date is
personalized with 31 December 2005) and its IAC – Denial is set to decline
transactions based on the expired application.
 Application #4—Visa Debit is the fourth priority application. It contains an
Application Preferred Name in Cyrillic code (i.e., Виса Дебет 2) and an Issuer Code
Table Index of 05. The application has a unique PAN to allow easier identification of
online transactions.
 Application #5—Visa Credit is the fifth priority application. It contains an
Application Preferred Name in Cyrillic code (i.e., Виса Кредит 3) and an Issuer Code
Table Index of 05. The application has a unique PAN to allow easier identification of
online transactions.

40 Visa Confidential 31 August 2017

 Test Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

4.5.1 Test Case 5: Expected Results

This table outlines the expected results for Test Case 5. To determine which row to use for the expected
results, identify the terminal’s functionality including support for cardholder selection and Issuer Code
Table Index of 05.
Table 4–1: Test Case 5: Expected Results

Terminal Cardholder Issuer Code Expected Results

Scenario Selection Table Index 05
Supported Supported

1 Yes No All five payment applications must be displayed to the cardholder

in priority order using their Application Label. Since the first three
applications are expired, either the fourth (“Visa Debit 2”) or fifth
(“Visa Credit 3”) should be selected. The transaction must be
approved offline or approved online. An offline decline is not
acceptable and indicates failure of the test. The only situation
where a decline is an acceptable response is when both the
amount is above the floor limit and tests are being conducted in
an offline mode (i.e., no connectivity to VCMS/VMTS/approved
host simulator). In this scenario, the terminal must attempt to
send the transaction online and then decline offline when online
is not available (due to the IAC and TAC-Default for Floor Limit
Exceeded).
The Visa AID must be printed on the receipt and it is strongly
recommended that the Application Label be printed as well.
2 Yes Yes All five payment applications must be displayed to the cardholder
in priority order using their Application Preferred Name. Since the
first three applications are expired, either the fourth (“Виса Дебет
2”) or fifth (“Виса Кредит 3”) should be selected. The transaction
must be approved offline or approved online. An offline decline is
not acceptable and indicates failure of the test. The only situation
where a decline is an acceptable response is when both the
amount is above the floor limit and tests are being conducted in
an offline mode (i.e., no connectivity to VCMS/VMTS/approved
host simulator). In this scenario, the terminal must attempt to
send the transaction online and then decline offline when online
is not available (due to the IAC and TAC-Default for Floor Limit
Exceeded).
The Visa AID must be printed on the receipt and it is strongly
recommended that the Application Preferred Name (i.e. either
“Виса Кредит” or “Виса Дебет”) be printed as well.

31 August 2017 Visa Confidential 41

 Test Cases
Test Case 5: Application Selection

Terminal Cardholder Issuer Code Expected Results

Scenario Selection Table Index 05
Supported Supported

3 No N/A In accordance with Visa rules, since the terminal does not support
the displaying of mutually supported applications or Cardholder
Selection, the highest priority application should be selected for
the transaction. The transaction will be declined offline because
the highest priority application is personalized with an expired
application.
If a receipt is printed, the Visa AID must be on the receipt and it is
strongly recommended that the Application Label (Visa Credit) be
printed as well.

42 Visa Confidential 31 August 2017

 Test Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

4.6 Test Case 6: Dual Interface

Test Case 6/Test Card 6 (Mandatory)

Test Case Number: 6 (unchanged from previous version)

Test Case Name: Dual Interface
Objective: To ensure acceptance of a Dual Interface card (contact and contactless) containing the
following within the contact payment application:
 A long PDOL (45 bytes)
 Language Preference field with Japanese, Korean, and Chinese language codes
specified
Note: The Language Preference field is an optional data element that issuers may
include on their cards. If included on the card, the terminal must be able to handle this
field.
Note: The VSDC contact application supports DDA.
Regional Requirement: Mandatory All Regions
Business Justification: For cardholder convenience, issuers may use the Language Preference feature to allow
cardholders to be presented with terminal messages in their language of choice. The
terminal needs to ensure one of the following:
 If it does not support any of the preferred languages identified on the card, it
continues to execute the transaction using the language it supports.
 If it does support one of the preferred languages, all terminal displays are presented
in the highest priority language.
Pre-requisite:
Applicable Terminal ☒POS ☒ATM ☒MPOS
Device Type:
Applicable Terminal ☒Contact ☐Contactless
Interface:
Test Card: 6
Test Evidence to be ☐Receipt (where possible) ☐Card-to-Terminal Interaction Log ☐Host Simulator Log
Submitted:
Pass Criteria/User Device must perform a complete transaction without any error messages. A
Validation: complete transaction is defined as the performance of all selected VSDC functions from
Application Selection through to Completion. Error messages (such as Not Accepted or
Card Error) are not acceptable and indicate failure of the test.
In addition, if the device supports Japanese, Korean, or Chinese, the device must
display any cardholder messages in that language (e.g., when prompting the
cardholder to agree to the amount of the transaction, the device must display
messages such as “Amount OK” to the cardholder in one of the above languages).

31 August 2017 Visa Confidential 43

 Test Cases
Test Case 7: Terminal Action Codes (TACs)

4.7 Test Case 7: Terminal Action Codes (TACs)

Test Case 7/Test Card 7 (Mandatory)

Test Case Number: 7 (unchanged from previous version)

Test Case Name: Terminal Action Codes (TACs)
Objective: To ensure Terminal Action Codes (TACs) are correctly configured (refer to Appendix B:
Terminal Action Code (TAC) Settings for the TACs that must be loaded into the device).
Note: In this test, the Application Usage Control on the card indicates that the card
cannot be used for international transactions. This will cause the terminal to set the
“Service Not Allowed For Card Product” bit in the TVR, which must result in a declined
transaction. This test is only for one bit in the TAC-Decline (Service Not Allowed For
Card Product) but is intended to focus attention on the TAC values in general.
Regional Requirement: Mandatory All Regions
Business Justification: For risk management and acceptance purposes, Visa has defined and specified a set of
values (referred to as Terminal Action Codes) that must be used on Chip Card
Acceptance Devices accepting Visa cards. It is therefore important to ensure these
values are being correctly applied.
Note: TAC values are mandated by Visa for all devices. The values can be found in the
Transaction Acceptance Device Requirements and Appendix B: Terminal Action Codes of
this document.
Pre-requisite:
Applicable Terminal ☒POS ☒ATM ☒MPOS
Device Type:
Applicable Terminal ☒Contact ☐Contactless
Interface:
Test Card: 7
Test Evidence to be ☐Receipt (where possible) ☐Card-to-Terminal Interaction Log ☐Host Simulator Log
Submitted:
Document Reference: Transaction Acceptance Device Requirements
Pass Criteria/User Device must decline the transaction offline. The device fails the test if the
Validation: transaction:
 Is terminated with an error message
 Approved offline
 Sent online for authorization
The device log must show:
 TVR, byte 2, bit 5 = 1 (Requested Service Not Allowed For Card Product)
 Device requests an AAC in the FIRST GENERATE AC command

44 Visa Confidential 31 August 2017

 Test Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

31 August 2017 Visa Confidential 45

 Test Cases
Test Case 8: Fallback

4.8 Test Case 8: Fallback

Test Case 8/Test Card 8 (Mandatory)

Test Case Number: 8 (unchanged from previous version)

Test Case Name: Fallback
Objective: To ensure that the terminal correctly allows Fallback in the case where there are no
mutually supported applications between the card and terminal.

Note 1: The Transaction Acceptance Device Guide (TADG) – Version 3.1 (November
2016) – Section 3.3 indicates that “If no applications are mutually supported, the device
should display a CARD TYPE NOT SUPPORTED message and invoke a magnetic-stripe
read”.
Note 2: Since Fallback must be supported unless disallowed by local regulation or
domestic operating rules, Clients are requested to consult with their local Visa
representative to ensure no violation of local rules governing Fallback.
Regional Requirement: All Regions
ADVT Online Testing Required
Business Justification: Since Fallback must be supported unless disallowed by local regulation or domestic
operating rules, this card may be used to ensure correct rules are being applied and
that the user interface is appropriate.
Also, according to Visa Core Rules, ATM Fallback is required except in Japan.
Pre-requisite: Device supports magnetic-stripe Fallback.
Applicable Terminal ☒POS ☒ATM ☒MPOS
Device Type:
Applicable Terminal ☒Contact ☐Contactless
Interface:
Test Card: 8
Test Evidence to be ☒Receipt (where possible) ☐Card-to-Terminal Interaction Log ☐Host Simulator Log
Submitted:
Document Reference: Visa Core Rules and Visa Product and Service Rules
Visa Europe Operating Regulations
Transaction Acceptance Device Guide
Pass Criteria/User General:
Validation: The device must attempt to read the chip, realize that it cannot be read, and allows
Fallback to magnetic stripe. This test should validate that the device allows for a
magnetic stripe entry when the chip cannot be read, and then performs a magnetic
stripe online transaction.

46 Visa Confidential 31 August 2017

 Test Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Test Case 8/Test Card 8 (Mandatory)

Readers that Have Separate Insertion Areas for Chip and Magnetic Stripe
Transactions:
The device must clearly indicate during the attempt to read the chip that the
“Chip Cannot Be Read” (or equivalent). To indicate that Fallback is supported, the
device must provide a message such as “Swipe Magnetic Stripe” (or equivalent).
Pass Criteria/User Combined Readers (Readers, such as ATMs, where there is a single insertion point
Validation (con’t): for both magnetic stripe and chip transactions):
In these devices, Fallback to magnetic stripe is transparent to the user. However, the
user must ensure that the device properly allows Fallback (i.e., a magnetic-stripe
transaction). The device fails this test when the device does not allow the magnetic
stripe to be read and/or when the receipt contains the Visa AID (A0000000031010).
Note 1: Any online response code is acceptable for the magnetic stripe Fallback
transaction including decline responses such as incorrect/missing PIN.
Note 2: Some Fallback procedures allow more than one attempt to read the chip card.

31 August 2017 Visa Confidential 47

 Test Cases
Test Case 9: “Reserved for Future Use” CVM

4.9 Test Case 9: “Reserved for Future Use” CVM

Test Case 9/Test Card 9 (Mandatory)

Test Case Number: 9 (unchanged from previous version)

Test Case Name: “Reserved for Future Use” CVM
Objective: To ensure that the terminal correctly processes a card containing a CVM that the
terminal does not recognize and the CVM is not on the list of CVMs that must be
recognized by the terminal (i.e., the first CVM in the list is a “Reserved For Future Use
CVM”, with instructions to apply the next CVM if CVM processing fails).
Regional Requirement: Mandatory All Regions
Business Justification: The CVM List of an EMV card may contain a method not recognizable by the terminal.
If the terminal encounters such a method, it must follow the CVM rules and proceed
with the transaction. This card is designed to ensure correct terminal behavior.
Pre-requisite:
Applicable Terminal ☒POS ☒ATM ☒MPOS
Device Type:
Applicable Terminal ☒Contact ☐Contactless
Interface:
Test Card: 9
Test Evidence to be ☐Receipt (where possible) ☐Card-to-Terminal Interaction Log ☐Host Simulator Log
Submitted:
Document Reference: EMV 4.3, Book 3, Section 10.5: Cardholder Verification
Transaction Acceptance Device Requirements
Pass Criteria/User All Devices:
Validation: The transaction must be approved offline or approved online. An error message or
an offline decline is not acceptable and indicates failure of the test.

48 Visa Confidential 31 August 2017

 Test Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Test Case 9/Test Card 9 (Mandatory)

Pass Criteria/User POS Devices:

Validation (con’t): When encountering a new CVM (represented by a “Reserved For Future Use” CVM
value in the CVM List), the device must set:
 TVR, byte 3, bit 7 = 1 (Unrecognized CVM)
Since this CVM list indicates that the “Reserved For Future Use” CVM must only be
performed when supported by the device, the device must proceed to the remaining
CVMs in the CVM list.
For POS devices supporting signature, signature must be requested and the terminal
must set:
 TVR, byte 3, bit 8 to ‘0’ (Cardholder Verification Successful)
Note: All online-capable unattended POS devices, including AFDs, must support the
“No CVM” CVM. This means that they should process this card without requesting any
CVM and send it online where it will be authorized.
ATMs:
ATMs must request that the cardholder enter their Online PIN. Subsequently, the ATM
must send the transaction online and the transaction must be approved.

31 August 2017 Visa Confidential 49

 Test Cases
Test Case 10: CDA

4.10 Test Case 10: CDA

Test Case 10/Test Card 10 (Mandatory)

Test Case Number: 10 (unchanged from previous version)

Test Case Name: CDA
Objective: To ensure acceptance of a card that supports Combined DDA/Generate Application
Cryptogram (CDA).
Regional Requirement: Mandatory All Regions
Business Justification: CDA combines DDA with the generation of a card’s Application Cryptogram to assure
card validity. It is intended to protect offline transactions where there is significant
opportunity for interception of chip-to-device communications. CDA is widely
supported by terminals in some regions and is a valid option for card issuers.
Pre-requisite:
Applicable Terminal ☒POS ☒ATM ☒MPOS
Device Type:
Applicable Terminal ☒Contact ☐Contactless
Interface:
Test Card: 10
Test Evidence to be ☐Receipt (where possible) ☐Card-to-Terminal Interaction Log ☐Host Simulator Log
Submitted:
Document Reference: EMV
Terminal Acceptance Device Requirements

50 Visa Confidential 31 August 2017

 Test Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Test Case 10/Test Card 10 (Mandatory)

Pass Criteria/User Devices That Support CDA:

Validation:
Mode Expected Result

1 CDA is successfully performed.

If the transaction is sent online, Online Card Authentication must be
successful (Field 44.8 = 2) and the transaction must be approved online.
The device log must show:
 Transaction Status Information (TSI), byte 1, bit 8 = 1 (Offline Data
Authentication was performed)
 TVR, byte 1, bit 8 = 0 (Offline Data Authentication was performed)
 TVR, byte 1, bit 3 = 0 (CDA did not fail)
2 CDA is successfully performed.
If the transaction is sent online, Online Card Authentication must be
successful (Field 44.8 = 2) and the transaction must be approved online.
The device log must show:
 Transaction Status Information (TSI), byte 1, bit 8 = 1 (Offline Data
Authentication was performed)
 TVR, byte 1, bit 8 = 0 (Offline Data Authentication was performed)
 TVR, byte 1, bit 3 = 0 (CDA did not fail)
3 CDA is not performed.
If the transaction is sent online, Online Card Authentication must be
successful (Field 44.8 = 2) and the transaction must be approved online.
The device log must show:
 Transaction Status Information (TSI), byte 1, bit 8 = 1 (Offline Data
Authentication was performed)
 TVR, byte 1, bit 8 = 1 (Offline Data Authentication was not performed)
 TVR, byte 1, bit 3 = 0 (CDA did not fail)
Note: if the transaction is completed offline, TVR, byte 1, bit 8 = 0 (Offline
Data Authentication was performed)
4 EMV does not recommend the implementation of Mode 4.

Devices That Do Not Support CDA:

CDA is not applicable. Device must perform a complete transaction without any error
messages. A complete transaction is defined as the performance of all selected VSDC
functions from Application Selection through to Completion. Error messages (such as
Not Accepted or Card Error) are not acceptable and indicate failure of the test.
This test ensures that even though the device does not support CDA, a card supporting
CDA does not cause acceptance problems.

31 August 2017 Visa Confidential 51

 Test Cases
Test Case 11: Multiple Applications

4.11 Test Case 11: Multiple Applications

Test Case 11/Test Card 11 (Mandatory)

Test Case Number: 11 (unchanged from previous version)

Test Case Name: Multiple Applications
Objective: To ensure correct acceptance of a card containing multiple applications, but with only
one application valid for use.
Card contains three applications where the last one is the only usable application:
 Application # 1 – Contains an unknown AID
 Application # 2 – Blocked application (PAN = 47 61 73 90 01 01 00 10)
 Application # 3 – Valid application (PAN = 47 61 73 90 01 01 01 19)
Note: Application #3 supports DDA.

Regional Requirement: Mandatory All Regions

Business Justification: As multi-application cards become more popular, it is important to ensure that
terminals are able to correctly identify and select appropriate applications on the card
and that the user interface is appropriate for the environment (i.e., the user interface
must not confuse the merchant or the cardholder).
Pre-requisite:
Applicable Terminal ☒POS ☒ATM ☒MPOS
Device Type:
Applicable Terminal ☒Contact ☐Contactless
Interface:
Test Card: 11
Test Evidence to be ☐Receipt (where possible) ☐Card-to-Terminal Interaction Log ☐Host Simulator Log
Submitted:
Document Reference: EMV 4.3, Book 1, Section 12.4: Final Selection
Pass Criteria/User The transaction must be approved offline or approved online. An error message or
Validation: an offline decline is not acceptable and indicates failure of the test.
This test is applicable to all devices, irrespective of whether or not ‘Cardholder
Application Selection’ is supported. Only one application is valid for use
(Application #3) and therefore should be the one selected.

52 Visa Confidential 31 August 2017

 Test Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

4.12 Test Case 12: Proprietary Data and 6-Digit PIN

Test Case 12/Test Card 12 (Mandatory; ADVT Online Testing)

Test Case Number: 12 (TC # 13 in previous version)

Test Case Name: Proprietary Data and 6-Digit PIN
Objective: To ensure acceptance of a card containing proprietary data. The test also ensures
correct processing of a card with a 6-digit (Offline or Online) PIN.
Card contains proprietary data. It contains the proprietary tags C2 with a value of
“Sample” and tag 9F73 with a value of “80 80” in the PSE. It also contains a proprietary
tag “C3” in a record in the application data.

Note: The PIN value is “123412”.

Regional Requirement: Mandatory All Regions
ADVT Online Testing Required
Business Justification: An issuer may choose to include Discretionary Data on the card. It is important to
ensure that terminals encountering cards that contain such data do not react
negatively to its presence.
Pre-requisite:
Applicable Terminal ☒POS ☒ATM ☒MPOS
Device Type:
Applicable Terminal ☒Contact ☐Contactless
Interface:
Test Card: 12
Test Evidence to be ☐Receipt (where possible) ☐Card-to-Terminal Interaction Log ☒Host Simulator Log
Submitted:
Document Reference: EMV 4.3, Book 3, Section 7.0: Files for Financial Transaction Interchange
Pass Criteria/User Devices that Support Offline PIN:
Validation: The device log must show:
 CVR, byte 2, bit 3 = 1 (Offline PIN Verification performed)
 CVR, byte 2, bit 2 = 0 (Offline PIN Verification did not fail)
Deferred Authorization Devices Devices:
Device must perform a complete transaction without any error messages. A
complete transaction is defined as the performance of all selected VSDC functions from
Application Selection through to Completion. Error messages (such as Not Accepted or
Card Error) are not acceptable and indicate failure of the test.

31 August 2017 Visa Confidential 53

 Test Cases
Test Case 12: Proprietary Data and 6-Digit PIN

Test Case 12/Test Card 12 (Mandatory; ADVT Online Testing)

Pass Criteria/User ADVT Online Testing (Online-Capable or Online-Only Devices including ATMs):
Validation (con’t): Device must perform an above floor limit transaction to send the transaction online to
a VCMS/VMTS/approved test-host simulator. Online Card Authentication must be
successful (Field 44.8 = 2). The transaction must be approved online.
For ADVT Online Testing, additional requirements (such as providing a Retrieval
Reference Number or submitting host logs) may apply and, if applicable, must be
submitted in the compliance report via CCRT.

54 Visa Confidential 31 August 2017

 Test Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

4.13 Test Case 13: Long PDOL and Unrecognized Tag

Test Case 13/Test Card 13 (Mandatory)

Test Case Number: 13 (TC # 14 in previous version)

Test Case Name: Long PDOL and Unrecognized Tag
Objective: To ensure acceptance of a card where the PDOL is requesting a long string of data,
including an unrecognized tag.
Regional Requirement: Mandatory All Regions
Business Justification: Cases have been noted in the past where (often through personalization discrepancies)
the length of a terminal-based data object requested by the card in a Data Object List
(DOL) may differ from the actual length of the data object. EMV specifies that cards
must not be rejected due to this situation. This card is intended to ensure that the
specified rules are being correctly applied.
Pre-requisite:
Applicable Terminal ☒POS ☒ATM ☒MPOS
Device Type:
Applicable Terminal ☒Contact ☐Contactless
Interface:
Test Card: 13
Test Evidence to be ☐Receipt ☐Card-to-Terminal Interaction Log ☐Host Simulator Log
Submitted:
Document Reference: EMV 4.3, Book 3, Section 5.4: Rules for Using a Data Object List
Pass Criteria/User Device must perform a complete transaction without any error messages. A
Validation: complete transaction is defined as the performance of all selected VSDC functions from
Application Selection through to Completion. Error messages (such as Not Accepted or
Card Error) are not acceptable and indicate failure of the test.
In addition, the device must send 97 zeroes followed by the Transaction Date in the
GET PROCESSING OPTIONS command.

31 August 2017 Visa Confidential 55

 Test Cases
Test Case 14: Two Applications and Cardholder Confirmation

4.14 Test Case 14: Two Applications and Cardholder Confirmation

Test Case 14/Test Card 14 (Mandatory)

Test Case Number: 14 (TC # 16 in previous version)

Test Case Name: Two Applications and Cardholder Confirmation
Objective: This test has the following objectives:
 Ensure acceptance of a card that contains two applications distinguishable by
suffixes added to the Visa AID
- Note: Visa Credit application is the first priority application and requires
cardholder confirmation. It has an expired application and the IACs indicate to
decline offline for expired application.
- Note: Visa Debit application is the second priority application and does not
require cardholder confirmation.
 Ensure support of card requirements related to cardholder confirmation
Note: This is a multi-access card.
Regional Requirement: Mandatory All Regions
Business Justification: As multi-application cards become more popular, it is important to ensure that
terminals are able to correctly identify and select appropriate applications on the card
and that the user interface is appropriate for the environment (i.e., the user interface
must not confuse the merchant or the cardholder). According to the Transaction
Acceptance Device Requirements, “Application Selection Indicators for Visa AIDs must
indicate support for Partial selection.”
On this test card, the first application requires cardholder confirmation (which can be
achieved through cardholder selection or cardholder confirmation). If the device does
not support cardholder selection or cardholder confirmation, it must not proceed with
a transaction using the first application (Visa Credit). It must stop processing the Visa
Credit application and proceed to application selection for the second application (Visa
Debit).
Pre-requisite:
Applicable Terminal ☒POS ☒ATM ☒MPOS
Device Type:
Applicable Terminal ☒Contact ☐Contactless
Interface:
Test Card: 14
Test Evidence to be ☐Receipt (where possible) ☐Card-to-Terminal Interaction Log ☐Host Simulator Log
Submitted:

56 Visa Confidential 31 August 2017

 Test Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Test Case 14/Test Card 14 (Mandatory)

Document Reference: EMV 4.3, Book 1, Section 12.3.1: Matching Terminal Applications to ICC Applications
EMV 4.3, Book 1, Section 12.4: Final Selection
EMV 4.3, Book 4, Section 11.3: Application Selection
Transaction Acceptance Device Requirements
Pass Criteria/User All Devices:
Validation: Transaction must be approved offline or approved online. An error message or an
offline decline indicates failure of this test.
Devices That Do Not Support Cardholder Selection/Confirmation:
First, the device attempts to select the Visa Credit application (this is the highest
priority application). Upon recognizing that this application requires cardholder
confirmation, the device terminates the transaction and begins processing the second
application (Visa Debit, the second highest priority application). Since Visa Debit does
not require cardholder confirmation, the transaction proceeds to completion using the
Visa Debit application.
Note: Devices that do not support cardholder confirmation must use the Visa Debit
application for this test; they must not select and process the transaction using the Visa
Credit application. In the event the device erroneously selects the Visa Credit
application, the transaction will be declined offline because this application is expired.
Use of the Visa Credit application for the transaction and/or an offline decline
constitutes a failure of this test.
Devices That Support Cardholder Selection/Confirmation:
Both applications should be displayed to the cardholder in priority order (Visa Credit
first, followed by Visa Debit). The tester should select the “Visa Debit” application
(second) for the transaction, since the “Visa Credit” application has expired.
Note: Since the objective of this test is to ensure that the desired application, as
selected by the cardholder, is the one used for the transaction (not the one with the
highest priority), an erroneous selection of the Visa Credit application by the device will
result in a decline. A transaction using the “Visa Credit” application will be declined
offline because this application has expired. Use of the “Visa Credit” application for this
transaction and/or an offline decline constitutes a failure of this test.
The Visa AID must be printed on the receipt and it is strongly recommended to print
the Application Label (Visa Debit) as well.

31 August 2017 Visa Confidential 57

 Test Cases
Test Case 15: DDA with 1984 Certificate

4.15 Test Case 15: DDA with 1984 Certificate

Test Case 11/Test Card 15 (Mandatory)

Test Case Number: 15 (TC # 18 in previous version)

Test Case Name: DDA with 1984 Certificate
Objective: To ensure acceptance of a card supporting DDA with a certificate signed with Visa CA’s
key of 1984 bits.
Regional Requirement: Mandatory All Regions
Business Justification: Visa is currently providing Issuer Public Key Certificates to issuers based on a 1984-bit
Visa Certificate Authority Public Key. Concerns were raised in the past regarding some
terminals’ ability to support keys of this length, particularly terminals that were
deployed in the earlier stages of chip migration. This card ensures that terminals are
capable of supporting an Issuer Public Key of this length.
Pre-requisite:
Applicable Terminal ☒POS ☒ATM ☒MPOS
Device Type:
Applicable Terminal ☒Contact ☐Contactless
Interface:
Test Card: 15
Test Evidence to be ☐Receipt (where possible) ☐Card-to-Terminal Interaction Log ☐Host Simulator Log
Submitted:
Document Reference: EMV 4.3, Book 3, Section 10.3: Offline Data Authentication
Transaction Acceptance Device Requirements
Pass Criteria/User Devices That Support Offline Data Authentication (ODA):
Validation: The device log must show:
 Transaction Status Information (TSI), byte 1, bit 8 = 1 (Offline Data Authentication
was performed)
 TVR, byte 1, bit 8 = 0 (Offline Data Authentication was performed)
 TVR, byte 1, bit 4 = 0 (DDA did not fail)
The transaction must be approved offline or approved online. An error message or
an offline decline is not acceptable and indicates failure of the test.

58 Visa Confidential 31 August 2017

 Test Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Test Case 11/Test Card 15 (Mandatory)

Devices That Do Not Support ODA:

For these devices, the primary objective of this test case is to ensure correct acceptance
of a card personalized with a 1984-bit IPK Certificate. Device must perform a
complete transaction without any error messages. A complete transaction is
defined as the performance of all selected VSDC functions from Application Selection
through to Completion. Error messages (such as Not Accepted or Card Error) are not
acceptable and indicate failure of the test.

31 August 2017 Visa Confidential 59

 Test Cases
Test Case 16: Plus and Visa Interlink

4.16 Test Case 16: Plus and Visa Interlink

Test Case 16/Test Card 16 (Conditional; ADVT Online Testing)

Test Case Number: 16 (TC # 19 in previous version)

Test Case Name: Plus and Visa Interlink
Objective: This test has the following objectives:
 ATM—Monitor acceptance of a card with the Plus AID in ATM environments;
this card also contains a Suffix to ensure correct Partial Name Selection processing
(A0 00 00 00 03 80 10 01)
 POS—Monitor acceptance of a card with the Visa Interlink AID (no Suffix) at
participating POS environments (A0 00 00 00 03 30 10)
Note: Because regional and/or domestic rules govern the policy on Plus and Interlink,
check with your Visa representative for current local rules and regulations.
Regional Requirement: Conditional
ADVT Online Testing Required
Business Justification: This card is included to assess the general acceptance of:
 Visa RID with the Plus PIX at ATMs—Plus is a deposit access product that offers
worldwide cash access and other around-the-clock financial services through the
Visa Global ATM Network.
Note: the Plus program can be added to any banking card as a complement to the
utility of other Visa products.
 Interlink AID at POS—Interlink is part of Visa’s Integrated Debit Solution, which is
a PIN-based POS Network that allows an account holder to use a stand-alone ATM
card, Visa branded prepaid card, or Visa Check Card with the Interlink acceptance
mark issued by their financial institution to make purchases at participating retail
locations.
Pre-requisite:  ATM—this test applies only to ATMs that support the Plus brand.
 POS—this test applies only to POS environments that support Interlink.
Applicable Terminal ☒POS ☒ATM ☒MPOS
Device Type:
Applicable Terminal ☒Contact ☐Contactless
Interface:
Test Card: 16
Test Evidence to be ☒Receipt (where possible) ☐Card-to-Terminal Interaction Log ☒Host Simulator Log
Submitted:
Document Reference: Visa Global ATM Member Guide, Appendix A: Acquirer Participation Requirements
Transaction Acceptance Device Requirements

60 Visa Confidential 31 August 2017

 Test Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Test Case 16/Test Card 16 (Conditional; ADVT Online Testing)

Pass Criteria/User ADVT Online Testing for ATMs Accepting Plus Cards 2:
Validation: The transaction must be sent online to VCMS/VMTS/approved host simulator and be
approved.
The AID must be printed on the receipt. The receipt should also include the Suffix since
it is part of the AID (A0 00 00 00 03 80 10 01). It is also strongly recommended that the
Application Label (Plus) is printed on the receipt.
For ADVT Online Testing, additional requirements (such as providing a Retrieval
Reference Number or submitting host logs) may apply and, if applicable, must be
submitted in the compliance report via CCRT.
ADVT Online Testing for POS Devices Containing the Interlink AID:
The transaction must be sent online to VCMS/VMTS/approved host simulator and be
approved.
The AID must be printed on the receipt. The receipt should also include the Suffix since
it is part of the AID (A0 00 00 00 03 30 10). It is also strongly recommended that the
Application Label (Interlink) is printed on the receipt.
For ADVT Online Testing, additional requirements (such as providing a Retrieval
Reference Number or submitting host logs) may apply and, if applicable, must be
submitted in the compliance report via CCRT.

Note: Test Case is not applicable to ‘No CVM’ kernels

2 It is assumed that the ATM supports acceptance of Visa in addition to Plus.

31 August 2017 Visa Confidential 61

 Test Cases
Test Case 17: Visa Electron

4.17 Test Case 17: Visa Electron

Test Case 17/Test Card 17 (Conditional)

Test Case Number: 17 (TC # 20 in previous version)

Test Case Name: Visa Electron
Objective: To ensure acceptance of a Visa Electron card with an unusable magnetic stripe.
Note: ATMs must support the Visa Electron AID (A0 00 00 00 03 20 10).
Refer to the Transaction Acceptance Device Guide for more details.
Merchants that agree to accept the Visa Electron product must support the Visa
Electron AID in their terminals (A0 00 00 03 20 10). For other merchants, if the terminal
supports the Visa AID, it is required to support the Visa Electron AID unless the
merchant specifically chooses to exclude it because the merchant does not accept Visa
Electron products by any interface including magnetic stripe.
To accept Visa Electron cards, the only activity that is required is to add the Visa
Electron AID to the terminal. No other activities (coding, adding keys, etc.) are required
as terminals that support Visa Electron use the same code and keys as required for the
Visa AID.
Regional Requirement: Conditional
Business Justification: This card ensures that the rules governing acceptance of the Visa Electron AID are
being applied and that, where a combined reader is used, the terminal does not
perform unnecessary processing on the magnetic-stripe data, which may hinder chip
acceptance. If the Visa AID is supported by the terminal, the Visa Electron AID must
also be supported, unless the merchant has specifically chosen to exclude it, and ATMs
must support the Visa Electron AID.
When the magnetic stripe of a card is read and the service code begins with a 2 or a 6,
indicating that a chip is present, the terminal must process the transaction using the
chip and ignore any other features of the magnetic stripe data. Failure to apply these
rules may lead to acceptance problems with chip-based Visa Electron cards and/or
chip-only products, which do not have meaningful magnetic stripe data.
Pre-requisite: Device supports Visa Electron AID
Applicable Terminal ☒POS ☒ATM ☒MPOS
Device Type:
Applicable Terminal ☒Contact ☐Contactless
Interface:
Test Card: 17
Test Evidence to be ☒Receipt (where possible) ☐Card-to-Terminal Interaction Log ☐Host Simulator Log
Submitted:

62 Visa Confidential 31 August 2017

 Test Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Test Case 17/Test Card 17 (Conditional)

Document Reference: EMV 4.3, Book 4, 6.6

Transaction Acceptance Device Requirements
Pass Criteria/User The transaction must be approved offline or approved online. An error message or
Validation: an offline decline is not acceptable and indicates failure of the test.
It is strongly recommended that the Application Label (VISA ELECTRON) or the
Application Preferred Name (ELECTRON DE VISA) (where appropriate) be printed on
the receipt.
Note: To facilitate Visa Electron acceptance, all chip-reading devices that support the
Visa Debit/Credit AID must also support the Visa Electron AID, unless specifically
excluded by the merchant who has elected not to accept transactions from Visa
Electron cards through any interface including magnetic stripe. Please consult with your
Visa representative for further local rules and regulations related to Visa Electron
acceptance.

31 August 2017 Visa Confidential 63

 Test Cases
Test Case 18: Combination CVM and Visa Fleet Chip

4.18 Test Case 18: Combination CVM and Visa Fleet Chip

Test Case 18/Test Card 18 (Mandatory)

Test Case Number: 18 (TC # 23 in previous version)

Test Case Name: Combination CVM and Visa Fleet Chip
Objective: The objectives of this test case are to:
 Ensure that the terminal correctly processes a card containing a CVM List that
supports the combination CVM of Signature and Offline Plaintext PIN
 Ensure that a card that contains the Visa Fleet Chip (VFC) feature is accepted at
standard EMV devices
Note: The Offline PIN value is: “1234”. The Online PIN value is “1234”.
Regional Requirement: Mandatory
Business Justification: Although a combination CVM (i.e., Signature plus Offline Plaintext PIN) is not
commonly used by Visa issuers, it is important to ensure all terminals accept this CVM
method.
It is also important to ensure that, as additional payment features are introduced to the
card (such as the Visa Fleet Chip feature), the card continues to be accepted at
standard EMV acceptance devices.
Pre-requisite:
Applicable Terminal ☒POS ☒ATM ☒MPOS
Device Type:
Applicable Terminal ☒Contact ☐Contactless
Interface:
Test Card: 18
Test Evidence to be ☐Receipt (where possible) ☐Card-to-Terminal Interaction Log ☐Host Simulator Log
Submitted:
Document Reference: EMV 4.3, Book 3, Section 10.5: Cardholder Verification
Transaction Acceptance Device Requirements

64 Visa Confidential 31 August 2017

 Test Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Test Case 18/Test Card 18 (Mandatory)

Pass Criteria/User Device must perform a complete transaction without any error messages. A
Validation: complete transaction is defined as the performance of all selected VSDC functions from
Application Selection through to Completion. Error messages (such as Not Accepted or
Card Error) are not acceptable and indicate failure of the test.
 If the device supports both Offline Plaintext PIN and Signature then, by default, it
supports the combination CVM of Offline Plaintext PIN and Signature. If this is the
case, the device must validate the cardholder’s Offline Plaintext PIN and print the
signature line on the receipt:
- CVR, byte 2, bit 3 = 1 (Offline PIN Verification performed)
- CVR, byte 2, bit 2 = 0 (Offline PIN Verification did not fail)
 For ATMs, Online PIN must be used:
- TVR, byte 3, bit 3 = 1 (Online PIN Entered)
 For devices supporting Online PIN and signature or Online PIN only, Online PIN
must be used:
- TVR, byte 3, bit 3 = 1 (Online PIN Entered)
 For devices supporting Offline Plaintext PIN but not Online PIN, Offline Plaintext PIN
must be used:
- CVR, byte 2, bit 3 = 1 (Offline PIN Verification performed)
- CVR, byte 2, bit 2 = 0 (Offline PIN Verification did not Fail)
 For devices that only support signature, signature must be used

31 August 2017 Visa Confidential 65

 Test Cases
Test Case 19: Account Number with Padded Fs

4.19 Test Case 19: Account Number with Padded Fs

Test Case 19/Test Card 19 (Mandatory; ADVT Online Testing)

Test Case Number: 19 (TC # 24 in previous version)

Test Case Name: Account Number with Padded Fs
Objective: To determine whether the terminal can handle transactions from a card that contains a
16-digit account number padded with hexadecimal “Fs” to maximize its field length.
Regional Requirement: Mandatory
ADVT Online Testing Required
Business Justification: There have been cases where issuers have used the maximum length of the Primary
Account Number field by padding the unused portion with ‘F’s’. It is important to
ensure that all terminals accept any card configured in this way and that the padded
‘F’s’ are not printed on the receipt.
Pre-requisite:
Applicable Terminal ☒POS ☒ATM ☒MPOS
Device Type:
Applicable Terminal ☒Contact ☐Contactless
Interface:
Test Card: 19
Test Evidence to be ☒Receipt (where possible) ☐Card-to-Terminal Interaction Log ☒Host Simulator Log
Submitted:
Document Reference: EMV 4.3, Book 3, Section 4.3: Data Element Format Conventions
Pass Criteria/User Deferred Authorization Devices:
Validation: Device must perform a complete transaction without any error messages. A
complete transaction is defined as the performance of all selected VSDC functions from
Application Selection through to Completion. Error messages (such as Not Accepted or
Card Error) are not acceptable and indicate failure of the test.
The device must not print the padded F’s or the full Primary Account Number on the
receipt.

66 Visa Confidential 31 August 2017

 Test Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Test Case 19/Test Card 19 (Mandatory; ADVT Online Testing)

Pass Criteria/User ADVT Online Testing (Online-Capable or Online-Only Devices including ATMs):
Validation (con’t): Device must perform an above floor limit transaction to send the transaction online to
a VCMS/VMTS/approved test-host simulator. Online Card Authentication must be
successful (Field 44.8 = 2). The transaction must be approved online.
For ADVT Online Testing, additional requirements (such as providing a Retrieval
Reference Number or submitting host logs) may apply and, if applicable, must be
submitted in the compliance report via CCRT.
The device must not print the padded F’s or the full Primary Account Number on the
receipt.

31 August 2017 Visa Confidential 67

 Test Cases
Test Case 20: No PAN Sequence Number

4.20 Test Case 20: No PAN Sequence Number

Test Case 20/Test Card 20 (Mandatory; ADVT Online Testing)

Test Case Number: 20 (TC # 25 in previous version)

Test Case Name: No PAN Sequence Number
Objective: To ensure acceptance of a card without a PAN Sequence Number.
Regional Requirement: Mandatory
ADVT Online Testing Required
Business Justification: The PAN Sequence Number is an optional data element that issuers may use to
differentiate card applications having the same Primary Account Number. If the issuer
chooses not to include this data element, it is important to ensure that terminals and
acquirer host systems recognize this omission and do not erroneously include this data
element in the online message.
Note: The PAN Sequence Number, if present, must come from the card; the terminal or
acquirer must never populate the PAN Sequence Number field in the online or clearing
message with a static value or a value from a terminal or acquirer-system table.
Pre-requisite:
Applicable Terminal ☒POS ☒ATM ☒MPOS
Device Type:
Applicable Terminal ☒Contact ☐Contactless
Interface:
Test Card: 20
Test Evidence to be ☐Receipt (where possible) ☐Card-to-Terminal Interaction Log ☒Host Simulator Log
Submitted:
Document Reference: Transaction Acceptance Device Requirements
Pass Criteria/User Deferred Authorization Devices:
Validation: Device must perform a complete transaction without any error messages. A
complete transaction is defined as the performance of all selected VSDC functions from
Application Selection through to Completion. Error messages (such as Not Accepted or
Card Error) are not acceptable and indicate failure of the test.

68 Visa Confidential 31 August 2017

 Test Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Test Case 20/Test Card 20 (Mandatory; ADVT Online Testing)

Pass Criteria/User ADVT Online Testing (Online-Capable or Online-Only Devices including ATMs):
Validation (con’t): Device must perform an above floor limit transaction to send the transaction online to
a VCMS/VMTS/approved test-host simulator. Online Card Authentication must be
successful (Field 44.8 = 2). The transaction must be approved online.
Since the Application PAN Sequence Number is not present on the card, the acquirer
may either exclude the field entirely from the request message (Field 23) or include it
with all zeroes.
For ADVT Online Testing, additional requirements (such as providing a Retrieval
Reference Number or submitting host logs) may apply and, if applicable, must be
submitted in the compliance report via CCRT.

31 August 2017 Visa Confidential 69

 Test Cases
Test Case 21: PAN Sequence Number of 11

4.21 Test Case 21: PAN Sequence Number of 11

Test Case 21/Test Card 21 (Mandatory; ADVT Online Testing)

Test Case Number: 21 (TC # 26 in previous version)

Test Case Name: PAN Sequence Number of 11
Objective: To ensure acceptance of a card with a PAN Sequence Number of 11.
Regional Requirement: Mandatory
ADVT Online Testing Required
Business Justification: The PAN Sequence Number is an optional data element that issuers may use to
differentiate card applications having the same Primary Account Number. In most
cases, when this data element is used, its value is less then ‘10’. There have been
interoperability problems, however, when the value is over 10 because acquirers have
formatted this binary value as hex. The incorrect formatting of this field leads to
erroneous Online Card Authentication failures, which may lead to declines. This test
ensures that a PAN Sequence Number greater than 10 is formatted correctly as a
binary value.
Pre-requisite:
Applicable Terminal ☒POS ☒ATM ☒MPOS
Device Type:
Applicable Terminal ☒Contact ☐Contactless
Interface:
Test Card: 21
Test Evidence to be ☐Receipt (where possible) ☐Card-to-Terminal Interaction Log ☒Host Simulator Log
Submitted:
Document Reference: Transaction Acceptance Device Requirements
Pass Criteria/User Deferred Authorization Devices:
Validation: Device must perform a complete transaction without any error messages. A
complete transaction is defined as the performance of all selected VSDC functions from
Application Selection through to Completion. Error messages (such as Not Accepted or
Card Error) are not acceptable and indicate failure of the test.

70 Visa Confidential 31 August 2017

 Test Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Test Case 21/Test Card 21 (Mandatory; ADVT Online Testing)

Pass Criteria/User ADVT Online Testing (Online-Capable or Online-Only Devices including ATMs):
Validation (con’t): Device must perform an above floor limit transaction to send the transaction online to
a VCMS/VMTS/approved test-host simulator. Online Card Authentication must be
successful (Field 44.8 = 2). The transaction must be approved online.
The online message must contain Field 23: PAN Sequence Number with a value of 11
(alphanumeric).
For ADVT Online Testing, additional requirements (such as providing a Retrieval
Reference Number or submitting host logs) may apply and, if applicable, must be
submitted in the compliance report via CCRT.

31 August 2017 Visa Confidential 71

 Test Cases
Test Case 22: 1144-Bit Issuer Public Key

4.22 Test Case 22: 1144-Bit Issuer Public Key

Test Case 22/Test Card 22 (Mandatory)

Test Case Number: 22 (TC # 27 in previous version)

Test Case Name: 1144-Bit Issuer Public Key
Objective: To ensure acceptance of a card with an Issuer Public Key Certificate based on an 1144-
bit Issuer Public Key.
Regional Requirement: Mandatory
Business Justification: In the past, some faulty RSA cryptographic engines were discovered that were unable
to handle key lengths not evenly divisible by 16, 8 or 4. With this in mind, a card with
an Issuer Public Key Certificate based on an 1144-bit (i.e., 143 bytes) Issuer Public Key
was proposed. This test ensures that terminals can support cards with Issuer Public
Keys that are not evenly divisible by 16, 8, or 4.
Pre-requisite:
Applicable Terminal ☒POS ☒ATM ☒MPOS
Device Type:
Applicable Terminal ☒Contact ☐Contactless
Interface:
Test Card: 22
Test Evidence to be ☐Receipt (where possible) ☐Card-to-Terminal Interaction Log ☐Host Simulator Log
Submitted:
Document Reference: EMV 4.3, Book 2, Section 6.1: Keys and Certificates
Pass Criteria/User Devices That Support SDA:
Validation: The transaction must be approved offline or approved online. An error message or
an offline decline is not acceptable and indicates failure of the test.
The device log must show:
 Transaction Status Information (TSI), byte 1, bit 8 = 1 (Offline Data Authentication
was performed)
 TVR, byte 1, bit 8 = 0 (Offline Data Authentication was performed)
 TVR, byte 1, bit 7 = 0 (SDA did not fail)
Devices That Do No Support SDA:
Not Applicable.

72 Visa Confidential 31 August 2017

 Test Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

4.23 Test Case 23: Single Application/Multiple Features

Test Case 23/Test Card 23 (Mandatory; ADVT Online Testing)

Test Case Number: 23 (TC # 28 in previous version)

Test Case Name: Single Application/Multiple Features
Objective: To ensure acceptance of a card with the following features:
 Issuer URL in the FCI Issuer Discretionary Data
 Extra Issuer Application Data
 Application Expiration Date = December 31, 2025
 CVM List with no Signature
 Specific IAC-Denial settings related to PIN activity
 Cryptogram Version Number = 18 (hex ‘12’)
 Card declines transaction if Issuer Authentication fails or was not performed
Regional Requirement: Mandatory
ADVT Online Testing Required
Business Justification: The Issuer URL was introduced to allow issuers to specify the location of their Library
Servers for Internet service. There are a few known cases where terminals reacted
negatively to cards containing an issuer URL. This test ensures that terminals can
accept a card containing an issuer URL.
A CVM List that does not contain “Signature” has been known to cause acceptance
problems with some terminals. This test ensures that terminals can accept a card
without this CVM.
Since there is an expectation that a significant number of issuers will begin supporting
CVN 18 card products over the coming years, acquirers need to prepare for support of
this cryptogram version.

Pre-requisite:
Applicable Terminal ☒POS ☒ATM ☒MPOS
Device Type:
Applicable Terminal ☒Contact ☐Contactless
Interface:
Test Card: 23
Test Evidence to be ☐Receipt (where possible) ☐Card-to-Terminal Interaction Log ☒Host Simulator Log
Submitted:
Document Reference: EMV

31 August 2017 Visa Confidential 73

 Test Cases
Test Case 23: Single Application/Multiple Features

Test Case 23/Test Card 23 (Mandatory; ADVT Online Testing)

Pass Criteria/User Devices Supporting Offline PIN:

Validation: The device logs must show:
 CVR byte 2 bit 3 = 1 (Offline PIN Verification performed)
 CVR, byte 2, bit 2 = 0 (Offline PIN Verification did not fail)
Pass Criteria/User Devices Supporting Online PIN:
Validation (con’t): The device logs must show:
 TVR, byte 3, bit 3 = 1 (Online PIN Entered)
Deferred Authorization Devices:
Device must perform a complete transaction without any error messages. A
complete transaction is defined as the performance of all selected VSDC functions from
Application Selection through to Completion. Error messages (such as Not Accepted or
Card Error) are not acceptable and indicate failure of the test.
ADVT Online Testing (Online-Capable or Online-Only Devices including ATMs):
Device must perform an above floor limit transaction to send the transaction online to
a VCMS/VMTS/approved test-host simulator. Online Card Authentication must be
successful (Field 44.8 = 2). The transaction must be approved online.
For ADVT Online Testing, additional requirements (such as providing a Retrieval
Reference Number or submitting host logs) may apply and, if applicable, must be
submitted in the compliance report via CCRT.

Note: An Online Decline is acceptable for Signature-only kernels. However, the device
must still be able to process a CVN 18 transaction

74 Visa Confidential 31 August 2017

 Test Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

4.24 Test Case 24: Multi-application/Multiple Features

Test Case 24/Test Card 24 (Mandatory; ADVT Online Testing)

Test Case Number: 24 (This is a new Test Case)
Test Case Name: Multi-application/Multiple Features
Objective: To ensure acceptance and correct terminal behavior for a Multi-application card with
the following features supported:
 Presence of a Payment System Environment (PSE)
Application # 1:
 Issuer Authentication is set to Mandatory and application set not to decline the
transaction when:
- the ARPC is not returned
- Issuer Authentication fails
 Presence of the Application Selection Registered Proprietary Data (9F0A) Tag
 Contains a CVM List (8E) with:
- Online Enciphered PIN for Credit being the preferred Method
 Support of Cryptogram Version Number ‘10’
Application # 2:
 Issuer Authentication set to Mandatory and application set not to decline the
transaction when:
- the ARPC is not returned
- Issuer Authentication fails
 Presence of the Application Selection Registered Proprietary Data (9F0A) Tag
 Contains a CVM List (8E) with:
- Online Enciphered PIN for Credit being the preferred Method
 Support of Cryptogram Version Number ‘22’
Note: this Test Case is not applicable for Quick Chip implementations in the US. Quick
Chip merchants can use this test card/test case to test online pin acceptance for credit
based on merchant/acquirer support (pass criteria varies accordingly)
Note 2: In support of this Test Case, VCMS/VMTS/Visa-confirmed host simulator will not
return Issuer Authentication Data for transactions involving this card.
Business Justification: The return of an Authorization Response Cryptogram (ARPC) in the authorization
response message is optional to the Issuer. Some terminals have been known to
erroneously request a transaction reversal in cases where the Issuer Authentication

31 August 2017 Visa Confidential 75

 Test Cases
Test Case 24: Multi-application/Multiple Features

Data that carries the ARPC is not present. This card is primarily intended to test for
such erroneous terminal behavior.
Additionally, the following recent introductions within the Visa Chip card specifications
justifies the use of this card to ensure no negative terminal reactions:
 Introduction of Cryptogram Version Number “22”
 Introduction of a new Application Selection Registered Proprietary Data (9F0A) Tag

Applicable Terminal ☒POS ☒ATM ☒MPOS

Device Type:
Applicable Terminal ☒Contact ☐Contactless
Interface:
Test Card: 24
Document Reference: Visa Integrated Circuit Card Specification (VIS), Version 1.5 – Section 13.7.2 – Approval
Requested After Online Authorization
Pass Criteria/User Note: Since neither application supports ODA, Online transactions shall always be
Validation initiated with this card.

All Devices (irrespective of capabilities supported):

A complete transaction shall be performed. This is defined as the performance of all
applicable VSDC functions from Application Selection through to Completion. Error
messages (such as Not Accepted or Card Error) are not acceptable and indicate failure
of the test.

Devices supporting Cardholder Selection/Confirmation:

For these types of devices, two separate transactions (one for each Application) will
need to be performed for this test case:
a) For Application # 1:
1. When prompted for Application Selection, select Application # 1
2. Initiate an Online transaction
3. The transaction should be completed online (using Application #1 (A0 00 00 00
03 10 10 01) and be approved by VCMS/VMTS or a Visa-confirmed Host
Simulator, following the successful performance of Online Card Authentication
(Field 44.8 = 2) for CVN # 10
- CVR, byte 2, bit 4 = 0 (Issuer Authentication performed and did not fail at
Second Generate AC.
Note: this can only be validated where card-to-terminal logs are available
TVR Byte 3 bit 3 = 1 (Online PIN entered) based on merchant/acquirer
-
support of Online Pin for Credit (conditional)
4. After going online the transaction must be approved at the terminal.
b) For Application # 2:
1. On completion of Step (a), reinsert the card

76 Visa Confidential 31 August 2017

 Test Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

2. When prompted for Application Selection, select Application # 2

3. Initiate an Online transaction
4. The transaction should be completed online (using Application #1 (A0 00 00 00
03 10 10 02) and be approved by VCMS/VMTS or a Visa-confirmed Host
Simulator, following the successful performance of Online Card Authentication
(Field 44.8 = 2) for CVN # 22
- CVR, byte 2, bit 4 = 0 (Issuer Authentication performed and did not fail) at
Second Generate AC. Note: this can only be validated where card-to-
terminal logs are available
- TVR Byte 3 bit 3 = 1 (Online PIN entered) based on merchant/acquirer
support of Online Pin for Credit (conditional)
5. After going online the transaction must be approved at the terminal.

Note: In this scenario, the overall result of the test case is dependent on successfully
completing the Pass Criteria for both Steps (a) and (b).

Devices not supporting Cardholder Selection/Confirmation:

For these types of devices, the highest priority application (Application # 2) shall be
selected by the terminal.
1. Initiate an Online transaction
2. The transaction should be completed online (using Application #1 (A0 00 00 00
03 10 10 02) and be approved by VCMS/VMTS or a Visa-confirmed Host
Simulator, following the successful performance of Online Card Authentication
(Field 44.8 = 2) for CVN # 22
- CVR, byte 2, bit 4 = 0 (Issuer Authentication performed and did not fail) at
Second Generate AC. Note: this can only be validated where card-to-
terminal logs are available
i. TVR Byte 3 bit 3 = 1 (Online PIN entered) based on merchant/acquirer
support of Online Pin for Credit (conditional)

Additional Actions that may be taken by Visa Testing Analysts:

To verify the correct outcome of this test case, the Visa Testing Analyst may need to
extract the VCMS Log for an online transaction initiated from this card (assuming
that VCMS was used for testing) and perform the following checks:
1) Confirm that the Log does not contain Issuer Authentication Data (tag '91') in
Field 55 of the 0110 response message returned to the acquirer/terminal
2) Confirm there was NO subsequent 400/420 reversal message from the same
transaction on this test case. If a reversal message is present, this could be an
erroneous indication that the terminal is expecting Tag 91 in F55 (APRC) to be
returned and as a result the test has failed.
Note: Since VCMS/VMTS or the Visa-confirmed host simulator will respond without
an Authorization Response Cryptogram, if the online transaction results in a decline,

31 August 2017 Visa Confidential 77

 Test Cases
Test Case 24: Multi-application/Multiple Features

the test has failed (indicating that the device has likely rejected the absence of the
response cryptogram).

78 Visa Confidential 31 August 2017

 Test Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

31 August 2017 Visa Confidential 79

 Visa CA Test Public Keys for VSDC
1152 Bit VSDC TEST Key

A Visa CA Test Public Keys for VSDC

For devices that support offline functionality, these test keys need to be loaded into the terminal to
support the tests associated with Offline Data Authentication and Offline Enciphered PIN.

Note: Expiration dates are not defined for test CA Public Keys, and it should not be assumed that a test
key has the same expiry date as the live key of the same length. If your Terminal Management
System requires expiry dates to be provided for CAPKs then please set the expiry date to 31
December 2025 for all test keys.

Important: Prior to deployment, these keys must be removed from the terminal and replaced with the
Visa CA production keys.

A.1 1152 Bit VSDC TEST Key

This key is the Visa CA Public 1152 bit TEST key:

Table A–1: 1152 Bit VSDC Test Key

Component Value

Registered Application A0 00 00 00 03
Provider Identifier (RID)

Index 95

Modulus BE 9E 1F A5 E9 A8 03 85 29 99 C4 AB 43 2D B2 86 00 DC D9 DA B7
6D FA AA 47 35 5A 0F E3 7B 15 08 AC 6B F3 88 60 D3 C6 C2 E5 B1
2A 3C AA F2 A7 00 5A 72 41 EB AA 77 71 11 2C 74 CF 9A 06 34 65
2F BC A0 E5 98 0C 54 A6 47 61 EA 10 1A 11 4E 0F 0B 55 72 AD D5
7D 01 0B 7C 9C 88 7E 10 4C A4 EE 12 72 DA 66 D9 97 B9 A9 0B 5A
6D 62 4A B6 C5 7E 73 C8 F9 19 00 0E B5 F6 84 89 8E F8 C3 DB EF
B3 30 C6 26 60 BE D8 8E A7 8E 90 9A FF 05 F6 DA 62 7B

Exponent 03

Secure Hash Algorithm-1 EE 15 11 CE C7 10 20 A9 B9 04 43 B3 7B 1D 5F 6E 70 30 30 F6

Hash

Comments: The production version of Visa’s 1152-bit CA public key is currently

set to expire on December 31, 2015.

80 Visa Confidential 31 August 2017

 Visa CA Test Public Keys for VSDC
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

A.2 1408 Bit VSDC TEST Key

This key is the Visa CA Public 1408 bit TEST key:

Table A–2: 1408 Bit VSDC Test Key

Component Value

Registered Application A0 00 00 00 03
Provider Identifier (RID)

Index 92

Modulus 99 6A F5 6F 56 91 87 D0 92 93 C1 48 10 45 0E D8 EE 33 57 39 7B
18 A2 45 8E FA A9 2D A3 B6 DF 65 14 EC 06 01 95 31 8F D4 3B E9
B8 F0 CC 66 9E 3F 84 40 57 CB DD F8 BD A1 91 BB 64 47 3B C8 DC
9A 73 0D B8 F6 B4 ED E3 92 41 86 FF D9 B8 C7 73 57
89 C2 3A 36 BA 0B 8A F6 53 72 EB 57 EA 5D 89 E7 D1 4E 9C 7B 6B
55 74 60 F1 08 85 DA 16 AC 92 3F 15 AF 37 58 F0 F0 3E BD 3C 5C
2C 94 9C BA 30 6D B4 4E 6A 2C 07 6C 5F 67 E2 81 D7 EF 56 78 5D
C4 D7 59 45 E4 91 F0 19 18 80 0A 9E 2D C6 6F 60 08 05 66 CE 0D
AF 8D 17 EA D4 6A D8 E3 0A 24 7C 9F

Exponent 03

Secure Hash Algorithm-1 42 9C 95 4A 38 59 CE F9 12 95 F6 63 C9 63 E5 82 ED 6E B2 53

Hash

Comments: The maximum expiration date for certificates issued using Visa’s
1408-bit CA public key is December 31, 2016. Considered to have
an anticipated lifetime to at least December 31, 2018.

31 August 2017 Visa Confidential 81

 Visa CA Test Public Keys for VSDC
1984 Bit VSDC TEST Key

A.3 1984 Bit VSDC TEST Key

This key is the Visa CA Public 1984 bit TEST key:

Table A–3: 1984 Bit VSDC Test Key

Component Value

Registered Application A0 00 00 00 03
Provider Identifier (RID)

Index 94

Modulus AC D2 B1 23 02 EE 64 4F 3F 83 5A BD 1F C7 A6 F6 2C CE 48 FF EC
62 2A A8 EF 06 2B EF 6F B8 BA 8B C6 8B BF 6A B5 87 0E ED 57 9B
C3 97 3E 12 13 03 D3 48 41 A7 96 D6 DC BC 41 DB F9 E5 2C 46 09
79 5C 0C CF 7E E8 6F A1 D5 CB 04 10 71 ED 2C 51 D2 20 2F 63 F1
15 6C 58 A9 2D 38 BC 60 BD F4 24 E1 77 6E 2B C9 64 80 78 A0 3B
36 FB 55 43 75 FC 53 D5 7C 73 F5 16 0E A5 9F 3A FC 53 98 EC 7B
67 75 8D 65 C9 BF F7 82 8B 6B 82 D4 BE 12 4A 41 6A B7 30 19 14
31 1E A4 62 C1 9F 77 1F 31 B3 B5 73 36 00 0D FF 73 2D 3B 83 DE
07 05 2D 73 03 54 D2 97 BE C7 28 71 DC CF 0E 19 3F 17 1A BA 27
EE 46 4C 6A 97 69 09 43 D5 9B DA BB 2A 27 EB 71 CE EB DA FA 11
76 04 64 78 FD 62 FE C4 52 D5 CA 39 32 96 53 0A A3 F4 19 27 AD
FE 43 4A 2D F2 AE 30 54 F8 84 06 57 A2 6E 0F C6 17

Exponent 03

Secure Hash Algorithm-1 C4 A3 C4 3C CF 87 32 7D 13 6B 80 41 60 E4 7D 43

Hash B6 0E 6E 0F

Comments: This key length is currently considered to have an anticipated

lifetime to at least December 31, 2018

82 Visa Confidential 31 August 2017

 Visa CA Test Public Keys for VSDC
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

31 August 2017 Visa Confidential 83

 Terminal Action Codes (TACs)
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

B Terminal Action Codes (TACs)

This appendix provides the Terminal Action Codes for terminals. Please refer to Visa 1.4.1 or VIS 1.5,
Section 10.2: Terminal Data for additional details.
Table B–1: Terminal Action Codes (TACs)

Terminal Action Value

Code (TAC)

TAC—Denial 0010000000
The TAC value causes a decline for the following condition:
 Service not allowed for card product
TAC—Online DC4004F800
This TAC value generates an online authorization when:
 Offline data authentication is not performed or failed
 The PAN is on the terminal exception file
 The application is expired
 An Online PIN is entered
 The transaction exceeds the floor limit
 The upper (9F23) or lower consecutive offline limit (9F14) is exceeded)
 The transaction is randomly selected for online processing
 The terminal forced the transaction online
 CDA failure
TAC—Default DC4000A800
This TAC value generates a decline if the transaction cannot be sent online for
authorization when:
 Offline data authentication is not performed or failed
 The PAN is on the terminal exception file
 The application is expired
 The transaction exceeds the floor limit
 The Upper Consecutive Offline Limit (9F23) is exceeded
 The merchant forced the transaction online
 CDA failure

Markets not supporting offline data authentication in cards may remove the TAC—Online and
TAC—Default settings for Offline Data Authentication Not Performed resulting in a TAC—Online value
of 584004F800 and a TAC—Default value of 584000A800.

84 Visa Confidential 31 August 2017

 Terminal Action Codes (TACs)
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

31 August 2017 Visa Confidential 85

 VSDC Stand-in Processing Conditions
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0) – Draft 3

C VSDC Stand-in Processing Conditions

This section provides the VSDC Stand-in Processing Conditions. When the Acquirer is connected to
VCMS/VMTS and the transaction associated with one of the ADV Toolkit cards is sent online,
VCMS/VMTS will use these conditions to make the online authorization decision.

Note: The Route to Issuer Default is not used as the transaction is processed in Stand-in. Only the Stand-
in Authorization Response Defaults are used.

This information is valuable in determining the reason that VCMS/VMTS either approved or declined
the online-initiated transaction.

For example, the VSDC Stand-in Authorization Response Default for expired application is “decline
offline.” If the application is expired and the transaction is sent online to VCMS/VMTS, VCMS/VMTS will
decline the transaction. VCMS/VMTS will indicate the decline in the Response Code (field 39) in the
response message.

Note: Currently, there is no VSDC Stand-in Processing Condition for CDA.

Table C–1: VSDC Stand-In Processing Conditions

Stand-in
Author-
ization
Stand-In Condition Source Route-to- Response
Issuer Default Default

1 Transaction exceeds floor limit TVR No Approve

2 Transaction selected randomly for online TVR No Approve

processing

3 Cardholder verification failed TVR Yes Decline

4 Unrecognized cardholder verification method TVR Yes Approve

5 Offline PIN verification failed CVR Yes Decline

6 PIN entry required and PIN pad not present or not TVR Yes Decline
working

7 PIN entry required, PIN pad is present, but PIN not TVR Yes Decline
entered

8 Offline PIN try limit exceeded CVR or Yes Decline

TVR

9 Exceeded total, domestic, or international counters CVR Yes Approve

10 Lower consecutive offline limit exceeded TVR Yes Approve

86 Visa Confidential 31 August 2017

 VSDC Stand-in Processing Conditions
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Stand-in
Author-
ization
Stand-In Condition Source Route-to- Response
Issuer Default Default

11 Upper consecutive offline limit exceeded TVR Yes Approve

12 Application not yet effective TVR Yes Decline

13 Issuer Authentication failed on last transaction CVR Yes Approve

Issuer cannot
modify

14 Offline Data Authentication not performed TVR Yes Approve

Note: Not applicable to ATM transactions Issuer cannot
modify

15 Script update succeeded on last transaction CVR Yes Approve

Issuer cannot Issuer
modify cannot
modify

16 Script update failed on last transaction CVR Yes Approve

Issuer cannot
modify

17 Merchant forced transaction online TVR Yes Decline

18 Last online transaction not completed CVR Yes Approve

19 Card Authentication failure and Card ** Yes Decline

Authentication reliable Issuer cannot
modify

20 Card Authentication failure and Card ** Yes Decline

Authentication unreliable Issuer cannot
modify

21 Card Authentication not performed and Card ** Yes Decline

Authentication unreliable Issuer cannot
modify

22 DDA failed TVR Yes Decline

Issuer cannot
modify

23 DDA failed on last transaction and was declined CVR Yes Approve
offline Issuer cannot
modify

31 August 2017 Visa Confidential 87

 VSDC Stand-in Processing Conditions
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0) – Draft 3

88 Visa Confidential 31 August 2017

 VSDC Stand-in Processing Conditions
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

31 August 2017 Visa Confidential 89

 Merchant Terminal Environments
1984 Bit VSDC TEST Key

D Merchant Terminal Environments

This appendix outlines the following merchant terminal environments:
 Stand-Alone Terminals (SATs)
 Stand-Alone Terminals (SATs) with Semi-Integrated Functionality
 Fully Integrated Environments
- Integrated: POS to Acquirer
- Integrated: In-Store Controller to Acquirer
- Integrated: Regional Network Controller to Acquirer

The EMV chip implementation process for POS environments and subsequently its testing requirements
will vary according to merchant type, size, and complexity of the payment system infrastructure. Since
merchant POS environments can be as simple as a stand-alone payment terminal at a small retailer, or
as complex as a series of interconnected state-of-the-art large retailer systems, this section is intended
to provide a general overview of the range of payment terminal environments. It gives users a sense of
the impact of incorporating EMV functionality into these different environments and the testing
implications.

90 Visa Confidential 31 August 2017

 Merchant Terminal Environments
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0) – Draft 3

D.1 Stand-Alone Terminals (SATs)

Separate from a merchant’s electronic cash register, a stand-alone payment terminal serves the primary
purpose of requesting authorizations and clearing payment card transactions. Typically merchant-
facing, it may also include a customer-facing device (e.g., PIN Pad for customer PIN entry). Since the
stand-alone terminal is usually supplied and managed by merchant acquirers, in many cases it contains
acquirer-specific transaction functionality within its payment application.

For smaller merchants, a stand-alone payment terminal POS is usually not connected to their electronic
cash register, but directly to an acquirer’s host processor via a Public Switched Telephone Network
(PSTN) or internet connection. Slightly larger merchants may, however, have their stand-alone payment
terminal directly connected to their electronic cash register.
Figure D–1: Stand-Alone Terminal

Figure D–2: Stand-Alone Terminal (SAT) with Cardholder-Facing Device

Characteristics of Stand-Alone Terminals:

 Mostly merchant facing, but may include a customer-facing device (PIN Pad); typically no
signature capture
 If a PIN Pad is connected, it typically contains a chip card reader but not a magnetic stripe reader
 Typically connected directly to a host processor
 Used mostly by smaller merchants (US Tier 4-5)

31 August 2017 Visa Confidential 91

 Merchant Terminal Environments
Stand-Alone Terminals (SATs) with Semi-Integrated Functionality

D.2 Stand-Alone Terminals (SATs) with Semi-Integrated Functionality

Stand-alone terminals with semi-integrated functionality typically utilize a customer-facing device that
interfaces with a POS system. The acquirer-specific transaction functionality generally resides either
within the payment application of the customer-facing device or in other “middleware” that is physically
and logically separated from the POS system.
Figure D–3: Stand-Alone Terminal (SAT) with Semi-Integrated Functionality

Characteristics of Stand-Alone Terminal with Semi-integrated Functionality:

 POS provides only the sale amount of the transaction but it is not involved in the processing of the
payment transaction
 No payment card data is routed through the POS
 POS provides inventory management
 EMV code typically resides in the customer-facing device (PIN Pad)

92 Visa Confidential 31 August 2017

 Merchant Terminal Environments
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0) – Draft 3

D.3 Fully Integrated Environments

In the fully integrated merchant environments, the card acceptance device is usually customer-facing
and is connected to and driven by logic that resides or co-resides in the POS system. All the acquirer-
specific transaction logic is embedded within or behind the POS system and not within the customer-
facing device.

This environment is typically implemented by the larger retailers and chain stores.
Figure D–4: Integrated—POS to Acquirer

Figure D–5: Integrated—In-Store Controller (ISC) to Acquirer

31 August 2017 Visa Confidential 93

 Merchant Terminal Environments
Fully Integrated Environments

Figure D–6: Integrated—Regional Network Controller to Acquirer

Characteristics of Integrated Environments:

 Payment card data routes from customer-facing device to POS system, through other merchant
systems (as needed), and to the acquirer
 The customer-facing device may be capable of signature capture
 The majority of devices are connected serially; some use Ethernet

94 Visa Confidential 31 August 2017

 Merchant Terminal Environments
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0) – Draft 3

31 August 2017 Visa Confidential 95

 ADVT Testing Use Cases
Use Cases

E ADVT Testing Use Cases

This appendix provides frequently asked questions related to ADVT testing.

Note: All references to ADVT testing refer to completion of all the test cases in the toolkit.

Although the list of use cases provided in this appendix is not exhaustive, it includes real-world scenarios
taken from user queries. Users should consult with their Visa representative for further clarifications on
any remaining uncertainties or scenarios not specifically covered here.

For more information, refer to Section 2.5.1: ADVT Usage Guidelines. This section outlines the situations
where ADVT testing is required, recommended, and not required.

E.1 Use Cases

This section provides use cases on the following:

 General Terminal Use Cases
 Acquirer/Processor Platform Use Cases
 System Integrator and Value-Added Reseller (VAR) Use Cases

A terminal can be any EMV chip capable terminal, peripheral card reader (such as a PIN pad, where the
peripheral contains some or all of the Level 1 or Level 2 functionality), or an ATM unless noted otherwise.
Terminals can also be other terminal types as defined in EMV, including POS terminals, bank branch
terminals (BBTs), unattended terminals, and onboard devices (e.g., handheld terminals on airplanes).

96 Visa Confidential 31 August 2017

 ADVT Testing Use Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

E.1.1 General Terminal Use Cases

This section provides general terminal use cases.

Table E–1: General Terminal Use Cases

General Terminal Use Cases

Q1 Multiple Terminal Vendors

If I deploy terminals by multiple terminal vendors, do I need to test each terminal configuration by
vendor?

Yes. ADVT testing is required for each terminal configuration. Also, if there are any changes to the
payment application affecting chip processing or the EMV kernel by terminal configuration, then
retesting is required.

Q2 Same Stand-Alone Terminal Deployed at Multiple Merchant Locations

I am an acquirer planning to deploy stand-alone terminals at multiple merchant locations, all with the
same terminal type, payment application, EMV kernel, and payment transaction flow. Do I need to
repeat ADVT testing at each merchant location?

No. As long at the payment infrastructure remains the same across numerous merchants or merchant
locations, then ADVT testing is only required once.

Q3 Terminal Family
If I perform ADVT testing on a single terminal vendor product line, which has the same EMV kernel and
payment application as other terminal models, do I need to test each one?

No. If the payment application, EMV kernel, and chip transaction flow are the same in each individual
POS model then this would be considered a “terminal family” and can be tested once. Please consult
with the terminal vendor to ensure a group of terminals fall within the same family.

Q4 New Communication Types

My terminal supports different communication types (e.g., Bluetooth, General Packet Radio
Service (GPRS), internet, dial-up). Do I need to perform ADVT testing for each communication type?

No. Only one set of ADVT testing per terminal family is required as long as the communication type is
the only change. Consult with the terminal vendor for information on whether a group of terminals fall
within the same terminal family.

Q5 EMV Level 1 Hardware Changes

Do I need to perform ADVT retesting if there are changes to EMV Level 1 hardware on my device,
which does not impact the EMV chip processing in the payment application or the EMV kernel?

No. This constitutes a “minor change”. Refer to the “Not Required” section in Section 2.5.1: ADVT
Usage Guidelines.

31 August 2017 Visa Confidential 97

 ADVT Testing Use Cases
Use Cases

General Terminal Use Cases

Q6 EMV Level 1 or Level 2 Approval Expiration

What happens when the Level 1 or Level 2 approval on my terminal expires?

Visa does not require that deployed terminals with expired Level 1 or Level 2 approvals be replaced or
updated. However, updates to software in existing terminals should be reviewed against Section 2.5.1:
ADVT Usage Guidelines. Update of terminal software may require replacement or upgrading of expired
Level 1 or 2 components. Alternatively, the vendor of the EMV kernel or chip reader (Level 1) may be
able to renew the EMV Level 1 or Level 2 approval.

Q7 Off-the-Shelf Terminal with EMV Approvals

I purchased an off-the-shelf chip terminal with EMV approvals. Do I still need to perform ADVT testing?

Yes. ADVT testing will ensure overall system integration of the device. It will validate that the data from
the card is correctly transmitted to the acquirer host, data from the acquirer host is correctly returned
to the card, and the device meets Visa requirement.

Q8 Upgraded Peripheral—New EMV Kernel

Does upgrading to a new version of a peripheral (such as a PIN pad with a new EMV kernel) require
retesting?

Yes. If the peripheral contains EMV Level 2 (kernel) functionality, ADVT retesting is required.

Q9 Upgraded Peripheral—No EMV Kernel Changes

I am upgrading to a new version of a peripheral that does not involve changes to EMV chip processing
but does involve other changes, such as changing prompts displayed to the customer. Do I need to
retest with the new version of the peripheral?

No. If EMV chip functionality is not impacted, ADVT retesting is not required.

Q10 Upgraded Peripheral—New PIN Pad

Does upgrading to a new peripheral, such as a PIN pad require retesting?

ADVT retesting is required when changes affect EMV chip processing. If the peripheral contains the
chip reader (Level 1) or any part of the EMV kernel (Level 2), retesting is required. This would include a
peripheral that supports Offline PIN. However, if the peripheral does not include any EMV functionality,
such as a PIN pad that only supports Online PIN, retesting is not needed.

Q11 Payment Application Changes—Magnetic Stripe Only

I will be making changes to the payment application which will impact magnetic stripe functionality
only, do I need to retest?

No. However, it is recommended that you perform the Fallback related tests to ensure that chip and
magnetic stripe functionality is invoked when required.

Q12 Non-Payment Changes to Integrated POS

Do changes to an integrated POS that are not payment related require ADVT retesting (i.e., changes to
the physical or logical interface between the cash register and the payment terminal)?

No. ADVT retesting is not required in these cases.

98 Visa Confidential 31 August 2017

 ADVT Testing Use Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

General Terminal Use Cases

Q13 Portfolio Changes

Do I need to retest if the portfolio changes? For example, in the US market, my Independent Sales
Organization (ISO) may sell or buy a portfolio and change where the device is pointing or change my
merchant ID or terminal ID.
If routing of the transaction is effected with a different gateway or acquirer processor, then ADVT
testing must be performed.
If the changes are only related to the terminal management system, ADVT testing is not required.

Q14 Operating System Changes

If there are changes to my operating system (for example, Windows XP to Windows 7) do I need to
repeat ADVT testing?

If this is the only change and there are no changes to the payment application impacting EMV chip
processing or the EMV kernel, then ADVT retesting is not required. However, if a new EMV kernel is
required to support the new operating system, then ADVT retesting will be required.

Q15 ADVT Scheduling

When performing ADVT testing, does an acquirer need to schedule testing with Visa?

No. ADVT is considered self-service testing and does not require scheduling with Visa. You can
perform the testing at your convenience. However, new acquirers need to ensure chip parameters are
set up in Visa’s test environment.

Q16 ADVT Test Results Submission

Can I submit the test results without using the Chip Compliance Reporting Tool (CCRT)?

No. CCRT must be used to submit test results.

Q17 New Service (e.g., Dynamic Currency Conversion or Cash-Back)

If adding an additional service, such as dynamic currency conversion or cash-back, do I need to repeat
required testing?

Yes. Retesting ADVT will be required since there are impacts to the payment component of the
terminal application for chip processing and the EMV kernel.

Q18 Contactless Testing

Can the ADVT be used for testing contactless?

No. ADVT is not used to test contactless terminal functionality. Contact your Visa representative for
contactless testing requirements.

Q19 New Non-Payment Application

Do changes to a non-payment related application (e.g., a loyalty program) on the device require ADVT
retesting?

No. Changes to non-payment applications are outside the scope of ADVT testing.

31 August 2017 Visa Confidential 99

 ADVT Testing Use Cases
Use Cases

General Terminal Use Cases

Q20 Repaired/Replaced Terminals

When terminals break and are sent for repair and replacement, they are recycled back into stock, is
ADVT testing required?

No. As long as there were no software code changes impacting chip processing or the EMV kernel,
ADVT testing is not required.

E.1.2 Acquirer/Processor Platform Use Cases

This section provides use cases for acquirer/processor platforms.

Table E–2: Acquirer/Processor Platform Use Cases

Acquirer/Processor Platform Use Cases

Q1 Visa Business Enhancements

When changes are applied to my platform as a result of Visa’s bi-annual business release, do I need to
perform any ADVT re-testing?

No. In general, no ADVT retesting is required as a result of business release changes unless specified in
the Business Enhancement Technical and Implementation Guide.

Q2 Network Switch Upgrade

I am upgrading my network switch (i.e., the system which processes and routes data at the data link
layer) to support changes from my supplier. Do I need to repeat ADVT testing?

Retesting may be required, depending on the areas that are affected. Review Section 2.5.1: ADVT
Usage Guidelines and consult with your Visa representative.

Q3 New Platform
I am changing my payment platform to a different network switch vendor’s platform using a different
transaction message. Do I need to repeat ADVT testing?

Yes. This is a major change and ADVT testing must be repeated.

100 Visa Confidential 31 August 2017

 ADVT Testing Use Cases
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

E.1.3 System Integrator and Value-Added Reseller (VAR) Use Cases

This section provides use cases for System Integrators and Value-Added Resellers (VARs).
Table E–3: System Integrator and Value-Added Reseller (VAR) Use Cases

System Integrator and Value-Added Reseller (VARs) Use Cases

Q1 Inventory Management System Changes

In an integrated payment environment, if there are changes to an inventory management system
within the payment application, would this require the terminal to be retested? For example, a retail
and restaurant management systems’ integrated payment application would include the inventory
system. If a change is made to the inventory system, it will impact the payment application but not chip
processing.

Modularizing applications in these environments is recommended to protect the payment application

and, provided this approach has been followed, no retesting would be required. Changes that affect
the EMV kernel or chip processing, however, will necessitate ADVT retesting. Refer to Appendix D:
Merchant Terminal Environments for examples.

Q2 Application Programming Interface Changes

I am using a middleware application for EMV. If I update my Application Program Interface (API), do I
need to repeat ADVT testing?

No. Retesting is only required if the changes impact the payment application for chip processing or the
EMV kernel. However, retesting is recommended as middleware changes often impact payment
processing.

Q3 New Peripheral Device

I've added a new payment peripheral device (for example, a printer or barcode reader) to my
processing chain. Do I need to repeat ADVT testing?

No. ADVT retesting is not required as long as the peripheral is not involved in EMV processing.

Q4 Payment Application Change

The version of my payment application has changed but the device hardware version has not. Do I
need to repeat ADVT testing?

Yes. Whenever there is a change to the payment application impacting chip processing or the EMV
kernel, retesting is required.

31 August 2017 Visa Confidential 101

 Acronyms and Glossary
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

F Acronyms and Glossary

This appendix provides a list of acronyms used in this document and in EMV as well as a glossary of
terms.
Table F–1: Acronyms

Acronym Meaning

a alpha
AAC Application Authentication Cryptogram
AAR Application Authentication Referral
ADA Application Default Action
ADF Application Definition File
ADVT Acquirer Device Validation Toolkit
AEF Application Elementary File
AFL Application File Locator
AID Application Identifier
AIP Application Interchange Profile
an alphanumeric
ans alphanumeric special
APDU Application Protocol Data Unit
API Application Priority Identifier
ARPC Application Response Cryptogram
ARQC Application Request Cryptogram
ATC Application Transaction Counter
ATM Automated Teller Machine
AUC Application Usage Control
b binary
BIN Bank Identification Number
CA Certificate Authority
CAM Card Authentication Method
CAT Cardholder Activated Device
CDA Combined Dynamic Data Authentication

102 Visa Confidential 31 August 2017

 Acronyms and Glossary
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Acronym Meaning

CDOL Card Risk Management Data Object List

CID Cryptogram Information Data
cn compressed numeric
CSV Comma-Separated Values
CVK Card Verification Key
CVM Cardholder Verification Method
CVR Card Verification Result
CVV Card Verification Value
DDA Dynamic Data Authentication
DDF Directory Definition File
DDOL Dynamic Data Authentication Data Object List
DEA Data Encryption Algorithm
DES Data Encryption Standard
DGI Data Group Identifier (used by the Card Personalizer only)
DKI Derivation Key Index
EMV Europay, MasterCard & Visa
FCI File Control Information
GPO Get Processing Options
hex. Hexadecimal
IAC Issuer Action Code
ICVV Alternate Card Verification Value
IFM Interface Module
MCC Merchant Category Code
MDK Master Derivation Key
MPOS Mobile Point of Sale Device
N/A Not Applicable
n numeric
PAN Primary Account Number
PDOL Processing Options Data Object List
PIN Personal Identification Number

31 August 2017 Visa Confidential 103

 Acronyms and Glossary
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Acronym Meaning

PIX Proprietary Application Identifier Extension

PK Public Key
PKI Public Key Infrastructure
PKI Public Key Index
POS Point of Sale
PSE Payment Systems Environment
PSTN Public Switched Telephone Network
PVK PIN Verification Key
PVV PIN Verification Value
RFU Reserved For Future Use
RID Registered Application Provider Identifier
RSA Rivest, Shamir, Adleman
RRN Retrieval Reference Number
SAD Signed Static Application Data
SAM Secure Access Module
SDA Static Data Authentication
STIP Stand-In Processing
TAC Terminal Action Code
TC Transaction Certificate
TDOL Transaction Certificate Data Object List
TITF Terminal Integration Task Force
TLV Tag-Length-Value
TSI Transaction Status Information
TVR Terminal Verification Result
UAT Unattended Acceptance Device
UCAT Unattended Cardholder Acceptance Device
UDK Unique Derived Key
var. variable
VCMS Visa Certification Management Service
VIP VisaNet Integrated Payment

104 Visa Confidential 31 August 2017

 Acronyms and Glossary
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Acronym Meaning

VLP Visa Low-value Payment

VMTS Visa Member Test System
VSDC Visa Smart Debit/Credit
VTS VisaNet Test System
XML Extensible Mark-up Language
XSD XML Schema Definition

Table F–2: Glossary

Term Definition
Application Protocol The communication format used between the chip card and the payment
Data Unit (APDU application on a card acceptance device. This format is defined in ISO specification
7816.
Automated Teller An unattended device that has electronic capability to send transactions online for
Machine (ATM) authorization, accepts PINs, and disburses currency.
Card Acceptor See “Terminal.”
Terminal
Card/Terminal Log A capture of the interaction between the card/card simulator and the device.
Typically provided in Application Protocol Data Unit (APDU) format.
Card/Terminal Log A Test Plan-defined description of the requirements for elements and content of
Validation the card/terminal log to be validated during terminal integration testing.
Cardholder Activated An unattended device, such as an automated dispensing machine, self-service
Device device, or limited amount device that is not an ATM.
Certification Validation that the format, function, and content of authorization messages
executed from a defined test plan adheres to a provided specification and set of
business rules.
Chip-Capable A transaction acceptance device that is designed and constructed to facilitate the
addition of a chip reader/writer.
Chip-Enabled For chip cards, this describes the state in which the card has already been
personalized with both cardholder and Brand-specific data in preparation for use.

For terminals, this describes the state in which the terminal has already been
equipped with a chip reader/writer and has been configured with Brand-specific
data and is ready for use in accepting chip cards.

31 August 2017 Visa Confidential 105

 Acronyms and Glossary
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Term Definition
Comma-Separated A format that stores tabular data (numbers and text) in plain-text form (i.e. a
Values (CSV) sequence of characters, with no data that has to be interpreted instead, as binary
numbers). A CSV file consists of any number of records, separated by line breaks of
some kind; each record consists of fields, separated by some other character or
string, most commonly a literal comma or tab. Usually, all records have an identical
sequence of fields.
Contact Transaction An interaction between a chip application and a device using the physical electrical
interface, as defined in [EMV Book 1].
Contactless An interaction between a chip application and a device using the radio frequency
Transaction wireless interface, as defined in [EMV CL].
Customer Activated See “Cardholder Activated Device.”
Terminal (CAT)
Deferred Where an online authorization is performed after the card is no longer available,
Authorization typically because the device temporarily does not have a connection (i.e.,
communications failure or device is on a transit vehicle) or the amount is over the
floor-limit and the device has no online capability.
EMVCo LLC (EMVCo) Industry organization that manages, maintains, and enhances the EMV
Specifications. Current Members are American Express, JCB International,
MasterCard Worldwide, UnionPay, and Visa Inc.
EMV Specifications Technical specifications developed and maintained by EMVCo to create standards
and ensure global interoperability for use of chip technology in the payment
industry. In order to support EMV, cards and terminals must also meet the
requirements described in the bulletins available on the EMVCo website.
Host Authorization A description of the transaction message initiated from the device and sent online
Message via the acquirer and network to the issuer, processor, or Brand for transaction
authorization.
Host Authorization A Test Plan-defined description of the requirements for elements and content of
Message Validation the Host Authorization Message to be validated during standalone or terminal
integration testing.
Implement To make a card, application, or device capable of performing a functionality.
Functionality that is implemented may also need to be enabled (see Chip-enabled).
Interoperability The ability of all card acceptance devices to accept and read all chip cards that are
properly coded and personalized.
Kernel EMV definition for the set of functions required to be present on every terminal
implementing a specific interpreter. The kernel contains device drivers, interface
routines, security and control functions, and the software for translating from the
virtual machine language to the language used by the real machine. In other words,
the kernel is the implementation of the virtual machine on the real machine.

106 Visa Confidential 31 August 2017

 Acronyms and Glossary
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Term Definition
Limited Amount An unattended device that has data capture-only capability, and accepts payment
Device for items such as parking garage fees, road tolls, etc.
Mobile Point of Sale A smartphone, tablet, or dedicated wireless device that performs the functions of a
(MPOS) cash register or electronic point of sale terminal (POS terminal).
Offline-Capable A transaction acceptance device that has the ability to process the transaction
offline for card authentication and authorizations.
Online-Capable A transaction acceptance device that is able to send transactions to the issuer or
processor for authorizations.
Online-Only A transaction acceptance device that requires that all transactions be sent online
for authorization.
PAN Key Entry A manual procedure in which the merchant uses a device key pad to enter the PAN
embossed on a card in order to process a transaction.
Pass Criteria A Test Plan-defined field that describes an expected result for a successful outcome
or conclusion of a test case.
Pass Criteria File The file (in CSV format) that embeds the Brand-defined pass criteria for each test
case.
Personalization For chip cards, the process of applying both cardholder and Brand-specific data to
the card in preparation for its use.
Point of Sale The physical location where a merchant or acquirer in a face-to-face environment
or an unattended device completes a transaction.
Point-of-Sale Device A device used at the POS to process transactions, including chip devices,
automated dispensing machines, self-service devices, and ATMs.
Terminal The device used in conjunction with the chip card at the point of transaction to
perform a financial transaction. The terminal incorporates the interface device and
may also include other components and interfaces such as host communications.
Terminal A description of the features and parameters on the acceptance device under test.
Configuration For example, it might include the EMV-defined terminal types, supported interfaces,
etc.
Terminal Integration A process implemented and managed by the respective Brands, aimed at providing
Testing a level of assurance that Brand-specific requirements and recommendations are
being implemented in contact or contactless chip acceptance devices that will
accept a Brand’s products.
Terminal Integration Task Force established by EMVCo in 2013 with the purpose of examining each of
Task Force (TITF) the Brand’s terminal integration processes, in order to determine the possibilities of
aligning key elements of these processes.
Test Card Image An electronic representation of a physical card.

31 August 2017 Visa Confidential 107

 Acronyms and Glossary
VSDC Acquirer Device Validation Toolkit User Guide (Version 7.0)

Term Definition
Test Case A Test Plan-defined description of a test scenario, defined by a Payment Brand for
execution of terminal integration or host message testing.
Test Case Name A Test Plan-defined description of the name associated with a specific test case.
Test Case Number A Test Plan-defined unique test case identifier.
Test Case Objective A Test Plan-defined description of the objective of performing a given test case.
Test Plan A Brand-developed and managed set of test criteria that defines the requirement
for terminal integration or host message testing. This may either take the form of a
textual document or a machine-readable file.
Test Procedure A Test Plan-defined description of the steps required in order to execute a specific
test case.
Test Tool The process undertaken by each Brand to provide themselves, tool vendors, and
Confirmation clients will a level of assurance that the tools being used by clients to execute
terminal integration testing will do so in compliance with Brand requirements.
Process is also referred to as “Test Tool Qualification.”
Test Tool The process undertaken by each Brand to provide themselves, tool vendors, and
Qualification clients will a level of assurance that the tools being used by clients to execute
terminal integration testing will do so in compliance with Brand requirements.
Process is also referred to as “Test Tool Confirmation.”
Transaction An EMV definition for the successful closing of transaction processing. The
Completion completion function is always the last function in transaction processing and must
occur unless the transaction is terminated prematurely by error processing.
Unattended A cardholder-operated device that reads, captures, and transmits card information
Cardholder Activated in an unattended environment.
Terminal (UCAT) Also known as “Customer Activated Terminal (CAT)” or “Unattended Acceptance
Device (UAT).”
User Validation A Test Plan-defined description of the requirements for the user/tester to validate
responses from the device under test.
Extensible Mark-up A mark-up language that defines a set of rules for encoding documents in a format
Language (XML) that is both human-readable and machine-readable.

108 Visa Confidential 31 August 2017