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 andis owned by Visa. These materials have been distributed and provided to VisaMembers for their internal use. The information in this document applies tobusiness in the United States only. Any use of disclosure of these materials tothird party vendors or any other entity outside of the Visa membership associationrequires 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 Introduction..............................................................................................................................................1

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

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

2 Verified by Visa Service Description..................................................................................... 6

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

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

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

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

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

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

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

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

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

4 Transaction Processing – Authentications and Payment Transactions........................... 22

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

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 Support for Dispute Resolution Processes .............................................................................................29

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

5.1 3-D Secure MPI Messages .....................................................................................................................30

April 2004 Visa *Confidential* i 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.


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

6 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 “Buy or Build” MPI Software Options ..................................................................................................51

7.2 Hosted MPI Options...............................................................................................................................53

8 Merchant Authentication and Transport Security............................................................ 54

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

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

April 2004 Visa *Confidential* ii 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.


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 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.


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:

• The functionality, uses, and benefits of Verified by Visa.

• The development, testing and production set up of Verified by Visa.

April 2004 Visa *Confidential* 1 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.


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.

Sections 6.3, 6.5, 6.6, and 6.7

Merchants must immediately ensure both the GP2 and eCommerce Visa Root Certificates are installed.

Section 9.7

Merchants must configure the MPI with both a primary and secondary URL for the production Visa Directory Server by October 1, 2004.

Sections 5.2 and 9.7

Verified by Visa Merchant Symbol is required on check out page.

Section 6.8

“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.

Section 6.13

Best Practices Changes

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:



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.

Section 6.10

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.

Section 6.7

1.3 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:

• 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.

• 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.

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


http://www.visa.com/verifiedmerchants


http://www.visa.com/verifiedvendors


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.)

• 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.

3-D Secure Specifications and Technical Requirements

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.


http://www.visa.com/cisp

http://usa.visa.com/business/merchants/online_risk_management.html

http://international.visa.com/fb/paytech/secure/main.jsp

http://international.visa.com/fb/paytech/secure/main.jsp


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 [email protected]. The following documentation describing the PIT can be accessed at the PIT Web site at URL:

https://dropit.3dsecure.net/PIT:

• PIT User’s Guide

• PIT Test Cases

• PIT Terms of Service

Production Certificate Request Documents

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 [email protected] 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


mailto:[email protected]

https://dropit.3dsecure.net/PIT

http://www.us.visaonline.com/

mailto:[email protected]


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.



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.

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

70%60%

40%

0%

10%

20%

30%

40%

50%

60%

70%

% of U.S. Pop.

Online% with InternetAccessat Home

% of Internet Users

Shopped

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.


http://www.ccp.ucla.edu/


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.

Figure 2. Consumer Concerns for Online Card Security

16.6%

19.1%

59.5%

42.6%

23.0%

25.2%

0%

20%

40%

60%

80%

100%

Security Concerns of New and Experienced Internet Users – Year 2002

ExtremelyVery Conc

8.8%

29.5%

61.7%

5.5%

23.1%

71.3%

7.6%

29.1%

63.3%

0%

20%

40%

60%

80%

100%

2000 2001 2002

Extremely or Very Concerned Somewhat Concerned Not At All Concerned

Level of Concern regarding Online Card Security over Past Three Years

April 2004 Visa *Confidential* Notice: This document contains Visa’s proprietary information for use by Visa Memparties or any other use is prohibited without the prior written permission of Visa U.S

New Users Experienced Users (<1 Year) (6 or More Years)

Concerned Somewhat Concerned erned Not At All Concerned

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

– UCLA Internet Report, 2002

8 bers’ Visa card programs. Disclosure to third .A. Inc.


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.



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



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. The cardholder visits the Issuer’s Activation Website and enters the requested authentication information.

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

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


http://www.visa.com/verified


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.



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.



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

• 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 3-D Secure Operations Guide for Issuers, Acquirers and Merchants.

Interchange Benefit

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/e-Commerce 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.



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.

Figure 6. e-Commerce Chargeback Dollars by Reason Code

Total Chargebacks

Reason Codes: 23 1% 61 42% 75 7% 83 16% All Other 34%

Total 100%

All Other Disputes

34%

U.S. Cardholder Disputes

Making Purchase50%

(Reason Codes 23, 61 and 75)

Non-US Cardholder Disputes Making

Purchase 16%

(Reason Code 83)

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

Data Quality 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.



3 3-D Secure – Global Payment Authentication

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

3.1 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

ACQUIRER

Interoperability Domain Acquirer Domain

ISSUER

MERCHANT CARDHOLDER

Figure 7: Three-Domain Model



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:

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

• 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.

• Performs activation of cardholders for Verified by Visa.

Access Control Server

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.

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



Acquirer Domain

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 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: • Receives Visa Authorization Requests from the

Merchant and forwards to VisaNet

• Provides Authorization Responses to the Merchant.

• Submits the completed transaction to the VisaNet settlement system.

Inter-operability Domain

Visa Directory Server

The Visa Directory Server, operated by Visa:

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

• Directs the request for cardholder authentication to the appropriate ACS.

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

Commercial Certificate Authority

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.



Inter-operability Domain (continued)

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.

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 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.



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.

VisaDirectory

3

Issuer Domain Acquirer Domain

MERCHANT

Plug - in

AccessControl

12

2

4

5

Interoperability Domain

Issuer VisaNet Acquirer

AuthenticationHistory

9

1

8 9

6

7

CARDHOLDER

1011

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



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.



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

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.

Y = Card eligible for authentication processing

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.

Verify Enrollment Response by ACS

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

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.



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 non-authenticated, 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.

• 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.

N = Authentication failed

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



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.



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 5 = Cardholder authenticated by the Issuer. This value should be returned by the ACS in the PARes message.

• 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.

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

Determining ECI Values

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

Merchant forwards PAReq to ACS and receives ECI in the Authentication Response (PARes).

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

ECI of 6 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.



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

ECI of 7 Merchant proceeds with purchase as non-authenticated 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 non-authenticated 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 e-Commerce Preferred requirements, as proof of the authentication or attempt to qualify for chargeback protection.

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 PARes DTD Element

Mapping PARes Fields to Authorization Messages

Cardholder Authentication Verification Value TX.cavv



Electronic Commerce Indicator TX.eci

Transaction Identifier (optional) Purchase.xid

Decoding CAVV from PARes Message

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: • Field 44.13—CAVV Results Code that carries the results of validating the

CAVV.



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

W or P Transaction qualified as CPS/e-Commerce Basic as a standard electronic commerce transaction. 7

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.



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 “fraud-type” 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 U (authentication transaction) or S (attempted authentication).

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

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

Using CAVV Results Field for Dispute Research

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 Attempted Authentication No Liability Shift

Good Result Failed Result

2 1 D

Good Result Failed Result

3 4 6 7 8 9 A C

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.



5 Merchant Server Plug-in Functionality

Organization This chapter describes:

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

• 3-D Secure messages involving MPI processing.

• Additional functional requirements of the MPI.

Overview of MPI functions

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.



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.



Error Error Message

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.

Record-keeping

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

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

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:

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

• Electronic Commerce Indicator (ECI)

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

Monitoring 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.



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.



6 Merchant Product Rules and Best Practices

Overview 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.

6.1 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.

• 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 third-party service provider or IPSP.

6.2 Merchant Authentication to Access Visa Directory Server

Requirement 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.



6.3 Use of Inline Page instead of Pop-Up Requirement 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 3-D 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.

6.4 Pre-Authentication Messaging Requirement 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.



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:



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:

1. Cardholder can verify the Issuer ACS URL.

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

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

Figure 9: Standard Inline Page

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.

Figure 10: Framed Inline Page

Cardholder can verify connectivity with Issuer Access Control Server URL

Cardholder can verify SSL session with Issuer ACS

Merchant URL

Merchant SSL certificate information



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

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.

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

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.

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

Figure 12: Framed Inline with Side Frame

Merchant status indicator (see Section 6.7)

Concise merchant message (see Section 6.7)

Merchant status indicator (see Section 6.7)

Concise merchant message (see Section 6.7)



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.

Figure 13: Inline Framed Merchant Message

Merchant message



Status Indicator In addition, Visa strongly recommends that Merchants implementing a framed

inline presentation of Verified by Visa provide a “processing” indicator with simple movement, outside of the frame for the authentication page, to provide a visual cue to customers that the purchase process is continuing in the background. Simple dots or arrows moving from left to right are sufficient for this purpose. It is important that the status indicator have some kind of simple movement: static processing screens confuse users because they cannot tell if the system is working or frozen.

Figure 14 below show a sample implementation, with “Processing your order” text followed by multicolored dots that move from left to right.

Figure 14: Inline Framed with Status Indicator

Status indicator



Requirement No Promotional Messages

Merchants must not display promotional messages to cardholders. It is important that cardholders have confidence in the authentication session with their card issuer.

Figure 15: Incorrect Inline Implementation

Merchant promotional messages not permitted

Must leave room for full Verified by Visa page without scrolling



User Interface Best Practices

Presenting Verified by Visa using an inline frame provides the ability for the Merchant to maintain a consistent look and feel across the Merchant site and purchase process. However, the frame should be kept simple: the graphics in the frame should be sufficient to preserve the site’s context, but should not be so elaborate that graphics distract from the Verified by Visa processing area in the main body of the page. Elements such as navigational links, text, and icons must be kept to a minimum.

Figure 16: Incorrect Inline Implementation

Excessive navigational links, etc., can distract the cardholder from the authentication task.

Merchant promotional messages not permitted



6.8 Verified by Visa Information via Merchant Symbol

Requirement Merchants must place the Verified by Visa “learn more”

Merchant Symbol on the checkout page on which the cardholder enters their Visa card number or on another page in the checkout flow that cardholders must view while placing their order. When clicked by the cardholder, the Merchant Symbol provides information on the Verified by Visa program and a link to the Verified by Visa web site that provides information on Verified by Visa and allows the cardholder to activate their card in Verified by Visa. Presence of the Merchant Symbol on the checkout page notifies the cardholder that the Merchant participates in Verified by Visa and alerts the cardholder to a possible interaction with the service. The Verified by Visa Merchant Toolkit provides information about the Merchant Symbol and standards for use. Merchants should ask their Acquirer for information.

The Verified by Visa “learn more” logo should be placed next to the credit card entry fields and other security-related icons on the checkout page.

The requirement to display the Merchant Symbol becomes effective on April 15, 2004. Merchants that either had entered production or had begun technical implementation prior to April 15, 2004, must implement the Merchant Symbol by June 30, 2004.

