Visa Secure Program Guide

Visa Secure Program Guide
Visa Supplemental Requirements

Version 1.4
3 September 2020
Visa Confidential
Important Information on Confidentiality and Copyright
© 2015-2020. All Rights Reserved.
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.
This document is a supplement of the Visa Core Rules and Visa Product and Service Rules. In the
event of any conflict between any content in this document, any document referenced herein,
any exhibit to this document, or any communications concerning this document, and any
content in the Visa Core Rules and Visa Product and Service Rules, the Visa Core Rules and Visa
Product and Service Rules shall govern and control.
THIS GUIDE IS PROVIDED ON AN "AS IS,” “WHERE IS,” BASIS, “WITH ALL FAULTS” KNOWN AND
UNKNOWN. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, VISA EXPLICITLY
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, REGARDING THE LICENSED WORK AND TITLES,
INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,
AND NON-INFRINGEMENT.
THIS PUBLICATION COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL

ERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN: THESE
CHANGES WILL BE INCORPORATED IN NEW EDITIONS OF THE PUBLICATION. VISA MAY MAKE
IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED
IN THIS PUBLICATION AT ANY TIME.
If you have technical questions or questions regarding a Visa service or capability, contact your Visa
representative.
Contents
Contents
Contents.................................................................................................................................................. i
Tables.................................................................................................................................................... iii
Figures.................................................................................................................................................. iv
Introduction........................................................................................................................................... 1
References................................................................................................................................ 2
Other Resources....................................................................................................................... 3
Contact Information.................................................................................................................. 4
1 Visa Secure Program..................................................................................................................... 6
1.1 Introduction....................................................................................................................... 6
1.2 How Visa Secure Works.................................................................................................... 9
1.3 Visa Authentication Data................................................................................................ 12
1.4 Authorization Overview................................................................................................... 20
2 Visa Secure Program Rules.........................................................................................................23
2.1 Visa Secure Program Participation Rules......................................................................23
2.2 Issuer Rules and Requirements......................................................................................24
2.3 Acquirer Rules and Requirements..................................................................................24
2.4 Card Type Restrictions (Non-Reloadable Visa Prepaid Cards)......................................25
2.5 Dispute Protection and Exceptions................................................................................25
2.6 CAVV Mandate................................................................................................................. 27
2.7 Global Attempts Processing........................................................................................... 27
2.8 Use of Authentication Data in Authorization..................................................................28
2.9 ECI 06 Quality of Service Program..................................................................................30
2.10......................................................................................... Authorization Processing 30
2.11.................................................................Authentication Approval Rates (U.S. Only) 31
2.12........................................................................................... EMV 3DS Requirements 31
2.13......................................................................................................... Country Rules 34
2.14................................................................................... User Interface Requirements 34
2.15......................................................................Authentication and Authorization Data 35
10-Sep-2020 Visa Confidential i

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
© 2018-2020 Visa. All Rights Reserved.
Contents
A Visa Secure with EMV 3DS Minimum Data Requirements........................................................36
A.1 Transactional and Checkout Page Information..............................................................36
A.2 3DS Requestor Authentication Information....................................................................40
A.3 3DS Requestor Prior Transaction Authentication Information......................................40
A.4 Merchant Risk Indicator..................................................................................................41
A.5 Cardholder Account Information.....................................................................................41
A.6 Device Information (Required for Mobile App)...............................................................42
A.7 3DS Method.............................................................................................................. 42
B Visa Country Rules and Visa Programs.....................................................................................43
B.1 Visa Country Rules and Local Regulatory Rules............................................................43
B.2 ECI 6 Quality of Service Program....................................................................................53
B.3 Visa Secure Global Performance Enhancement Program..............................................55
C CAVV Verification Results Code (Field 44.13)............................................................................59
C.1 CAVV Results Codes Summary.......................................................................................59
C.2 CAVV Results Code Values Descriptions.......................................................................61
D Acronyms and Glossary.............................................................................................................. 69
D.1 Acronyms......................................................................................................................... 69
D.2 Glossary........................................................................................................................... 71
ii Visa Confidential 10-Sep-2020

Tables
Tables
Table 1: EMV 3DS Protocol Version Numbers.......................................................................................1

Table 1–1: Participants in a Visa Secure transaction.....................................................................................8
Table 1–2: Electronic Commerce Indicator (ECI) Values..............................................................................13
Table 1–3: 3DS 1.0.2 Transaction Flow Messages and Transaction Status................................................14
Table 1–4: EMV 3DS Transaction Flow Messages and Transaction Status.................................................16
Table 1–5: EMV 3DS Transaction Status Reason Code......................................................................18
Table 2–1: Merchant Dispute Protection Exceptions....................................................................................26
Table 2–2: Authorization & Authentication Fields..............................................................................35
Table A–3: Transactional and Checkout Page Information..........................................................................36
Table A–4: 3DS Requestor Authentication Information......................................................................40
Table A–5: 3DS Requestor Prior Transaction Authentication Information...................................................40
Table A–6: Merchant Risk Indicator....................................................................................................41
Table A–7: Cardholder Account Information.......................................................................................41
Table B–1: Visa Country/ Region /Territory Rules and Local Regulatory Rules.................................43
Table B–2: Issuer Non-Compliance Assessments for Excessive Decline Rates (ECI 6)..............................54
Table B–3: Global “N or R” Policy Requirements................................................................................56
Table B–4: Global “U” Policy Requirements........................................................................................57
Table C–1: CAVV Results Code (Field 44.13) and Who Created CAVV...............................................59
Table C–2: Field 44.13: CAVV Verification Results Code Values Descriptions............................................61
10-Sep-2020 Visa Confidential ii

i
Figures
Figure 1-1: Domains and Components................................................................................. 9

Figure 1-2: Authorization Flow................................................................................................... 20
Summary of Changes
Summary of Changes
Version 1.4 updates
Change Description Section(s)
Rule Change Update rules to include Non-Payment transactions Section 2.12.5 – Non-
Payment Transactions
Appendix A - Visa Secure
with EMV 3DS Minimum
Data Requirements
10-Sep-2020 Visa Confidential v

Visa Secure Program
Introduction
The Visa Secure Program Guide contains information about:
 Visa Secure
 Program Rules
This document is a supplement of the Visa Core Rules and Visa Product and Service Rules. In the
event of any conflict between any content in this document, any document referenced herein,
any exhibit to this document, or any communications concerning this document, and any
content in the Visa Core Rules and Visa Product and Service Rules, the Visa Core Rules and Visa
Product and Service Rules shall govern and control.
Audience
This Guide is a global guide intended for Issuers who are:

 Evaluating Visa Secure Program OR
 Planning a Visa Secure Program implementation
Scope
This document is for Visa Secure and its use to support authentication of payment transactions.
There are two versions of 3-D Secure (3DS): 1.0.2 and EMV 3DS.
3DS 1.0 (Version 1.0.2)—This specification was first designed by Visa in 1999 to support
cardholder authentication for browser-based e-commerce transactions. Visa began licensing the 3DS
specification to the payment industry in 2002 and 3DS 1.0.2 has become the de facto standard for
e-commerce authentication globally. Visa maintains sole ownership and management of
3DS 1.0.2.
EMV 3DS—EMVCo began work in 2015 to advance 3DS through its open specifications creation
process. The focus of EMV 3DS is to enhance the protocol in the areas of authentication,
user experience, technology, performance, security, and flexibility to promote the longevity of the
protocol for the benefit of Visa Secure as well as the other payment systems. EMVCo is the
owner of EMV 3DS.
Table 1: EMV 3DS Protocol Version Numbers
Protocol Version
Status
Numbers
2.0.0 Deprecated
2.1.0 Active
10-Sep-2020 Visa Confidential 1

Introduction
2.2.0 Active
2 Visa Confidential 10-Sep-2020

Visa Supports all active protocol version of the EMV 3DS specifications.
References
The following references are available to support a Visa Secure implementation.
Visa
Visa references can be accessed through Visa Online, unless otherwise noted.
 Brand Standards—Visa’s Master Brand, artwork, reproduction, and application guidelines
can be accessed through Visa Online or at www.productbrandstandards.com
 CAVV Technical Details— Visa Secure Cardholder Authentication Verification Value
(CAVV) Guide.
 Digital Certificates—Contact your Visa regional representative for details. Forms
and procedures vary by region.
 Dispute Resolution—Visa Secure Dispute Resolution Guide
 Implementation Guides
- Visa Secure - Issuer Implementation Guide for EMV 3-D Secure
- Visa Secure - Merchant/Acquirer Implementation Guide for EMV 3-D Secure
- Visa Secure - Issuer Implementation Guide for 3-D Secure 1.0.2
- Visa Secure - Merchant/Acquirer Implementation Guide for 3-D Secure 1.0.2
 Rules—Visa Core Rules and Visa Product and Service Rules (referred to as the “Visa Rules”)
 PSD2 SCA for Remote Electronic Transaction Implementation Guide—Set of Visa
guidance documents that are relevant to the implementation of Strong Customer
Authentication under PSD2
 Implementing Strong Consumer Authentication (SCA) for Travel & Hospitality—Guide
to explain how to implement SCA solutions in the travel and hospitality sector
EMVCo
EMV 3DS specifications can be found on EMVCo’s website and include the following:
 3DS Specification—EMV®3-D Secure Protocol and Core Functions Specification, Version
2.1.0, 2.2.0
 3DS SDK Reference—EMV® 3-D Secure SDK Specification, Version 2.1.0, 2.2.0
 3DS SDK Reference—EMV® 3-D Secure SDK—Device Information, Version 2.1.0, 2.2.0
 3DS SDK Reference—EMV® 3-D Secure SDK—Technical Guide, Version 2.1.0, 2.2.0
3-D Secure 1.0.2
 Specification
- 3-D Secure Protocol Specification—Core Functions
 Technical Requirements
- 3-D Secure Functional Requirements—Access Control Server
- 3-D Secure Functional Requirements—Merchant Plug-in
- 3-D Secure Functional Requirements—Directory Server
- 3-D Secure Security Requirements—Enrollment Servers and Access Control Servers
- 3-D Secure Service Specification—Authentication History Server
Industry Standards
 Data Security
