Information about this New Manual

Transcription

1 Information about this New Manual New Manual This SecureCode Merchant Implementation Guide, dated September 2005, is an entirely new manual. Contents This manual contains excerpts from the SecureCode Member Enrollment and Implementation Guide, and describes the objectives of the SecureCode Electronic Commerce Program, enablement requirements and options for participating members, roles, responsibilities, and obligations of program participants, and the implementation and testing procedures, with specific focus on the SecureCode issuer platforms based on the SPA algorithm. Please refer to Using this Manual for a complete list of the contents of this manual. Billing MasterCard will bill principal members for this document in printed format. Please refer to the MasterCard Consolidated Billing System Manual for billing-related information. Questions? If you have questions about this manual, please contact the Customer Operations Services team or your regional help desk. Please refer to Using this Manual for more contact information. MasterCard is Listening Please take a moment to provide us with your feedback about the material and usefulness of the SecureCode Merchant Implementation Guide using the following address: publications@mastercard.com We continually strive to improve our publications. Your input will help us accomplish our goal of providing you with the information you need.

2 SecureCode Merchant Implementation Guide September 2005

3 Copyright The information contained in this manual is proprietary and confidential to MasterCard International Incorporated (MasterCard) and its members. This material may not be duplicated, published, or disclosed, in whole or in part, without the prior written permission of MasterCard. Legal Notice This document contains the proprietary and confidential information of MasterCard International Incorporated ( MasterCard ). Such information may not be used for any unauthorized purpose and may not be published or disclosed to third parties, in whole or part, without the express written permission of MasterCard. You acknowledge and agree that between you and MasterCard this document and all portions thereof, including, but not limited to, any copyright, trade secret and other intellectual property rights relating thereto, are and at all times shall remain the sole property of MasterCard and that title and full ownership rights in the information contained herein and all portions thereof are reserved to and at all times shall remain with MasterCard. You agree to safeguard the confidentiality of the information contained herein using the same standard you employ to safeguard your own confidential information of like kind, but in no event less than a commercially reasonable standard of care. If you do not agree with the foregoing conditions, you are required to return this document immediately to MasterCard. Sep 2005 Trademarks Trademark notices and symbols used in this manual reflect the registration status of MasterCard trademarks in the United States. Please consult with the Customer Operations Services team or the MasterCard Law Department for the registration status of particular product, program, or service names outside the United States. All third-party product and service names are trademarks or registered trademarks of their respective owners. Media This document is available: On MasterCard OnLine On the MasterCard Electronic Library (CD-ROM) MasterCard International Incorporated 2200 MasterCard Boulevard O Fallon MO USA SecureCode Merchant Implementation Guide September 2005 Publication Code: SMI

4 Table of Contents Using this Guide Purpose...1 Audience...1 Overview...1 Excerpted Text...3 Language Use...3 Times Expressed...3 Revisions...4 Support...4 Regional Representative...5 Section 1 Overview MasterCard and Electronic Commerce Maestro and Electronic Commerce The Opportunity to Grow Your Online Business with the MasterCard SecureCode Program MasterCard SecureCode Platform Components What is UCAF? What is an AAV? What is a Merchant Plug-In? Section 2 MasterCard SecureCode 3-D Secure Solution Overview Overview Components Issuer Domain Acquirer Domain SecureCode Merchant Implementation Guide September 2005 i

5 Table of Contents Interoperability Domain Messages Card Range Request/Response Verification Request/Response Payer Authentication Request/Response Payer Authentication Transaction Request/Response Cardholder Enrollment Cardholder Enrollment Process Sample Cardholder Enrollment Flow Cardholder Authentication Sample Cardholder Authentication Process Sample Cardholder Authentication Flow Section 3 Merchants Overview Infrastructure Establishment of SecureCode Operating Environment Authorization System Enhancements Maestro Considerations Customization Program Identifier Usage Guidelines Integrated Support for Merchant Plug-In Processing Consumer Message on Payment Page Creation of Cardholder Authentication Window TERMURL field Replay Detection Merchant Server Plug-In Configuration Operational Loading of MasterCard Root Certificates Loading of MasterCard SSL Client Certificate MPI Log Monitoring MPI Authentication Request/Response Archival Accountholder Authentication Value (AAV) Processing ii September 2005 SecureCode Merchant Implementation Guide

6 Table of Contents Identification of SPA AAV format in PARes Validation of Payer Authentication Response (PARes) signature Global Infrastructure Testing Requirements MasterCard SecureCode Participating Merchant Listings Merchant Processing Matrix Appendix A Merchant Customer Service Guide Overview... A-1 Audience... A-1 Purpose... A-1 Frequently Asked Questions... A-2 What is MasterCard SecureCode?... A-2 What is a SecureCode?... A-2 What is the format of a SecureCode?... A-2 Why is our web site supporting SecureCode?... A-2 How does our web site support SecureCode?... A-2 What is a Personal Greeting?... A-3 What is the difference between authentication and authorization?... A-3 How does MasterCard SecureCode work?... A-3 What is the difference between a pop-up and an inline authentication window?... A-4 How does our web site know if a card is protected by MasterCard SecureCode?... A-4 Who knows the consumer s SecureCode?... A-4 What are the consumer s system requirements for MasterCard SecureCode?... A-5 How does a consumer enroll in the SecureCode program?... A-5 What information is contained on the SecureCode authentication window?... A-5 Will the authentication window appear if the consumer never enrolled in the SecureCode program?... A-6 What happens if the consumer does not know his SecureCode?... A-6 What is pop-up killer software and what happens if it is installed on the consumer s PC?... A-7 What happens if authentication fails?... A-8 SecureCode Merchant Implementation Guide September 2005 iii

7 Table of Contents What happens if the consumer does not choose to enroll or does not enter his SecureCode?... A-8 What happens if the consumer clicks the x in the top right corner of the authentication window?... A-9 Cardholder Enrollment... A-10 Traditional Cardholder Enrollment... A-10 Activation During Shopping... A-10 Consumer Buying Scenarios... A-12 Authentication - Successful... A-13 Authentication Forgotten SecureCode... A-14 Authentication Failed... A-16 Authentication Account Locked... A-18 Authentication X ing Out The Window... A-19 Activation During Shopping... A-22 Activation During Shopping Opt Out of Enrollment... A-25 Appendix B MasterCard SecureCode SPA Algorithm Specification Overview... B-1 Accountholder Authentication Value Layout... B-2 Base64 Encoding... B-3 Introduction... B-3 Examples... B-3 Base64 Alphabet... B-6 Appendix C Contact Information Contact Information... C-1 Appendix D MasterCard SecureCode Program Identifier Usage Guidelines General Standards of Use...D-1 Authorized Use...D-1 iv September 2005 SecureCode Merchant Implementation Guide

8 Table of Contents MasterCard SecureCode Word Mark...D-1 MasterCard SecureCode Program Identifier...D-2 Approved Versions...D-2 Placement on a Merchant Website...D-6 Placement within a MasterCard SecureCode Application or a Member Website...D-8 Parity...D-9 Sizes...D-9 Authorized Artwork...D-10 For More Information...D-10 Appendix E Maestro Considerations Account in Good Standing...E-1 SecureCode Merchant Implementation Guide September 2005 v

9 Using this Guide This chapter contains information that helps you understand and use this document. Purpose...1 Audience...1 Overview...1 Excerpted Text...2 Language Use...2 Times Expressed...3 Revisions...3 Support...4 Regional Representative...4 SecureCode Merchant Implementation Guide September 2005 i

10 Using this Guide Purpose Purpose The SecureCode Merchant Implementation Guide describes the following: Objectives of the MasterCard SecureCode Electronic Commerce Program MasterCard and Maestro offering, benefits, and enablement requirements and options for participating members Roles, responsibilities, and obligations of both MasterCard and program participants Implementation and testing procedures, with specific focus on the MasterCard SecureCode issuer platforms based on the SPA algorithm. Audience This manual is intended for use by MasterCard and Maestro members who are considering participating in the MasterCard SecureCode Electronic Commerce Program. Overview The following table provides an overview of this manual: Chapter Table of Contents Using this Guide Description A list of the manual s chapters and subsections. Each entry references a chapter and page number. A description of the manual s purpose and its contents. 1 Overview Provides a general overview of the MasterCard SecureCode Electronic Commerce program. 2 MasterCard SecureCode 3-D Secure Solution Overview Provides a general overview of MasterCard s implementation of 3-D Secure for MasterCard cards and Maestro cards, including cardholder enrollment and payer authentication. 3 Merchants Provides a general overview of the various activities and requirements associated with building and maintaining the merchant components required to support MasterCard SecureCode. A Merchant Customer Service Guide Overview of the MasterCard SecureCode service, along with an understanding of the consumer experience, in order to provide assistance to customers when needed SecureCode Merchant Implementation Guide September

11 Using this Guide Excerpted Text Chapter B MasterCard SecureCode SPA Algorithm Specification Description Layout of the Accountholder Authentication Value (AAV) to be used by issuers participating in MasterCard SecureCode, as well as an overview of Base64 encoding C Contact Information MasterCard contact information D E MasterCard SecureCode Program Identifier Usage Guidelines Maestro Considerations Contains guidelines, which are intended for all use of the MasterCard SecureCode word mark and/or the MasterCard SecureCode program identifier Contains detailed information regarding Maestro specific processing issues associated with MasterCard SecureCode Excerpted Text At times, this document may include text excerpted from another document. A note before the repeated text always identifies the source document. In such cases, we included the repeated text solely for the reader s convenience. The original text in the source document always takes legal precedence. Language Use The spelling of English words in this manual follows the convention used for U.S. English as defined in Merriam-Webster s Collegiate Dictionary. MasterCard is incorporated in the United States and publishes in the United States. Therefore, this publication uses U.S. English spelling and grammar rules. An exception to the above spelling rule concerns the spelling of proper nouns. In this case, we use the local English spelling. 2 September 2005 SecureCode Merchant Implementation Guide

12 Using this Guide Times Expressed Times Expressed MasterCard is a global company with locations in many time zones. The MasterCard operations and business centers are in the United States. The operations center is in St. Louis, Missouri, and the business center is in Purchase, New York. For operational purposes, MasterCard refers to time frames in this manual as either St. Louis time or New York time. Coordinated Universal Time (UTC) is the basis for measuring time throughout the world. You can use the following table to convert any time used in this manual into the correct time in another zone: St. Louis, Missouri USA Central Time Purchase, New York USA Eastern Time UTC Standard time (last Sunday in October to the first Sunday in April a ) Daylight saving time (first Sunday in April to last Sunday in October) 9:00 10:00 15:00 9:00 10:00 14:00 a For Central European Time, last Sunday in October to last Sunday in March. Revisions MasterCard periodically will issue revisions to this document as we implement enhancements and changes, or as corrections are required. With each revision, we include a Summary of Changes describing how the text changed. Revision markers (vertical lines in the right margin) indicate where the text changed. The date of the revision appears in the footer of each page. Occasionally, we may publish revisions or additions to this document in a Global Operations Bulletin or other bulletin. Revisions announced in another publication, such as a bulletin, are effective as of the date indicated in that publication, regardless of when the changes are published in this manual. SecureCode Merchant Implementation Guide September

13 Using this Guide Support Support Please address your questions to the Customer Operations Services team as follows: Phone: or (Spanish Language support) Fax: Canada, Caribbean, and U.S. Asia/Pacific Europe South Asia/Middle East/Africa Latin America (Spanish Language support) Address: MasterCard International Incorporated Customer Operations Services 2200 MasterCard Boulevard O Fallon MO USA Telex: answerback: ITAC UI Regional Representative The regional representatives work out of the regional offices. Their role is to serve as intermediaries between the members and other departments in MasterCard. Members can inquire and receive responses in their own language and during their office s hours of operation. To find out the location of the regional office serving your area, call the Customer Operations Services team at: Phone: or (Spanish Language support) 4 September 2005 SecureCode Merchant Implementation Guide

