about this new manual - mastercard · about this new manual ... and describes the objectives of the...

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 e-mail address:

[email protected]

We continually strive to improve our publications. Your input will help us accomplish our goal of providing you with the information you need.

mailto:[email protected]

SecureCode Merchant Implementation Guide September 2005

© 2005 MasterCard International Incorporated

SecureCode Merchant Implementation Guide • September 2005 Publication Code: SMI

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.

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 63368-7263 USA

1-636-722-6100

www.mastercard.com

Sep 2005

http://www.mastercard.com/

Table of Contents


SecureCode Merchant Implementation Guide • September 2005 i

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

Maestro and Electronic Commerce.....................................................................1-1

The Opportunity to Grow Your Online Business with the MasterCard SecureCode Program...........................................................................................1-2

MasterCard SecureCode Platform Components .................................................1-3 What is UCAF?...............................................................................................1-3 What is an AAV?............................................................................................1-5 What is a Merchant Plug-In? .........................................................................1-5

Section 2 MasterCard SecureCode 3-D Secure Solution Overview

Overview .............................................................................................................2-1

Components ........................................................................................................2-2 Issuer Domain ...............................................................................................2-2 Acquirer Domain...........................................................................................2-3

Table of Contents


ii September 2005 • SecureCode Merchant Implementation Guide

Interoperability Domain................................................................................2-3

Messages ..............................................................................................................2-5 Card Range Request/Response.....................................................................2-5 Verification Request/Response .....................................................................2-5 Payer Authentication Request/Response......................................................2-5 Payer Authentication Transaction Request/Response .................................2-6

Cardholder Enrollment........................................................................................2-7 Cardholder Enrollment Process ....................................................................2-7 Sample Cardholder Enrollment Flow ...........................................................2-8

Cardholder Authentication ................................................................................2-13 Sample Cardholder Authentication Process ...............................................2-13 Sample Cardholder Authentication Flow ...................................................2-15

Section 3 Merchants

Overview .............................................................................................................3-3

Infrastructure .......................................................................................................3-4 Establishment of SecureCode Operating Environment ...............................3-4 Authorization System Enhancements ...........................................................3-4 Maestro Considerations.................................................................................3-6

Customization ......................................................................................................3-8 Program Identifier Usage Guidelines ...........................................................3-8 Integrated Support for Merchant Plug-In Processing ..................................3-8 Consumer Message on Payment Page .......................................................3-10 Creation of Cardholder Authentication Window .......................................3-10 TERMURL field ............................................................................................3-13 Replay Detection.........................................................................................3-14 Merchant Server Plug-In Configuration......................................................3-14

Operational........................................................................................................3-17 Loading of MasterCard Root Certificates ....................................................3-17 Loading of MasterCard SSL Client Certificate.............................................3-17 MPI Log Monitoring ....................................................................................3-17 MPI Authentication Request/Response Archival........................................3-17

Accountholder Authentication Value (AAV) Processing..................................3-18

Table of Contents


SecureCode Merchant Implementation Guide • September 2005 iii

Identification of SPA AAV format in PARes ...............................................3-18 Validation of Payer Authentication Response (PARes) signature .............3-18

Global Infrastructure Testing Requirements.....................................................3-19

MasterCard SecureCode Participating Merchant Listings .................................3-19

Merchant Processing Matrix ..............................................................................3-20

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

Table of Contents


iv September 2005 • SecureCode Merchant Implementation Guide

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

Table of Contents


SecureCode Merchant Implementation Guide • September 2005 v

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 i

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

Using this GuidePurpose


SecureCode Merchant Implementation Guide • September 2005 1

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 Description

Table of Contents A list of the manual’s chapters and subsections. Each entry references a chapter and page number.

Using this Guide 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

Using this Guide Excerpted Text


2 September 2005 • SecureCode Merchant Implementation Guide

Chapter Description

B MasterCard SecureCode SPA Algorithm Specification

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 MasterCard SecureCode Program Identifier Usage Guidelines

Contains guidelines, which are intended for all use of the MasterCard SecureCode word mark and/or the MasterCard SecureCode program identifier

E Maestro Considerations

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.

Using this GuideTimes Expressed


SecureCode Merchant Implementation Guide • September 2005 3

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)

9:00 10:00 15:00

Daylight saving time

(first Sunday in April to last Sunday in October)

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.

Using this Guide Support


4 September 2005 • SecureCode Merchant Implementation Guide

Support Please address your questions to the Customer Operations Services team as follows:

