Acquirer Device Validation Toolkit (ADVT)

Frequently Asked Questions (FAQs)

Version: 2.0 January 2007

This document provides users of Visa’s Acquirer Device Validation Toolkit (ADVT) with
answers to some of the most frequently asked questions that arise while using the toolkit.
It also provides a useful reference to some of the general policy and operational
questions that relate to the ADVT.

1.0 Policy Questions

1.1 What is the relationship between the “Acquirer Device Validation Toolkit (ADVT)”, Asia
Pacific’s “Visa Smart Debit/Smart Credit – User Acceptance Test for Visa Chip
Programmes”, and Visa Europe’s “End-to-End Test Pack”?
The two regional test tools mentioned were the forerunners to the ADVT. These toolkits were
supported and distributed only within those two regions. Both these tools are no longer
supported by Visa and should not be used in testing programs. ADVT is Visa’s global test
product and is available in all regions.
1.2 Can the ADVT be used to test other transaction types besides Purchase and Cash, such
as Reversals and Refunds?

Reversal transactions can be executed and sent online to the Visa Certification Management
Service (VCMS). However, an Authorization Response of “21” (no action taken) will be
returned by VCMS, since there is no corresponding transaction in VCMS to be reversed (only
an approved transaction can be reversed).

Refunds however should not be performed as an online transaction (there is no such

transaction type as an online Refund). In the past Acquirers have performed Refunds as
online purchase transactions but Visa strongly recommends against this.

Please note: the following transaction types cannot be tested within VCMS:
• Referrals
• Balance Enquiries
• PIN Change/PIN Unblock transaction
• Any other transaction involving an Issuer Script

It may be possible to test some of these transaction types using one of the host simulators
confirmed by Visa, but this is outside the scope of ADVT testing.
1.3 Can the ADVT cards be used to perform Cash-back transactions?
No. None of the ADVT cards are currently personalized with the appropriate options
(Application Usage Control) to allow Cash-back.

Visa Public 1
Copyright © 2007 Visa International Service Association. All rights reserved.
This document is solely intended to be used with Visa products and services.
1.4 Can the ADVT cards be used to test Clearing (Base II) transactions into the VisaNet
Certification Management Service (VCMS)?
In theory, yes. However, Visa does not currently provide this service as part of the ADVT
process. Clearing tests involving VCMS are performed during the Acquirer Host
Certification process and require a manual audit of the clearing data.
1.5 Can the ADVT be used with VTS/3 configured as the Issuer host?
This configuration is technically possible, and some Acquiring Members have used it in
the past. Although Visa has no objections to this set-up, users should be aware that it is
outside of the scope of the current ADVT process and therefore not supported.
1.6 All the EMV technical references within the ADVT document refer to EMV 4.1. The
system being tested uses an EMV kernel that is only certified for EMV 3.1.1. Is this a
problem?
No. All ADVT tests apply equally to chip card acceptance devices based on EMV 3.1.1,
EMV 4.0 or EMV 4.1. As most of the tests in the ADVT relate to Visa-specific
requirements that are supplemental to EMV requirements, the exact version of EMV
supported on the device is of less significance.
1.7 Some of the tests are indicated as not being appropriate for the type of device being
tested, should these tests still be performed?
It is preferable that these tests be performed even if you do not provide us with test
results. Although the detailed test results (TVR etc.) may be of limited value, it is always
useful to confirm acceptance of all ADVT cards by the device.
1.8 We are purchasing an off-the-shelf Chip and PIN device with fully approved EMV level
2 software. Are the ADVT tests still relevant to us?
Yes. One of the key objectives of the ADVT tests is to ensure overall system integration,
not just the validation of the technical characteristics of the device. Even though an EMV
Level 1 & Level 2 approved device may correctly interact with a card, all the following
criteria still need to be met:
a. Data from the card must be correctly transmitted to an Acquirer host
b. Data received from the Acquirer Host must be correctly returned to the card
c. In addition to EMV, the acceptance device must meet specific Visa requirements