14 1 Overview This section provides a general overview of the MasterCard SecureCode Electronic Commerce program. MasterCard and Electronic Commerce Maestro and Electronic Commerce The Opportunity to Grow Your Online Business with the MasterCard SecureCode Program MasterCard SecureCode Platform Components What is UCAF? UCAF Structure What is an AAV? What is a Merchant Plug-In? SecureCode Merchant Implementation Guide September i

15 Overview MasterCard and Electronic Commerce MasterCard and Electronic Commerce Electronic commerce transactions account for an increasing share of MasterCard and member gross dollar volume, currently estimated at more than 8%. The number of remote transactions is increasing at a rate of 30% to 35% per year. For this reason, it is important to position electronic commerce and mobile commerce channels to increase gross dollar volume profitability by using security and authentication solutions that authenticate cardholders, thereby reducing chargebacks and expenses associated with disputed transactions. From a risk perspective, the current MasterCard electronic and mobile transaction environment closely resembles traditional mail order/telephone order (MO/TO) transactions. The remote nature of these transactions increases risk, resulting in more cardholder disputes, and associated chargebacks. These factors increase costs to MasterCard members for managing disputes and chargebacks. Approximately 60% of all chargebacks for electronic commerce transactions are associated with reason code 4837 No Cardholder Authorization or reason code 4863 Cardholder Not Recognized, where the consumer denies responsibility for the transaction and the acquirer lacks evidence of the cardholder s authentication or the consumer does not recognize the transaction. Proving that the cardholder conducted and authorized the transaction in a virtual, non-face-to-face environment of electronic and mobile commerce has been extremely difficult. The MasterCard SecureCode program is designed to provide the infrastructure for an issuer security solution that reduces problems associated with disputed charges that impact all parties in a transaction the issuer, the acquirer, the cardholder and the merchant. Sep 2005 Maestro and Electronic Commerce Low credit card penetration in many countries has led to inefficient payment forms like cash on delivery, check, and domestic transfer/ach. MasterCard SecureCode will allow Maestro cards to be used for Internet purchases in a safe and secure environment. Currently there are over 560 million Maestro cards and MasterCard SecureCode will allow Maestro to be the first fully authenticated global online debit brand accepted on the Internet. Unless otherwise stated by domestic country rules, all Maestro Internet transactions will be guaranteed. Sep 2005 SecureCode Merchant Implementation Guide September

16 Overview The Opportunity to Grow Your Online Business with the MasterCard SecureCode Program The Opportunity to Grow Your Online Business with the MasterCard SecureCode Program MasterCard SecureCode offers flexible, robust and easy to implement solutions for cardholder authentication. Recognizing that one size does not fit all, MasterCard places a premium on flexibility, enabling issuers to choose from a broad array of security solutions for authenticating their cardholders including both password and smart card-based approaches. Based on the MasterCard implementation of 3-D Secure, MasterCard and Maestro issuers may use issuer assigned or cardholder selected passwords to authenticate their cardholders. Issuers may also choose to utilize the Chip Authentication Protocol (CAP), which provides for the creation of a one-time use cardholder authentication password, similar to what the cardholder experiences in a face-to-face environment using chip and pin. This program provides a seamless integration of both EMV and 3-D Secure technologies that result in stronger authentication than traditional static password solutions. Sep 2005 MasterCard SecureCode is the MasterCard consumer-and-merchant-facing name for all existing and new MasterCard cardholder authentication solutions. While these solutions may each appear quite different on the surface, these various approaches converge around UCAF and share a number of common features. Hence the common program name MasterCard SecureCode. In every case, for example, two things occur: 1. The MasterCard or Maestro cardholder is authenticated using a secure private code unique to them (MasterCard SecureCode). With both password and Chip Authentication Program implementations of MasterCard SecureCode, an authentication box appears on the order confirmation page and prompts the cardholder for their SecureCode. In a password-based implementation, the cardholder enters the SecureCode previously registered with the issuer. With the Chip Authentication Program, the cardholder inserts her/her smart card into a card reader and enters the challenge and his/her PIN. Then, the chip generates a value that the cardholder places into the issuer authentication window as the SecureCode. 2. The authentication data is transported from party to party via the MasterCard UCAF mechanism. Sep September 2005 SecureCode Merchant Implementation Guide

17 Overview MasterCard SecureCode Platform Components MasterCard SecureCode Platform Components The MasterCard SecureCode Platform is comprised of a number of layered components. Each of the components, as described below, provides for specific authorization and authentication functionality during the processing of a MasterCard SecureCode transaction. When combined, the platform provides a mechanism for online merchants to receive a similar global payment guarantee to one that brick-and-mortar retailers enjoy with physical point-ofsale transactions. What is UCAF? UCAF Structure UCAF (Universal Cardholder Authentication Field) is a standard, globally interoperable method of collecting cardholder authentication data at the point of interaction across all channels, including the Internet and mobile devices. Within the MasterCard authorization networks (for example Banknet, MDS, RSC, EPSnet), UCAF is a universal, multi-purpose data transport infrastructure that is used to communicate authentication information among cardholder, issuer, merchant and acquirer communities. It is a variable length, 32-position field with a flexible data structure that can be tailored to support the needs of a variety of issuer security and authentication approaches. SecureCode Merchant Implementation Guide September

18 Overview MasterCard SecureCode Platform Components The generic structure of UCAF is illustrated below: Control Byte Application-Specific Data 1 Binary Byte Max 23 Binary Bytes Max 32 characters (after Base64 encoding) The control byte contains a value that is specific to each security application. MasterCard is responsible for assigning and managing UCAF control byte values and the structure of UCAF application specific data. Other solutions, which utilize UCAF for authentication collection and transport, will be assigned its own control byte value and the structure of the application-specific data will be tailored to support the specifics of the security protocol. The current SecureCode control byte definitions include: Usage 3-D Secure SPA AAV for first and subsequent transactions Base64 Encoded Value J Hexadecimal Value x 8C 3-D Secure SPA AAV for attempts H x 86 In most UCAF implementations, the application specific data is defined as binary data with a maximum length of 24 binary bytes including the control byte. However, there are some restrictions in the various MasterCard authorization networks regarding the passing of binary data in the authorization messages. As a result, all UCAF data generated by SPA algorithm-based MasterCard SecureCode implementations must be base64 encoded at some point prior to being included in the authorization message. The purpose of this encoding is to produce a character representation of the associated binary data. This results in a character representation that is approximately 33% larger than the binary equivalent. For this reason, the UCAF field is defined with a maximum length of 32 positions. For additional information on base64 encoding, refer to appendix A, MasterCard SecureCode SPA AAV. 1-4 September 2005 SecureCode Merchant Implementation Guide

19 Overview MasterCard SecureCode Platform Components What is an AAV? The Accountholder Authentication Value (AAV) is a MasterCard SecureCode specific token that uses the UCAF field for transport within MasterCard authorization messages. It is generated by the issuer and presented to the merchant for placement in the authorization request upon successful authentication of the cardholder. Sep 2005 In the case of a chargeback or other potential dispute processing, the AAV will be used to identify the processing parameters associated with the transaction. Among other things, the field values will identify: The issuer ACS that created the AAV. The sequence number that can be used to positively identify the transaction within the universe of transactions for that location. The secret key used to create the Message Authentication Code (MAC), which is a cryptographic method that will not only ensure AAV data integrity but also bind the entire AAV structure to a specific PAN. UCAF is the mechanism that is used to transmit the AAV from the merchant to issuer for authentication purposes during the authorization process. What is a Merchant Plug-In? As part of the MasterCard SecureCode infrastructure requirements, all merchant end-points must implement application software capable of processing 3-D Secure messages. An end-point is described as any merchant or merchant processor platform, which directly connects to the MasterCard SecureCode infrastructure. A merchant plug-in is a software application that is developed and tested to be compliant with the 3-D Secure protocol and interoperable with the MasterCard SecureCode infrastructure. The plug-in application is typically provided by a technology vendor and integrated with the merchant s commerce server. It serves as the controlling application for the processing of 3-D Secure messages. SecureCode Merchant Implementation Guide September

20 2 MasterCard SecureCode 3-D Secure Solution Overview This chapter provides a general overview of the MasterCard implementation of 3-D Secure for MasterCard cards and Maestro cards, including cardholder enrollment and payer authentication. Overview Components Issuer Domain Cardholder Browser and Related Cardholder Software Enrollment Server Access Control Server AAV Validation Server/Process Acquirer Domain Merchant Plug-In Signature Validation Server Interoperability Domain Directory Server Certificate Authority Transaction History Server Attempts Server Messages Card Range Request/Response Verification Request/Response Payer Authentication Request/Response Payer Authentication Transaction Request/Response Cardholder Enrollment Cardholder Enrollment Process Sample Cardholder Enrollment Flow Welcome Enter Your Card Number Terms & Conditions and Privacy Policy Validate Your Identity Validate Your Identity Create Your SecureCode SecureCode Merchant Implementation Guide September i

21 MasterCard SecureCode 3-D Secure Solution Overview Congratulations Cardholder Authentication Sample Cardholder Authentication Process Sample Cardholder Authentication Flow Enter Payment Information Confirm and Submit Order Enter Your SecureCode Purchase Completed ii September 2005 SecureCode Merchant Implementation Guide

22 MasterCard SecureCode 3-D Secure Solution Overview Overview Overview Cardholder authentication is the process of verifying cardholder account ownership during a purchase transaction in an online electronic commerce environment. All SPA algorithm-based MasterCard SecureCode solutions, which support MasterCard cards and Maestro cards, define and provide a base level of security around performing this authentication process. For this solution specifically, MasterCard is deploying its own implementation of 3-D Secure under the MasterCard SecureCode program branding for MasterCard and Maestro. This implementation of 3-D Secure includes support for the SPA algorithm and UCAF without any changes to the 3-D Secure specification, messages, or protocol. The components described in this chapter are organized according to requirements that fall within the issuer, acquirer, and interoperability domains associated with the payment process. Issuer Domain Interoperability Domain Acquirer Domain Cardholder Browser Related Cardholder Software Enrollment Server Access Control Server AAV Validation Server/Process Directory Server Certificate Authority Merchant Plug-In Signature Validation Server The Issuer Domain is those systems and functions of the card issuing financial institutions and its customers The Interoperability Domain is those systems, functions, and messages that allow the Issuer Domain and Acquirer Domain to interoperate. These components will be globally operated and managed by MasterCard The Acquirer Domain is those systems and functions of the acquirer and its customers SecureCode Merchant Implementation Guide September

23 MasterCard SecureCode 3-D Secure Solution Overview Components Components Issuer Domain Cardholder Browser and Related Cardholder Software 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). Optional cardholder software to support implementations such as chip cards may also be included. Both the browser and related software are considered to be off-the-shelf components that do not require any specific modification to support 3-D Secure. Enrollment Server The purpose of the enrollment server is to facilitate the process of cardholder enrollment for an issuer s implementation of 3-D Secure under the MasterCard SecureCode program. The server will be used to perform initial cardholder authentication, as well as administrative activities such as SecureCode resets and viewing 3-D Secure payment history. In some cases, the enrollment server and the access control server may be packaged together. Access Control Server The access control server serves two basic, yet vital, functions during the course of a MasterCard SecureCode online purchase. First, it will verify whether a given account number is enrolled in the MasterCard SecureCode program. Secondly, it will facilitate the actual cardholder authentication process. Sep 2005 AAV Validation Server/Process This server or process will be used to perform validation of the cardholder authentication data received by the issuer s authorization system in the authorization messages. 2-2 September 2005 SecureCode Merchant Implementation Guide