6.9 Activation Anytime Best Practice Visa recommends that participating Merchants implement the Verified by Visa

“Activate Now” logo and link on their website, and that the “Activate Now” logo be placed on the Merchant’s home page. As described in Appendix E, when cardholders click the “Activate Now” logo they are provided the opportunity to learn about Verified by Visa and, if desired, to activate their Visa card for Verified by Visa. Implementing the “Activate Now” logo benefits the Merchant by providing an opportunity to for the Merchant to assist in the activation of cardholders in Verified by Visa. Cardholders can leave the “Activation Anytime” landing page at any time, and return to the Merchant Site to continue shopping and checkout.



Best Practice The flow of an Activation Anytime transaction is shown in Figure 17.

Figure 17: Activation Anytime Flow

Appendix E provides more detailed information about how Acworks and the implementation requirements.

Step 2: Activation Anytime Landing Page appears

Step 1: Cardholder clicks on Verified by Visa button at Merchant site

Click

3 2

1

6.10 Failed Authentication Processing

Best Practice Merchants are not permitted to submit for Visa authorizationwhich it receives a Verified by Visa failed authentication resp

When Merchants receive a PARes message with a failed authvalue of N, Merchants must immediately display a message orcommunicate to the cardholder that the purchase will not be ctheir card. Alternatively, Merchants may immediately send athat communicates this to the cardholder; however, this methrecommended as a “Best Practice”. The requirement to providfailure messaging becomes effective on April 15, 2004. Merchhad entered production or had begun technical implementatio2004, must implement authentication failure messaging by Ju

April 2004 Visa *Confidential* Notice: This document contains Visa’s proprietary information for use by Visa Members’ Visa card prograparties or any other use is prohibited without the prior written permission of Visa U.S.A. Inc.

Step 3: Cardholder enters data to activate and is returned to

tivation Anytime

any transaction for onse value of N.

entication response page to ompleted with n email message od is not e authentication ants that either n prior to April 15, ne 30, 2004.

44 ms. Disclosure to third


Requirement

Best Practice Best Practice

At the Merchant’s option, the cardholder may be asked to provide another form of payment. The suggested wording for the failed authentication message is:

Authentication Failed Your financial institution has indicated that it could not authenticate this transaction via Verified by Visa. To protect against unauthorized use, this Visa card cannot be used to complete your purchase. You may complete the purchase by clicking here to select another form of payment.

Visa strongly recommends that Merchants provide an easy, simple recovery mechanism to cardholders that fail Verified by Visa authentication. On the page on which the Merchant provides the “Authentication Failure” message, the recovery mechanism may either provide an immediate opportunity for the cardholder to enter a new payment card number and click to try again, or provide a button that, when clicked, presents a new page that allows the cardholder to easily reinitiate the purchase.

Visa strongly recommends that Merchants provide the Verified by Visa “Learn More” link on the “Authentication Failed” page. The “Learn More” logo provides an additional opportunity to cardholders to learn about Verified by Visa.

6.11 Merchant Performance Standards

Requirement To enable participating Merchants to complete sales without risk of excessively

long delays in response wait time, participating Merchants must establish minimum timeout values within the 3-D Secure Merchant Server software. The following are the Verified by Visa Merchant timeout criteria:

• Verify Enrollment Request/Response. The Merchant MPI software must have a timeout value of not less than 10 seconds for the Verify Enrollment Response (VERes) to be returned by the Visa Directory Server. When the timeout expires, the Merchant may proceed with the transaction as a non-authenticated purchase.

• Purchase Authentication Request/Response. The MPI software must have a timeout value of not less than five minutes for the Payer Authentication Response (PARes) from the Issuer ACS to allow for timing variations in the cardholder interaction.



6.12 Timing between VERes and PAReq

Best Practice Merchants should ensure that the MPI, upon receipt of the Verify Enrollment

Response (VERes) with a value of Y, promptly formats and transmits the Payer Authentication Request (PAReq) to the Issuer ACS URL contained in the VERes message. When ACSs return a VERes, it contains a unique Account Identifier for each transaction. To minimize the possibility of fraudulent transactions, an ACS will set a validity timer for each Account Identifier that it generates for a VERes message. This timer is usually set to not exceed a period of 10 to 15 minutes because of the expectation that Merchants will complete authentication processing quickly. PAReq messages that are received after the validity timer has expired will be returned with a failed authentication response that includes an error code. This practice reduces the likelihood that an Account Identifier can be fraudulently re-used when a PARes message is sent to an ACS.

6.13 Expiration/No Re-Use of Authentication Data

Requirement Authentication data is considered valid for 90 days after the date of the Payer

Authentication response returned to the Merchant.

Requirement Authentication data for a transaction must not be submitted in the Authorization Request for another transaction. There are two exceptions to this general requirement – one is for split shipments and the other is for delayed delivery.

Split Shipments and Delayed Delivery

• 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.

• 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 transaction.



6.14 Recurring Payments

Requirement When a participating Merchant offers services of an ongoing nature to a

cardholder for which the cardholder pays on a recurring basis (for example, insurance premiums, subscriptions, Internet service provider fees, membership fees, tuition, or utility charges), the cardholder payments are considered recurring payments, as defined in the Visa U.S.A. Inc. Operating Regulations.

If the first payment originated as an Electronic Commerce Transaction via the Internet, it must be submitted for authorization with the appropriate Electronic Commerce Indicator (ECI) value, including Verified by Visa authentication data (CAVV), if applicable. If these transactions are disputed as not made or not authorized by the cardholder, the Issuer is not permitted to charge the transaction back for Reason Codes 23, 61, 75 or 83. To qualify for chargeback protection, Merchants are required to have included a valid CAVV and ECI in the Visa Authorization Request message.

All subsequent payments must be submitted for authorization using the Recurring Indicator (MOTO/ECI value of 2). The Merchant must not store and submit the CAVV with any subsequent transaction. Because cardholders may dispute that they did not authorize the recurring payments charged to their account, subsequent recurring payments are subject to chargeback if disputed by the cardholder for the reason codes above.

6.15 Online Auctions

Requirement Participating Merchants that offer 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 PAReq to the Authorization Request. Merchants must not re-use the CAVV for another transaction with the same cardholder (for example, on another auction).

6.16 Merchant Customer Support

Requirement Merchants must train their customer support staff on Verified by Visa so that

they can respond effectively to customer inquiries. This requirement becomes effective April 15, 2004. To assist Merchants with the training of their internal customer support staff, Visa developed the Merchant Quick Reference for Verified by Visa. Ask your Acquirer or Merchant commerce server provider for a copy.



6.17 Risk Identification Service for e-Commerce

RIS Overview The Risk Identification Service (RIS) provides early identification of fraudulent,

potentially fraudulent, or other risky activity at Merchant locations. The service monitors Merchant exception item activity and identifies Merchants that exceed RIS risk activity levels. The goal of the program is to help reduce Member fraud losses caused by Merchant fraud and by improper card acceptance procedures. Additional information about the RIS program is included in the Risk Identification Service User’s Manual.

Visa has established Risk Identification Service (RIS) thresholds to identify unusually high fraud levels for two categories of electronic commerce transactions (i.e., ECI = 5, Issuer authenticated cardholder; and ECI = 6, attempted authentication by participating Merchant). Visa established the threshold levels based on analysis of historical report fraud levels. The two thresholds have been established as follows:

• Transactions with an ECI 5 (Issuer authenticated cardholder): Merchants with a combination, for a given month, of 3 fraud transactions reported by U.S. Issuers with a total value of $1,000 and a fraud to sales ratio greater than 3%.

• Transactions with an ECI 6 (attempted authentication by participating Merchant) Merchants with a combination, for a given month, of 10 fraud transactions reported by U.S. Issuers with a total value of $5,000 and a fraud to sales ratio greater than 3%.

Each violation of an electronic commerce RIS threshold will generate a RIS “Warning”; if a Merchant is identified multiple times by the electronic commerce or other thresholds, it may result in the Merchant being statused as a High Risk Merchant, which carries with it chargeback liability for fraud transactions.

When a Merchant is identified as High Risk, RIS produces two reports that notify Issuers and Acquirers of transactions eligible for chargebacks under Reason Code 93. The reports are faxed weekly:

• Issuer Chargeback Exception Report (RERW310)

• Acquirer Chargeback Exception Report (RERW320)

The Issuer Chargeback Exception Report provides Issuers with a listing by cardholder account number of all transactions that have chargeback eligibility. All of the listed transactions occurred during the time RIS designated the Merchant as High Risk.

Issuers may charge back a transaction using Reason Code 93 if the transaction is on the report and the transaction was not previously charged back. Issuers have 45 days from the report run date to charge back the transaction to the Acquirer.



6.18 Data Quality in VEReq and PAReq Messages

Requirements When the Merchant Software formats the Verify Enrollment Request (VEReq)

and Payer Authentication Request (PAReq) message to send to the Issuer ACS, there are several data fields that are used to identify the Acquirer and Merchant, present transaction data to the cardholder in the authentication process, or conduct transaction research in the event of a cardholder dispute. Merchants must accurately populate the data in both VEReq and PAReq messages. Entities that host Verified by Visa on behalf of multiple Merchants must ensure that Merchant-specific data is accurate for each Merchant.

Merchants must populate the data fields as follows:

Verify Enrollment Requests (VEReq) • Acquirer’s Bank Identification Number (Merchant.acqBIN field). This field

must be the Merchant’s Visa Acquirer’s BIN. If this value is not known, ask your Acquirer or Merchant Processor representative.

• Merchant Identifier (ID) Number (Merchant.merID field). This field must be the Merchant ID assigned by the Acquirer to the Merchant for use in Visa transactions. If this value is not known, ask your Acquirer or Merchant Processor representative.

Payer Authentication Requests (PAReq) • Acquirer’s Bank Identification Number (Merchant.acqBIN field). This field

must match the Acquirer BIN used in the Verify Enrollment Request.

• Merchant Identifier (ID) Number (Merchant.merID field). This field must match the Merchant ID used in the Verify Enrollment Request.

• Merchant Name (Merchant.name field). This field must contain the name of online Merchant at which cardholder is making the purchase. The maximum length is 25 characters.

• Merchant Country Code (Merchant.country field). This field must contain the value 840 for U.S. Merchants.

• Merchant URL (Merchant.url field). This field must contain the fully qualified URL of the Merchant site. A URL that is “fully qualified” is prefixed with the URL scheme, either “http://” or “https://”.

• Purchase Amount (Purchase.purchAmount field). This field must contain the value of the purchase being made by the cardholder. It is a value up to 12 digits with punctuation removed, for example, an amount of $123.45 would be 12345.