1.9 Will we receive a Letter of Approval from Visa once we have completed our ADVT
process and submitted our results to Visa?
No. Visa will record the ADVT test results submitted but will not be issuing a Letter Of
Approval to ADVT Users.
1.10 We wish to make changes to the payment part of our terminal application, but it will
only affect mag stripe and not chip functionality. Do we have to retest?
No. However, we recommend that you perform the fallback-related tests to ensure that
the chip and mag stripe functionality remain correctly integrated with each other.
1.11 We only acquire ATM transactions. What are the precise implications of this for
ADVT testing?
You still need to perform ADVT testing and you must still perform all the tests, except for
Visa Public 2
Copyright © 2007 Visa International Service Association. All rights reserved.
This document is solely intended to be used with Visa products and services.
those which are marked as not being appropriate for ATMs. These are Test Cases: 24,
27, 28, 30, 31, 32, 33, 40, 45, 48 and 49.
1.12 Can we test manual cash transactions with the ADVT?
Yes, you can. Where a terminal supports both purchase and manual cash we will expect
to see two sets of test results for this device.
1.13 Our ATMs sell mobile phone top-up vouchers as well as dispensing cash. Do we
need to test them twice?
Yes, you do. From Visa’s point of view an ATM which also performs sale transactions is
really two terminals in one – an ATM and an unattended POS terminal. Therefore, we
expect to see two sets of test results – one for cash transactions and one for sale
transactions.
1.14 Can we waive testing with the ADVT?
Yes, you can. An acquirer or their agent (including processors or national/regional/global
acquiring networks) can request waiving of the ADVT testing requirement if they can
attest that the deployed application has already been tested on the same acquiring
network. The deployed application would be recognized by concatenation of all
identifiers:

• Kernel id - as submitted to EMV and listed on the EMVCo website

• Acquiring network - as identified by the acquiring network or regional or global
body
• Application identifier - as identified by the application developer or system
integrator

If the device deployer wishes to see the ADVT test results recognized in multiple regions,
they will need to request this. 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 can then be forwarded to Visa Inc headquarters for retention and access by other
regional personnel.

Visa Public 3
Copyright © 2007 Visa International Service Association. All rights reserved.
This document is solely intended to be used with Visa products and services.
2.0 Operational Questions
2.1 Our online transactions are being declined by VCMS with an Authorization Response
Code of “05” (“do not honour”). What does this mean?
These declines may be caused by a failure of Offline Data Authentication (SDA or DDA), as
reflected in the Terminal Verification Result (TVR). The valid reasons for a decline by VCMS
are outlined in Section 8 of the ADVT manual (“VSDC Stand-In Processing Conditions”). If the
transaction is not being declined for one of those reasons, the most likely cause of a “05”
response is that the validation of the Application Request Cryptogram (ARQC) has failed. This
can be confirmed by checking the value of Field 44.8 in the authorization response message.
A value of ‘1’ indicates a failure.
Some of the reasons why ARQC validation may fail are as follows:
• One or more of the data elements used to calculate the ARQC does not match it’s
corresponding value in the 3rd Bit Map field
• One or more of the values used by VCMS to derive the Unique Derivation Key (UDK)
for the cryptogram validation may be missing or incorrect.
You may need to work with your Visa Regional Representative to try to determine the cause
of the failure.
2.2 Almost all the transactions conducted with the ADVT have the TVR bit set for “transaction
exceeds floor limit”, even though we perform transactions with small amounts which are under
our floor limit. Why is this?
It is possible that your card acceptance device may be set up to prevent the use of “split
sales” (use of the same card to perform more than one transaction in quick succession), a
means of avoiding floor limit checks. In this situation the device will aggregate the transaction
amounts in the split sale to determine if the floor limit has been exceeded, rather than using
just the current amount.
2.3 Our online transactions are being authorized by VCMS but appear to fail Issuer
Authentication. What is the likely cause?
There are a couple of likely causes for this failure:
1. The Acquirer fails to correctly convert the Issuer Authentication Data to the
appropriate format when it is returned from VisaNet (VCMS in this case). The format
used for Issuer Authentication Data (Field 139) is as follows:
• 16 Hex digits + 2 bytes EBCDIC
The 16 Hex digits correspond to the 8-byte ARPC cryptogram. The 2 bytes of EBCDIC
correspond to the Authorization Response Code that is sent to the card. The ARC has to be
in ASCII format to be recognized by the card. So, for example, if the two bytes are F0F0,
they should be converted to 3030.

