Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

3-D Secure Acquirer and Merchant Implementation Guide

Company names mentioned herein are the property of, and may be trademarks of, their respective owners and are for educational purposes only.

  • Als Erste(r) kommentieren

3-D Secure Acquirer and Merchant Implementation Guide

  1. 1. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide April 2004 Visa U.S.A
  2. 2. The enclosed documentation and described technology has been developed and is owned by Visa. These materials have been distributed and provided to Visa Members for their internal use. The information in this document applies to business in the United States only. Any use of disclosure of these materials to third party vendors or any other entity outside of the Visa membership association requires that such third party or entity first obtain a license from Visa. The Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide License Agreement, which governs such third party, use is available through the Verified by Visa Overview on the Merchants page (http://usa.visa.com/business/merchants/verified_index.html). Disclaimer: This document is intended as an informational tool and should not be relied upon for marketing, technology, financial or other advice. The information presented is not intended to advise you of strategies applicable to your specific situation, but rather to highlight issues for your consideration. Therefore, you should consult your own advisors. This document contains dated information and may be superseded by subsequent versions at any time. Visa is not responsible for your use of the document and the information contained herein, including errors of any kind, or any assumptions or conclusions that you might draw from its use. April 2004 Visa *Confidential* Notice: This document contains Visa’s proprietary information for use by Visa Members’ Visa card programs. Disclosure to third parties or any other use is prohibited without the prior written permission of Visa U.S.A. Inc.
  3. 3. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide Table of Contents 1 Document Overview................................................................................................................ 1 1.1 1.2 Document Change Control.......................................................................................................................2 1.3 2 Introduction..............................................................................................................................................1 Resources and Tools ................................................................................................................................3 Verified by Visa Service Description..................................................................................... 6 2.1 2.2 Verified by Visa Service Features............................................................................................................9 2.3 Cardholder Activation and Authentication.............................................................................................10 2.4 Attempted Authentications.....................................................................................................................12 2.5 3 Consumer Market Dynamics....................................................................................................................7 Merchant Benefits ..................................................................................................................................13 3-D Secure – Global Payment Authentication.................................................................... 16 3.1 3.2 3-D Secure Service Participants .............................................................................................................17 3.3 4 3-D Secure Three-Domain Model..........................................................................................................16 Transaction Flow....................................................................................................................................19 Transaction Processing – Authentications and Payment Transactions........................... 22 4.1 4.2 Authentication Transaction Processing ..................................................................................................23 4.3 Attempted Authentication Processing ....................................................................................................24 4.4 Electronic Commerce Indicators ............................................................................................................25 4.5 Authorization Processing .......................................................................................................................26 4.6 5 Verify Enrollment Transaction Processing ............................................................................................22 Support for Dispute Resolution Processes .............................................................................................29 Merchant Server Plug-in Functionality .............................................................................. 30 5.1 April 2004 3-D Secure MPI Messages .....................................................................................................................30 Visa *Confidential* i 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.
  4. 4. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide 5.2 6 Additional MPI Functional Requirements .............................................................................................32 Merchant Product Rules and Best Practices ...................................................................... 34 6.1 Acquirer Responsibility for Merchant Participation ..............................................................................34 6.2 Merchant Authentication to Access Visa Directory Server....................................................................34 6.3 Use of Inline Page instead of Pop-Up ....................................................................................................35 6.4 Pre-Authentication Messaging ...............................................................................................................35 6.5 Use of Inline Page ..................................................................................................................................37 6.6 Use of Inline Page with a Framed Window............................................................................................38 6.7 Text for Inline Page with a Framed Window .........................................................................................39 6.9 Activation Anytime................................................................................................................................43 6.10 Failed Authentication Processing...........................................................................................................44 6.11 Merchant Performance Standards ..........................................................................................................45 6.12 Timing between VERes and PAReq ......................................................................................................46 6.13 Expiration/No Re-Use of Authentication Data.......................................................................................46 6.14 Recurring Payments ...............................................................................................................................47 6.15 Online Auctions .....................................................................................................................................47 6.16 Merchant Customer Support ..................................................................................................................47 6.17 Risk Identification Service for e-Commerce..........................................................................................48 6.18 Data Quality in VEReq and PAReq Messages.......................................................................................49 6.19 Pre-Production Implementation Checklist .............................................................................................50 7 MPI Implementation Alternatives....................................................................................... 51 7.1 7.2 8 “Buy or Build” MPI Software Options ..................................................................................................51 Hosted MPI Options...............................................................................................................................53 Merchant Authentication and Transport Security............................................................ 54 8.1 Merchant Authentication........................................................................................................................54 8.2 Transport Security..................................................................................................................................55 April 2004 Visa *Confidential* ii 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. 5. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide 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.
  6. 6. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide 1 Document Overview 1.1 Introduction Overview Verified by Visa is an online service designed to make Internet transactions safer by authenticating a cardholder’s identity at the time of purchase. Verified by Visa software installed at the Merchant's site activates the cardholder interface for the authentication process. Verified by Visa is built upon the technology platform called Three-Domain (3-D) Secure. The 3-D Secure technical specifications and protocol uses SSL encryption that is currently supported by the majority of online Merchants. The 3-D Secure framework divides the authentication process according to the participants involved: • Issuer Domain: Issuer and cardholder • Acquirer Domain: Acquirer and Merchant • Interoperability Domain: Visa-operated systems that connect the Issuer and Acquirer Domains Verified by Visa is the brand name used to communicate the online authentication service to consumers. As noted above, 3-D Secure is the technology platform for Verified by Visa. The terms Verified by Visa and 3-D Secure may be used interchangeably throughout this document – referring to the Issuer authentication of cardholders during online purchases for transactions originated by participating Merchants. Verified by Visa is a global service and is being implemented worldwide by Visa Members and Merchants. Protocol Version This document has been updated for 3-D Secure protocol version 1.0.2. The protocol version 0.7 is no longer supported; all participating merchants must support version 1.0.2. Audience The 3-D Secure Acquirer and Merchant Implementation Guide is intended for Acquirers and Merchants that are evaluating or have decided to implement support for Verified by Visa. This Guide explains the Verified by Visa program, transaction flows, integration of authentication with payment transaction flows, and the steps required for participating Merchants. Specifically, this Guide can assist Acquirers and Merchants in understanding: • • April 2004 The functionality, uses, and benefits of Verified by Visa. The development, testing and production set up of Verified by Visa. Visa *Confidential* 1 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.
  7. 7. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide 1.2 Document Change Control Product Rule Changes This version of the 3-D Secure Acquirer and Merchant Implementation Guide reflects changes and additions to Visa U.S.A.’s Verified by Visa Product Rules. Except as otherwise noted, the changes defined below become effective April 15, 2004. Merchants that either had entered production or had began work on their Verified by Visa implementation prior to April 15, 2004, must comply with the new and revised Product Rules by June 30, 2004. Changes to the Product Rules are provided in the table below, and changes to the Product Rules and Best Practices are highlighted throughout the document in underlined red text. Product Rule Section Reference “Pop-up” presentations of Verified by Visa are prohibited. Merchants must immediately ensure both the GP2 and eCommerce Visa Root Certificates are installed. Merchants must configure the MPI with both a primary and secondary URL for the production Visa Directory Server by October 1, 2004. Sections 6.3, 6.5, 6.6, and 6.7 Section 9.7 Sections 5.2 and 9.7 Verified by Visa Merchant Symbol is required on check out page. “Pre-Authentication” message is required. Section 6.4 Inline “framed” implementations must provide a brief communication to cardholders outside of the frame for the Verified by Visa Authentication Page. Section 6.7 Merchants must train customer support staff on Verified by Visa. Section 6.16 System monitoring is required. Section 5.2 Authentication data is considered valid for 90 days after the date of the Payer Authentication response returned to the Merchant. Best Practices Changes Section 6.8 Section 6.13 In addition to Product Rule changes, this version of the 3-D Secure Acquirer and Merchant Implementation Guide also contains new “Best Practices”, many of which are drawn from recent Visa usability research with cardholders. While Merchants are not required to follow these Best Practices, Visa strongly recommends that Merchants follow these recommendations to ensure the success of their implementation and the best possible cardholder experience. New Best Practices are provided below: April 2004 Visa *Confidential* 2 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.
  8. 8. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide Best Practice Section Reference Cardholder is provided a smooth method for reinitiating the purchase in the event a Verified by Visa “Failed Authentication” response is received. Verified by Visa “learn more” Merchant Symbol is provided on the “Failed Authentication” page. Section 6.10 “Activate Now” logo is placed on Merchant’s home page or other cardholder-accessible location. Section 6.9 For “framed” implementations, navigational links, text, and icons are kept to a minimum. Section 6.7 For framed” implementations, a simple status indicator is provided. 1.3 Section 6.10 Section 6.7 Resources and Tools 3-D Secure and Verified by Visa Documents Documentation has been developed for Acquirers and Merchants to assist in understanding the 3-D Secure technology platform as well as Verified by Visa program information. These support materials are described below. Verified by Visa Materials The following are available to Visa Acquirers and Merchants to assist in Verified by Visa program development. These materials are available at Visa Online (www.us.visaonline.com). Verified by Visa, 3-D Secure Operations Guide for Issuers, Acquirers and Merchants, Version 1.2, April 2003. Merchant Materials: • • Verified by Visa Merchant Tool Kit provides the Verified by Visa Merchant Symbol graphic and usage standards. Merchants can obtain the Tool Kit at www.visa.com/verifiedmerchants. • April 2004 Visa Website (www.visa.com/verifiedmerchants) -- Acquirers and Merchants can obtain information about Verified by Visa and technology providers who can provide software that supports Verified by Visa functionality. The 3-D Secure Technology Provider list is available electronically at www.visa.com/verifiedvendors. Visa *Confidential* 3 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. 9. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide Merchant Risk Management Information The following are available electronically to Visa Acquirers and Merchants to provide guidance in assuring that risk management requirements are met: Cardholder Information Security Program, version 5.5, contains requirements for Merchants to protect cardholder and transaction information. Information is available at www.visa.com/cisp. Click on “Select Merchants” or “Merchants.” (See also Production Certificate Request Documents below.) • 3-D Secure Specifications and Technical Requirements • Electronic Commerce Risk Management Merchant Best Practices defines business risks and proposed solutions for Merchants conducting secure commerce. This document is available at: http://usa.visa.com/business/Merchants/online_risk_management.html. Copies of these documents are available at: http://international.visa.com/fb/paytech/secure/main.jsp. • 3-D Secure Introduction, Version 1.0.2, Visa Publication 70001-01, dated September 26, 2002 • 3-D Secure System Overview, Version 1.0.2, Visa Publication 70015-01, dated September 26, 2002 • 3-D Secure Protocol Specification – Core Functions, Version 1.0.2, Visa Publication 70000-01, revision dated July 16, 2002 with Errata as of January 16, 2003 • 3-D Secure Functional Requirements – Merchant Server Plug-in, Version 1.0.2, Visa Publication 70003-01, revision dated July 16, 2002 with Errata as of January 16, 2003 Some 3-D Secure documents are available only to parties that have executed a 3-D Secure Publication Suite Master License Agreement. A click-through Master License Agreement and licensed documents are available at the Visa International link above. The above publications and materials are designed to assist Acquirers and Merchants in the development and support of 3-D Secure capabilities. 3-D Secure Compliance Testing Documents Acquirers or Merchants that build or buy 3-D Secure Merchant Server Plug-in software will need to review the following documents: • 3-D Secure Compliance Testing Facility – Policies and Procedures, Visa Publication 70017-01 • 3-D Secure System and Compliance Testing Facility – User Guide, Visa Publication 70018-01 • 3-D Secure System Test Facility – Policies and Procedures, Visa Publication 70021-01 These documents are also available at: http://international.visa.com/fb/paytech/secure/main.jsp. April 2004 Visa *Confidential* 4 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.
  10. 10. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide Product Integration Test (PIT) Facility Documents Each Acquirer, Merchant, or designated processing agent (e.g., hosting provider), operating a Merchant Server Plug-in (MPI), must successfully complete production readiness testing in Visa’s Product Integration Testing (PIT) facility prior to moving a new MPI implementation into the production 3-D Secure environment. Requirements for PIT testing are documented in Visa U.S.A. Requirements for Pre-Production Readiness via the PIT, available to Acquirers on Visa Online or by sending a request to VbVMerchants@Visa.com. The following documentation describing the PIT can be accessed at the PIT Web site at URL: https://dropit.3dsecure.net/PIT: • • PIT Test Cases • Production Certificate Request Documents PIT User’s Guide PIT Terms of Service Each Acquirer, Merchant, or designated processing agent (e.g., hosting provider), operating a Merchant Server Plug-in (MPI), must obtain and install Verified by Visa production certificates to be able to connect to the service and successfully process transactions. The following document, available at Visa Online (www.us.visaonline.com) or by sending an email to VbVMerchants@visa.com requesting the document, contains instructions and procedures for obtaining production digital certificates. The document also provides Product Rules for CISP Compliance and digital certificate issuance and implementation specific to third party hosting providers and Internet Payment Service Providers (IPSPs). An Acquirer who has contracted with a third-party service provider, or uses an Internet Payment Services Provider (IPSP), to provide Verified by Visa services to its Merchants must file an Exhibit VV with Visa for the third-party service provider or IPSP. Verified by Visa, 3-D Secure Merchant Client Authentication Certificate Requests: Rules, Instructions, and Forms, July 2003 April 2004 Visa *Confidential* 5 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.
  11. 11. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide 2 Verified by Visa Service Description Introduction Over the past five years, the Internet has presented new commerce opportunities to Visa Members and Merchants. Each year, the number of consumers and businesses that use the Internet for information, browsing, and purchasing has increased. It is now estimated that over 100 million households have Internet access. The U.S. represents, by far, the largest population of Internet users in the world. The Internet has and will continue to represent a phenomenal environment for information, communications and commerce. And as consumers become more acclimated to online shopping, the potential for online Merchants is significant. Currently, cardholders enjoy the ease and convenience of shopping at Internet Merchants; however, there is no way for the Merchant to know that a valid cardholder has made the purchase. As a result, Merchants incur losses due to fraud. To address this issue, Visa has developed the Verified by Visa service that enables an Issuer to verify a cardholder’s account ownership during an online purchase. Once activated, cardholders can shop at any participating online Merchant using that card and password. Each time they shop online at a participating Merchant, cardholders will see a Verified by Visa window, where they authenticate themselves to their Issuer. After verifying the cardholder’s identity, the Issuer creates and sends an Authentication Response message to the Merchant, providing the authentication result during the checkout process. A change to the Visa International and Visa U.S.A. operating regulations, effective April 5, 2003, shifted chargeback liability for fraudulent transactions from the Acquirer and Merchant to the Issuer when a Merchant submits proof that it was authenticated – or attempted to authenticate – the cardholder in a Verified by Visa transaction. Upon receiving the Issuer’s Authentication Response, Merchants follow their usual commerce procedures. After the Merchant determines the status of the order fulfillment, a Visa Authorization Request, including the authentication data required for Verified by Visa transactions, is forwarded to its Acquirer. The transaction completes via traditional payment processing through VisaNet with authorization, clearing and settlement. With Verified by Visa, cardholders have more confidence buying over the Internet. Issuers, Acquirers, and Merchants are expected to enjoy increased online transaction volumes and reduced exposure to fraud. April 2004 Visa *Confidential* 6 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.
  12. 12. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide 2.1 Consumer Market Dynamics Introduction Even with the strong growth trends over the past several years, there remain many Internet users that have not yet tried online shopping. As consumers gain confidence with the Internet, there are significant additional sales to be generated. Internet Accessed by High Percentage of Consumers The Internet continues to grow in importance – it is now widely accessed by U.S. consumers for information and commerce. The UCLA Center for Communication Policy has conducted a multi-year study of Internet usage in the United States, called The UCLA Internet Report – Surveying the Digital Future, Year Three. The results for 2002, the third year of the report, were released January 31, 2003. Key findings included: • More than 70 percent of Americans in 2002 went online, up from 67 percent in 2000, the first year of the UCLA Internet Project. • The number of hours online continued to increase – rising to an average of 11.1 hours per week in 2002, up from 9.8 hours in 2001 and 9.4 hours in 2000. • Almost 60 percent of users have Internet access at home, a substantial increase in only two years from the 47 percent of users who reported home Internet access in 2000. In addition to online access, shopping represents a key activity for Internet users. As shown in the chart below, approximately 40 percent of Internet users made a purchase online in 2002. 70% 60% 50% 40% 30% 70% 60% % of U.S. Pop. Online 20% 10% % with Internet Access at Home 40% % of Internet Users Shopped 0% Source: The UCLA Internet Report – Surveying the Digital Future, Year Three. Copies of this and prior year reports are available for download at no charge at: www.ccp.ucla.edu. Figure 1. Internet Access and Usage Profile in 2002 – U.S. Households April 2004 Visa *Confidential* 7 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.
  13. 13. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide Security of Payment Card Information Is Key Concern While the Internet has grown as a key channel for communication and shopping, consumer security concerns regarding the use of payment cards for purchases have shown little change over the past several years. The UCLA Internet Report – Surveying the Digital Future reported on consumer concerns relative to payment card security on the Internet. Over the past three years of the study, a very high percentage of consumers reported being “Extremely Concerned” or “Very Concerned” regarding card security when buying online. From 2000, 2001 and 2002, these concerns were reported by 91%, 92% and 94% of survey respondents, respectively. These results are shown in the graph on the left below. Both new and experienced Internet users expressed security concerns making purchases online. In 2002, 79 percent of new Internet users and 48 percent of experienced Internet users indicated that they were Extremely or Very Concerned about the security of their payment card information when buying online. These results are shown in the graph below on the right. Security Concerns of New and Experienced Internet Users – Year 2002 Level of Concern regarding Online Card Security over Past Three Years 100% 100% 80% 61.7% 71.3% 59.5% 63.3% 60% 60% 23.0% 40% 40% 20% 25.2% 80% 19.1% 29.5% 23.1% 8.8% 2000 29.1% 7.6% 5.5% 0% 20% 2001 42.6% 16.6% 0% 2002 New Users (<1 Year) Extremely or Very Concerned Somewhat Concerned Not At All Concerned Extremely Concerned Very Concerned Experienced Users (6 or More Years) Somewhat Concerned Not At All Concerned Source: The UCLA Internet Report – Surveying the Digital Future, Year Three. Figure 2. Consumer Concerns for Online Card Security – UCLA Internet Report, 2002 April 2004 Visa *Confidential* 8 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.
  14. 14. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide Recap – Consumer Market Potential Even with the dramatic growth in Internet commerce, there are underlying security concerns that have limited consumers’ willingness to make purchases online. Numerous research studies have noted that security concerns are predominant – one of the top issues cited when consumers are asked to name barriers to making more online purchases. Of course, payment security is not the only concern or issue cited by consumers as a barrier to making more purchases online. It is clear, however, that a better process is needed to protect consumers so that unauthorized usage cannot take place as well as to protect Merchants from fraudulent purchases. The Verified by Visa service has been developed to meet this market need. By participating in Verified by Visa, Merchants can leverage the consumer desire for more security for when shopping online. By displaying the Verified by Visa logo on their commerce site, Merchants can proactively reinforce the added security available to consumers by shopping at their online store. The next sections provide a description of the Verified by Visa service, including the 3-D Secure model, service features and how transactions flow. 2.2 Verified by Visa Service Features Support for All Visa Card Types Verified by Visa is designed to support the broad base of Visa cards currently offered by Visa card Issuers. These include: • Magnetic Stripe Visa Cards. Verified by Visa supports standard, magnetic stripe Visa cards. It’s easy for cardholders to participate – all they need is access to a PC with one of several widely used Internet browsers. • Smart Visa Cards. Issuers are able to support cardholders that have a chip card, a smart Visa card, by offering cardholders an enhanced level of security for Internet shopping. They provide cardholders with a smart card reader and PC software that operates the reader. Smart cards allow Issuers to authenticate both the cardholder (by validating the password or other code) and the card (by communicating with the card and validating the smart Visa card cryptogram). There are no additional requirements for Merchants when a cardholder uses a smart Visa card. The Issuer server returns an Authentication Response message the same as if the cardholder was not using a smart card. April 2004 Visa *Confidential* 9 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.
  15. 15. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide 2.3 Cardholder Activation and Authentication Overview Verified by Visa enables real-time cardholder authentication by participating Issuers. With authentication, an Issuer ensures that the presenter of the card is authorized and entitled to use the card. Online purchases are authenticated when the cardholder correctly enters the information requested by the Issuer and the Issuer ACS returns an Authentication Response to the Merchant. Cardholders may activate their Visa cards in a number of ways. They can visit the Verified by Visa site at Visa.com and be directed to their Issuer’s web site for enrollment. They can enroll using Activation Anytime, a service that is designed to enable Issuers to activate cardholders at various Internet sites, including participating Merchants, using Verified by Visa banners or buttons. The Issuer may also pre-enroll their cardholders to enable authentication and activation during a transaction. Market research has shown the importance of the Verified by Visa and Issuer’s brand identities in creating cardholder confidence to proceed with the authentication while shopping online. Shown below in Figure 3 are sample user interface pages that cardholders may see from their Issuers. All Issuers and their ACS Processors are required to adhere to the standards and requirements. After the cardholder selects the “buy” button at the Merchant’s checkout page, the cardholder is presented with a Verified by Visa page from the Issuer’s ACS. On the left below, the cardholder is authenticated by entering their personal password. On the right, the cardholder is authenticated by entering identity data and is activated in Verified by Visa. Cardholder Enters Personal Password Cardholder Enters Authentication Data Figure 3. Sample User Interface for Cardholder Activation In both cases above, the Issuer ACS returns an Authentication Response to the Merchant. If the cardholder clicks “Do Not Activate Now”, the ACS returns an Attempts Response to the Merchant. This response message includes the April 2004 Visa *Confidential* 10 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.
  16. 16. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide authentication data (Electronic Commerce Indicator, ECI, and Cardholder Authentication Verification Value, CAVV) for submission with the Authorization Request. Issuer Activation Site An individual cardholder may also be activated in response to Issuer communications or advertising by visiting the Issuer’s website. The cardholder is asked for personal information that allows the Issuer to complete cardholder authentication, such as, name, address, and other identity information. For example, a cardholder may visit one of following: • www.visa.com/verified, where the cardholder is directed to the Issuer’s online website for information and activation. • The Issuer website, where the cardholder provides all required authentication information, and then selects a password and personal message. • The Issuer’s online banking website, where the cardholder may opt to participate in Verified by Visa, agrees to use the existing online banking password, and selects a personal message. At the Issuer’s option, the cardholder may be asked to provide a password hint or user ID, in addition to a password and personal message. Figure 4. Issuer Activation Website When the cardholder initiates activation: Step 1. Step 2. The Issuer Server sends the cardholder information to the Issuer for comparison with Issuer records. Step 3. April 2004 The cardholder visits the Issuer’s Activation Website and enters the requested authentication information. The Issuer confirms the cardholder’s identity and forwards an activation record to the ACS for authentication during online purchases. Visa *Confidential* 11 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.
  17. 17. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide 2.4 Attempted Authentications Overview Some Issuers may elect not to participate or some cardholders may not participate in Verified by Visa. To ensure that participating Merchants are provided with the required proof of an attempted authentication, either the Issuer ACS or Visa (for non-participating Issuers and for stand-in processing if an ACS is not operational) will return an Attempt Response. These transactions provide the participating Merchant with chargeback protection when the subsequent Authorization Request includes the required data. The customer experience for cardholders is shown in Figure 5 below. Figure 5. Attempted Authentication Processing Page The processing for attempted authentications has no cardholder interaction. A “Processing” window (shown above) is briefly displayed while the Attempt Response is processed by the ACS and returned to the Merchant. When the Verified by Visa Merchant receives the Attempt Response, the message will have ECI and CAVV values for inclusion in the Authorization Request. As noted earlier, these data elements must be included in the Authorization Request for the Merchant to qualify for chargeback protection. April 2004 Visa *Confidential* 12 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.
  18. 18. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide 2.5 Merchant Benefits Overview In an e-commerce environment, as with mail and telephone orders, the purchase is a card-not-present transaction. Accepting payment cards for online payment presents a variety of challenges for Merchants that include the following: • Cardholder reluctance to purchase goods and services via the Internet because of the perception that online purchasing is not secure. • Chargebacks of purchase transactions to online Merchants and increased exception item processing that impacts profitability. • Fraud by unauthenticated cardholders that affect Merchants. Verified by Visa addresses these issues and may provide benefits for Acquirers and/or Merchants as highlighted in the following sections. Increased Security and Revenue Growth Consumer research suggests that payment card security concerns present significant barriers to online purchasing and that improved security will be a key motivator for increasing online purchasing. By improving online security, cardholders who currently browse the Internet will become more confident purchasers, thus, possibly increasing sales volume for participating Merchants. Verified by Visa can assist revenue generation in the following ways: • Cardholders may see the names of participating Merchants at Visa.com as well as see the Verified by Visa symbol at Merchant sites. This will encourage cardholders to bookmark these sites for future purchases. • Visa and Issuers have undertaken consumer education to reinforce the message that participating Merchants offer a more secure purchasing environment for consumers. In the third quarter of 2002, Visa conducted a market research tracking study. Consumers that own and use payment cards were asked about Verified by Visa. Respondents indicated that they would feel more comfortable with online shopping, more likely to shop at Merchants that offer Verified by Visa and more likely to spend more online. The survey are shown below: Consumers Prefer Payment Card with Verified by Visa Consumer Respondents Say Verified by Visa Would Make Them: % of Respondents More comfortable with online shopping 77% More likely to shop at sites that offer Verified by Visa 71% Likely to spend more online with Verified by Visa 37% * % of respondents indicating they “Strongly Agree” or “Agree”; 3Q 2002 Visa Tracking Study. April 2004 Visa *Confidential* 13 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.
  19. 19. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide Fraud Reduction When a purchase transaction fails the authentication process, the Merchant is alerted to the possibility of a potential fraud situation. The Merchant must not submit the purchase for authorization if the authentication fails and instead ask the cardholder to use another form of payment. Verified by Visa helps reduce the fraudulent use of Visa cards at participating Merchants. Chargeback Protection Participating in Verified by Visa provides protection for both authenticated and attempted authentication transactions, as described below: • Authenticated Transactions. Since Issuers authenticate cardholders’ identities during Verified by Visa transactions, the following chargeback reason codes do not apply to successfully authenticated transactions: 23 – T&E Invalid Transaction 61 – Fraudulent Mail/Phone/e-Commerce Transaction 75 – Cardholder Does Not Recognize Transaction 83 – International Cardholder – Fraudulent Purchases • Interchange Benefit April 2004 Attempted Authentication Transactions. If a participating Merchant attempts to authenticate a cardholder, and either the Issuer or cardholder is not participating in Verified by Visa, the Merchant is provided with protection from chargebacks for the same reason codes as shown above for authenticated transactions. Merchants must properly process the 3-D Secure Authentication Request and Visa Authorization Request to qualify for chargeback protection. These requirements are described more fully in the 3D Secure Operations Guide for Issuers, Acquirers and Merchants. Transactions that qualify for Custom Payment Service (CPS)/e-Commerce Preferred Retail Credit, and effective January 31, 2004, CPS/e-Commerce Preferred Retail Debit, will be processed with an interchange rate that is five basis points less than CPS/e-Commerce Basic. CPS-e-Commerce Preferred includes authenticated and attempted authenticated transactions while CPS/eCommerce Basic includes standard electronic commerce transactions. Only Merchants that support Verified by Visa are eligible to qualify transactions for CPS/e-Commerce Preferred. Merchants should check with their Acquirer for additional information. Visa *Confidential* 14 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.
  20. 20. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide Reduced Operational Expense Losses from fraud, customer service costs, and back office costs associated with dispute/chargeback processing can be significant expenses Acquirers and Merchants. Even when chargebacks are successfully represented, exception item and dispute processing are costly. The reduction in fraud and operating expenses associated with these chargebacks is expected to improve the bottom line for Acquirers and Merchants. When Acquirers forward a valid Cardholder Authentication Verification Value (CAVV) and Electronic Commerce Indicator (ECI) in a properly formatted Visa Authorization Requests for authentications and attempted authentications, the transactions may qualify for automated blocks on U.S. Chargeback Reason Codes 23, 61 and 75, eliminating the operational expense of those disputes. Verified by Visa addresses the majority of disputes that apply to electronic commerce purchases. An analysis of all chargeback reason codes for U.S. Acquirers and Merchants shows that 66% were for the U.S. and international reason codes impacted by Verified by Visa (23, 61, 75 and 83) where the cardholder disputes having the purchase – these are the “fraud-type” disputes. If a transaction is a properly processed authentication or attempted authentication, the Issuer may not submit the chargeback. Non-US Cardholder Disputes Making Purchase 16% U.S. Cardholder (Reason Disputes Code 83) Making Purchase 50% (Reason Codes All Other 23, 61 and 75) Disputes 34% Total Chargebacks Reason Codes: 23 61 75 83 All Other Total 1% 42% 7% 16% 34% 100% Source: VisaNet System Chargebacks, U.S. Acquirers, June 2003 Figure 6. e-Commerce Chargeback Dollars by Reason Code Data Quality April 2004 Based on data required for authenticated purchase transactions, the integrity of the authorization transaction and the related authentication can be validated. Merchants forward designated authenticated data elements that provide proof that the Issuer authenticated the cardholder or that the Merchant attempted to authenticate the cardholder. Through validation of the CAVV value, Issuers and Acquirers/Merchants have the assurance that the results of the authentication process have not been altered, providing a link between authentication, authorization and clearing and settlement. Acquirers/Merchants receive the CAVV validation results in the Visa Authorization Response so this information is available for dispute resolution. Visa *Confidential* 15 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.
  21. 21. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide 3 3-D Secure – Global Payment Authentication Introduction 3.1 This chapter provides an overview of the Verified by Visa service and a high level review of the 3-D Secure technology components. 3-D Secure Three-Domain Model Overview of 3-D Secure Visa has developed the Three Domain Model of payment systems as the basis of new payment solutions. The model divides payment systems as follows: • Issuer Domain. Systems and functions of the Issuer and its customers (cardholders). • Acquirer Domain. Systems and functions of the Acquirer and its customers (Merchants). • Interoperability Domain. Systems, functions, and messages that allow Issuer Domain systems and Acquirer Domain systems to interoperate worldwide. Figure 7 provides a simple illustration of the participants in their associated domains. Issuer Domain Interoperability Domain CA RDHOLDER Acquirer Domain MERCHA NT ISSUER A CQUIRER Figure 7: Three-Domain Model April 2004 Visa *Confidential* 16 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.
  22. 22. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide 3.2 3-D Secure Service Participants Overview This section describes entities that participate in the 3-D Secure service, by domain. Issuer Domain Cardholder The cardholder shops online, providing shipping and payment card information, then indicates readiness to finalize the transaction. In response to the Purchase Authentication Page, the cardholder provides information needed for authentication, such as a password or identity information. Cardholder browser The cardholder browser acts as a conduit to transport messages between the Merchant Server Plug-in (in the Acquirer Domain) and the Access Control Server (in the Issuer Domain). Issuer A Visa Member financial institution that: • • Determines the cardholder’s eligibility to participate in the 3-D Secure service. • Defines card number ranges eligible to participate in the 3-D Secure service and specifies those card number ranges to the Visa Directory Server. • Access Control Server Enters into contractual relationships with cardholders for issuance of one or more Visa cards. Performs activation of cardholders for Verified by Visa. The Access Control Server (ACS) has several functions: To verify whether 3-D Secure authentication (or proof of attempted authentication) is available for a particular card number • To respond to Verify Enrollment and Payer Authentication messages originated by participating Merchants. • April 2004 • To forward copies of Authentication Responses to the Visa Authentication History Server. Visa *Confidential* 17 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.
  23. 23. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide Merchant Existing Merchant software handles the shopping experience, obtains the card number, and then invokes the Merchant Plug-in to conduct payment authentication. After payment authentication, the Merchant software may submit a Visa Authorization Request to the Acquirer, if appropriate, or forward authorization data to the Acquirer. Merchant Server Plug-in The Merchant Plug-in (MPI) creates and processes payment authentication messages, then returns control to the Merchant software. As part of processing the Authentication Response message from the Issuer, the MPI validates the digital signature in the Authentication Response message. Acquirer Acquirer Domain A Visa Member financial institution that: • Enters into a contractual relationship with a Merchant for purposes of accepting Visa cards. • Determines the Merchant’s eligibility to participate in the 3-D Secure service. • Requests Merchant Certificate for Merchant’s commerce server, if applicable. Following payment authentication, the Acquirer performs its traditional role: • • Visa Directory Server Provides Authorization Responses to the Merchant. • Interoperability Domain Receives Visa Authorization Requests from the Merchant and forwards to VisaNet Submits the completed transaction to the VisaNet settlement system. The Visa Directory Server, operated by Visa: Directs the request for cardholder authentication to the appropriate ACS. • April 2004 Receives messages from Merchants for a specific card and determines whether the card number participates. • Commercial Certificate Authority • Receives the response from the ACS and forwards the response to the Merchant. Generates SSL/TLS encryption certificates used to secure communications between the Merchant and cardholder’s browser. These are the standard SSL/TLS certificates used for secure connectivity with browsers. Visa *Confidential* 18 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.
  24. 24. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide Interoperability Domain Visa Brand Certificate Authority Generates selected certificates for the use of 3-D Secure entities, including: • SSL server certificate that Merchants must use to contact the Visa Directory Server; this certificate is signed by the Visa Root Certificate. • Visa Root Certificate – Merchant software must support a copy of this certificate for purposes of validating the Issuer signature returned in authentication response messages. (continued) Authentication History Server The Authentication History Server (AHS), operated by Visa: • Receives a message from the ACS for each attempted payment authentication • Stores the records received A copy of the data stored by the AHS is available to Acquirers and Issuers in case of disputes. VisaNet Following payment authentication, VisaNet performs its traditional role: • Receives Authorization Requests from Acquirers. • Performs CAVV validation, if applicable. • Forwards Authorization Requests to the Issuer. • Provides Authorization Responses to Acquirers. • Provides clearing and settlement services to the Acquirer and Issuer. Through the interaction of the Acquirer and Issuer Domains, as facilitated by the Interoperability Domain, cardholder purchases are authenticated by Issuers, providing enhanced security for Internet payments to Merchants and cardholders alike. 3.3 Transaction Flow Overview April 2004 Once activated, the cardholder is authenticated during each online purchase at a participating Merchant. The cardholder visits a participating Internet Merchant site, selects goods or services, and proceeds to the checkout page. The cardholder may complete the checkout information in one of a variety of ways – for example, self-entered, electronic wallet, or Merchant one-click. The cardholder initiates a purchase transaction, as described below and illustrated in Figure 8. Visa *Confidential* 19 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.
  25. 25. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide Transaction Steps Step 1. The cardholder completes the purchase by pressing the Buy or Submit button. This activates the Merchant Plug-In (MPI) and initiates a Verified by Visa transaction. Interoperability Domain Issuer Domain CARDHOLDER MERCHANT 1 6 Plug-in 10 11 9 7 Acquirer Domain 2 8 5 Access Control 4 9 12 Visa Directory 3 Authentication History Issuer Acquirer VisaNet Figure 8. 3-D Secure Transaction Flow Step 2. The MPI identifies the card number and sends it to the Visa Directory Server to determine whether the card is in a participating card range. Step 3. If the Issuer is participating for the card range, the Visa Directory sends a Verify Enrollment Request message to the Issuer ACS to determine whether authentication is available for the account number. Continued on next page April 2004 Visa *Confidential* 20 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.
  26. 26. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide Transaction Steps (continued) Step 4. The ACS returns a Verify Enrollment Response to the Visa Directory • If authentication is available for this card number, the response provides the URL of the ACS where the cardholder can be authenticated. • If authentication is not available, the Merchant server receives a Cardholder Not Enrolled or Authentication Not Available message and returns the transaction to the Merchant’s commerce server to proceed with a standard transaction processing. Step 5. The Visa Directory forwards the ACS response to the MPI. Step 6. The MPI sends an Authentication Request message to the cardholder’s browser for routing to the ACS. Step 7. The cardholder’s browser passes the Authentication Request to the ACS. Step 8. The ACS authenticates the cardholder, as described in the Cardholder Activation section. Step 9. The ACS creates, digitally signs, and sends an Authentication Response to the Merchant via the cardholder’s browser. The ACS also sends transaction record to the Authentication History Server for storage. Step 10. The browser routes the Authentication Response back to the MPI. Step 11. The MPI validates the digital signature in the response, verifying that it is from a valid participating Issuer. Step 12. The Merchant formats and sends to its Acquirer a Visa Authorization Request message, which includes information from the Issuer’s Authentication Response—including the CAVV and the ECI. The Acquirer passes the Authorization Request to VisaNet and the transaction completes through standard VisaNet processing. April 2004 Visa *Confidential* 21 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.
  27. 27. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide 4 Transaction Processing – Authentications and Payment Transactions Introduction This chapter describes how Verified by Visa authentication data is incorporated in payment processing that Acquirers and Merchants support for authorization and settlement of Visa transactions. Note: Processing and contractual arrangements pertaining to authorization and settlement can vary across several parties. This chapter generally describes the activities and requirements that Acquirers and Merchants and payment gateways, and/or commerce server providers are responsible for support of Verified by Visa. 4.1 Verify Enrollment Transaction Processing Verify Enrollment Response by ACS The MPI forwards a Verify Enrollment Request to the Visa Directory Server to determine if the account is eligible for authentication processing. When the Issuer ACS receives a Verify Enrollment Request, the ACS responses are shown below. When a Y response is received in the VERes, the Merchant forwards a Payer Authentication Request to the ACS URL included in the response. N = Card eligible for attempts liability, but attempts proof is not be available from the Issuer Merchant proceeds with the purchase as an attempted authentication, submits an ECI of 6 in the Visa Authorization and leaves the CAVV blank. The Issuer may not submit a chargeback if the cardholder later disputes the purchase. U = Unable to process or card not eligible for attempts (e.g., Commercial Cards) April 2004 Y = Card eligible for authentication processing Merchant proceeds with purchase as non-authenticated and submits authorization with ECI 7. The Acquirer/Merchant retains liability if the cardholder later disputes making the purchase. Visa *Confidential* 22 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.
  28. 28. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide 4.2 Authentication Transaction Processing Payer Authentication Response Processing Upon receiving a VERes of Y, the Merchant forwards a Payer Authentication Request to the Issuer ACS. The ACS interfaces with the cardholder and determines the action to communicate to the Merchant. The response codes are inserted in the “Transaction Status” field of the PARes message. The ACS responses are shown below: Y = Authentication approved The Issuer has authenticated the cardholder by verifying the identity information or password. The ACS returns a CAVV and an ECI of 5 in the Authentication Response. A = Authentication attempted Cardholder is not enrolled and has Merchant attempted authentication. The ACS returns a CAVV and an ECI of 6 in the Authentication Response. U = Unable to authenticate The Issuer ACS is not able to complete the authentication request – possible reasons include: • Authentication request mis-routed to the wrong ACS. • ACS is not able to establish an SSL session with cardholder browser. • System failure that prevents proper processing of the authentication request. • Card type is excluded from attempts (Commercial Card). Merchants may proceed with the above purchases as nonauthenticated, using an ECI of 7 in the authorization message, and retain liability if the cardholder later disputes making the purchase. These are standard e-commerce transactions. The ACS does not return a CAVV. • N = Authentication failed When the PARes has a U and an Invalid Request Code of 55, this indicates that the Account Identifier in the PAReq did not match the value returned by the ACS in the VERes. Merchants should view this as an invalid transaction. The Issuer is not able to authenticate the cardholder. The following are reasons to fail an authentication: • Cardholder fails to correctly enter the authentication information within the Issuer-defined number of entries (possible indication of fraudulent user). • Cardholder “cancels” authentication page (possible indication of a fraudulent user). Merchants are not permitted to submit these transactions for authorization processing. The ACS does not return CAVV or ECI values in the Failed Authentication April 2004 Visa *Confidential* 23 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.
  29. 29. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide 4.3 Attempted Authentication Processing VERes Processing for Attempted Authentication Transactions For U.S. Transactions, Visa provides authentication responses when a participating Verified by Visa Merchant attempts to authenticate a cardholder, if either the cardholder or the Issuer does not yet participate in Verified by Visa. The Directory Server forwards the transaction to the Visa Attempts Server, which will return a Y in the VERes message. For International Transactions, non-U.S. Issuers may optionally support responses to attempted authentications as described above, returning a Y in the VERes message. Other non-U.S. Issuers, especially those not yet participating in Verified by Visa, will not have the capability to support attempts responses. In these transactions, participating Merchants will receive a VERes response of N for non-enrolled cardholder or non-participating Issuer. For these transactions, the Visa Authorization Request is submitted with an ECI of 6, leaving CAVV blank. VisaNet recognizes the Issuer as non-U.S. and permits these transactions to qualify for CPS/e-Commerce Preferred even though there is no CAVV included in the authorization. PARes Processing for Attempted Authentication Transactions For attempted authentications, the ACS will return an A in the PARes response. The PARes includes a CAVV value and ECI of 6. Both of these authentication data elements are submitted in the Visa Authorization Request; enabling the transaction to qualify for CPS/e-Commerce Preferred, providing the Merchant with protection from fraud-type chargebacks. Exclusions from Attempts Processing The Visa Operating Regulations provide several types of transactions that are excluded from requirements for attempted authentications: • Excluded Card Types – Two card types, Commercial Cards and anonymous Prepaid Cards, are excluded from requirements for attempted authentications on non-enrolled cardholders. The Visa Attempts Server will verify that the BIN is in the Directory Server Excluded File and return U in the Verify Enrollment Response to the Merchant to communicate that attempted authentications do not apply. • New Channel Devices – Transactions originated with designated new channel devices types, such as mobile or wireless devices. • Merchants in Global Merchant Chargeback Monitoring Program are not permitted to process attempted authentication transactions. The VERes response for these transactions will be a U to indicate that the transaction is not eligible for attempts processing. These transactions are standard electronic commerce and are submitted in the Visa Authorization Request with an ECI of 7 as CPS/e-Commerce Basic. April 2004 Visa *Confidential* 24 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.
  30. 30. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide 4.4 Electronic Commerce Indicators ECI Values and Authorization Processing The Electronic Commerce Indicator (ECI) must be set to a value corresponding to the level of security and type of authentication for a transaction. The merchant transmits data for the Visa Authorization Request message, including the ECI, to the Acquirer or its processor. Possible ECI data values are: • • ECI 6 = Authentication attempted by Merchant. The value should be returned by the ACS in the in the PARes message for an Attempt Response. Additionally, merchants may use an ECI 6 in the Authorization Request when a VERes of N is received from the Visa Directory Server for Issuer or cardholder not participating. • ECI 7 = Merchant used SSL for obtaining cardholder payment information, but payment authentication was not performed. An ECI 7 applies when the VEReq or PAReq of U for Unable to Authenticate. • Determining ECI Values ECI 5 = Cardholder authenticated by the Issuer. This value should be returned by the ACS in the PARes message. ECI 8 = A non-secure channel was used by the Merchant when obtaining cardholder payment information. Table 1 summarizes the various VERes and PARes transactions and the related ECI values for inclusion in Visa Authorization Request. Response Code ECI Meaning Verify Enrollment Response Codes Y = Card eligible for authentication processing NA – the ECI is determined by the PARes message N = Card eligible for attempts liability, but attempts proof will not be available ECI of 6 April 2004 Merchant forwards PAReq to ACS and receives ECI in the Authentication Response (PARes). Merchant proceeds with purchase as attempted authentication, submits ECI of 6 in Authorization Request and leaves CAVV blank. The Issuer is not permitted to submit a chargeback if the cardholder later disputes having made the purchase. If the Merchant receives a chargeback, they may represent. Visa *Confidential* 25 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.
  31. 31. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide U = Unable to process or card not eligible for attempts processing (e.g., Commercial Card) ECI of 7 Merchant proceeds with purchase as nonauthenticated and submits authorization with ECI of 7. The Acquirer/Merchant retains liability if the cardholder later disputes making the purchase. Authentication Response Codes Y = Authentication approved ECI of 5 in PARes message The Issuer has authenticated the cardholder. A = Authentication attempted ECI of 6 in PARes message The Merchant has attempted to authenticate the cardholder and either the Issuer or cardholder is not enrolled. U = Unable to authenticate ECI of 7 The Issuer ACS is not able to complete the authentication. An ECI is not returned in the authentication response. Merchant proceeds with these purchases as nonauthenticated and retain liability if the cardholder later disputes making the purchase. N = Authentication failed NA The Issuer is not able to authenticate the cardholder. Merchants are not permitted to submit these transactions for authorization. No ECI or CAVV is returned in the response. Table 1. ECI Codes for Visa Authorization Request Messages 4.5 Authorization Processing Required Data in Visa Authorization Requests The Visa Authorization Request for an authenticated or attempted authentication must contain the Electronic Commerce Indicator (ECI) and Cardholder Authentication Verification Value (CAVV), along with other CPS eCommerce Preferred requirements, as proof of the authentication or attempt to qualify for chargeback protection. Mapping PARes Fields to Authorization Messages After each successfully authenticated transaction (as indicated by a Transaction Status of Y in the PARes), or each transaction for which proof of authentication was generated (as indicated by a Transaction Status of A in the PARes), the Merchant is required to pass the fields defined in the table below from the PARes to the Merchant’s commerce server in order to correctly identify the transaction in the authorization process: PARes Field Name Cardholder Authentication Verification Value April 2004 Visa *Confidential* PARes DTD Element TX.cavv 26 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.
  32. 32. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide Electronic Commerce Indicator Transaction Identifier (optional) Decoding CAVV from PARes Message TX.eci Purchase.xid The CAVV value that the ACS returns to the MPI is Base 64-encoded, resulting in a 28-byte value. The Merchant receives the PARes as a Base 64-encoded message. The CAVV field is further Base 64-encoded within the PARes message that results in a length of 28 bytes. The CAVV field has also been separately Base 64-encoded. The Merchant, or Merchant processor, must therefore perform the following in sequence: • Base 64 decode the PARes message • Base 64 decode the CAVV field to get it back to a 20 byte binary value • If necessary, convert the data field to gateway processor’s traditionally required data format (EBCDIC, etc.) • Submit data field to gateway processor • Construct the BASE I authorization message to ensure that the CAVV is entered in BASE I as a binary value in Field 126.9 To adhere to the VisaNet requirements for Field 126.9, which is 20 bytes long, the CAVV must be decoded into a 20-byte binary value prior to submitting it to VisaNet or their payment processor. Because the arrangements between Merchants and payment processors can vary, Merchants will need to confirm whether they or their payment processor will convert the CAVV data into binary. Transmit CAVV The Cardholder Authentication Verification Value is a cryptographic value derived by the Issuer during payment authentication that provides evidence of the results of payment authentication during an online purchase. Issuers must include this value in each Payer Authentication Response message sent to the MPI in which the Transaction Status value is either Y or A. When a Merchant receives a CAVV value in a PARes message from the Issuer, the CAVV and ECI must be included in the Visa Authorization Request for the Merchant to qualify transactions for chargeback protection. Parties that transmit Authorization Requests directly to Visa must support and certify for the following V.I.P. fields: Sent in Visa Authorization Requests: • Field 126.9— CAVV field • Field 60.8—Additional POS Information, positions 9–10, that carries the MOTO/ECI for BASE I. • Field 126.8— XID, optional Returned in Visa Authorization Responses: • April 2004 Field 44.13—CAVV Results Code that carries the results of validating the CAVV. Visa *Confidential* 27 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.
  33. 33. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide Transaction Identifier (XID) This is a unique tracking number set by the Merchant and sent to the ACS in the PAReq message. It is optional for the XID to be included in Visa Authorization Requests. Matching ACI and ECI for Clearing and Settlement The Authorization Characteristic Indicator (ACI) must be consistent with the ECI in the clearing and settlement messages. This means that the Merchant or gateway processor must ensure that the ECI submitted for clearing and settlement matches the ACI received in the Authorization Response. The ACI indicates the CPS category for which the transaction qualifies, as shown below: ACI Value in Authorization Response What the Value Means ECI Value for Settlement U Transaction qualified as CPS/e-Commerce Preferred as an authenticated purchase. 5 S Transaction qualified as CPS/e-Commerce Preferred as an attempted authentication. 6 Transaction qualified as CPS/e-Commerce Basic as a standard electronic commerce transaction. 7 W or P e-Commerce Custom Payment Service Custom Payment Services (CPS) establish a framework for processing transactions across different acceptance environments. There are requirements for defined data fields, processing rules, interchange rates and chargeback provisions. The CPS/e-Commerce categories are: • CPS/e-Commerce Basic • CPS/e-Commerce Preferred Retail • CPS/e-Commerce Preferred Passenger Transport • CPS/e-Commerce Preferred Hotel and Car Rental CPS/e-Commerce Basic is a standard, non-authenticated electronic commerce transaction that requires the appropriate ECI and an Address Verification Service (AVS) inquiry. Qualification for CPS/e-Commerce Preferred also requires a successfully authenticated or attempted authenticated transaction in which a valid CAVV is included in the Visa Authorization Request. More information about these programs and the respective transaction characteristics are highlighted in Appendix D. April 2004 Visa *Confidential* 28 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.
  34. 34. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide 4.6 Support for Dispute Resolution Processes Chargeback Protection for Authenticated and Attempted Authenticated Transactions If the Issuer provides a positive authentication response or an attempt response, the transaction may not be charged back to the Merchant if the cardholder later disputes the transaction as an unauthorized purchase. A full description of dispute processing can be found in the 3-D Secure Operations Guide for Issuers, Acquirers and Merchants. A summary of the dispute resolution process for Acquirers can be found in Appendix F, Suggested Dispute Resolution Procedures. As noted in Chapter 2, the chargeback protection affects the following “fraudtype” disputes in which cardholders allege they did not make the purchase: U.S. Chargebacks: Reason Code 23 – T&E Invalid Transaction Reason Code 61 – Fraudulent Mail/Phone Order Transaction Reason Code 75 – Cardholder Does Not Recognize Transaction International Chargebacks: Reason Code 23 – T&E Invalid Transaction Reason Code 83 – Fraud, Non-Possession of Card All other chargeback rights continue to apply to e-commerce transactions. Using ACI Value for Dispute Research Acquirers and Merchants may also find the Authorization Characteristic Indicator (ACI) assigned by VisaNet in the Authorization Response helpful in dispute research. This value indicates whether the transaction qualified for chargeback blocking, as follows: • • ACI of W (standard e-commerce) or P (standard T&E e-commerce). • Using CAVV Results Field for Dispute Research ACI of U (authentication transaction) or S (attempted authentication). Other ACI Values (transactions have not qualified as electronic commerce). The CAVV Results field is returned in Authorization Responses (BASE I Field 44.13). This value may be helpful in determining if a transaction qualifies for chargeback protection. Authentication Good Result Result 2 D Attempted Authentication Failed 1 Good Result Result 3 6 8 A C Failed 4 7 9 No Liability Shift No CAVV or Invalid Result Blank 0 No Liability Shift Result B Information about CAVV Results values can be found in Appendix F, Suggested Dispute Resolution Procedures. April 2004 Visa *Confidential* 29 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.
  35. 35. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide 5 Merchant Server Plug-in Functionality Organization This chapter describes: • • 3-D Secure messages involving MPI processing. • Overview of MPI functions The key role of the Merchant Server Plug-in (MPI) in 3-D Secure Processing. Additional functional requirements of the MPI. The Merchant Server Plug-in is software that can be integrated with a Merchant’s Web storefront software or may be supplied as a service by an Acquirer, payment service provider, payment gateway provider, or Internet Service Provider (ISP). The MPI performs a number of essential functions in 3-D Secure processing including: • Transmitting Verify Enrollment Request (VEReq) messages to the Visa Directory Server and receiving Verify Enrollment Response (VEReq) messages from the Visa Directory Server. • Transmitting Payer Authentication Requests (PAReq) to, and receiving Payer Authentication Responses (PARes) from, the ACS via the cardholder’s device. • Optionally, transmitting Card Range Request (CRReq) messages to the Visa Directory Server and receiving Card Range Response (CRRes) messages from the Visa Directory Server. • Validating the cryptographic signature in the PAReq message from the ACS to ensure its authenticity and integrity using the Visa Root Certificate. • Providing authentication results data to the Merchant’s authorization processing function. The functional requirements of the Merchant Plug-in were developed in the context of common operating system, Web server, and storefront development environments, to enable development of software that is widely compatible with products being used by most Merchant sites. 5.1 3-D Secure MPI Messages The following short descriptions of each message that affects the MPI are provided for reference only. Please refer to the 3-D Secure Protocol Specification, Core Functions for exact formats, element definitions, and DTDs. April 2004 Visa *Confidential* 30 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.
  36. 36. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide CRReq and CRRes Card Range Request (CRReq) and Response (CRRes) are optional messages that enable the MPI to request the full set of participating card ranges in the Visa Directory Server. The Merchant Server Plug-in formats a CRReq message and sends it to the Visa Directory Server to request updated card range data. The Visa Directory Server formats a CRRes message containing the participating card ranges and sends it to the MPI so the MPI can update its card range cache information. If the MPI supports a card range cache, a CRReq message must be forwarded at least once every 24 hours. Note: The majority of Visa card ranges are loaded in the Directory Server, so Visa recommends that MPIs forward all Verify Enrollment Request messages to the Directory Server and avoid support for the cache of card ranges. VEReq and VERes Verify Enrollment Request (VEReq) and Verify Enrollment Response (VEReq) After the cardholder completes the Merchant’s checkout process, the MPI formats a VEReq message and sends it to the Visa Directory Server to determine whether authentication is available for a specific card number. The Visa Directory Server searches for a card range that includes the cardholder PAN received in the VEReq message. If the PAN is identified in a participating card range, the Visa Directory Server forwards the VEReq message to the URL of the ACS associated with that card range. The ACS receives the VEReq message and checks the participation of the card number and returns a VEReq message that contains the URL of the ACS for either authentication processing – either an authentication or attempted authentication. The Directory Server forwards the VEReq message to the MPI. If the Visa Directory Server cannot identify a card range that includes the PAN received in the VEReq message, the Visa Directory Server returns a VEReq message to the MPI with an N for Not Enrolled response. PAReq and PARes Payer Authentication Request (PAReq) and Payer Authentication Response (PARes) Messages The MPI sends a PAReq message to the ACS URL that was received in the corresponding VEReq. The PAReq contains information regarding the purchase transaction. The ACS responds with a PARes, a message containing transaction details and signed by the ACS, providing the Issuer’s authentication results for the cardholder’s purchase. The MPI validates the signature on the PARes message in order to complete the 3-D Secure authentication process. April 2004 Visa *Confidential* 31 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.
  37. 37. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide Error Message Error All 3-D Secure components must be able to create and process an Error message. This message is reserved for instances of protocol and system-level errors. 5.2 Additional MPI Functional Requirements Digital Certificates The Merchant server certificate signed by the Visa Root Certificate must be encrypted and securely stored in the MPI. The MPI must be able to import and securely store the Visa Root Certificate for use in validating the Issuer’s signature retuned in PARes messages. Recordkeeping The MPI must log all 3-D Secure related functions as part of normal processes. Reporting It is highly desirable that merchants modify current transaction reporting to include Verified by Visa specific fields. This following data will be beneficial in disputes resolution: The MPI must be able to maintain and store PARes records for dispute resolution purposes. • • Electronic Commerce Indicator (ECI) • Monitoring Transaction Status (results of authentication – Y, A, U, or N) CAVV Field (includes the Authentication Tracking Number or ATN to assist research with CAVV Field in Visa Authorization Request message. Merchant (or the hosting entity) must integrate monitoring of the MPI server and application into its systems monitoring processes so that the Merchant can quickly identify and correct problems with its implementation of 3-D Secure. Quick identification and repair will enable the Merchant to minimize any potential loss of the program benefits on its Visa transactions, and participating cardholders will be more likely to have the Verified by Visa experience they have grown to expect at a Verified by Visa Merchant. The systems monitoring requirements stated above become effective on April 15, 2004. Merchants that either had entered production or had begun technical implementation prior to April 15, 2004, must institute system monitoring by June 30, 2004. However, Merchant (or the hosting entity) must not send test transactions to the Visa Directory Server as part of its monitoring. April 2004 Visa *Confidential* 32 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.
  38. 38. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide Directory Server Fallback Merchant must implement fallback to a secondary Visa Directory Server. Merchants should consult with their MPI software vendor to identify the correct primary and secondary production Visa Directory Server URLs and how to properly configure the MPI to automatically fall back to a secondary Directory Server if the primary Visa Directory Server is temporarily not available. Fallback must be configured so that no human intervention is required. All Merchants must implement fallback to the secondary production Visa Directory Server by October 1, 2004. 3-D Secure Timeout Sequencing Please refer to Appendix C for requirements governing 3-D Secure timeout sequencing. Cardholder Data Security Any payment card data stored by the Merchant Server Plug-in or on servers that are connected to the Internet must be encrypted and securely stored as defined in the Visa Cardholder Information Security Program (CISP). See Chapter 1, Resources and Tools for information to obtain a copy of these requirements. For More Information Additional information regarding mandatory and optional functionality of the Merchant Server Plug-in is contained in 3-D Secure Functional Requirements – Merchant Server Plug-in. See Chapter 1, Resources and Tools for information to obtain a copy of these requirements. April 2004 Visa *Confidential* 33 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.
  39. 39. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide 6 Merchant Product Rules and Best Practices Overview 6.1 This chapter discusses additional Acquirer and Merchant program and transaction requirements, which supplement the Visa U.S.A. Inc. Operating Regulations. Also outlined are some recommendations for best practices to ensure a good authentication experience for customers. Acquirer Responsibility for Merchant Participation General Requirements Participating Acquirers are responsible for ensuring that participating Merchants operate in accordance with these Product Rules and the Visa U.S.A. Inc. Operating Regulations, and that such requirements are included in Merchant Agreements. Acquirers must ensure and/or approve the following: • Merchants Agreements have been modified to reflect a Merchant’s participation in Verified by Visa. • The issuance of a Merchant digital certificate for use in Merchant authentication to the Visa Directory Server. • Merchants and third-party commerce server providers meet the security requirements for 3-D Secure processing, including support for the Cardholder Information Security Program (CISP). For further information on Verified by Visa-specific CISP compliance requirements, see Section 1.3 Resources and Tools, Production Certificate Request Documents. • • 6.2 Contracts with third-party commerce server providers or payment gateways must ensure that each Merchant activated for Verified by Visa is reported to and approved by the Acquirer. An Acquirer who has contracted with a third-party service provider, or uses an Internet Payment Services Provider (IPSP), to provide Verified by Visa services to its Merchants must file an Exhibit VV with Visa for the thirdparty service provider or IPSP. Merchant Authentication to Access Visa Directory Server Requirement April 2004 A Merchant client certificate is required for participating Merchants to connect to the Visa Directory Server. To support this capability, the Common Name in the Merchant certificate must contain a Host Name (also known as a Domain Name). During the connection attempt, the Visa Directory Server will check that the client’s DNS-resolvable Host Name matches the information contained in the Common Name of the Merchant certificate. If the information does not match, the Directory Server will deny the connection. Visa *Confidential* 34 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.
  40. 40. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide 6.3 Use of Inline Page instead of Pop-Up Requirement 6.4 The 3-D Secure Protocol allows for two types of authentication page displays to be presented to cardholders: inline or pop-up pages. The inline page uses the full browser window to display the authentication page. Pop-ups display as a separate smaller window on top of the Merchant checkout page. Pop-up suppression software has gained market adoption through stand-alone applications as well as online service providers that incorporate it as a standard feature of the service. Microsoft has announced the inclusion of pop-up suppression software in the next version of Internet Explorer. Cardholders have also learned to disregard pop-up windows due to the high frequency of pop-up windows being used for unsolicited advertisements. Therefore, U.S. Merchant 3D Secure implementations must not use the pop-up page presentation for Verified by Visa and must instead use an inline page. This change will prevent issues with pop-up suppression software and avoid situations where cardholders inadvertently close the Verified by Visa pop-up. The prohibition of pop-up page implementations becomes effective April 15, 2004. Merchants that either had entered production or had begun technical implementation using a pop-up presentation prior to April 15, 2004, must change to an in-line presentation by June 30, 2004. Pre-Authentication Messaging Requirement April 2004 Merchants must provide a brief message to cardholders on the checkout page after the Merchant knows that the cardholder has selected a Visa card as the payment method. The intention of the messaging is to notify the cardholder that they might next be prompted either to activate their card for Verifed by Visa or, if they already participate in Verified by Visa, to provide their Verified by Visa password. The messaging is also intended to provide a further reminder and reassurance to the cardholder, beyond the presence of the Verified by Visa “Learn More” logo on the Merchant’s site, that the Merchant participates in Verified by Visa and is aware of the possible cardholder experiences associated with the program. However, any such messaging must not state affirmatively that the cardholder will have a Verified by Visa experience, and the Merchant must not indicate that the Merchant requires the cardholder to authenticate himself or herself. Also, Merchants must not insert an interim page, after the cardholder clicks the “buy” button, that requires the cardholder to click a “Continue” button for Verified by Visa, as this may be confusing to cardholders who are processed as an “Attempted Authentication”. The pre-authentication messaging Product Rules stated above become effective on April 15, 2004. Merchants that either had entered production or had begun technical implementation prior to April 15, 2004, must adhere to the Product Rules by June 30, 2004. Visa *Confidential* 35 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.
  41. 41. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide Requirement Pre-authentication messaging should be kept as short and concise as possible. The pre-authentication message should be free from technical jargon (e.g., “You may be taken to your bank’s secure Verified by Visa site…”) as the jargon will tend to confuse users. Visa recommends pre-authentication messaging as follows: The next screen you see may be payment card verification through Verified by Visa. Or, if the Merchant is implementing Verified by Visa in conjunction with other payment card brand’s 3-D Secure-based authentication solutions, and the merchant cannot determine which payment brand’s card is being used for the transaction, Visa recommends the following: The next screen you see may be payment card verification through your card issuer. The pre-authentication message is most effective and most likely to be read by cardholders when placed immediately next to the final order button. Merchants should also consider graphical treatments such as using large text, bolding, and color to help draw attention to the pre-authentication message. A visual grouping such as drawing a box around the pre-authentication message and the final order button can also help draw attention and emphasize that authentication is part of the merchant’s normal checkout process flow. An example is provided below: April 2004 Visa *Confidential* 36 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.
  42. 42. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide 6.5 Use of Inline Page Best Practice Merchants must implement either an inline or a “framed” inline approach. Examples and the benefits of each permitted approach are discussed below. Figure 9 shows a standard inline page and Figure 10 shows a framed inline page. Inline Page This approach provides a clean presentation to the cardholder and has the following additional benefits: Cardholder can verify connectivity with Issuer Access Control Server URL 1. Cardholder can verify the Issuer ACS URL. 2. Cardholder can check the SSL lock to ensure connection with Issuer ACS. Cardholder can verify SSL session with Issuer ACS Both features provide increased cardholder confidence for entering sensitive information, like a password. Figure 9: Standard Inline Page Merchant URL Framed Inline Page This approach allows the Merchant to provide a consistent look and feel across the checkout process. However, there may be cardholder concerns regarding the confidentiality of information entered into the page when the cardholder sees the Merchant URL in the window and Merchant name in the SSL lock. Merchant SSL certificate information Figure 10: Framed Inline Page April 2004 Visa *Confidential* 37 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.
  43. 43. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide 6.6 Use of Inline Page with a Framed Window Requirement If a Merchant uses the framed inline approach, the frame opened for the Issuer ACS to present the Verified by Visa window must be large enough to present the entire 390 pixel width by 400 pixel height authentication page without scrolling. Merchants that elect to implement an inline page with a frame may place a frame at the top of the page (Figure 11) and/or on the side of the page (Figure 12). Framed Inline Page with Top Frame Merchant status indicator (see Section 6.7) Frame must allow at least 390 pixels width by 400 pixels height to display, without requiring the customer to scroll to see the authentication page. Concise merchant message (see Section 6.7) See section 6.7 for requirements related to the use of text communications. Figure 11: Framed Inline with Top Frame Framed Inline Page with Side Frame Merchant status indicator (see Section 6.7) Frame must allow at least 390 pixels width by 400 pixels height to display, without requiring the customer to scroll to see the authentication page. Concise merchant message (see Section 6.7) See Section 6.7 for requirements related to the use of text communications. Figure 12: Framed Inline with Side Frame April 2004 Visa *Confidential* 38 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.
  44. 44. Verified by Visa 3-D Secure Acquirer and Merchant Implementation Guide 6.7 Text for Inline Page with a Framed Window Recommended Text Merchants must provide a brief communication to customers outside of the frame for the authentication page, as shown in Figure 13 below. The text will be seen by Visa cardholders that are both activated for Verified by Visa and non-activated where an attempted authentication response is returned to the Merchant. Recommended text is as follows: Do not click the refresh or back button or your transaction may be interrupted. If the Merchant elects alternate wording from that recommended by Visa above, the customer communication provided by the Merchant should be free of technical jargon. Visa research has shown that most users are confused by terminology that explains the technical side of Verified by Visa. Users do not understand and may misinterpret messages regarding which server they are interacting with, whether they are technically at a different site, etc. Therefore, Merchants should not provide text that explains, for example, “you may be taken to the secure Verified by Visa site for authentication after which you will return to our site.” Merchants should keep the technology as transparent as possible to the user. Any Merchant messaging outside of the frame for the authentication page must avoid explicitly describing the Verified by Visa experience to the user. The Merchant is unable to determine the particular experience that a cardholder may have. For example, some cardholders will be processed as an attempted authentication, and will not be presented with a Verified by Visa password entry screen. Again, Visa market and usability research has clearly shown that a simple statement, such as that shown below, provides the best user experience. Merchant message Figure 13: Inline Framed Merchant Message April 2004 Visa *Confidential* 39 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.

×