- Payment Card Industry Data Security Standards (PCI DSS)—PCI DSS security
requirements applicable to third party ACS, DS, and 3DS Server service
providers (https://www.pcisecuritystandards.org/security_standards/documents.php).
Filter by PCI DSS
- Payment Card Industry (PCI) 3DS Security Requirements and Assessment Procedures for EMV®
— PCI 3DS security requirements applicable to third party ACS service providers
(https://www.pcisecuritystandards.org/security_standards/documents.php). Filter by 3DS
Other Resources
Other implementation resources include:
Visa Online (VOL)
Visa Online (VOL) is a business-to-business extranet that provides secure access to important
Visa
content and services for our clients around the world. Visa Online is available to enrolled clients,
approved third-party partners, Visa employees, contractors, agencies, and vendors.
 Information about Visa Secure can be found by selecting “Visa Secure” under “Risk” in
the top navigation bar from the VOL home page.
 A VOL user ID and password is required to access VOL. Please contact your Visa
representative to request access.
Summary of Changes
Version 1.4 updates
Change Description Section(s)
Non- Addition of new non-payment rules Throughout the

Payment entire guide
Rules
Contact Information
The following contacts are available to answer any additional questions regarding:
 Visa Secure Program
Visa regional support teams are available to answer your questions about Visa Secure. Contact
the team for your region using the email address below:
- North America: [email protected]
- Latin America, and Caribbean (LAC): Visa’s Account Support Center (ASC) through the
Visa Client Support Application (VCSA), available via Visa Online
- Asia Pacific (AP): [email protected]
- Central Europe, Middle East, and Africa (CEMEA): [email protected]
- European Region: [email protected]
 Visa Rules
- Email: [email protected]
Visa Secure Program
1 Visa Secure Program

This chapter provides an overview of Visa Secure and includes:
 Introduction—Describes Visa Secure purpose, the 3-D Secure Protocol, and the benefits of
the program.
 How Visa Secure Works—Provides a high-level overview of the Visa Secure transaction
flow along with information on the associated participants and components.
 Visa’s Authentication Data—Highlights the key data elements associated with Visa
Secure: Electronic Commerce Indicator (ECI), Cardholder Authentication Verification Value
(CAVV), CAVV Results Code, and the 3-D Secure Indicator.
 Message Details and Transaction Flows—Outlines the Visa Secure messages along with
the Frictionless flow, the Challenge flow (for both browser use and merchant application
use), and the authorization flow.
1.1 Introduction
Visa Secure is a global solution designed to make e-commerce transactions more secure by
helping to ensure the transaction is initiated by the rightful owner of the Visa account. Implementing
Visa Secure can improve profitability through increased sales and reduced operational
costs.
The Three-Domain Secure (3-D Secure or 3DS) Protocol that Visa Secure is based on serves as
the mechanism for cardholder authentication at the time of an e-commerce purchase. For
merchants and issuers, Visa Secure provides an additional layer of security prior to authorization, and
for cardholders, it creates the trust they seek when shopping online.
1.1.1 Authentication vs. Authorization
Visa Secure focuses on cardholder authentication for e-commerce transactions. Authentication and
authorization are distinctly different processes with different business objectives:
 Authentication is the process of helping to ensure that the cardholder is the rightful owner
of the Visa payment account. Authentication takes place using the issuer’s selected
authentication method. See the next section for more information.
 Authorization is the process used by a card issuer to approve or decline a Visa
payment transaction from a merchant/acquirer or other card acceptor.
Authentication using Visa Secure, if invoked by the merchant, occurs before authorization and outside
of the authorization stream. Once authentication is completed, then authorization may occur through
the merchant’s acquirer following the standard process.
6 Visa Confidential 10-Sep-2020

1.1.2 Authentication Methods
Depending on the authentication solution the Issuer chooses, there are many authentication methods
available for an issuer to use.
Visa recommends that issuers use risk-based authentication as their authentication approach, when
appropriate—recognizing that in some cases regulatory requirements may have specific “step-
up” or challenge authentication requirements. With risk-based authentication, the issuer will assess
the risk of the transaction and then either:
 Complete authentication without involving the cardholder. OR
 If needed, request further authentication by challenging the cardholder through a
dynamic method1.
Risk-based authentication typically results in a frictionless experience for the cardholder and
limits cardholder involvement in the authentication process to those transactions that require
additional verification.
If additional verification of the cardholder is required, Visa recommends that a dynamic (rather
than static) method be used. A dynamic authentication method is one where the data entered by
the cardholder is different for each transaction—the information entered is only valid for one
transaction and can be entered into the authentication screen to verify the cardholder’s identity.
A one-time passcode is an example of a dynamic authentication method.
1.1.3 Benefits
Visa Secure involves cardholders, issuers, merchants, acquirers, and Visa. Visa Secure is designed to
benefit all participants in an e-commerce payment transaction. The benefits include:
 Optimized Approvals—Used as another layer of fraud defense, false-positives can be minimized
allowing increased authorization throughput.
 Reduced Operational Expenses—A decrease in fraudulent Disputes and their associated
losses and processing costs contribute to a healthier bottom line.
 Increased Consumer Confidence—The use of more robust authentication methods at the
time of purchase improves security and reduces friction, which in turn bolsters consumer
confidence leading to increased profitability for merchants and issuers.
1
In some cases, an active challenge of the cardholder may be required due to local/country regulations.
1.1.4 Participants
The main participants in a Visa Secure transaction are described in the table below.
Table 1–1: Participants in a Visa Secure transaction
Participants Roles
Cardholder  Uses Visa card to pay for online purchases from a merchant’s
website or merchant’s e-commerce application (which resides on a device
such as a smart phone)
 Is authenticated according to issuer’s choice of authentication
method
Issuer  Manages the issuer’s authentication program according to the Visa
Secure guidelines
 Uses software to authenticate the cardholder during online purchases;
this software is referred to as the Issuer Access Control Server
(ACS)
 Provides a cryptographic value for each authenticated transaction; this
value is called a Cardholder Authentication Verification Value
(CAVV)
 Receives VisaNet authorization messages from acquirers, which includes
Visa Authentication Data, and responds with authorization
decisions
See Section 1.3: Visa Authentication Data for details.
Merchant  Offers merchandise or services at an e-commerce website or via
merchant’s e- commerce application and accepts Visa for payment
 Uses software to support Visa Secure Program; this software is referred to as
the 3DS Server and optionally a 3DS Software Development Kit (SDK)
 Sends Visa’s Authentication Data to the acquirer as part of the
authorization message
Acquirer  Signs up merchants to participate in Visa Secure

 Ensures that merchants originating e-commerce transactions are
operating under a Merchant Agreement with the acquirer in accordance with
the business rules and technical requirements of Visa Secure
 Receives transaction details from merchants, including Visa Authentication
Data to include in the authorization, formats and submits authorization
messages to issuers through Visa; and provides the issuer’s
authorization decision to merchants
 Responsible for signing up 3DS Server providers as third-party agents
Visa  Operates components of the Interoperability Domain for Visa Secure,

including the Visa Directory Server and Visa’s Attempts Service
 Operates VisaNet to route payment transactions between issuers and
acquirers
 Offers issuer services where VisaNet can verify the CAVV on the issuer’s
behalf for all transactions or those processed in VisaNet Stand-in
 Manages Visa 3DS Security Program that ensures third parties performing
ACS or DS services on behalf of issuers comply with applicable
requirements
1.2 How Visa Secure Works
This section provides an overview of Visa Secure including:

 Domains and Components Overview
 Merchant/Acquirer Domain
 Issuer Domain
 Visa Interoperability Domain
 Transaction Flow Overview
 Dispute Requirements
1.2.1 Domains and Components
Visa Secure defines three distinct domains that interact to support authentication and authorization a
Merchant/Acquirer Domain, the Visa Interoperability Domain, and Issuer Domain.
Figure 1-1: Domains and Components
Merchant / Acquirer Domain Visa Interoperability Domain Issuer Domain
3DS Server / 3DS SDK Visa Directory Server Issuer Access Control Server (ACS)
Merchant’s E-Commerce Software Visa Attempts Service
Acquirer / Acquirer Processor VisaN Issuer / Issuer

et Processor Host
System
1.2.2 Merchant/Acquirer Domain
The Merchant/Acquirer Domain includes Merchant’s e-commerce checkout, Authentication, and

Authorization components.
1.2.2.1 Merchant’s E-Commerce Checkout Environment
Merchants can invoke Visa Secure for consumers shopping on the Merchant’s e-commerce websites
using a browser or shopping via the merchant’s e-commerce application on a device (e.g.,
mobile application or mobile browser).
1.2.2.2 Authentication Components
A merchant’s authentication components enable the merchant to send and Visa Secure messages and
include:
 Merchant Plug-in (MPI) or 3DS Server software to enables the merchant to use
3DS authentication with consumers using browser-based devices
 3DS Software Development Kit (SDK) software enables the merchant to use 3DS
with consumers using device-based applications (e.g., a mobile application)
1.2.2.3 Authorization Components
A merchant’s authorization components enable the merchant to interface with VisaNet to process
payment transactions. A merchant’s authorization components generally include:
 Payment Processing System—Software that creates and sends the payment
transaction information to the acquirer processor, including Visa Authentication Data that
is sent to the Issuer in the authorization message.
 Acquirer Processor—The acquirer host system that communicates with VisaNet to
process payment transactions.
1.2.3 Issuer Domain
The Issuer Domain includes Authentication and Authorization components.
1.2.3.1 Authentication Component
Issuer ACS—The Issuer ACS responds to authentication requests and performs cardholder
authentication.
 The issuer defines the authentication methods and the criteria that the ACS uses to
determine what type of authentication is needed.
 The Issuer’s ACS creates the CAVV and provides it to the merchant in the
authentication response.
 The merchant includes the CAVV in the authorization request message to the issuer as
proof that authentication was performed.
1.2.3.2 Authorization Component
Issuer Host—The Issuer Host system communicates with VisaNet to process payment transactions.
 The Issuer Host receives the VisaNet authorization message and uses Visa Authentication
Data included in the transaction to approve or decline the purchase.
 The Visa Authentication Data in the authorization message includes the CAVV. The issuer
can use the CAVV to support the authorization decision process.
 Visa Secure requires the Issuer verify the CAVV sent in the authorization request by the
Merchant/Acquirer. VisaNet offers a service where VisaNet can perform CAVV verification on
behalf of the Issuer.
1.2.4 Visa Domain
The Visa Domain, also referred to as the Interoperability Domain, includes Authentication and
Authorization components.
1.2.4.1 Authentication Components
Visa operates Visa Secure Directory Server and the Visa Secure Attempts Service.
 Visa Directory Server—The Visa Directory Server routes Visa Secure messages
between Merchant MPI or 3DS Servers and the Issuer ACS or Attempts Server.
 Visa Attempts Service—Is a Visa service that responds to authentication request messages on
behalf of the Issuer when either the Issuer does not participate in Visa Secure or the
Issuer participates but their ACS is unavailable. The Visa Attempts Service provides proof, in
the form of a CAVV, in the authentication response that the merchant attempted to
obtain authentication.
NOTE: The Visa Directory Server for 3DS 1.0 and EMV 3DS are independent and not
backwards compatible
1.2.4.2 Authorization Components
Visa’s authorization component is VisaNet and VisaNet’s CAVV verification service.

 VisaNet—Is a collection of systems and services where Visa offers online financial
processing, authorization, clearing, and settlement services to issuers and
acquirers.
 CAVV Verification— VisaNet can perform CAVV verification on behalf of the issuer
during authorization processing OR during Visa Stand-In Processing (STIP) when the
Issuer’s Host is not available). The issuer must provide their CAVV keys to VisaNet to
participate in these services.
1.2.5 Dispute Requirements
When Visa Secure authentication is successful (ECI 05) or attempted authentication (ECI 06) is
completed for a transaction, the Merchant is protected against e-commerce fraud-related
Disputes.
The Merchant must include the CAVV received during authentication in the authorization
request for every Visa Secure transaction.
1.3 Visa Authentication Data
Visa Authentication Data is used to communicate information about authentication between the Issuer
ACS, the Merchant, VisaNet, and the Issuer Host.
The Merchant receives some Visa Authentication Data from the Issuer ACS during authentication. Visa
Secure requires that this data be sent in the authorization request to VisaNet and the
Issuer.
Authentication Data created during authentication by the Issuer ACS, Issuer Attempts Server, or Visa’s
Attempts Service include:
 Electronic Commerce Indicator (ECI)
 Cardholder Authentication Verification Value (CAVV)
Other Visa Authentication Data are created by VisaNet or the Issuer (in one scenario only)
during authorization; these fields include:
 3-D Secure Indicator (3DS Indicator)
 CAVV Results Code (created by the Issuer or VisaNet)
1.3.1 Electronic Commerce Indicator (ECI)
The Issuer ACS or an Attempts Server provides the ECI value to the Merchant during
authentication.
The ECI indicates the level of authentication that was performed on the transaction.
The Merchant must include the ECI value received from authentication in the authorization request.
Visa’s ECI values are shown in the table below.
Table 1–2: Electronic Commerce Indicator (ECI) Values
ECI Value Description
0 Cardholder authentication successful

5
0 Merchant attempted to authenticate the cardholder
6
0 Non-authenticated e-commerce transaction
7
1.3.2 Cardholder Authentication Verification Value (CAVV)
The Issuer’ ACS or an Attempts Server returns a CAVV in the authentication response message
to the Merchant.
 The Issuer ACS creates a CAVV when cardholder authentication is successful; the
corresponding ECI is 05 OR
 The Issuer Attempts Server or Visa Attempts Service creates a CAVV when authentication
is attempted; the corresponding ECI is 06
Effective 17 October 2020 in the Canada Region, Europe Region, LAC Region, US Region.
Effective 17 April 2020 in the AP Region, CEMEA Region. CAVV usage 3 version 7 must be
used when responding to a Visa Secure EMV 3DS transactions.
A CAVV is unique for each authentication transaction. The CAVV provides proof that
cardholder authentication occurred or that the Merchant attempted authentication.
The Merchant/Acquirer must include the CAVV in the authorization request message.
1.3.3 CAVV Results Code
The CAVV Results Code field contains results of CAVV verification performed during
authorization:
 VisaNet will update the CAVV Results Code field with the CAVV verification results
(e.g., PASS/FAIL), if the Issuer has opted for VisaNet to perform CAVV
verification,
 The Issuer is responsible for updating the CAVV Results Code field with the CAVV
verification results (e.g., PASS/FAIL), if the Issuer has opted to perform CAVV
verification,
The CAVV Results Code communicates CAVV verification results (e.g., PASS/FAIL) and the value
returned will also indicate if the CAVV was created by the Issuer’s ACS, the Issuer’s Attempts Server,
or Visa’s Attempts Service.
See Appendix C: CAVV Verification Results Code (Field 44.13) for more details.
1.3.4 3-D Secure Indicator (3DS Indicator)—Optional
The 3DS Indicator communicates the 3DS version number (i.e., 3DS 1.0 or EMV 3DS) and the EMV
3DS
authentication method used to authenticate the cardholder. The 3DS Indicator can be
used for authorization processing or for back-office activities (e.g., reporting or
analytics).
The 3DS Indicator is a field that the Issuer or Acquirer can optionally choose to
receive in authorization:
 The Issuer receives the 3DS Indicator in the authorization request message
 The Acquirer receives the 3DS Indicator in the authorization response message
See Cardholder Authentication Verification Value (CAVV) Implementation Guide or Visa

Secure Merchant/Acquirer or Issuer Implementation Guides for a list of 3DS Indicator
values.
1.3.5 3DS 1.0.2 Authentication Messages Descriptions and Transaction Status Values
This section provides a description of each message along with the response data (Transaction Status
values, ECI values, and whether or not a CAVV is present).
Table 1–3: 3DS 1.0.2 Transaction Flow Messages and Transaction Status
Message Type
Transactio Transaction Status

Message n Status Description EC CAVV
I
Verify Enrollment Request Y Transaction is eligible N/ N/A

/Response for authentication A
(VEReq/VERes) N Card is not valid 07 No CAVV
Prior to authentication,
the merchant must first U Card product type is
Non- Reloadable Visa
ensure that the issuer
Prepaid
participates in Visa Secure
and that the card is
eligible for authentication
Payer Y Authentication 05 CAVV

Authentication Successful
Request/Respons
e
(PAReq/PARes)
The cardholder is
authenticated using the
Message Type

Message n Status Description EC CAVV
I
issuer’s authentication A Merchant attempted 06 CAVV
method authentication but issuer
does not participate in
Visa Secure or card is
not eligible for
authentication
N Not Authenticated; 07 No CAVV
Transaction Denied
U Authentication could not be 07 No CAVV

performed (generally
indicates a system error); or
Issuer ACS is unavailable
Exceptions
- ERROR RECEIVED—If the 3DS Server receives an error message the merchant may
proceed with authorization with an ECI = 07 (non-authenticated e-commerce
transaction).
Note: This does not apply in countries where authentication is mandated.
- NOT AVAILABLE—If an Issuer ACS or Attempts Server is not available, the Visa Attempts
Service will respond to the MPI with PARes = A (Attempts Processing Performed), ECI 06,
and a CAVV.
The merchant may proceed to authorization and must provide the ECI 06 and the
CAVV in the authorization message.
 Merchant Plug-in
- Evaluates the PRes message and the Transaction Status provided by Issuer
ACS/Attempts Server.
 Y, N, U, or A, the merchant can proceed to authorization using the ECI value and
CAVV (CAVV is only applicable for Y or A) provided by the Issuer
See Table 1–4: EMV 3DS Transaction Flow Messages and Transaction Status for Transaction Status
details.
1.3.6 EMV 3DS Authentication Messages Descriptions and Transaction Status Values
This section provides a description of each message along with the response data (Transaction Status
values, ECI values, and whether or not a CAVV is present).
Table 1–4: EMV 3DS Transaction Flow Messages and Transaction Status
Message Type

Message n Status Description ECI CAVV
Authentication Request Y3 Authentication 05 CAVV Present

/Response Successful
(AReq/ARes) Attempts Processing 06
A34
2
The 3DS Server sends Performed
the AReq through the
I Informational Only; 07 CAVV Present
Visa DS to the Issuer 3DS Requestor
ACS or Attempts ACS
challenge preference
Upon receipt, the Issuer acknowledged.
ACS or Attempts ACS
N Authentication Failed; 07 No CAVV
performs risk-based
Not Authenticated;
authentication and
Transaction Denied
provides the results of
authentication to the U Authentication Could Not
3DS Server in the ARes Be Performed; Technical or
Other Problem
C Challenge Required to
authenticate the cardholder
R Authentication Rejected
Challenge Y Authentication Results of the

Request/Response Successful challenge are sent
in the Results
(CReq/CRes)
Request (RReq)
The 3DS Server (or 3DS message by the ACS
SDK) sends the CReq to to the 3DS Server.
the Issuer ACS
Upon receipt, the Issuer N Not Authenticated;
ACS challenges the Transaction Denied
cardholder through an
authentication
method such as OTP and
2
A server or system that the merchant (or third party on the merchant’s behalf) uses to support Visa Secure program
authentication processing.
3
Not a valid response for an AReq sent with a 3DS Requestor Challenge Indicator 06 = No challenge requested (Data
share only)
4
NPA is excluded from Attempts Processing
Message Type

Message n Status Description ECI CAVV
responds to the 3DS
Server or 3DS SDK with
the CRes
Results Request/Response
Same set of values as AReq/ARes
(RReq/RRes)
 A successful challenge is an ECI 05 with a CAVV
The Issuer ACS sends
the RReq to the 3DS  An unsuccessful challenge is an ECI 07 with
no CAVV
Server to provide the
results of the challenge
authentication
The 3DS Server
acknowledges the RReq by
responding with the
RRes
Exceptions
- ERROR RECEIVED—If the 3DS Server receives an error message the merchant may
proceed with authorization with an ECI = 07 (non-authenticated e-commerce
transaction).
Note: This does not apply in countries where authentication is mandated.
- NOT AVAILABLE—If an Issuer ACS or Attempts Server is not available, the Visa Attempts
Service will respond to the 3DS Server with ARes = A (Attempts Processing Performed),
ECI 06, and a CAVV.
The merchant may proceed to authorization and must provide the ECI 06 and the
CAVV in the authorization message.
 3DS Server
- Evaluates the ARes message and the Transaction Status provided by Issuer
 Y, N, U, or A, the merchant can proceed to authorization using the ECI value and
CAVV (CAVV is only applicable for Y or A) provided by the Issuer
 R, it is not recommended to proceed to authorization.
 C, the frictionless flow transitions to the Challenge flow.
- See Table 1–4: EMV 3DS Transaction Flow Messages and Transaction Status for Transaction Status
details.
 ACS
- If ACS responds ARes or RReq N, U, or R, a Transaction Status Reason Code
should be included.
- See Table 1–4: EMV 3DS Transaction Flow Messages and Transaction Status Reason Code for
Transaction Status Reason Code details.
Table 1–5: EMV 3DS Transaction Status Reason Code
Message
Type
Transactio Transaction Status Reason
n Status
Transacti Reason
Message on Code ECI CAVV
Status
Authenticati N 01 Card Authentication Failed 07 No CAVV

on Request
/Response 02 Unknown Device
U
(AReq/ARes) 03 Unsupported Device
04 Exceeds authentication
R Frequency Limit
05 Expired Card
06 Invalid Card Number
07 Invalid Transaction
08 No Card Record
09 Security Failure
10 Stolen Card
11 Suspected Fraud
12 Transaction Not Permitted

to Cardholder
135 Cardholder not enrolled in

service
14 Transaction timed out at the
ACS
15 Low confidence
16 Medium Confidence
17 High Confidence
5
The Visa Attempts Server will stand in if an ARes = N and Transaction Status = 13 is returned by the ACS
Message
Type
n Status
Transacti Reason
Status
18 Very High Confidence
19 ACS Maximum Challenges
22 ACS technical issue
23 Decoupled Authentication
Required by ACS but not
requested by 3DS Requestor
24 3DS Requestor Decoupled Max

Expiry Time Exceeded
25 Decoupled Authentication was

provided insufficient time to
authenticate cardholder. ACS will
not make attempt
26 Authentication attempted but not

performed by the cardholder
20 Non-Payment transactions not N

Supported /
Effective 14 April 2021, A
Reason Code Not
Allowed
21 3RI transaction not supported
Effective 1 September 2019,
Reason Code not Allowed
806 Error Connecting to ACS 07 No CAVV
816 ACS Timed Out
826 Invalid Response from ACS
836 System Error Response from

ACS
846 Internal Error While Generating
CAVV
6
Visa Directory Server (DS) Response only
Message
Type
n Status
Transacti Reason
Status
856 VMID not eligible for
requested program
866 Protocol Version Not

Supported by ACS
876 Transaction is excluded from

Attempts Processing (includes
non- reloadable pre-paid cards
and Non- Payments (NPA))
886 Requested program not

supported by the ACS
1.4 Authorization Overview
Once authentication is completed, the Merchant/Acquirer can submit the Visa Authentication data
(i.e., ECI and CAVV) in the authorization request message to VisaNet and the Issuer.
Figure 1-2: Authorization Flow
1.4.1 Precursor to the Authorization Flow
The merchant provides the authentication results including the ECI value and the CAVV to their
Acquirer/Acquirer Processor. The ECI and CAVV are provided to the merchant in the
 3DS 1.0.2
- PARes message
 EMV 3DS
- ARes message for a Frictionless Flow or
- RReq message for a Challenge Flow
1.4.2 Authorization Flow (Authorization Request message)
 Acquirer/Acquirer Processor:
- Creates the authorization request including the ECI and CAVV
- Forwards the authorization request to the issuer through VisaNet
 VisaNet
- Recognizes ECI 05 and 06 transactions as Visa Secure transaction:
 If the Issuer has selected Visa to perform CAVV verification, VisaNet will verify the
CAVV and provide the issuer with the CAVV verification results
 If the Issuer has opted perform CAVV verification, VisaNet will forward the CAVV
to the Issuer for the Issuer to verify
- Includes the 3DS Indicator to the Issuer in the authorization request, if the Issuer has
elected to receive the 3DS Indicator.
 The 3DS Indicator identifies the 3DS protocol version (i.e., 3DS 1.0.2 or EMV
3DS) and authentication method used during authentication.
- Includes the 3DS Protocol Version Number to the Acquirer in the authorization request,
if the Acquirer has elected to receive the 3DS Protocol Version Number.
 The 3DS Protocol Version Number identifies the 3DS protocol version (i.e., 3DS
1.0.2 or EMV 3DS v2.1.0, v2.2.0) used during authentication.
- Forwards the authorization request to the Issuer Host for processing
1.4.3 Authorization Flow (Authorization Response message)
 Issuer Host
- Receives the ECI, CAVV, and CAVV Results (if signed up for the CAVV Verification Service)
in the authorization message
- Verifies the CAVV and updates the CAVV Results field (if the issuer performs their own
CAVV verification)
- Completes their authorization decision
- Returns the authorization response (approve or decline) to the acquirer via VisaNet.
 VisaNet
- Includes the 3DS Indicator to the Acquirer in the authorization request, if the
Acquirer has elected to receive the 3DS Indicator.
 The 3DS Indicator identifies the 3DS protocol version (i.e., 3DS 1.0.2 or EMV
3DS) and authentication method used during authentication.
- Includes the 3DS Protocol Version Number to the Acquirer in the authorization request,
if the Acquirer has elected to receive the 3DS Protocol Version Number.
 The 3DS Protocol Version Number identifies the 3DS protocol version (i.e., 3DS
1.0.2 or EMV 3DS v2.1.0, v2.2.0) used during authentication.
- Forwards the authorization response to the Acquirer for processing
 Acquirer/Acquirer Processor
- Forwards authorization decision to the merchant.
- Note: For dual message endpoints, merchants/acquirers must ensure that the same ECI
and CAVV values used in authorization messages are submitted in Clearing and
Settlement messages.
 Merchant
- Provides authorization response to cardholder.
Visa Secure Program Rules
2 Visa Secure Program Rules

This chapter outlines Visa Secure program rules:
 Visa Secure Program Participation Rules
 Issuer Rules and Requirements
 Acquirer Rules and Requirements
 Card Product Type Restrictions (Non-Reloadable Prepaid Cards)
 Dispute Protection and Exceptions
 CAVV Mandate
 Global Attempts Processing
 Use of Authentication Data in Authorization
 ECI 6 Decline Compliance Program
 Authorization Processing
 Authentication Approval Rates (U.S. Only)
 EMV 3DS Requirements
 Country Rules
 User Interface Requirements
2.1 Visa Secure Program Participation Rules
A Visa Secure participant must:

 Complete Visa Secure program enrollment process.7
 Ensure that its Visa Secure for EMV 3DS component8 has successfully met the requirements
of the EMVCo 3-D Secure Compliance Testing Program and Visa Secure Product
Certification Testing.
 Ensure that its Visa Secure for 3-D Secure 1.0.2 component9 has successfully met
the requirements of the Visa 3-D Secure 1.0.2 Compliance Testing.
 Only use a digital certificate issued by or associated with Visa as an authentication
mechanism for a Visa product or service.
7
See Issuer or Merchant/Acquirer Implementation Guide
8
ACS for issuers and 3DS Server and/or 3DS SDK for merchants/acquirers.
9
ACS for issuers and MPI for merchants/acquirers.
10-Sep-2020 Visa Confidential 23

 Adhere to the 3-D Secure 1.0.2 or EMVCo 3-D Secure data inclusion requirements10.
2.2 Issuer Rules and Requirements
A Visa Secure participant must:

 Issuers that do not support an ACS are automatically enrolled in the Visa Attempts Server
(where Visa will respond to authentication requests on behalf of the issuer with an attempt
response that contains a CAVV) and issuer will be liable for any fraudulent transactions
associated with specific reason codes.
2.3 Acquirer Rules and Requirements
Acquirers are responsible for ensuring that participating merchants operate in accordance
with the requirements in this Guide and the Visa Core Rules and Visa Product and Service
Rules, and that such requirements are included in Merchant Agreements. Acquirers must
ensure and/or approve the following:
 Service Availability—Acquirers must notify their e-commerce merchants of the
availability of Visa Secure and provide the service to their e-commerce merchants,
as requested.
 Merchant Agreements—Merchant Agreements must be modified to
reflect a merchant’s participation in Visa Secure.
 Visa Secure Digital Certificates—Acquirers must assist 3DS Server Operators in
obtaining digital certificates to support mutual authentication between the 3DS Server
and the Visa Directory Server.
 Security Requirements— Merchants and third-party commerce server providers must
meet the security requirements for 3-D Secure processing, including support for
the Payment Card Industry Data Security Standard (PCI DSS) for protecting card
and cardholder information.
 Acquirer Approval—Contracts with third-party server providers or payment gateways
must ensure that each merchant activated for Visa Secure is reported to
and approved by the acquirer.
10
See 3-D Secure 1.0.2 Protocol Specifications or EMV 3-D Secure Protocol and Core Functions Specification, and EMV 3-D
Secure SDK Specification, for details.
 Third Party Agent Registration—An acquirer who has contracted with a third-
party service provider to provide Visa Secure services to its merchants must
register third party
2.4 Card Type Restrictions (Non-Reloadable Visa Prepaid Cards)
Non-reloadable Visa prepaid cards are not required to participate in Visa Secure program.
Although not required to participate, issuers may choose to include this card type in Visa
Secure program by setting up the ISO BIN to participate in the service.
In terms of liability:
 Authentication—If a non-reloadable Visa prepaid card is authenticated during Visa Secure
program (ECI 05), the merchant is protected against specific Dispute reason codes.
 Attempted Authentication—If authentication is attempted on a non-reloadable Visa
prepaid card (ECI 06), the merchant does not receive liability protection on e-commerce
fraud-related Disputes.
See Visa Secure Program Dispute Resolution Guide for more information on merchant
Dispute protection.
2.5 Dispute Protection and Exceptions
With Visa Secure program, merchants/acquirers are protected against e-commerce fraud-related
Disputes when the ECI is 05 or 06 and a CAVV is present in the authorization message.
Visa Secure with EMV 3DS dispute protection is fully active on the following:
 15 August 2019 – Canada, and Latin America
 14 March 2020 – Europe
 18 April 2020 – Asia Pacific and CEMEA
 31 August 2020 - US
This means prior to the EMV 3DS activation date, merchants/acquirers are not protected
against e- commerce fraud-related Disputes when they attempt an authentication and the
issuer is not participating.
2.5.1 Exceptions
There are exceptions to merchant Dispute protection for ECI 05 and ECI 06 transactions. For
these
exceptions, the issuer can Dispute:
Table 2–1: Merchant Dispute Protection Exceptions
Scope Restriction ECI Description
Global CAVV Not Present ECI 05 or Merchants are not protected when ECI is
06 05 or 06 and a CAVV is not present in
authorization.
Global Non-Reloadable Prepaid ECI 06 Merchants are not protected when card
type is a non-reloadable Visa prepaid
card.
Global Visa Fraud ECI 05 or Merchants are not protected if they have
Monitoring 06 been identified in the program.
Program Merchant/acquirers in the program
should submit Visa Secure transactions
using ECI 07.
U.S. Visa 3-D Secure Fraud ECI 05 or Merchants are not protected if they have
Monitoring Program 06 been identified in the program.
Merchants/acquirers in these programs
should submit Visa Secure transactions
using ECI 07
U.S. Custom Payment System ECI 05 or Merchants are not protected if transaction
(CPS) Requirements 06 does not meet CPS requirements.
U.S. Merchant Restricted ECI 05 or Merchants are not protected if they are
Merchant Category 06 in one of the following MCCs:
Codes (MCCs)  MCC 4829—Wire Transfer/Money
Order
 MCC 5967—Direct Marketing-
Inbound Teleservices
 MCC 6051—Non-Financial Institution-
Foreign Currency, Money Order (not
Wire Transfer), Travelers’ Cheques
 MCC 7995—Betting, including
Lottery Tickets, Casino Gaming
Chips, Off-Track Betting and
Wagers at Race Tracks
 MCC 6540 - Non-Financial
Institutions: Stored Value Card
Purchase / Load
 MCC 7801 - Government Licensed On-
Line Casinos (On-Line Gambling)
 MCC 7802 - Government-
Licensed Horse/Dog
Racing
2.6 CAVV Mandate
Participating issuers are required to provide a CAVV on authenticated (ECI 05) and attempted
authentication (ECI 06) transactions.
Merchants will receive a CAVV for authenticated and attempted authentication transactions
which they must provide in the authorization message. For ECI 05 or ECI 06 transactions where a
CAVV was not received in authorization, VisaNet will reclassify the ECI value to ECI 07. ECI 07
transactions are not protected from Disputes.
2.7 Global Attempts Processing
When an issuer or issuers cardholder does not participate in Visa Secure or participates but
their ACS is unavailable, the Visa Attempts Server responds on their behalf. The response
indicates that the merchant attempted to obtain authentication and provides the merchant with
a CAVV. Where the Visa Attempts Service responds on the issuer's behalf, the issuer will be
liable for any e-commerce fraud- related disputes.
Visa assesses a fee to the issuer for providing a CAVV on its behalf as specified in the
applicable Fee Guide.
2.7.1 Global Attempts Processing for EMV 3DS
Effective 15 August 2019
For issuers in the Canada and LAC, regions, if an issuer does not support Visa Secure with
EMV 3DS, Visa will respond to an authentication request, on behalf of the issuer, with an
attempt response (ECI
06) that contains a Cardholder Authentication Verification Value (CAVV).
Effective 14 March 2020
For issuers in Europe, if an issuer does not support Visa Secure with EMV 3DS, Visa will
respond to an authentication request, on behalf of the issuer, with an attempt response (ECI
06) that contains a Cardholder Authentication Verification Value (CAVV).
Effective 18 April 2020
For issuers in the AP and CEMEA regions, if an issuer does not support Visa Secure with EMV
3DS, Visa will respond to an authentication request, on behalf of the issuer, with an attempt
response (ECI 06) that contains a Cardholder Authentication Verification Value (CAVV).
Effective 31 August 2020

For issuers in the US region, if an issuer does not support Visa Secure with EMV 3DS, Visa will
respond to an authentication request, on behalf of the issuer, with an attempt response (ECI 06)
that contains a Cardholder Authentication Verification Value (CAVV).Visa assesses a fee to
issuers for providing a CAVV on its behalf as specified in the applicable Fee Guide.
2.8 Use of Authentication Data in Authorization
This section outlines the rules and requirements associated with the use of authentication data in
different transaction types such as split shipments, delayed deliveries, recurring transactions,
installment transactions, and online auctions.
2.8.1 Split Shipment and Delayed Delivery
The following outlines information on the use of authentication data in split shipments and
delayed
delivery:
 Split Shipment—A split shipment occurs when a single purchase order results in more
than one shipment of merchandise. In the event a merchant splits the shipment of an
order, the second Authorization Request may be submitted with the original authentication
data for the purchase.
 Delayed Delivery—When a second authorization request is submitted for the same
original purchase due to delayed delivery the authentication data may be included in
the second Authorization Request message.
In the event of a cardholder dispute, the acquirer and merchant must be able to demonstrate
that all Authorization Requests are related to the single, original, authenticated purchase
transaction. The total amount of the split transaction must not exceed 15% over the original
authentication amount. The 15% variation allows for shipping costs associated with the items. Any
authorization amount that exceeds 15% of the authenticated amount is not subject to Visa
Secure Dispute protection and may be charged back by the issuer.
2.8.2 Time Limit and Amount Variation
Authentication data for a transaction must not be submitted in the authorization request for
another
transaction and merchants must adhere to the following limits associated with authentication data:
 Time Limit—Data received in an original authentication may be obtained up to 90 days
prior to an authorization date. This time allows for instances such as pre-purchase
transactions where the cardholder may pre-order and purchase a good or service prior to
the item’s availability.
 Amount Variation—The original authentication data will be valid in authorization for
amounts that do not exceed 15% over the authenticated amount. This variation allows
for additional shipping costs associated with the transaction. Any authorization amount that
exceeds 15% of
the authenticated amount is not subject to Visa Secure Dispute protection and may be
charged back by the issuer.
2.8.3 Recurring Transactions
Recurring transactions occur when the cardholder and merchant agree to purchase goods or services
on an ongoing basis over a period of time. Recurring transactions are multiple transactions processed
at predetermined intervals, not to exceed one year between transactions. Examples of recurring
transactions include insurance premiums, subscriptions, Internet service provider fees, membership
fees, tuition, or utility charges.
 First Authentication Transaction—Issuer should be aware that for merchants to receive

Dispute protection, the first transaction in the series must be authenticated and
must follow authorization rules associated with an authenticated transaction, which
means the authorization is submitted with the appropriate ECI and CAVV for the Visa
Secure transaction.
 Subsequent Authorization Transactions—All subsequent authorization requests in the recurring
series must be processed as Recurring Transactions, using the Recurring Indicator.
Recurring indicators vary based on acquirer region:
- Recurring: US acquired: ECI = “02”
- Non-US acquired: POS Environment Code = “R”
- The merchant must not store and submit the CAVV with any subsequent
authorization transaction.
- Because the first transaction was conducted via the Internet as a Visa Secure authenticated
or attempted authentication, Dispute protection applies to the original e-commerce
transaction. For the subsequent Recurring Transactions, Dispute provisions applicable
to Recurring Transactions apply; Visa Secure Dispute protection does not apply.
 Authentication Fields—The ‘Recurring Payment Data’ field, ‘Recurring Frequency’ field,
and ‘Recurring Expiry’ field in the Authentication Request (AReq) message are required
when the merchant and cardholder have agreed to recurring payments. The ‘Recurring Expiry’
field must contain a date that is later than the original authentication date.
2.8.4 Installment Transactions
Like recurring transactions, installment transactions are divided into two or more transactions and are
billed to an account in multiple segments over a period of time that is agreed to by the
cardholder and merchant.
An installment transaction is for a single good or service rather than an ongoing (or
recurring) purchase. The transactions must have a specified end date.
 First Authentication Transaction
- Similar to the processing of recurring payments, the initial installment transaction must
be authenticated and must follow authorization rules associated with an
authenticated transaction.
- The first installment transaction received Dispute protection from fraud related Disputes
for fully authenticated and attempted authentications.
 Subsequent Authorization Transactions—The remaining transactions are processed as
installment transactions, so must not contain authentication data, specifically the ECI and the
CAVV. Dispute liability protection for the acquirer/merchant does not apply to the
subsequent installment transactions.
 Authentication Fields—The ‘Instalment Payment Data’ field in the Authentication
Request message (AReq) is required when the merchant and cardholder have agreed to
an installment payment option.
2.8.5 Online Auctions
Issuers should be aware that merchants offering online auctions may submit a valid CAVV and
appropriate ECI for an authentication or attempted authentication transaction in the authorization
request message, even though the purchase amount may have changed from the Authentication
Request (AReq) to the authorization request.
Merchants must not re-use the CAVV for another transaction with the same cardholder (for
example, on another auction).
2.9 ECI 06 Quality of Service Program
To help ensure a positive e-commerce experience for cardholders and protect the overall
integrity of the Visa Secure, issuers are not permitted to establish authorization processing
criteria where transactions submitted as attempted authentications (ECI 6) are blanket
declined. Standards and penalties have been defined in the Visa Rules.
See Appendix B.2: ECI 06 Quality of Service Program for more details.
2.10 Authorization Processing
For a Visa Secure transaction, an acquirer/merchant must submit the same ECI value in clearing
that was submitted in authorization. Applies to ECI 05 and ECI 06. If the ECI values are not the
same, the acquirer/merchant will not receive fraud liability protection.
2.11 Authentication Approval Rates (U.S. Only)
U.S. issuers must operate their Visa Secure program such that 95% of authentication transactions are
approved responses, excluding attempted authentication transactions.
2.12 EMV 3DS Requirements
2.12.1 Minimum Data Requirements for EMV 3DS
Merchants must provide the data elements in Visa Secure authentication message as follows: 1)
required always and 2) required if available. Merchants are also required to use the 3DS Method
if the Method URL is provided by the issuer. Providing Visa Secure data is subject to regional
and country regulations.
2.12.2Visa Secure Performance Program with EMV 3DS
To help ensure a positive e-commerce experience for cardholders, provide enhanced risk-based
decision making, and protect the overall integrity of Visa Secure, issuers who are processing EMV 3DS
transactions must comply with the following performance requirement for EMV 3DS transactions.
2.12.2.1 Risk-based Authentication (RBA)
Effective 19 Oct 2019 - CA, EU, LAC,
US Effective 18 Apr 2020 – CEMEA
Effective 17 Oct 2020 – AP
Issuers are required to support RBA for EMV 3DS. Issuers must evaluate the risk level of each
transaction using some form of risk-model, rules engine, or risk analysis. Issuers must apply the
following authentication procedure:
 Low risk transactions – no step-up (frictionless authentication)11