24 MasterCard SecureCode 3-D Secure Solution Overview Components Acquirer Domain Merchant Plug-In The merchant server plug-in creates and processes payer authentication messages and then returns control to the merchant software for further authorization processing. The plug-in is invoked after the cardholder finalizes the purchase request, which includes selecting the account number to be used, and submitting the order but prior to obtaining authorization for the purchase. Signature Validation Server The signature validation server is used to validate the digital signature on purchase requests that have been successfully authenticated by the issuer. This server may be integrated with the merchant plug-in or may be a separately installed component. Interoperability Domain Directory Server The MasterCard SecureCode global directory server provides centralized decision-making capabilities to merchants enrolled in the MasterCard SecureCode program. Based on the account number contained in the merchant enrollment verification request message, the directory will first determine whether the account number is part of a participating MasterCard or Maestro issuer s card range. It will then direct eligible requests to the appropriate issuer s access control server for further processing. All implementations of this issuer platform must use the MasterCard SecureCode global directory server for processing MasterCard card and Maestro card transactions. SecureCode Merchant Implementation Guide September

25 MasterCard SecureCode 3-D Secure Solution Overview Components Certificate Authority The MasterCard Certificate Authority is used to generate and distribute all private hierarchy end-entity and subordinate certificates, as required, to the various components and subordinate certificate authorities across all three domains. These certificates include: MasterCard Root certificate (used for both MasterCard and Maestro) SSL Server and Client certificates issued under the MasterCard hierarchy Issuer Digital Signing certificates issued under the MasterCard hierarchy Additionally, SSL certificates based on a public root hierarchy are required. These certificates are not issued by the MasterCard Certificate Authority and must be obtained from another commercially available certificate-issuing provider. Sep 2005 Transaction History Server The MasterCard SecureCode infrastructure does not support this component server. Attempts Server The MasterCard SecureCode infrastructure does not support this component server. 2-4 September 2005 SecureCode Merchant Implementation Guide

26 MasterCard SecureCode 3-D Secure Solution Overview Messages Messages Card Range Request/Response Message Pair: CRReq/CRRes For performance reasons, the Merchant Server Plug-In has the capability to cache the card ranges contained in the Directory, which indicate issuer participation in 3-D Secure. The Card Range Request/Response messages are used by the Merchant Server Plug-In as a way to request updates to the cache from the Directory. Verification Request/Response Message Pair: VEReq/VERes The first step in the payer authentication process is to validate that the cardholder account number is part of an issuer s card range, which is participating in 3-D Secure. The Verification Request/Response messages are sent from the Merchant Server Plug-In to the Directory to check card range eligibility. If the specified account number is contained within a SecureCode eligible card range, this message is then sent from the Directory to the Access Control Server to check if the specific account number is enrolled and active to participate in 3-D Secure. For those merchants that cache the contents of the MasterCard SecureCode directory server, this message is not used if the cache indicates that the issuer is not enrolled in 3-D Secure. If the cache does indicate that the issuer is enrolled, or if no cache is being maintained, this message must be formatted and processed as described. Sep 2005 Payer Authentication Request/Response Message Pair: PAReq/PARes Once it has been determined that a cardholder is enrolled to participate in 3-D Secure, the actual process of payer authentication is performed for each online purchase. The Payer Authentication Request/Response messages are sent from the Merchant Server Plug-In to the Access Control Server to perform the actual authentication. It is at this point in the process where the cardholder will be presented with an authentication window and asked to enter his SecureCode. SecureCode Merchant Implementation Guide September

27 MasterCard SecureCode 3-D Secure Solution Overview Messages The Access Control Server will perform authentication and, if successful, generate an Accountholder Authentication Value (AAV). This information, if received by the merchant, must be sent to the acquirer and forwarded to the issuer as part of the authorization request. Payer Authentication Transaction Request/Response Message Pair: PATransReq/PATransRes Following authentication, it may be desirable to centralize storage of authentication requests for later dispute processing. The Payer Authentication Transaction Request/Response messages provide a record of this authentication activity sent from the ACS to the History Server. The MasterCard SecureCode global infrastructure does not support these messages. 2-6 September 2005 SecureCode Merchant Implementation Guide

28 MasterCard SecureCode 3-D Secure Solution Overview Cardholder Enrollment Cardholder Enrollment Cardholder Enrollment Process Enrollment is the process whereby authorized MasterCard and Maestro branded cardholders will activate their cards for a specific issuer s MasterCard SecureCode program. Part of the planning process for building a 3-D Secure infrastructure will involve determining exactly how this process will work. The major component associated with enrollment is the enrollment server. It is responsible for driving the process under which: The cardholder validates that his account number is designated as eligible to participate in MasterCard SecureCode by the card issuing financial institution. The cardholder is authenticated by the card issuing financial institution through the validation of secret questions, independently determined by each issuer participating in the program. The cardholder sets up and defines his SecureCode The cardholder performs functions such as profile administration (including SecureCode and changes) and review of recent purchases. 1 Internet 2 Enrollment Server 3 4 Acct Holder File Issuer or 3 rd Party Validation In a typical example: 1. The cardholder visits an issuer enrollment site. This may be accessible, for example, from the issuer s web site or home banking system. SecureCode Merchant Implementation Guide September

29 MasterCard SecureCode 3-D Secure Solution Overview Cardholder Enrollment 2. The cardholder is asked to provide issuer identified enrollment data. During this phase of the process, the cardholder will be asked a series of secret questions to prove his identity to the issuer. 3. The enrollment data, or answers to the secret questions, is validated by the issuer. 4. If the appropriate answers are provided, the cardholder is considered to be authenticated and is allowed to establish his SecureCode to be associated with the specified account number. The SecureCode is stored by the issuer for later use during online purchases at participating merchants. Sample Cardholder Enrollment Flow The following sample cardholder enrollment flow is identical for both MasterCard and Maestro cardholders. Contact your Maestro e-commerce representative for Maestro branded screen shots. Welcome The welcome screen will introduce the cardholder to the benefits of MasterCard SecureCode. 2-8 September 2005 SecureCode Merchant Implementation Guide

30 MasterCard SecureCode 3-D Secure Solution Overview Cardholder Enrollment Enter Your Card Number The cardholder will be prompted to enter his card number. This will be used to perform a check to validate that the card number is part of a MasterCard or Maestro issuer card range, which is participating in the MasterCard SecureCode program. Terms and Conditions and Privacy Policy Prior to any cardholder authentication, any issuer specific terms and conditions statement, along with a privacy policy, will be presented to the cardholder for acceptance. Acceptance of this information is a requirement for the process flow to continue. SecureCode Merchant Implementation Guide September

31 MasterCard SecureCode 3-D Secure Solution Overview Cardholder Enrollment Validate Your Identity This is the first of two displays that may be used to collect cardholder authentication data. The Name on Card field allows for MasterCard SecureCode registration of multiple individuals using the same account number (for example husband and wife). Only the name and expiration date fields are required. All additional fields are customizable as determined by the issuer. Validate Your Identity This screen is the second of two, which may be used to collect cardholder authentication data. All questions on this screen are customizable as determined by the issuer September 2005 SecureCode Merchant Implementation Guide

32 MasterCard SecureCode 3-D Secure Solution Overview Cardholder Enrollment Create Your SecureCode Assuming that all cardholder data is successfully validated, the cardholder will now have the opportunity to create: 1. An individual SecureCode to use when paying with the designated MasterCard card or Maestro card at participating merchants. 2. A secret question and corresponding answer that can be used in case of a forgotten SecureCode. Another option, used extensively by many implementations, is to ask cardholders the original authentication questions again. 3. A Personal Greeting. This greeting will be displayed on the authentication window every time a purchase is made. The presence of this field on the authentication window is an assurance to the cardholder that he is communicating with his issuing financial institution Sep 2005 SecureCode Merchant Implementation Guide September

33 MasterCard SecureCode 3-D Secure Solution Overview Cardholder Enrollment Congratulations The cardholder is now ready to start shopping! 2-12 September 2005 SecureCode Merchant Implementation Guide

34 MasterCard SecureCode 3-D Secure Solution Overview Cardholder Authentication Cardholder Authentication Sample Cardholder Authentication Process Cardholder SSL -1 SSL -4 Merchant Plug-In SSL -6 SSL -5 SSL - 2 SSL - 3 MasterCard Directory Issuer ACS The sample flow that follows assumes that the cardholder has already enrolled in his issuer s MasterCard SecureCode program and obtained a MasterCard SecureCode to use while shopping online at participating merchants. For more information on the cardholder enrollment process, refer to Cardholder Enrollment. Sep 2005 Sep 2005 Link SSL-1 SSL-2 SSL-3 SSL-4 Description The cardholder shops at the merchant and, when ready to checkout, enters the appropriate payment information including the account number The Merchant Plug-In queries the Directory to verify the enrollment status for a specific issuer using the verification request messages. It is possible that this step will be performed locally at the merchant via the local MasterCard directory cache if applicable. If the directory indicates that an issuer is participating, then the directory must forward a request to the issuer s Access Control Server to check the enrollment status of a specific cardholder. The configuration information in the Directory will indicate exactly which Access Control Server will perform the check. The resulting response will flow back over the same links to the Merchant Plug-In. If the Access Control Server indicates that a specific cardholder is participating, the Merchant Plug-In creates the Payer Authentication Request message and sends it to the cardholder s browser. SecureCode Merchant Implementation Guide September

35 MasterCard SecureCode 3-D Secure Solution Overview Cardholder Authentication Link SSL-5 SSL-6 Description The cardholder browser redirects the message to the appropriate Access Control Server to perform cardholder authentication. When the Access Control Server receives the Payer Authentication Request message, it causes the user authentication dialog to begin. This in turn causes a separate authentication window to appear to the cardholder that will facilitate the cardholder authentication process. The Access Control Server authenticates the cardholder SecureCode, constructs the SPA AAV for MasterCard s implementation of 3-D Secure, and builds and digitally signs the Payer Authentication Response message. It is returned to the Merchant Plug-In, at which point the cardholder authentication window will disappear. Once cardholder authentication has been completed, the merchant is required to pass the corresponding SPA AAV to the acquirer via the UCAF field within the authorization message. This value is then passed from the acquirer to the issuer as part of the authorization message. Merchant Merchant Plug-In Acquirer Issuer -OR- Ucaf_Authentication_Data Authorization Network (Banknet) (MDS) 0100 [UCAF] (Acquirer Message Format) 0200 [UCAF] (Acquirer Message Format) 0100 [UCAF] (Authorization Network Format) 0200 [UCAF] (Authorization Network Format) When received by the issuer, the AAV can be validated as part of authorization request processing, as well as archived for use in potential cardholder disputes September 2005 SecureCode Merchant Implementation Guide

36 MasterCard SecureCode 3-D Secure Solution Overview Cardholder Authentication Sample Cardholder Authentication Flow The following sample cardholder authentication flow is identical for both MasterCard and Maestro cardholders. Contact your Maestro e-commerce representative for Maestro branded screen shots. Enter Payment Information The cardholder will shop at a merchant location just as they would today. After selecting the items to be placed into the shopping cart, the payment card information to be used for the transaction is entered. Tom Maxwell J November 2004 Confirm and Submit Order Once all of the payment and shipping information has been entered, the cardholder is typically given an opportunity to review the purchase one last time before submitting the order. SecureCode Merchant Implementation Guide September