2. Another possibility is that the Acquirer host may not be passing on the Issuer
Authentication Data, which may not be easy to detect from the response message.
For example, in the UK, the Issuer Authentication Data field being filled with Hex ‘Fs’
in the APACS response messages indicates the absence of valid data. If this “data” is
passed to the card it will result in Issuer Authentication failure.

Visa Public 4
Copyright © 2007 Visa International Service Association. All rights reserved.
This document is solely intended to be used with Visa products and services.
2.4 Whenever we use Online PIN as the CVM, the transaction is declined by VCMS with the
Response Code “81” (“PIN cryptographic error”). What is the likely reason for this?
The most likely reason is that the Acquirer host is using the wrong Acquirer Working Key
(AWK) to encrypt the PIN block when it is sent to VCMS. It is possible that the AWK may
have been changed since Acquirer Host Certification was performed. Please contact the Host
Certification Team in your Visa Regional office for further assistance.
2.5 In the course of testing, the PIN on one of the cards has been inadvertently blocked. Does
Visa provide a service for unblocking the PIN?
In general, Visa does not provide a service for unblocking the PIN. Unblocking of the PIN
requires the use of an Issuer Script command with the appropriate MAC value. The values of
cryptographic keys used for the MAC are documented in the ADVT User Guide (5.1 Baseline
Card). There are various test tools available in the marketplace that can perform this function.
Please contact your Visa Regional Representative for more information.
2.6 For some test cases (e.g. Test Case 23- Valid for domestic-only transactions), we know
right from the beginning of the transaction that it will result in a decline. Can we just cancel the
transaction?
This terminal behavior would be out of compliance with EMV. An option for the terminal
would be to skip some of the transaction processing steps before requesting the Application
Authentication Cryptogram (AAC). EMV 4.1, Book 3, 10.7 states that “The terminal action
analysis function may be executed at several places during a transaction to eliminate the
need for unnecessary processing”.

Visa Public 5
Copyright © 2007 Visa International Service Association. All rights reserved.
This document is solely intended to be used with Visa products and services.
3.0 Technical Clarifications Questions
3.1 In the test cases there are numerous references to how the system should behave in the
event of “no connectivity to VCMS” and “online is not available”. What do these terms mean in
the context of a complex Electronic Point Of Sale (EPOS) system where the EMV functionality
resides on multiple pieces of hardware?
In general, “Online is not available” means a failure to connect to the Acquirer host and
ultimately to VisaNet (VCMS). The failure of a connection between, for example, an Electronic
Cash Register (ECR) and an in-store server constitutes a system failure and is outside the
scope of the ADVT testing requirements.
3.2 Our device sometimes displays additional messages explaining to cardholders why a
transaction has been declined. An example is “this card cannot be used to withdraw cash”. Is
this acceptable?
If the device is able to determine the specific reason for the transaction decline then
displaying the appropriate message is acceptable. Generally, such messages apply to offline-
declined results. For online declines, it is often difficult for the terminal to determine exactly
why the transaction was declined, except in the case where an incorrect online PIN was
entered (Auth Response Code “55”).
3.3 For a fallback to magnetic stripe condition, our device fails to display any “Card Error”
messages, it just says “Use Mag Stripe”. Is this acceptable?
The “Standard Messages” defined in EMV 4.1 – Book 4: Section 11.2 includes the “Card
Error” message. This indicates to the cardholder or attendant that a malfunction of the card
has taken place or the answer-to-reset (ATR) from the card was unacceptable. Note that
these messages (or their local language equivalents) are not specifically mandated. So, the
implementation described in this case is acceptable. Visa’s recommendation however would
be to display the message: “Chip Error, Use Mag Stripe” (Chip Card Acceptance Device
Reference Guide - Requirements and Best Practices, Version 7.0).
3.4 The Application Version Number (AVN) on most of your test cards is x8C. Which Terminal
AVN should our device be configured with?
For EMV 4.0 or EMV 4.1 approved devices, the correct AVN is x8C (decimal value = 140).
This also indicates that the device is compliant with VIS 1.4.0. For EMV 3.1.1-approved
devices, the correct AVN is x84 (decimal value = 132, corresponding to VIS 1.3.2). It should
be noted that the precise value of the AVN on the terminal is not critical for the tests, as it
does not affect card acceptance or the outcome of any ADVT tests.
3.5 Why does setting the “merchant forced online” bit in the TVR result in a decline?
There is no clear definition of what this bit means, in EMV or anywhere else. However, it is
generally assumed that it means “merchant is suspicious so it is safest to decline”. Therefore,
just like many real issuers, VCMS STIP will decline transactions where this bit is set. If you
want to ensure that a transaction goes online at an offline-capable terminal without
prejudicing the outcome of the transaction you can set the TVR bit for “floor limit exceeded” or
“transaction randomly selected for online processing”.
3.6 We originally purchased a version 2 ADVT test pack which has subsequently been
upgraded. This means that many of our cards are the original version 2 cards with an
Application Version Number of x84. Will this cause problems?
No. The AVN has no effect on card behaviour and the Visa-mandated Terminal Action Codes
(TACs) make no reference to the TVR bit “ICC and terminal have different application
Visa Public 6
Copyright © 2007 Visa International Service Association. All rights reserved.
This document is solely intended to be used with Visa products and services.
versions”.

