Mastercard SecureCode

Acquirer Implementation Guide

21 March 2017

CIR
 Summary of Changes, 21 March 2017

Summary of Changes, 21 March 2017

This document reflects changes effective since the last publication of this manual..

Description of Change Where to Look

Updated the Mastercard Secure Code And Identity See the attached spreadsheet
Check Liability Shift Matrix

Updated the chart title from "Liability Shift— Liability Shift Rule Summary
Consumer Cards" to "Liability Shift—Cards and
Commercial Cards"
Removed chart "Libility Shift —Commercial
Cards"

Updated "Liability Shift" definition Mastercard SecureCode Merchant Process and

Liability Shift Matrix

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 2
 Contents

Contents

Summary of Changes, 21 March 2017...............................................................2

Chapter 1: SecureCode Acquirer Implementation Overview.................6

Mastercard and E-commerce.............................................................................................. 7
Maestro and E-commerce...................................................................................................7
Mastercard Debit................................................................................................................8
Mastercard SecureCode Program........................................................................................8
Typical Payment Transaction Participants...........................................................................10
Mastercard SecureCode Program Platform........................................................................11
What is UCAF and Its Structure?.................................................................................. 11
UCAF Transport in Mastercard Authorization Messages........................................... 13
Sample DE 48 Contents.......................................................................................... 14
What is an AAV?......................................................................................................... 15
What is a Merchant Plug-In..........................................................................................16
Rules to Support UCAF Liability Shift................................................................................ 16
Liability Shift Rule Summary.........................................................................................17
UCAF Compliance Requirements...................................................................................... 17
Authorization Requirements........................................................................................ 17
Debit/Single Message System Requirements.................................................................20
Clearing Requirements................................................................................................ 20
Enrollment Requirements................................................................................................. 20
Maintenance Requirements......................................................................................... 21
Participation Responsibilities for all Customers..................................................................21
Acquirer Responsibilities.............................................................................................. 22
Mastercard SecureCode Compliance and Functional Testing............................................. 23
Mastercard SecureCode Program Enrollment Procedure....................................................23
Mastercard Support..........................................................................................................24
Additional References...................................................................................................... 24

Chapter 2: 3-D Secure Solution...........................................................................26

3-D Secure Solution Overview.......................................................................................... 27
Components.................................................................................................................... 27
Issuer Domain..............................................................................................................27
Acquirer Domain......................................................................................................... 29
Interoperability Domain............................................................................................... 29
3-D Secure Solution Message Types.................................................................................. 31
Card Range Request/Response.....................................................................................31
Verification Request/Response..................................................................................... 31

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 3
 Contents

Payer Authentication Request/Response.......................................................................32

Payer Authentication Transaction Request/Response.................................................... 32
Cardholder Enrollment..................................................................................................... 32
Cardholder Enrollment Process.................................................................................... 32
Cardholder Authentication............................................................................................... 33
Sample Cardholder Authentication Process.................................................................. 33

Chapter 3: Mastercard SecureCode Cardholders....................................... 37

Cardholder Overview....................................................................................................... 38
Cardholder Infrastructure................................................................................................. 38
Cardholder Customization............................................................................................... 38
Cardholder Operational....................................................................................................38
Accountholder Authentication Value Processing............................................................... 39
Cardholder Global Infrastructure Testing Requirements.....................................................39

Chapter 4: Customer Interface Requirements............................................. 40

Purchase Authentication Page.......................................................................................... 41
Activation During Shopping Enrollment............................................................................ 41

Chapter 5: SecureCodeAcquirers........................................................................43
Acquirer Overview............................................................................................................44
Acquirer Infrastructure.................................................................................................44
Establishment of SecureCode Operating Environment............................................. 44
Digital Signature Key Management......................................................................... 45
Authorization System Message Enhancements........................................................ 45
Maestro Considerations.......................................................................................... 45
Acquirer Customization....................................................................................................47
Authentication Window Contents............................................................................... 47
Mastercard SecureCode Program Identifier Usage Guidelines....................................... 47
Acquirer Operational........................................................................................................ 48
Mastercard SecureCode Directory Server Maintenance................................................. 48
SSL and Digital Signing Certificates..............................................................................48
Mastercard SecureCode 360 Webinar Series................................................................ 48
Mastercard SecureCode Merchant Information............................................................ 49
Mastercard SecureCode Merchant Process and Liability Shift Matrix............................. 49

Chapter 6: Issuer Authentication Options.....................................................51

Issuer Authentication Options Background....................................................................... 52
Static Password................................................................................................................ 52
Random Static..................................................................................................................53

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 4
 Contents

Short Message Service (SMS)............................................................................................54

Mobile Application...........................................................................................................55
Chip and Pin.................................................................................................................... 56
Display Card.....................................................................................................................56
Other Authentication Options.......................................................................................... 57

Appendix A: Mastercard SecureCode Contact Information................. 59

Mastercard SecureCode Contact Information................................................................... 60

Appendix B: Maestro Processing Considerations...................................... 62

Account in Good Standing............................................................................................... 63

Appendix C: Mastercard Advance Registration Program

Requirements...............................................................................................................64
Maestro Advance Registration Program............................................................................ 65
MARP Merchant Use of Mastercard SecureCode...............................................................65
Issuer Participation in MARP............................................................................................. 66

Appendix D: India IVR Transations (SecureTelephone)........................... 67

Overview..........................................................................................................................68
Data Extensions to the Existing 3-D Secure Protocol..........................................................68
UCAF Transport in Mastercard Authorization Messages.................................................... 68
Mastercard SecureCode—Security Level Indicator (DE 48, subelement 42)................... 69
Universal Cardholder Authentication Field (DE 48, subelement 43)...............................70
What is an AAV?......................................................................................................... 70
Sample IVR Transaction Flow........................................................................................71
Mastercard SecureCode Compliance and Functional Testing.........................................71

Appendix E: Mastercard Extensions for the Brazil Market...................72

Brazil Market Extensions...................................................................................................73

Notices.............................................................................................................................75

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 5
 SecureCode Acquirer Implementation Overview

Chapter 1 SecureCode Acquirer Implementation Overview

This section provides a general overview of the Mastercard® SecureCode™ Electronic Commerce
program.

Mastercard and E-commerce...........................................................................................................7

Maestro and E-commerce............................................................................................................... 7
Mastercard Debit............................................................................................................................ 8
Mastercard SecureCode Program.................................................................................................... 8
Typical Payment Transaction Participants........................................................................................10
Mastercard SecureCode Program Platform.................................................................................... 11
What is UCAF and Its Structure?...............................................................................................11
UCAF Transport in Mastercard Authorization Messages........................................................13
Sample DE 48 Contents....................................................................................................... 14
What is an AAV?...................................................................................................................... 15
What is a Merchant Plug-In...................................................................................................... 16
Rules to Support UCAF Liability Shift............................................................................................. 16
Liability Shift Rule Summary......................................................................................................17
UCAF Compliance Requirements...................................................................................................17
Authorization Requirements..................................................................................................... 17
Debit/Single Message System Requirements............................................................................. 20
Clearing Requirements............................................................................................................. 20
Enrollment Requirements.............................................................................................................. 20
Maintenance Requirements...................................................................................................... 21
Participation Responsibilities for all Customers.............................................................................. 21
Acquirer Responsibilities........................................................................................................... 22
Mastercard SecureCode Compliance and Functional Testing.......................................................... 23
Mastercard SecureCode Program Enrollment Procedure.................................................................23
Mastercard Support...................................................................................................................... 24
Additional References................................................................................................................... 24

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 6
 SecureCode Acquirer Implementation Overview
Mastercard and E-commerce

Mastercard and E-commerce

E-commerce transactions account for a significant and increasing share of Mastercard® gross
dollar volume.
The number of remote transactions is increasing at a rate of more than 40 percent per year
and growing. For this reason, it is important to position e-commerce and mobile commerce
channels—web access from PCs, PDAs, mobile phones, and other wireless-enabled devices—
to increase gross dollar volume profitability by using security and authentication solutions that
authenticate cardholders. This reduces chargebacks and expenses that are 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 all parties for managing disputes and chargebacks. According
to Mastercard data, more than 70 percent of all chargebacks for e-commerce transactions are
associated with reason code 4837 (No Cardholder Authorization) or reason code 4863
(Cardholder Not Recognized), and are currently estimated at a cost of USD 34.00 per
chargeback to the industry. These reason codes are used 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, offering the
opportunity to authenticate the cardholder at the time of purchase. Disputed charges affect
all parties in a transaction—issuer, acquirer, cardholder, and merchant.

Maestro and E-commerce

Low credit card penetration in many countries has led to the use of inefficient payment forms
like cash on delivery, check, and domestic transfer/automated clearing house (ACH).
Mastercard® SecureCode™ will allow Maestro® cards to be used for Internet purchases in a
safe and secure environment. Mastercard SecureCode allows Maestro to be the first fully-
authenticated global debit brand accepted on the Internet.
Unless otherwise stated by domestic country rules, all Maestro Internet transactions provide
protection against chargebacks and fraud if the transaction was authorized by the issuer.
Unless otherwise stated by domestic country rules, all Maestro Internet transactions are
guaranteed. Please note that a merchant can not accept Maestro transactions unless they
support Mastercard SecureCode.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 7
 SecureCode Acquirer Implementation Overview
Mastercard Debit

Mastercard rules require any merchant that wants to accept Maestro to undertake Mastercard
SecureCode on every Maestro transaction unless they have applied and been accepted to the
Maestro Advance Registration Program (MARP).

NOTE: MARP is closed to new business and will be decommissioned 1 June 2015. For more
details, refer to Europe Region Operations Bulletin No. 2, 3 February 2014.

Mastercard recommends that issuers deploy an authentication solution for cardholders to have
appropriate evidence of cardholder participation in the case of a disputed transaction.

Mastercard Debit
Issuers of Debit® Mastercard (either single or dual message) should note that the Single
Message System is capable of supporting transport of the Universal Cardholder Authentication
Field™ (UCAF) value.
Issuers must ensure that authorization, and clearing for dual message are compliant with the
latest debit standards available on the Publications product on Mastercard Connect™. The
Mastercard® SecureCode™ authentication program occurs before an authorization takes place,
therefore, it can be used to authenticate any Mastercard card. Issuers should ensure that their
systems can support the transport of the Account Authentication Value (AAV) before
proceeding with a Mastercard SecureCode program.

Mastercard SecureCode Program

Mastercard® SecureCode™ offers flexible, robust, and easy-to-implement solutions for
cardholder authentication.
Because requirements vary from issuer to issuer, Mastercard places a premium on flexibility,
enabling issuers (with their ACS service provider) to choose from a broad array of security
solutions for authenticating their cardholders. As the need for strong authentication and
better consumer experience grow, new methods of authentication have evolved. The
migration to dynamic authentication with risk-based solutions is becoming more common.
Dynamic authentication can be one-time passwords (OTPs) via SMS, mobile device, or EMV
chip with or without display cards.
From a program perspective there are a number of decisions that an issuer has to make prior
to implementing Mastercard SecureCode.
• What is the issuer’s attitude to risk?
• When should you authenticate a transaction? Do you want to authenticate every
transaction or just those that fall into a certain risk profile? The Mastercard Risk Based
Authentication white paper may be relevant if a percentage is preferred.
• How should you authenticate? See Issuer Authentication Options for a selection of possible
Authentication options.
• How does this authentication strategy impact your current authorization strategy?

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 8
 SecureCode Acquirer Implementation Overview
Mastercard SecureCode Program

The decision on authentication strategy will influence the issuer’s Mastercard SecureCode
deployment and is, perhaps, the most important decision. This decision will balance the
following considerations:
• The cardholder experience that an issuer wants to support for their cardholders. Just as
card portfolios are segmented, authentication strategies can also be developed offering
multiple forms of authentication (for example, SMS for youth, and display card for High
Value).
• Cost of authentication
• Cost of fraud being experienced and projected
• Requirements from domestic regulators
When determining cost of deployment it is important to factor in the cost of both “Know
Your Customer” and “Identification and Verification” that affects any opt in service deployed
compared to the costs of a dynamic approach that does not require an opt-in by the
cardholder.
From a program perspective there are several decisions that an acquirer has to make prior to
implementing Mastercard SecureCode.
• Does the acquirer have concerns surrounding disintermediation or is it acceptable to allow
third-party vendors and service providers to supply merchants solutions?
• Does the acquirer want to directly support merchants? If so, then this will require a
minimum of a server based Merchant Plug-In solution available from any certified MPI
vendor. A list of the certified MPI vendors is available at www.mastercard.us/merchants/
securecode-vendors.html. Some merchants may require more than access to an MPI,
including for example, fraud management, or web design, that are commonly provided by
service providers such as DataCash. It is the acquirers responsibility to research what their
customer’s need and decide what propositions they want to offer.
• If reliant on third-party service providers who do you partner with? Are they certified for
submission of authorization on and clearing to the acquirers host systems? Are they PCI-
DSS compliant?
Although not within the acquirers area of responsibility, acquirers may be interested in the
following authentication information.
The most common solutions for Mastercard and Maestro® issuers is the use of static or
dynamic passwords. Dynamic password usage is typically based on the Chip Authentication
Protocol (CAP) that provides for the creation of a one-time use cardholder authentication
password. This scenario is similar to what the cardholder experiences in the face-to-face
environment using EMV chip card and personal identification number (PIN). CAP is now
available in a number of form factors ensuring that a single CAP Issuer solution can support
SMS, Mobile Applications, Display Card and the traditional CAP models using sleave devices.
See Issuer Authentication Options for more information on authentication options. 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 consumer-and-merchant-facing name for all existing and new
Mastercard cardholder authentication solutions. While these solutions may each appear quite

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 9
 SecureCode Acquirer Implementation Overview