37 MasterCard SecureCode 3-D Secure Solution Overview Cardholder Authentication Enter Your SecureCode Upon submitting the final order, the cardholder will be presented with an authentication window from their MasterCard card or Maestro cardissuing bank. At this point, the cardholder will enter his SecureCode value to perform authentication processing. * * * * * * Purchase Completed After validation of the cardholder SecureCode by the issuing bank, the authentication window will disappear and the authorization of the payment card will complete as usual September 2005 SecureCode Merchant Implementation Guide

38 3 Merchants This chapter provides a general overview of the various activities and requirements associated with building and maintaining the merchant components required to support MasterCard SecureCode. Overview Infrastructure Establishment of SecureCode Operating Environment Authorization System Enhancements Passing the AAV in the Authorization Message AAV Usage Passing the ECI in the Authorization Message Recurring Payments Maestro Considerations Account Number Length Requirements Authorization Request Timeframes Account in Good Standing Customization Program Identifier Usage Guidelines Integrated Support for Merchant Plug-In Processing Consumer Message on Payment Page Creation of Cardholder Authentication Window Pop-Up Authentication Windows Inline Windows With Frames Without Frames TERMURL Field Replay Detection Merchant Server Plug-In Configuration Initialization of MasterCard Directory URL Initialization of MPI Processing Timers Cache Expiration Timers Transaction Timeout Timers Initialization of MPI Processing Parameters TERMURL Zero or Empty Parameters SecureCode Merchant Implementation Guide September i

39 Merchants Overview Operational Loading of MasterCard Root Certificates Loading of MasterCard SSL Client Certificate MPI Log Monitoring MPI Authentication Request/Response Archival Accountholder Authentication Value (AAV) Processing Identification of SPA AAV Format in PARes Validation of Payer Authentication Response (PARes) Signature Global Infrastructure Testing Requirements MasterCard SecureCode Participating Merchant Listings MasterCard Site Data Protection Program Merchant Processing Matrix ii September 2005 SecureCode Merchant Implementation Guide

40 Merchants Overview Overview This chapter will outline the major activities and requirements associated with building and maintaining the merchant components required to support MasterCard SecureCode. The activities and requirements will be separated into five primary categories: Category Infrastructure Customization Operational Accountholder Authentication Value (AAV) Processing Global Infrastructure Testing Requirements Description Those requirements related to installation of new hardware and software components. Those requirements related to customizing or configuring vendor products. Those requirements related to operating the components in a production environment, including any process oriented changes that may be required. Those requirements related to handling and processing of the AAV. Those requirements related to testing of MasterCard SecureCode platform components. Definition Throughout this chapter, there will be references made to a merchant endpoint. This is any merchant implementation which connects directly to the MasterCard Directory Server. These may include, for example, individual merchants, hosting providers and payment service providers. Not all merchants participating in the SecureCode program are considered end-points. SecureCode Merchant Implementation Guide September

41 Merchants Infrastructure Infrastructure Establishment of SecureCode Operating Environment All merchants participating in the MasterCard SecureCode program are required to install or have access to a 3-D Secure v1.0.2 or higher compliant Merchant Server Plug-In. A current list of MasterCard SecureCode compliant vendors can be found at Authorization System Enhancements Passing the AAV in the Authorization Message MasterCard requires that the SPA AAV returned to the merchant in the Payer Authentication Response (PARes) message be included in all electronic commerce transactions in which cardholder authentication has been performed successfully. Currently this is defined as being when the merchant plug-in detects a value of Y in the transaction status field of the PARes message. Sep 2005 Note MasterCard currently utilizes a transaction status of A only when the cardholder opts out of enrollment during activation during shopping. For authorizations covered by the merchant-only liability shift, these transactions still meet the liability shift qualifying criteria when authorized by the issuer. Merchants must ensure that they follow the message formatting requirements of their acquirer when generating UCAF related authorization requests. There are two potential issues to consider: 1. MasterCard requires that the SPA AAV contained in the authorization from the acquirer to the issuer be base64 encoded. Passing this data in binary format is not an option. Merchant plug-in software typically provides the SPA AAV returned in the PARes message already in this format. While some acquirers allow merchants to simply pass the base64 encoded SPA AAV through in the authorization, others have varying requirements. Depending on the specific merchant system and acquirer message formats, it may be necessary for the SPA AAV to be converted between ASCII and EBCDIC encoding prior to it being sent to the acquirer. Any such conversion must only be performed on the SPA AAV after it has been base64 encoded. Any attempt to modify the binary representation of the SPA AAV will result in corruption of the data and the inability of the issuer to perform cardholder authentication verification processing. 3-4 September 2005 SecureCode Merchant Implementation Guide

42 Merchants Infrastructure For additional information on base64 encoding, refer to Accountholder Authentication Value Layout in appendix B. 2. While an authentication status of A is a valid PARes status response and will contain a SPA AAV, it is not considered to be a successful cardholder authentication. MasterCard requires that acquirers ensure that only unauthenticated authorization requests result from authentications with this particular status. This is similar to what would happen in the case of a status of N in the VERes message. In these cases, MasterCard requires that the SPA AAV provided with the PARes message be excluded from the authorization message. In some cases, the merchant will be required to exclude this from the authorization message sent to their acquirer. In other cases, the acquirer may require that the merchant send the SPA AAV and then exclude it prior to sending the authorization message to MasterCard. Sep 2005 If there are any questions, merchants should consult with their acquirers for more detailed information. AAV Usage The AAV contained within a single authorization request must match the AAV value returned by the issuer for a single associated authentication request. Reuse of an AAV across multiple authorization request messages is only permitted if these authorization requests are part of the same transaction information document (TID), for example; split shipment processing. In all cases, the total transaction amount of the authorization message(s) must not exceed the associated transaction amount contained in the authentication request. Passing the ECI in the Authorization Message An electronic commerce indicator (ECI) flag will be present in a PARes message when the status field contains a value of Y or A. The 3-D Secure protocol defines that this ECI field be determined by each brand. As a result, MasterCard has adopted values that may be different from other participating payment brands. Sep 2005 Most, if not all, acquirers and payment processors have defined the ECI as a required field in their authorization request message formats. Each merchant must ensure that the MasterCard ECI value is properly translated to a valid value as defined in the appropriate acquirer or payment processor authorization message format. Failure to perform the appropriate translation may affect the ability to obtain authorizations successfully. SecureCode Merchant Implementation Guide September

43 Merchants Infrastructure MasterCard has currently defined two ECI values. The table below indicates the relationship between these values and the status field in the PARes message. Any questions on translating MasterCard defined values for authorization should be directed to your acquirer or payment processor. PARes Status Field Description Y Cardholder was successfully authenticated 02 A Authentication could not be completed but a proof of authentication attempt was provided. The presence of the AAV from this response in a corresponding authorization message does not constitute a fully authenticated transaction and does not qualify for chargeback protection under the global liability shift as outlined in Section 1. MasterCard ECI Value 01 Sep 2005 Sep 2005 See Passing the AAV in the Authorization Message for more information N Cardholder authentication failed Absent U Authentication could not be completed due to technical or other problems Absent Sep 2005 Recurring Payments Only the initial authorization request for a recurring payment may contain UCAF data. Merchants must not provide UCAF data in any subsequent recurring payment authorizations as these are not considered electronic commerce transactions by MasterCard and are not eligible for participation in the MasterCard SecureCode program. Maestro cards are not eligible to be used for recurring payments. Sep 2005 Maestro Considerations The following requirements and activities are specific to merchant support of Maestro cards as part of the MasterCard SecureCode program. Contact your acquirer for a complete set of Maestro e-commerce acceptance requirements. Sep 2005 Account Number Length Requirements Maestro merchants must support cardholder account numbers that are from 13 to 19 digits in length. 3-6 September 2005 SecureCode Merchant Implementation Guide

44 Merchants Infrastructure Authorization Request Timeframes In the case of split shipment, Maestro merchants are required to notify the cardholder if original price is exceeded or the total completion of the order has taken more than 30 days from the time the cardholder placed the order. If the actual amount of the transaction is higher than the original authorization, then a new authorization for the additional amount if required. Maestro recommends that merchants advise cardholders at the time of check out that additional delivery fees may result in the case of a split shipment. Sep 2005 Account in Good Standing Merchants should support the Account in Good Standing Transaction. Refer to Maestro Considerations for more information. SecureCode Merchant Implementation Guide September

45 Merchants Customization Customization Program Identifier Usage Guidelines Merchants are required to adhere to the applicable usage guidelines as outlined in MasterCard SecureCode Program Identifier Usage Guidelines. Proof of adherence must be provided to MasterCard as a condition of successful completion of SecureCode functional testing. MasterCard highly recommends that all screen shots be provided for review as soon as possible in case changes are required. A copy of the MasterCard SecureCode logo artwork, as well as any updates to the program identifier usage guidelines, is available for download at Sep 2005 Integrated Support for Merchant Plug-In Processing The following sample diagram depicts a sample, high level, flow of a transaction through a merchant s e-commerce site that has integrated support for MasterCard SecureCode. 3-8 September 2005 SecureCode Merchant Implementation Guide

46 Merchants Customization Figure 3.01 Sample Integrated MasterCard SecureCode Solution This diagram indicates merchant best practices regarding SecureCode processing. Any transaction that does not result in a PARes status Y with an AAV and a successful signature validation, must be flagged as unauthenticated if the authorization request process continues. Consumer shops and selects items for purchase Merchant Plug-In checks if card is in cached card range No Yes Merchant prompts cardholder for payment information Merchant Plug-In generates VEReq to see if cardholder is enrolled in the program Received VERes=Y within timeout value? No Merchant displays order confirmation and the cardholder clicks the submit button Yes No Merchant Plug-In generates PAReq message to perform cardholder authentication PAReq Received within timeout value? Yes PAReq Signature Validation Successful? No Sep 2005 Yes Cardholder Authentication Failed? Yes No No PARes=A ECI=01 Interrogate Authentication Response PARes=U Interrogate reason code. Is it acceptable to continue? PARes=Y ECI=02 Merchant submits an unauthenticated authorization request Merchant submits authenticated authorization request with UCAF data in the UCAF transport field. Yes Unless otherwise indicated, this is the recommended default choice Merchant displays receipt page At the completion of the authentication process, the merchant should create an authorization message, which contains the appropriate UCAF related data fields. The associated merchant acquirer or processor will provide message specifications detailing UCAF related data fields within their authorization, clearing and settlement records. SecureCode Merchant Implementation Guide September

47 Merchants Customization Consumer Message on Payment Page MasterCard recommends the use of a consumer message on the payment page further indicating merchant participation in the program. The following page shows a sample message in use at a participating merchant s web site. Creation of Cardholder Authentication Window The 3-D Secure protocol is designed so that the creation of the cardholder authentication window is performed by the merchant. The actual content of the window is controlled by the cardholder s issuing financial institution. There are two primary methods for creation of this window. Of the two primary methods for creation of this window, only one approach, inline windows, is now acceptable for deployment. Previous implementation approaches based on pop-up authentication windows are no longer supported for new merchant implementations and existing merchants are expected to convert to an inline window implementation. Sep 2005 Pop-Up Authentication Windows Pop-up windows create a secondary browser window for performing cardholder authentication. Most early deployments of MasterCard SecureCode 3-10 September 2005 SecureCode Merchant Implementation Guide