Issuers may also apply one or both of the following authentication procedures:
 Higher risk transactions – step-up may be performed (recommend no more than 5%)
11
May not apply to regulated markets requiring strong authentication (e.g., cardholders providing additional
information).
 Very high-risk transactions – may decline with no further cardholder interaction
2.12.2.2 Authentication Response Time Threshold
Effective 19 Oct 2019
An issuer must respond to the original authentication request (i.e., AReq) within 5 seconds.
If an issuer does not respond within the time threshold, Visa will provide and attempts
response (ECI 06 and CAVV) on behalf of the issuer. The issuer will be liable for fraud related
disputes on these transactions.
See EMV 3-D Secure Protocol and Core Functions Specification, Section 5.5 for more details.
2.12.2.3 Abandonment Rate Threshold
Cardholder authentication abandonment rate on EMV 3DS transactions must not exceed 5%.
Abandonment rate is calculated monthly as follows: (count of transactions a cardholder abandons 12
or selects “cancel”) divided by the total number of authentication requests.
Issuers that do not comply with the rule must provide a performance improvement plan.
If no improvements are made after four months from first identification in the program, non-
compliance assessments may be applied starting month five.
2.12.3Issuer Access Control Server (ACS) Availability with EMV 3DS
An issuer’s ACS must be available 99% of the time. Availability will be measured by: 1 - number
AReq message timeouts / total number of AReq messages.
2.12.43DS Requestor Initiated (3RI) Transactions
Effective 1 September 2019

 All issuers must support and respond to 3RI transaction.