Phone: 1-800-999-0363 or 1-636-722-6176 1-636-722-6292 (Spanish Language support)

Fax: 1-636-722-7192

E-mail: Canada, Caribbean, and U.S. [email protected] Asia/Pacific [email protected] Europe [email protected] South Asia/Middle East/Africa [email protected] Latin America (Spanish

Language support) [email protected]

Address: MasterCard International Incorporated Customer Operations Services 2200 MasterCard Boulevard O’Fallon MO 63368-7263 USA

Telex: 434800 answerback: 434800 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: 1-800-999-0363 or 1-636-722-6176

1-636-722-6292 (Spanish Language support)







SecureCode Merchant Implementation Guide • September 2005 1-i

1 Overview This section provides a general overview of the MasterCard SecureCode Electronic Commerce program.

MasterCard and Electronic Commerce ...............................................................1-1

Maestro and Electronic Commerce.....................................................................1-1

The Opportunity to Grow Your Online Business with the MasterCard SecureCode Program...........................................................................................1-2

MasterCard SecureCode Platform Components .................................................1-3 What is UCAF?...............................................................................................1-3

UCAF Structure........................................................................................1-3 What is an AAV?............................................................................................1-5 What is a Merchant Plug-In? .........................................................................1-5

OverviewMasterCard and Electronic Commerce


SecureCode Merchant Implementation Guide • September 2005 1-1

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.

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

Sep 2005

Overview The Opportunity to Grow Your Online Business with the MasterCard SecureCode Program


1-2 September 2005 • SecureCode Merchant Implementation Guide

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.

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 2005

Sep 2005

OverviewMasterCard 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-of-sale 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.

Overview MasterCard SecureCode Platform Components



The generic structure of UCAF is illustrated below:

Con

trol B

yte

Application-Specific Data

1 BinaryByte

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 Base64 Encoded

Value Hexadecimal

Value

3-D Secure SPA AAV for first and subsequent transactions

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

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

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.

Sep 2005



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

Components ........................................................................................................2-2 Issuer Domain ...............................................................................................2-2

Cardholder Browser and Related Cardholder Software ........................2-2 Enrollment Server ...................................................................................2-2 Access Control Server .............................................................................2-2 AAV Validation Server/Process ..............................................................2-2

Acquirer Domain...........................................................................................2-3 Merchant Plug-In.....................................................................................2-3 Signature Validation Server ....................................................................2-3

Interoperability Domain................................................................................2-3 Directory Server ......................................................................................2-3 Certificate Authority ................................................................................2-4 Transaction History Server .....................................................................2-4 Attempts Server .......................................................................................2-4

Messages ..............................................................................................................2-5 Card Range Request/Response.....................................................................2-5 Verification Request/Response .....................................................................2-5 Payer Authentication Request/Response......................................................2-5 Payer Authentication Transaction Request/Response .................................2-6

Cardholder Enrollment........................................................................................2-7 Cardholder Enrollment Process ....................................................................2-7 Sample Cardholder Enrollment Flow ...........................................................2-8

Welcome .................................................................................................2-8 Enter Your Card Number........................................................................2-9 Terms & Conditions and Privacy Policy ................................................2-9 Validate Your Identity...........................................................................2-10 Validate Your Identity...........................................................................2-10 Create Your SecureCode ......................................................................2-11

MasterCard SecureCode 3-D Secure Solution Overview


2-ii September 2005 • SecureCode Merchant Implementation Guide

Congratulations .....................................................................................2-12

Cardholder Authentication ................................................................................2-13 Sample Cardholder Authentication Process ...............................................2-13 Sample Cardholder Authentication Flow ...................................................2-15

Enter Payment Information ..................................................................2-15 Confirm and Submit Order...................................................................2-15 Enter Your SecureCode ........................................................................2-16 Purchase Completed.............................................................................2-16

MasterCard SecureCode 3-D Secure Solution OverviewOverview



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.

Cardholder Browser

Related Cardholder Software

Enrollment Server

Access Control Server

AAV Validation Server/Process

Directory Server

Certificate AuthorityMerchant Plug-In

Signature Validation Server

Issuer Domain Interoperability Domain Acquirer Domain

• 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

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.

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.

Sep 2005

MasterCard SecureCode 3-D Secure Solution OverviewComponents



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.

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.

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.

Sep 2005

MasterCard SecureCode 3-D Secure Solution OverviewMessages



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.

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.

Sep 2005

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.

MasterCard SecureCode 3-D Secure Solution OverviewCardholder 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 e-mail changes) and review of recent purchases.