48 Merchants Customization used this type of implementation. However, increasing use of pop-up blocking software by the major internet service providers (for example Earthlink, AOL, MSN, etc.) has a significant effect on this type of implementation. In addition, consumers have become wary of pop-up ads and many delete them as soon as they appear without ever looking at the content. MasterCard explicitly prohibits this type of implementation. Any merchant still supporting the use of a pop-up authentication window must modify its implementation. Sep 2005 Inline Windows Inline window implementations, which have proven to virtually eliminate the issues caused by pop-up authentication windows, are required for all new merchant implementations and existing pop-up implementations must convert to inline windows. By presenting a full-page view, it makes the SecureCode authentication process appear to be a seamless part of the merchant checkout process. This is particularly true if the merchant utilizes the with frames approach depicted below. Sep 2005 SecureCode Merchant Implementation Guide September

49 Merchants Customization With Frames Many merchants use frames to customize their MasterCard SecureCode deployments. In a frame implementation, only part of the full window is redirected to the issuer s access control server. A frame implementation allows the merchant to display a branded header, as well as explanation text that can assist cardholders who are new to the MasterCard SecureCode experience. Figure 3.02 Inline Authentication Window with frames Merchant Branded Header Frame Below is your card issuer s MasterCard SecureCode authentication page. If you have not already signed up for MasterCard SecureCode, your card issuer may ask you to do before proceeding with the purchase. Please follow the instructions below. If you encounter any difficulties, click here to return to the checkout page Authentication Frame For those merchants choosing to implement the frames approach displayed above: The use of active HTML links in the branded header frame is not allowed. Below the header frame, however, it is recommended to include a link that directs the cardholder back to the checkout page in case of technical difficulties. See Figure 3.02 for an example of sample text. The explanation text should be clear and concise. The text should not assume that the cardholder is already enrolled in MasterCard SecureCode and should not provide instructions that might conflict with the cardholder s issuer instructions. MasterCard strongly recommends against the use of newer frame technologies such as iframes and floating.net frames as some cardholders set their browsers to block such elements September 2005 SecureCode Merchant Implementation Guide

50 Merchants Customization The merchant should make sure that the authentication window frame is fully visible and is not located too low in the page due to long text or large upper frame. A minimum space of 400x400 pixels is required for the Access Control Server (ACS) frame. Merchants must ensure that the back button functionality works and cardholders who click on it are routed back to the checkout page. Sep 2005 Without Frames Figure 3.03 Inline Authentication Window without frames SecureCode Merchant Implementation Guide September

51 Merchants Customization TERMURL Field The TERMURL is a field that is provided by the merchant to the issuer during the payer authentication request process. This field provides the issuer with the merchant URL where the payer authentication response message is to be sent. The use of mixed HTTP and HTTPS frames typically results in a security box being presented to the cardholder. Depending upon how the cardholder responds to this dialog, the current and all future attempts to transmit the PAReq message may fail. As a result, merchants using inline authentication windows with frames must populate the TERMURL field with a HTTPS address. Sep 2005 Replay Detection Many issuer access control servers attempt to detect replay attacks by not allowing a transaction with the same account ID and XID to be processed more than once. Merchants must ensure that each Payer Authentication Request (PAReq) contains a unique combination of account id and XID. Sep 2005 Merchant Server Plug-In Configuration Initialization of MasterCard Directory URL Each merchant end-point must configure the MPI software to communicate with both the MasterCard SecureCode Directory server and the disaster recovery site. The current production MasterCard Directory server is located at The disaster recovery server, which is only activated as required, is located at Sep 2005 Initialization of MPI Processing Timers Cache Expiration Timers For those merchants using caching, the cache expiration period determines how often cached directory entries must be updated. MasterCard requires that it be updated no sooner than every 8 hours and no later than every 24 hours. The updates must not be performed at a specific time everyday in order to allow requests to the MasterCard directory to spread out through the day September 2005 SecureCode Merchant Implementation Guide

52 Merchants Customization Transaction Timeout Timers Transaction timeout periods determine how long to wait for a response to a Verification Request message and a Payer Authentication Request. In the case of PARes processing specifically, the wait times may vary because of the requirement for cardholder interaction. In practice, however, many financial institutions are utilizing existing consumer credentials (for example home banking passwords) for the MasterCard SecureCode program. As such, issues related to time consuming functions such as forgotten passwords are minimized. MasterCard recommends the following best practices regarding timeout values: Function Verify Enrollment Request Payer Authentication Request Timeout Values Action if timer expires prior to receipt of response 10 Seconds Continue as if the cardholder is not enrolled in the program (for example VERes transaction status = N ) MasterCard strongly encourages that the merchant allow up to 10 minutes for return of the PARes. Continue as if cardholder authentication failed (for example PARes transaction status = N ) Initialization of MPI Processing Parameters There are a number of MPI configuration parameters which, if not set properly, may cause 3-D Secure protocol violations. All merchants must ensure that their implementation plans account for the following field restrictions: The merchant name within any applicable message must be less than or equal to 25 characters including spaces. The merchant URL field in the PAReq message must be fully qualified and, ideally, should be the URL of the merchant home page. Many ACS providers present this URL to cardholders, including an active HTML link that directs cardholders to this address. The merchant country code must be a valid, 3 digit, ISO 3166 country code. The purchase currency code must be a valid, 3 digit, ISO 4217 currency code. SecureCode Merchant Implementation Guide September

53 Merchants Customization TERMURL Merchants must ensure that the TERMURL used for testing is modified to properly reflect the production environment. In addition, the TERMURL field must be fully qualified. Zero or Empty Parameters Merchants should make sure that all parameters sent to the ACS are valid and, unless otherwise indicated by the 3-D Secure protocol, do not contain zero or empty data elements. Sep 2005 For example: 1. The transaction amount should contain a non-zero amount. While technically allowed, sending zeros may cause mishandling of the transaction by the ACS. 2. The MD field must always be provided even if it is not used. 3. If optional fields are not utilized, MasterCard recommends they be excluded from the message instead of utilizing empty data elements September 2005 SecureCode Merchant Implementation Guide

54 Merchants Operational Operational Loading of MasterCard Root Certificates At the time of publication, MasterCard currently has two active roots that must be loaded Merchant end-points are required to load all active and pending MasterCard Root hierarchy certificates. This root will be required by the merchant plug-in to perform digital signature validation. It may also be required in order to establish SSL sessions using certificates based on the MasterCard private hierarchy. Loading of MasterCard SSL Client Certificate Merchant end-points are responsible for obtaining all necessary SSL client and server certificates for use by the MPI platform. Individual merchants will be required to utilize a single MasterCard hierarchy SSL client certificate for their acquirer. If a processor is utilizing the merchant plug-in, MasterCard does not require an individual certificate for each merchant. However, the processor will be required to utilize a separate and distinct client certificate for each applicable acquirer. For more information on certificate requirements and procedures, refer to Component Certificate Requirements and Authentication Options, chapter 7, in the SecureCode Member Enrollment and Implementation Guide. Sep 2005 MPI Log Monitoring Merchant end-points should establish a policy of monitoring MPI logs for various authentication failure messages including signature validation failures. Repeated failures should be reported to the merchant s acquirer. MPI Authentication Request/Response Archival Merchants, or merchant end points, should establish a policy for archival of authentication request and response messages. MasterCard recommends that the archival period for this data be the same as the associated authorization transaction data. This should be a minimum of 180 days. Sep 2005 SecureCode Merchant Implementation Guide September

55 Merchants Accountholder Authentication Value (AAV) Processing Accountholder Authentication Value (AAV) Processing The following processing steps are required by the 3-D Secure protocol and typically handled by the MPI. Any subsequent processing is the responsibility of the merchant. Identification of SPA AAV Format in PARes The CAVV algorithm field in the PARes message indicates the algorithm used to create the cryptogram contained in the CAVV field. All MasterCard AAV values will be identified with a value of 3 (MasterCard SPA Algorithm). This is the only value that is permitted for MasterCard card and Maestro card transactions. Validation of Payer Authentication Response (PARes) Signature All PARes messages returned to the merchant are digitally signed by the associated cardholder s issuer ACS using MasterCard provided certificates. The merchant is required to validate the signature prior to extracting the SPA AAV from the PARes message for inclusion in the authorization request sent to the acquirer. The AAV value in the PARes must be considered unusable if the signature validation process fails. Any subsequent authorization associated with this authentication attempt must be processed with no cardholder authentication data in the UCAF field September 2005 SecureCode Merchant Implementation Guide

56 Merchants Global Infrastructure Testing Requirements Global Infrastructure Testing Requirements All merchant end-points are required to complete MasterCard SecureCode functional testing. This includes execution of the MasterCard SecureCode System Test Agreement, as well as remittance of applicable fees. The purpose for this testing, which only encompasses cardholder authentication testing, is to ensure that merchant implementations meet minimum functional and brand requirements for participating in the MasterCard SecureCode program. Any additional authorization testing will need to be coordinated through the appropriate merchant acquirer or processor. Additional information on the MasterCard SecureCode testing process is available from MasterCard SecureCode Participating Merchant Listings Once a merchant site is live and is ready to begin processing SecureCode transactions, MasterCard can include the merchant URL in our list of participating merchants found on our consumer web site. To request a listing on this page, complete the request form at In addition, following submission of the request form, please send screen shots indicating compliance with the program usage guidelines for use of the SecureCode logo, including payment pages if available. These screen shots should be ed to securecodemerchant@mastercard.com. MasterCard Site Data Protection Program Sep 2005 The MasterCard Site Data Protection Program (SDP) represents a critical piece in the MasterCard comprehensive approach to payment card security. All merchants impacted by the SDP mandate must demonstrate compliance with the Payment Card Industry (PCI) security requirements to their acquirer. For more information on SDP, contact your acquirer or visit SecureCode Merchant Implementation Guide September

57 Merchants Merchant Processing Matrix Merchant Processing Matrix Sep 2005 The following table illustrates merchant behavior during various potential scenarios associated with MasterCard SecureCode authentication request processing. All information in this table is current. Authentication Scenario Authentication Process VEReq Sent? VERes Status PAReq Sent? Authorization Process PARes Notes Banknet DE48 Liability Shift (See Note) Authorization Proccessing Fully Status ECI AAV Recommendation SE42 SE43(UCAF) Merchant-Only Authenticated Authentication Success Yes Y Yes Y 02 Yes Yes Yes Yes Yes Authentication Failure (SecureCode failure) Yes Y Yes N - No No No Yes No Authentication Failure (Signature verification incorrect) Yes Y Yes All All All No No Yes No Unable to Authenticate Yes Y Yes U - No Merchant Optional No Yes No Unable to Authenticate Yes U No Yes No Yes No Attempt Yes Y Yes A 01 Yes Yes No Yes No Cardholder Not Participating Yes N No Yes No Yes No Cardholder Not Participating (via directory cache) No Yes No Yes No Error on DS No Yes No Yes No Error on VEReq Error - No Merchant Optional No Yes No Error on VERes Yes Error No Merchant Optional No Yes No Error on PARes Yes Y Yes Error Merchant Optional No Yes No Merchant Not SecureCode-enabled Yes No No No Authorization Processing Column: Based on the outcome of the authentication process, this column makes a recommendation on whether or not the merchant should proceed with authorization. Any transaction which does not result a PARes status "Y" with an AAV must be flagged as unauthenticated in the authorization request. Banknet DE 48: These indicators map to MasterCard authorization specification requirements for acquirers and issuers. SE42 is the Security Level Indicator and SE43 is the UCAF Data, which contains the AAV. Merchants must refer to the appropriate acquirer or payment processor message specifications for specific formatting requirements. Liability Shift (assumes issuer approval of the authorization message) The following MasterCard regions are currently covered by the "fully authenticated" liability shift for intra-regional transactions: North America. A fully authenticated transaction containing an AAV in the UCAF field is part of the eligibility requirements for the liability shift. All inter-regional transactions involving North America and LAC are also covered by the "fully authenticated" liability shift. The following MasterCard regions are currently covered by an intra-regional "merchant only" liability shift: Europe, AP, SAMEA, LAC. Merchant support for UCAF is just part of the eligibility requirements for the liability shift. All inter-regional transactions involving Europe, AP and SAMEA are also covered by the "merchant-only" liability shift. Notes: (1) Best practice would suggest that fraud may be involved and the merchant should prompt the consumer to try again or to use a different form of payment. (2) Refer to "Passing the AAV in the Authorization Message" for information on handling of the AAV in these cases (3) The merchant should check the reason for the error message before deciding whether to proceed with the authorization. Not all reason codes may indicate a failure September 2005 SecureCode Merchant Implementation Guide