12
Exclude ARes challenge requests the merchant opts-out of, and RReq responses where the merchant cancelled the
CReq/CRes prior to the minimum Visa challenge time limit of 60 seconds
 3RI transactions for payments can only be used for the following 3RI Indicator values:
- Version 2.2
o 06 = Split/delayed shipments (in conjunction with the current rules above)
o 11 = Other Payments (can only be used for travel agencies & travel merchants)
- Version 2.1
o 80 = 3RI for Payments (for split/delayed shipments or travel agencies)
2.12.5Non-Payment (NPA)
 If a merchant sends an NPA Authentication Request (AReq) for 3DS Requestor

Authentication
Indicator “04 = Add Card or 05 = Maintain Card” the following will apply:
- If the transaction was successfully authenticated with a challenge, the Results Request
(RReq) must contain an electronic commerce indicator (ECI) value of 05 and a
Cardholder Authentication Verification Value (CAVV).
- If the transaction is authenticated without a challenge (i.e., frictionless), the ECI and CAVV
are not required.
- If a 3DS Server sends a NPA AReq with 3DS Requestor Authentication Indicator of “06
= Cardholder Verification as part of EMV token ID&V” an issuer must respond with a
challenge request and the 3DS Server must proceed with initiating the challenge.
- If a merchant sends an NPA as part of a 3DS Requestor Initiated (3RI) authentication
request (e.g., a merchant initiated authentication request when the cardholder is not
available) and the transaction is successfully authenticated, the ECI and CAVV are not
required. 3RI NPA Values are:
o 03 – Add Card
o 04 – Maintain Card
o 05 – Account Verification

 All issuers must support and respond to NPA transactions.
2.12.6Europe & Payment Services Directive 2 (PSD2)
To take advance of the exemptions Visa’s recommends supporting EMV 3DS v2.2. Please reference the
following materials available on Visa Online to assist with planning and implementing SCA compliance
polices and solutions:
 Preparing for PSD2 SCA
 PSD2 SCA for Remote Electronic Transactions: Implementation Guide
 Addendum: Implementing SCA for Travel & Hospitality
 Trusted Listing Implementation Guide
 Delegated Authentication Implementation Guide