Enrollment Server

Issuer or 3rd PartyValidation

Acct Holder

File

Internet1

2

3

4

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.

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.




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.




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.




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




Congratulations

The cardholder is now ready to start shopping!

MasterCard SecureCode 3-D Secure Solution OverviewCardholder Authentication



Cardholder Authentication

Sample Cardholder Authentication Process

Cardholder Merchant Plug-In

SSL - 2

MasterCardDirectory

SSL -1

Issuer ACS

SSL -6

SSL -4

SSL -5

SSL - 3

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

Link Description

SSL-1 The cardholder shops at the merchant and, when ready to checkout, enters the appropriate payment information – including the account number

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

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

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

Sep 2005

Sep 2005

MasterCard SecureCode 3-D Secure Solution Overview Cardholder Authentication



Link Description

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

SSL-6 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 Plug-In

Merchant

Acquirer Issuer

Authorization Network

0100……[UCAF]…(Acquirer Message Format)

0100……[UCAF]…(Authorization Network Format)

Ucaf_Authentication_Data

- OR -

0200……[UCAF]…(Acquirer Message Format)

0200……[UCAF]…(Authorization Network Format)

(Banknet)

(MDS)

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.

MasterCard SecureCode 3-D Secure Solution OverviewCardholder 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.

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.

Tom JMaxwell

5400123456789000 November 2004

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® card-issuing 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.

* * * * * *



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

Infrastructure .......................................................................................................3-4 Establishment of SecureCode Operating Environment ...............................3-4 Authorization System Enhancements ...........................................................3-4

Passing the AAV in the Authorization Message.....................................3-4 AAV Usage ..............................................................................................3-5 Passing the ECI in the Authorization Message ......................................3-5 Recurring Payments ................................................................................3-6

Maestro Considerations.................................................................................3-6 Account Number Length Requirements.................................................3-6 Authorization Request Timeframes ........................................................3-7 Account in Good Standing .....................................................................3-7

Customization ......................................................................................................3-8 Program Identifier Usage Guidelines ...........................................................3-8 Integrated Support for Merchant Plug-In Processing ..................................3-8 Consumer Message on Payment Page .......................................................3-10 Creation of Cardholder Authentication Window .......................................3-10

Pop-Up Authentication Windows ........................................................3-10 Inline Windows.....................................................................................3-11

With Frames....................................................................................3-12 Without Frames...............................................................................3-13

TERMURL Field ...........................................................................................3-14 Replay Detection.........................................................................................3-14 Merchant Server Plug-In Configuration......................................................3-14

Initialization of MasterCard Directory URL ..........................................3-14 Initialization of MPI Processing Timers................................................3-14

Cache Expiration Timers ................................................................3-14 Transaction Timeout Timers ..........................................................3-15

Initialization of MPI Processing Parameters.........................................3-15 TERMURL ..............................................................................................3-16 “Zero” or Empty Parameters.................................................................3-16

Merchants Overview


3-ii September 2005 • SecureCode Merchant Implementation Guide

Operational........................................................................................................3-17 Loading of MasterCard Root Certificates ....................................................3-17 Loading of MasterCard SSL Client Certificate.............................................3-17 MPI Log Monitoring ....................................................................................3-17 MPI Authentication Request/Response Archival........................................3-17

Accountholder Authentication Value (AAV) Processing..................................3-18 Identification of SPA AAV Format in PARes ..............................................3-18 Validation of Payer Authentication Response (PARes) Signature .............3-18

Global Infrastructure Testing Requirements.....................................................3-19

MasterCard SecureCode Participating Merchant Listings .................................3-19

MasterCard Site Data Protection Program ........................................................3-19

Merchant Processing Matrix ..............................................................................3-20

MerchantsOverview



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 Description

Infrastructure Those requirements related to installation of new hardware and software components.

Customization Those requirements related to customizing or configuring vendor products.

Operational Those requirements related to operating the components in a production environment, including any process oriented changes that may be required.

Accountholder Authentication Value (AAV) Processing

Those requirements related to handling and processing of the AAV.

Global Infrastructure Testing Requirements

Those requirements related to testing of MasterCard SecureCode platform components.

Definition Throughout this chapter, there will be references made to a merchant end-point. 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.

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 http://www.mastercardmerchant.com/securecode/vendors.html.

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.

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.

Sep 2005

http://www.mastercardmerchant.com/securecode/vendors.html

MerchantsInfrastructure



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.

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.

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.