58 A Merchant Customer Service Guide This section is intended to provide customer service staff with a general overview of the MasterCard SecureCode service, along with an understanding of the consumer experience, in order to provide assistance to customers when needed. Overview... A-1 Audience... A-1 Purpose... A-1 Frequently Asked Questions... A-2 What is MasterCard SecureCode?... A-2 What is a SecureCode?... A-2 What is the format of a SecureCode?... A-2 Why is our web site supporting SecureCode?... A-2 How does our web site support SecureCode?... A-2 What is a Personal Greeting?... A-3 What is the difference between authentication and authorization?... A-3 How does MasterCard SecureCode work?... A-3 What is the difference between a pop-up and an inline authentication window?... A-4 How does our web site know if a card is protected by MasterCard SecureCode?... A-4 Who knows the consumer s SecureCode?... A-4 What are the consumer s system requirements for MasterCard SecureCode?... A-4 How does a consumer enroll in the SecureCode program?... A-4 What information is contained on the SecureCode authentication window?... A-5 Will the authentication window appear if the consumer never enrolled in the SecureCode program?... A-5 What happens if the consumer does not know his SecureCode?... A-6 What happens if authentication fails?... A-7 What happens if the consumer does not choose to enroll or does not enter his SecureCode?... A-7 Cardholder Enrollment... A-8 Traditional Cardholder Enrollment... A-8 Activation During Shopping... A-9 SecureCode Merchant Implementation Guide September 2005 A-i

59 Merchant Customer Service Guide Consumer Buying Scenarios... A-10 Authentication - Successful... A-11 Authentication Forgotten SecureCode... A-12 Authentication Failed... A-14 Authentication Account Locked... A-16 Activation During Shopping... A-17 Activation During Shopping Opt Out of Enrollment... A-20 A-ii September 2005 SecureCode Merchant Implementation Guide

60 Merchant Customer Service Guide Overview Overview Audience This publication is designed for customer service staff at e-retailers that support MasterCard SecureCode. Purpose The purpose is to provide customer service staff a general overview of the MasterCard SecureCode service, along with an understanding of the consumer experience, in order to provide assistance to customers when needed. Note All screen shots in this document are samples. Actual consumer experiences may vary based on the specific implementation by the e-tailer and the cardissuing bank. Sep 2005 Definition Throughout this section, the term card issuer will refer to the bank of financial institution that issued the MasterCard card used by the consumer in the transaction. SecureCode Merchant Implementation Guide September 2005 A-1

61 Merchant Customer Service Guide Frequently Asked Questions Frequently Asked Questions What is MasterCard SecureCode? Today, when a consumer makes a purchase from your web site, there is no way to know if they are whom they say they are. MasterCard SecureCode is a new service from MasterCard that provides a mechanism for the consumer s identity to be validated by the bank that issued the consumer s card. By doing so, it provides your business with the ability to obtain a payment guarantee similar to what is available in the physical point-of-sale world. What is a SecureCode? A SecureCode is a secret password, known only to the consumer, which is used to validate his identity. Depending upon the consumer s bank, he may be asked to enter his SecureCode, SecureCode Password or simply Password. Regardless, all of these terms refer to the same thing. What is the format of a SecureCode? The format of a consumer s SecureCode will vary based on the security policy of the consumer s card-issuing bank. Typically, it will be a combination of between 4 and 10 letters and numbers. Why is our web site supporting SecureCode? MasterCard SecureCode gives your web site a method to securely authenticate the identity of the consumer. In the online world, there is no signed sales receipt and, in the case of a disputed purchase, it is difficult for you to prove that a consumer made a particular purchase. In those instances, your business is liable for unauthorized purchase fraud. By asking a consumer for a SecureCode, and obtaining confirmation from the consumer s card issuer, your business can obtain a guarantee against certain types of fraud. In addition, MasterCard consumer research has shown that consumers are more confident shopping at web sites that support SecureCode. How does our web site support SecureCode? In order to participate in SecureCode, your web site has new functionality that works to connect consumers with their card issuer so that their identity can be validated each time they make a purchase. Your web site may have decided to purchase and operate Merchant Plug-in software from an outside vendor. A-2 September 2005 SecureCode Merchant Implementation Guide

62 Merchant Customer Service Guide Frequently Asked Questions Alternatively, your web site may be communicating with a server that runs the software program. Depending upon the implementation, there are times when consumers may be presented with vendor-specific error codes. Your technical support staff should consult with your vendor or service provider for a list of these codes. What is a Personal Greeting? The Personal Greeting is a message that the consumer creates when he registers for his card issuer s SecureCode program. During an online purchase, the Personal Greeting will appear in the pop-up box from the card issuer. The Personal Greeting is the consumer s assurance that he is communicating with, and submitting his SecureCode to, the card issuer. What is the difference between authentication and authorization? Authentication is the process of validating a consumer s identity prior to completing the purchase. MasterCard SecureCode is a cardholder authentication program. Authorization is the process of obtaining approval from the credit card issuing bank for a specific purchase. How does MasterCard SecureCode work? First, a consumer must register and create a SecureCode. Each time an online purchase is made at a participating e-retailer, a window will automatically appear asking for his SecureCode. Sometimes this window will be a separate pop-up window, while other times it may be part of the existing browser display. The exact implementation is controlled by your web site. After reviewing the details of the purchase and confirming that the Personal Greeting is correct, the consumer simply enters the appropriate SecureCode to complete the purchase. When the consumer correctly enters his SecureCode, the card issuer confirms that he is the authorized user of that card and provides your web site with a piece of data, called the accountholder authentication value, which proves that the authentication was successful. This value must be added to the credit card authorization request to prove that authentication was performed. If a consumer does not enter the correct SecureCode, the card issuer cannot confirm the identity, and no authentication token is provided. In this particular instance, your web site may choose to continue with the authorization or ask the consumer for an alternative form of payment. SecureCode Merchant Implementation Guide September 2005 A-3

63 Merchant Customer Service Guide Frequently Asked Questions What is the difference between a pop-up and an inline authentication window? The SecureCode program is designed so that the merchant is responsible for creating the authentication window and the card issuer is responsible for the content of this window. Merchants create an inline window, which will appear as part of the current browser session. Sep 2005 How does our web site know if a card is protected by MasterCard SecureCode? Sep 2005 When a consumer uses a card that is enrolled in MasterCard SecureCode at your web site, the SecureCode software automatically makes an inquiry to MasterCard, which will check with the consumer s card-issuing bank. If the consumer is participating, the card issuer will open up a secure dialog with the consumer. This dialog will enable confirmation of the identity of the consumer and, assuming the correct SecureCode is entered, guarantee the purchase to the merchant. Who knows the consumer s SecureCode? The SecureCode value is known only by the consumer and his card-issuing bank. The dialog during which the consumer enters his SecureCode value takes place with the issuing bank only. No other parties, including your web site or MasterCard, are involved in this process. Your web site is simply notified of the result of this process via the SecureCode software. What are the consumer s system requirements for MasterCard SecureCode? MasterCard SecureCode works with most browsers. If the consumer has any difficulty performing authentication, he should contact his card issuer s customer service by calling the phone number on the back of his card. Sep 2005 How does a consumer enroll in the SecureCode program? Refer to Cardholder Enrollment for more information. A-4 September 2005 SecureCode Merchant Implementation Guide

64 Merchant Customer Service Guide Frequently Asked Questions What information is contained on the SecureCode authentication window? The authentication window is similar to the receipt that consumers sign in a store. It includes details such as where the purchase is being made and how much money is being spent. The actual content of this window is provided by the consumer s card issuing bank based on information provided by your web site. Will the authentication window appear if the consumer never enrolled in the SecureCode program? There are two situations where the authentication window may appear both of which are related to the enrollment process. A SecureCode has been selected by one authorized user and not communicated to the other authorized users on the account. For example, husband and wife. Most card issuers do provide the ability for each authorized user of the card to individually enroll and establish his/her own SecureCode. In that case, the SecureCode value for either user may complete the authentication process. The card issuer tries to enroll the consumer using Activation During Shopping. Refer to Activation During Shopping for more information. SecureCode Merchant Implementation Guide September 2005 A-5

65 Merchant Customer Service Guide Frequently Asked Questions What happens if the consumer does not know his SecureCode? It varies by card-issuing bank but consumers are usually given three chances to enter their SecureCode successfully. An invalid attempt will result in a prompt to the consumer to try again. In the event that a consumer forgets his SecureCode, most card issuers provide an alternative mechanism to complete the authentication process. Typically, there is a Forgot my SecureCode link that the consumer can click to obtain assistance. After the allowable number of tries has been exceeded, the card-issuing bank may prompt the consumer with a series of questions to authenticate his identity (for example last four digits of social security number, birth date, signature panel code on card, etc.). If this information is successfully validated, a successfully authentication response will be returned to your web site. If not, the account will most likely be locked to prevent any further authentication attempts at your web site and also at other participating web sites. Refer to Authentication Forgotten SecureCode for more information. A-6 September 2005 SecureCode Merchant Implementation Guide

66 Merchant Customer Service Guide Frequently Asked Questions What happens if authentication fails? The result of a failed authentication depends on how your particular web site has been set up. At some web sites, a failed authentication will cause the e- retailer to request a different payment method before allowing the purchase to proceed. In other cases, the transaction may be submitted for authorization as an unauthenticated request. Refer to Authentication Failed for more information. What happens if the consumer does not choose to enroll or does not enter his SecureCode? Depending upon the particular card issuer s SecureCode program implementation, consumers may either be required to authenticate themselves or they will be given the option of canceling the process. When a consumer elects to cancel from the process, an alert will be displayed that gives them the option to return to the authentication window to continue the authentication process. Selecting OK will return the consumer back to the previous authentication window. Selecting Cancel will terminate the authentication window and return an authentication failed status indicator back to your web site. Your web site implementation will determine what is next presented to the consumer. Some e-tailers will continue with the authorization. Others choose to not accept payment from cards, which fail authentication, and instead, they ask for a different form of payment. Sep 2005 SecureCode Merchant Implementation Guide September 2005 A-7

67 Merchant Customer Service Guide Cardholder Enrollment Cardholder Enrollment Enrollment is the process whereby eligible MasterCard and Maestro branded cardholders will activate their cards for use in the program. This process typically occurs in one of two ways: Traditional Cardholder Enrollment Activation During Shopping The cardholder will need to go to his issuing bank s web site to enroll, prior to going shopping. The cardholder will activate his account during a purchase. It is important to remember that all enrollments are between the authorized cardholders and their card-issuing banks. MasterCard is not involved in the enrollment process. Traditional Cardholder Enrollment This type of enrollment typically takes place at a web site designated by the bank that issued the card. For example, it may be the bank s home page or home banking system. In a typical example: 1. The consumer will be asked to provide enrollment data. During this phase of the process, he will be asked a series of questions to prove his identity to their bank. This may include asking for information such as the last four digits of his social security number, birthdate, or signature panel code from the back of his credit card. 2. The answers to the questions will be validated either in-house at the bank or through a third party processor such as a credit bureau. 3. If the consumer answers the questions correctly, he is considered authenticated and will be allowed to establish his SecureCode for that particular MasterCard account number. The SecureCode will be stored by the card issuer for use later on during online purchases at participating e- retailers. A-8 September 2005 SecureCode Merchant Implementation Guide

