3-D Secure Acquirer and Merchant Implementation Guide

Verified by Visa

3-D Secure Acquirer and Merchant
Implementation Guide

April 2004
Visa U.S.A

The enclosed documentation and described technology has been developed and
is owned by Visa. These materials have been distributed and provided to Visa
Members for their internal use. The information in this document applies to
business in the United States only. Any use of disclosure of these materials to
third party vendors or any other entity outside of the Visa membership association
requires that such third party or entity first obtain a license from Visa.
The Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide
License Agreement, which governs such third party, use is available through the
Verified by Visa Overview on the Merchants page
(http://usa.visa.com/business/merchants/verified_index.html).
Disclaimer: This document is intended as an informational tool and should not be relied
upon for marketing, technology, financial or other advice. The information presented is
not intended to advise you of strategies applicable to your specific situation, but rather to
highlight issues for your consideration. Therefore, you should consult your own advisors.
This document contains dated information and may be superseded by subsequent
versions at any time. Visa is not responsible for your use of the document and the
information contained herein, including errors of any kind, or any assumptions or
conclusions that you might draw from its use.

April 2004

Visa *Confidential*

Notice: This document contains Visa’s proprietary information for use by Visa Members’ Visa card programs. Disclosure to third
parties or any other use is prohibited without the prior written permission of Visa U.S.A. Inc.

Verified by Visa
3-D Secure Acquirer and Merchant Implementation Guide

Table of Contents
1

Document Overview................................................................................................................ 1
1.1
1.2

Document Change Control.......................................................................................................................2

1.3

2

Introduction..............................................................................................................................................1

Resources and Tools ................................................................................................................................3

Verified by Visa Service Description..................................................................................... 6
2.1
2.2

Verified by Visa Service Features............................................................................................................9

2.3

Cardholder Activation and Authentication.............................................................................................10

2.4

Attempted Authentications.....................................................................................................................12

2.5

3

Consumer Market Dynamics....................................................................................................................7

Merchant Benefits ..................................................................................................................................13

3-D Secure – Global Payment Authentication.................................................................... 16
3.1
3.2

3-D Secure Service Participants .............................................................................................................17

3.3

4

3-D Secure Three-Domain Model..........................................................................................................16

Transaction Flow....................................................................................................................................19

Transaction Processing – Authentications and Payment Transactions........................... 22
4.1
4.2

Authentication Transaction Processing ..................................................................................................23

4.3

Attempted Authentication Processing ....................................................................................................24

4.4

Electronic Commerce Indicators ............................................................................................................25

4.5

Authorization Processing .......................................................................................................................26

4.6

5

Verify Enrollment Transaction Processing ............................................................................................22

Support for Dispute Resolution Processes .............................................................................................29

Merchant Server Plug-in Functionality .............................................................................. 30
5.1

April 2004

3-D Secure MPI Messages .....................................................................................................................30
Visa *Confidential*

i


Verified by Visa

5.2

6

Additional MPI Functional Requirements .............................................................................................32

Merchant Product Rules and Best Practices ...................................................................... 34
6.1

Acquirer Responsibility for Merchant Participation ..............................................................................34

6.2

Merchant Authentication to Access Visa Directory Server....................................................................34

6.3

Use of Inline Page instead of Pop-Up ....................................................................................................35

6.4

Pre-Authentication Messaging ...............................................................................................................35

6.5

Use of Inline Page ..................................................................................................................................37

6.6

Use of Inline Page with a Framed Window............................................................................................38

6.7

Text for Inline Page with a Framed Window .........................................................................................39

6.9

Activation Anytime................................................................................................................................43

6.10 Failed Authentication Processing...........................................................................................................44
6.11 Merchant Performance Standards ..........................................................................................................45
6.12 Timing between VERes and PAReq ......................................................................................................46
6.13 Expiration/No Re-Use of Authentication Data.......................................................................................46
6.14 Recurring Payments ...............................................................................................................................47
6.15 Online Auctions .....................................................................................................................................47
6.16 Merchant Customer Support ..................................................................................................................47
6.17 Risk Identification Service for e-Commerce..........................................................................................48
6.18 Data Quality in VEReq and PAReq Messages.......................................................................................49
6.19 Pre-Production Implementation Checklist .............................................................................................50

7

MPI Implementation Alternatives....................................................................................... 51
7.1
7.2

8

“Buy or Build” MPI Software Options ..................................................................................................51
Hosted MPI Options...............................................................................................................................53

Merchant Authentication and Transport Security............................................................ 54
8.1

Merchant Authentication........................................................................................................................54

8.2

Transport Security..................................................................................................................................55

April 2004

Visa *Confidential*

ii


Verified by Visa

9

Planning and Implementation ............................................................................................. 56
9.1

Assessment and Preparation...................................................................................................................56

9.2

Merchant MPI Software Selection .........................................................................................................57

9.3

MPI Technical Review...........................................................................................................................58

9.4

Software Installation Planning ...............................................................................................................58

9.5

Software Integration...............................................................................................................................59

9.6

Testing....................................................................................................................................................59

9.7

Pre-Production and Production Launch .................................................................................................60

9.8

Pre-Production Implementation Checklist .............................................................................................62

Appendix A: Glossary ............................................................................................................... 65
Appendix B: Sample Merchant Project Plan .......................................................................... 69
Appendix C: Timeout Sequencing............................................................................................ 70
Appendix D: Authorization Requirements for CPS/ e-Commerce Qualification................ 71
Appendix E: Activation Anytime ............................................................................................. 72
Appendix F: Suggested Procedures for Dispute Resolution .................................................. 78

April 2004

Visa *Confidential*

iii


Verified by Visa

1 Document Overview
1.1

Introduction

Overview

Verified by Visa is an online service designed to make Internet transactions safer
by authenticating a cardholder’s identity at the time of purchase. Verified by
Visa software installed at the Merchant's site activates the cardholder interface
for the authentication process.
Verified by Visa is built upon the technology platform called Three-Domain (3-D)
Secure. The 3-D Secure technical specifications and protocol uses SSL
encryption that is currently supported by the majority of online Merchants. The
3-D Secure framework divides the authentication process according to the
participants involved:
•

Issuer Domain: Issuer and cardholder

•

Acquirer Domain: Acquirer and Merchant

•

Interoperability Domain: Visa-operated systems that connect the Issuer and
Acquirer Domains

Verified by Visa is the brand name used to communicate the online
authentication service to consumers. As noted above, 3-D Secure is the
technology platform for Verified by Visa. The terms Verified by Visa and
3-D Secure may be used interchangeably throughout this document – referring to
the Issuer authentication of cardholders during online purchases for transactions
originated by participating Merchants.
Verified by Visa is a global service and is being implemented worldwide by Visa
Members and Merchants.

Protocol
Version

This document has been updated for 3-D Secure protocol version 1.0.2. The
protocol version 0.7 is no longer supported; all participating merchants must
support version 1.0.2.

Audience

The 3-D Secure Acquirer and Merchant Implementation Guide is intended for
Acquirers and Merchants that are evaluating or have decided to implement
support for Verified by Visa. This Guide explains the Verified by Visa program,
transaction flows, integration of authentication with payment transaction flows,
and the steps required for participating Merchants. Specifically, this Guide can
assist Acquirers and Merchants in understanding:
•
•

April 2004

The functionality, uses, and benefits of Verified by Visa.
The development, testing and production set up of Verified by Visa.

Visa *Confidential*

1


Verified by Visa

1.2

Document Change Control

Product Rule
Changes

This version of the 3-D Secure Acquirer and Merchant Implementation Guide
reflects changes and additions to Visa U.S.A.’s Verified by Visa Product Rules.
Except as otherwise noted, the changes defined below become effective April 15,
2004. Merchants that either had entered production or had began work on their
Verified by Visa implementation prior to April 15, 2004, must comply with the
new and revised Product Rules by June 30, 2004.
Changes to the Product Rules are provided in the table below, and changes to the
Product Rules and Best Practices are highlighted throughout the document in
underlined red text.

Product Rule

Section Reference

“Pop-up” presentations of Verified by Visa are
prohibited.
Merchants must immediately ensure both the GP2 and
eCommerce Visa Root Certificates are installed.
Merchants must configure the MPI with both a
primary and secondary URL for the production Visa
Directory Server by October 1, 2004.

Sections 6.3, 6.5,
6.6, and 6.7
Section 9.7
Sections 5.2 and
9.7

Verified by Visa Merchant Symbol is required on check
out page.
“Pre-Authentication” message is required.

Section 6.4

Inline “framed” implementations must provide a brief
communication to cardholders outside of the frame for
the Verified by Visa Authentication Page.

Section 6.7

Merchants must train customer support staff on
Verified by Visa.

Section 6.16

System monitoring is required.

Section 5.2

Authentication data is considered valid for 90 days
after the date of the Payer Authentication response
returned to the Merchant.

Best
Practices
Changes

Section 6.8

Section 6.13

In addition to Product Rule changes, this version of the 3-D Secure Acquirer and
Merchant Implementation Guide also contains new “Best Practices”, many of
which are drawn from recent Visa usability research with cardholders. While
Merchants are not required to follow these Best Practices, Visa strongly
recommends that Merchants follow these recommendations to ensure the success
of their implementation and the best possible cardholder experience.
New Best Practices are provided below:

April 2004

Visa *Confidential*

2


Verified by Visa

Best Practice

Section Reference

Cardholder is provided a smooth method for
reinitiating the purchase in the event a Verified by Visa
“Failed Authentication” response is received.
Verified by Visa “learn more” Merchant Symbol is
provided on the “Failed Authentication” page.

Section 6.10

“Activate Now” logo is placed on Merchant’s home page
or other cardholder-accessible location.

Section 6.9

For “framed” implementations, navigational links, text,
and icons are kept to a minimum.

Section 6.7

For framed” implementations, a simple status indicator
is provided.

1.3

Section 6.10

Section 6.7

Resources and Tools

3-D Secure
and Verified
by Visa
Documents

Documentation has been developed for Acquirers and Merchants to assist in
understanding the 3-D Secure technology platform as well as Verified by Visa
program information. These support materials are described below.

Verified by
Visa Materials

The following are available to Visa Acquirers and Merchants to assist in Verified
by Visa program development. These materials are available at Visa Online
(www.us.visaonline.com).
Verified by Visa, 3-D Secure Operations Guide for Issuers, Acquirers and
Merchants, Version 1.2, April 2003.
Merchant Materials:
•

•

Verified by Visa Merchant Tool Kit provides the Verified by Visa Merchant
Symbol graphic and usage standards. Merchants can obtain the Tool Kit at
www.visa.com/verifiedmerchants.

•

April 2004

Visa Website (www.visa.com/verifiedmerchants) -- Acquirers and Merchants
can obtain information about Verified by Visa and technology providers who
can provide software that supports Verified by Visa functionality.

The 3-D Secure Technology Provider list is available electronically at
www.visa.com/verifiedvendors.

Visa *Confidential*

3


Verified by Visa

Merchant Risk
Management
Information

The following are available electronically to Visa Acquirers and Merchants to
provide guidance in assuring that risk management requirements are met:
Cardholder Information Security Program, version 5.5, contains
requirements for Merchants to protect cardholder and transaction
information. Information is available at www.visa.com/cisp. Click on “Select
Merchants” or “Merchants.” (See also Production Certificate Request
Documents below.)

•

3-D Secure
Specifications
and Technical
Requirements

•

Electronic Commerce Risk Management Merchant Best Practices defines
business risks and proposed solutions for Merchants conducting secure
commerce. This document is available at:
http://usa.visa.com/business/Merchants/online_risk_management.html.

Copies of these documents are available at:
http://international.visa.com/fb/paytech/secure/main.jsp.
•

3-D Secure Introduction, Version 1.0.2, Visa Publication 70001-01, dated
September 26, 2002

•

3-D Secure System Overview, Version 1.0.2, Visa Publication 70015-01, dated
September 26, 2002

•

3-D Secure Protocol Specification – Core Functions, Version 1.0.2, Visa
Publication 70000-01, revision dated July 16, 2002 with Errata as of January
16, 2003

•

3-D Secure Functional Requirements – Merchant Server Plug-in,
Version 1.0.2, Visa Publication 70003-01, revision dated July 16, 2002 with
Errata as of January 16, 2003

Some 3-D Secure documents are available only to parties that have executed a
3-D Secure Publication Suite Master License Agreement. A click-through
Master License Agreement and licensed documents are available at the Visa
International link above.
The above publications and materials are designed to assist Acquirers and
Merchants in the development and support of 3-D Secure capabilities.

3-D Secure
Compliance
Testing
Documents

Acquirers or Merchants that build or buy 3-D Secure Merchant Server Plug-in
software will need to review the following documents:
•

3-D Secure Compliance Testing Facility – Policies and Procedures, Visa
Publication 70017-01

•

3-D Secure System and Compliance Testing Facility – User Guide, Visa
Publication 70018-01

•

3-D Secure System Test Facility – Policies and Procedures, Visa Publication
70021-01

These documents are also available at:
http://international.visa.com/fb/paytech/secure/main.jsp.

April 2004

Visa *Confidential*

4


Verified by Visa

Product
Integration
Test (PIT)
Facility
Documents

Each Acquirer, Merchant, or designated processing agent (e.g., hosting provider),
operating a Merchant Server Plug-in (MPI), must successfully complete
production readiness testing in Visa’s Product Integration Testing (PIT) facility
prior to moving a new MPI implementation into the production 3-D Secure
environment. Requirements for PIT testing are documented in Visa U.S.A.
Requirements for Pre-Production Readiness via the PIT, available to Acquirers on
Visa Online or by sending a request to VbVMerchants@Visa.com. The following
documentation describing the PIT can be accessed at the PIT Web site at URL:
https://dropit.3dsecure.net/PIT:
•
•

PIT Test Cases

•

Production
Certificate
Request
Documents

PIT User’s Guide

PIT Terms of Service

Each Acquirer, Merchant, or designated processing agent (e.g., hosting provider),
operating a Merchant Server Plug-in (MPI), must obtain and install Verified by
Visa production certificates to be able to connect to the service and successfully
process transactions. The following document, available at Visa Online
(www.us.visaonline.com) or by sending an email to VbVMerchants@visa.com
requesting the document, contains instructions and procedures for obtaining
production digital certificates. The document also provides Product Rules for
CISP Compliance and digital certificate issuance and implementation specific to
third party hosting providers and Internet Payment Service Providers (IPSPs).
An Acquirer who has contracted with a third-party service provider, or uses an
Internet Payment Services Provider (IPSP), to provide Verified by Visa services
to its Merchants must file an Exhibit VV with Visa for the third-party service
provider or IPSP.
Verified by Visa, 3-D Secure Merchant Client Authentication Certificate Requests:
Rules, Instructions, and Forms, July 2003

April 2004

Visa *Confidential*

5


Verified by Visa

2 Verified by Visa Service Description
Introduction

Over the past five years, the Internet has presented new commerce opportunities
to Visa Members and Merchants. Each year, the number of consumers and
businesses that use the Internet for information, browsing, and purchasing has
increased. It is now estimated that over 100 million households have Internet
access.
The U.S. represents, by far, the largest population of Internet users in the world.
The Internet has and will continue to represent a phenomenal environment for
information, communications and commerce. And as consumers become more
acclimated to online shopping, the potential for online Merchants is significant.
Currently, cardholders enjoy the ease and convenience of shopping at Internet
Merchants; however, there is no way for the Merchant to know that a valid
cardholder has made the purchase. As a result, Merchants incur losses due to
fraud. To address this issue, Visa has developed the Verified by Visa service that
enables an Issuer to verify a cardholder’s account ownership during an online
purchase.
Once activated, cardholders can shop at any participating online Merchant using
that card and password. Each time they shop online at a participating Merchant,
cardholders will see a Verified by Visa window, where they authenticate
themselves to their Issuer. After verifying the cardholder’s identity, the Issuer
creates and sends an Authentication Response message to the Merchant,
providing the authentication result during the checkout process.
A change to the Visa International and Visa U.S.A. operating regulations,
effective April 5, 2003, shifted chargeback liability for fraudulent transactions
from the Acquirer and Merchant to the Issuer when a Merchant submits proof
that it was authenticated – or attempted to authenticate – the cardholder in a
Verified by Visa transaction.
Upon receiving the Issuer’s Authentication Response, Merchants follow their
usual commerce procedures. After the Merchant determines the status of the
order fulfillment, a Visa Authorization Request, including the authentication
data required for Verified by Visa transactions, is forwarded to its Acquirer. The
transaction completes via traditional payment processing through VisaNet with
authorization, clearing and settlement.
With Verified by Visa, cardholders have more confidence buying over the
Internet. Issuers, Acquirers, and Merchants are expected to enjoy increased
online transaction volumes and reduced exposure to fraud.

April 2004

Visa *Confidential*

6


Verified by Visa

2.1

Consumer Market Dynamics

Introduction

Even with the strong growth trends over the past several years, there remain
many Internet users that have not yet tried online shopping. As consumers gain
confidence with the Internet, there are significant additional sales to be
generated.

Internet
Accessed by
High
Percentage of
Consumers

The Internet continues to grow in importance – it is now widely accessed by U.S.
consumers for information and commerce. The UCLA Center for Communication
Policy has conducted a multi-year study of Internet usage in the United States,
called The UCLA Internet Report – Surveying the Digital Future, Year Three. The
results for 2002, the third year of the report, were released January 31, 2003.
Key findings included:
•

More than 70 percent of Americans in 2002 went online, up from 67 percent
in 2000, the first year of the UCLA Internet Project.

•

The number of hours online continued to increase – rising to an average of
11.1 hours per week in 2002, up from 9.8 hours in 2001 and 9.4 hours in
2000.

•

Almost 60 percent of users have Internet access at home, a substantial
increase in only two years from the 47 percent of users who reported home
Internet access in 2000.

In addition to online access, shopping represents a key activity for Internet users.
As shown in the chart below, approximately 40 percent of Internet users made a
purchase online in 2002.

70%
60%
50%
40%
30%

70%
60%
% of
U.S. Pop.
Online

20%
10%

% with
Internet
Access
at Home

40%
% of
Internet
Users
Shopped

0%
Source: The UCLA Internet Report – Surveying the Digital Future, Year Three. Copies of this and
prior year reports are available for download at no charge at: www.ccp.ucla.edu.

Figure 1. Internet Access and Usage Profile in 2002 – U.S. Households

April 2004

Visa *Confidential*

7


Verified by Visa

Security of
Payment Card
Information Is
Key Concern

While the Internet has grown as a key channel for communication and shopping,
consumer security concerns regarding the use of payment cards for purchases
have shown little change over the past several years.
The UCLA Internet Report – Surveying the Digital Future reported on consumer
concerns relative to payment card security on the Internet. Over the past three
years of the study, a very high percentage of consumers reported being
“Extremely Concerned” or “Very Concerned” regarding card security when buying
online. From 2000, 2001 and 2002, these concerns were reported by 91%, 92%
and 94% of survey respondents, respectively. These results are shown in the
graph on the left below.
Both new and experienced Internet users expressed security concerns making
purchases online. In 2002, 79 percent of new Internet users and 48 percent of
experienced Internet users indicated that they were Extremely or Very
Concerned about the security of their payment card information when buying
online. These results are shown in the graph below on the right.
Security Concerns of New and Experienced
Internet Users – Year 2002

Level of Concern regarding Online Card
Security over Past Three Years
100%

100%
80%

61.7%

71.3%

59.5%

63.3%
60%

60%

23.0%

40%

40%
20%

25.2%

80%

19.1%

29.5%

23.1%
8.8%

2000

29.1%
7.6%

5.5%

0%

20%

2001

42.6%

16.6%

0%

2002

New Users
(<1 Year)

Extremely or Very Concerned
Somewhat Concerned
Not At All Concerned

Extremely Concerned
Very Concerned

Experienced Users
(6 or More Years)
Somewhat Concerned
Not At All Concerned

Source: The UCLA Internet Report – Surveying the Digital Future, Year Three.

Figure 2. Consumer Concerns for Online Card Security – UCLA Internet Report, 2002

April 2004

Visa *Confidential*

8


Verified by Visa

Recap –
Consumer
Market
Potential

Even with the dramatic growth in Internet commerce, there are underlying
security concerns that have limited consumers’ willingness to make purchases
online. Numerous research studies have noted that security concerns are
predominant – one of the top issues cited when consumers are asked to name
barriers to making more online purchases.
Of course, payment security is not the only concern or issue cited by consumers
as a barrier to making more purchases online. It is clear, however, that a better
process is needed to protect consumers so that unauthorized usage cannot take
place as well as to protect Merchants from fraudulent purchases. The Verified by
Visa service has been developed to meet this market need.
By participating in Verified by Visa, Merchants can leverage the consumer desire
for more security for when shopping online. By displaying the Verified by Visa
logo on their commerce site, Merchants can proactively reinforce the added
security available to consumers by shopping at their online store.
The next sections provide a description of the Verified by Visa service, including
the 3-D Secure model, service features and how transactions flow.

2.2

Verified by Visa Service Features

Support for
All Visa Card
Types

Verified by Visa is designed to support the broad base of Visa cards currently
offered by Visa card Issuers. These include:
•

Magnetic Stripe Visa Cards. Verified by Visa supports standard, magnetic
stripe Visa cards. It’s easy for cardholders to participate – all they need is
access to a PC with one of several widely used Internet browsers.

•

Smart Visa Cards. Issuers are able to support cardholders that have a chip
card, a smart Visa card, by offering cardholders an enhanced level of security
for Internet shopping. They provide cardholders with a smart card reader
and PC software that operates the reader. Smart cards allow Issuers to
authenticate both the cardholder (by validating the password or other code)
and the card (by communicating with the card and validating the smart Visa
card cryptogram).
There are no additional requirements for Merchants when a cardholder uses
a smart Visa card. The Issuer server returns an Authentication Response
message the same as if the cardholder was not using a smart card.

April 2004

Visa *Confidential*

9


Verified by Visa

2.3

Cardholder Activation and Authentication

Overview

Verified by Visa enables real-time cardholder authentication by participating
Issuers. With authentication, an Issuer ensures that the presenter of the card is
authorized and entitled to use the card. Online purchases are authenticated
when the cardholder correctly enters the information requested by the Issuer and
the Issuer ACS returns an Authentication Response to the Merchant.
Cardholders may activate their Visa cards in a number of ways. They can visit
the Verified by Visa site at Visa.com and be directed to their Issuer’s web site for
enrollment. They can enroll using Activation Anytime, a service that is designed
to enable Issuers to activate cardholders at various Internet sites, including
participating Merchants, using Verified by Visa banners or buttons. The Issuer
may also pre-enroll their cardholders to enable authentication and activation
during a transaction. Market research has shown the importance of the Verified
by Visa and Issuer’s brand identities in creating cardholder confidence to proceed
with the authentication while shopping online.
Shown below in Figure 3 are sample user interface pages that cardholders may
see from their Issuers. All Issuers and their ACS Processors are required to
adhere to the standards and requirements. After the cardholder selects the “buy”
button at the Merchant’s checkout page, the cardholder is presented with a
Verified by Visa page from the Issuer’s ACS. On the left below, the cardholder is
authenticated by entering their personal password. On the right, the cardholder
is authenticated by entering identity data and is activated in Verified by Visa.

Cardholder Enters Personal Password

Cardholder Enters Authentication Data

Figure 3. Sample User Interface for Cardholder Activation
In both cases above, the Issuer ACS returns an Authentication Response to the
Merchant. If the cardholder clicks “Do Not Activate Now”, the ACS returns an
Attempts Response to the Merchant. This response message includes the
April 2004

Visa *Confidential*

10


Verified by Visa

authentication data (Electronic Commerce Indicator, ECI, and Cardholder
Authentication Verification Value, CAVV) for submission with the Authorization
Request.

Issuer
Activation
Site

An individual cardholder may also be activated in response to Issuer
communications or advertising by visiting the Issuer’s website. The cardholder is
asked for personal information that allows the Issuer to complete cardholder
authentication, such as, name, address, and other identity information. For
example, a cardholder may visit one of following:
•

www.visa.com/verified, where the cardholder is directed to the Issuer’s online
website for information and activation.

•

The Issuer website, where the cardholder provides all required
authentication information, and then selects a password and personal
message.

•

The Issuer’s online banking website, where the cardholder may opt to
participate in Verified by Visa, agrees to use the existing online banking
password, and selects a personal message.

At the Issuer’s option, the cardholder may be asked to provide a password hint or
user ID, in addition to a password and personal message.

Figure 4. Issuer Activation Website
When the cardholder initiates activation:
Step 1.
Step 2.

The Issuer Server sends the cardholder information to the Issuer for
comparison with Issuer records.

Step 3.

April 2004

The cardholder visits the Issuer’s Activation Website and enters the
requested authentication information.

The Issuer confirms the cardholder’s identity and forwards an
activation record to the ACS for authentication during online purchases.
Visa *Confidential*

11


Verified by Visa

2.4

Attempted Authentications

Overview

Some Issuers may elect not to participate or some cardholders may not
participate in Verified by Visa. To ensure that participating Merchants are
provided with the required proof of an attempted authentication, either the
Issuer ACS or Visa (for non-participating Issuers and for stand-in processing if
an ACS is not operational) will return an Attempt Response. These transactions
provide the participating Merchant with chargeback protection when the
subsequent Authorization Request includes the required data. The customer
experience for cardholders is shown in Figure 5 below.

Figure 5. Attempted Authentication Processing Page
The processing for attempted authentications has no cardholder interaction. A
“Processing” window (shown above) is briefly displayed while the Attempt
Response is processed by the ACS and returned to the Merchant.
When the Verified by Visa Merchant receives the Attempt Response, the message
will have ECI and CAVV values for inclusion in the Authorization Request. As
noted earlier, these data elements must be included in the Authorization Request
for the Merchant to qualify for chargeback protection.

April 2004

Visa *Confidential*

12


Verified by Visa

2.5

Merchant Benefits

Overview

In an e-commerce environment, as with mail and telephone orders, the purchase
is a card-not-present transaction. Accepting payment cards for online payment
presents a variety of challenges for Merchants that include the following:
•

Cardholder reluctance to purchase goods and services via the Internet
because of the perception that online purchasing is not secure.

•

Chargebacks of purchase transactions to online Merchants and increased
exception item processing that impacts profitability.

•

Fraud by unauthenticated cardholders that affect Merchants.

Verified by Visa addresses these issues and may provide benefits for Acquirers
and/or Merchants as highlighted in the following sections.

Increased
Security and
Revenue
Growth

Consumer research suggests that payment card security concerns present
significant barriers to online purchasing and that improved security will be a key
motivator for increasing online purchasing. By improving online security,
cardholders who currently browse the Internet will become more confident
purchasers, thus, possibly increasing sales volume for participating Merchants.
Verified by Visa can assist revenue generation in the following ways:
•

Cardholders may see the names of participating Merchants at Visa.com as
well as see the Verified by Visa symbol at Merchant sites. This will
encourage cardholders to bookmark these sites for future purchases.

•

Visa and Issuers have undertaken consumer education to reinforce the
message that participating Merchants offer a more secure purchasing
environment for consumers.

In the third quarter of 2002, Visa conducted a market research tracking study.
Consumers that own and use payment cards were asked about Verified by Visa.
Respondents indicated that they would feel more comfortable with online
shopping, more likely to shop at Merchants that offer Verified by Visa and more
likely to spend more online. The survey are shown below:
Consumers Prefer Payment Card with Verified by Visa
Consumer Respondents Say Verified by Visa
Would Make Them:

% of Respondents

More comfortable with online shopping

77%

More likely to shop at sites that offer Verified by Visa

71%

Likely to spend more online with Verified by Visa

37%

* % of respondents indicating they “Strongly Agree” or “Agree”; 3Q 2002 Visa Tracking Study.

April 2004

Visa *Confidential*

13


Verified by Visa

Fraud
Reduction

When a purchase transaction fails the authentication process, the Merchant is
alerted to the possibility of a potential fraud situation. The Merchant must not
submit the purchase for authorization if the authentication fails and instead ask
the cardholder to use another form of payment. Verified by Visa helps reduce the
fraudulent use of Visa cards at participating Merchants.

Chargeback
Protection

Participating in Verified by Visa provides protection for both authenticated and
attempted authentication transactions, as described below:
•

Authenticated Transactions. Since Issuers authenticate cardholders’
identities during Verified by Visa transactions, the following chargeback
reason codes do not apply to successfully authenticated transactions:
23 – T&E Invalid Transaction
61 – Fraudulent Mail/Phone/e-Commerce Transaction
75 – Cardholder Does Not Recognize Transaction
83 – International Cardholder – Fraudulent Purchases

•

Interchange
Benefit

April 2004

Attempted Authentication Transactions. If a participating Merchant
attempts to authenticate a cardholder, and either the Issuer or cardholder is
not participating in Verified by Visa, the Merchant is provided with
protection from chargebacks for the same reason codes as shown above for
authenticated transactions. Merchants must properly process the 3-D Secure
Authentication Request and Visa Authorization Request to qualify for
chargeback protection. These requirements are described more fully in the 3D Secure Operations Guide for Issuers, Acquirers and Merchants.

Transactions that qualify for Custom Payment Service (CPS)/e-Commerce
Preferred Retail Credit, and effective January 31, 2004, CPS/e-Commerce
Preferred Retail Debit, will be processed with an interchange rate that is five
basis points less than CPS/e-Commerce Basic. CPS-e-Commerce Preferred
includes authenticated and attempted authenticated transactions while CPS/eCommerce Basic includes standard electronic commerce transactions. Only
Merchants that support Verified by Visa are eligible to qualify transactions for
CPS/e-Commerce Preferred. Merchants should check with their Acquirer for
additional information.

Visa *Confidential*

14


Verified by Visa

Reduced
Operational
Expense

Losses from fraud, customer service costs, and back office costs associated with
dispute/chargeback processing can be significant expenses Acquirers and
Merchants. Even when chargebacks are successfully represented, exception item
and dispute processing are costly. The reduction in fraud and operating expenses
associated with these chargebacks is expected to improve the bottom line for
Acquirers and Merchants. When Acquirers forward a valid Cardholder
Authentication Verification Value (CAVV) and Electronic Commerce Indicator
(ECI) in a properly formatted Visa Authorization Requests for authentications
and attempted authentications, the transactions may qualify for automated
blocks on U.S. Chargeback Reason Codes 23, 61 and 75, eliminating the
operational expense of those disputes.
Verified by Visa addresses the majority of disputes that apply to electronic
commerce purchases. An analysis of all chargeback reason codes for U.S.
Acquirers and Merchants shows that 66% were for the U.S. and international
reason codes impacted by Verified by Visa (23, 61, 75 and 83) where the
cardholder disputes having the purchase – these are the “fraud-type” disputes. If
a transaction is a properly processed authentication or attempted authentication,
the Issuer may not submit the chargeback.

Non-US Cardholder
Disputes Making
Purchase
16%
U.S. Cardholder
(Reason
Disputes
Code 83)
Making Purchase
50%
(Reason Codes
All Other
23, 61 and 75)
Disputes
34%

Total Chargebacks
Reason Codes:
23
61
75
83
All Other
Total

1%
42%
7%
16%
34%
100%

Source: VisaNet System Chargebacks, U.S. Acquirers, June 2003

Figure 6. e-Commerce Chargeback Dollars by Reason Code

Data Quality

April 2004

Based on data required for authenticated purchase transactions, the integrity of
the authorization transaction and the related authentication can be validated.
Merchants forward designated authenticated data elements that provide proof
that the Issuer authenticated the cardholder or that the Merchant attempted to
authenticate the cardholder. Through validation of the CAVV value, Issuers and
Acquirers/Merchants have the assurance that the results of the authentication
process have not been altered, providing a link between authentication,
authorization and clearing and settlement. Acquirers/Merchants receive the
CAVV validation results in the Visa Authorization Response so this information
is available for dispute resolution.

Visa *Confidential*

15


Verified by Visa

3 3-D Secure – Global Payment Authentication
Introduction

3.1

This chapter provides an overview of the Verified by Visa service and a high level
review of the 3-D Secure technology components.

3-D Secure Three-Domain Model

Overview of
3-D Secure

Visa has developed the Three Domain Model of payment systems as the basis of
new payment solutions. The model divides payment systems as follows:
•

Issuer Domain. Systems and functions of the Issuer and its customers
(cardholders).

•

Acquirer Domain. Systems and functions of the Acquirer and its customers
(Merchants).

•

Interoperability Domain. Systems, functions, and messages that allow Issuer
Domain systems and Acquirer Domain systems to interoperate worldwide.

Figure 7 provides a simple illustration of the participants in their associated
domains.

Issuer Domain

Interoperability

Domain

CA
RDHOLDER

Acquirer Domain
MERCHA
NT

ISSUER
A
CQUIRER

Figure 7: Three-Domain Model

April 2004

Visa *Confidential*

16


Verified by Visa

3.2

3-D Secure Service Participants

Overview

This section describes entities that participate in the 3-D Secure service, by
domain.

Issuer
Domain

Cardholder

The cardholder shops online, providing shipping and
payment card information, then indicates readiness to
finalize the transaction. In response to the Purchase
Authentication Page, the cardholder provides information
needed for authentication, such as a password or identity
information.

Cardholder
browser

The cardholder browser acts as a conduit to transport
messages between the Merchant Server Plug-in (in the
Acquirer Domain) and the Access Control Server (in the
Issuer Domain).

Issuer

A Visa Member financial institution that:
•
•

Determines the cardholder’s eligibility to participate in
the 3-D Secure service.

•

Defines card number ranges eligible to participate in
the 3-D Secure service and specifies those card number
ranges to the Visa Directory Server.

•
Access Control
Server

Enters into contractual relationships with cardholders
for issuance of one or more Visa cards.

Performs activation of cardholders for Verified by Visa.

The Access Control Server (ACS) has several functions:
To verify whether 3-D Secure authentication (or proof
of attempted authentication) is available for a
particular card number

•

To respond to Verify Enrollment and Payer
Authentication messages originated by participating
Merchants.

•

April 2004

•

To forward copies of Authentication Responses to the
Visa Authentication History Server.

Visa *Confidential*

17


Verified by Visa

Merchant

Existing Merchant software handles the shopping
experience, obtains the card number, and then invokes the
Merchant Plug-in to conduct payment authentication.
After payment authentication, the Merchant software may
submit a Visa Authorization Request to the Acquirer, if
appropriate, or forward authorization data to the Acquirer.

Merchant Server
Plug-in

The Merchant Plug-in (MPI) creates and processes
payment authentication messages, then returns control to
the Merchant software. As part of processing the
Authentication Response message from the Issuer, the MPI
validates the digital signature in the Authentication
Response message.

Acquirer

Acquirer
Domain

A Visa Member financial institution that:
•

Enters into a contractual relationship with a Merchant
for purposes of accepting Visa cards.

•

Determines the Merchant’s eligibility to participate in
the 3-D Secure service.

•

Requests Merchant Certificate for Merchant’s
commerce server, if applicable.

Following payment authentication, the Acquirer performs
its traditional role:
•
•

Visa Directory
Server

Provides Authorization Responses to the Merchant.

•

Interoperability
Domain

Receives Visa Authorization Requests from the
Merchant and forwards to VisaNet
Submits the completed transaction to the VisaNet
settlement system.

The Visa Directory Server, operated by Visa:

Directs the request for cardholder authentication to the
appropriate ACS.

•

April 2004

Receives messages from Merchants for a specific card
and determines whether the card number participates.

•

Commercial
Certificate
Authority

•

Receives the response from the ACS and forwards the
response to the Merchant.

Generates SSL/TLS encryption certificates used to secure
communications between the Merchant and cardholder’s
browser. These are the standard SSL/TLS certificates used
for secure connectivity with browsers.
Visa *Confidential*

18


Verified by Visa

Interoperability
Domain

Visa Brand
Certificate
Authority

Generates selected certificates for the use of 3-D Secure
entities, including:
•

SSL server certificate that Merchants must use to
contact the Visa Directory Server; this certificate is
signed by the Visa Root Certificate.

•

Visa Root Certificate – Merchant software must
support a copy of this certificate for purposes of
validating the Issuer signature returned in
authentication response messages.

(continued)

Authentication
History Server

The Authentication History Server (AHS), operated by
Visa:
•

Receives a message from the ACS for each attempted
payment authentication

•

Stores the records received

A copy of the data stored by the AHS is available to
Acquirers and Issuers in case of disputes.
VisaNet

Following payment authentication, VisaNet performs its
traditional role:
•

Receives Authorization Requests from Acquirers.

•

Performs CAVV validation, if applicable.

•

Forwards Authorization Requests to the Issuer.

•

Provides Authorization Responses to Acquirers.

•

Provides clearing and settlement services to the
Acquirer and Issuer.

Through the interaction of the Acquirer and Issuer Domains, as facilitated by the
Interoperability Domain, cardholder purchases are authenticated by Issuers,
providing enhanced security for Internet payments to Merchants and cardholders
alike.

3.3

Transaction Flow

Overview

April 2004

Once activated, the cardholder is authenticated during each online purchase at a
participating Merchant. The cardholder visits a participating Internet Merchant
site, selects goods or services, and proceeds to the checkout page. The cardholder
may complete the checkout information in one of a variety of ways – for example,
self-entered, electronic wallet, or Merchant one-click. The cardholder initiates a
purchase transaction, as described below and illustrated in Figure 8.

Visa *Confidential*

19


Verified by Visa

Transaction
Steps

Step 1.

The cardholder completes the purchase by pressing the Buy or Submit
button. This activates the Merchant Plug-In (MPI) and initiates a
Verified by Visa transaction.

Interoperability Domain

Issuer Domain
CARDHOLDER

MERCHANT

1
6

Plug-in

10

11

9

7

Acquirer Domain

2

8
5

Access
Control

4

9

12

Visa
Directory

3

Authentication
History

Issuer

Acquirer

VisaNet

Figure 8. 3-D Secure Transaction Flow
Step 2.

The MPI identifies the card number and sends it to the Visa Directory
Server to determine whether the card is in a participating card range.

Step 3.

If the Issuer is participating for the card range, the Visa Directory sends
a Verify Enrollment Request message to the Issuer ACS to determine
whether authentication is available for the account number.
Continued on next page

April 2004

Visa *Confidential*

20


Verified by Visa

Transaction
Steps
(continued)

Step 4.

The ACS returns a Verify Enrollment Response to the Visa Directory
•

If authentication is available for this card number, the response
provides the URL of the ACS where the cardholder can be
authenticated.

•

If authentication is not available, the Merchant server receives a
Cardholder Not Enrolled or Authentication Not Available message
and returns the transaction to the Merchant’s commerce server to
proceed with a standard transaction processing.

Step 5.

The Visa Directory forwards the ACS response to the MPI.

Step 6.

The MPI sends an Authentication Request message to the cardholder’s
browser for routing to the ACS.

Step 7.

The cardholder’s browser passes the Authentication Request to the ACS.

Step 8.

The ACS authenticates the cardholder, as described in the Cardholder
Activation section.

Step 9.

The ACS creates, digitally signs, and sends an Authentication Response
to the Merchant via the cardholder’s browser. The ACS also sends
transaction record to the Authentication History Server for storage.

Step 10. The browser routes the Authentication Response back to the MPI.
Step 11. The MPI validates the digital signature in the response, verifying that it
is from a valid participating Issuer.
Step 12. The Merchant formats and sends to its Acquirer a Visa Authorization
Request message, which includes information from the Issuer’s
Authentication Response—including the CAVV and the ECI.
The Acquirer passes the Authorization Request to VisaNet and the
transaction completes through standard VisaNet processing.

April 2004

Visa *Confidential*

21


Verified by Visa

4 Transaction Processing – Authentications and
Payment Transactions
Introduction

This chapter describes how Verified by Visa authentication data is incorporated
in payment processing that Acquirers and Merchants support for authorization
and settlement of Visa transactions.
Note: Processing and contractual arrangements pertaining to authorization and
settlement can vary across several parties. This chapter generally describes the
activities and requirements that Acquirers and Merchants and payment
gateways, and/or commerce server providers are responsible for support of
Verified by Visa.

4.1

Verify Enrollment Transaction Processing

Verify
Enrollment
Response by
ACS

The MPI forwards a Verify Enrollment Request to the Visa Directory Server to
determine if the account is eligible for authentication processing. When the
Issuer ACS receives a Verify Enrollment Request, the ACS responses are shown
below.
When a Y response is received in the VERes, the Merchant
forwards a Payer Authentication Request to the ACS URL
included in the response.

N = Card eligible
for attempts
liability, but
attempts proof is
not be available
from the Issuer

Merchant proceeds with the purchase as an attempted
authentication, submits an ECI of 6 in the Visa
Authorization and leaves the CAVV blank. The Issuer may
not submit a chargeback if the cardholder later disputes
the purchase.

U = Unable to
process or card not
eligible for
attempts (e.g.,
Commercial Cards)

April 2004

Y = Card eligible
for authentication
processing

Merchant proceeds with purchase as non-authenticated
and submits authorization with ECI 7. The
Acquirer/Merchant retains liability if the cardholder later
disputes making the purchase.

Visa *Confidential*

22


Verified by Visa

4.2

Authentication Transaction Processing

Payer
Authentication
Response
Processing

Upon receiving a VERes of Y, the Merchant forwards a Payer Authentication
Request to the Issuer ACS. The ACS interfaces with the cardholder and
determines the action to communicate to the Merchant. The response codes are
inserted in the “Transaction Status” field of the PARes message. The ACS
responses are shown below:
Y = Authentication
approved

The Issuer has authenticated the cardholder by verifying
the identity information or password. The ACS returns a
CAVV and an ECI of 5 in the Authentication Response.

A = Authentication
attempted

Cardholder is not enrolled and has Merchant attempted
authentication. The ACS returns a CAVV and an ECI of 6
in the Authentication Response.

U = Unable to
authenticate

The Issuer ACS is not able to complete the authentication
request – possible reasons include:
•

Authentication request mis-routed to the wrong ACS.

•

ACS is not able to establish an SSL session with
cardholder browser.

•

System failure that prevents proper processing of the
authentication request.

•

Card type is excluded from attempts (Commercial Card).

Merchants may proceed with the above purchases as nonauthenticated, using an ECI of 7 in the authorization
message, and retain liability if the cardholder later disputes
making the purchase. These are standard e-commerce
transactions. The ACS does not return a CAVV.
•

N = Authentication
failed

When the PARes has a U and an Invalid Request Code
of 55, this indicates that the Account Identifier in the
PAReq did not match the value returned by the ACS in
the VERes. Merchants should view this as an invalid
transaction.

The Issuer is not able to authenticate the cardholder. The
following are reasons to fail an authentication:
•

Cardholder fails to correctly enter the authentication
information within the Issuer-defined number of entries
(possible indication of fraudulent user).

•

Cardholder “cancels” authentication page (possible
indication of a fraudulent user).
Merchants are not permitted to submit these transactions
for authorization processing. The ACS does not return
CAVV or ECI values in the Failed Authentication

April 2004

Visa *Confidential*

23


Verified by Visa

4.3

Attempted Authentication Processing

VERes
Processing for
Attempted
Authentication
Transactions

For U.S. Transactions, Visa provides authentication responses when a
participating Verified by Visa Merchant attempts to authenticate a cardholder, if
either the cardholder or the Issuer does not yet participate in Verified by Visa.
The Directory Server forwards the transaction to the Visa Attempts Server,
which will return a Y in the VERes message.
For International Transactions, non-U.S. Issuers may optionally support
responses to attempted authentications as described above, returning a Y in the
VERes message. Other non-U.S. Issuers, especially those not yet participating
in Verified by Visa, will not have the capability to support attempts responses.
In these transactions, participating Merchants will receive a VERes response of
N for non-enrolled cardholder or non-participating Issuer. For these
transactions, the Visa Authorization Request is submitted with an ECI of 6,
leaving CAVV blank. VisaNet recognizes the Issuer as non-U.S. and permits
these transactions to qualify for CPS/e-Commerce Preferred even though there is
no CAVV included in the authorization.

PARes
Processing for
Attempted
Authentication
Transactions

For attempted authentications, the ACS will return an A in the PARes response.
The PARes includes a CAVV value and ECI of 6. Both of these authentication
data elements are submitted in the Visa Authorization Request; enabling the
transaction to qualify for CPS/e-Commerce Preferred, providing the Merchant
with protection from fraud-type chargebacks.

Exclusions
from Attempts
Processing

The Visa Operating Regulations provide several types of transactions that are
excluded from requirements for attempted authentications:
•

Excluded Card Types – Two card types, Commercial Cards and anonymous
Prepaid Cards, are excluded from requirements for attempted
authentications on non-enrolled cardholders. The Visa Attempts Server will
verify that the BIN is in the Directory Server Excluded File and return U in
the Verify Enrollment Response to the Merchant to communicate that
attempted authentications do not apply.

•

New Channel Devices – Transactions originated with designated new
channel devices types, such as mobile or wireless devices.

•

Merchants in Global Merchant Chargeback Monitoring Program are not
permitted to process attempted authentication transactions.

The VERes response for these transactions will be a U to indicate that the
transaction is not eligible for attempts processing. These transactions are
standard electronic commerce and are submitted in the Visa Authorization
Request with an ECI of 7 as CPS/e-Commerce Basic.

April 2004

Visa *Confidential*

24


Verified by Visa

4.4

Electronic Commerce Indicators

ECI Values
and
Authorization
Processing

The Electronic Commerce Indicator (ECI) must be set to a value corresponding to
the level of security and type of authentication for a transaction. The merchant
transmits data for the Visa Authorization Request message, including the ECI,
to the Acquirer or its processor.
Possible ECI data values are:
•
•

ECI 6 = Authentication attempted by Merchant. The value should be
returned by the ACS in the in the PARes message for an Attempt Response.
Additionally, merchants may use an ECI 6 in the Authorization Request
when a VERes of N is received from the Visa Directory Server for Issuer or
cardholder not participating.

•

ECI 7 = Merchant used SSL for obtaining cardholder payment information,
but payment authentication was not performed. An ECI 7 applies when the
VEReq or PAReq of U for Unable to Authenticate.

•

Determining
ECI Values

ECI 5 = Cardholder authenticated by the Issuer. This value should be
returned by the ACS in the PARes message.

ECI 8 = A non-secure channel was used by the Merchant when obtaining
cardholder payment information.

Table 1 summarizes the various VERes and PARes transactions and the related
ECI values for inclusion in Visa Authorization Request.

Response Code

ECI

Meaning

Verify Enrollment Response Codes
Y = Card eligible
for authentication
processing

NA – the ECI is
determined by the
PARes message

N = Card eligible
for attempts
liability, but
attempts proof will
not be available

ECI of 6

April 2004

Merchant forwards PAReq to ACS and receives ECI
in the Authentication Response (PARes).
Merchant proceeds with purchase as attempted
authentication, submits ECI of 6 in Authorization
Request and leaves CAVV blank.
The Issuer is not permitted to submit a chargeback if
the cardholder later disputes having made the
purchase. If the Merchant receives a chargeback,
they may represent.

Visa *Confidential*

25


Verified by Visa

U = Unable to
process or card not
eligible for
attempts processing
(e.g., Commercial
Card)

ECI of 7

Merchant proceeds with purchase as nonauthenticated and submits authorization with ECI of
7.
The Acquirer/Merchant retains liability if the
cardholder later disputes making the purchase.

Authentication Response Codes
Y = Authentication
approved

ECI of 5 in PARes
message

The Issuer has authenticated the cardholder.

A = Authentication
attempted

ECI of 6 in PARes
message

The Merchant has attempted to authenticate the
cardholder and either the Issuer or cardholder is not
enrolled.

U = Unable to
authenticate

ECI of 7

The Issuer ACS is not able to complete the
authentication. An ECI is not returned in the
authentication response.
Merchant proceeds with these purchases as nonauthenticated and retain liability if the cardholder
later disputes making the purchase.

N = Authentication
failed

NA

The Issuer is not able to authenticate the cardholder.
Merchants are not permitted to submit these
transactions for authorization. No ECI or CAVV is
returned in the response.

Table 1. ECI Codes for Visa Authorization Request Messages

4.5

Authorization Processing

Required Data
in Visa
Authorization
Requests

The Visa Authorization Request for an authenticated or attempted
authentication must contain the Electronic Commerce Indicator (ECI) and
Cardholder Authentication Verification Value (CAVV), along with other CPS eCommerce Preferred requirements, as proof of the authentication or attempt to
qualify for chargeback protection.

Mapping
PARes Fields
to
Authorization
Messages

After each successfully authenticated transaction (as indicated by a Transaction
Status of Y in the PARes), or each transaction for which proof of authentication
was generated (as indicated by a Transaction Status of A in the PARes), the
Merchant is required to pass the fields defined in the table below from the
PARes to the Merchant’s commerce server in order to correctly identify the
transaction in the authorization process:
PARes Field Name
Cardholder Authentication Verification Value

April 2004

Visa *Confidential*

PARes DTD Element
TX.cavv
26


Verified by Visa

Electronic Commerce Indicator
Transaction Identifier (optional)

Decoding
CAVV from
PARes
Message

TX.eci
Purchase.xid

The CAVV value that the ACS returns to the MPI is Base 64-encoded, resulting
in a 28-byte value. The Merchant receives the PARes as a Base 64-encoded
message. The CAVV field is further Base 64-encoded within the PARes message
that results in a length of 28 bytes. The CAVV field has also been separately
Base 64-encoded. The Merchant, or Merchant processor, must therefore perform
the following in sequence:
•

Base 64 decode the PARes message

•

Base 64 decode the CAVV field to get it back to a 20 byte binary value

•

If necessary, convert the data field to gateway processor’s traditionally
required data format (EBCDIC, etc.)

•

Submit data field to gateway processor

•

Construct the BASE I authorization message to ensure that the CAVV is
entered in BASE I as a binary value in Field 126.9

To adhere to the VisaNet requirements for Field 126.9, which is 20 bytes long,
the CAVV must be decoded into a 20-byte binary value prior to submitting it to
VisaNet or their payment processor. Because the arrangements between
Merchants and payment processors can vary, Merchants will need to confirm
whether they or their payment processor will convert the CAVV data into binary.

Transmit
CAVV

The Cardholder Authentication Verification Value is a cryptographic value
derived by the Issuer during payment authentication that provides evidence of
the results of payment authentication during an online purchase. Issuers must
include this value in each Payer Authentication Response message sent to the
MPI in which the Transaction Status value is either Y or A.
When a Merchant receives a CAVV value in a PARes message from the
Issuer, the CAVV and ECI must be included in the Visa Authorization Request
for the Merchant to qualify transactions for chargeback protection.
Parties that transmit Authorization Requests directly to Visa must support and
certify for the following V.I.P. fields:
Sent in Visa Authorization Requests:
•

Field 126.9— CAVV field

•

Field 60.8—Additional POS Information, positions 9–10, that carries the
MOTO/ECI for BASE I.

•

Field 126.8— XID, optional

Returned in Visa Authorization Responses:
•

April 2004

Field 44.13—CAVV Results Code that carries the results of validating the
CAVV.

Visa *Confidential*

27


Verified by Visa

Transaction
Identifier (XID)

This is a unique tracking number set by the Merchant and sent to the ACS in the
PAReq message. It is optional for the XID to be included in Visa Authorization
Requests.

Matching ACI
and ECI for
Clearing and
Settlement

The Authorization Characteristic Indicator (ACI) must be consistent with the
ECI in the clearing and settlement messages. This means that the Merchant or
gateway processor must ensure that the ECI submitted for clearing and
settlement matches the ACI received in the Authorization Response. The ACI
indicates the CPS category for which the transaction qualifies, as shown below:
ACI Value in
Authorization
Response

What the Value Means

ECI Value for
Settlement

U

Transaction qualified as CPS/e-Commerce
Preferred as an authenticated purchase.

5

S

Transaction qualified as CPS/e-Commerce
Preferred as an attempted authentication.

6

Transaction qualified as CPS/e-Commerce Basic
as a standard electronic commerce transaction.

7

W or P

e-Commerce
Custom
Payment
Service

Custom Payment Services (CPS) establish a framework for processing
transactions across different acceptance environments. There are requirements
for defined data fields, processing rules, interchange rates and chargeback
provisions. The CPS/e-Commerce categories are:
•

CPS/e-Commerce Basic

•

CPS/e-Commerce Preferred Retail

•

CPS/e-Commerce Preferred Passenger Transport

•

CPS/e-Commerce Preferred Hotel and Car Rental

CPS/e-Commerce Basic is a standard, non-authenticated electronic commerce
transaction that requires the appropriate ECI and an Address Verification
Service (AVS) inquiry. Qualification for CPS/e-Commerce Preferred also
requires a successfully authenticated or attempted authenticated transaction in
which a valid CAVV is included in the Visa Authorization Request. More
information about these programs and the respective transaction characteristics
are highlighted in Appendix D.

April 2004

Visa *Confidential*

28


Verified by Visa

4.6

Support for Dispute Resolution Processes

Chargeback
Protection for
Authenticated
and
Attempted
Authenticated
Transactions

If the Issuer provides a positive authentication response or an attempt response,
the transaction may not be charged back to the Merchant if the cardholder later
disputes the transaction as an unauthorized purchase. A full description of
dispute processing can be found in the 3-D Secure Operations Guide for Issuers,
Acquirers and Merchants. A summary of the dispute resolution process for
Acquirers can be found in Appendix F, Suggested Dispute Resolution Procedures.
As noted in Chapter 2, the chargeback protection affects the following “fraudtype” disputes in which cardholders allege they did not make the purchase:
U.S. Chargebacks:
Reason Code 23 – T&E Invalid Transaction
Reason Code 61 – Fraudulent Mail/Phone Order Transaction
Reason Code 75 – Cardholder Does Not Recognize Transaction
International Chargebacks:
Reason Code 23 – T&E Invalid Transaction
Reason Code 83 – Fraud, Non-Possession of Card
All other chargeback rights continue to apply to e-commerce transactions.

Using ACI
Value for
Dispute
Research

Acquirers and Merchants may also find the Authorization Characteristic
Indicator (ACI) assigned by VisaNet in the Authorization Response helpful in
dispute research. This value indicates whether the transaction qualified for
chargeback blocking, as follows:
•
•

ACI of W (standard e-commerce) or P (standard T&E e-commerce).

•

Using CAVV
Results Field
for Dispute
Research

ACI of U (authentication transaction) or S (attempted authentication).

Other ACI Values (transactions have not qualified as electronic commerce).

The CAVV Results field is returned in Authorization Responses (BASE I Field
44.13). This value may be helpful in determining if a transaction qualifies for
chargeback protection.
Authentication
Good Result
Result
2
D

Attempted Authentication

Failed
1

Good Result
Result
3
6
8
A
C

Failed
4
7
9

No Liability Shift
No CAVV or Invalid Result
Blank
0
No Liability Shift Result
B

Information about CAVV Results values can be found in Appendix F, Suggested
Dispute Resolution Procedures.

April 2004

Visa *Confidential*

29


Verified by Visa

5

Merchant Server Plug-in Functionality

Organization

This chapter describes:
•
•

3-D Secure messages involving MPI processing.

•

Overview of
MPI functions

The key role of the Merchant Server Plug-in (MPI) in 3-D Secure Processing.

Additional functional requirements of the MPI.

The Merchant Server Plug-in is software that can be integrated with a
Merchant’s Web storefront software or may be supplied as a service by an
Acquirer, payment service provider, payment gateway provider, or Internet
Service Provider (ISP). The MPI performs a number of essential functions in
3-D Secure processing including:
•

Transmitting Verify Enrollment Request (VEReq) messages to the Visa
Directory Server and receiving Verify Enrollment Response (VEReq)
messages from the Visa Directory Server.

•

Transmitting Payer Authentication Requests (PAReq) to, and receiving
Payer Authentication Responses (PARes) from, the ACS via the cardholder’s
device.

•

Optionally, transmitting Card Range Request (CRReq) messages to the Visa
Directory Server and receiving Card Range Response (CRRes) messages
from the Visa Directory Server.

•

Validating the cryptographic signature in the PAReq message from the ACS
to ensure its authenticity and integrity using the Visa Root Certificate.

•

Providing authentication results data to the Merchant’s authorization
processing function.

The functional requirements of the Merchant Plug-in were developed in the
context of common operating system, Web server, and storefront development
environments, to enable development of software that is widely compatible with
products being used by most Merchant sites.

5.1

3-D Secure MPI Messages
The following short descriptions of each message that affects the MPI are
provided for reference only. Please refer to the 3-D Secure Protocol Specification,
Core Functions for exact formats, element definitions, and DTDs.

April 2004

Visa *Confidential*

30


Verified by Visa

CRReq and
CRRes

Card Range Request (CRReq) and Response (CRRes) are optional messages that
enable the MPI to request the full set of participating card ranges in the Visa
Directory Server.
The Merchant Server Plug-in formats a CRReq message and sends it to the Visa
Directory Server to request updated card range data.
The Visa Directory Server formats a CRRes message containing the
participating card ranges and sends it to the MPI so the MPI can update its card
range cache information.
If the MPI supports a card range cache, a CRReq message must be forwarded at
least once every 24 hours.
Note: The majority of Visa card ranges are loaded in the Directory Server, so
Visa recommends that MPIs forward all Verify Enrollment Request messages to
the Directory Server and avoid support for the cache of card ranges.

VEReq and
VERes

Verify Enrollment Request (VEReq) and Verify Enrollment Response (VEReq)
After the cardholder completes the Merchant’s checkout process, the MPI
formats a VEReq message and sends it to the Visa Directory Server to determine
whether authentication is available for a specific card number.
The Visa Directory Server searches for a card range that includes the cardholder
PAN received in the VEReq message. If the PAN is identified in a participating
card range, the Visa Directory Server forwards the VEReq message to the URL
of the ACS associated with that card range.
The ACS receives the VEReq message and checks the participation of the card
number and returns a VEReq message that contains the URL of the ACS for
either authentication processing – either an authentication or attempted
authentication. The Directory Server forwards the VEReq message to the MPI.
If the Visa Directory Server cannot identify a card range that includes the PAN
received in the VEReq message, the Visa Directory Server returns a VEReq
message to the MPI with an N for Not Enrolled response.

PAReq and
PARes

Payer Authentication Request (PAReq) and Payer Authentication Response
(PARes) Messages
The MPI sends a PAReq message to the ACS URL that was received in the
corresponding VEReq. The PAReq contains information regarding the purchase
transaction.
The ACS responds with a PARes, a message containing transaction details and
signed by the ACS, providing the Issuer’s authentication results for the
cardholder’s purchase.
The MPI validates the signature on the PARes message in order to complete the
3-D Secure authentication process.

April 2004

Visa *Confidential*

31


Verified by Visa

Error Message

Error

All 3-D Secure components must be able to create and process an Error
message. This message is reserved for instances of protocol and system-level
errors.

5.2

Additional MPI Functional Requirements

Digital
Certificates

The Merchant server certificate signed by the Visa Root Certificate must be
encrypted and securely stored in the MPI.
The MPI must be able to import and securely store the Visa Root Certificate for
use in validating the Issuer’s signature retuned in PARes messages.

Recordkeeping

The MPI must log all 3-D Secure related functions as part of normal processes.

Reporting

It is highly desirable that merchants modify current transaction reporting to
include Verified by Visa specific fields. This following data will be beneficial in
disputes resolution:

The MPI must be able to maintain and store PARes records for dispute
resolution purposes.

•
•

Electronic Commerce Indicator (ECI)

•

Monitoring

Transaction Status (results of authentication – Y, A, U, or N)

CAVV Field (includes the Authentication Tracking Number or ATN to assist
research with CAVV Field in Visa Authorization Request message.

Merchant (or the hosting entity) must integrate monitoring of the MPI server
and application into its systems monitoring processes so that the Merchant can
quickly identify and correct problems with its implementation of 3-D Secure.
Quick identification and repair will enable the Merchant to minimize any
potential loss of the program benefits on its Visa transactions, and participating
cardholders will be more likely to have the Verified by Visa experience they have
grown to expect at a Verified by Visa Merchant. The systems monitoring
requirements stated above become effective on April 15, 2004. Merchants that
either had entered production or had begun technical implementation prior to
April 15, 2004, must institute system monitoring by June 30, 2004.
However, Merchant (or the hosting entity) must not send test transactions to the
Visa Directory Server as part of its monitoring.

April 2004

Visa *Confidential*

32


Verified by Visa

Directory
Server
Fallback

Merchant must implement fallback to a secondary Visa Directory Server.
Merchants should consult with their MPI software vendor to identify the correct
primary and secondary production Visa Directory Server URLs and how to
properly configure the MPI to automatically fall back to a secondary Directory
Server if the primary Visa Directory Server is temporarily not available.
Fallback must be configured so that no human intervention is required. All
Merchants must implement fallback to the secondary production Visa Directory
Server by October 1, 2004.

3-D Secure
Timeout
Sequencing

Please refer to Appendix C for requirements governing 3-D Secure timeout
sequencing.

Cardholder
Data Security

Any payment card data stored by the Merchant Server Plug-in or on servers that
are connected to the Internet must be encrypted and securely stored as defined
in the Visa Cardholder Information Security Program (CISP). See Chapter 1,
Resources and Tools for information to obtain a copy of these requirements.

For More
Information

Additional information regarding mandatory and optional functionality of the
Merchant Server Plug-in is contained in 3-D Secure Functional Requirements –
Merchant Server Plug-in. See Chapter 1, Resources and Tools for information to
obtain a copy of these requirements.

April 2004

Visa *Confidential*

33


Verified by Visa

6

Merchant Product Rules and Best Practices

Overview

6.1

This chapter discusses additional Acquirer and Merchant program and
transaction requirements, which supplement the Visa U.S.A. Inc. Operating
Regulations. Also outlined are some recommendations for best practices to
ensure a good authentication experience for customers.

Acquirer Responsibility for Merchant Participation

General
Requirements

Participating Acquirers are responsible for ensuring that participating
Merchants operate in accordance with these Product Rules and the Visa U.S.A.
Inc. Operating Regulations, and that such requirements are included in
Merchant Agreements. Acquirers must ensure and/or approve the following:
•

Merchants Agreements have been modified to reflect a Merchant’s
participation in Verified by Visa.

•

The issuance of a Merchant digital certificate for use in Merchant
authentication to the Visa Directory Server.

•

Merchants and third-party commerce server providers meet the security
requirements for 3-D Secure processing, including support for the
Cardholder Information Security Program (CISP). For further information
on Verified by Visa-specific CISP compliance requirements, see Section 1.3
Resources and Tools, Production Certificate Request Documents.

•

•

6.2

Contracts with third-party commerce server providers or payment gateways
must ensure that each Merchant activated for Verified by Visa is reported to
and approved by the Acquirer.
An Acquirer who has contracted with a third-party service provider, or uses
an Internet Payment Services Provider (IPSP), to provide Verified by Visa
services to its Merchants must file an Exhibit VV with Visa for the thirdparty service provider or IPSP.

Merchant Authentication to Access Visa Directory Server

Requirement

April 2004

A Merchant client certificate is required for participating Merchants to connect
to the Visa Directory Server. To support this capability, the Common Name in
the Merchant certificate must contain a Host Name (also known as a Domain
Name). During the connection attempt, the Visa Directory Server will check that
the client’s DNS-resolvable Host Name matches the information contained in the
Common Name of the Merchant certificate. If the information does not match,
the Directory Server will deny the connection.

Visa *Confidential*

34


Verified by Visa

6.3

Use of Inline Page instead of Pop-Up

Requirement

6.4

The 3-D Secure Protocol allows for two types of authentication page displays to
be presented to cardholders: inline or pop-up pages. The inline page uses the
full browser window to display the authentication page. Pop-ups display as a
separate smaller window on top of the Merchant checkout page. Pop-up
suppression software has gained market adoption through stand-alone
applications as well as online service providers that incorporate it as a standard
feature of the service. Microsoft has announced the inclusion of pop-up
suppression software in the next version of Internet Explorer. Cardholders have
also learned to disregard pop-up windows due to the high frequency of pop-up
windows being used for unsolicited advertisements. Therefore, U.S. Merchant 3D Secure implementations must not use the pop-up page presentation for
Verified by Visa and must instead use an inline page. This change will prevent
issues with pop-up suppression software and avoid situations where cardholders
inadvertently close the Verified by Visa pop-up. The prohibition of pop-up page
implementations becomes effective April 15, 2004. Merchants that either had
entered production or had begun technical implementation using a pop-up
presentation prior to April 15, 2004, must change to an in-line presentation by
June 30, 2004.

Pre-Authentication Messaging

Requirement

April 2004

Merchants must provide a brief message to cardholders on the checkout page
after the Merchant knows that the cardholder has selected a Visa card as the
payment method. The intention of the messaging is to notify the cardholder that
they might next be prompted either to activate their card for Verifed by Visa or,
if they already participate in Verified by Visa, to provide their Verified by Visa
password. The messaging is also intended to provide a further reminder and
reassurance to the cardholder, beyond the presence of the Verified by Visa
“Learn More” logo on the Merchant’s site, that the Merchant participates in
Verified by Visa and is aware of the possible cardholder experiences associated
with the program. However, any such messaging must not state affirmatively
that the cardholder will have a Verified by Visa experience, and the Merchant
must not indicate that the Merchant requires the cardholder to authenticate
himself or herself. Also, Merchants must not insert an interim page, after the
cardholder clicks the “buy” button, that requires the cardholder to click a
“Continue” button for Verified by Visa, as this may be confusing to cardholders
who are processed as an “Attempted Authentication”. The pre-authentication
messaging Product Rules stated above become effective on April 15, 2004.
Merchants that either had entered production or had begun technical
implementation prior to April 15, 2004, must adhere to the Product Rules by
June 30, 2004.

Visa *Confidential*

35


Verified by Visa

Requirement

Pre-authentication messaging should be kept as short and concise as possible.
The pre-authentication message should be free from technical jargon (e.g., “You
may be taken to your bank’s secure Verified by Visa site…”) as the jargon will
tend to confuse users. Visa recommends pre-authentication messaging as
follows:
The next screen you see may be payment card verification
through Verified by Visa.
Or, if the Merchant is implementing Verified by Visa in conjunction with other
payment card brand’s 3-D Secure-based authentication solutions, and the
merchant cannot determine which payment brand’s card is being used for the
transaction, Visa recommends the following:
The next screen you see may be payment card verification
through your card issuer.
The pre-authentication message is most effective and most likely to be read by
cardholders when placed immediately next to the final order button. Merchants
should also consider graphical treatments such as using large text, bolding, and
color to help draw attention to the pre-authentication message. A visual
grouping such as drawing a box around the pre-authentication message and the
final order button can also help draw attention and emphasize that
authentication is part of the merchant’s normal checkout process flow. An
example is provided below:

April 2004

Visa *Confidential*

36


Verified by Visa

6.5

Use of Inline Page

Best Practice

Merchants must implement either an inline or a “framed” inline approach.
Examples and the benefits of each permitted approach are discussed below.
Figure 9 shows a standard inline page and Figure 10 shows a framed inline page.

Inline Page
This approach provides a
clean presentation to the
cardholder and has the
following additional
benefits:

Cardholder can verify
connectivity with Issuer
Access Control Server URL

1. Cardholder can verify the
Issuer ACS URL.
2. Cardholder can check the
SSL lock to ensure
connection with Issuer
ACS.

Cardholder can verify SSL session with Issuer ACS

Both features provide
increased cardholder
confidence for entering
sensitive information, like a
password.

Figure 9: Standard Inline Page

Merchant URL

Framed Inline Page
This approach allows the
Merchant to provide a
consistent look and feel
across the checkout process.
However, there may be
cardholder concerns
regarding the confidentiality
of information entered into
the page when the
cardholder sees the
Merchant URL in the
window and Merchant name
in the SSL lock.
Merchant SSL certificate information

Figure 10: Framed Inline Page
April 2004

Visa *Confidential*

37


Verified by Visa

6.6

Use of Inline Page with a Framed Window

Requirement

If a Merchant uses the framed inline approach, the frame opened for the Issuer
ACS to present the Verified by Visa window must be large enough to present the
entire 390 pixel width by 400 pixel height authentication page without scrolling.
Merchants that elect to implement an inline page with a frame may place a
frame at the top of the page (Figure 11) and/or on the side of the page (Figure
12).

Framed Inline Page
with Top Frame

Merchant status
indicator (see
Section 6.7)

Frame must allow at
least 390 pixels width by
400 pixels height to
display, without
requiring the customer
to scroll to see the
authentication page.

Concise merchant
message (see
Section 6.7)

See section 6.7 for
requirements related to
the use of text
communications.

Figure 11: Framed Inline with Top Frame

Framed Inline Page
with Side Frame

Merchant status
indicator (see
Section 6.7)

Frame must allow at
least 390 pixels width by
400 pixels height to
display, without
requiring the customer
to scroll to see the
authentication page.

Concise merchant
message (see
Section 6.7)

See Section 6.7 for
requirements related to
the use of text
communications.

Figure 12: Framed Inline with Side Frame

April 2004

Visa *Confidential*

38


Verified by Visa

6.7

Text for Inline Page with a Framed Window

Recommended
Text

Merchants must provide a brief communication to customers outside of the
frame for the authentication page, as shown in Figure 13 below. The text will
be seen by Visa cardholders that are both activated for Verified by Visa and
non-activated where an attempted authentication response is returned to the
Merchant. Recommended text is as follows:
Do not click the refresh or back button or your transaction may
be interrupted.
If the Merchant elects alternate wording from that recommended by Visa
above, the customer communication provided by the Merchant should be free of
technical jargon. Visa research has shown that most users are confused by
terminology that explains the technical side of Verified by Visa. Users do not
understand and may misinterpret messages regarding which server they are
interacting with, whether they are technically at a different site, etc.
Therefore, Merchants should not provide text that explains, for example, “you
may be taken to the secure Verified by Visa site for authentication after which
you will return to our site.” Merchants should keep the technology as
transparent as possible to the user.
Any Merchant messaging outside of the frame for the authentication page
must avoid explicitly describing the Verified by Visa experience to the user.
The Merchant is unable to determine the particular experience that a
cardholder may have. For example, some cardholders will be processed as an
attempted authentication, and will not be presented with a Verified by Visa
password entry screen. Again, Visa market and usability research has clearly
shown that a simple statement, such as that shown below, provides the best
user experience.

Merchant message

Figure 13: Inline Framed Merchant Message
April 2004

Visa *Confidential*

39


3-D Secure Acquirer and Merchant Implementation Guide

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à 3-D Secure Acquirer and Merchant Implementation Guide

Similaire à 3-D Secure Acquirer and Merchant Implementation Guide (20)

Plus de - Mark - Fullbright

Plus de - Mark - Fullbright (20)

Dernier

Dernier (20)

3-D Secure Acquirer and Merchant Implementation Guide