Visa Public 7
Copyright © 2007 Visa International Service Association. All rights reserved.
This document is solely intended to be used with Visa products and services.
4.0 Specific Test Case/Test Card Questions
(NB – these are in order of Test Case number)
4.1 Card 17 does not require an unpredictable number from the device (CDOL1 only contains
the tag for TVR). Do we still need to send an unpredictable number online to VCMS?
Yes, the Unpredictable Number should still be sent to VisaNet (VCMS) in F132, even though it
was not used in the cryptogram (ARQC) calculation by the card.
4.2 I don’t understand the significance of all the additional personalization data defined for Card
18. How will our terminals see this card?
The purpose of this card is to test the Visa Low-Value Payment (VLP) feature. This is an
optional feature of the Visa Integrated Circuit Card Specifications (VIS), which an Issuer can
choose to enable for a VSDC card. A detailed definition can be found in the VIS 1.4.0 Card
Spec., Appendix G.
The purpose of this feature is to enable low-value transactions to be dealt with in an offline
environment.

To support this feature, a terminal is required to perform a small amount of additional

functionality. Specifically, the terminal must support a “VLP Terminal Support Indicator” which is
requested by the card in its PDOL data. If this data element is not present or is not set to ‘1’, the
card will perform a normal VSDC transaction – i.e. the data identified in the first part of Section
5.19 in the ADVT manual will be used. Only terminals that support VLP will receive the data
defined under the heading “The following data elements need to be added to support VLP:”

4.3 All our transactions seem to be successfully authorized by VCMS when they go online,
except for Card 25. What does this mean?
Card 25 is the only card that requires Issuer Authentication to be performed in order for the
transaction to be authorized – the other cards do support Issuer Authentication but the
transactions can be authorized without it being performed. A common error made by some
Acquirers is to set the POS Entry Mode to “9010” for chip read transactions. This will cause chip
data to be ignored and Card # 25 will fail.
POS Entry Mode (F22) should be set to “0510” for chip read transactions.
4.4 When the Card 21 (19-digit PAN) transaction is sent online it is declined with a Response
Code of “27”. What does this mean?
Track 2 Data with an odd number of digits should be sent to VisaNet (VCMS or a confirmed
host simulator in this case) with a leading zero as padding. If this leading zero is not present
you will receive this Response Code.
4.5 With Cards 32 and 33 (where the PIN Try Limit is exceeded) our terminal displays a “PIN
blocked” message to help the cardholder and merchant understand what is happening. Is this
acceptable?
This is specifically prohibited by EMV. EMV 4.1, Book 4, 6.3.4.1 states that "If the value of the
PIN Try Counter is zero, indicating no remaining PIN tries, the terminal should not allow offline
PIN entry. The terminal:
• Shall set the ‘PIN Try Limit exceeded’ bit in the TVR to 1
• Shall not display any specific message regarding PINs,
• Shall not set the CVM Results, and
• Shall continue cardholder verification processing in accordance with the card’s CVM List."

Visa Public 8
Copyright © 2007 Visa International Service Association. All rights reserved.
This document is solely intended to be used with Visa products and services.
 Visa Public 9
Copyright © 2007 Visa International Service Association. All rights reserved.
This document is solely intended to be used with Visa products and services.