68 Merchant Customer Service Guide Cardholder Enrollment Activation During Shopping Unlike the traditional enrollment process, Activation During Shopping (ADS) does not require the consumer to visit an enrollment web site before shopping. This type of enrollment, which has proven to be very successful, takes place during the shopping process. When an eligible consumer goes to checkout, the card-issuing bank will ask a series of questions similar to the traditional enrollment process. Providing the correct answers will result in both a successful enrollment and a successful authentication response returned to your web site. Refer to Consumer Buying Scenarios for a sample shopping scenario. SecureCode Merchant Implementation Guide September 2005 A-9

69 Merchant Customer Service Guide Consumer Buying Scenarios Consumer Buying Scenarios The following section provides sample screen shots of several consumer scenarios that may be encountered while shopping at your web site. Each of these scenarios occurs after the consumer elects to submit the order but prior your site actually initiating a request to authorize the transaction. Each of the scenarios begins at the point where this particular e-tailer is asking for final confirmation of the purchase. In addition, each scenario also assumes that the e-tailer has implemented pop-up authentication windows. Actual screen contents will most likely vary from the samples depicted. A-10 September 2005 SecureCode Merchant Implementation Guide

70 Merchant Customer Service Guide Consumer Buying Scenarios Authentication - Successful In this scenario, the consumer is presented with the authentication window as seen below. After entering the proper SecureCode, a message will returned to your web site indicating the authentication was performed successfully. At this point, your web site will send the fully authenticated authorization request to MasterCard for approval. An approved response for qualified requests will result in a payment guarantee to your company. SecureCode Merchant Implementation Guide September 2005 A-11

71 Merchant Customer Service Guide Consumer Buying Scenarios Authentication Forgotten SecureCode In this scenario, the consumer is presented with the authentication window to begin the process. However, in this case, the consumer does not know his SecureCode. A-12 September 2005 SecureCode Merchant Implementation Guide

72 Merchant Customer Service Guide Consumer Buying Scenarios In response to not knowing his SecureCode, the consumer clicks the Forgot Your SecureCode link. The following screen appears next: This particular financial institution has decided to tell the consumer that they must call the bank s customer service department for additional help and will return a failed authentication response to the merchant. In other cases, some financial institutions will prompt the consumer to answer a series of secret questions. Providing the proper answer to these questions will permit the consumer authentication process to complete successfully. SecureCode Merchant Implementation Guide September 2005 A-13

73 Merchant Customer Service Guide Consumer Buying Scenarios Authentication Failed In this scenario, the consumer is presented with the authentication window to begin the process. Unlike the previous example, the consumer thinks he knows his SecureCode. Each subsequent attempt to enter an invalid value will result in an error message on the authentication window. A-14 September 2005 SecureCode Merchant Implementation Guide

74 Merchant Customer Service Guide Consumer Buying Scenarios After a pre-determined number of attempts, the card-issuing bank may optionally lock the account and present the consumer with a display indicating that authentication has failed. In addition, the display may give information on how to obtain help in order to reset the SecureCode value for next time. Once the account has been locked, it may not be used for shopping at any participating e-tailer. The consumer must utilize the facilities provided by his card-issuing financial institution to reset his SecureCode. These may include the bank s customer service and/or SecureCode enrollment site. SecureCode Merchant Implementation Guide September 2005 A-15

75 Merchant Customer Service Guide Consumer Buying Scenarios Authentication Account Locked When card-issuing banks detect that potential fraud may be occurring, they will often lock the account to prevent authentication. One example of this is when the consumer unsuccessfully attempts to enter his SecureCode too many times. When the e-tailer attempts to perform authentication on these accounts, the response back from the card issuer will be that authentication has failed. A-16 September 2005 SecureCode Merchant Implementation Guide

76 Merchant Customer Service Guide Consumer Buying Scenarios Activation During Shopping Unlike the previous scenarios, this example shows what may happen to a consumer that is not currently enrolled in his card issuer s SecureCode program. Instead of being provided with a window to enter his SecureCode, the consumer is provided with a window in which he can enroll in the program and authenticate himself for the current transaction. This window will typically ask a series of secret questions. If correct answers are provided to the questions, the merchant will be returned a status indicating that the consumer was successfully authenticated just as if he had entered a valid SecureCode. SecureCode Merchant Implementation Guide September 2005 A-17

77 Merchant Customer Service Guide Consumer Buying Scenarios If the incorrect responses are provided to the questions, the consumer will be given at least one more opportunity to provide the appropriate answers. A-18 September 2005 SecureCode Merchant Implementation Guide

78 Merchant Customer Service Guide Consumer Buying Scenarios If the incorrect answers are provided too many times or if the consumer chooses not to enroll in the program at the current time, a message will be displayed to the consumer indicating that the purchase will continue without a SecureCode value. To your web site, this means the credit card authorization will be unauthenticated. At this point in time, the merchant will be notified that consumer authentication has failed. In this particular case, merchants may either request an alternative form of payment or proceed with an unauthenticated authorization request. SecureCode Merchant Implementation Guide September 2005 A-19

79 Merchant Customer Service Guide Consumer Buying Scenarios Activation During Shopping Opt Out of Enrollment In this scenario, the consumer opts not to enroll in the program at the current time. Instead of providing answers to the questions on the window, the consumer clicks the Do Not Activate button. A-20 September 2005 SecureCode Merchant Implementation Guide

80 Merchant Customer Service Guide Consumer Buying Scenarios At this point in time, the e-tailer will be notified that the consumer declined to enroll in the program. In this particular case, the e-tailer should proceed with an unauthenticated authorization using the current card number. MasterCard requires that card issuers give cardholders at least three chances to enroll in the SecureCode program. If the cardholder does not enroll after three chances, some card issuers will not give the cardholder the ability to opt-out of their SecureCode program, and will, in fact, lock the account and present the consumer with a display indicating that authentication has failed. Once the account has been locked, it may not be used for shopping at any participating e-tailer. The consumer must utilize the facilities provided by his card issuer financial institution to enroll in SecureCode. These may include the bank s customer service and/or SecureCode enrollment site. SecureCode Merchant Implementation Guide September 2005 A-21

81 B MasterCard SecureCode SPA Algorithm Specification This chapter contains the layout of the Accountholder Authentication Value (AAV) to be used by issuers participating in MasterCard SecureCode, as well as an overview of Base64 encoding. Overview... B-1 Accountholder Authentication Value Layout... B-1 Base64 Encoding... B-1 Introduction... B-1 Examples... B-2 AAV Control Byte hexadecimal 8C (Successful cardholder authentication)... B-2 AAV Control Byte hexadecimal 86 (Attempted cardholder authentication)... B-2 Base64 Alphabet... B-4 SecureCode Merchant Implementation Guide September 2005 B-i