2.13 Country Rules
Specific country rules exist for participation in Visa Secure.
See Appendix B.1: Visa Country Rules and Local Regulatory Rules for more details.
2.14 User Interface Requirements
Visa Secure badge, artwork, reproduction, and application guidelines can be accessed through Visa
Online or at www.productbrandstandards.com
2.14.1 Issuer User Interface Requirements
The ACS must comply with specific user interface requirements and only use the Visa master
brand
logo on frictionless and challenge screens.
See Visa Secure User Experience Guidelines available on Visa Developers Partner webpage for more
details. https://developer.visa.com/pages/visa-3d-secure
Use of the Visa Secure badge is optional on checkout page and website. However, if
branding for competing payment authentication programs are displayed, the Visa Secure
badge must also be displayed.
Visa master brand and Visa Secure badge, artwork, reproduction, and application guidelines can be
accessed through Visa Online or at www.productbrandstandards.com
2.14.2Merchant User Interface Requirements
Use of the Visa Secure badge is optional on checkout page and website. However, if branding for
competing payment authentication programs are displayed, the Visa Secure badge must also be
displayed.
If the merchant displays the Visa Secure badge on its website, use of the mark must comply
with the Visa Product Brand Standards.
Visa Secure badge, artwork, reproduction, and application guidelines can be accessed through Visa
Online or at www.productbrandstandards.com
2.15 Authentication and Authorization Data
Acquirers and merchants should ensure that the data elements in Visa Secure authentication messages
match the specified data elements in VisaNet transactions.
Table 2–2: Authorization & Authentication Fields
VisaNet Field Comments
Description
Acquirer Identifier ( This field must match the acquirer Identifier used
in the Verify Enrollment Request or Authentication
Request. This field also must match the acquirer
identifier submitted in VisaNet (BASE I/SMS and
BASE
II) transactions.13
Merchant Identifier (ID) This field must match the Merchant ID used in the
Number Verify Enrollment Request or Authentication
Request. This field also must match the Merchant ID
used by the acquirer in VisaNet (BASE I/SMS and
BASE II) transactions.13
Merchant Name This field must contain the name of the online
merchant at which cardholder is making the
purchase. The maximum length is 25 characters.
The merchant name must match the name
submitted in VisaNet (BASE I/SMS and BASE II)
transactions.
Travel Agencies: For transactions booked through
travel agencies, the name of the travel merchant 14
as the merchant of record must be included in the
authentication message. The required format is
“travel agency name* travel merchant” The travel
merchant name must match the name submitted in
VisaNet (BASE I/SMS and BASE II) transactions.
13
If a merchant uses multiple acquirers, a different acquirer may be used for authentication and VisaNet processing
(i.e., BASE I/SMS and BASE II. When different acquirers are used, the acquirer identifier and Merchant ID
submitted in the authentication message do not have to match those identifiers in the VisaNet transactions (i.e., BASE
I/SMS and BASE II) 14 Travel merchant is defined as a seller or provider of goods and services
A Visa Secure with EMV 3DS Minimum Data Requirements
Merchants must provide the data elements in EMV 3DS authentication message (AReq) as
follows: 1) required always and 2) required if available. Merchants are also required to use the
3DS Method if the Method URL is provided by the issuer. Providing EMV 3DS data is subject to
regional and country regulations. The merchant data has been categorized into seven
groups.
Data Element Categorization:
Message Inclusion Device

Channel
R = Required A = App
C = Required B=
15
Conditional O = Browser
Optional 3 = 3RI
A.1 Transactional and Checkout Page Information
Table A–3: Transactional and Checkout Page Information16

Messag Message Device
Data e Category - Channel
Element Catego Non-
ry - Payment
Payme
nt
3DS Method Completion Indicator R R B
3DS Requestor Authentication Indicator R R A/B
3DS Requestor Authentication Information O O A/B
3DS Requestor Challenge Indicator O O A/B
3DS Requestor Decoupled Requestor Max O O A/B/3

Time
3DS Requestor Decoupled Requestor O O A/B/3

Indicator
3DS Requestor ID R R A/B/3
15
Sender shall include the data element in the identified Message Type if the Conditional Inclusion requirements are
met; Recipient shall check for data element presence and Validate data element contents. When no data is to be sent
data element, the data element should be absent. See EMV 3DS Specifications for Conditional Inclusions
16
Based on EMV 3DS 2.2.0 specification.
Element Catego Non-
ry - Payment
Payme
nt
3DS Requestor Name R R A/B/3
3DS Requestor Prior O O A/B/3

Transaction Authentication
Information
3DS Requestor URL R R A/B/3
3DS Server Reference Number R R A/B/3
3DS Server Operator ID17 R R A/B/3
3DS Server Transaction ID R R A/B/3
3DS Server ULR R R A/B/3
3RI Indicator18 R R 3
Account Type C C A/B/3
Acquirer BIN R O A/B/3
Acquirer Merchant ID R O A/B/3
Address Match Indicator O O A/B
Broadcast Information C C A/B/3
Browser Accept Headers R R B
Browser IP Address C C B
Browser Java Enabled C C B
Browser JavaScript Enabled R R B
Browser Language R R B
Browser Screen Color Depth C C B
Browser Screen Height C C B
Browser Screen Width C C B
Browser Time Zone C C B

17
Visa required data element. Must be present or Visa DS will reject the transaction.
18
Required for Device Channel -03 – 3RI
Element Catego Non-
ry - Payment
Payme
nt
Browser User-Agent R R B
Card/Token Expiry Date17 R O A/B/3
Cardholder Account Information O O A/B/3
Cardholder Account Number R R A/B/3
Cardholder Account Identifier O O A/B/3
Cardholder Billing Address City C C A/B/3
Cardholder Billing Address Country C C A/B/3
Cardholder Billing Address Line 1 C C A/B/3
Cardholder Billing Address Postal Code C C A/B/3
Cardholder Billing Address State C C A/B/3
Cardholder Email Address C C A/B/3
Cardholder Home Phone Number C C A/B/3
Cardholder Mobile Phone Number C C A/B/3
Cardholder Name C C A/B/3
Cardholder Shipping Address City C C A/B/3
Cardholder Address Country C C A/B/3
Cardholder Shipping Address Line 1 C C A/B/3
Cardholder Shipping Address Postal Code C C A/B/3
Cardholder Shipping Address State C C A/B/3
Cardholder Work Phone Number C C A/B/3
Device Channel R R A/B/3
Device Information C C A
Element Catego Non-
ry - Payment
Payme
nt
Device Rendering Options Supported R R A
EMV Payment Token Indicator C C A/B/3
EMV Payment Token Source C C A/B/3
Installment Payment Data C C A/B/3
Merchant Category Code R O A/B/3
Merchant Country Code R O A/B/3
Merchant Name R O A/B/3
Merchant Risk Indicator O O A/B/3
Message Category R R A/B/3
Message Extension C C A/B/3
Message Type R R A/B/3
Message Version Number R R A/B/3
Notification URL R R B
Purchase Amount R C A/B/3
Purchase Currency R C A/B/3
Purchase Currency Exponent R C A/B/3
Purchase Date & Time R C A/B/3
Recurring Expiry C C A/B/3
Recurring Frequency C C A/B/3
SDK App ID R R A
SDK Encrypted Data C C A
SDK Ephemeral Public Key (Qc) R R A
SDK Maximum Timeout R R A
SDK Reference Number R R A
SDK Transaction ID R R A
Transaction Type17 R N A/B/3

/A
Element Catego Non-
ry - Payment
Payme
nt
Whitelist Status C C A
Whitelist Status Source O O A/B/3
A.2 3DS Requestor Authentication Information
Table A–4: 3DS Requestor Authentication Information

Element Catego Non-
ry - Payment
Payme
nt
3DS Requestor Authentication Method O O A/B
3DS Requestor Authentication O O A/B

Timestamp
3DS Requestor Authentication Data O O A/B
A.3 3DS Requestor Prior Transaction Authentication Information
Table A–5: 3DS Requestor Prior Transaction Authentication Information

Element Catego Non-
ry - Payment
Payme
nt
3DS Requestor Prior Transaction O O A/B/3
Reference
Method
Timestamp
Data
A.4 Merchant Risk Indicator
Table A–6: Merchant Risk Indicator

Message Message Device
Data Categor Categor Channel
Element y- y - Non-
Payme Payment
nt
Shipping Indicator O O A/B/3
Delivery Timeframe O O A/B/3
Delivery Email Address O O A/B/3
Reorder Items Indicator O O A/B/3
Pre-Order Purchase Indicator O O A/B/3
Pre-Order Date O O A/B/3
Gift Card Amount O O A/B/3
Gift Card Currency O O A/B/3
Gift Card Count O O A/B/3
A.5 Cardholder Account Information
Table A–7: Cardholder Account Information

Element Catego Non-
ry - Payment
Payme
nt
Cardholder Account Age Indicator O O A/B/3
Cardholder Account Date O O A/B/3
Cardholder Account Change Indicator O O A/B/3
Cardholder Account Change O O A/B/3
Cardholder Account Password O O A/B/3

Change Indicator
Cardholder Account Password Change O O A/B/3
Shipping Address Usage Indicator O O A/B/3

Number of Transactions Day O O A/B/3
Number of Transactions Year O O A/B/3

Element Catego Non-
ry - Payment
Payme
nt
Number of Provisioning Attempts Day O O A/B/3
Cardholder Account Purchase Count O O A/B/3
Suspicious Account Activity O O A/B/3
Shipping Name Indicator O O A/B/3
Payment Account Age Indicator O O A/B/3
Payment Account Age O O A/B/3
A.6 Device Information (Required for Mobile App)
Device information must be provided if a mobile app is being used by the cardholder.
A.7 3DS Method
The merchant checkout page must load the ACS 3DS Method URL, if the 3DS Method URL is
present, which allows the ACS to obtain additional browser information for risk-based decision
making.
B Visa Country Rules and Visa Programs
 Visa Country Rules and Local Regulatory Rules
 ECI 6 Quality of Service Program
 Visa Secure Global Performance Enhancement Program
B.1 Visa Country Rules and Local Regulatory Rules
Acquirers and issuers must comply with specific country rules and, where applicable, regulatory rules.
This section outlines the rules which are organized by country within each Visa region.
For more information, see Visa Core Rules and Visa Product and Service Rules.
Table B–1: Visa Country/ Region /Territory Rules and Local Regulatory Rules
Country/ Visa Rule
Region/Ter or Ru
rit ory Regulator le
y Rule
All Regions
All Regions Visa Issuers When an issuer does not participate in Visa Secure or participates
but their ACS is unavailable, the Visa Attempts Server responds on
their behalf. The response indicates that the merchant attempted to
obtain authentication and provides the merchant with a CAVV.
Visa assesses a fee to the issuer for providing a CAVV on its
behalf as specified in the applicable Fee Guide.
Asia Pacific
Australia Visa Issuers An Issuer must participate in both Visa Secure with 3-D Secure 1.0
and Visa Secure with EMV 3DS, as follows:
 Visa credit19, Visa debit10, Reloadable Prepaid Cards
19
This does not apply to Virtual Accounts associated with Visa Commercial Cards
Visa Ensure that its Electronic Commerce Merchant processes an Electronic
Acquirers Commerce Transaction uses Visa Secure using EMV 3DS if it is
assigned any of the following MCCs:
 4722 (Travel Agencies and Tour Operators)
 4816 (Computer Network/Information Services)
 4829 (Wire Transfer Money Orders)
 5085 (Industrial Supplies)
 5311 (Department Stores)
 5399 (Miscellaneous General Merchandise)
 5411 (Grocery Stores and Supermarkets)
 5661 (Shoe Stores)
 5691 (Men’s and Women’s Clothing Stores)
 5699 (Miscellaneous Apparel and Accessory Shops)
 5722 (Household Appliance Stores)
 5732 (Electronics Stores)
 5733 (Music Stores – Musical Instruments, Pianos, and Sheet
Music)
 5734 (Computer Software Stores)
 5912 (Drug Stores and Pharmacies)
 5943 (Stationery Stores, Office and School Supply Stores)
 5944 (Jewelry Stores, Watches, Clocks, and Silverware Stores)
 5999 (Miscellaneous and Specialty Retail Stores)
 6211 (Security Brokers/Dealers)
 7011 (Lodging – Hotels, Motels, Resorts, Central Reservation
Services)
 7832 (Motion Picture Theaters)
 7995 (Betting, including Lottery Tickets, Casino Gaming Chips, Off-
Track Betting, and Wagers at Race Tracks)
 8999 (Professional Services)
 9402 (Postal Services – Government Only)
If a Merchant is not enrolled in Visa Secure with EMV 3DS and is
identified by the Visa Fraud Monitoring Program, it will be subject
to the High Risk MCC timeline, as outlined in the Visa Fraud
Monitoring Program.
Cambodia Visa Issuers
An Issuer must participate in both Visa Secure with 3-D Secure 1.0
 Visa credit, Visa debit
Visa
Acquirers Effective 18 April 2020
Ensure that its Electronic Commerce Merchant processes an Electronic

Commerce Transaction using Visa Secure with EMV 3DS,1 if it is
 MCC 4814 (Telecommunication Services, including Local and
Long Distance Calls, Credit Card Calls, Calls through Use of
Magnetic Stripe Reading Telephones, and Fax Services)
 MCC 8398 (Charitable Social Service Organizations)

Monitoring Program.
Hong Kong Visa Issuers
Visa
Acquirer Effective 18 April 2020
Ensure that its Electronic Commerce Merchant processes an
Electronic Commerce Transaction using Visa Secure with EMV 3DS, if
it is assigned any of the following MCCs:
 MCC 4722 (Travel Agencies and Tour Operators)
 MCC 4812 (Telecommunication Equipment and Telephone
Sales)
 MCC 5045 (Computers and Computer Peripheral
Equipment and Software)
 MCC 5621 (Women’s Ready-To-Wear Stores)
 MCC 5691 (Men’s and Women’s Clothing Stores)
 MCC 5732 (Electronics Stores)
 MCC 5734 (Computer Software Stores)
 MCC 5816 (Digital Goods – Games)
 MCC 5945 (Hobby, Toy, and Game Shops)
 MCC 5999 (Miscellaneous and Specialty Retail Stores)