• Purchase Currency (Purchase.currency field). The appropriate currency code for the transaction currency between the cardholder and Merchant must be used. For U.S. currency, the value is 840.

• Purchase Exponent (Purchase.exponent field). The minor units of currency. For U.S. dollars, the value must be 2.



6.19 Pre-Production Implementation Checklist

Requirement Before coming live in production, participating Merchants must ensure their

implementation meets all Verified by Visa Product Rules. Merchants must also successfully complete all of the items on the Pre-Production Implementation Checklist, provided in Section 9.8 below, prior to deploying Verified by Visa into production. To ensure continued Product Rules compliance, Visa strongly recommends that Merchants review their adherence to the items on the checklist should the Merchant make subsequent, substantial changes to its implementation of Verified by Visa or to its checkout process.



7 MPI Implementation Alternatives

Organization This chapter reviews some alternatives for implementing Merchant Server Plug-in (MPI) functionality to enable participation by Merchants in the 3-D Secure service

Overview of Alternatives

Merchants that elect to participate in the 3-D Secure service will want to assess their business requirements, technological capabilities, and current operating environment to determine what approach they should pursue to become 3-D Secure enabled. The MPI can be located at the Merchant location, at the Acquirer or processor site, or at the Merchant service provider.

Among the implementation options available to Merchants are the following:

• Contract with Merchant’s Acquirer, if the Acquirer provided 3-D Secure MPI processing to their Merchant clients.

• Purchase components from a solution provider and integrate into an existing system.

• Develop MPI software using internal or contracted resources (the product developed must adhere to the requirements described in 3-D Secure Functional Requirements – Merchant Server Plug-in). Merchants using this option will also be required to complete software compliance testing with Visa International. See Chapter 1, Resources and Tools for information on Software Compliance Testing.

• Obtain MPI hosted processing services from a third-party payment services provider or subscribe to electronic commerce Merchant services provided by a third party, such as a mall operator.

7.1 “Buy or Build” MPI Software Options Vendor Provided Software Solution

Vendor provided software solutions are generally available as Software Development Kits (SDK). These SDKs provide a set of callable interface options for each step required of the Merchant in the 3-D Secure authentication process. These interfaces are used to integrate the Verified by Visa transaction into the existing Merchant commerce application. This approach provides the Merchant with a high degree of control over the execution and monitoring of each step of the MPI implementation, and can enable a high degree of functional Merchant Server Plug-in efficiency.



Vendor Provided Software Solution

A 3-D Secure SDK typically needs to support the following services, described in 3-D Secure Functional Requirements – Merchant Server Plug-in:

• Creating CRReq, VEReq, and PAReq messages

• Processing CRRes, VEReq, and PARes messages

• Validating the signature on PARes messages

• Optionally, maintaining a local cache of participating card ranges, based on data supplied in CRRes messages

• Communicating with the Visa Directory Server (may be optional; can be provided by most commerce server platforms)

Custom Software Development

Merchants who desire to develop their own custom software for participation in the 3-D Secure service can obtain copies of the following documents:

• 3-D Secure Protocol Specification – Core Function

• 3-D Secure Functional Requirements – Merchant Server Plug-in

Development of the MPI does not require the use of any proprietary algorithms or software. Many of the software components required to develop a custom 3-D Secure implementation can be downloaded from the Internet (for example, from www.openssl.org) free of charge. If the Merchant has adequate software engineering resources, the development of customized software is a feasible option to pursue.

After development, but prior to moving the customized MPI software into its production environment, the Merchant will be required to successfully complete testing to prove compliance with Visa International’s requirements. Details of the required testing are defined in 3-D Secure Compliance Testing Facility – Policies and Procedures.

Custom software development of the MPI may be the ideal solution for Merchants with highly customized commerce environments. Merchants pursuing this option must possess adequate project management and engineering resources to plan, analyze, and implement the 3-D Secure protocol.

Acquirer Merchant Server Plug-in Service

Acquirers, particularly those currently operating front-end point-of-sale systems for their Merchants, may elect to enhance their traditional authorization and data capture transaction processing service offerings by adding support for 3-D Secure MPI functionality. By incorporating 3-D Secure into their front-end systems, an Acquirer can provide its Merchants with an additional service and enable them to participate in the 3-D Secure service with cost effective support for their commerce server application


http://www.openssl.org/


7.2 Hosted MPI Options

Acquirer Merchant Server Plug-in Service

When an Acquirer’s Internet commerce hosting platform is 3-D Secure enabled, every Merchant using that platform can leverage the capability to become 3-D Secure enabled.

Internet Payment Service Provider

Numerous Internet service providers offer services allowing Merchants to set up and run a Web site. Along with utilities to simplify the set-up and administration of the Web site, these service providers frequently partner with one or more payment service providers to offer support for the processing of online payments. In this model, the service provider typically develops and deploys software that is integrated with one or more Internet payment service provider or traditional Acquirer processing systems.

Internet Payment Gateway Service Provider

An Internet payment gateway typically provides a way for Internet Merchants to route an online payment transaction from the Merchant’s Web site to a legacy transaction processing system offered by a traditional brick-and-mortar payment processor. The payment gateway provides the bridge between the Internet systems of the Merchant and the legacy systems of the payment processor.

Internet gateway providers often partner with one or more payment processors to offer support for online payments process, as well as utilities to simplify the set-up and administration of online payments. In this model, the payment gateway provider has developed and deployed software that is integrated with one or more legacy payment processing systems.

As with the Internet payment service provider option, when an Internet payment gateway provider’s payment platform is 3-D Secure enabled, every Merchant using that platform has the capability to become 3-D Secure enabled.



8 Merchant Authentication and Transport Security

Organization This chapter:

• Describes the process for authenticating Merchants to the Visa Directory Server for 3-D Secure processing

• Defines the requirements for securing the channels across which 3-D Secure messages flow to and from the Acquirer Domain.

Visa Root Certificate

The Visa Root Certificate is required by the Merchant for the process of validating the signature of the Issuer contained in the Payer Authentication Response message. The Merchant or commerce server provider obtains this certificate from Visa U.S.A. concurrent with the return of the signed Merchant Certificate (see below). The MPI must be able to import and securely store the Visa Root Certificate.

8.1 Merchant Authentication

Authentication via Merchant Certificate

U.S. Merchants will be authenticated to the Visa Directory Server in 3-D Secure by use of a Visa-rooted client digital certificate that the Merchant presents to the Visa Directory when attempting a connection. The Merchant Certificate is required by the Directory Server before allowing a connection to process either CRReq or VEReq messages.

Visa U.S.A. must receive authorization from the Merchant’s Acquirer before a client certificate signed by the Visa root will be processed. Merchants should contact their Acquirer for information about 3-D Secure client certificates. Merchants that operate their own commerce servers and connect directly to the Directory Server must obtain a Visa-signed client certificate.

Acquirers, at their discretion, may contract with a Third-Party Processor that hosts multiple Merchants signed by that Acquirer. The Acquirer may approve the issuance of a Visa-signed client certificate to the Processor for all of the Acquirer’s Merchants. Alternatively, the Acquirer may require the Processor to support client certificates for each Merchant processed for that Acquirer.

Note: Individual client certificates must be used for each Merchant whose business requires a Merchant Category Code (MCC) within the High Risk Sponsored Merchant program. Additionally, a separate Visa client certificate must be used for each high risk Internet Payment Service Provider (IPSP).



8.2 Transport Security

Introduction All 3-D Secure messages depend upon transport security to provide

confidentiality. Prior to the transmission of a data message between 3-D Secure components, the channel over which the message is transmitted must be secured through the establishment of an SSL session using an SSL/TLS Server Certificate. Typically, Merchants with existing web sites will have obtained such certificates during the ordinary course of business. If not, the operator of the MPI must obtain an SSL/TLS Server Certificate from a commercial certificate authority. This is the same SSL/TSL certificate used to support secure SSL sessions with customers.

There are two channels in 3-D Secure processing to which the Merchant is a party. These channels, and the component responsibility for securing each channel, are described separately below.

Cardholder to Merchant

The channel between the cardholder and the Merchant transmits:

• The cardholder’s payment information to the Merchant,

• The Payer Authentication Request message from the MPI through the cardholder device to the Access Control Server (ACS), and

• The Payer Authentication Response message from the ACS through the cardholder device to the MPI.

The Merchant commerce server must secure this channel with an SSL session initiated using its SSL/TLS Server Certificate.

Merchant to Visa Directory Server

After validating the Merchant Certificate, Visa Directory Server secures the channel with the Merchant Server Plug-in and transmits:

• The MPI’s optional request for card range (CRReq) data to the Visa Directory Server, and the Visa Directory Server’s response (CRRes), so that the MPI can refresh its internal cache of card ranges participating in 3-D Secure;

• The MPI’s query about the availability of 3-D Secure processing for a specific cardholder (VEReq), and the response (VERes) indicating whether 3-D Secure authentication is available for the cardholder.

The Visa Directory Server will secure this channel with an SSL session using its SSL/TLS Server Certificate.



9 Planning and Implementation

Overview This chapter provides an example of the planning and implementation steps for Merchants who purchase a Merchant Server Plug-in to integrate with the Web storefront software at their location.

9.1 Assessment and Preparation

Decide to Participate

In this phase, Merchants determine their interest in participating in the 3-D Secure service. This process begins with a joint review between the Merchant and its Acquirer or commerce server provider of the features and benefits of the 3-D Secure service and the requirements for participation.

Review Activities

Following the Merchant’s decision to participate, the Merchant conducts an initial review of the major activities to be performed and the necessary skills and disciplines required to plan and execute the 3-D Secure implementation process.

Establish Project Team

A project team is established that includes a business manager, a project manager, and representatives of various functional areas; including marketing, legal, operations, customer support, risk, and information technology.

Develop Project Plan

A project plan is created which defines the major activities, tasks, dependencies, dates, and resources required to produce the deliverables to implement the 3-D Secure service within the Merchant’s environment. Some of the key activities and tasks that will require attention are:

• Develop the schedule for interim checkpoint reviews of the project plan.

• Determine MPI implementation location, that is, at the Merchant, payment service provider, or Acquirer.

• Select software vendor, install, integration, and test the MPI, if applicable.

• Develop dispute resolution procedures.

• Obtain Merchant Client Certificate, URL of the primary and secondary production Visa Directory Servers, and the Visa GP2 and eCommerce Root Certificates from the Acquirer.

• Develop production rollout plan.



9.2 Merchant MPI Software Selection

Obtain names of Software Solution Providers