82 MasterCard SecureCode SPA Algorithm Specification Overview Overview This chapter includes the layout of the Accountholder Authentication Value (AAV) defined for use with MasterCard SecureCode. It also contains a brief overview of base64 encoding. Accountholder Authentication Value Layout For format of the AAV is defined and described in the SPA Algorithm for the MasterCard Implementation of 3-D Secure publication. This is a licensed publication available only to MasterCard members or any non-member that has successfully executed the SecureCode license agreement. Base64 Encoding The following overview of base64 encoding is taken from RFC1521 Mime (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies For more detailed information, refer to Introduction Base64 encoding is designed to represent arbitrary sequences of octets in a form that need not be humanly readable. The encoding and decoding algorithms are simple, but the encoded data are consistently about 33% larger than the un-encoded data. A 65-character subset of US-ASCII is used, enabling 6 bits to be represented per printable character. The extra 65 th character, =, is used to signify a special processing function. The encoding process represents 24-bit groups of input bits as output strings of four encoded characters. Proceeding from left to right, a 24-bit input group is formed by concatenating three 8-bit input groups. These 24 bits are then treated as four concatenated 6-bit groups, each of which is then translated into a single digit in the base64 alphabet. When encoding a bit stream via the base64 encoding, the bit stream must be presumed to be ordered with the most-significant-bit first. That is, the first bit in the stream will the high-order bit in the first byte and the eighth bit will be the low-order in the first byte, and so on. SecureCode Merchant Implementation Guide September 2005 B-1

83 MasterCard SecureCode SPA Algorithm Specification Base64 Encoding Each 6-bit group is then used as an index into an array of 64 printable characters. The character referenced by the index is placed in the output string. These characters, identified by Base64 Alphabet, are selected so that they are universally representable. The set excludes characters with particular significance to SMTP (e.g.,., CR, LF). Examples The following examples will perform the beginning steps of base64 encoding of an AAV control byte field. The encoding process for the remainder of the AAV will follow the same process. The decoding process will simply work in reverse. AAV Control Byte hexadecimal 8C (Successful cardholder authentication) Displaying hexadecimal 8C in its binary equivalent gives the following: The data is then broken down into three 24-bit segments, which are interpreted as four 6-bit segments for encoding. In this case, the first 6 bits equal: Converting this to its decimal equivalent yields the following: (1*2 5 ) + (0*2 4 ) + (0*2 3 ) + (0*2 2 ) + (1*2 1 ) + (1*2 0 ) Decimal 35 = Base64 j AAV Control Byte hexadecimal 86 (Attempted cardholder authentication) Displaying hexadecimal 86 in its binary equivalent gives the following: B-2 September 2005 SecureCode Merchant Implementation Guide

84 MasterCard SecureCode SPA Algorithm Specification Base64 Encoding The data is then broken down into three 24-bit segments, which are interpreted as four 6-bit segments for encoding. In this case, the first 6 bits equal: Converting this to its decimal equivalent yields the following: (1*2 5 ) + (0*2 4 ) + (0*2 3 ) + (0*2 2 ) + (0*2 1 ) + (1*2 0 ) Decimal 33 = Base64 h SecureCode Merchant Implementation Guide September 2005 B-3

85 MasterCard SecureCode SPA Algorithm Specification Base64 Encoding Base64 Alphabet Decimal Value Encoding Decimal Value Encoding Decimal Value Encoding Decimal Value 0 A 17 R 34 i 51 z 1 B 18 S 35 j C 19 T 36 k D 20 U 37 l E 21 V 38 m F 22 W 39 n G 23 X 40 o H 24 Y 41 p I 25 Z 42 q J 26 a 43 r K 27 b 44 s L 28 c 45 t M 29 d 46 u 63 / 13 N 30 e 47 v (pad) = 14 O 31 f 48 w 15 P 32 g 49 x 16 Q 33 h 50 y Encoding B-4 September 2005 SecureCode Merchant Implementation Guide

86 C Contact Information This section contains a list of MasterCard contact information. Contact Information... C-1 SecureCode Merchant Implementation Guide September 2005 C-i

87 Contact Information Contact Information Contact Information This chapter contains names, areas of responsibility, and contact information for MasterCard personnel who can assist members with electronic commerce enrollment, testing, and implementation issues. Area of Responsibility Completed and signed enrollment forms Maestro MasterCard Electronic Project Management Support and Pricing/Billing Contact Information Send all completed and signed enrollment forms to your MasterCard regional representative. The regional representative will forward the forms to the appropriate electronic commerce representative. Yves Lalieu Phone: Fax: yves_lalieu@mastercard.com Mercedes Garcia Phone: Fax: mercedes_garcia@mastercard.com Bruce Rutherford Phone: Fax: bruce_rutherford@mastercard.com Laura Quevedo Phone: Fax: laura_quevedo@mastercard.com Mark Wiesman Phone: Fax: mark_wiesman@mastercard.com Sep 2005 Information Security Jean-Paul Boly Phone: Fax: jean-paul_boly@mastercard.com Sep 2005 Johan Kestens Phone: Fax: johan_kestens@mastercard.com SecureCode Merchant Implementation Guide September 2005 C-1

88 Contact Information Contact Information For additional information on MasterCard SecureCode, please visit one of the following web sites: Consumer site: Merchant site: In addition, the e-business section of MasterCard OnLine contains additional program information. C-2 September 2005 SecureCode Merchant Implementation Guide

89 D MasterCard SecureCode Program Identifier Usage Guidelines This chapter contains guidelines, which are intended for all use of the MasterCard SecureCode word mark and/or the MasterCard SecureCode program identifier. Basic Edition v3.0 General Standards of Use...D-1 Authorized Use...D-1 MasterCard SecureCode Word Mark...D-1 MasterCard SecureCode Program Identifier...D-2 Approved Versions...D-2 Full-Color Version...D-2 Usage...D-2 Color Reproduction...D-3 Match Colors (Recommended)...D-3 Process Colors...D-3 Electronic Media Colors...D-4 Background Colors...D-4 Trapping Adjustments...D-4 Linked HTML Version...D-4 Usage...D-4 Linking...D-5 Color Reproduction...D-5 Background Colors...D-5 One-Color Version...D-5 Usage...D-5 Color Reproduction...D-6 Background Colors...D-6 Placement on a Merchant Web site...d-6 Placement within a MasterCard SecureCode Application or a Member Web site...d-8 Parity...D-9 Sizes...D-9 Authorized Artwork...D-10 SecureCode Merchant Implementation Guide September 2005 D-i

90 MasterCard SecureCode Program Identifier Usage Guidelines For More Information...D-10 D-ii September 2005 SecureCode Merchant Implementation Guide

91 MasterCard SecureCode Program Identifier Usage Guidelines General Standards of Use General Standards of Use The following guidelines are intended for all use of the MasterCard SecureCode word mark and/or the MasterCard SecureCode program identifier. The word mark/identifier is the exclusive property of MasterCard International Incorporated ( MasterCard ) and may not be used without the express written consent of MasterCard. These guidelines apply to use of the word mark/identifier in all media, including but not limited to use in print, the Internet, at tradeshows, and on promotional items. Note MasterCard may update these requirements from time to time. When available, updated versions of these guidelines, along with MasterCard approved artwork, are available for download at: Authorized Use The MasterCard SecureCode program identifier must be used by participating members and merchants of the MasterCard SecureCode Program. Use is intended to signify participation in the program and must be displayed on web sites. It may also be used in print and Internet marketing collateral. MasterCard reserves the right to review and approve all proposed use of the program identifier. MasterCard SecureCode Word Mark Always refer to the MasterCard SecureCode Program by its full name, MasterCard SecureCode. The MasterCard word mark must always appear in upper and lowercase letters, with a capital M and C and the remaining letters in lowercase; similarly, the word mark SecureCode must always appear in upper and lowercase letters, with a capital S and C and the remaining letters in lowercase. SecureCode Merchant Implementation Guide September 2005 D-1

92 MasterCard SecureCode Program Identifier Usage Guidelines MasterCard SecureCode Program Identifier At the first mention of MasterCard SecureCode on each web page or printed page, always add a registered trademark symbol after the word mark MasterCard, and the after the word mark SecureCode to read MasterCard SecureCode. The MasterCard SecureCode word mark must always appear in English and must never be translated into any other languages nor appear in another alphabet. MasterCard SecureCode Program Identifier The MasterCard SecureCode program identifier is comprised of the MasterCard word mark associated with the word mark SecureCode, in a customized typographic treatment. It must be reproduced only from authorized artwork provided by MasterCard International. Approved Versions The program identifier may appear in one of three approved versions, depending on the method of reproduction and the background color: Full-Color Version Linked HTML Version One-Color Version Full-Color Version Usage The Full-Color Version is recommended for use in all media and should be reproduced as specified below. Do not reproduce this version in one color. If the program identifier is reproduced in less than full color, the One-Color Version must be used. D-2 September 2005 SecureCode Merchant Implementation Guide

93 MasterCard SecureCode Program Identifier Usage Guidelines MasterCard SecureCode Program Identifier Color Reproduction When the Full-Color Version appears in printed media, it may be reproduced in match colors (recommended), four-color process colors, or a combination of the two, as described below. When it appears in electronic media, the colors must visually match the specified PANTONE colors by using the hexadecimal values below. PANTONE is a registered trademark of Pantone, Inc. The colors shown and specified in this chapter are not intended to match the PANTONE Color Standards. The standards for PANTONE Colors are shown in the current edition of the PANTONE Color Publications Match Colors (Recommended) The elements reproduce as follows: The word mark MasterCard and the symbol appears/prints in 100% MasterCard Red, PANTONE 485C The word mark SecureCode and the symbol appears/prints in 100% MasterCard Yellow, PANTONE 137C Process Colors Four-color process printing may be used only when the specified match colors are not available. The elements reproduce as follows: The word mark MasterCard and the symbol simulate MasterCard Red, reproducing as 100% Magenta + 100% Yellow The word mark SecureCode and the symbol simulate MasterCard Yellow, reproducing as 50% Magenta + 100% Yellow When the program identifier is being used in a four-color process printing situation and a fifth color is available, it is preferred that the fifth color be MasterCard Yellow, PANTONE 137C. In this case the word mark SecureCode and the symbol reproduce as MasterCard Yellow, PANTONE 137C. SecureCode Merchant Implementation Guide September 2005 D-3

94 MasterCard SecureCode Program Identifier Usage Guidelines MasterCard SecureCode Program Identifier Electronic Media Colors When the program identifier is displayed in electronic media, the following hexadecimal color values are required. If the program identifier is used to represent an active link, the Linked HTML Version must be used instead. The word mark MasterCard and the symbol appears as #CC0000 The word mark SecureCode and the symbol appears as #FF9900 The color values in the supplied gif files have been optimized to achieve the closest possible match to the specified PANTONE* colors. Background Colors The Full-Color Version may appear on any color background provided there is sufficient contrast to ensure the program identifier stands out from the background. White is the preferred background for the identifier. Trapping Adjustments Where a light or medium background color is used, the background color spreads to trap the program identifier. Where a dark background color is used, the program identifier spreads to trap the background but must always maintain its correct proportions. Linked HTML Version Usage The Linked HTML Version of the program identifier is designed for use on HTML web pages when the program identifier will link to a pop-up box containing program or registration information. This version must only be used when an active link is available. D-4 September 2005 SecureCode Merchant Implementation Guide

95 MasterCard SecureCode Program Identifier Usage Guidelines MasterCard SecureCode Program Identifier Linking When displayed on a merchant site, the required URL is nt=securecodepopup. When displayed on an issuer s site, the above URL is optional, or the issuer should create his or her own informational link. Color Reproduction When the Linked HTML Version is displayed electronically, the colors must visually match the specified PANTONE* colors by using the hexadecimal color values below. The word mark MasterCard and the symbol appears as #CC0000 The word mark SecureCode and the symbol appears as #FF9900 The text learn more appears as #0000FF The color values in the supplied gif files have been optimized to achieve the closest possible match to the specified PANTONE colors. Background Colors The Linked HTML Version may appear on any color background provided there is sufficient contrast to ensure the program identifier stands out from the background. White is the preferred background for the identifier. One-Color Version Usage The One-Color Version of the program identifier is designed for use in limitedcolor print communications where match color or four-color process printing is not available. This version must not be used in electronic media unless the media does not support full color reproduction. SecureCode Merchant Implementation Guide September 2005 D-5

96 MasterCard SecureCode Program Identifier Usage Guidelines MasterCard SecureCode Program Identifier Color Reproduction The One-Color Version reproduces in black, white, or MasterCard Dark Blue, PANTONE 2758C. When printing in process colors, MasterCard Dark Blue reproduces as 100% Cyan + 80% Magenta + 40% black. Background Colors The One-Color Version must appear on a background that provides sufficient contrast to allow optimum visibility of the program identifier. When printing in black or MasterCard Dark Blue, the One-Color Version must appear on a white or light-color background. When reversing to white, the One-Color Version must appear on a dark color background. When used in reverse, always reverse and reproduce the artwork as a unit. Placement on a Merchant Web site The program identifier is provided to merchants for display on their web sites to indicate their participation in the MasterCard SecureCode program. Use of the program identifier by participating merchants is mandatory. It is recommended that the program identifier appear on any page that displays payment options. Substantial free space between program identifier and payment acceptance marks must be maintained. See Minimum Free Space for more information. Sep 2005 The program identifier is also recommended for use in the trust mark space of a merchant web site. The identifier never should be used in place of, or directly paired with, the MasterCard or Maestro brand mark. (The MasterCard and/or Maestro acceptance brand mark always must be used to indicate acceptance of MasterCard cards and Maestro cards.) D-6 September 2005 SecureCode Merchant Implementation Guide

97 MasterCard SecureCode Program Identifier Usage Guidelines MasterCard SecureCode Program Identifier MasterCard must review and approve all proposed use of the program identifier on merchant web sites. Figure D.1 Recommended placement of the program identifier in the trust mark space of a merchant web site Minimum Free Space No visually distracting graphic element may surround or encumber the program identifier. This includes text, tag lines, logotypes, shapes, and strong background patterns. Generally, use a distance equal to the height of the M in MasterCard as a minimum free space around the program identifier. No other elements may be printed within the area of the program identifier. When the identifier is displayed on a webpage that displays payment acceptance marks, the minimum free space required from the acceptance marks is equal to 4x the overall width of the program identifier. SecureCode Merchant Implementation Guide September 2005 D-7

98 MasterCard SecureCode Program Identifier Usage Guidelines MasterCard SecureCode Program Identifier The program identifier should never be paired with the MasterCard or Maestro brand mark. Figure D.2 Minimum free space equal to 4x the overall width of the program identifier when displayed on pages with payment acceptance marks Placement within a MasterCard SecureCode Application or a Member Web site The program identifier is available for members or on behalf of application service providers to brand a MasterCard-sanctioned e-commerce authentication program. Use of the program identifier is required for all such programs and should appear in the enrollment screens and media as well as the authentication window. For additional information regarding requirements for issuer enrollment and authentication screens, refer to the MasterCard SecureCode Cardholder Interface Requirements publication. D-8 September 2005 SecureCode Merchant Implementation Guide

99 MasterCard SecureCode Program Identifier Usage Guidelines MasterCard SecureCode Program Identifier The program identifier never should be used in place of, or be directly paired with the MasterCard brand mark or Maestro brand mark. It is acceptable for an issuer to use both the brand mark and the program identifier on the same page with the issuer brand mark provided the marks are treated as separate elements and minimum free space requirements are met. Parity The program identifier must be displayed at least at visual parity (in terms of both color and size) with any other marks similarly displayed. Adjust final size to achieve visual parity, but do not alter the proportions or arrangement of the elements in the program identifier. While merchants may display multiple marks on their web site, issuer enrollment and authentication screens must not contain any other authentication program identifiers. Sizes The minimum size for all versions of the MasterCard SecureCode program identifier is 11mm (7/16 ) in width (measuring the width of the letters in the word mark MasterCard). SecureCode Merchant Implementation Guide September 2005 D-9