If a Merchant is not enrolled in Visa Secure with EMV 3DS

and is identified by the Visa Fraud Monitoring Program, it will
be subject to the High Risk MCC timeline, as outlined in the
Visa Fraud Monitoring Program.
India Regulatory All e-commerce transactions (including Mail Order/Telephone Order and
Rule, Interactive Voice Response) are required to support 2FA (Visa
Reserve Secure)
Bank of
India (RBI)
Visa Issuers An Issuer must participate in Visa Secure, as follows:
 Visa credit , Visa debit10, Reloadable Prepaid Cards
An Issuer must authorize only a domestic Electronic Commerce
Transaction with an Electronic Commerce Indicator 5 (Secure
Electronic Commerce Transaction).
Visa Ensure that its Electronic Commerce Merchant processes

Acquirers Electronic Commerce Transactions using Visa Secure
Not process a domestic Electronic Commerce Transaction unless the
Cardholder has been successfully authenticated using Visa Secure
Indonesia Visa Issuers

Visa
Acquirers must ensure that its Electronic Commerce Merchant
processes an Electronic Commerce Transaction using Visa Secure with
EMV 3DS, if it is assigned any of the following:
MCCs:
 MCC 4511 (Airlines and Air Carriers [Not Elsewhere Classified])
Monitoring Program.
Japan Industry All JOGA members are strongly requested to implement Visa
Rule, Japan Secure
Online
Gaming
Association
(JOGA)
Macau Visa Issuers
Visa
 MCC 4812 (Telecommunication Equipment and Telephone
Sales)
 MCC 5621 (Women’s Ready-To-Wear Stores)
 MCC 5691 (Men’s and Women’s Clothing Stores)
 MCC 5945 (Hobby, Toy, and Game Shops)

Monitoring Program.
Malaysia Visa Issuers
Visa
MCCs:
 MCC 5977 (Cosmetic Stores)
 MCC 7011 (Lodging – Hotels, Motels, Resorts, Central
Reservation Services)
Monitoring Program.
New Visa Issuers An Issuer must participate in both Visa Secure with 3-D Secure 1.0
Zealand and Visa Secure with EMV 3DS, as follows:
 Visa credit20, Visa debit10, Reloadable Prepaid Cards
Visa Ensure that its Electronic Commerce Merchant processes an Electronic
Acquirers Commerce Transaction uses Visa Secure using EMV 3DS if it is
 4722 (Travel Agencies and Tour Operators)
Long Distance Calls, Credit
 Card Calls, Calls through Use of Magnetic Stripe Reading
Telephones, and Fax Services)
 MCC 5310 (Discount Stores)
 MCC 5722 (Household Appliance Stores)
 MCC 5941 (Sporting Goods Stores)
 MCC 9402 (Postal Services – Government Only)
If a Merchant is not enrolled in Visa Secure with EMV 3DS

and is identified by the Visa Fraud Monitoring Program, it
will be subject to the High Risk MCC timeline, as outlined
in the Visa Fraud Monitoring Program.
Mainland Visa Issuers An Issuer must ensure that its Visa Secure program provides a
China dynamic Authentication Mechanism to Cardholders such that the
data elements used in one Transaction cannot be reused in another
Transaction within a pre-defined time frame.
An issuer that fails to comply with the dynamic authentication
requirements in Mainland China will be subject to will be subject to
a non- compliance assessment for each month of non-
compliance
Philippines Visa Issuers
20
This does not apply to Virtual Accounts associated with Visa Commercial Cards
Visa
MCCs:
 MCC 3000-3350 (Airlines, Air Carriers)
Long Distance Calls, Credit Card Calls, Calls through Use of
Magnetic Stripe Reading Telephones, and Fax Services)
 MCC 5977 (Cosmetic Stores)
 MCC 7011 (Lodging – Hotels, Motels, Resorts, Central
Reservation Services)
Monitoring Program.
Singapore Monetary Recommends that dynamic one-time password authentication be
Authority of implemented for all card-not-present e-commerce transactions (Visa
Singapore Secure meets this requirement).
(MAS),
Technology
Risk
Management
Guidelines
Visa Issuers
Visa
Acquires must ensure that its Electronic Commerce Merchant
EMV 3DS1 if it is assigned any of the following MCCs:
 MCC 5815 (Digital Goods Media – Books, Movies, Music)
 MCC 5817 (Digital Goods – Applications [Excludes Games])
 MCC 5818 (Digital Goods – Large Digital Goods Merchant)
 MCC 5968 (Direct Marketing – Continuity/Subscription
Merchant)
 MCC 8999 (Professional Services)
Monitoring Program.
South Visa Issuers
Korea Effective 18 April 2020
Visa

Electronic Commerce Transaction using Visa Secure with EMV 3DS,if it is
 MCC 5968 (Direct Marketing – Continuity/Subscription
Merchant)

Monitoring Program.
Taiwan Visa Issuers
Visa

Electronic Commerce Transaction using Visa Secure with EMV 3DS,if it is
 MCC 4112 (Passenger Railways)
 MCC 7372 (Computer Programming, Data Processing, and
Integrated Systems Design Services)

Monitoring Program.
Thailand Visa Issuers
Visa

 MCC 5968 (Direct Marketing – Continuity/Subscription Merchant)
 MCC 8999 (Professional Services)
Monitoring Program.
Vietnam Visa Issuers
Visa

 MCC 5311 (Department Stores)
 MCC 7994 (Video Game Arcades/Establishments)
Monitoring Program.

Canada
Canada Visa Issuers An Issuer must participate in Visa Secure for Visa Debit Category
Central Europe Middle East and Africa

All Visa Must process Electronic Commerce Transactions using Visa
Countries Acquirers Secure
Visa Issuers
An Issuer that participates in Visa Secure must be capable of
supporting risk-based authentication
Nigeria Visa Issuers Issuers must participate in Visa Secure for all
products Nigerian issuers must:
 Complete the registration process for a ISO BIN before
permitting a Cardholder to perform Electronic Commerce
Transactions
 Ensure that a Cardholder is enrolled in Visa Secure before
authorizing Electronic Commerce
 Authorize only a domestic Electronic Commerce Transaction for
which the Acquirer has requested Visa Secure verification
(except for Transactions processed under the International
Airline Program)
Visa Must not process a domestic Electronic Commerce Transactions unless
Acquirers the cardholder has been successfully authenticated using Visa
Secure
Europe
All Visa Issuers
Countries Effective 14 March 2020
An Issuer must participate in both Visa Secure with EMV 3DS
version 2.1, as follows:
 Visa credit, Visa debit, Visa commercial, Reloadable Prepaid
Cards
Effective 14 September 2020

An Issuer must participate in both Visa Secure with EMV 3DS
version 2.2, as follows:
 Visa credit, Visa debit, Visa commercial, Reloadable Prepaid
Cards
An Issuer that submits Secure Electronic Commerce Transactions must

use Visa Secure.
An Issuer must do all of the following:

 Support a Visa-recognized payment Authentication Method
 Notify its Cardholders of the availability of Visa-recognized
payment Authentication Methods
 Provide a Visa-recognized payment Authentication
Method to a Cardholder upon Cardholder request
 Monitor Electronic Commerce Transactions
This requirement does not apply to Visa Commercial Cards and
Cards bearing the Plus Symbol.
Visa Process Secure Electronic Commerce Transactions using Visa
Acquirers Secure
Latin America
Brazil Visa Issuers
An Issuer must ensure the ISO BIN participates in Visa Secure
 Visa Electronic, Visa debit
B.2 ECI 6 Quality of Service Program
Issuers are not permitted to establish authorization processing criteria in which transactions that are
submitted as attempted authentications (ECI 6) are blanket declined during authorization processing.
This program is intended to manage authorization decline rates on ECI 6 transactions to help
ensure a positive e-commerce experience for cardholders and protect the overall integrity of the
Visa Secure.
This requirement does not apply to Visa products issued under restrictive terms clearly communicated
to the cardholder.
For more information, the Visa Core Rules and Visa Product and Service Rules and
the Visa International Member Letter 09/06.
B.2.1 Program Parameters
An issuer will be identified as out of compliance when both of the following apply:
 Have at least 500 total authorizations for the reporting month.
 Have a decline rate of 50% to 80% (Warning Level) or a decline rate of >80% (Extreme
Warning Level) for transactions coded with an ECI value of 6.
B.2.2 Out of Compliance Severity Levels
The compliance program consists of two levels of identification:

 Level I – Warning (Information) Level – Decline rate between 50% to 80%
The information level is for any issuer that has a decline rate from 50% to 80% for any
given month. If an issuer has a decline rate within this range, Visa may send an
“information level” letter reminding the issuer of the current rules surrounding ECI
6 declines.
 Level II – Extreme Warning Level – Decline rate greater than 80%
The extreme warning level highlights potential non-Compliance with the Visa Secure
rules. Issuers will be notified with a letter requesting that a corrective action or
plan and/or compelling business justification be provided. The issuer will also be reminded
of the penalty schedule if they do not respond with the following:
- (i) an explanation of the high decline rate/business justification,
- (ii) a time schedule to address the high decline rate, or
- (iii) corrective action
B.2.3 Remedial Actions
Visa may take remedial action when an issuer is reported to have met excessive decline rates for ECI 6
transactions, if there is no corrective action or no compelling business justification provided.
The principles in Visa Europe differ from the ones provided here. Visa Europe issuers should
contact their Visa representative for details.
Table B–2: Issuer Non-Compliance Assessments for Excessive Decline Rates (ECI 6)
Violati Visa Action or Penalty
on
First violation of regulation Warning letter with specific date for correction and
USD $15,000 fine
Violati Visa Action or Penalty
on
Second violation of same regulation USD $30,000 fine
in a 12-month period after
Notification of first violation
Third violation of same regulation in a USD $45,000 fine

12-month period after Notification of
first violation
Fourth violation of same regulation in USD $50,000 fine

a 12-month period after Notification
of first violation
Five or more violations of same Visa Discretion

regulation in a 12-month period after
Notification of first violation
B.3 Visa Secure Global Performance Enhancement Program
Visa Secure Global Performance Enhancement program defines issuer standards for “Authentication
Failed” and “Unable to Authenticate” Authentication Responses to reduce excessive or
inappropriate use of the "N", "R", and "U" status codes by issuers and protect the integrity
of Visa Secure.
This appendix will describe the program rules for Issuer ACS on:
 Limits for “Authentication Failed” responses (3DS 1.0.2 – PARes = N OR EMV 3DS -
21
ARes = N or R, or RReq = N or R)
 Limits for “Unable to Authenticate” responses (3DS 1.0.2 – PARes = U OR EMV 3DS ARes
= U or RReq = U)
 Out of Compliance Escalation Process
For more information, see the Visa Core Rules and Visa Product and Service Rules.
B.3.1 Limits for “Authentication Failed” Responses
An Issuer whose ACS meets both of the following criteria is subject to conditions specified by the
corresponding severity level:
21
Includes 3DS Requestor Initiated (3RI) transactions
 Exceeds 500 authentication transactions (i.e., PARes or ARes and RReq messages) for
2 consecutive months.
 3DS 1.0.2