The Merchant obtains from www.visa.com/verifiedvendors a list of software solution providers who have developed 3-D Secure Merchant Server Plug-in (MPI) software and have successfully completed the required Visa compliance testing, as defined in 3-D Secure Compliance Testing Facility – Policies and Procedures.

Identify Technical Team

The Merchant identifies the technical team responsible for the evaluation of the software of the 3-D Secure technology solution providers.

Evaluate Solutions

The MPI software vendors present their respective solutions and associated Merchant integration process documentation to the Merchant for review and discussion. Joint review of the software options and the completed Merchant environmental will help the Merchant to select the software that best matches the business and technology needs.

A key aspect in the selection of the MPI will be an assessment of its compatibility, and integration requirements, with the Merchant’s existing software. Modifications to existing Merchant software to implement the 3-D Secure service will vary based on a given Merchant’s commerce server installation and the Merchant Server Plug-in software solution chosen. At a minimum, the Merchant commerce server must be able to perform the following functions to enable it for 3-D Secure processing:

• Prepare all data relevant to the authentication and ensure the data is made available in the form where the final “Buy” page or “Check Out” button is present.

• Present authentication data to the Merchant Server Plug-in; the method for doing so being determined by the specific software functionality, attributes of a vendor MPI, and by the Merchant’s existing commerce server environment.

• Handle the return values presented by the Merchant Server Plug-in after the MPI receives the authentication response message.

Select Solution

The Merchant selects the software product that best enables the Merchant’s participation in the 3-D Secure service. After appropriate review, the Merchant executes the vendor’s software license agreement. This agreement should detail the vendor’s commitment to provide support, either under the license agreement or separate professional services agreement, for software installation and future software upgrades as required by the Merchant.




9.3 MPI Technical Review

Conduct Technical Review

The Merchant technical team should complete a thorough review of the vendor’s documentation and identify any outstanding questions or issues. Most vendors provide extensive documentation and various installation tools that expedite the implementation process.

9.4 Software Installation Planning

Decide who Install Software

Based on the outcome of technical reviews with the vendor and internal assessment of options, the Merchant will decide who will install the MPI software. In most instances, the options for installation are the Merchant’s internal engineering resources, contracted resources, or execution of a professional services agreement with the software vendor. Once this decision is made, the process of installing the 3-D Secure software can begin.

Define Resources

If the Merchant elects to implement the software with internal resources, the Merchant needs to ensure agreement with the technology provider as to the level of support that the vendor will make available. Conversely, if the Merchant decides to have contracted resources or the vendor install the software, the Merchant should identify a technically proficient staff resource to liaise with the contracted resources or the vendor regarding questions specific to the Merchant environment and to monitor the progress of software installation.

Obtain Necessary Configuration Data Elements from Acquirer

Several data elements will be required for configuration of the Merchant software, including:

Acquirer BIN – This is a six-digit field that identifies the acquiring bank to Visa. This information should be obtained directly from the Merchant’s acquirer contact.

Merchant ID – This is a unique number assigned to the Merchant by its Acquirer to identify that Merchant within the authorization and settlement processes. This information should be obtained directly from the Merchant’s acquirer contact.