Sep 2005

Sep 2005

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

MasterCard ECI Value

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.

See “Passing the AAV in the Authorization Message” for more information

01

N Cardholder authentication failed Absent

U Authentication could not be completed due to technical or other problems

Absent

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.

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.

Account Number Length Requirements

Maestro merchants must support cardholder account numbers that are from 13 to 19 digits in length.

Sep 2005

Sep 2005

Sep 2005

Sep 2005

Sep 2005

MerchantsInfrastructure



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.

Account in Good Standing

Merchants should support the Account in Good Standing Transaction. Refer to “Maestro Considerations” for more information.

Sep 2005

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 http://www.mastercardmerchant.com/securecode/artwork.html.

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.

Sep 2005

http://www.mastercardmerchant.com/securecode/artwork.html.

MerchantsCustomization



Figure 3.01—Sample Integrated MasterCard SecureCode Solution

Consumer shops andselects items for

purchaseMerchant prompts cardholder for

payment information

Merchant displays orderconfirmation and the cardholder

clicks the submit button

Merchant displaysreceipt page

Merchant submitsauthenticated

authorization requestwith UCAF data in

the UCAF transportfield.

Merchant submits anunauthenticated

authorization request

MerchantPlug-In checks

if card is incached card

range

Merchant Plug-Ingenerates VEReq tosee if cardholder is

enrolled in the program

ReceivedVERes=Y

within timeoutvalue?

Merchant Plug-Ingenerates PAReq

message to performcardholder

authentication

CardholderAuthentication

Failed?

Yes

No

PARes=YECI=02

PARes=AECI=01 Interrogate

AuthenticationResponse

No

PARes=U Interrogatereason code. Is it

acceptable tocontinue?

No

Yes

Unless otherwiseindicated, this is therecommendeddefault choice

PAReqReceived

within timeoutvalue?

No

PAReqSignatureValidation

Successful?

Yes

Yes

Yes

No

Yes

No

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.

Sep 2005

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

Pop-Up Authentication Windows

Pop-up windows create a secondary browser window for performing cardholder authentication. Most early deployments of MasterCard SecureCode

Sep 2005




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.

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

Sep 2005




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 HeaderFrame

Authentication 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

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.




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

Without Frames

Figure 3.03—Inline Authentication Window without frames

Sep 2005




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.

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.

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 https://directory.securecode.com. The disaster recovery server, which is only activated as required, is located at https://directory2.securecode.com.

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.

Sep 2005

Sep 2005

Sep 2005

https://directory.securecode.com/

https://directory2.securecode.com/




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 Timeout Values Action if timer expires prior to receipt of response

Verify Enrollment Request

10 Seconds Continue as if the cardholder is not enrolled in the program (for example VERes transaction status = “N”)

Payer Authentication Request

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.




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.

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.

Sep 2005

MerchantsOperational



Operational

Loading of MasterCard Root Certificates

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.

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

At the time of publication, MasterCard currently has two active roots that must be loaded

Sep 2005

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.

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

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 http://www.mastercardmerchant.com/securecode/freeadvertising.html.

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

MasterCard Site Data Protection Program 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 http://www.mastercard.com/sdp.

Sep 2005


http://www.mastercardmerchant.com/securecode/freeadvertising.html


http://www.mastercard.com/sdp

Merchants Merchant Processing Matrix



Merchant Processing Matrix The following table illustrates merchant behavior during various potential scenarios associated with MasterCard SecureCode authentication request processing. All information in this table is current.

Notes

Status ECI AAV SE42 SE43(UCAF) Merchant-Only Fully Authenticated

Authentication Success Yes Y Yes Y 02 Yes Yes 2-1-2 Yes Yes YesAuthentication Failure (SecureCode failure) Yes Y Yes N - No No 1 2-1-1 No Yes NoAuthentication Failure (Signature verification incorrect) Yes Y Yes All All All No 1 2-1-1 No Yes NoUnable to Authenticate Yes Y Yes U - No Merchant Optional 3 2-1-1 No Yes NoUnable to Authenticate Yes U No - - - Yes 2-1-1 No Yes NoAttempt Yes Y Yes A 01 Yes Yes 2 2-1-1 No Yes NoCardholder Not Participating Yes N No - - - Yes 2-1-1 No Yes NoCardholder Not Participating (via directory cache) No - - - - - Yes 2-1-1 No Yes NoError on DS No - - - - - Yes 2-1-1 No Yes NoError on VEReq Error - No - - - Merchant Optional 3 2-1-1 No Yes NoError on VERes Yes Error No - - - Merchant Optional 3 2-1-1 No Yes NoError on PARes Yes Y Yes Merchant Optional 3 2-1-1 No Yes NoMerchant Not SecureCode-enabled - - - - - - Yes 2-1-0 No No No

