Acquirer Device Validation Toolkit (ADVT)

Frequently Asked Questions (FAQs)

Version: 2.0 January 2007

This document provides users of Visas 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 Pacifics Visa Smart Debit/Smart Credit User Acceptance Test for Visa Chip Programmes, and Visa Europes 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 Visas 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 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 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 Visas 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 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 its 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 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 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 offlinedeclined 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. Visas 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 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 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 dont 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 cards CVM List."
Visa Public Copyright 2007 Visa International Service Association. All rights reserved. This document is solely intended to be used with Visa products and services.

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