Merchant URL – This is the Merchant’s fully qualified URL (such as, https://www.merchantname.com)

Also, it is important to review the software installation documentation for a complete list of data elements and how they are used in the configuration process.


https://www.merchantname.com/


Obtain Specifications for VisaNet Authorization Changes

Authorization requests must be modified to include the correct ECI and CAVV values in the message. Specifications should be obtained from the Merchant’s authorization processor and included in the project plan.

9.5 Software Integration

Develop Integration Plan

A detailed MPI software integration plan is created, listing the detailed implementation tasks to be completed, estimated start and completion dates, and the resource responsible for completion of each activity.

Install Software

The responsible parties perform the defined tasks necessary to install the software in the Merchant’s development environment. After installation, testing will be conducted to ensure the quality of the integration of the vendor software before moving it into production.

Implement Required Changes

The Merchant will need to identify, plan, schedule, and execute all required changes to server configurations, DNS, routing tables, firewalls, procedures, and other operational matters.

Implement Authorization Changes

Complete updates to authorization processing to include VisaNet fields required for Verified by Visa.

9.6 Testing

Perform Unit Testing

The Merchant performs unit testing to ensure that the software was successfully installed. During unit testing, the Merchant software communicates with test servers to simulate 3-D Secure transaction processing.

Perform Other Internal Testing

After unit testing has been successfully completed, the Merchant performs additional testing according to internal requirements and testing procedures, including regression, stress, and QA testing.



Conduct Product Integration Testing (PIT)

Merchants operating MPIs, and third parties operating MPIs on behalf of Merchants, are required to evidence proof of the production readiness of their MPI implementation prior to entering live production in the 3-D Secure service.

Visa provides the Product Integration Testing (PIT) facility to test the production readiness of MPI implementations prior to entry into production 3-D Secure. When conducting the required PIT testing, Merchants must read and follow the Test Plan exactly. To ensure that PIT testing has been successfully completed, the Merchant must make sure that its website has provided the expected behavior as specified in each test case, and that no exceptions were noted by the PIT during its review of the 3-D Secure messages generated and sent by the Merchant. For further information about PIT, see Chapter 1, the Resources and Tools section.

9.7 Pre-Production and Production Launch

Introduction Completion of successful testing will ensure Merchant confidence that the

3-D Secure software functionality and its integration into the Merchant commerce server are yielding the expected results, and that the Merchant’s processing environment is stable.

The implementation project is now ready to proceed with the final pre-production steps described below.

Set Date for Production

Step 1. Determine a production date and request that the Acquirer have necessary Merchant data populated in the Visa Directory Server by that date.

Obtain Data from Acquirer

Step 2. Request authorization from the Acquirer to receive: The URL of the production Visa Directory Server. A URL for both a primary and secondary production Visa Directory Server must be obtained and installed in the MPI. The MPI must automatically fallback to the secondary production Visa Directory Server in the event the primary Visa Directory Server is temporarily not available. The Visa-signed Merchant Client Certificate and both the GP2 and eCommerce Visa Root Certificates.

Details on how to obtain the Verified by Visa Merchant Mark Brand Identity Guidelines and the Verified by Visa Merchant Symbol are also available from the Merchant’s Acquirer.



Install Merchant Certificate

Step 3. Arrange for Acquirer to approve Merchant certificate application. Generate client certificate and forward to Visa U.S.A. Visa signs the client certificate with the Visa Root key and returns it for installation in the MPI.

Install Visa Root Certificates

Step 4. Install two Visa Root Certificates in the MPI: the GP2 root certificate and the eCommerce root certificate. The Visa Root Certificate is used to validate the digital certificate in PARes messages. Both Visa root certificates – GP2 and eCommerce – must be installed in the MPI.

All Visa certificates are currently issued under the GP2 root. However, starting October 1, 2004, Visa will begin transitioning to certificates issued under the under the new eCommerce root. After that date, Issuers that obtain signing certificates from Visa will receive certificates issued under the new eCommerce root, and Merchants will begin to receive PARes messages signed by Issuers using the new eCommerce-rooted signing certificates. Therefore, until all existing GP2 certificates expire in October, 2006, some Issuers will use GP2 signing certificates to sign the PARes messages, while other Issuers will use eCommerce signing certificates. Merchants must install both root certificates in order to be able to validate the digital signatures on PARes messages for all Issuers. Visa strongly recommends that all existing Merchant implementations download and install the new eCommerce root certificate immediately. Merchants can test that both the eCommerce and GP2 root certificates have been loaded correctly using the Visa Product Integration Testing facility (see Section 9.6 above).

Both the GP2 and eCommerce Visa Root Certificates are returned with the signed Merchant Certificate by Visa U.S.A., and may also be obtained from the Visa website at:

http://www.international.visa.com/fb/downloads/rootcert/main.jsp

Point MPI to Visa Directory Server

Step 5. Make necessary code changes to enable the MPI software to point to the production Visa Directory Server. Configure the MPI to fall over automatically to the secondary Visa production Directory Server in the event that the primary Visa Directory Server is not available.

Go Live/ Review Authorization Logs

Step 6. Commence processing in the production 3-D Secure service. Merchants should confirm with their authorization and settlement processors that all Verified by Visa data elements have been correctly processed for the CPS/e-Commerce Preferred rate and chargeback protection.


http://www.international.visa.com/fb/downloads/rootcert/main.jsp


9.8 Pre-Production Implementation Checklist Introduction Merchants must successfully complete all of the items on the Checklist provided

below before deploying Verified by Visa in production. Merchants should use the Checklist to conduct a pre-production review of their implementation to ensure a successful implementation and compliance with the Verified by Visa Product Rules. Visa also strongly recommends that Merchants review their adherence to the items on the checklist should the Merchant make subsequent, significant changes to its implementation of 3-D Secure or to its checkout process.

Item Description/Reference

Acquirer submitted VV to Visa

Required: 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. See Section 6.1, Acquirer Responsibility for Merchant Participation and Section 1.3 Resources and Tools, Production Certificate Request Documents.

CISP Compliance

Required: Website is CISP-compliant. If the MPI will be hosted by a third party or an Internet Payment Service Provider, a third-party CISP audit may be required, and sufficient lead time should be allocated for completion of this task. See Section 6.1, Acquirer Responsibility for Merchant Participation and Section 1.3 Resources and Tools, Production Certificate Request Documents.

Digital Certificate Installed

Required: Acquirer approval has been obtained for each requested production Merchant Client Authentication certificate and the certificates have been installed and tested. Merchant has installed both the GP2 and eCommerce Visa root certificates. See Section 1.3 Resources and Tools, Production Certificate Request Document,Section 8.1, Merchant Authentication, and Section 9.7, Pre-Production and Production Launch.

Continued on next page.




Inline Presentation Required: Presentation of Verified by Visa is inline. See Sections 6.3, 6.5, 6.6, and 6.7.

3-D Secure Timeout Values

Required: Merchant has set appropriate timeout values for receipt of VERes and PARes messages. See Section 6.11, Merchant Performance Standards.

Pre-Authentication Messaging

Required: Merchant provides messaging, that follows Visa guidelines, to the cardholder prior to the initiation of Verified by Visa processing. See Section 6.4, Pre-Authentication Messaging.

Framed Implementation

Text

Required: For framed implementations only, a brief communication to customers about Verified by Visa is presented outside of the frame for the authentication page. See Section 6.7, Text for Inline Page with a Framed Window.

Framed Implementation Status Indicator

Best Practices: For framed implementations only, a “processing” indicator with a simple movement is provided outside of the frame for the authentication page. See Section 6.7, Text for Inline Page with a Framed Window.

Authentication Failure Messaging

Required: Verified by Visa-specific messaging for authentication failures that follows Visa guidelines has been implemented. The cardholder is provided a smooth method for reinitiating the transaction using (the same or) a different payment card. See Section 6.10, Authentication Failure Processing.

Authentication Failure Processing

Best Practices: The cardholder is provided a smooth method for reinitiating the transaction using (the same or) a different payment card, and the Verified by Visa “learn more” logo is provided on the “Failed Authentication” page. See Section 6.10, Authentication Failure Processing.

VbV Merchant Symbol

Required: Verified by Visa Merchant Symbol is installed on the checkout page. See Section 6.8, Verified by Visa Information via Merchant Symbol.

“Activate Now” Link

Best Practice: “Activate Now” button/link is installed correctly on at least one Merchant page. See Section 6.9, Activation Anytime.

VbV Message Values

Required: Data is populated accurately in all 3-D Secure message fields. See Section 6.16, Data Quality in VEReq and PAReq Messages.

Continued on next Page




Monitoring Required: MPI is integrated into Merchant’s production monitoring processes. See Section 5.2, Additional MPI Functional Requirements: Monitoring.

Customer Support Training

Required: Customer support staff have received Verified by Visa training. See Section 6.16, Merchant Customer Support.

Authorization Processing

Required: Merchant correctly populates Verified by Visa data in the authorization message. See Section 4.5,Authorization Processing.

Visa Directory Server URLs

Required: Merchant has configured the MPI with both the primary and secondary URLs for the Visa Production Directory Server. See Section 5.2, Additional MPI Functional Requirements, and Section 9.7, Pre-Production and Production Launch.

PIT Testing Required: PIT testing has been successfully completed. See Section 1.3 Resources and Tools, Product Integration Testing (PIT) Facility Documents.



Appendix A: Glossary

Term Description

3-D Secure An e-commerce protocol that enables the secure processing of payment card transactions in an open network environment, such as the Internet.

Access Control Server (ACS)

A server that operates in the Issuer Domain, verifies whether authentication is available for a card number, and authenticates specific transactions.

Acquirer A Visa member financial institution that establishes a contractual service relationship with a Merchant for the purpose of accepting Visa cards. In 3-D Secure, the Acquirer determines whether Merchant is eligible to participate and performs the traditional role of receiving and forwarding authorization and settlement messages.

Acquirer BIN A six digit unique identifier for the Acquirer that is assigned and recognized by Visa.

Acquirer Domain Contains the systems and functions of the Acquirer and Merchants.

ACS See Access Control Server.

AHS See Authentication History Server.

Attempts or Attempted Authentication

The process by which the proof of an authentication attempt is generated when payment authentication is not available. Attempted authentications are only supported with 3-D Secure version 1.0.2.

Authentication The process of verifying that the person making an e-commerce purchase is entitled to use the payment card.

Authentication History Server (AHS)

A component that operates in the Interoperability Domain; archives authentication activity for use by Acquirers and Issuers for dispute resolution and other purposes.

Authorization A process by which an Issuer, or a processor on the Issuer’s behalf, approves a transaction for payment.

Business ID (BID) An eight-digit identifier that Visa assigns to Members and approved Non-Member Processors and Service Providers.

BID See Business ID.



Term Description

Bank Identification Number (BIN)

The first six digits of a payment card account number that uniquely identify the issuing financial institution.

BIN See Bank Identification Number.

Cardholder The party that holds a Visa payment card.

Cardholder Authentication Verification Value (CAVV)

A cryptographic value generated by the ACS to provide a way during authorization processing for VisaNet to rapidly validate the integrity of certain values copied from the Payer Authentication Response to the authorization request and to prove that authentication occurred.

Cardholder software Optional cardholder software that may supplement the abilities of the browser. Chip card authentication, for example, requires cardholder software to operate the chip card reader.

CAVV See Cardholder Authentication Verification Value.

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 A trusted party that issues and revokes certificates.

Chip card A payment card with an integrated circuit chip that stores information about the account and user.

Core Protocol Refers to the protocol described in the publication: 3-D Secure Protocol Specification – Core Functions, Visa Publication 70000-01

Cryptography The process of protecting information by transforming it into an unreadable format. The information is encrypted using a key, which makes the data unreadable, and is later decrypted when the information needs to be used again.

Digital certificate See certificate.

Digital signature An asymmetric cryptographic method whereby the recipient of the data can prove the origin and integrity of data, thereby protecting the sender of the data and the recipient against modification or forgery by third parties and the sender against forgery by the recipient.

Directory Server See Visa Directory Server.

Interoperability Domain Facilitates the transfer of information between the Issuer and Acquirer Domain systems.



Term Description

Issuer A Visa member financial institution that issues Visa cards, contracts with cardholder to provide card services, determines eligibility of cardholder to participate in 3-D Secure, and identifies card number ranges eligible to participate in 3-D Secure.

Issuer Domain Contains the systems and functions of the Issuer and its customers (cardholders)

Key In cryptography, the value needed to encrypt and/or decrypt something

Merchant Entity that contracts with an Acquirer to accept Visa cards. Manages the online shopping experience with the cardholder, obtains card number, then transfers control to the Merchant Plug-in, which conducts payment authentication.

Merchant commerce server

A server hardware/software entity that handles online transactions and facilitates communication between the Merchant application and the Visa gateway.

Merchant Server Plug-in (MPI)

A component that operates in the Acquirer Domain; incorporated into the Merchant’s Web storefront to perform functions related to 3-D Secure on behalf of the Merchant, such as determining whether authentication is available for a card number and validating the digital signature in a 3-D Secure message.

MPI See Merchant Server Plug-in.

PAReq See Payer Authentication Request.

PARes See Payer Authentication Response.

PATransReq Payer Authentication Transaction Request; a record of authentication activity sent by the ACS to the Authentication History Server

PATransRes Payer Authentication Transaction Response; Authentication History Server response to PATransReq.

Payer Authentication Request (PAReq)

A message sent from the Merchant Server Plug-in to the Access Control Server via the cardholder’s device. Requests the Issuer to authenticate its cardholder and contains the cardholder, Merchant, and transaction-specific information necessary to do so.

Payer Authentication Response (PARes)

A message formatted, digitally signed, and sent from the Access Control Server to the Merchant Server Plug-in (via the cardholder’s device) providing the results of the Issuer’s 3-D Secure cardholder authentication.



Term Description

Payment gateway A third party that provides an interface between the Merchant and Acquirer’s payment system and VisaNet.

Secure Sockets Layer (SSL)

SSL: A cryptographic protocol developed to confidentially transmit information over open networks like the Internet. See also Transport Layer Security.

Smart card See chip card.

Split shipment A split shipment occurs when a single purchase order results in multiple shipments of purchased merchandise with multiple Visa Authorization Requests.

SSL See Secure Sockets Layer.

Three-Domain Secure See 3-D Secure.

Uniform Resource Locator

Address scheme for pages on the World Wide Web usually in the format http://address or https://address such as http://www.visa.com

URL See Uniform Resource Locator.

Validation Usually refers to validating the cryptographic signature passed in the message from the ACS to the Merchant.

VEReq See Verify Enrollment Request.

VERes See Verify Enrollment Response.

Verify Enrollment Request (VEReq)

Message from Merchant Server Plug-in to the Visa Directory Server or from Visa Directory Server to ACS, asking whether authentication is available for a particular card number

Verify Enrollment Response (VERes)

Message from ACS or Visa Directory Server, telling Merchant Server Plug-in whether authentication is available

Visa Directory Server A server hardware/software entity which is operated by Visa in the Interoperability Domain; it determines whether a specific card number is participating in 3-D Secure, and if so, it returns the URL of the appropriate Access Control Server to the Merchant Plug-in.

Visa Certificate Authority A component that operates in the Interoperability Domain; generates and signs digital certificates to entities participating in 3-D Secure.

VisaNet The systems and services, including the V.I.P and BASE II systems, through which Visa delivers online financial processing, authorization, clearing and settlement services to members.


http://address/

https://address/

http://www.visa.com/


Appendix B: Sample Merchant Project Plan

ID Task Name Resource

Merchant Assessment and Preparation: 3-D Secure Participation 1 Review of 3-D Secure service with Acquirer Acquirer and Merchant 2 Determine service fit with merchant strategy, goals, and priorities Merchant 3 Conduct preliminary technical solutions with potential service providers 4 Scope high-level resource requirements for 3-D Secure participation 5 Define success criteria 6 Make ‘Go’/’No Go’ participation decision 7 Identify project manager, technical lead, and project team candidates 8 Hold project ‘kick-off’ meeting Project Manager 9 Develop draft project plan 10 Merchant completes environment questionnaire Technical Lead 11 Detail review of 3-D Secure service options, software, and service providers Project Manager/Technical Lead 12 Selection of 3-D Secure product or service solution Merchant Implementation Planning 13 Determine implementation approach Merchant 14 Update merchant agreement with Acquirer for 3-D Secure participation Acquirer/Merchant 15 Merchant executes agreement with 3-D Secure solution provider Merchant/Solution Provider 16 Finalize of merchant 3-D Secure implementation project plan Project Manager 17 Conduct environmental questionnaire detailed review Technical Lead/Solution Provider 18 Define dispute resolution procedures Project Team 19 Develop reporting requirements 20 Identify process for integration of solution with merchant check-out processes Technical Lead/Solution Provider Testing 21 Complete installation and/or integration of 3-D Secure functionality Technical Lead/Solution Provider 22 Conduct merchant unit testing 23 Conduct end-to-end and connectivity testing 24 Test for accuracy of merchant 3-D Secure processing requirements 25 Conduct MPI compliance testing if required Merchant/Solution Provider/Visa 26 Execute agreements for testing in 3-D Secure System Test Facility 27 Conduct end-to-end/connectivity testing with 3-D Secure System Test Facility 3-D Secure Service Preparation and Activation 28 Complete CISP review Merchant/Visa 29 File Exhibit VV for any third-party service provider or IPSP Acquirer/Visa 30 Obtain merchant certificate for Verified by Visa operations Acquirer/Merchant/Visa 31 Update Web site pages with 3-D Secure notification to online shoppers Merchant 32 Conduct production readiness testing with the PIT Acquirer/Merchant/Visa 33 Point MPI to URL of production 3-D Secure Visa Directory Server Technical Lead/Solution Provider 34 Conduct final review for activation preparedness Project Manager 35 Activate merchant participation in 3-D Secure Merchant/Visa



Appendix C: Timeout Sequencing

Introduction 3-D Secure components need to be configured to a common timeout sequencing convention to ensure efficient, synchronized processing. Only as an exception should a Merchant Server Plug-in (MPI) ever time out the Visa Directory Server or the Visa Directory Server time out the Access Control Server (ACS).

Each link in the 3-D Secure chain progressively should have a lower timeout value than the previous component. Since the transaction originates with the MPI, the MPI should have a longer timeout value than the Visa Directory Server. Likewise, the Directory Server has a longer timeout value than the ACS.

VEReq/VERes Processing

The required timeout value for the MPI to send a VEReq and receive a VERes is ten seconds, as illustrated below. Allowing for up to one second for processing between the MPI and Visa Directory Server each way, the standard Visa Directory Server timeout value to send the VEReq and receive a VERes from the ACS is eight seconds. Conservatively assuming up to a one second transport each way, the ACS should normally respond within six seconds or less to the Visa Directory Server.

VisaDirectory

Issuer Domain Acquirer Domain

MERCHANT

Plug-in

AccessControl

InteroperabilityDomain

Issuer

<:08

:10

<:06

Figure: Timeout Sequencing

PAReq and PARes Processing

The Payer Authentication Request/Response message pair has a recommended timeout value of 5 minutes, recognizing that cardholders may become distracted while completing the authentication.



Appendix D: Authorization Requirements for CPS/ e-Commerce Qualification

CPS/e-Commerce Basic CPS/e-Commerce Preferred

• Purchase made via the Internet • Authorization Message Data:

- POS Processing Code (Field 3) must be 00 for purchase.

- POS Entry Mode (Field 22) must be 01 for Manual/Key Entry.

- POS Condition Code (Field 25) must be 59 for electronic commerce.

- Additional POS Info (BASE I 60.8 or SMS Field 63.6) must be an ECI 5, 6 or 7. Transactions with ECI of 8 or 9 are downgraded to ERIF.

- An Address Verification Service (AVS) inquiry must be supported for ZIP code or full address.

- An Authorization Characteristic Indicator (ACI) value in the Authorization Request must be value of Y for retail transactions and either Y or P for T&E transactions.

• Settlement Message Data: - ECI 7. Transactions with ECI 8 or 9 are

downgraded to ERIF. - An ACI Authorization Response value of W for

Retail or P for T&E as returned in the in BASE I/SMS Field 62.1.

• BASE II will assign Chargebacks Rights Indicators (CRIs) of 10 for T&E and 11 for Retail that block chargeback reasons not applicable to electronic commerce transactions (for example, missing signature).

Same requirements for CPS/e-Commerce Basic, plus:

• Authorization Message Data: - An ECI value 5 for authenticated or 6 for

attempted authentication in the authorization.

- The Authorization Request message includes valid CAVV data.

• Settlement Message Data: - An ECI value 5 for authenticated or

ECI 6 for attempted authentication in settlement.

- An Authorization Characteristic Indicator (ACI) in Authorization Response value of U for authentication transaction or S for attempted authentication as returned in BASE I/SMS Field 62.1.

• BASE II will assign Chargebacks Rights Indicators (CRIs) of 12 for T&E and 13 for Retail that block U.S. chargeback Reason Codes 23, 61 and 75 for unauthorized usage. These blocks apply to authenticated and attempted authentications that have met the CPS requirements for e-Commerce Preferred.

Visa Authorization Request Messages for CPS/e-Commerce Basic and CPS/e-Commerce Preferred

Important Notice to Acquirers/Merchants: Consistency of electronic commerce transaction data submitted in the Visa Authorization Request is important for CPS qualification. If either the Field 22, POS Entry Mode is not 01 for Manual Key Entry or Field 25, POS Condition Code, is not 59 to designate an electronic commerce transaction, the transaction will not qualify for CPS/e-Commerce status even if other electronic commerce or authentication data are included. If a CAVV is included in the authorization message, the ECI must be either a 5 or 6 to qualify for CPS/e-Commerce Preferred.



Appendix E: Activation Anytime

Activation Anytime is a capability designed to enable Issuers to activate cardholder at various Internet sites, including participating Merchants. It is easy for participating Merchants to implement support for Activation Anytime. The only requirement is the placement of Verified by Visa banners or buttons for Activation Anytime. When the cardholder clicks on the banner or button, the Verified by Visa Landing Page appears. The transaction flow is described below.

Step 1: Click to Activate. When cardholders click on a Verified by Visa banner or button for Activation Anytime, the Activation Anytime Landing Page appears. This page provides a brief description of Verified by Visa and benefits to the cardholder for activating their Visa card. Figure 15 shows this page.

Figure 15. Activation Anytime Landing Page

Cardholders are given the opportunity to enter their Visa card numbers to activate immediately. When the card number is entered, the cardholder is presented with one of several pages: an Issuer activation page or an Issuer enrollment page. If the Issuer is not participating in Verified by Visa, a “Service Not Available” page is presented. These pages are illustrated in the following sections.



Step 2: Verify Identity and Activate. When customers enter their card numbers, the Activation

Anytime server performs a validity check that it is a valid Visa card number and that the Issuer support activation. The customer is then presented with the Issuer’s activation page. Figure 16 shows an example of a typical activation page. The Issuer may request identity information or a pre-existing password, such as an online banking password, to authenticate the cardholder.

Figure 16. Sample Issuer Activation Page

After completing the authentication process, the cardholder creates a password for on-going use at participating Merchants. Figure 17 illustrates a typical create password page.



Step 3: Create Password. To complete the activation, the cardholder is requested to create a password for use at participating online Merchants. Figure 17 shows a sample Create Password Page.

Figure 17. Sample Password Creation Page

Once entry and confirmation of the password are completed, the cardholder is presented with an Activation Successful Page, as shown in Figure 18.



Step 4: Confirm Activation Successful. After the activation is completed, the cardholder is presented with a confirmation page that the activation was successful. Figure 18 illustrates this page.

Figure 18. Activation Successful Page

Upon clicking the Close button, the cardholder is returned to the Merchant site.

If an Issuer does not support activation, the cardholder is presented with an Issuer enrollment page. Figure 19 shows a sample of this type of page.



Step 5: Issuer Enrollment Page. If the Issuer does not support Activation Anytime, the customer is first presented with a Visa-hosted “Transferring to Your Card Issuer Website” message, then automatically directed to the appropriate Issuer activation website. Figure 19 shows a sample page at an Issuer Activation website. After the cardholder completes the card activation process and creates a password, the cardholder can close the activation website browser window to arrive at the online store where the process originated. Note: the online store is always accessible to the cardholder.

Figure 19. Issuer Activation Website Page

Note: Non-Participating Issuer. If the Issuer does not participate in Verified by Visa, the customer is presented with a “Verified by Visa Not Available for This Card” page and returned to the Merchant site.



What’s Required for Merchants to Support Activation Anytime Participating Merchants may support Activation Anytime by displaying Visa-provided signage for Activation Anytime. When the cardholder clicks on the signage, a secure Activation Anytime browser window will be opened with the Visa URL visible and SSL lock displayed with the corresponding Visa digital certificate information. These security cues are important for customers to be able to ensure that they are connecting to the authentic www.verified.visa.com server – helping to reassure customers of the confidentiality of their information.

As shown in Figure 1, the browser window is smaller than a full browser window, so the customer maintains visibility of the Merchant site. When the browser window is closed, the customer automatically returns to the Merchant site.

The Verified by Visa signage for Activation Anytime is available. Acquirers and Merchants may request information and guidelines by email at .


http://www.verified.visa.com/


Appendix F: Suggested Procedures for Dispute Resolution Overview The following guidelines are designed to assist U.S. Members in establishing dispute resolution procedures for electronic commerce transactions involving Verified by Visa, both authentications and attempted authentications. The guidelines discuss procedures to determine if a disputed electronic commerce transaction is eligible for Representment by the Acquirer, based on certain data fields in the transaction record. Additionally, procedural differences for U.S. and International transactions are highlighted.

Operating Regulations The Visa U.S.A. and Visa International Operating Regulations specify that Issuers may not charge back electronic commerce transactions under the following conditions:

• The cardholder indicates that he/she did not authorize or does not recognize the purchase and the transaction involved either a 3-D Secure authentication or attempted authentication.

When an Acquirer receives a Chargeback under one of the reason codes below, additional research may be required. To streamline the research process, it is recommended that an Acquirer implement the dispute resolution procedures in the following section.

U.S. Chargeback: • Reason Code 23 – T&E Invalid Transaction • Reason Code 61 – Fraudulent Mail/Phone Order/Electronic Commerce • Reason Code 75 – Cardholder Does Not Recognize Transaction

International Chargeback: • Reason Code 23 – T&E Invalid Transaction • Reason Code 75 – Cardholder Does Not Recognize Transaction (effective 10/04) • Reason Code 83 – Fraudulent Mail/Phone Order/Electronic Commerce

For other Chargeback Reason Codes for electronic commerce transactions, Acquirers should follow existing dispute resolution procedures.


Verif

ied

by V

isa

3-D

Sec

ure

Acqu

irer a

nd M

erch

ant I

mpl

emen

tatio

n G

uide

Acq

uire

rs: S

ugge

sted

Pro

cedu

res

for

Dis

pute

Res

olut

ion

Whe

n an

Issu

er c

harg

es b

ack

a tr

ansa

ctio

n as

not

rec

ogni

zed

or o

ne n

ot c

ondu

cted

by

the

card

hold

er, A

cqui

rers

can

det

erm

ine

the

stat

us o

f th

e tr

ansa

ctio

n by

rese

arch

ing

the

Ele

ctro

nic

Com

mer

ce In

dica

tor

(EC

I) a

nd C

ardh

olde

r A

uthe

ntic

atio

n V

erifi

catio

n V

alue

(CA

VV

) Res

ult

Cod

e in

the

auth

oriz

atio

n m

essa

ge.

Sugg

este

d re

sear

ch s

teps

are

sum

mar

ized

bel

ow.

EC

I 5:

Car

dhol

der

auth

enti

cate

d by

the

Issu

er u

sing

3-D

Sec

ure

(Ver

ifie

d by

Vis

a).

Act

ion

Step

s : C

heck

the

CA

VV

Res

ults

Cod

e in

BA

SEI/S

MS

Fiel

d 44

.13

to d

eter

min

e if

a va

lid C

AV

V w

as in

clud

ed in

the

auth

oriz

atio

n m

essa

ge.

If

For

U.S

. Tra

nsac

tion

s F

or I

nter

nati

onal

Tra

nsac

tion

s Th

e C

AV

V R

esul

ts

Cod

e sh

ows

“pas

sed

verif

icat

ion”

– a

val

id

CA

VV

C

AV

V R

esul

t Cod

e:

2 or

D

The

Cha

rgeb

ack

indi

cate

s th

at th

e tra

nsac

tion

did

not q

ualif

y fo

r C

PS

/e-C

omm

erce

Pre

ferre

d an

d ch

arge

back

blo

ckin

g. T

he m

ost

likel

y re

ason

is th

at th

e se

ttlem

ent t

rans

actio

n w

as n

ot s

ubm

itted

w

ithin

the

timef

ram

e re

quire

d fo

r CP

S q

ualif

icat

ion.

Be

caus

e th

e A

utho

rizat

ion

Res

pons

e in

clud

ed th

e EC

I 5 a

nd a

va

lid C

AV

V, t

he tr

ansa

ctio

n is

elig

ible

for R

epre

sent

men

t.

Doc

umen

tatio

n m

ust i

nclu

de a

cop

y of

the

trans

actio

n re

cord

sh

owin

g th

e E

CI a

nd v

alid

CA

VV

.

The

trans

actio

n is

will

be

bloc

ked

for C

harg

ebac

ks b

y th

e no

n-U

.S.

Issu

er; h

owev

er, t

he A

cqui

rer m

ay re

ceiv

e a

Pre

-Com

plia

nce

actio

n.

If th

e A

cqui

rer’s

rese

arch

con

firm

s th

e E

CI 5

and

val

id C

AV

V in

th

e A

utho

rizat

ion

Res

pons

e, th

e A

cqui

rer s

houl

d re

spon

d to

the

Pre

-Com

plia

nce

actio

n w

ith “C

AV

V IN

AU

TH” a

nd p

rovi

de a

cop

y of

the

Aut

horiz

atio

n R

espo

nse

mes

sage

sho

win

g th

e E

CI 5

and

va

lid C

AV

V R

esul

ts C

ode.

If

the

CA

VV

Res

ults

C

ode

show

s th

e C

AV

V

was

not

incl

uded

or

was

inva

lid

CA

VV

Res

ult C

ode:

B

lank

, 0 o

r B

Thes

e C

AV

V R

esul

t Cod

es in

dica

te th

at th

e tra

nsac

tion

does

not

qu

alify

for R

epre

sent

men

t unl

ess

the

mer

chan

t sub

mitt

ed

auth

entic

atio

n da

ta, e

xact

ly a

s re

ceiv

ed fr

om th

e Is

suer

. A

cqui

rers

sh

ould

rese

arch

the

Ver

ified

by

Vis

a A

uthe

ntic

atio

n R

espo

nse

rece

ived

by

the

mer

chan

t: •

If th

e C

AV

V in

the

auth

entic

atio

n re

cord

was

mis

sing

(rea

son

why

it w

as n

ot in

clud

ed in

the

auth

oriz

atio

n m

essa

ge),

or

• M

atch

es e

xact

ly w

ith th

e C

AV

V in

the

Vis

aNet

Aut

horiz

atio

n R

eque

st

The

Acq

uire

r may

pro

cess

a R

epre

sent

men

t with

doc

umen

tatio

n th

at in

clud

es a

cop

y of

the

Ver

ified

by

Vis

a tra

nsac

tion

reco

rd

show

ing

the

CA

VV

Fie

ld a

nd a

cop

y of

the

Aut

horiz

atio

n R

eque

st

show

ing

the

sam

e co

nten

ts o

f the

CA

VV

Fie

ld.

The

trans

actio

n is

will

be

bloc

ked

for C

harg

ebac

ks b

y th

e no

n-U

.S.

Issu

er; h

owev

er, t

he A

cqui

rer m

ay re

ceiv

e a

Pre

-Com

plia

nce

actio

n.

If th

e A

cqui

rer’s

rese

arch

con

firm

s th

at th

e C

AV

V R

esul

ts C

ode

is

Bla

nk* o

r has

a v

alue

of 0

* or B

, thi

s tra

nsac

tion

is n

ot e

ligib

le fo

r ch

arge

back

pro

tect

ion.

The

Acq

uire

r sho

uld

proc

ess

a cr

edit

to

the

Issu

er.

* Th

e A

cqui

rer s

houl

d re

sear

ch th

e 3-

D S

ecur

e A

uthe

ntic

atio

n R

espo

nse

to d

eter

min

e if

the

CA

VV

Fie

ld w

as p

rovi

ded

by th

e Is

suer

was

eith

er m

issi

ng o

r the

sam

e as

that

sub

mitt

ed in

the

Aut

horiz

atio

n. I

f so,

the

Acq

uire

r may

repr

esen

t with

a c

opy

of

the

Aut

hent

icat

ion

Res

pons

e sh

owin

g th

at th

e C

AV

V F

ield

was

su

bmitt

ed in

the

Aut

horiz

atio

n ex

actly

as

retu

rned

by

the

Issu

er.

If th

e C

AV

V R

esul

ts

Cod

e sh

ows

“faile

d ve

rific

atio

n” b

ut th

e au

thor

izat

ion

was

ap

prov

ed

CA

VV

Res

ult C

ode:

1.

The

CA

VV

Res

ults

Cod

e in

dica

tes

that

the

Issu

er a

ccep

ted

the

risk

of a

uthe

ntic

atio

n da

ta th

at c

ould

not

be

verif

ied.

The

Acq

uire

r m

ay s

ubm

it a

Rep

rese

ntm

ent w

ith d

ocum

enta

tion

of A

utho

rizat

ion

Req

uest

sho

win

g th

e C

AV

V R

esul

ts C

ode

faile

d ve

rific

atio

n va

lue.

The

trans

actio

n is

will

be

bloc

ked

for C

harg

ebac

ks b

y th

e no

n-U

.S.

Issu

er; h

owev

er, t

he A

cqui

rer m

ay re

ceiv

e a

Pre

-Com

plia

nce

actio

n.

If th

e A

cqui

rer’s

rese

arch

con

firm

s th

e fa

iled

CA

VV

Res

ults

Cod

e,

this

tran

sact

ion

is e

ligib

le fo

r Rep

rese

ntm

ent.

The

Acq

uire

r sho

uld

prov

ide

the

Issu

er w

ith d

ocum

enta

tion

of th

e Au

thor

izat

ion

Res

pons

e sh

owin

g th

e EC

I, Ap

prov

ed R

espo

nse

and

faile

d C

AVV

Res

ult C

ode.

April

200

4 Vi

sa *C

onfid

entia

l* 79

N

otic

e: T

his

docu

men

t con

tain

s Vi

sa’s

pro

prie

tary

info

rmat

ion

for u

se b

y Vi

sa M

embe

rs’ V

isa

card

pro

gram

s. D

iscl

osur

e to

third

par

ties

or a

ny o

ther

use

is p

rohi

bite

d w

ithou

t the

prio

r w

ritte

n pe

rmis

sion

of V

isa

U.S

.A. I

nc.

Verif

ied

by V

isa

3-D

Sec

ure

Acqu

irer a

nd M

erch

ant I

mpl

emen

tatio

n G

uide

E

CI

6: A

pur

chas

e in

whi

ch a

mer

chan

t att

empt

ed to

aut

hent

icat

e th

e ca

rdho

lder

usi

ng th

e 3-

D S

ecur

e te

chno

logy

pla

tfor

m,

but t

he I

ssue

r or

car

dhol

der

did

not p

arti

cipa

te.

Act

ion

Step

s : C

heck

the

CA

VV

Res

ults

Cod

e in

BA

SEI/S

MS

Fiel

d 44

.13

to d

eter

min

e if

a va

lid C

AV

V w

as in

clud

ed in

the

auth

oriz

atio

n m

essa

ge.

If

For

U.S

. Tra

nsac

tion

s F

or I

nter

nati

onal

Tra

nsac

tion

s

The

CA

VV

Res

ults

C

ode

show

s “p

asse

d ve

rific

atio

n” –

a v

alid

C

AV

V

CA

VV

Res

ult C

ode:

3,

6, 8

, A o

r C.

The

Cha

rgeb

ack

indi

cate

s th

at th

e tra

nsac

tion

did

not q

ualif

y fo

r C

PS

/e-C

omm

erce

Pre

ferre

d an

d ch

arge

back

blo

ckin

g. T

he m

ost

likel

y re

ason

is th

at th

e se

ttlem

ent t

rans

actio

n w

as n

ot s

ubm

itted

w

ithin

the

timef

ram

e re

quire

d fo

r CP

S q

ualif

icat

ion.

Be

caus

e th

e A

utho

rizat

ion

Res

pons

e in

clud

ed th

e EC

I 6 a

nd a

va

lid C

AV

V, t

he tr

ansa

ctio

n is

elig

ible

for R

epre

sent

men

t.

Doc

umen

tatio

n m

ust i

nclu

de a

cop

y of

the

trans

actio

n re

cord

sh

owin

g th

e E

CI a

nd v

alid

CA

VV

.

Tran

sact

ions

with

EC

I 6 a

re b

lock

ed fo

r Cha

rgeb

acks

whe

n th

e Is

suer

doe

s no

t pro

vide

sup

port

for a

ttem

pted

aut

hent

icat

ions

. Tr

ansa

ctio

ns w

ith a

n E

CI 6

may

be

char

ged

back

if th

e Is

suer

do

es o

ffer s

uppo

rt fo

r atte

mpt

ed a

uthe

ntic

atio

ns.

The

Acq

uire

r sh

ould

rese

arch

Cha

rgeb

acks

with

an

EC

I 6.

If th

e A

cqui

rer’s

rese

arch

con

firm

s th

e E

CI 6

and

val

id C

AV

V in

th

e A

utho

rizat

ion

Res

pons

e, th

e A

cqui

rer s

houl

d su

bmit

a R

epre

sent

men

t and

pro

vide

doc

umen

tatio

n: M

embe

r Mes

sage

Te

xt “C

AV

V IN

AU

TH” a

nd a

cop

y of

the

Vis

aNet

Aut

horiz

atio

n R

espo

nse

show

ing

the

EC

I 6 a

nd v

alid

CA

VV

Res

ults

Cod

e.

If th

e C

AV

V R

esul

ts

Cod

e sh

ows

the

CA

VV

w

as n

ot in

clud

ed o

r w

as in

valid

C

AV

V R

esul

t Cod

e:

Bla

nk, 0

or B

.

Thes

e C

AV

V R

esul

t Cod

es in

dica

te th

at th

e tra

nsac

tion

does

not

qu

alify

for R

epre

sent

men

t unl

ess

the

mer

chan

t sub

mitt

ed

auth

entic

atio

n da

ta, e

xact

ly a

s re

ceiv

ed fr

om th

e Is

suer

. A

cqui

rers

sh

ould

rese

arch

the

Ver

ified

by

Vis

a A

uthe

ntic

atio

n R

espo

nse

rece

ived

by

the

mer

chan

t: •

If th

e C

AV

V in

the

auth

entic

atio

n re

cord

was

mis

sing

(rea

son

why

it w

as n

ot in

clud

ed in

the

auth

oriz

atio

n m

essa

ge),

or

• M

atch

es e

xact

ly w

ith th

e C

AV

V in

the

Vis

aNet

Aut

horiz

atio

n R

eque

st

The

Acq

uire

r may

pro

cess

a R

epre

sent

men

t with

doc

umen

tatio

n th

at in

clud

es a

cop

y of

the

Ver

ified

by

Vis

a tra

nsac

tion

reco

rd

show

ing

the

CA

VV

Fie

ld a

nd a

cop

y of

the

Aut

horiz

atio

n R

eque

st

show

ing

the

sam

e co

nten

ts o

f the

CA

VV

Fie

ld.

Tran

sact

ions

with

EC

I 6 a

re b

lock

ed fo

r Cha

rgeb

acks

whe

n th

e Is

suer

doe

s no

t pro

vide

sup

port

for a

ttem

pted

aut

hent

icat

ions

. Tr

ansa

ctio

ns w

ith a

n E

CI 6

may

be

char

ged

back

if th

e Is

suer

do

es o

ffer s

uppo

rt fo

r atte

mpt

ed a

uthe

ntic

atio

ns.

If an

EC

I 6 tr

ansa

ctio

n is

cha

rged

bac

k, th

e Is

suer

is re

quire

d to

us

e on

e of

the

follo

win

g M

embe

r Mes

sage

Tex

ts:

“CA

VV

M

ISS

ING

IN A

UTH

,” “U

NA

BLE

TO

AU

THE

NTI

CAT

E

RE

SP

ON

SE

,” or

“AU

THE

NTI

CA

TIO

N D

EN

IAL.

” Th

e A

cqui

rer

shou

ld re

sear

ch th

e m

erch

ant’s

Ver

ified

by

Vis

a tra

nsac

tion

reco

rds.

If

the

Acq

uire

r’s re

sear

ch c

onfir

ms

the

EC

I 6 a

nd th

e C

AV

V

Res

ults

Cod

e is

Bla

nk*,

the

trans

actio

n ca

nnot

be

repr

esen

ted.

If

the

Acq

uire

r’s re

sear

ch c

onfir

ms

the

EC

I 6 a

nd th

e C

AV

V

Res

ults

Cod

e is

0*,

the

trans

actio

n ca

nnot

be

repr

esen

ted.

If

the

Acq

uire

r’s re

sear

ch c

onfir

ms

the

EC

I 6 a

nd th

e C

AV

V

Res

ults

Cod

e is

B, t

he tr

ansa

ctio

n ca

nnot

be

repr

esen

ted.

* Th

e A

cqui

rer s

houl

d re

sear

ch th

e 3-

D S

ecur

e A

uthe

ntic

atio

n R

espo

nse

to d

eter

min

e if

the

CA

VV

Fie

ld w

as p

rovi

ded

by th

e Is

suer

was

eith

er m

issi

ng o

r the

sam

e as

that

sub

mitt

ed in

the

Aut

horiz

atio

n. I

f so,

the

Acq

uire

r may

repr

esen

t with

a c

opy

of

the

Aut

hent

icat

ion

Res

pons

e sh

owin

g th

at th

e C

AV

V F

ield

was

su

bmitt

ed in

the

Aut

horiz

atio

n ex

actly

as

retu

rned

by

the

Issu

er.

April

200

4 Vi

sa *C

onfid

entia

l* 80

N

otic

e: T

his

docu

men

t con

tain

s Vi

sa’s

pro

prie

tary

info

rmat

ion

for u

se b

y Vi

sa M

embe

rs’ V

isa

card

pro

gram

s. D

iscl

osur

e to

third

par

ties

or a

ny o

ther

use

is p

rohi

bite

d w

ithou

t the

prio

r w

ritte

n pe

rmis

sion

of V

isa

U.S

.A. I

nc.

Verif

ied

by V

isa

3-D

Sec

ure

Acqu

irer a

nd M

erch

ant I

mpl

emen

tatio

n G

uide

E

CI 6

(Con

tinue

d)

If

For

U.S

. Tra

nsac

tion

s F

or I

nter

nati

onal

Tra

nsac

tion

s

If th

e C

AV

V R

esul

ts

Cod

e sh

ows

“faile

d ve

rific

atio

n” b

ut th

e au

thor

izat

ion

was

ap

prov

ed

CA

VV

Res

ult C

ode:

4,

7, o

r 9.

The

CA

VV

Res

ults

Cod

e in

dica

tes

that

the

Issu

er a

ccep

ted

the

risk

of a

uthe

ntic

atio

n da

ta th

at c

ould

not

be

verif

ied.

The

Acq

uire

r m

ay s

ubm

it a

Rep

rese

ntm

ent w

ith d

ocum

enta

tion

of A

utho

rizat

ion

Req

uest

sho

win

g th

e C

AV

V R

esul

ts C

ode

faile

d ve

rific

atio

n va

lue.

Tran

sact

ions

with

EC

I 6 a

re b

lock

ed fo

r Cha

rgeb

acks

whe

n th

e Is

suer

doe

s no

t pro

vide

sup

port

for a

ttem

pted

aut

hent

icat

ions

. Tr

ansa

ctio

ns w

ith a

n E

CI 6

may

be

char

ged

back

if th

e Is

suer

do

es o

ffer s

uppo

rt fo

r atte

mpt

ed a

uthe

ntic

atio

ns.

If th

e A

cqui

rer’s

rese

arch

con

firm

s th

e fa

iled

CA

VV

Res

ults

Cod

e,

this

tran

sact

ion

is e

ligib

le fo

r Rep

rese

ntm

ent.

The

Acq

uire

r sho

uld

prov

ide

the

Issu

er w

ith d

ocum

enta

tion

of th

e Au

thor

izat

ion

Res

pons

e sh

owin

g th

e EC

I, Ap

prov

ed R

espo

nse

and

faile

d C

AVV

Res

ult C

ode.

April

200

4 Vi

sa *C

onfid

entia

l* 81

N

otic

e: T

his

docu

men

t con

tain

s Vi

sa’s

pro

prie

tary

info

rmat

ion

for u

se b

y Vi

sa M

embe

rs’ V

isa

card

pro

gram

s. D

iscl

osur

e to

third

par

ties

or a

ny o

ther

use

is p

rohi

bite

d w

ithou

t the

prio

r w

ritte

n pe

rmis

sion

of V

isa

U.S

.A. I

nc.

Verif

ied

by V

isa

3-D

Sec

ure

Acqu

irer a

nd M

erch

ant I

mpl

emen

tatio

n G

uide

Sugg

este

d P

roce

dure

s fo

r D

ispu

te R

esol

utio

n (c

ont.)

E

CI

7: C

ardh

olde

r’s

paym

ent c

ard

data

was

pro

tect

ed v

ia a

sec

urit

y m

etho

d, s

uch

as S

ecur

e So

cket

Lay

er (S

SL),

but

auth

enti

cati

on w

as n

ot p

erfo

rmed

.

EC

I 8:

A n

on-s

ecur

e tr

ansa

ctio

n in

whi

ch th

e ca

rdho

lder

’s p

aym

ent c

ard

data

was

tran

smit

ted

in th

e cl

ear

wit

h no

sec

urit

y m

etho

d.

EC

I 9:

A S

ecur

ed E

lect

roni

c T

rans

acti

on (S

ET

) tra

nsac

tion

s (t

his

valu

e sh

ould

not

be

used

by

U.S

. mer

chan

ts).

Act

ion

Step

s : T

hese

are

tran

sact

ions

not

pro

cess

ed b

y A

cqui

rer/

mer

chan

t as

an a

uthe

ntic

atio

n or

att

empt

ed a

uthe

ntic

atio

n. F

ollo

w

stan

dard

dis

pute

reso

lutio

n pr

oced

ures

for

both

U.S

. and

Inte

rnat

iona

l tra

nsac

tions

.

April

200

4 Vi

sa *C

onfid

entia

l* 82

N

otic

e: T

his

docu

men

t con

tain

s Vi

sa’s

pro

prie

tary

info

rmat

ion

for u

se b

y Vi

sa M

embe

rs’ V

isa

card

pro

gram

s. D

iscl

osur

e to

third

par

ties

or a

ny o

ther

use

is p

rohi

bite

d w

ithou

t the

prio

r w

ritte

n pe

rmis

sion

of V

isa

U.S

.A. I

nc.


CAVV Result Code Values (BASE I/SMS Field 44.13)

The chart that follows provides a summary for Acquirer use in determining the validity of CAVV Results Code. Additionally, the full list of CAVV Result Code values are summarized in the table below.

Authentication Attemped Authentication No Liability Shift

Good Result Failed Result 2 1* D

Good Result Failed Result 3 4* 6 7* 8 9* A C

No CAVV or Invalid Result Blank

0 No Liability Shift Result

B

* If an Issuer approves an Authorization Request with a failed verification result code, it cannot be charged back later based on the failed result value.

Value Authentication

or Attempt What the Code Means

Blank Not Applicable Standard e-Commerce or non e-Commerce transactions, not an authentication or attempted authentication.

0 Not Applicable CAVV data field not properly formatted; verification cannot be performed.

1 Authentication CAVV failed verification.

2 Authentication CAVV passed verification.

3 Attempt-Issuer Key CAVV passed verification.

4 Attempt-Issuer Key CAVV failed verification.

5 Reserved For future use; value not currently used.

6 Not Applicable CAVV not verified because Issuer has requested no verification. VisaNet processes as if CAVV is valid.

7 Attempt – Visa Key CAVV failed verification.

8 Attempt – Visa Key CAVV passed verification.

9 Attempt – Visa Key (ACS Unavailable)

CAVV failed verification; Visa generated CAVV because Issuer ACS was not available.

A Attempt – Visa Key (ACS Unavailable)

CAVV passed verification; Visa generated CAVV because Issuer ACS was not available.

B Attempt-Issuer Key Info. Only

CAVV passed verification but no liability shift because a) ECI was not 5 or 6 or b) the card type is an excluded (e.g., Commercial Card).

C Attempt Issuer elected to return CAVV verification results and Field 44.13 blank. Value is set by VisaNet; means CAVV Results are valid.

D Authentication Issuer elected to return CAVV verification results and Field 44.13 blank. Value is set by VisaNet; means CAVV Results are valid.


3-d secure acquirer and merchant implementation guide

Education