Typical Payment Transaction Participants

different on the surface, these various approaches converge around the Universal Cardholder
Authentication Field™ (UCAF) mechanism and share a number of common features.
In every case, for example, two things occur:
1. Mastercard or Maestro cardholders are authenticated using a secure, private code that is
unique to them. Authentication can occur by weak implementation with static passwords;
or a stronger authentication approach can be implemented where the issuer pre-enrolls
cardholders with a static value or implements a one-time password (OTP) service provided
through text message, chip card reader, or on an EMV display card. Some local regulators
have more stringent rules based on region or country.
2. The authentication data is transported from party-to-party via the Mastercard UCAF
mechanism.
For more information about the Mastercard SecureCode platform components, see the
Mastercard SecureCode Program Platform section in this chapter.

Typical Payment Transaction Participants

In a face-to-face retail transaction or MO/TO transaction, electronic processing begins with the
merchant or the acquirer. In a Mastercard® SecureCode™ transaction, the electronic processing
begins with the cardholder.
The following paragraphs describe the bankcard payment participants that are involved in a
Mastercard SecureCode transaction.

Cardholder
A cardholder is an authorized user of a card issued by a licensed financial institution. In the e-
commerce environment, consumers and corporate purchasers interact with merchants
remotely, typically through personal computers. However, these points of interaction are
expanding to include new devices such as mobile phones. A cardholder uses a payment card
issued by a licensed Mastercard financial institution. Mastercard SecureCode will ensure that a
cardholder’s identity is authenticated prior to the completion of a purchase from a
participating merchant.
Cardholders participating in Mastercard SecureCode are expected to feel more confident
when shopping online and being authenticated by their issuer.

Issuer
An issuer is a Mastercard financial institution customer that issues either only Mastercard cards
or Mastercard and Maestro® cards. The issuer guarantees payment for an authorized
transaction using the payment card in accordance with payment card brand regulations and
local legislation. Specifically for Mastercard SecureCode, the issuer is responsible for providing
authentication services for eligible online purchases.
Mastercard and Maestro issuers can benefit from participating in Mastercard SecureCode by
increased transaction volume and value as consumer confidence increases from cardholder

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 10
 SecureCode Acquirer Implementation Overview
Mastercard SecureCode Program Platform

authentication programs. Mastercard issuers can benefit from lower dispute management and
processing costs.

Merchant
A merchant is a retailer, or any other person, firm, or corporation that, pursuant to a merchant
agreement, agrees to accept Mastercard and/or Maestro cards when properly presented. With
Mastercard SecureCode, the merchant can offer a cardholder an authenticated electronic
interaction over the Internet. A merchant that accepts payment cards must have a relationship
with an acquirer. Merchants can benefit from participating in Mastercard SecureCode in
several ways including reduced fraud and dispute costs, increased transaction volume and
value, protection from unauthorized card use, and access to the Maestro card base.

Acquirer
The Mastercard SecureCode program platform is comprised of a number of layered
components. As described in the following pages, each of the components provides for
specific authorization and authentication functionality during the processing of a Mastercard
SecureCode transaction.

Mastercard SecureCode Program Platform

The Mastercard® SecureCode™ program platform is comprised of a number of layered
components.
As described in the following sections, each of the components 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 POS transactions.

What is UCAF and Its Structure?

Universal Cardholder Authentication Field™ (UCAF) 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. This is also known as the Accountholder
Authentication Value (AAV).
Within the Mastercard authorization networks (that is the Single Message and Dual Message
System, and RSC) 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.
The generic structure of UCAF is illustrated as follows:

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 11
 SecureCode Acquirer Implementation Overview
Mastercard SecureCode Program Platform

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 that use UCAF for authentication collection and
transport will be assigned their own control byte value and the structure of the application-
specific data will be tailored to support the specifics of the security protocol.
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 Secure Payment
Application™ (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 that is approximately 33
percent larger than the binary equivalent. For this reason, the UCAF field is defined with a
maximum length of 32 positions. For more information about Base64 coding, refer to the
#unique_12 appendix.
The current Mastercard SecureCode control byte definitions include the following.

Base64 Encoded
Usage Value Hexadecimal Value
3-D Secure SPA Accountholder Authentication Value
j x‘8C’
(AAV) for first and subsequent transactions
3-D Secure SPA AAV for attempts h x‘86’

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 12
 SecureCode Acquirer Implementation Overview
Mastercard SecureCode Program Platform

UCAF Transport in Mastercard Authorization Messages

Mastercard has designated specific subelements within data element (DE) 48 (Additional Data
—Private Use) for the transport of Universal Cardholder Authentication Field™ (UCAF)-related
data and associated indicators in authorization messages.

NOTE: UCAF data or an AAV may not be reused in authorization. It should only be sent with
the original purchase authorization request. It should not be included in the Account status
check inquiry or within subsequent recurring transactions.

The following sections describe these subelements.

DE 48, Subelement 42 (Electronic Commerce Security Level Indicator)

The Electronic Commerce Security Level Indicator contains the fields representing the security
protocol and cardholder authentication type associated with the transaction. Mastercard
requires that subelement 42 be included, and properly populated for all e-commerce
transaction authorizations.
The preferred data values for Mastercard® SecureCode™ are:

Position Value Description

1—Security Protocol 2 Channel Encryption (for example, SSL)

2—Cardholder 1 Cardholder Certificate Not Used

Authentication

3—UCAF Collection 0 UCAF data collection is not supported by the merchant or a

Indicator Mastercard SecureCode merchant has chosen not to
undertake Mastercard SecureCode on this transaction.
1 UCAF data collection is supported by the merchant, and UCAF
data is populated (DE 48, SE 43 is present) and contains an
“attempt” AAV.)
2 UCAF data collection is supported by the merchant,
cardholder authentication was successful, and UCAF data is
present and contains a fully authenticated AAV. (DE 48, SE 43)
3 Merchant participates in MARP, Data collection is supported
and UCAF data (the MARP static AAV) is present (DE 48, SE
43)

DE 48, subelement 43 (Universal Cardholder Authentication Field)

The UCAF contains the encoded result of the authentication. This data is collected by the
merchant and may contain fully authenticated or attempts values generated by the issuing
Access Control Server (ACS) or the Mastercard Attempts Processing Service.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 13
 SecureCode Acquirer Implementation Overview
Mastercard SecureCode Program Platform

NOTE: MARP is closed to any new business and was decommissioned 1 June 2015. For more
details, refer to the Europe Region Operations Bulletin No. 2, 3 February 2014.

™
NOTE: The Universal Cardholder Authentication Field (UCAF) length is variable up to a
maximum of 32 positions. All acquirers and issuers must ensure that they can send and/or
receive contents in this field up to the maximum length of 32. Applications using this field,
such as Mastercard SecureCode, may provide contents that are less than the maximum length.
For Mastercard SecureCode specifically, this field will be 28 positions.

For additional information about the contents of this field for a Mastercard SecureCode
authorization request message, see What is AAV? in this chapter.

Sample DE 48 Contents
Following are samples of different DE 48 contents.

Properly Coded DE 48 UCAF Fields

The following are examples of properly coded Universal Cardholder Authentication Fields™
(UCAFs) within a Mastercard® SecureCode™ authorization request message. The content of
the DE 48, subelement 42 is underlined.

Scenario Sample DE 48

Mastercard Advance 5MARPPROGRAM9999999999999999

Registration Program (MARP)

Fully authenticated T420701032124328jHyn+7YFi1EUAREAAAAvNUe6Hv8=820252

authorization
NOTE: The UCAF field (DE 48, subelement 43) is a variable
length field up to a maximum of 32 positions. The Mastercard
SecureCode Accountholder Authentication Value (AAV), in this
case, is 28 characters in length. There must be no padding or
trailing spaces in the UCAF field.

Unauthenticated authorization T420701032114328hHyn+7YFi1EUAREAAAAvNUe6Hv8=820252

from UCAF enabled merchant
containing an Attempt AAV

Unauthenticated authorization T42070103210820252

from non-UCAF enabled
merchant

Improperly Coded DE 48 UCAF Fields

The following are examples of improperly coded UCAF fields within a Mastercard SecureCode
authorization request message. The content of the DE 48, subelement 42 is underlined.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 14
 SecureCode Acquirer Implementation Overview
Mastercard SecureCode Program Platform

Scenario Sample DE 48

UCAF data field is T420701032124332jJJLtQa+Iws8AREAEbjsA1MAAAA= 820252.

improperly padded
NOTE: The UCAF field (SE 43) is a variable length field up to a
maximum of 32 positions. The Mastercard SecureCode AAV is 28
characters in length. There must be no padding or trailing spaces in
the UCAF field.

Unknown Control Byte T4207010321243328CC744DB69D5739CFE0100008EA89433820252

and invalid length
indicator NOTE: The contents of the UCAF data field is not properly Base64.
Instead the field contains a character representation of the hex
Mastercard SecureCode AAV. The first character must be one of the
documented control bytes.

UCAF data field T43328CC744DB69D5739CFE0100008EA89433820252

contains binary AAV
data instead of Base64 NOTE: The Security Level Indicator (DE 48, SE 42) is required when
encoded data UCAF data (DE 48, SE 43) is present in the message. This results in a
Banknet format error. Also, the UCAF data content is hex-encoded
and not Base64-encoded.