- Exceeds an "N" rate of 5.0% for 2 consecutive months:
o The calculation for “N” transactions includes all eligible transactions in which the merchant
genuinely and legitimately attempted to authenticate the cardholder.
o The calculation is as follows:
[(PARes=N) / [(PARes=Y+N+A+U) + (VERes=N)]
 EMV 3DS
- Exceeds an ["N" + "R”] rate of 5.0% for 2 consecutive months:
o The calculation for ["N" + "R"] transactions includes all eligible transactions in which the
merchant genuinely and legitimately attempted to authenticate the cardholder.
[(ARes=N or R) + (RReq=N or R)] / [(ARes=Y+N+A+U+R) + (RReq=Y+N+A+U+R)]
The actual rate determines the severity level and corresponding issuer and Visa actions to
achieve compliance.
Table B–3: Global “N or R” Policy Requirements
Severity ["N" + "R"] Response Rate
Level
Advice 5.0% to 7.49%
Alert/Warning 7.5% to 9.9%
Extreme Warning 10.0% and Above
B.3.2 Limits for “Unable to Authenticate” responses
An issuer responding to an authentication request with an Unable-to-Authenticate response

(PARes = U OR ARes = U or RReq = U) must do so only under one or more of the
following conditions:
 Issuer experiences technical problems that prevent a timely response.
 Authentication data received from the merchant does not comply with the 3-D
Secure specification.
 Transaction is attempted with a Non-Reloadable Visa Prepaid Card
An issuer whose ACS meets both of the following criteria is subject to conditions specified
by the corresponding severity level:
 Exceeds 500 authentication transactions for 2 consecutive months.
 3DS 1.0.2
- Exceeds an "U" rate of 5.0% for 2 consecutive months:
o The calculation for “N” transactions includes all eligible transactions in which the merchant
genuinely and legitimately attempted to authenticate the cardholder.
[(PARes = U) / (Y+N+U+A+(VERes = N)]
 EMV 3DS
- Exceeds an ["N" + "R”] rate of 5.0% for 2 consecutive months:
o The calculation for ["N" + "R"] transactions includes all eligible transactions in which the
merchant genuinely and legitimately attempted to authenticate the cardholder.
[(ARes=U) + (RReq=U)] / [(ARes=Y+N+A+U+R) + (RReq=Y+N+A+U+R)]
The actual rate determines the severity level and corresponding issuer and Visa actions to
achieve compliance.
Table B–4: Global “U” Policy Requirements
Severity “U” Response Rate
Level
Advice 0.5 % to 0.99%
Alert/Warning 1.0 % to 1.24%
Extreme Warning 1.25% and Above
B.3.3 Out of Compliance Severity Levels
There are three levels of severity:

 Advice—“Advice” levels indicate that an issuer is sending higher-than-expected levels of
“N” responses. Any actions taken (e.g., email notification that levels are higher than average)
are at the discretion of Visa.
 Alert/Warning—“Alert/Warning” levels must be addressed by the issuer within 90 days of
the initial report. The issuer may be required to provide Visa with transaction
reports and a resolution plan to improve performance within 30 days of entering this
status. Failure to do so will result in an automatic escalation to an Extreme
Warning level.
- In cases where an “Alert” is escalated to “Extreme Warning,” the issuer must provide
a resolution plan and implement the plan within 30 days of the escalation
date.
 Extreme Warning—An issuer at the “Extreme Warning” level must provide to Visa a
resolution plan within 60 days of the initial report (or when it enters the “Extreme
Warning” level). The actions defined in the resolution plan must be implemented within
30 days of submission of the resolution plan.
B.3.4 Probation Period
Any issuer that has been notified under this program will remain on probation for a period of 6
months from the date of the initial report. At any time during this probation period, should
the issuer revert to Alert or Extreme Warning status, it will immediately be escalated to
Extreme Warning status, with 30 days to implement changes to address the situation.
Failure to do so will result in escalation to Visa actions for non-compliance described in
the following section.
B.3.5 Failure to Comply
Visa reserves the right to take the following actions when an issuer fails to comply with these
terms,
 Stand in with “Attempts” functionality on behalf of the non-compliant issuer implementation,
with the following terms:
- Issuer will be subject to set-up fees and per-transaction fees related to the stand-in
service
- Issuer assumes liability for the resulting Attempts “A” transactions while it remains in stand-
in status
- Issuer will remain in this status until an agreement for resolution is reached with Visa
 Remove the non-compliant issuer implementation from the service by disconnecting it
from the Visa Directory Server, with the following terms:
- Issuer assumes liability for the resulting transactions while it remains in non-
participation status
- Issuer will remain in this status until an agreement for resolution is reached with Visa
 Levy fines under existing non-compliance rules, as specified in the Visa Core Rules and
Visa Product and Service Rules.
C CAVV Verification Results Code (Field 44.13)
The CAVV Results Code (Field 44.13) identifies whether the CAVV value submitted in the authorization
message passed or failed CAVV verification.
The issuer decides whether the issuer or VisaNet will perform CAVV verification during
authorization for each participating ISO BIN/card range. During CAVV verification, the issuer’s CAVV
keys are used to verify the CAVV.
The CAVV Results Code augments other online risk management transaction data (e.g., Address
Verification Value, CVV2, and Advance Authorization) and is available to the issuer at the time of
authorization decisioning. Issuers are encouraged to develop an authorization strategy that utilizes a
layered risk management approach.
C.1 CAVV Results Codes Summary
The CAVV Results Code (Field 44.13) provides information to enhance the issuer’s authorization
decision. The CAVV Results Code informs the issuer whether:
 CAVV was created by the Issuer ACS, Issuer Attempts Server, or Visa Attempts Server
 CAVV verification passed or failed
The following table provides a high-level overview of this information.

Table C–1: CAVV Results Code (Field 44.13) and Who Created CAVV
Field 44.13
CAVV Created By Value Description
Issuer ACS 122 CAVV verification failed–cardholder authentication
2 CAVV verification passed–cardholder

authentication
D CAVV not verified–cardholder
authentication Process as passed. Issuer
elects to perform CAVV
verification but fails to return CAVV results in F
44.13.
Only Visa generates this code, issuers do not.
Issuer Attempts Server 3 CAVV verification passed–attempted authentication
22
If an issuer approves an authorization request with a failed verification result code, it cannot be charged back.
Field 44.13
CAVV Created By Value Description
4 CAVV verification failed–attempted authentication

2
2
C CAVV not verified–attempted

authentication Process as passed. Issuer
elects to perform CAVV
verification but fails to return CAVV results in F
44.13.
Visa Attempts Server 7 CAVV verification failed–attempted authentication
2
2
8 CAVV verification passed–attempted

authentication Non-participating issuer or
cardholder.
9 CAVV verification failed–attempted

2
2 authentication Issuer ACS was not
available.
A CAVV verification passed–attempted authentication
Issuer ACS was not available.
CAVV Key Type Blank CAVV not

Not Available present OR
CAVV not verified, issuer has not selected
CAVV verification option
0 CAVV could not be

verified OR
CAVV data was not provided when expected.
6 CAVV not verified, issuer not participating in CAVV

verification
Any CAVV Key Type B CAVV passed verification–no liability shift

C.2 CAVV Results Code Values Descriptions
The following table provides definitions of the CAVV Results Codes that issuers can receive in
Field 44.13 along with suggested considerations for how issuers/issuer processors may incorporate
these values into authorization processing.
Table C–2: Field 44.13: CAVV Verification Results Code Values Descriptions
Field 44.13:
CAVV
Results Description Usage Considerations for Authorization
Code Processing
Value
Blank CAVV not MEANING
present in This value means that the authorization message did not
authorization contain any data in Field 126.9. Sample scenarios where this
is expected
message
 Face-to-Face, MOTO, and other non-e-commerce
transactions.
OR
 E-commerce transactions from merchants that do not
yet support Visa’s 3-D Secure program.
SUGGESTED ISSUER ACTION
Use standard authorization criteria, the issuer retains
Dispute rights.
CAVV not MEANING
verified, issuer CAVV is submitted but the issuer’s VisaNet CAVV verification
has not setting has not been set up. Data is present in Field 126.9.
selected SUGGESTED ISSUER ACTION
CAVV Check issuer settings in VisaNet.
verification
option
0 CAVV could not MEANING
be verified Data is present in Field 126.9, but it could not be
verified, when one or more of the sub-fields in Field 126.9
contains an invalid value (e.g., misidentified keys in the
OR CAVV, invalid values, etc.)
Data is present in Field 126.9.
RECEIVED IN THE AUTHORIZATION REQUEST BY
 Issuers that elect to have VisaNet verify the CAVV using
the issuer’s CAVV key pair OR
 Issuers for whom Visa provides support for
attempted authenticated transactions.
RETURNED IN THE AUTHORIZATION RESPONSE BY
 VisaNet OR Issuers that elect to perform CAVV
verification at their processing center.
Confirm that CAVV keys used to generate the CAVV are the
same CAVV keys identified in the CAVV (position 3) and
installed at VisaNet or the Issuer’s Host. Also confirm that
the VisaNet ISO BIN list match those provided to the Issuer’s
ACS and Visa Directory Server.
Field
44.13:
CAVV Description Usage Considerations for Authorization
Results Processing
Code
Value
0 OR (continued) MEANING
(continued) CAVV was required in the message (ECI = 05 or 06)
CAVV data was but the acquirer/merchant did not provide a CAVV.
not provided
when Data is not present in Field 126.9.
expected SUGGESTED ISSUER ACTION
CAVV was not provided by the merchant in the
authorization request. Use standard authorization criteria as
the issuer retains all Dispute rights.
1 CAVV failed MEANING

verification – CAVV verification failed for an authenticated transaction. This is
cardholder an indication of potential bad or fraudulent data submitted
authentication in
Field 126.9 of the authorization message.
CAVV was created by the Issuer’s ACS.
Issuers that elect to have VisaNet verify the CAVV using the
issuer’s CAVV key pair.
VisaNet or issuers that elect to perform CAVV verification
Issuers should consider declining the authorization due to CAVV
verification failed result in the authorization message.
2 CAVV passed MEANING
verification – CAVV authentication was successful for an
cardholder authenticated transaction.
authentication CAVV was created by the Issuer’s ACS.
Issuers that elect to have VisaNet verify the CAVV using the
issuer’s CAVV key pair.
VisaNet or issuers that elect to perform CAVV verification
A valid CAVV indicates that authentication of the cardholder was
successful; apply standard authorization criteria.
Field
44.13:
Results Processing
Code
Value
attempted attempted authentication transaction.
authentication CAVV was created by the Issuer’s Attempts Server.
Issuers that elect to have VisaNet verify the issuer’s attempts
CAVV using the issuer’s CAVV keys.
VisaNet or issuers that elect to perform CAVV verification at
their processing center.
A valid CAVV indicates that the attempted authentication of
the cardholder was successful; apply standard authorization
criteria.
verification – CAVV verification failed for an attempted authentication
attempted transaction. A failed verification result is an indication of
authentication potential bad or fraudulent data submitted in Field 126.9
of the authorization.
CAVV was created by the Issuer’s Attempts Server.
Issuers that elect to have VisaNet verify the issuer’s attempts
CAVV using the issuer’s CAVV keys.
VisaNet or issuers that elect to perform CAVV verification at
their processing center.
Issuers should consider declining the authorization message as
the CAVV in the authorization message failed verification.
5 Reserved Value not used.

Field
44.13:
Results Processing
Code
Value
623 CAVV not MEANING
verified, issuer Possible set up problem—the issuer ACS has started to
not generate CAVV values, but the issuer’s VisaNet CAVV
participating verification setting is not properly set up.
in CAVV CAVV can be created by the Issuer’s ACS, Issuer’s Attempts
verification Server, or Visa Attempts Service
Any issuer that has begun to generate CAVV values in
authentication responses, but has not properly set up their
VisaNet CAVV settings.
VisaNet will process the authorization as if the CAVV is
valid.
This value is only assigned by VisaNet. If the issuer returns
this value in error, VisaNet will process the authorization as if
the CAVV is valid.
The authorization will be processed by VisaNet as having a
valid CAVV for an attempted authentication; the issuer should
consider applying standard authorization criteria.
Issuer should also review their VisaNet issuer identifier
settings to confirm that participating issuer identifiers are
activated with the correct setting, and that the ISO BIN list
match those provided to the Issuer’s ACS and Visa
Directory Server.
23
For Visa use only—Only Visa generates this code, issuers do not.
Field
44.13:
Results Processing
Code
Value
verification – The CAVV verification failed for an attempted authentication
of the authorization message.
CAVV was created by Visa’s Attempts Service
Issuers that elect to receive VisaNet verification results for
Visa’s Attempts Service.
This value is only assigned by VisaNet. If the issuer has
elected to perform CAVV verification and returns this value in
error, VisaNet will process the authorization as if the
CAVV is valid.
Issuers should consider declining authorization message as the
CAVV in the authorization message failed verification.
attempted attempted authentication transaction.
authentication CAVV was created by Visa’s Attempts Service—Non-
participating issuer or cardholder
CAVV is valid.
criteria.
Field
44.13:
Results Processing
Code
Value
verification – CAVV verification failed for an attempted authentication
of the authorization message.
CAVV was created by Visa’s Attempts Service—Issuer ACS was
not available
CAVV is valid.
Issuers should consider declining the authorization message as
the CAVV in the authorization message failed verification.
A CAVV passed MEANING
attempted attempted authentication.
authentication CAVV was created by Visa’s Attempts Service—Issuer ACS was
not available
CAVV is valid.
criteria.
Field
44.13:
Results Processing
Code
Value
B24 CAVV NO LIABILITY SHIFT
passed This value indicates that a valid CAVV was processed but
verification – the transaction does not qualify for Visa’s 3-D Secure
no liability program; apply standard authorization criteria.
shift For example, when the ECI was not 05/06, or card type is a Non-
Reloadable Visa Prepaid Card.
CAVV created by the Issuer’s ACS, Issuer’s Attempts Server, or
Visa Attempts Service
Issuer receives this value when the transaction does not qualify
for Visa’s 3-D Secure program.
This value is only assigned by VisaNet.
If the issuer has elected to perform CAVV verification and
returns this value in error, VisaNet will process the
authorization as if the CAVV is valid.
Use standard authorization criteria.
C25 CAVV was MEANING

not verified The Attempts CAVV was not verified by the issuer even
– through the issuer has elected to verify the CAVV for
attempted authentications.
attempted
authenticatio CAVV was created by the Issuer’s Attempts Server.
n RECEIVED IN THE AUTHORIZATION REQUEST BY
 Not applicable to issuers.
 When an issuer elects to perform Attempts CAVV
verification, but fails to return results values in Field
44.13, VisaNet will generate this value and forward it
to the acquirer in the authorization response
message.
VISA ACTION
VisaNet will treat this authorization as having a valid
CAVV if the issuer has approved the authorization.
24
25
Field
44.13:
Results Processing
Code
Value
D26 CAVV was MEANING
not verified The CAVV for an authenticated transaction was not verified by
– the issuer even though the issuer has elected to verify the
cardholder CAVV.
authenticatio CAVV was created by the Issuer’s ACS.
n RECEIVED IN THE AUTHORIZATION REQUEST BY
 Not applicable to issuers.
 When an issuer elects to perform CAVV verification, but
fails to return results values in Field 44.13, VisaNet will
generate this value and forward it to the acquirer in
the authorization response message.
VISA ACTION
VisaNet will treat this authorization as having a valid
CAVV if the issuer has approved the authorization.
26
D Acronyms and Glossary
D.1 Acronyms
This appendix provides a list of acronyms and a glossary of terms.
Acronym Descripti
on
3DS 3-D Secure
AACS Attempts Access Control Server
ACS Access Control Server
BID Business I.D.
AReq Authentication Request
ARes Authentication Response
ATN Authentication Tracking Number
ISO BIN Issuer Bank Identification Number
CAVV Cardholder Authentication Verification Value
CReq Challenge Request
CRes Challenge Response
ECI Electronic Commerce Indicator
MPI Merchant Plug-in
NPA Non-Payment Authentication
PAReq Payer Authentication Request
PARes Payer Authentication Response
PCI DSS Payment Card Industry Data Security Standard
PReq Preparation Request Message
PRes Preparation Response Message
RReq Results Request Message
RRes Results Response Message

Acronym Descripti
on
SDK Software Development Kit
TLS Transport Layer Security
URL Uniform Resource Locator
VEReq Verify Enrollment Request
VERes Verify Enrollment Response

D.2 Glossary
Term Definition
0-9
3-D Secure (3DS) The Three Domain Secure (3-D Secure™ or 3DS)
Protocol has been developed to improve transaction
performance online and to accelerate the growth of e-
commerce. The objective is to benefit all participants by
providing issuers with the ability to authenticate
cardholders during an online purchase, thus reducing
the likelihood of fraudulent usage of payment cards
and improving transaction performance.
Visa owns 3DS 1.0.2 and licenses it to other
payment providers.
EMVCo owns 3DS EMV 3DS.
Visa’s offering of 3DS is called Visa Secure.
3-D Secure Server (3DS Server) A server or system that the merchant (or third party
on the merchant’s behalf) uses to support Visa Secure
authentication processing.
3DS Server Client Certificate (3DSS The certificate used to secure the channel between the Visa
Client Certificate) Directory Server and the 3DS Server when the Visa Directory
Server sends message to the 3DS Server.
3DS Server Server Certificate (3DSS The certificate used to secure the channel between the
Server Certificate) Visa Directory Server and the 3DS Server when the
3DS Server sends message to the Visa Directory
Server.
3-D Secure Software Development Kit A software component that is incorporated into the
(3DS SDK) merchant’s application to support Visa Secure processing
on behalf of the 3DS Server.
3-D Secure Specification A software protocol that enables secure processing of

transactions over the Internet and other networks.
3DS Requestor The initiator of the authentication request. For the scope
of this document, this is the merchant.
Term Definition
A
Access Control Server (ACS) A server hardware/software component that supports
Visa Secure and other functions. The ACS is operated
by the issuer or the issuer’s processor. In response to Visa
Directory Server inquiries, the ACS verifies that the
individual card account number is eligible for
authentication, receives authentication requests from
merchants, authenticates the cardholder, and provides
digitally-signed authentication response messages
(containing the authentication results and other Visa
Secure data) to the merchant.
Acquirer A member that signs a merchant or payment
facilitator or disburses currency to a cardholder in a cash
disbursement, and directly or indirectly enters the
resulting transaction receipt into interchange.
Acquirer Identifier A 6-digit number assigned by Visa that is used to

identify an acquirer, VisaNet Processor, or Visa
Scheme Processor for Authorization, Clearing, or
Settlement processing.
ACS See Access Control Server.
ACS Client Certificate The certificate used to secure the channel between the Visa
Directory Server and the ACS when the Visa Directory Server
sends messages to the ACS.
ACS Operator ID Visa-assigned ID that identifies the business entity

operating the ACS.
ACS Server Certificate The certificate used to secure the channel between the
Visa Directory Server and the ACS when the ACS sends
messages to the Visa Directory Server.
ACS Service Provider The business entity operating an ACS or attempts

server on behalf of the issuer.
ACS Signing Certificate The certificate used to digitally sign authentication

responses sent from the ACS to a Visa Secure
merchant. Upon receipt, the merchant verifies the
digital signature to ensure that the response was sent
from an authorized ACS.
Term Definition
Attempts Access Control Server (AACS) A server hardware/software component that provides
an attempted authentication response for issuers that
do not have their own ACS. Like the ACS, the AACS
can be operated by the issuer, the issuer’s processor,
or Visa on behalf of the issuer. The AACS does not
provide cardholder authentication but generates an
attempted authentication response and a CAVV that is
sent to the merchant for inclusion in the
authorization message, as proof that authentication
was attempted.
Attempts Functionality The process by which the proof of an authentication
attempt is generated, when payment authentication is
not available.
Attempts Response A message from a Visa Secure issuer or an attempts service
in response to an authentication request, indicating that
the issuer or cardholder is not participating in Visa
Secure.
Authentication See cardholder authentication.
Authentication Data All transaction-related data associated with a Visa

Secure authentication request.
Authentication Request (AReq) A EMV 3DS request for cardholder authentication from
a Visa Secure merchant.
Authentication Response (ARes) A EMV 3DS response from Visa Secure issuer, or Visa on
behalf of an issuer, in response to an authentication
request.
Authentication responses include:
 Attempt Responses
 Unable-to-Authenticate Responses
Authorization A process where an issuer, a VisaNet processor, or
stand-in processing approves a transaction. This
includes offline authorization.
B
Issuing (ISO) Bank Identification A 6-digit identifier assigned by ISO to Visa and then
Number (BIN) licensed by Visa to an Issuer before 22 April 2022 and
that comprises the first 6 digits of an Account
Number.
An 8-digit identifier assigned by ISO to Visa and then
licensed by Visa to an Issuer and that comprises the
first 8 digits of an Account Number.
Business ID (BID) A unique Visa financial institution identification number
assigned by Visa.
Term Definition
C
Cardholder An individual who is issued and authorized to use
either or both a:
 Card
 Virtual Account
Cardholder Authentication The process used to ensure that the transaction is
being initiated by the rightful owner of the Visa
account.
Cardholder Authentication Verification A unique value transmitted in response to an
Value (CAVV) authentication request that provides proof that
authentication or attempted authentication took place on
the transaction.
Certificate An electronic document that contains the public key
of the certificate holder and which is attested to by a
Certificate Authority and rendered unforgeable by
cryptographic technology (signing with the private
key of the Certificate Authority).
Certificate Authority (CA) An entity that issues and manages Digital Certificates for
use with Visa products and services in accordance
with Visa specified requirements. Entities eligible to
be Certification Authorities within the Visa Certification
Authority hierarchy include both:
 Visa
 Visa Members
Challenge Request (CReq) message A EMV 3DS message sent by the 3DS SDK or 3DS Server
where additional information is sent from the cardholder
to the ACS to support the authentication process.
Challenge Response (CRes) message The ACS response to the EMV 3DS CReq message.
It can indicate the result of the cardholder
authentication or, in the case of a merchant application-
based model, also signal that further cardholder
interaction is required to complete the
authentication.
Cryptography The process of protecting information by transforming
it into an unreadable format. The information is
encrypted using a key that makes the data unreadable,
and then decrypted later when the information must be
used again.
Customer Service Representative (CSR) Employees or agents who are responsible for primary
customer support; can be employees of an issuer, acquirer or
merchant.
Term Definition
D
Digital Signature A set of electronic data used to authenticate
parties to a transaction.
Directory Server See Visa Directory Server.
Dynamic Password See One-Time Passcode.
E
Electronic Commerce Indicator (ECI) A value used in an electronic commerce transaction to
indicate the transaction's level of authentication and
security.
F
Failed Authentication A message sent by a Visa Secure issuer in response
to an authentication request that denies cardholder
authentication. Also Authentication Failed or Not
Authenticated.
I
Interoperability Domain The Visa operated systems in Visa Secure that connect
the issuer and acquirer domains. See also
Merchant/Acquirer Domain and Issuer Domain.
Issuer A member that enters into a contractual relationship with a

cardholder for the issuance of one or more card products.
Issuer Domain The systems and functions of issuers and cardholders in

Visa Secure. See also Merchant/Acquirer Domain and
Interoperability Domain.
Issuing Identifier Assigned by Visa and used to define issuing

processing. Multiple issuing (ISO) BINs may use the same
issuing identifier
M
Merchant An entity that accepts a Visa Card for the sale of
goods or services and submits the resulting transaction
to an acquirer for interchange, directly or via a
payment facilitator. A merchant may be a single
merchant outlet or represent multiple merchant
outlets.
Merchant/Acquirer Domain The systems and functions of acquirers and merchants Visa
Secure. See also Issuer Domain and Interoperability Domain.
Term Definition
Merchant Commerce Server A server hardware/software entity that handles all
online transactions and facilitates communication
between the merchant application and the Visa
gateway.
Merchant Server Plug-In A 3DS 1.0.2 module integrated into merchant store-front
applications used to process Visa Secure authentication
transactions. It provides an interface to the merchant
commerce server.
O
One-Time Passcode A one-time passcode is a Visa Secure cardholder
authentication method. It is passcode that the issuer
provides to the cardholder (usually via text or email)
which can be used on one transaction to verify the
identity of the cardholder.
P
Payment Gateway A third party that provides an interface
between the merchant/acquirer’s payment
system and VisaNet.
Payer Authentication Request (PAReq) A 3DS 1.0.2 message sent from the MPI to the Issuer ACS
through the Visa Directory Server to initiate cardholder
authentication.
See "Authentication Request."
Payer Authentication Response The Issuer ACS response to the 3DS 1.0.2 Payer
(PARes) Authentication Request (PARes).
See "Authentication Response."
Preparation Request (PReq) Message The EMV 3DS PReq message is sent from the 3DS Server
to the Visa Directory Server to request information about
the versions supported by available ACSs and, if one
exists, any corresponding 3DS Method URL.
Preparation Response (PRes) Message The EMV 3DS PRes message is the Visa Directory
Server response to the PReq message. The 3DS Server can
utilize the PRes message to cache information about
the versions supported by available ACSs, and if one
exists, about the corresponding 3DS Method URL.
Proof of Attempted Authentication See Attempts Functionality.
R
Results Request (RReq) message A EMV 3DS message sent from the Issuer ACS to
the 3DS Server via the Visa Directory Server to transmit
the results of the authentication transaction.
Term Definition
Results Response (RRes) message The EMV 3DS 3DS Server response to the Results Result
(RRes) message used to acknowledge receipt of this
message.
Risk-Based Authentication Risk-based authentication is a Visa Secure
authentication approach. It may include analyzing
historical data about the cardholder and merchant as
well as taking into consideration the specifics of the
transaction such as the amount or location. The risk
profile is used to determine if authentication is
successful, failed, or if step-up authentication (such as a
one- time passcode) is required. See Step-up
Authentication for additional information.
S
Step-Up Authentication When the issuer supports risk-based authentication and
the results of authentication indicate that further
authentication is required, the issuer can optionally
request additional authentication from the
cardholder such as a one-time passcode. This
additional authentication method is referred to as step-up
authentication.
T
Technology Provider An entity that provides technical services in support of
Visa Secure.
Three-Domain Secure See 3-D Secure.
Transport Layer Security (TLS) A protocol that is designed to secure

processing of transactions over the internet
and other networks.
U
Unable-to-Authenticate Response A message from a Visa Secure Issuer in response to
an authentication request indicating that the issuer is
unable to authenticate the cardholder for reasons other
than those that result in an authentication denial.
Uniform Resource Locator (URL) Global address used for locating resources on the
Internet.
V
Visa Directory Server A server hardware/software entity that is operated by
Visa, whose primary function is to route
authentication requests from merchants to specific
ACSs and to return the results of authentication.
Term Definition
Verify Enrollment Request (VEReq) A 3DS 1.0.2 message sent from the MPI to the Issuer ACS via
the Visa Directory Server to verify that the issuer participates
in Visa Secure and the card is eligible for authentication.
Verify Enrollment Response (VERes) A 3DS 1.0.2 message sent from the Issuer ACS (or Visa Directory
Server on its behalf) in response to a Verify Enrollment Request.
Visa Secure Visa’s implementation of the 3-D Secure 1.0.2 & EMV 3DS
protocols.
VisaNet The systems and services, including the V.I.P. System,
Visa Europe Authorization Service, and BASE II, through
which Visa delivers online financial processing,
authorization, clearing, and settlement services to
members, as applicable.

Visa Secure Program Guide

Uploaded by

Copyright:

Available Formats

Visa Secure Program Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Visa Secure Program Guide

Uploaded by

Copyright:

Available Formats

Visa Secure Program Guide

Visa Supplemental Requirements

© 2015-2020. All Rights Reserved.

THIS PUBLICATION COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL

10-Sep-2020 Visa Confidential i

ii Visa Confidential 10-Sep-2020

Table 1: EMV 3DS Protocol Version Numbers.......................................................................................1

10-Sep-2020 Visa Confidential ii

Figure 1-1: Domains and Components................................................................................. 9

Version 1.4 updates

Change Description Section(s)

10-Sep-2020 Visa Confidential v

This Guide is a global guide intended for Issuers who are:

10-Sep-2020 Visa Confidential 1

2 Visa Confidential 10-Sep-2020

The following references are available to support a Visa Secure implementation.

Other implementation resources include:

Visa Online (VOL)

Version 1.4 updates

Change Description Section(s)

Non- Addition of new non-payment rules Throughout the

1 Visa Secure Program

1.1.1 Authentication vs. Authorization

6 Visa Confidential 10-Sep-2020

Acquirer  Signs up merchants to participate in Visa Secure

Visa  Operates components of the Interoperability Domain for Visa Secure,

This section provides an overview of Visa Secure including:

1.2.1 Domains and Components

Merchant / Acquirer Domain Visa Interoperability Domain Issuer Domain

Merchant’s E-Commerce Software Visa Attempts Service

Acquirer / Acquirer Processor VisaN Issuer / Issuer

The Merchant/Acquirer Domain includes Merchant’s e-commerce checkout, Authentication, and

1.2.2.1 Merchant’s E-Commerce Checkout Environment

1.2.2.2 Authentication Components

1.2.2.3 Authorization Components

1.2.3 Issuer Domain

The Issuer Domain includes Authentication and Authorization components.

1.2.3.1 Authentication Component

1.2.3.2 Authorization Component

1.2.4 Visa Domain

1.2.4.1 Authentication Components

1.2.4.2 Authorization Components

Visa’s authorization component is VisaNet and VisaNet’s CAVV verification service.

1.2.5 Dispute Requirements

1.3 Visa Authentication Data

1.3.1 Electronic Commerce Indicator (ECI)

ECI Value Description

0 Cardholder authentication successful

1.3.2 Cardholder Authentication Verification Value (CAVV)

1.3.3 CAVV Results Code

See Cardholder Authentication Verification Value (CAVV) Implementation Guide or Visa

Transactio Transaction Status

Verify Enrollment Request Y Transaction is eligible N/ N/A

Payer Y Authentication 05 CAVV

Transactio Transaction Status

U Authentication could not be 07 No CAVV

Transactio Transaction Status

Authentication Request Y3 Authentication 05 CAVV Present

Challenge Y Authentication Results of the