Authorization Processing Column:

Banknet DE 48:

Liability Shift (assumes issuer approval of the authorization message)

Notes:

Authorization ProcessAuthentication Process

(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. (2) Refer to "Passing the AAV in the Authorization Message" for information on handling of the AAV in these cases

Banknet DE48

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

Authentication Scenario VEReq Sent?

VERes Status

PAReq Sent?

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.

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 (See Note)PAResAuthorizationProccessing

Recommendation

Error

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.

Sep 2005


SecureCode Merchant Implementation Guide • September 2005 A-i

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

Merchant Customer Service Guide


A-ii September 2005 • SecureCode Merchant Implementation 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

Merchant Customer Service GuideOverview


SecureCode Merchant Implementation Guide • September 2005 A-1

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 card-issuing bank.

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.

Sep 2005

Merchant Customer Service Guide Frequently Asked Questions


A-2 September 2005 • SecureCode Merchant Implementation Guide

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.

Merchant Customer Service GuideFrequently 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.




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.

How does our web site know if a card is protected by MasterCard SecureCode?

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.

How does a consumer enroll in the SecureCode program?

Refer to “Cardholder Enrollment” for more information.

Sep 2005

Sep 2005

Sep 2005




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.




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.




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

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 The cardholder will need to go to his issuing bank’s web site to enroll, prior to going shopping.

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

Merchant Customer Service GuideCardholder 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.

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.

Merchant Customer Service GuideConsumer 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.




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.




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.




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.




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.




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.




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.




If the incorrect responses are provided to the questions, the consumer will be given at least one more opportunity to provide the appropriate answers.




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.




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.




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 B-i

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

MasterCard SecureCode SPA Algorithm SpecificationOverview


SecureCode Merchant Implementation Guide • September 2005 B-1

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 http://www.ietf.org/rfc/rfc1521.txt?number=1521.

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

http://www.ietf.org/rfc/rfc1521.txt?number=1521

MasterCard SecureCode SPA Algorithm Specification Base64 Encoding


B-2 September 2005 • SecureCode Merchant Implementation Guide

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:

1 0 0 0 1 1 0 0

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:

1 0 0 0 1 1

Converting this to its decimal equivalent yields the following:

(1*25) + (0*24) + (0*23) + (0*22) + (1*21) + (1*20) 32 + 0 + 0 + 0 + 2 + 1 Decimal 35 = Base64 j

AAV Control Byte hexadecimal “86” (Attempted cardholder authentication)

Displaying hexadecimal 86 in its binary equivalent gives the following:

1 0 0 0 0 1 1 0

MasterCard SecureCode SPA Algorithm SpecificationBase64 Encoding


SecureCode Merchant Implementation Guide • September 2005 B-3

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:

1 0 0 0 0 1

Converting this to its decimal equivalent yields the following:

(1*25) + (0*24) + (0*23) + (0*22) + (0*21) + (1*20) 32 + 0 + 0 + 0 + 0 + 1 Decimal 33 = Base64 h

MasterCard SecureCode SPA Algorithm Specification Base64 Encoding


B-4 September 2005 • SecureCode Merchant Implementation Guide

Base64 Alphabet

Decimal Value Encoding




0 A 17 R 34 i 51 z

1 B 18 S 35 j 52 0

2 C 19 T 36 k 53 1

3 D 20 U 37 l 54 2

4 E 21 V 38 m 55 3

5 F 22 W 39 n 56 4

6 G 23 X 40 o 57 5

7 H 24 Y 41 p 58 6

8 I 25 Z 42 q 59 7

9 J 26 a 43 r 60 8

10 K 27 b 44 s 61 9

11 L 28 c 45 t 62 +

12 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


SecureCode Merchant Implementation Guide • September 2005 C-i

C Contact Information This section contains a list of MasterCard contact information.

Contact Information ........................................................................................... C-1

Contact InformationContact Information


SecureCode Merchant Implementation Guide • September 2005 C-1

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 Contact Information

Completed and signed enrollment forms

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.

Maestro Yves Lalieu Phone: +32 2 352 5554 Fax: +32 2 352 5830 E-mail: [email protected]

MasterCard Electronic Mercedes Garcia Phone: +1 914-249-5971 Fax: +1 914-249-4162 E-mail: [email protected]

Project Management Support and Pricing/Billing

Bruce Rutherford Phone: +1 914-249-5743 Fax: +1 914-249-4368 E-mail: [email protected] Laura Quevedo Phone: +1 914-249-6371 Fax: +1 914-249-4368 E-mail: [email protected]

Mark Wiesman Phone: +1 636-722-2340 Fax: +1 636-722-2878 E-mail: [email protected]

Information Security Jean-Paul Boly

Phone: +32 2 352 5988

Fax: +32 2 352 5839

Email: [email protected]

Johan Kestens Phone: +32 2 352 5477 Fax: +32 2 352 5839 Email: [email protected]

Sep 2005

Sep 2005








Contact Information Contact Information


C-2 September 2005 • SecureCode Merchant Implementation Guide

For additional information on MasterCard SecureCode, please visit one of the following web sites:

Consumer site: www.mastercard.com/securecode

Merchant site: www.mastercardmerchant.com/securecode

In addition, the e-business section of MasterCard OnLine contains additional program information.

http://www.mastercard.com/securecode

http://www.mastercardmerchant.com/securecode


SecureCode Merchant Implementation Guide • September 2005 D-i

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

MasterCard SecureCode Program Identifier Usage Guidelines


D-ii September 2005 • SecureCode Merchant Implementation Guide

For More Information.......................................................................................D-10

MasterCard SecureCode Program Identifier Usage GuidelinesGeneral Standards of Use


SecureCode Merchant Implementation Guide • September 2005 D-1

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:

http://www.mastercardmerchant.com/securecode/artwork.html

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.

http://www.mastercardmerchant.com/securecode/artwork.html

MasterCard SecureCode Program Identifier Usage Guidelines MasterCard SecureCode Program Identifier


D-2 September 2005 • SecureCode Merchant Implementation Guide

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.

MasterCard SecureCode Program Identifier Usage GuidelinesMasterCard 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.




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.




Linking

When displayed on a merchant site, the required URL is http://www.mastercardbusiness.com/mcbiz/index.jsp?template=/orphans&content=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 limited-color 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.

http://www.mastercardbusiness.com/mcbiz/index.jsp?template=/orphans&content=securecodepopup




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.

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

Sep 2005




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.




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.




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

MasterCard SecureCode Program Identifier Usage Guidelines Authorized Artwork



Authorized Artwork Use only the authorized artwork that is distributed with these guidelines. Never enlarge or reduce any of the elements of this artwork independently of each other. Always enlarge or reduce the artwork as a unit.

The artwork is provided in Adobe Illustrator EPS format. The artwork is also provided in gif format in a full range of sizes for use on the Internet and in other electronic media.

For More Information For consultation on approved use of the word mark/program identifier, please contact the MasterCard International Brand Strategy group at +1 914 249-1326.


SecureCode Merchant Implementation Guide • September 2005 E-i

E Maestro Considerations This chapter contains detailed information regarding Maestro specific processing issues associated with MasterCard SecureCode. For additional information, refer to the MDS Online Specification publication or the Host-EM Programmer Specifications publication.

Account in Good Standing..................................................................................E-1

Maestro ConsiderationsAccount in Good Standing


SecureCode Merchant Implementation Guide • September 2005 E-1

Account in Good Standing An account in good standing transaction is a request by a merchant to check the authenticity of a Maestro account number. Unlike other Maestro transactions, Account in Good Standing is not a financial transaction. It does not perform a value check or guarantee that the customer has sufficient funds to cover the purchase. The Maestro objective is to satisfy the merchant’s primary concern, which is ensure that the Maestro® card number being provided by the customer is not counterfeit.

Merchants must not confuse an Account in Good Standing transaction with a pre-authorization transaction used for self-service pumps at petrol/gas stations. These transactions are used to guarantee a block of funds up to the amount in the transaction, provided it is followed within 20 minutes by a completion transaction.

An account in good standing transaction is a standard authorization message with the following specific data content requirements:

Data Element Name Value

4 Transaction Amount One unit of purchase currency

61, subfield 7 Point-of-Service POS Data – POS Transaction Status

“4” – Preauthorized Request

These data elements must be used by the acquirer when placing an account in good standing transactions. Each acquirer is responsible for determining how this transaction is supported in the point of interaction message defined for the merchant to acquirer interface.

Sep 2005

about this new manual - mastercard · about this new manual ... and describes the objectives of the...

Documents