What is an AAV?
The Accountholder Authentication Value (AAV) is a Mastercard® SecureCode™ specific token
that uses the Universal Cardholder Authentication Field™ (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. This AAV can be proof of a fully authenticated or an attempted authentication
transaction.
The AAV is 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. (This could be the Issuer ACS or, in the case of an
attempt, the Mastercard Attempt processing server.)
• Sequence number that can positively identify the transaction for that location
• Secret key used to create the Message Authentication Code (MAC), which is a
cryptographic method that ensures AAV data integrity, and binds 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.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 15
 SecureCode Acquirer Implementation Overview
Rules to Support UCAF Liability Shift

MARP Exception
For merchants that have qualified to participate in the Mastercard Advance Registration
Program (MARP), Mastercard assigns a static AAV that conforms to the same format as an
issuer-generated AAV.

NOTE: MARP is closed to new business and will be decommissioned 1 June 2015. For more
details, refer to Europe Region Operations Bulletin No. 2, 3 February 2014.

What is a Merchant Plug-In

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.
As part of the Mastercard SecureCode infrastructure requirements, all merchant endpoints
must implement application software capable of processing 3-D Secure messages. An
endpoint is described as any merchant or merchant processor platform, which directly
connects to the Mastercard SecureCode infrastructure.

NOTE: If a retailer has qualified and accepted a merchant for the Mastercard Advance
Registration Program (MARP), then Mastercard will assign a static Accountholder
Authentication Value (AAV) for use when the transaction is undertaken as MARP instead of
standard Mastercard SecureCode. This value is passed in plain text in the Universal
Cardholder Authentication Field™ (UCAF) field. For additional information, refer to the
Mastercard Advance Registration Program Requirements appendix.

Rules to Support UCAF Liability Shift

In support of the Mastercard® SecureCode™ program, Mastercard has implemented liability
shift programs governing specific fraud-related chargeback reason codes.
This section provides an overview of the Universal Cardholder Authentication Field™ (UCAF)
liability shift programs in effect as of the date of publication. For more information, see the
Chargeback Guide.
E-commerce Rules are provided in the Transaction Processing Rules available on Mastercard
Connect®. Issuers should reference this publication for full details of the responsibilities and
requirements when undertaking e-commerce transactions and the for the benefits of
Mastercard SecureCode with this product.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 16
 SecureCode Acquirer Implementation Overview
UCAF Compliance Requirements

DEFINITION: An intraregional transaction is one in which the acquiring institution and issuing
institution are in the same Mastercard region, for example, the U.S., Canada, Europe, Asia
Pacific, Middle East/Africa, and the Latin America/Caribbean regions.
An interregional transaction is one in which the acquiring institution and the issuing
institution are in different Mastercard regions.

Liability Shift Rule Summary

Issuers should always check the Chargeback Guide for the current liability shift rules.
The following table summarizes the applicability of the liability shift rules for qualifying
transactions across the Mastercard regions.

Liability Shift—Consumer Cards and Commercial Cards

* = Merchant-Only and Fully Authenticated Liability Shift

Issuing Regions

U.S. CAN EUR LA/C AP MEA

Acquiring U.S. * * * * * *

Regions CAN * * * * * *

EUR * * * * * *

LA/C * * * * * *

AP * * * * * *

MEA * * * * * *

UCAF Compliance Requirements

Support for processing of Universal Cardholder Authentication Field™ (UCAF) transaction data
is a co-requisite for all Mastercard® SecureCode™ acquirer implementations.

Authorization Requirements
Mastercard issuers and acquirers must modify their authorization systems to support the
required Universal Cardholder Authentication Field™ (UCAF) transaction data elements.
Further, it is a requirement that all qualifying transactions must be properly coded e-commerce
transactions.
The following table highlights the field requirements that are required for coding of
Mastercard® SecureCode™ e-commerce authorizations. For more information about the

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 17
 SecureCode Acquirer Implementation Overview
UCAF Compliance Requirements

coding of Mastercard SecureCode UCAF data elements for non-e-commerce transactions,

refer to the appropriate authorization message specification document. When implementing
Mastercard SecureCode with Masterpass™ wallet, refer to the Masterpass Merchant
Implementation Guide for authorization processing rules. When implementing Securecode
with Masterpass wallet, please refer to the Masterpass Merchant implementation guide for
authorization processing rules.

Data Element Comments

22 Point of Service Entry Mode

Subfield 01—POS Terminal Entry Mode 81—PAN entry via electronic commerce,
including chip

48 Additional Data—Private Use

TCC—Transaction Category Code Contains one of the following values:
• P = Payment Transaction
• T = All other non–face-to-face
transactions
• U = Unique (Refer to the GCMS
Reference Manual for additional
requirements regarding the use of this
value.
• X = Airline and Other Transportation
Services (regardless of whether or not
the transaction originates at a face-to-
face terminal)

Subfields
42—Electronic Commerce Security Level Contains the security level in positions 1
Indicator (Mandatory) and 2 and the UCAF collection indicator in
position 3
• Position 1 = Security Protocol (for
Mastercard SecureCode, the value is 2
—Channel)
• Position 2 = Cardholder Authentication
(for Mastercard SecureCode, the value
is 1–Cardholder Certificate Not Used)

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 18
 SecureCode Acquirer Implementation Overview
UCAF Compliance Requirements

Data Element Comments

42—Electronic Commerce Security Level Position 3—UCAF Collection Indicator.

Indicator (Mandatory) Valid values are:
• 0 = UCAF data collection is not
supported by the merchant for this
transaction or a Mastercard SecureCode
merchant has chosen not to undertake
Mastercard SecureCode on this
transaction.
• 1 = UCAF data collection is supported
by the merchant, and UCAF data may
be available (DE 48, subelement 43
should contain an “attempt” AAV for
Mastercard SecureCode)
• 2 = UCAF data collection is supported
by the merchant and UCAF data must
be populated and contains a fully
authenticated AAV. (DE 48, subelement
43)
• 3 = Merchant participates in MARP and
UCAF must be populated with the
Mastercard assigned static AAV (DE 48,
sub element 43)

43—Universal Cardholder Authentication Field Contains the encoded Mastercard

(Conditional) SecureCode-generated authentication
data.

61 Point-of-Service Data Contains the following values to uniquely

identify the ecommerce transaction.
Subfields
3—POS Terminal Location 2 = Off premises of card acceptor facility
(cardholder terminal including home PC,
mobile phone, PDA)
4—POS Cardholder Presence 5 = Electronic order (home PC, Internet,
mobile phone, PDA
10—Cardholder Activated Terminal Level 6 = Authorized Level 6 CAT: Electronic
commerce

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 19
 SecureCode Acquirer Implementation Overview
Enrollment Requirements

Debit/Single Message System Requirements

Issuers and acquirers of Debit Mastercard and Maestro® cards must modify their authorization
systems to support Universal Cardholder Authentication Field™ (UCAF) transaction data.
For more information about requirements to support UCAF, refer to the Single Message
System Specifications manual.

Clearing Requirements
In support of the Mastercard® SecureCode™ program, Mastercard requires that acquiring
members must support changes to the Global Clearing Management System (GCMS) clearing
records in support of associated interchange rate programs.
Mastercard requires that all clearing and chargeback records associated with an e-commerce
authorization message contain the DE 48, private data subelement 0052 (Electronic
Commerce Security Level Indicator). Failure to include this field will result in the message
being rejected by GCMS with an edit error. The contents of this field must be consistent with
the value of the DE 48, subelement 42, position 3 in the corresponding authorization
message. In addition, Universal Cardholder Authentication Field™ (UCAF) interchange rate
qualifications for all transactions acquired in the U.S. region are subject to interchange
compliance edits.

NOTE: Issuers should refer to the latest Interchange Manual for their region to determine
what interchange is applied for Full UCAF and Merchant UCAF transactions.

Enrollment Requirements
Following are acquirer requirements to participate in the Mastercard® SecureCode™ Electronic
Commerce Program:
• All participating customers must complete both a general enrollment form and the acquirer
program enrollment form. Refer to the Mastercard SecureCode Program Enrollment
Procedure section for additional information.
• Select a vendor or service provider to provide the required infrastructure (for example,
merchant plug-ins, access control servers, and more) if the acquirer has decided to directly
support an MPI.
• Select a vendor or service provider to provide the required infrastructure (for example,
merchant plug-ins, access control servers, and more) if the acquirer has decided to directly
support an MPI.
• Assign a program manager to manage, test, and integrate the current system with
Mastercard SecureCode, or to manage the recruitment of third parties or service providers
to provide Mastercard SecureCode to their e-commerce merchants.
• Ensure all authorization and clearing systems can support Universal Cardholder
Authentication Field™ (UCAF) data. For additional information, refer to the UCAF
Compliance Requirements section.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 20
 SecureCode Acquirer Implementation Overview
Participation Responsibilities for all Customers

The Mastercard E-commerce Program Manager will review and approve customer enrollment
materials.

Maintenance Requirements
Issuers and acquirers should regularly review the content of their existing registration
document, especially when key individuals noted in the registration move to other roles or
leave the organization.
If changes are required, update the form and send it for amendment of the current
registration to [email protected]. Issuers should regularly
maintain their Mastercard® SecureCode™ contact in the Member Information-Mastercard by
accessing the Applications page from Mastercard Connect™.

Participation Responsibilities for all Customers

The following sections explain customer roles and responsibilities for participation in the
Mastercard® SecureCode™ program. These roles and responsibilities are applicable for both
Mastercard and Maestro® issuers.

Customer Agreement to Abide by Mastercard Rules and Policies

Mastercard agrees to permit a member to participate in transactions involving the Mastercard
SecureCode program in return for which member agrees to be bound by all of the rules,
policies, and procedures relating to the Mastercard SecureCode program in effect at the time
the transactions are conducted whether formally enacted by Mastercard or communicated
through brochures, statements, guidelines or other member communications. Without
limiting the foregoing, member specifically acknowledges and agrees to be bound by the
Mastercard implementation of Mastercard SecureCode. Member understands and
acknowledges that all rules and policies relating to the Mastercard SecureCode program and
electronic commerce may be amended from time to time and are subject to change without
notice by Mastercard.

No Representations or Warranties
Mastercard makes no representations or warranties whatsoever with respect to the
Mastercard SecureCode program, including without limitation any software, hardware or
other technology built to Mastercard standards, any services provided by it, or any other
matter relating to or arising out of any implementation of the Mastercard SecureCode
specifications. Without limiting the foregoing, Mastercard specifically disclaims all
representations and warranties as to its operation of the Mastercard Certificate Authority.
Mastercard specifically disclaims all implied warranties of merchantability, fitness for a
particular purpose and non-infringement of third party intellectual property rights with respect
to any and all Mastercard SecureCode implementations whether or not Mastercard has been
advised, has reason to know, or is otherwise in fact aware of any information regarding the
foregoing.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 21
 SecureCode Acquirer Implementation Overview
Participation Responsibilities for all Customers

Indemnity and Limitation of Liability

Member agrees to indemnify and hold harmless Mastercard and its directors, officers,
employees, agents and affiliates against any and all claims arising out of member’s
participation in the Mastercard SecureCode program. Member agrees that it shall not assert
any claim or action against Mastercard arising out or otherwise connected in any way with the
Mastercard SecureCode program and hereby waives all such claims against Mastercard and
releases Mastercard from and against any and all liability for such claims. Without limiting the
foregoing, member specifically waives and releases Mastercard from any and all claims arising
out of its operation of the Mastercard SecureCode certificate authority. The foregoing
limitations of liability shall apply to any claim or cause of action under law or equity
whatsoever, including contract, warranty, strict liability, or negligence, even if Mastercard has
been notified of the possibility of such claims. The entire liability of Mastercard to member for
any and all acts, errors, and omissions relating to or arising out of or in connection with the
Mastercard SecureCode program shall be limited to USD 1,000.

License Agreement for Specifications

If member executes a license agreement for any Mastercard specifications related to the
Mastercard SecureCode Program (whether by written, click-wrap, or shrink-wrap agreement),
the terms of such license agreement shall have precedence and govern over the terms in the
Participation Responsibilities section of this chapter.

Acceptance of Terms
The signing of enrollment forms indicates that the member understands and agrees to the
terms and conditions set forth herein including but not limited to those above. The member
acknowledges that its acceptance of these terms and conditions is relied upon by Mastercard
in permitting member’s participation in the Mastercard SecureCode program.

Acquirer Responsibilities
The following are responsibilities specific to acquirers participating in the Mastercard®
SecureCode™ program.
• Soliciting merchants to participate in the Mastercard SecureCode program.
• Adhering to:
– Mastercard requirements for information and data security, including but not limited to
protection of Mastercard card numbers, Maestro account numbers, cardholder
enrollment information and management and protection of secret cryptographic keys.
– Applicable usage guidelines as published in the Mastercard SecureCode Program
Identifier Usage Guidelines section.
• Ensuring that merchants comply with the requirements documented within the Mastercard
SecureCode—Merchant Implementation Guide.
• Reporting to Mastercard on experiences and progress with merchants use of Mastercard
SecureCode products, shopping experiences, and related market research information.
• Providing:

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 22
 SecureCode Acquirer Implementation Overview
Mastercard SecureCode Compliance and Functional Testing

– Primary customer service for merchants.

– Testing resources to test the ability to process Authorization Request/0100 (for
Mastercard and Maestro cards in the Europe region) and Authorization Request/0200
(for Maestro cards) messages and receive Authorization Request Response/0110 (for
Mastercard cards and Maestro cards in the Europe region) and Authorization Request
Response/0210 (for Maestro cards) messages containing data specific to e-commerce.

Mastercard SecureCode Compliance and Functional Testing

Mastercard has developed vendor compliance testing, as well as issuer and merchant
functional testing, to ensure vendor products and member and merchant implementations are
compliant and successfully interoperate with all Mastercard® SecureCode™ platforms and
infrastructure.
Proof of Visa Certification of IVR-ACS and IVR-MPI development is required before Mastercard
compliance testing can commence.
All vendors, merchant endpoints, and issuers are required to complete the designated testing
process prior to launch. More information regarding testing is available from
[email protected].

Mastercard SecureCode Program Enrollment Procedure

The following information outlines the Mastercard® SecureCode™ enrollment procedure.
1. Request enrollment forms by sending an email message to
[email protected].
2. Complete and sign both the General and Acquirer enrollment forms for the Mastercard
SecureCode Electronic Commerce Program.
3. Submit the enrollment forms by email message to
[email protected].
After the authorized representative receives the completed and signed enrollment forms, the
Mastercard E-commerce Program team will:
1. Review and approve the forms and forward them to the appropriate internal groups for
review and approval. If necessary, site visits are scheduled.
2. Provide testing details and instructions to program contacts listed on the enrollment
forms.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 23
 SecureCode Acquirer Implementation Overview
Mastercard Support

Mastercard Support
Mastercard will provide support to customers enrolled in the Mastercard® SecureCode™
program.

Project Management Support

Mastercard team members are available to provide guidance and advice about member
implementation, subject to personnel availability. For specific contact information, refer to the
Mastercard SecureCode Contact Information section.

Regional Mastercard Office Support

Regional Mastercard offices will provide direction and planning support subject to personnel
availability.
All advice and information provided by Mastercard is subject to the disclaimers and limitations
on liability.

Additional References
Unless otherwise noted, all publications are available from the Publications section of
Mastercard Connect™.

Mastercard SecureCode Program Publications

Mastercard® SecureCode™ program publications include:
• Licensed publications available by email request to
[email protected]:
– SPA Algorithm for the Mastercard Implementation of 3-D Secure
– SecureCode ACS Security Requirements
– Mastercard SecureCode Production Procedures
• The following, which are available by sending an email request to
[email protected]:
– Chip Authentication Program—Functional Architecture
– Chip Authentication Program—Implementation Guide
– CAP 2007 Specifications Updates
– CAP 2007 Implementation Guide Update—CDOL
• The Mastercard SecureCode Toolkit, which can be accessed via the following web address:
– www.mastercard.com/us/merchant/security/what_can_do/SecureCode/toolkit/
SecureCode.html

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 24
 SecureCode Acquirer Implementation Overview
Additional References

NOTE: The documentation regarding the industry standard for 3-D Secure is not available
from Mastercard. These documents must be sourced under license from the standard owner.

Mastercard Authorization Specification Publications

Mastercard Authorization specification publications are as follows:
• Customer Interface Specification
• Regional Service Center Message Specification Manuals
• Single Message Specifications
• Quick Reference Booklet (contains state, country, and currency codes)
• Mastercard SecureCode web training and information presentations are available at https://
globalrisk.mastercard.com/securecode-360/.
• White paper on Risk-based Authentication is available at https://globalrisk.mastercard.com/
online-resources/.
• Issuer Best Practice Guide for SecureCode available at https://globalrisk.mastercard.com/
online-resources/.

Additional Mastercard Publications

Additional Mastercard publications that may be helpful include:
• Mastercard SecureCode—Issuer Implementation Guide
• Mastercard SecureCode—Merchant Implementation Guide
• GCMS Reference Manual
• Transaction Processing Rules
• Interchange Manual (region-specific)

3-D Secure Protocol Specification Publications

3-D Secure Protocol Specification documents include:
• 3-D Secure Functional Requirements Merchant Server Plug-In v1.0.2 6 May 2006
• 3-D Secure Functional Requirements Access Control Server v1.0.2 6 May 2006

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 25
 3-D Secure Solution

Chapter 2 3-D Secure Solution

This section provides an overview of the Mastercard implementation of 3-D Secure for Mastercard®
cards and Maestro® cards, including cardholder enrollment and payer authentication.

3-D Secure Solution Overview....................................................................................................... 27

Components.................................................................................................................................27
Issuer Domain.......................................................................................................................... 27
Acquirer Domain...................................................................................................................... 29
Interoperability Domain............................................................................................................ 29
3-D Secure Solution Message Types...............................................................................................31
Card Range Request/Response................................................................................................. 31
Verification Request/Response.................................................................................................. 31
Payer Authentication Request/Response................................................................................... 32
Payer Authentication Transaction Request/Response................................................................. 32
Cardholder Enrollment.................................................................................................................. 32
Cardholder Enrollment Process................................................................................................. 32
Cardholder Authentication............................................................................................................33
Sample Cardholder Authentication Process...............................................................................33

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 26
 3-D Secure Solution
3-D Secure Solution Overview

3-D Secure Solution Overview

Cardholder authentication is the process of verifying cardholder account ownership during a
purchase transaction in an online electronic commerce environment.
All Mastercard® SecureCode™ solutions 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
Secure Payment Application™ (SPA) algorithm and Universal Cardholder Authentication Field™
(UCAF) without any changes to the 3-D Secure specification, messages, or protocol.
The components described herein are organized according to requirements that fall within the
issuer, acquirer, and interoperability domains associated with the payment process.
• Issuer Domain—Systems and functions of the card issuing financial institutions and its
customers.
– Cardholder Browser
– Related Cardholder Software
– Enrollment Server
– Access Control Server
– Accountholder Authentication Value (AAV) Validation Server/Process
• Acquirer Domain—Systems and functions of the acquirer and its customers.
– Merchant Plug-In
– Signature Validation Server
• Interoperability Domain—Systems, functions, and messages that allow the Issuer Domain
and Acquirer Domain to interoperate. These components will be globally operated and
managed by Mastercard.
– Directory Server
– Certificate Authority
– Mastercard Authentication History Server
– Attempts Processing Server

Components
Following is information about components related to the Issuer Domain, Acquirer Domain,
and Interoperability Domain.

Issuer Domain
The Issuer Domain is comprised of the following components.
• Cardholder browser and related software
• Enrollment server

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 27
 3-D Secure Solution
Components

• Access control server

• Accountholder Authentication Value (AAV) validation server/process

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. Issuers may
perform their own validation or sign up for the Mastercard-hosted on-behalf service. To
register for the Mastercard-hosted on-behalf service, send an email to your regional Customer
Implementation Service team.
Mastercard recommends that issuers validate the AAV contained in the authorization message
prior to the authorization decision. This is considered a best practice, although it is not
required. With the implementation of the Mastercard Attempts Processing Service (Stand-In
Authentication), issuers that perform self-AAV validation will continue to be able to validate
AAV values generated by their Access Control Server (ACS) service. However, an issuer will not
have the ability to validate an attempt AAV generated by the Mastercard Attempts Processing
Service. Issuers that participate in the AAV validation on-behalf service will have all AAV values
validated.
The server of the Mastercard Attempts Processing Service will generate an attempt AAV when:
• The Issuer’s account ranges do not participate in Mastercard SecureCode.
• The Issuer’s ACS responds negative to the merchant enrollment verification message (VERes
= N) for unenrolled cardholders.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 28
 3-D Secure Solution
Components

• The Issuer’s ACS times out or is unavailable.

Under these circumstances, an issuer will not be able to validate a Mastercard generated
attempts AAV. For security reasons, the keys will not be shared.
For details about the AAV validation on-behalf service, refer to the Authorization Services
Details chapter of the Authorization Manual.

Acquirer Domain
The Acquirer Domain is comprised of the following components.
• Merchant plug-in (MPI)
• Signature validation server

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
The Interoperability Domain is comprised of the following components.
• Directory server
• Certificate authority
• Mastercard Authentication History Server
• Attempts server

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 access
control server for further processing.
All implementations of this platform must use the Mastercard SecureCode global directory
server for processing Mastercard and Maestro® transactions.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 29
 3-D Secure Solution
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 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 for communication
to the Directory Server and Mastercard Authentication History Server
• Issuer Digital Signing certificates issued under the Mastercard hierarchy for communication
to the Directory Server and History Server
In addition, 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.
For more information, refer to the Mastercard SecureCode—Production Procedures manual.

Mastercard Authentication History Server

The Mastercard Authentication History Server is a central repository of all authentication
activity occurring out of band from Mastercard Authorization systems. All Access Control
Server (ACS) service providers should implement communications with the History Server. For
questions relating to the History Server, contact Mastercard SecureCode Customer Support.
The History Server is a central repository of all authentication activity occurring within the
issuer ACS for all transactions that occurred, including the PAReq and PARes details.
The Mastercard SecureCode infrastructure supports this component server. All Access Control
Server (ACS) providers will need to implement communication with the History Server. Send
an email to [email protected] with questions.

Attempts Server
The Mastercard SecureCode infrastructure supports this component server.
The Mastercard Attempt processing server provides the merchant with an Attempt
Accountholder Authentication Value (AAV) when:
• The Issuer account range is not participating on the Mastercard SecureCode Directory
Server.
• The Issuer sends a verify enrollment response with the value of an N (Cardholder not
enrolled).
• The Issuer ACS is Unavailable or times out.
Issuers may choose to have their ACS provider to send a VEres=Y for non-enrolled
cardholders, and then providing the PAres=A to avoid invoking the Mastercard Attempts
Processing Service.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 30
 3-D Secure Solution
3-D Secure Solution Message Types

The AAV generated by the attempts Server service will be generated with Mastercard keys
which will not be shared. An issuer can identify an AAV generated by the new Mastercard
Attempts Processing Service by the ACS identifier in the base64 decoded version of the AAV.

Attempts Server
With the implementation of the Mastercard Attempts Processing Service’s “Stand-In”
Authentication, Attempts AAVs will be generated in the following cases:
• ACS Services are not responding to Verify Enrollments.
• Issuer card ranges are not participating or enrolled in the Directory Server.
• A cardholder is not enrolled or participating in the issuer’s service.
Issuers that perform self-validation on the AAV at the time of authorization are not be able to
validate an Attempts AAV generated by the Mastercard Attempts Processing Service since the
key which generates this value by Mastercard will not be provided or shared.

3-D Secure Solution Message Types

The card range request/response, the verification request/response, the payer authentication
request/response, and the payer authentication transaction request/response are all message
types associated with the 3-D Secure Solution process.

Card Range Request/Response

Card Range Request/Response, also known as card range caching, is no longer a viable
implementation. The Mastercard Attempts Processing Service generates a Stand-In
Authentication for cardholders not enrolled, card ranges not participating, and Access Control
Server (ACS) services not responding. This Attempts Accountholder Authentication Value
(AAV) is only provided upon Merchant Plug-In (MPI) communication to the Directory Server for
each transaction. This ensures proper processing by all parties.

Verification Request/Response
Message Pair: VEReq/VERes– The first step in the payer authentication process is to validate
issuer and cardholder participation in the 3-D Secure. As designed by the protocol for the
safety and security of the authentication, the Mastercard Directory Server validates and routes
the VEReq/VERes between Merchant Plug-In (MPI) and Access Control Server (ACS) providers.
Therefore, the verification request process sent by the merchant is a two-step method
resulting in two verification requests (VEReqs).
1. A VEReq is sent from the MPI to the Directory Server to check card range enrollment and
routing to the appropriate authenticating ACS.
2. A second VEReq is sent from the Directory Server to the appropriate ACS for cardholder
enrollment verification and response back through the Directory Server.
All merchants will need to call the directory server for every Mastercard SecureCode
transaction to receive an Attempts Accountholder Authentication Value (AAV) or an AAV from

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 31
 3-D Secure Solution
Cardholder Enrollment

the issuer’s ACS provider. Upon implementation of the Attempts Service, MPI services will only
see VERes message values of Y. The VERes will route the MPI service via the cardholder’s
browser to either the cardholder’s ACS Service or the Mastercard Attempts Processing Service
for Stand-In authentication.

Payer Authentication Request/Response

Message Pair: PAReq/PARes—After determining 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 initiate the actual authentication. At this point in the
process, cardholders will be presented with an authentication window and asked to enter
their SecureCode or one-time password (OTP).
The Access Control Server (ACS) will perform authentication and, if successful, generate an
Accountholder Authentication Value (AAV). It is returned to the merchant within the PARes
message. For successfully authenticated transactions and Attempts, this AAV must be sent by
the merchant to the acquirer and forwarded to the issuer as part of the authorization request.
ACS providers should provide AAV values for all attempts (PARes = A) when the cardholder is
not enrolled or declines activation in addition to the fully authenticated (PARes = Y)
transaction status.

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 Access Control Server (ACS) to the Mastercard
Authentication History Server. All ACS service providers must support the PATransReq/
PATransRes messages for the History Server.
The Mastercard® SecureCode™ global infrastructure supports the History Server. All ACS
providers must support these messages.

Cardholder Enrollment
Enrolling cardholders in the Mastercard Location Alerts is the sole responsibility of the issuer.
This section outlines the enrollment requirements and process.

Cardholder Enrollment Process

The following section outlines the cardholder enrollment process for Mastercard®
SecureCode™ when an opt-in service such as static password is used.
This will be impacted by the decision on which authentication has been taken, and if risk-
based authentication has been implemented. Cardholder enrollment is not required for some
of these dynamic/risk-based methods of authentication.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 32
 3-D Secure Solution
Cardholder Authentication

There are two primary types of interactions between a cardholder and the issuer software:
• Enrollment—if static password
• Purchase Transactions—when risk-based authentication does not occur and the cardholder
needs to be challenged
Supplemental functionality is available based on Access Control Server (ACS) service provider
functionality:
• Account Management—to view historical activity or other account profile information
• Reregistration—if static password is used or mobile phone collection is necessary for SMS
• Frequently Asked Questions (FAQs)
• Contact Details
To shop with the assurance of 3-D Secure, a cardholder must enroll in the program through
the issuer. The enrollment process verifies the cardholder’s identity and allows the cardholder
to establish a SecureCode for authentication while shopping online. Enrollment of cardholders
can be a weak implementation with static passwords after answering basic enrollment
questions or a stronger authentication approach where the issuer pre-enrolls cardholders with
a static value or implements a one-time password (OTP) service. These options can be
discussed and reviewed with ACS Service Providers.

Cardholder Authentication
Following is information about the cardholder authentication process.

Sample Cardholder Authentication Process

The sample flow that follows assumes that the cardholder has already enrolled in the issuer’s
Mastercard® SecureCode™ program and obtained a SecureCode to use while shopping online
at participating merchants.
The figure below also assumes that all communication channels between the various
components are properly secured using the Secure Socket Layer (SSL) protocol.
Refer to the Components section for additional information.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 33
 3-D Secure Solution
Cardholder Authentication

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.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 34
 3-D Secure Solution
Cardholder Authentication

Link Description
SSL-3 The Directory Server determines routing of the enrollment request to send a second
VEReq from the directory to the Access Control Server for enrollment verification and
response to complete the cardholder authentication. 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 The Merchant Plug-In creates the Payer Authentication Request message and sends it to
the cardholder’s browser.
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.
SSL-7 The Access Control Server sends PATransRec to the Mastercard Authentication History
Server.

After cardholder authentication is complete, the merchant is required to pass the

corresponding Secure Payment Application™ (SPA) Accountholder Authentication Value (AAV)
to the acquirer via the Universal Cardholder Authentication Field™ (UCAF) within the
authorization message. This value is then passed from the acquirer to the issuer as part of the
authorization message.

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. Issuers will only be
able to validate an Attempt or fully authenticated AAV generated by their own ACS. If the

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 35
 3-D Secure Solution
Cardholder Authentication

Mastercard Attempts Processing Service generates an AAV, it cannot be issuer validated. The
Mastercard Attempts Processing Service uses a unique key that cannot be shared. For issuers
wanting to ensure that all AAVs are validated, Mastercard offers the Mastercard-hosted on-
behalf service. AAVs will also be generated by the Mastercard Attempts Processing Service for
Stand-In Authentication when cardholders are not enrolled, card ranges are not participating
in Mastercard SecureCode, or Access Control Server (ACS) services are not responding. This
Attemtpts AAV can only validate through the Mastercard AAV Validation Service rather than
through self-validation.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 36
 Mastercard SecureCode Cardholders

Chapter 3 Mastercard SecureCode Cardholders

This section provides an overview of the various activities and requirements for building and
maintaining the cardholder components that are required to support Mastercard® SecureCode™.

Cardholder Overview.................................................................................................................... 38
Cardholder Infrastructure.............................................................................................................. 38
Cardholder Customization............................................................................................................ 38
Cardholder Operational................................................................................................................ 38
Accountholder Authentication Value Processing............................................................................39
Cardholder Global Infrastructure Testing Requirements................................................................. 39

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 37
 Mastercard SecureCode Cardholders
Cardholder Overview

Cardholder Overview
This section outlines the major activities and requirements for building and maintaining the
cardholder components that are required to support Mastercard® SecureCode™.
The activities and requirements are separated into five primary categories:
• Infrastructure—Installation of new hardware and software components.
• Customization—Customizing or configuring vendor products.
• Operational—Operating the components in a production environment, including any
process oriented changes that may be required.
• Accountholder Authentication Value (AAV) Processing—Handling and processing of the
AAV.
• Global Infrastructure Testing Requirements—Testing of Mastercard SecureCode platform
components with the Mastercard SecureCode global infrastructure.

Cardholder Infrastructure
Following is the cardholder infrastructure requirement for the installation of new hardware
and software components that support Mastercard® SecureCode™.

Availability of Secure Browser

Mastercard recommends that cardholders have a web browser that is capable of supporting
128-bit Secure Sockets Layer (SSL) encryption.

Cardholder Customization
There are no customization issues related to cardholder participation in the Mastercard®
SecureCode™ program.

Cardholder Operational
Following are the cardholder requirements for operating the components in a production
environment, including any process-oriented changes that may be required.

Cardholder Registration
Depending on the exact nature of a card issuer’s program, cardholders may be asked to
register with their issuer to participate in its Mastercard® SecureCode™ program. Issuers have
the option of allowing cardholders to enroll in the program while shopping at a participating
merchant or outside of this process all together. The exact method of registration will be both
issuer and issuer platform specific.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 38
 Mastercard SecureCode Cardholders
Accountholder Authentication Value Processing

For accounts with more than one authorized user, both users should be able to register and
create their own unique SecureCode. After one of the authorized card users has registered, all
online payments using that card—at participating merchants—will cause the cardholder
authentication process to initiate. This process will initiate even if the buyer is not the
cardholder that explicitly enrolled in the program.

Use of Pop-Up Blocking Software

Early merchant implementations of Mastercard SecureCode used pop-up authentication
windows. Pop-up blocking software used by cardholders inhibited these types of
authentication windows from working properly. Mastercard requires that all merchant
implementations use inline authentication windows because they are not impacted by the use
of pop-up blocking software.

NOTE: Pop-up blocking software prevents most types of advertisement windows from being
created or “popping up” while a user browses websites.

Accountholder Authentication Value Processing

There are no issues related to processing of the Secure Payment Application™ (SPA)
Accountholder Authentication Value (AAV) for cardholders.

Cardholder Global Infrastructure Testing Requirements

There are no testing requirements for cardholders.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 39
 Customer Interface Requirements

Chapter 4 Customer Interface Requirements

This section helps customer personnel understand the Mastercard® SecureCode™ program
requirements associated with issuer purchase authentication and enrollment pages, and details
cardholder enrollment options.

Purchase Authentication Page.......................................................................................................41

Activation During Shopping Enrollment.........................................................................................41

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 40
 Customer Interface Requirements
Purchase Authentication Page

Purchase Authentication Page

This section describes the function and requirements of the Purchase Authentication page.

General Program Requirements

A purchase authentication page is presented to authenticate cardholders when completing an
online purchase at a participating Mastercard® SecureCode™ merchant.
The following requirements must be implemented on all purchase authentication pages by
Mastercard SecureCode merchants.
1. The payer authentication page must be a minimum of 400 pixels high x 400 pixels wide.
– Mastercard requires that all merchants implement the payer authentication page as an
inline window. Pop-up windows are not permitted for new merchant implementations.
2. The minimum acceptable pixel size, both for the SecureCode Program Identifier and the
issuer logo, is 62w x 34h. It is recommended that the issuer logo be at least as large as the
SecureCode Program Identifier. The issuer logo may be larger than the SecureCode
Program Identifier, however the total area designated for use by both logos must never
exceed one-sixth of the total page area.

Activation During Shopping Enrollment

Activation During Shopping (ADS) is a proactive approach to cardholder enrollment when
static password authentication is selected. When using stonger authentication methods such
as one-time passwords (OTPs), activation during shopping is not used. In addition, risk-based
authentication methods limit cardholder interruptions and reduce cardholder abandonments.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 41
 Customer Interface Requirements
Activation During Shopping Enrollment

Unlike standard enrollment processes, which require that the cardholder take initiative to
enroll in the program, ADS permits the issuer to solicit cardholder enrollment as part of the
shopping experience. This approach also provides issuers with a means for requiring
cardholder participation.
Cardholder response rates to ADS have been higher than those associated with standard
enrollment, when issuers have sufficiently communicated Mastercard® SecureCode™ program
details and benefits to their cardholder base. While effective in driving program enrollment,
issuers must take care to minimize any disruption to purchase completion and avoid negative
impact to participating merchants.
In recognition of this, Mastercard has outlined the requirements in this document with three
goals in mind:
• Maximize cardholder registrations. ADS has proven to be very effective when deployed
correctly. Several issuers have attained very high rates of registration with ADS.
• Minimize loss of volume. If not orchestrated correctly, ADS could cause some cardholder
dissatisfaction. This may result in loss of purchase volume for the issuer.
• Minimize lost merchant sales. If merchants perceive that consumers are spending
excessive time during the checkout process, they are likely to have concerns about the
Mastercard SecureCode program.
Early use of ADS caused some concern within the merchant community regarding the
potential for disruption of the sales process in some issuer deployments. Such concerns
included the consumer abnormally terminating the registration, thereby causing abandonment
of the entire purchase transaction.
Problems that occurred can be traced to a handful of causes that can be easily avoided:
• Lack of consumer education
• Lack of proper financial institution and program identifiers. Registration windows
must clearly identify the consumer’s financial institution to avoid confusion and fear of
spoofing or “phishing” scams.
• Overly long registration process. Once presented, the registration should be short and
straightforward. The use of too many questions to establish the identity of cardholders will
only tax their patience and cause them to abandon the process.
Each issuer is responsible for evaluating the pros and cons of ADS enrollment in general, as
well as the individual methods for initiating ADS, to determine which course of action is most
appropriate for its program.
However, the requirements and guidelines outlined below are based on issuer experiences as
well as on extensive focus groups and usability studies, so issuers may want to leverage these
learnings for their own Mastercard SecureCode deployments.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 42
 SecureCodeAcquirers

Chapter 5 SecureCodeAcquirers
This section provides an overview of the activities and requirements for building and maintaining
the acquirer components that are required to support Mastercard® SecureCode™.

Acquirer Overview........................................................................................................................ 44
Acquirer Infrastructure..............................................................................................................44
Establishment of SecureCode Operating Environment.......................................................... 44
Digital Signature Key Management...................................................................................... 45
Authorization System Message Enhancements.....................................................................45
Maestro Considerations....................................................................................................... 45
Acquirer Customization................................................................................................................ 47
Authentication Window Contents............................................................................................ 47
Mastercard SecureCode Program Identifier Usage Guidelines....................................................47
Acquirer Operational.....................................................................................................................48
Mastercard SecureCode Directory Server Maintenance..............................................................48
SSL and Digital Signing Certificates...........................................................................................48
Mastercard SecureCode 360 Webinar Series............................................................................. 48
Mastercard SecureCode Merchant Information......................................................................... 49
Mastercard SecureCode Merchant Process and Liability Shift Matrix.......................................... 49

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 43
 SecureCodeAcquirers
Acquirer Overview

Acquirer Overview
The activities and requirements for acquirers are separated into the following categories.
• Infrastructure—Installation of new hardware and software components. Internal or
outsourced provision of system support.
• Customization—Customizing or configuring vendor products.
• Operational—Operating the components in a production environment, including any
process oriented changes that may be required.
• Accountholder Authentication Value (AAV) Processing—Handling and processing of the
AAV.
• SecureCode 360—A Web presentation series available to merchants and acquirers with
information on implementation and benefits of the use of Mastercard SecureCode.
• Mastercard SecureCode—Merchant Implementation Guide—Detailed information specific
to merchants.

Acquirer Infrastructure
Following are the requirements related to the installation of new hardware and software
components. If the acquirer has contracted with a Merchant Plug-In (MPI) provider, then the
MPI provider will manage this.

Establishment of SecureCode Operating Environment

Following is information about establishing the Mastercard® SecureCode™ operating
environment for acquirers.
Acquirers who choose to support Mastercard SecureCode on their own systems by deploying
an Merchant Plug-In (MPI) must ensure compliance with the latest Mastercard specifications
for authorization and clearing for all Mastercard and Maestro® products.
Acquirers can opt to not directly support the MPI and not have any infrastructure impact
directly related to Mastercard SecureCode. However, if an acquirer chooses to deploy an MPI,
then the acquirer must source, deploy, and test this key infrastructure element. Acquirers that
want to support an MPI should refer to the Mastercard SecureCode—Merchant
Implementation Guide. For specific questions, contact Mastercard by sending an email
message to [email protected].

Secure Operating Facility

Acquirers may establish a secure operational facility for deployment of a server-based MPI for
merchant use in order to offer an integrated solution to their merchants. All facilities must
adhere to Mastercard security requirements regarding operations of cardholder authentication
processing platforms.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 44
 SecureCodeAcquirers
Acquirer Overview

Digital Signature Key Management

Acquirers must securely create and manage the keys to be used for performing digital signing
of Merchant Plug-In (MPI) requests.
MPI hosting providers and processors must have the ability to utilize a separate digital
signature key and associated Mastercard hierarchy certificate for each merchant.
MPI hosting providers and processors must have the ability to use a separate secret key for
each individual merchant.

Authorization System Message Enhancements

Acquirers must adhere to Universal Cardholder Authentication Field™ (UCAF) compliance
requirements as outlined in this document.
Among other things, this includes support for the UCAF and Security Level Indicator in DE 48,
subelement 42 and subelement 43. Acquirers will need to ensure that they have completed
validation of their authorization systems for both UCAF and Account Authentication Value
(AAV) through Mastercard, and should contact Customer Implementation Services to confirm
this certification has occurred.

Maestro Considerations
The following requirements and activities are specific to support of Maestro® cards as part of
the Mastercard® SecureCode™ program.

Mandatory Requirements for Maestro Acceptance

Acquirers must ensure that any merchant that wants to accept Maestro must support
Mastercard SecureCode on every transaction.

Account Number Length Requirements

Mastercard requires that issuers provide Maestro cardholders who want to participate in e-
commerce an account number that is 13–19 digits in length and merchants that choose to
accept Maestro must be able to support this variable PAN length.

Static Account Number Requirements

To facilitate both higher levels of customer service and provide increased security, Maestro
requires that all Internet transactions be performed using a static account number. This
number may differ from the actual account number but remains the same for all of the
cardholder’s Internet purchases.
Static account numbers assist merchants with their fraud management and marketing
requirements when the PAN is linked to a shopper’s activity. Merchants using static account
numbers must ensure that they (the merchants) remain PCI-DSS compliant.

Track 2 Requirements
If the issuer’s authorization system requires track 2 data, the issuer will need to implement a
platform that can intercept the message prior to authorization and create real track 2 data.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 45
 SecureCodeAcquirers
Acquirer Overview

Technology vendors, which implement surrogate account number solutions, are good
candidates for these platforms. Currently, Maestro authorization networks will add pseudo
Track 2 data in the following format.

No Field Name Length Value

1 PAN n...19 PAN as supplied in authorization message.

Currently, issuers are required to issue 16 digit
account numbers for Maestro Internet use.
However, acquirers are requested to implement
this functionality based on an account number of
12–19 digits in length.

2 Separator ans-1 D

3 Expiry Date ans-4 Expiry Date (YYMM) as supplied in authorization

message.

4 Service Code ans-3 101

For more information, see the appropriate authorization specification manual.

Authorization Platform Support

Maestro is supported on the Single Message System in regions outside of the Europe region.
Issuers are required to reference the appropriate authorization specification manual for
messaging details.

Single Message System Support

Maestro is supported on the Single Message System in regions outside of the Europe region.
Acquirers are required to reference the appropriate authorization specification manual for
messaging details.

Account in Good Standing

Maestro requires that all issuers provide support for Account in Good Standing transactions.
For more information, refer to the Maestro Considerations section.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 46
 SecureCodeAcquirers
Acquirer Customization

Acquirer Customization
The following is Mastercard® SecureCode™ customization information for acquirers.

Authentication Window Contents

The 3-D Secure protocol is designed so that creation of the cardholder authentication window
is performed by the merchant.
The issuer controls the actual content of the window. All cardholder authentication pages
must adhere to published Mastercard requirements on this topic. For more information, see
the Mastercard SecureCode—Issuer Implementation Guide. Proof of adherence to the
Mastercard requirements is a condition of successful completion of Mastercard® SecureCode™
issuer functional testing.
Acquirers should be aware that while they are not responsible for the content of the iFrame
deployed by the issuer, Mastercard has a rigorous testing process in place to ensure a
successful cardholder experience.

Mastercard SecureCode Program Identifier Usage Guidelines

Issuers and acquirers must adhere to the applicable usage guidelines.
Acquirers should advise their merchants that the merchant must adhere to the applicable
usage guidelines, as well.
Merchants are required to adhere to the applicable usage guidelines.
These guidelines are indicated in the Mastercard SecureCode Program Identifier Guidelines
accessed using the following web address:
www.mastercard.com/us/merchant/security/what_can_do/pdf/SecureCode_logo_usage.pdf
Proof of adherence to these guidelines must be provided to Mastercard as a condition of
successful completion of Mastercard® SecureCode™ merchant or service provider functional
testing.
Proof of adherence to these guidelines must be provided to Mastercard as a condition of
successful completion of Mastercard SecureCode issuer functional testing.
Mastercard highly recommends that all screenshots be provided for review as soon as possible
in case changes are required.
A copy of the Mastercard SecureCode logo artwork is available for download at https://
brand.mastercard.com/brandcenter/other-marks.html.
A copy of the Mastercard SecureCode logo artwork, as well as any updates to the program
identifier usage guidelines, is available for download at www.mastercardbrandcenter.com/us/
getourbrand/index.shtml.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 47
 SecureCodeAcquirers
Acquirer Operational

Acquirer Operational
Following are details about the operational aspects of acquirers implementing Mastercard®
SecureCode™.

Mastercard SecureCode Directory Server Maintenance

The following responsibilities apply for issuers and acquirers for directory server maintenance.
Issuers are responsible for ensuring that Mastercard has the appropriate card range
information and Access Control Server (ACS) web address for initialization of the Mastercard
Directory server. When an issuer releases bank identification number (BIN) ownership, it is their
responsibility to ensure the BIN is no longer enrolled with the Directory Server.
Acquirers are responsible for loading merchant IDs to the Mastercard® SecureCode™ Global
Directory with the correct acquirer bank identification number (BIN) information. When
acquirers release a BIN ownership, it is their responsibility to ensure the BIN is no longer
enrolled with the Directory Server and merchant IDs have updated new acquirer BIN
information.
Mastercard will accept updates only from an authorized contact, as indicated on the program
enrollment forms. All updates must be made using the approved submission form, available
from [email protected].
For more information about directory updates and maintenance schedules, refer to the
Mastercard SecureCode—Production Procedures document.

SSL and Digital Signing Certificates

Acquirers are responsible for requesting, installing or supplying to merchants or service
providers, and maintaining all necessary Secure Socket Layer (SSL) server and digital signing
certificates for use by the Access Control Server (ACS) platform. Certificates are needed for
communicating with the Directory Server and separately for communicating with the
Mastercard Authentication History Server.
All Mastercard hierarchy certificates must be obtained from Mastercard. See the Mastercard
SecureCode—Production Procedures manual for more information.

Mastercard SecureCode 360 Webinar Series

Mastercard provides a series of web-based presentations that are presented by Mastercard
staff and external companies that cover a range of Mastercard® SecureCode™ topics.
These web presentations are provided free of charge and only require an email address to
register and view the content.
Visit https://globalrisk.mastercard.com/securecode-360/ to see available presentations and to
access the service.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 48
 SecureCodeAcquirers
Acquirer Operational

Mastercard SecureCode Merchant Information

Mastercard has a merchant site containing detailed information on Mastercard® SecureCode™.
Merchants can access information related to Mastercard SecureCode (for example,
implementation guides) via the following URL:
• http://www.mastercard.us/merchants/securecode.html

Mastercard SecureCode Merchant Process and Liability Shift Matrix

The following table illustrates merchant behavior during various potential scenarios associated
with Mastercard® SecureCode™ authentication request processing.

Mastercard SecureCode Processing Matrix

To access the Mastercard SecureCode Processing Matrix in a Microsoft® Excel® format that can
be copied and used as needed, click here. This file can be saved to a local drive for later use.

CIS DE 48 (Additional Data—Private Use) Components

These indicators, as listed in the table above, map to Mastercard Authorization specification
requirements for acquirers and issuers. DE 48, subelement 42 (Electronic Commerce
Indicators), subfield 1 (Electronic Commerce Security Level Indicator and UCAF Collection
Indicator) contains the Security Level Indicator and DE 48, subelement 43 (Universal
Cardholder Authentication Field [UCAF]) contains the UCAF Data (AAV). Merchants must refer
to the appropriate acquirer or payment processor message specifications for specific
formatting requirements.

Merchant Risk-Based Approach

A merchant is not required to undertake Mastercard SecureCode on every transaction except
when accepting Maestro®, as this is a requirement of the program. Any merchant that
chooses not to use Mastercard SecureCode on any transaction should process on the basis of
the last entry in the table above labeled “Merchant Not SecureCode-enabled OR SecureCode
Not Used for Transaction” (SLI = 210).

Failed Authentication
A merchant may proceed with a transaction for which the authentication failed, but it must
be as a SecureCode not used for transaction (SLI = 210). This transaction must not be
submitted as merchant only and is not eligible for any liability shift. No AAV will be provided,
and issuers are likely to decline the transaction if submitted.

Liability Shift
For more information, refer to the Chargeback Guide.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 49
 SecureCodeAcquirers
Acquirer Operational

Errors
Error responses are sent in lieu of the VERes. Error responses will have similar messages as iReq
Reason code for the following activities.
If an error is received in response to a VEReq, then the transaction must be submitted as non-
Mastercard Identity Check/SecureCode and will not carry liability shift.
• Directoy Server Cache Request (CRReq) - Error 2 - message element not defined message -
Mastercard does not support CRReq message
• Acquirer BIN / Merchant ID not enrolled - Error 50 - Acquirer not participating or Error 51 -
Merchant not participating
• Invalid PAN - not a Mastercard valid credit / debit / prepaid card - Error 2 - Not a Mastercard
supported card range
• If an error is found with the submission of the VEReq due to formatting or syntax, then the
authentication must be resubmitted or the transaction proceed as non-Mastercard Identity
Check/SecureCode

Notes
The following numbered items correspond with the numbers provided in the “Notes” column
in the table above.
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. If merchant decides to
send for authorization, the transaction is not eligible for the liability shift and should be
submitted as non-Mastercard Identity Check/SecureCode
2. The AAV associated with an attempt must be included in any subsequent authorization
message.
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.
4. The PAN failed a Mod-10 check or the Mastercard Attempts service is unavailable.
5. Merchant Risk Based Approach - A merchant is not required to undertake Mastercard
Identity Check/SecureCode on every transaction except when accepting Maestro, as a
requirement for debit acceptance. Any merchant who chooses not to use Mastercard
Identity Check/SecureCode on any transaction should process on the basis of the last entry
in the matrix above entitled Merchant Does not support Mastercard Identity Check/
SecureCode not used for transaction (SLI = 210).
6. The Directory Server converts the status on the ACS Verify Enrollment Responses (VERes)
for N (card not enrolled) and U (unsupported device) to a Y and includes the URL for the
Mastercard attempts processing Server.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 50
 Issuer Authentication Options

Chapter 6 Issuer Authentication Options

This section introduces and describes the various authentication options available to issuers.
Acquirers and merchants may be interested to know that the standard option of a static password,
although present, is now being replaced by many different dynamic options improving cardholder
experience.

Issuer Authentication Options Background....................................................................................52

Static Password.............................................................................................................................52
Random Static.............................................................................................................................. 53
Short Message Service (SMS).........................................................................................................54
Mobile Application........................................................................................................................55
Chip and Pin................................................................................................................................. 56
Display Card................................................................................................................................. 56
Other Authentication Options....................................................................................................... 57

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 51
 Issuer Authentication Options
Issuer Authentication Options Background

Issuer Authentication Options Background

Perhaps the most important issuer decision in a Mastercard® SecureCode™ implementation is
how to authenticate the cardholder and, in case of a transaction dispute, provide evidence of
authentication.
The decision will differ depending on the issuer’s view and the attitude to risk. While issuers
must evaluate the risk/reward of these options, this section will focus on explaining some of
the available options.
Another consideration is whether a single authentication option fits with the issuer’s strategy.
The needs of an issuer’s cardholders differ depending on the market segmentation of the
issuer’s portfolio.
Access Control Server (ACS) providers and issuers should consider the impact to cardholders
and the security of authentication because weaker authentication solutions may result in fraud
within fully authenticated transactions. These fraudulent transactions then become the issuer’s
liability upon authentication and authorization. Best practices are to use strong authentication
of dynamic password programs (for example, one-time password [OTP]) with risk-based
decisions to challenge cardholders appropriately while minimizing continual authentication
challenges for low-risk transactions.
Additionally, the Mastercard Authentication History Server requires additional Mastercard
extensions to communicate the Purchase Authentication Approach and Challenge Type for
each transaction.

Static Password
Mastercard launched the Mastercard® SecureCode™ static password in 2002 as an entry-level
initial deployment that could be quick to market, not as a long-term strategy. Much of this
publication is still aimed at this proposition and, therefore, does not provide in-depth detail.
• Quick to market.
• Relies on a static password and usually on static data to identify the customer when they
enroll.
• Know your customer, Identification and Verification (ID&V), is important to ensure that
fraudsters can neither enroll in the service on behalf of a genuine cardholder, nor change
the password of an enrolled cardholder.
• Activation During Shopping (ADS) produces good enrollment results for an issuer, but
interrupts the shopping experience. It is important to follow the practices identified in this
publication, because if executed poorly, ADS can cause genuine cardholders to abandon
transactions. Additional information is available in the Mastercard SecureCode Issuer Best
Practices.
• Needs communication to cardholders to ensure that they are aware of the Mastercard
SecureCode process before they are requested to enroll, especially in the case of ADS.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 52
 Issuer Authentication Options
Random Static

Although static password was a common solution in the past, new deployments where
Mastercard SecureCode deployment is strong such as the Asia/Pacific, South Asia/ Middle East/
Africa and Europe regions, are moving to a dynamic solution.
To avoid the issues surrounding ID&V some issuers using static password have undertaken a
“PIN Mailing” whereby all existing cardholders receive a SecureCode through the mail with
full information on its use. Making SecureCode part of the card-opening procedures is also
gaining in popularity.

Random Static
Random static is a variant of a static password solution that some issuers have chosen to
deploy.
It is similar to that seen for some banks Internet banking solutions. Although the cardholder
still has a static password, they are never asked to complete the entire password when
prompted but rather a random selection of characters from the password. For example, first,
sixth, and ninth are depicted in the following figure.

This method is an improvement in security, but makes the cardholder experience more
challenging, especially if the issuer chooses to enforce password requirements such as
minimum 9, or must be alphanumeric.
The same issues stated above for Static Password are also seen and should be considered in
this deployment.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 53
 Issuer Authentication Options
Short Message Service (SMS)

Short Message Service (SMS)

The use of Short Message Service (SMS) has grown in popularity with the advantage that
almost any phone issued today can support SMS text messaging.
Banks use this method to send alerts to their customers, and it can now be used as an
authentication method for Mastercard® SecureCode™.
The generation of a dynamic one-time password (OTP) sent to the registered mobile device
can be undertaken in a number of ways. Issuers should discuss with their Access Control
Server (ACS) service provider. One way that Mastercard undertakes this is through the use of a
CAP (Chip and Pin) authentication server. This single server could be used for validation of
CAP, Mobile Application and Display card values, and the generation of SMS passwords. In
addition to re-using investments made in EMV, this method allows Chip issuers to examine a
solution that could support several authentication options.
The advantage to the cardholder is not having to remember a password because when the
card is used at an e-commerce merchant that supports Mastercard SecureCode, the dynamic
code can be sent to the registered mobile device. Issuers could also consider alerts from their
systems to the phone which advise the cardholder of the amount spent at any e-commerce
merchant—even if Mastercard SecureCode is not used.
The cardholder experience will be similar to that of a static password as depicted in the
following figure.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 54
 Issuer Authentication Options
Mobile Application

It is important to ensure that the mobile device used is trusted as owned by the cardholder,
and that a back-up mechanism is in place for instances when a cardholder is unable to obtain
a mobile signal.

Mobile Application
Smart phones are growing in issuance and in popularity. The number of mobile applications is
also growing rapidly. Mastercard has a growing number of mobile applications, some of which
—such as wallets—are not yet available globally.
One option that is available globally is the Advanced Authentication for Mobile application.
This application resides on the smart phone and allows a secure software application to have
the equivalent of the consumers chip card on the phone. This solution allows the cardholder
to have a similar experience that they would in a face-to-face chip transaction. The customer,
opens the application, enters their PIN, and obtains a generated, dynamic, one-time password
(OTP) to use as the SecureCode, which is then used in the usual box required by their issuer
for authenticating the cardholder.

The issuer can verify the password by using the same “black box” solution available for any
EMV-generated authentication.
Ensuring that the application is delivered to the cardholders mobile phone will be a key
consideration in this deployment.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 55
 Issuer Authentication Options
Chip and Pin

Chip and Pin

Perhaps the closest user experience to the face-to-face channel that a Chip and Pin (CAP)
cardholder can experience is through the use of a CAP device as depicted in the following
figure.

In this case, a cardholder would insert their card into the reader and follow the prompts on
the device to enter their PIN and generate their dynamic one-time password (OTP) to use as
their SecureCode.
Security can be increased by entering other information before entering the PIN, for example,
a dynamic challenge that the issuer could display when prompting for the SecureCode.
Balance needs to be maintained between the user experience and the chance for fraud. For
example, an issuer may decide that a simple PIN driven SecureCode would be sufficient for
amounts under a defined threshold with increased requirements for high-value items.
This may not be a practical solution for cardholders that shop from multiple devices and
locations. For those that shop either from home or work, this added security and simple
cardholder experience may be appealing.

Display Card
Mastercard has launched a new card design that integrates the CAP reader into the card in
two designs.
In the first design, the act of pushing a single button will generate a one time code in the
display. For increased security, there is a second option that works like the CAP reader in that
it requires the cardholder to first input their PIN.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 56
 Issuer Authentication Options
Other Authentication Options

These cards can be configured to also work with the CAP reader to provide both options for
generating the SecureCode.
The Display Card is still based on the EMV standard and the same “black box” solution that
would check the authentication from Mobile Authentication and CAP can be used to verify
the number generated by the display card.
These cards are available for all Mastercard cards including credit, debit, and Maestro®.

Other Authentication Options

Mastercard® SecureCode™ has the flexibility to accommodate many authentication options
that ensure both the integrity of the program and of the authentication.
Examples of other such authentication options include, but are not limited to, internet
banking solutions with key fobs, secure tokens, and software tokens.
Mastercard can investigate deployment availability for issuers that have an existing
authentication method. Non-standard deployments will require a thorough review by
Mastercard, and agreement must be reached on screen design, and other features and
options. Therefore, Mastercard should be involved early in any deployment discussion.
Send an email message for more information about additional options or an authentication
concept to [email protected].

Virtual Card Numbers

In reality, the problem faced by an issuer is that they are liable for transactions that occur at a
merchant that has deployed Mastercard SecureCode.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 57
 Issuer Authentication Options
Other Authentication Options

Virtual Card Numbers can be a strong issuer and cardholder solution if the numbers are
generated in a secure way.
Solutions, such as the inControl offering from Mastercard, can add further value through
features such as cardholder alerts, prohibitions from using the card at certain merchants/
MCCs, and maximum value of purchase. This can be used for any card but is particularly
popular for commercial cards.
Unfortunately a merchant can not distinguish if it is a real or a virtual card, or the level of
security that may have occurred. An issuer can have an ACS that is configured to work with
the inControl platform to provide the merchant with a valid fully authenticated transaction
avoiding any potential acceptance issues.
When the virtual card is used, this integration avoids the cardholder being prompted for an
additional SecureCode, and also delivers the fully authenticated response to the merchant in
silent mode as a transparent authentication. The added value is that this integration can also,
optionally, provide a failed authentication response to the merchant if the real card is used,
and an advice to the cardholder to use the virtual card system supplied to fulfill the
transaction.
For more information about inControl and SecureCode options, contact your Mastercard
representative.
In summary, virtual cards have the following characteristics:
• Strong issuer response securing transactions for all Internet purchases both current and
future. Benefits include:
– Real card number may or may not be used for Internet purchases
– Flexibility to be static, or a one-time generated virtual number
• Strong when integrated with Mastercard SecureCode by the issuer using inControl and
SecureCode Issuer ACS for “silent” authentication.
• Weak from a merchant perspective:
– Merchant cannot identify if the card is virtual
– No chance of full authentication, which could trip fraud merchant parameters

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 58
 Mastercard SecureCode Contact Information

Appendix A Mastercard SecureCode Contact Information

Mastercard SecureCode Contact Information

This section contains names, areas of responsibility, and contact information for Mastercard
personnel who can assist customers with e-commerce enrollment, testing, and implementation
issues.

Mastercard SecureCode Contact Information................................................................................ 60

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 59
 Mastercard SecureCode Contact Information
Mastercard SecureCode Contact Information

Mastercard SecureCode Contact Information

This section contains contact information for Mastercard personnel who can assist customers
with e-commerce enrollment, testing, and implementation issues.

Area of Responsibility Contact Information

Completed and signed enrollment forms Send all completed and signed enrollment forms
to:
[email protected]
®
Maestro Customer Operations Services
U.S., Canada, Caribbean, Latin America, and
Middle East/Africa regions
Phone: 800-999-0363 (Inside U.S.)
636-722-6176 (Outside U.S.)
636-722-6292 (Spanish Language Support)
Fax: 636-722-7192
Email:[email protected]
om
Europe region
Phone: +32-2-352-54-03
Email:[email protected]
Customer Implementation Services
Asia/Pacific region
Email:[email protected]
Middle East/Africa region
Email:[email protected]
Europe region
Email:[email protected]
Canada and U.S. regions
Email:[email protected]
Latin America and the Caribbean region
Email:[email protected]

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 60
 Mastercard SecureCode Contact Information
Mastercard SecureCode Contact Information

Area of Responsibility Contact Information

Program Management Support [email protected]

Pricing/Billing

Support [email protected]

Mastercard SecureCode Online Resources

For additional information about Mastercard® SecureCode™, visit one of the following
websites:
• Mastercard Security Resources
• Mastercard SecureCode 360 Webinars
• Consumer Website
• Mastercard SecureCode Vendor List
• Mastercard SecureCode Frequently Asked Questions
• Merchant Website
– Merchant Frequently Asked Questions
– Program Identifier Guidelines
Additional references are available on Mastercard Connect™ in English, Spanish, and
Portuguese under Library > Publications > SecureCode.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 61
 Maestro Processing Considerations

Appendix B Maestro Processing Considerations

Maestro Processing Considerations

This section contains detailed information about specific processing issues associated with Maestro®
and Mastercard® SecureCode™. Merchants should contact their acquirer for specific authorization
and clearing requirements.

Account in Good Standing............................................................................................................63

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 62
 Maestro Processing Considerations
Account in Good Standing

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 objective is to satisfy the merchant’s primary concern to 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 Value

DE 4 (Amount, Transaction) One unit of purchase currency
DE 61 (Point-of-Service [POS] Data), subfield 7 4 = Preauthorized Request
(POS Transaction Status)

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.
For Credit, there is the Account Status Inquiry, which is a non-financial request that allows
acquirers to validate aspects of the cardholder account. Some ACS providers will also use this
message to verify cardholder enrollment such as CVC, AVC, and expiry date. Additional details
can be found in the Customer Interface Specification manual.

Data Element Value

DE 3 (Processing Code) 00 = Purchase
DE 4 (Amount, Transaction) Must be zero
DE 48 (Additional Data—Private Use), subelement 52 = AVS and authorization Request 0100
82 (Address Verification Service Request)
DE 48 (Additional Data—Private Use), subelement CVC2 from signature panel if applicable
92 (CVC 2)
DE 61 (Point-of-Service [POS] Data), subfield 7 8 =Account Status Inquiry Service
(POS Transaction Status)

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 63
 Mastercard Advance Registration Program Requirements

Appendix C Mastercard Advance Registration Program

Requirements
Mastercard Advance Registration Program Requirements

This section defines the Mastercard Advance Registration Program (MARP) and identifies the
program requirements.

Maestro Advance Registration Program.........................................................................................65

MARP Merchant Use of Mastercard SecureCode........................................................................... 65
Issuer Participation in MARP..........................................................................................................66

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 64
 Mastercard Advance Registration Program Requirements
Maestro Advance Registration Program

Maestro Advance Registration Program

Global Clearing Management System supports e-commerce transactions processed under the
Maestro® Advance Registration Program (MARP). MARP was introduced in 2008.

NOTE: MARP will be decommissioned 1 June 2015. For more details, refer to Europe Region
Operations Bulletin No. 2, 3 February 2014.

MARP Merchant Use of Mastercard SecureCode

The Mastercard Advance Registration Program (MARP) enables enrolled merchants to
authenticate e-commerce transactions.

NOTE: No new merchants are allowed to enroll in MARP. Effective 30 April 2014, Mastercard
will be withdrawing MARP. For more details, refer to the Europe Region Operations Bulletin
No. 2, 3 February 2014.

• The merchant invites the customer to register on its website by choosing a username and
password, or similar credentials acceptable to Mastercard, and must provide the customer
with the option to register a Mastercard® or Maestro® card account number for use in
future e-commerce transactions.
• For the first Mastercard or Maestro e-commerce transaction, the merchant must request
Mastercard® SecureCode™ authentication before submitting the transaction for
authorization. If that transaction is subsequently authorized by the issuer, it is guaranteed
to the acquirer or its merchant, regardless of whether the issuer or cardholder participates
in Mastercard SecureCode as determined by the merchant request.
• If the first Mastercard or Maestro e-commerce transaction for the cardholder registered
with the merchant is authorized by the issuer, the merchant can skip the Mastercard
SecureCode authentication on subsequent transactions by the same customer using the
same Mastercard or Maestro card account. In that case, the merchant will populate:
– Data Element (DE) 48, (Additional Data Private Use, subelement 32 (Mastercard
Assigned ID) in the Authorization Request/0100 message with an ID assigned by
Mastercard.
– DE 48, subelement 43 (3-D Secure for Mastercard SecureCode) in the Authorization
Request/0100 message with a Mastercard-assigned static Account Authentication Value
(AAV).
– DE 48, subelement 42, position 3 (UCAF Collection Indicator) in the Authorization
Request/0100 message with a value of 3.
– Private data subelement 0052 (Electronic Commerce Security Level Indicator) subfield 3
(UCAF Collection Indicator) in the clearing record submitted to GCMS for processing
(where applicable) with a value of 3.
– The PDS 176 (Mastercard Assigned ID) in the clearing record submitted to GCMS for
processing with an ID assigned by Mastercard.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 65
 Mastercard Advance Registration Program Requirements
Issuer Participation in MARP

• If the merchant populates the Universal Cardholder Authentication Field™ (UCAF) with the
static AAV assigned by Mastercard, and populates the UCAF Collection Indicator with the
value of 3, and the issuer authorizes the transaction, the issuer will have a right to charge
back the transaction for reason of fraud.
• If a registered cardholder uses a different Mastercard or Maestro card account number for
a transaction, the merchant must request Mastercard SecureCode authentication before
submitting the transaction for authorization.
• Based on a risk assessment, the merchant always has the option of requesting Mastercard
SecureCode authentication for any Mastercard or Maestro transaction, in which case the
transaction will be governed by existing Mastercard SecureCode and Chargeback rules. For
instance, for consumer cards acquired in the Europe region, if the transaction is
subsequently authorized by the issuer, it is guaranteed to the acquirer or its merchant,
regardless of whether the issuer or cardholder participates in Mastercard SecureCode as
determined by the merchant request.

Issuer Participation in MARP

Any Maestro® issuer that supports e-commerce is required to support the static Accountholder
Authentication Value (AAV) in authorization until 1 June 2015, at which time Mastercard will
discontinue the Maestro Advance Registration Program (MARP). For more details, refer to
Europe Region Operations Bulletin No. 2, 3 February 2014.
Issuers must meet existing Europe region requirements to support Maestro e-commerce
transactions.
Requirements can be found in the Authorization Manual and, if applicable, the GCMS
Reference Manual available on the Publications page on Mastercard Connect™.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 66
 India IVR Transations (SecureTelephone)

Appendix D India IVR Transations (SecureTelephone)

India IVR Transations (SecureTelephone)

This section provides an overview of the Mastercard requirements to support IVR Transactions in
India.

Overview...................................................................................................................................... 68
Data Extensions to the Existing 3-D Secure Protocol...................................................................... 68
UCAF Transport in Mastercard Authorization Messages.................................................................68
Mastercard SecureCode—Security Level Indicator (DE 48, subelement 42)................................ 69
Universal Cardholder Authentication Field (DE 48, subelement 43)........................................... 70
What is an AAV?...................................................................................................................... 70
Sample IVR Transaction Flow.................................................................................................... 71
Mastercard SecureCode Compliance and Functional Testing..................................................... 71

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 67
 India IVR Transations (SecureTelephone)
Overview

Overview
Following the successful deployment of 3-D Secure (SecureCode) for all domestic electronic
commerce transactions, the banking authority of India, Reserve Bank of India (RBI), has
defined a mandate that requires a similar two-factor authentication process to also be rolled
out for IVR transactions.
As there was no technology or precedent of authenticating an IVR transaction with two-factor
authentication, Mastercard has worked with IVR vendors to utilize existing investments in
technology, process and infrastructure to build a framework and specification using the 3-D
Secure protocol. As owner of the 3-D Secure Protocol, Visa has published a country-specific
(India) specification that defines a number of additional data elements in the existing 3-D
Secure messages.
For more information, refer to the Visa document 3-D Secure Functional Requirements—
Extensions for Mobile and IVR Transactions in India v1.1.

Data Extensions to the Existing 3-D Secure Protocol

As detailed in the 3-D Secure Functional Requirements—Extensions for Mobile and IVR
Transactions in India v1.1, the Verify Enrollment Request (VEReq), Verify Enrollment Response
(VERes), and PAReq messaging within the 3-D Secure protocol have been extended to allow
the Merchant plug-in (MPI) and Issuer Access Control Server (ACS) to convey the additional
transaction related elements that identify an IVR transaction, as opposed to an electronic
commerce transaction.

UCAF Transport in Mastercard Authorization Messages

Mastercard has designated specific subelements within DE 61 (Point-of-Service [POS] Data)
and DE 48 (Additional Data–Private Use) for the identification of SecureTelephone Order and
transport of Universal Cardholder Authentication Field™ (UCAF)-related data and associated
indicators in authorization messages.
These subelements will be used to support and identify IVR transactions within the
authorization message. Support for SecureTelephone Order within the authorization message
was mandated as part of the 7.2 Banknet release.
The subelements are described in the following sections. Refer to the Customer Interface
Specification manual for additional information regarding authorization message formatting.
SecureTelephone—DE 61—Point-of-Service (POS) Data, subelements 4, 7, and 10. The
following subelement values are to correctly identify an IVR (SecureTelephone Order) DE 61.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 68
 India IVR Transations (SecureTelephone)
UCAF Transport in Mastercard Authorization Messages

Position Value Description

4—POS Cardholder 3 Cardholder Not Present, Phone/ARU Order

Presence

7—POS Transaction Status 2 SecureCode Phone Order

10—Cardholder-Activated MUST Authorized Level 6 CAT:Electronic Commerce

Terminal Level NOT BE
6

Mastercard SecureCode—Security Level Indicator (DE 48, subelement 42)

The SecureCode Security Level Indicator contains the fields representing the security protocol
and cardholder authentication type associated with the transaction.
Mastercard requires that DE 48 (Additional Data—Private Use), subelement 42 (Electronic
Commerce Indicators) be included and properly populated for all electronic commerce and
SecureTelephone (IVR) transaction authorizations.
Please note that only Fully authenticated IVR transactions (Security Level Indicator 2 [UCAF
data collection is supported by the merchant, and Universal Cardholder Authentication Field™
{UCAF} data is present in DE 48, subelement 43 [Universal Cardholder Authentication Field
{UCAF}]) are applicable to SecureTelephone order (IVR) transactions.
The required DE 48 (Additional Data—Private Use), subelement 42 (Electronic Commerce
Indicators), subfield 1 (Electronic Commerce Security Level Indicator and UCAF Collection
Indicator) values for SecureTelephone order (IVR) are provided in the table below.

Position Value Description

1—Security Protocol 2 Channel

2—Cardholder 1 Cardholder certificate not used

Authentication

3—UCAF Collection 0 UCAF data collection is not supported by the merchant

Indicator
1 UCAF data collection is supported by the merchant, and UCAF
data may be available (DE 48, subelement 43 may be present
for Mastercard SecureCode)

2 UCAF data collection is supported by the merchant, and UCAF

data must be present (DE 48, subelement 43)

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 69
 India IVR Transations (SecureTelephone)
UCAF Transport in Mastercard Authorization Messages

Universal Cardholder Authentication Field (DE 48, subelement 43)

The Universal Cardholder Authentication Field™ (UCAF) contains the encoded Mastercard®
SecureCode™ issuer-generated authentication data (collected by the merchant) resulting from
all Mastercard SecureCode fully authenticated transactions.
UCAF is a standard, globally interoperable method of collecting cardholder authentication
data at the point of interaction. Within the Mastercard authorization networks, UCAF is a
universal, multipurpose data transport infrastructure that is used to communicate
authentication information between cardholders, merchants, issuers, and acquirers. It is a
variable length (maximum 32 characters) field with a flexible data structure that can be
tailored to support the needs of issuer security and authentication approaches.

NOTE: All acquirers and issuers must ensure that they can send and/or receive contents in this
field up to the maximum length of 32. Note that applications utilizing this field, such as
Mastercard SecureCode, may provide contents that are less than the maximum length. For
Mastercard SecureCode specifically, this field will be 28 positions. This field should NOT
include any padding to meet the maximum length of 32 bytes.

What is an AAV?
The Accountholder Authentication Value (AAV) is a Mastercard® SecureCode™ specific token
that uses the Universal Cardholder Authentication Field™ (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. This AAV can be proof of a fully authenticated or an attempted authentication
transaction.
The AAV is 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. (This could be the Issuer ACS or, in the case of an
attempt, the Mastercard Attempt processing server.)
• Sequence number that can positively identify the transaction for that location
• Secret key used to create the Message Authentication Code (MAC), which is a
cryptographic method that ensures AAV data integrity, and binds 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.

MARP Exception
For merchants that have qualified to participate in the Mastercard Advance Registration
Program (MARP), Mastercard assigns a static AAV that conforms to the same format as an
issuer-generated AAV.

NOTE: MARP is closed to new business and will be decommissioned 1 June 2015. For more
details, refer to Europe Region Operations Bulletin No. 2, 3 February 2014.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 70
 India IVR Transations (SecureTelephone)
UCAF Transport in Mastercard Authorization Messages

Sample IVR Transaction Flow

An example of a SecureTelephone order (IVR) transaction is as follows.
1. Cardholder calls the merchant to order items, and finalize purchase.
2. Merchant collects all necessary data, including the cardholder’s primary account number
(PAN) and phone information.
3. The merchant’s modified IVR-MPI creates a Verify Enrollment Request (VEReq) message
with the IVR extensions, including the following data:
a. Format of Phone number or Device ID
b. Cardholder Phone number or Device ID
c. PAReq channel—DIRECT
d. Shopping Channel—IVR
e. Available Authentication Channels
4. The Mastercard Directory Server will forward the VEReq message to the appropriate Issuer
IVR-ACS, to validate that the PAN is enrolled in the service.
5. The issuer IVR-ACS responds to the Mastercard Directory with confirmation of enrollment
and the Verify Enrollment Response (VERes) message including the ACS web address is
returned to the Merchant IVR-MPI.
6. IVR-MPI generates a PAReq message with the IVR extension, and sends to the appropriate
Issuer IVR-ACS.
7. ACS receives and processes the PAReq message—IVR extensions may be used by the Issuer
ACS in the authentication process.
8. Upon successful validation of the cardholder (or using data contained in the extended
PAReq), the issuer ACS will generate the PARes message and forward to Merchant IVR-
MPI.
9. IVR-MPI receives PARes and proceeds with authorization request.

Mastercard SecureCode Compliance and Functional Testing

Mastercard has developed vendor compliance testing, as well as issuer and merchant
functional testing, to ensure vendor products and member and merchant implementations are
compliant and successfully interoperate with all Mastercard® SecureCode™ platforms and
infrastructure.
Proof of Visa Certification of IVR-ACS and IVR-MPI development is required before Mastercard
compliance testing can commence.
All vendors, merchant endpoints, and issuers are required to complete the designated testing
process prior to launch. More information regarding testing is available from
[email protected].

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 71
 Mastercard Extensions for the Brazil Market

Appendix E Mastercard Extensions for the Brazil Market

Mastercard Extensions for the Brazil Market

This section provides specifications related to extensions that support Brazil domestic processing.
These extensions allow passing of data from the merchant to the issuer in 3-D Secure messages.

Brazil Market Extensions............................................................................................................... 73

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 72
 Mastercard Extensions for the Brazil Market
Brazil Market Extensions

Brazil Market Extensions

This section provides specifications related to extensions that support Brazil domestic
processing. These extensions allow passing of data from the merchant to the issuer in 3-D
Secure messages.
These extensions will be used in both the VEReq and PAReq messages.
• Card Account Type
• Mobile Phone Number
• Merchant Category Code
• Transaction Type
The VEReq and PAReq are extended to allow the Merchant Plug In (MPI) to pass the additional
transaction-related elements to the Access Control Server (ACS) specified below.

Field Definitions for Brazil Market Extensions in VEReq and PAReq

Element Name Description Format and Values

Extension Id visa.3ds.brazil_market

brazilmcc Merchant Category Length 1–4, Numeric digits

Code,provided by the
merchant

brazilaccounttype Account Type as selected Length1–2, Numeric digits

by the cardholder during
• 00 (NOT APPLICABLE)
checkout.
• 01 (CREDIT)
• 02 (DEBIT)

brazilmobilenumber Mobile number (as entered Length 1–25, Numeric digits

by the cardholder during
checkout)

braziltransactiontype Transaction Type, provided Length 1–2; Numeric Digit

by the merchant
• 00 (Goods/Service Purchase)
• 03 (Check Acceptance)
• 10 (Account Funding)
• 11 (Quasi-Cash Transaction)
• 28 (Prepaid Activation & Load)

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 73
 Mastercard Extensions for the Brazil Market
Brazil Market Extensions

NOTE: The critical attribute must be set to “false” for all Extension fields defined in this
protocol extension specification.

Message Sample of Brazil Market Extensions in VEReq

Message Sample of Brazil Market Extensions in PAReq

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 74
 Notices

Notices
Following are policies pertaining to proprietary rights, trademarks, translations, and details
about the availability of additional information online.

Proprietary Rights

The information contained in this document is proprietary and confidential to Mastercard International
Incorporated, one or more of its affiliated entities (collectively “Mastercard”), or both.
This material may not be duplicated, published, or disclosed, in whole or in part, without the prior written
permission of Mastercard.

Trademarks

Trademark notices and symbols used in this document reflect the registration status of Mastercard
trademarks in the United States. Please consult with the Global Customer Service 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.

Disclaimer

Mastercard makes no representations or warranties of any kind, express or implied, with respect to the
contents of this document. Without limitation, Mastercard specifically disclaims all representations and
warranties with respect to this document and any intellectual property rights subsisting therein or any part
thereof, including but not limited to any and all implied warranties of title, non-infringement, or suitability
for any purpose (whether or not Mastercard has been advised, has reason to know, or is otherwise in fact
aware of any information) or achievement of any particular result. Without limitation, Mastercard specifically
disclaims all representations and warranties that any practice or implementation of this document will not
infringe any third party patents, copyrights, trade secrets or other rights.

Translation

A translation of any Mastercard manual, bulletin, release, or other Mastercard document into a language
other than English is intended solely as a convenience to Mastercard customers. Mastercard provides any
translated document to its customers “AS IS” and makes no representations or warranties of any kind with
respect to the translated document, including, but not limited to, its accuracy or reliability. In no event shall
Mastercard be liable for any damages resulting from reliance on any translated document. The English
version of any Mastercard document will take precedence over any translated version in any legal
proceeding.

Information Available Online

Mastercard provides details about the standards used for this document—including times expressed,
language use, and contact information—on the Publications Support page available on Mastercard
Connect™. Go to Publications Support for centralized information.

©2012–2016 Mastercard. Proprietary. All rights reserved.

Mastercard SecureCode—Acquirer Implementation Guide • 21 March 2017 75