EMVCO 3-D SECURE 2.0

page 3page 3

EXECUTIVE SUMMARY

The boost of e-commerce has offered consumers convenient services and payment methods that have led to a significant increase in

the number of Card-Not-Present (CNP) transactions. In CNP transactions there is no longer a direct interaction between merchants

and customers. As a result, fraudulent activities in the CNP domain have grown almost at the same pace as the increase of CNP

transactions.

The industry's response to this challenge was the 3 Domain Secure Standards (commonly referred to as 3DS). The first version of

3DS was a set of security specifications developed by Visa with the aim of being the standard for securing CNP transactions. Other

schemes have used 3DS Standards to build and implement their own flavors of specifications.

The primary objective of 3DS is to reduce frauds in CNP environments, safeguarding the security of e-commerce transactions. This

results in saving time and money for customers, merchants, acquirers, and issuers. However, the first version of 3DS (3DS 1.0) faced

challenges on both the technical and commercial sides. The evolution towards mobile commerce was also a challenge for 3DS 1.0.

As the importance of mobile devices and mobile commerce increased, 3DS 1.0 started to become obsolete.

To increase the market acceptance of 3DS, solve some technical and business challenges, and to make this protocol suitable for the

latest trends in e- and mobile commerce, 3DS 1.0 was revised. In October 2016, a new version of 3DS was released under version

number 2.0 (3DS 2.0) which is now governed centrally by EMVCo.

This technical white paper takes a closer look at 3DS 2.0, beginning with a short overview of the background and the reasons that

led to the introduction of 3DS. Next, an analysis of the challenges that 3DS 1.0 has faced is presented, discussing how 3DS 2.0

intends to deal them. Then, 3DS 2.0 is analyzed in detail including a comparison to 3DS 1.0, and describing how 3DS 2.0 operates on

a technical level.

page 3

INTRODUCTION

The boost of e-commerce has offered

consumers convenient services and

payment methods that have led to a

significant increase in the number of

Card-Not-Present (CNP) transactions.

CNP transactions are beneficial for both

merchants and customers. Merchants

can make their product easily available

for the customer without leaving their

location, while customers can use

convenient method(s) of shopping

in their place of comfort. In CNP

transactions there is no longer a direct

interaction between merchants and

customers. The customer usually needs

to enter visible card information on

the merchant’s website and merchants

cannot see or check who is in fact

paying. This introduces the challenge

of assuring proper payment instrument

ownership. As a result, fraudulent

activities in the CNP domain have

grown almost at the same pace as the

increase of CNP transactions.

The industry's response to this

challenge was the 3 Domain Secure

Standards (commonly referred to as

3DS). The first version of 3DS was a set

of security specifications developed by

Visa with the aim of being the standard

for securing CNP transactions. Other

schemes have used 3DS Standards to

build and implement their own flavors

of specifications. All 3DS methods can

be recognized by their brand names

such as Verified by Visa™, Mastercard

SecureCode™, American Express

SafeKey™ and JCB J/Secure™.

The primary objective of 3DS is to

reduce frauds in CNP environments,

safeguarding the security of

e-commerce transactions. This results in

saving time and money for customers,

merchants, acquirers, and issuers.

However, the first version of 3DS (3DS

1.0) faced challenges on both the

technical and commercial sides. 3DS

adds an extra authentication step to

the checkout process, which led to

customers’ confusion and annoyance.

This caused significant reduction of

conversion rates in many regions and

as a result, limited adoption of 3DS by

merchants.

On top of this, the evolution towards

mobile commerce was also a challenge

for 3DS 1.0. The mobile application

domain is extremely competitive in

terms of user interface and ease of use.

However, in-app payment modalities

are not covered by 3DS 1.0. As the

importance of mobile devices and

mobile commerce increased, 3DS 1.0

started to become obsolete.

To increase the market acceptance of

3DS, solve some technical and business

challenges, and make this protocol

suitable for the latest trends in e- and

mobile commerce, 3DS 1.0 was revised.

In October 2016, a new version of 3DS

page 4

EMVCO 3-D SECURE 2.0

DID YOU KNOW?

3DS 1.0 was not the first attempt to

solve the authentication challenge in

CNP transactions. The first attempt

was SET (Secure Electronic Transaction)

consortium. It was established in 1996 by

Visa and Mastercard in cooperation with

GTE, IBM, Microsoft, Netscape and others.

However, it failed to get traction and was

then replaced by 3DS 1.0.

page 5

was released under version number

2.0 (3DS 2.0) which is now governed

centrally by EMVCo.

This technical white paper takes a closer

look at 3DS 2.0, beginning with a short

overview of the background and the

reasons that led to the introduction of

3DS. Next, an analysis of the challenges

that 3DS 1.0 has faced is presented,

discussing how 3DS 2.0 intends to deal

them. Then, 3DS 2.0 is analyzed in detail

including a comparison to 3DS 1.0, and

describing how 3DS 2.0 operates on a

technical level.

AUTHENTICATION CHALLENGES IN CARD-NOT-PRESENT DOMAIN

Card-Not-Present transactions have

always been susceptible to fraud. In

general, fraud in CNP transactions is

harder to prevent than in Card-Present

transactions. This is because the

merchant cannot personally examine

the card for signs of possible fraud and

the payment information required for

CNP transactions can be fairly easily

captured by a thief. It is also notable

that as the security of Card-Present

transactions increase, fraud is shifting to

other channels such as CNP transactions.

In regions where the Card-Present

domain moved from magstripe to more

secure EMV chip-based cards, a clear

fraud channel migration towards CNP

transactions has occurred. For example

after the United Kingdom migrated to

EMV chip-based cards the level of CNP

fraud tripled from 2002 to 20061.

Ultimately, a secure card payment

requires two elements to be properly

verified by the issuer:

1. The payment instrument (for

example, credit card) is valid

2. The user presenting the payment

instrument is the actual holder of

that instrument

While the first element can be easily

verified by the issuer, the second element

is challenging in the CNP domain. During

CNP transactions, issuers have limited

tools available to perform customer

authentication and verify the payment

instrument ownership. To perform a

CNP transaction, the customer needs to

provide a limited set of information: the

Card Number (PAN); Cardholder Name,

Expiry Date, and Card Security Code (also

known as CVV/CVC). This information

can be easily obtained by a criminal

by capturing an image of the physical

card, phishing, or other cross channel

information capture mechanisms.

To offer the issuer a possibility of

properly authenticating the customer,

Visa introduced 3DS 1.0 in 2001. The

3DS ecosystem is designed to perform

an additional authentication “challenge”

with the customer before the payment is

processed. The goal of this challenge is to

authenticate the customer to the issuer.

3DS 1.0 consists of a number of systems

that together form a network that can be

used to verify the customer (see Figure

2). Each of the actors in the environment

(Merchant, Scheme, and Issuer) must

have their own system (Merchant

Plug-in, Directory Server, and Access

Control Server, respectively). Together

the ecosystem allows the merchant

to communicate to the issuer, retrieve

the information needed to perform the

authentication, and help the issuer to

authenticate the customer.

1 Source: UK Payments Administration

CHALLENGES OF 3DS 1.0

Although 3DS 1.0 helps to reduce the number of frauds

and offers an extra layer of security for both customers and

merchants, it has not been warmly welcomed by the industry.

Below is a list of the key reasons for this.

USER EXPERIENCE DURING CHECKOUT PROCESS

For merchants, implementing 3DS 1.0 increased customer

friction and confusion which caused customers to drop the

purchase before finishing the payment. Friction in this case

refers to difficulties in the process a customer must go through

when checking out the items in the cart (commonly known

as a checkout process). The most common friction generators

are excessive steps to complete a purchase, additional

authentication layers, poor or inconsistent user interfaces, and

large numbers of forms to be filled by the consumer. Friction in

the checkout process impacts merchant’s conversion rate and

consequently results in a loss of revenue.

Figure 1 shows a usual checkout process from a customer point

of view. 3DS adds extra steps in the checkout process that

complicates the payment process. The customer needs to enter

his password in a separate pop-up window and confirm the

payment. In the case that the customer has not been enrolled

to the 3DS services before, the customer must enroll first. This

introduces a disruption in the customer journey and may cause

the customer to drop the purchase.

SECURITY

Another challenge of 3DS 1.0 is a potential vulnerability to

phishing and “man in the middle” attacks. This is due to the

redirection to another URL (a separate pop-up window) for the

3DS authentication process. An attacker can steal personal

information by generating a similar looking pop-up window or

executing an attack on the computer of the customer.

NEW PAYMENT CHANNELS AND NON-PAYMENT SERVICES

Over the years a large portion of online shopping has shifted

towards the mobile domain. However, 3DS 1.0 supports

only browser based purchases while in-app purchases are

not supported. This excluded a high volume of transactions

performed via consumers’ mobile devices using apps. Moreover,

the online services that require customer authentication

go far beyond payments. Think of identity services, card on

file verification, etc. For any of these services the customer

experience is of high importance. This forces merchants and

service providers to develop simple, streamlined, and consistent

user interfaces and customer authentication mechanisms.

IMPLEMENTATION EFFORTS

3DS requires investments in implementation while its benefits

are not immediately obvious for merchants. On one hand, with

3DS the customer authentication is moved to the issuer domain

which eliminates the merchant’s liability for the fraudulent

transactions. On the other hand, the merchant needs to invest in

the development and setting up of additional components.

Figure 1. Checkout process from the customer point of view

INTRODUCTION OF 3DS 2.0

3DS 1.0 has not received broad support in the industry. Thus, a clear need for

customer authentication during online payments has remained in high priority. In

many regions this need has been enhanced by local legislation. For example, one

of the latest legislations in the European Union, the Payment Service Directive 2

(PSD2), mandates issuers to perform two-factor authentication (so called Strong

Customer Authentication – SCA) for CNP payments (with some exemptions). This

requirement has raised the need to:

• Streamline the customer experience during the authentication process.

• Adopt customer authentication in other use cases like in-app purchase and

non-payment transactions.

• Enable issuers to have a choice of approving the transaction based on a

risk-based analysis.

To address the market needs and to reflect the current and future market

requirements, the 3DS 1.0 specifications have been revised. In October 2016,

during the Money 20/20 conference in Las Vegas, a new version of the 3DS

specification under version number 2.0 (3DS 2.0) was released. This time the 3DS

specifications are governed centrally by EMVCo2. The centralized approach:

• Unifies the 3DS 2.0 implementation across the schemes.

• Makes the implementation the 3DS 2.0 specifications for all the schemes

easier for merchants as the core functionality remains the same for all the

schemes.

The main enhancements of 3DS 2.0 compared to 3DS 1.0 are to:

• Support applications on mobile phones and other devices.

• Enable merchants to better integrate the authentication process into their

checkout experiences, for both app and browser-based implementations,

allowing for a smoother checkout process.

• Allow issuers to approve a payment transaction based on a risk-based analysis

of transactions. Based on this analysis, a “frictionless” authorization can

be followed where the customer is not required to perform any additional

step-up authentication.

• Enable non-payment customer authentication that allows services like

Identification & Verification (ID&V) for mobile wallets and secure request of

tokens for card on file.

• Allow issuers to design a customer authentication that is more secure and user

friendly than the static password often seen in 3DS 1.0. For instance, this can

include biometrics through Out-Of-Band (OOB) authentication or the use of a

One-Time-Passcode via SMS/email.

LATEST NEWS

3DS 1.0 was not the first

attempt to solve the

authentication challenge in

CNP transactions. The first

attempt was SET (Secure

Electronic Transaction)

consortium. It was established

in 1996 by Visa and Mastercard

in cooperation with GTE,

IBM, Microsoft, Netscape and

others. However, it failed to get

traction and was then replaced

by 3DS 1.0.

2 EMVCo is a consortium with control split equally among Visa, Mastercard, JCB, American Express, China UnionPay, and Discover.

Please note that 3DS 2.0 is not backwards compatible with 3DS 1.0. 3DS 2.0 introduces new components and adds extra functionality

to the existing components. The authentication flow and messaging specifications have changed from 3DS 1.0. 3DS 2.0 will demand

the merchants’ and issuers’ systems to be upgraded, even if 3DS 1.0 is already supported.

In the following sections, the changes introduced by 3DS 2.0 are analyzed. First, new components and their functionality that are

specified by 3DS 2.0 are presented. Next, the differences of the flows in 3DS 1.0 and 3DS 2.0 are discussed.

NEW COMPONENTS IN 3DS ECOSYSTEM

The 3DS ecosystem of both 1.0 and 2.0, operates in 3 domains:

• Issuer domain

• Acquirer domain

• Interoperability domain

However, the components and functionality included in these domains are different between the two versions. 3DS 2.0 introduces new

components to the 3DS ecosystem to support the new authentication flows. In addition, the functions of the existing components are

extended in 3DS 2.0. Figure 2 shows an overview of the ecosystem and components of 3DS 1.0 (left) and 3DS 2.0 (right).

Figure 2. Domains and components of 3DS 1.0 (left) and 3DS 2.0 (right)

PAYMENT SERVICE DIRECTIVE 2

In December 2015 European Parliament

adopted the Payment Service Directive 23

(PSD2). It came into effect on January 12,

2016. EU countries have two years to adopt

the PSD2 into their legislation and national

laws before the deadline of January 12,

2018. The main objective of the PSD2

is to unify the EU e-payment market by

creating rules and guidelines for payment

institutions within the EU. Among others,

the PSD2 introduces strict security

requirements for initiation and processing

of electronic payment transactions and

access to accounts. These requirements

include the need of using Strong Customer

Authentication (SCA) for electronic

payment including remote payments. SCA

is a customer authentication process that

must include at least two out of the three

authentication factor types: knowledge,

possession, inherence.

As part of the PSD2, the European

Banking Authority (EBA) was mandated to

formulate Regulatory Technical Standards

(RTS) on SCA and Common and Secure

Communication (CSC). The final draft

of RTS specifies exemptions for SCA

according to which, CNP transactions that

are lower than 30 euro do not require SCA.

Besides this, SCA may not be required if

the issuer uses a risk-based analysis for

transactions of the maximum possible

value of 500 euro.

The PSD2 can be the powerful driver of 3DS

2.0 in the EU region. Issuers will probably

decline a transaction if they are not able

to perform SCA or a risk-based analysis (if

the transaction is exempted from SCA).

This may cause a significant drop of the

conversion rate on the merchant’s website.

This may also negatively impact the issuer

and card brands’ brand. Thus, merchants

and issuers are forced to look for a

convenient and smooth way to implement

an authentication process during the

checkout process to comply with the PSD2

requirements. 3DS 2.0 has a potential

to be an effective tool to support PSD2

requirements and thus may be considered

by merchants and issuers.

Table 1 provides the summary of the components present in 3DS 1.0 and 3DS 2.0,

which are described in more detail in the rest of this section.

ISSUER DOMAIN COMPONENTS

For both 3DS 1.0 and 3DS 2.0, the issuer domain contains three main

components: Customer, Issuer, and Access Control Server (ACS). While the

functionality of the Customer and Issuer components remain the same for both

versions of 3DS, the ACS component functionality is extended in 3DS 2.0.

Customer. The customer shops online using the payment card issued by the

issuer. The customer provides necessary account information during the

transaction and confirms the purchase.

Issuer. The issuer is the financial institution that:

• Issues payment cards for the customer

• Defines card number ranges eligible to participate in 3DS and provides it to

DS and ACS

Access Control Server (ACS). The ACS operates in the issuer domain and contains

the authentication rules specified by the issuer. In 3DS 1.0 the ACS has two main

functions:

• To verify whether a given PAN is enrolled in 3DS

• To authenticate a specific transaction

3DS 1.0 includes only a single customer authentication flow, known as challenge

flow. 3DS 2.0 introduces frictionless authentication flow which allows the issuer

to use the risk-based analysis for the customer authentication. Additionally, in

3DS 1.0, the ACS supports customer authentication for payment transactions

only, whereas in 3DS 2.0 non-payment customer authentication is also supported

(see section "A Typical Transaction: 3DS 1.0 vs 3DS 2.0" for more details).

3 DIRECTIVE (EU) 2015/2366 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 25 November

2015 on payment services in the internal market.

4 Draft Regulatory Technical Standards on Strong Customer Authentication and common and secure

communication under Article 98 of Directive 2015/2366 (PSD2) published by European Banking

Authority on 23 February 2017.

Table 1. Summary of the components present in 3DS 1.0 and 3DS 2.0

page 10

INTEROPERABILITY DOMAIN COMPONENTS

The interoperability domain includes 3

components in 3DS 2.0: Payment network

(Authorization network), Directory

Server Certificate Authority (DS CA) and

Directory Server (DS). 3DS 1.0 includes

an additional (sub) component of the

DS, the Authentication History. The

Authentication History is not a separate

component in 3DS 2.0.

Payment network (Authorization System).

The payment network performs its

traditional role after 3DS authentication

is completed. This is among other clearing

and settlement services provided to the

acquirer and the issuer.

Directory Server Certificate Authority (DS

CA). The DS CA generates and distributes

Transport Layer Security (TLS) certificates

for use by 3DS components. In 3DS 2.0 the

DS CA also signs the certificates used for

the encryption of certain pieces of data

and certain messages when performing

a challenge authentication. To simplify

the description of the transaction flows

provided in the following sections, the

DS CA is not included in the further

discussions as it does not actively

participate during a transaction.

Directory Server (DS). The DS in 3DS 1.0

includes the following functions:

• Onboarding merchants and issuers

• Determining whether the PAN is in a

participating card range

• Routing messages between the

merchant and the ACS of the relevant

issuer

In 3DS 2.0 the number of functions of the

DS is extended to include:

• Defining 3DS specific rules (for

example, 3DS logo, time-out

values, etc.). This facilitates 3DS

implementation on the merchant’s

website.

• Maintaining ACS versions and 3DS

Method URLs. This enables the

merchant to receive information

about the ACS without the need to

connect to the ACS.

Authentication History (AH). This

component is applicable only for 3DS 1.0

and responsible for storing records for

each completed transaction. To simplify

the description of the transaction flows

with 3DS provided in the following

sections, the AH is not represented

separately and is assumed to be a part of

the DS.

ACQUIRER DOMAIN COMPONENTS

The acquirer domain includes a number of

new components in 3DS 2.0 that extend

the possibilities of 3DS authentication

compared to 3DS 1.0. These components

are the 3DS Requestor Environment and its

(sub) components and the 3DS Integrator.

The Acquirer component is the same for

both versions of 3DS while the Merchant

Server Plug-in (MPI) is only relevant for

3DS 1.0 and is dismissed in 3DS 2.0.

Acquirer. For both versions of 3DS, the

acquirer performs the traditional role that

includes the following functions:

• Handling payment authorization

requests/response to/from the

merchant

• Communication with the Payment

network for payment authorization

request confirmation

• Submitting the completed

transactions to the settlement system

The Merchant Server Plug-in (MPI).

MPI creates and processes customer

authentication messages, then returns

control to the merchant software. In 3DS

2.0 this component is replaced by the 3DS

Requestor and 3DS Server that are part of

the 3DS Requestor Environment and are

discussed below.

The following components are introduced by 3DS 2.0. These

components are intended to extend the 3DS authentication

options and provide better services for both merchants and

customers.

The 3DS Requestor Environment. The 3DS Requestor

Environment is a collective term for 3 components that are in

the merchant’s control:

• 3DS Requestor

• 3DS Client

• 3DS Server

3DS Requestor. This component initiates the start of the

customer authentication and is a pipeline for the 3DS data

from the customer device. 3DS Requestor supports both

application and browser based authentication.

3DS Client. The 3DS Client is provided by the merchant and

runs on a customer device that initiates a 3DS authentication.

The 3DS Client can be implemented in two models:

• App-based: The 3DS Client is the 3DS SDK that contacts the

3DS Requestor and provides the following functions:

• Providing and rendering the customer interface

• Gathering and encrypting 3DS information from the

customer device

• Browser-based: The 3DS Client is the 3DS Method that

is integrated in the merchant’s website and is in contact

with the 3DS Requestor. The 3DS Method is called within

the browser on the customer’s device. The purpose of the

3DS Method is allow the ACS to obtain additional browser

information before the authentication is started to

facilitate risk-based decisions.

3DS Server. The 3DS Server provides the functional interface

between the 3DS Requestor and the DS. The main functions of

the 3DS Server are the following:

• Communicating with the DS including transferring

necessary information from the 3DS Requestor to the DS

• Protecting the message contents

3DS Integrator. The role of the 3DS Integrator is to facilitate

integration of 3DS into the merchant’s system including

providing the functional interface between the 3DS Requestor

and the 3DS messages. To simplify description of the

transaction flows with 3DS provided in the following sections,

the 3DS Integrator is not included in further discussions.

A TYPICAL TRANSACTION: 3DS 1.0 VS 3DS 2.0

While 3DS 1.0 enables only a payment flow that always

requires customer authentication, 3DS 2.0 introduces

frictionless flow that allows use of a risk-based analysis to

reduce the number of interactions with the customer during

customer authentication. In Figure 3 (right), the frictionless

transaction is shown as a green path (steps 1-4).

Figure 3. Typical transaction in 3DS 1.0 (left) vs 3DS 2.0 (right). Steps 1-3: A transaction is started and an authentication request/response is sent to/from the issuer. Steps 4-5: If needed the customer is authenticated by the issuer. Step 6: Results of the authentication are communicated either through the customer (1.0) or through the DS (2.0). Steps 7-8: Completion of the flow. After this the normal Payment flow is followed (dashed line).

page 12

3DS 1.0 STEP 3DS 2.0

ENROLLMENT TO 3DS SERVICES

Both versions of 3DS require prior customer

enrollment to 3DS services with customer’s

issuing bank.

STEP 0CUSTOMER

ENROLLMENT

Both versions of 3DS require prior customer

enrollment to 3DS services with customer’s

issuing bank.

TRANSACTION INITATION

The customer initiates a transaction and provides the

required data (e.g. cardholder name, PAN etc.) on the

merchant website.

The following steps 2-4 are performed on the background

and are not visible for the customer.

STEP 1TRANSACTION

INITIATION

Similarly to 3DS 1.0, the customer provides all the

necessary information to initiate the transaction.

3DS 2.0 enables merchants to integrate the 3DS Client

into their checkout process, for both app and browser-

based implementations.

Merchant Server Plug-in (MPI) sends Verify Enrollment

Request (VEReq message) to DS. If the PAN range is in the

participating card range, DS forwards the VEReq message

to the appropriate ACS to check if the customer

is enrolled to 3DS services.

STEP 23DS VERIFICATION

REQUEST

VS

3DS 2.0

AUTHENTICATION

REQUEST

Instead of a VEReq message, in 3DS 2.0 the 3DS Server

sends an Authentication Request (AReq message) to

the ACS via the DS. This message includes information

needed for ACS to make a decision if the further

customer authentication is required.

Upon receiving the VEReq message, the ACS checks if

the customer is enrolled in 3DS services and sends the

response (VERes message) to the DS. DS then forwards it

back to the MPI.

STEP 33DS VERIFICATION

RESPOND

VS

3DS 2.0

AUTHENTICATION

RESPOND

Upon receiving the AReq message, the ACS evaluates

the data provided in the message.

Based on the risk assessment of the issuer, the

ACS determines if additional customer verification

is required to complete the authentication. If the

transaction is considered a low risk transaction, the

authentication process follows the frictionless flow.

Otherwise the customer authentication will proceed

with the challenge flow.

ACS communicates its decision of following the

frictionless flow or applying the challenge flow back to

the 3DS Server via the DS in the ARes message.

ACS communicates its decision of following the

frictionless flow or applying the challenge flow back to

On top of this, 3DS 1.0 supports only payment flows while 3DS 2.0 enables also non-payment authentication. This allows customer

authentication for the non-payment services. The flow of the customer authentication is the same as the payment authentication

flow shown in Figure 3 (right). The difference is that there is no actual payment (blue path on the figure) after the customer

authentication.

This section discusses the payment authentication challenge and frictionless flows in 3DS 2.0 in detail in comparison with the 3DS

1.0 flow (Figure 3).

3DS 2.0 FRICTIONLESS FLOW

The Frictionless flow is one of the fundamental differences between 3DS 1.0 and 3DS 2.0. This flow is represented as the green

path in Figure 3 (right hand side, steps 1-4). 3DS 2.0 allows the issuer to make a decision on the transaction authorization based

on the information received in the AReq message. If the issuer decides that the transaction is a low risk transaction then it falls

under frictionless flow, and no additional interaction with the customer is needed to complete the authentication. In this case the

3DS Requestor informs the customer that the authentication has been completed successfully. If the issuer decides that additional

customer authentication is required, then the process continues with step 4 (red path in Figure 3).

CHALLENGE FLOW

Based on data included in the VERes message, the MPI

generates the Payer Authentication Request (PAReq

message) and sends it to the ACS via the merchant’s

website. This message includes the results of the

previous steps and the merchant’s URL to which

the final reply should be sent.

In case the customer is not yet enrolled, first the issuer

will trigger the 3DS enrollment process.

STEP 43DS PAYER

AUTHENTICATION

REQUEST

VS

3DS 2.0

CHALLENGE

REQUEST

The 3DS Server communicates the result of the ARes

message to the 3DS Requestor which passes it

to the 3DS Client.

If the transaction falls under the frictionless flow, the

customer is informed that the authentication has been

completed successfully, otherwise further customer

interaction is required. In this case, a Challenge Request

(CReq message) is sent to the ACS.

The ACS responds with the challenge to the payment

authentication request from the MPI (PARes message).

From the customer experience point of view, the

customer sees a separate HTML page (pop up window)

that is outside of the merchant website environment,

requiring the customer for instance to enter a password

in order for the issuing bank to

authenticate the customer.

The customer enters the data required to perform the

challenge and this data is sent to the ACS

in the PAReq message.

STEP 5CUSTOMER

AUTHENTICATION

The response of ACS to the challenge request is

included in the CRes message to the 3DS Client.

The customer experience in this case is another

fundamental difference between 3DS 1.0 and 3DS

2.0. From the customer experience point of view, the

customer remains in the merchant’s website/app

environment. This flow enhances the user experience

and makes the checkout process smoother.

Please note, for out-of-band authentication,

the user experience may differ and highly depends

on the issuer implementation.

This white paper does not discuss this type of the

customer authentication.

The customer enters the data required to perform the

challenge and this data is sent to the ACS.

Based on the received information, ACS authenticates

the customer and forwards the Payer Authentication

Response (PARes message) with the results of

authentication to the MPI via merchant’s website URL

(received during step 4).

This message closes the pop-up window and returns to

the merchant’s browser window.

As a final step, the ACS sends the transaction details to

STEP 63DS PAYER

AUTHENTICATION

RESPONSE

VS

3DS 2.0

CHALLENGE

RESPONSE

Unlike 3DS 1.0, in 3DS 2.0 the authentication results

are first sent to the 3DS Server via the DS (RReq

message). In this way, the merchant is informed about

the authentication results via a separate channel that

enhances security.

After receiving RReq message and sending a response

in the RRes message, the merchant can proceed with

initiating the payment transaction.

N/A

STEP 7FINAL CHALLENGE

RESPONSE

As a final step of the transaction flow, the ACS sends

the final CRes message to the 3DS Client with the

authentication results.

page 14

3DS 2.0 aims to solve multiple technical and business pain points of 3DS 1.0. Below

is the summary of 3DS 1.0 shortcomings and the 3DS 2.0 solutions.

USER EXPERIENCE DURING CHECKOUT PROCESS

3DS 1.0 adds an additional step during the checkout process when the customer

needs to authenticate himself to the issuer. This authentication is done in a

separate pop-up window that causes a disruption in the customer journey and can

lead to customer friction and confusion. This negatively impacts the conversion rate

on the merchant’s website, directly correlating with the merchant’s revenue.

The challenge flow of 3DS 2.0 still requires the customer to perform an additional

step during the checkout process. However, the authentication process can now

be embedded in the merchant’s website which reduces confusion by not leaving

the merchant shopping environment. 3DS 2.0 allows integration of risk-based

authentication techniques for customer authentication, enabling a frictionless flow

substantially improving customer experience. By reducing 3DS impact for some

of the transactions, merchants will benefit by getting a better and smoother user

experience during the checkout process.

However, although 3DS 2.0 allows the issuer to perform the frictionless flow for

the customer authentication, it does not necessary mean that the issuer will do so.

The merchant does not have much influence over issuer’s decisions to apply the

frictionless flow. If the issuers are not willing to enhance the user experience, the

frictionless flow may not play the beneficial role it potentially has.

SECURITY

3DS 1.0 is potentially vulnerable to phishing and “man in the middle” attacks.

By integrating the authentication process to the merchant’s website in 3DS

2.0, the risk of these types of attacks is significantly reduced. Additionally, to

enhance security 3DS 2.0 separates the channels of the customer authentication

(via 3DS Client on the merchant’s website/application) and the sending of the

authentication results to the merchant via the DS and 3DS Server.

SUMMARY + CONCLUSION

AUTHENTICATION CHANNELS

3DS 1.0 supports only in-browser purchases causing a high volume of transactions performed via

consumers’ mobile devices to not be supported. 3DS 2.0 allows integration of the authentication

process for both in-browser and in-app purchases.

AUTHENTICATION METHODS

3DS 2.0 allows the issuer to design a customer authentication that is more secure and user

friendly than the static password often seen in 3DS 1.0. Issuers may also apply Out-Of-Band (OOB)

authentication for example biometrics or other authentication methods through their proprietary

application.

NON-PAYMENT SERVICES

3DS 1.0 focuses solely on the authentication process during a payment transaction. 3DS 2.0 offers

broader services and allows merchants to initiate the non-payment customer authentication flow.

This may be particularly useful for customer identification and verification (ID&V) and card on file use

cases.

COMPATIBILITY

3DS 2.0 is not backwards compatible with 3DS 1.0. 3DS 2.0 introduces new components and adds

extra functionality on existing components. The authentication flow and messaging specification

differs from 3DS 1.0. 3DS 2.0 will demand the merchants’ and issuers’ systems to be upgraded, even if

3DS 1.0 is already supported.

IMPLEMENTATION

A notable difference between 3DS 1.0 and 3DS 2.0 is that 3DS 2.0 standards are developed centrally by

EMVCo and include input from the major global card brands such as American Express, Discover, JCB,

Mastercard, China UnionPay and Visa. This may facilitate 3DS 2.0 implementation for both merchants

and issuers; however, it is likely that card brands will release their own specific requirements on top of

the EMVCo specifications. Please follow news on our website (https://www.ul-ts.com) for the latest

information on the EMVCo and card brands requirements for 3DS 2.0.

MARKET ACCEPTANCE

3DS 1.0 has faced some resistance from the industry. 3DS 2.0 has the potential to become a

well-accepted practice in online commerce. Additionally, a powerful boost of 3DS 2.0 may be Payment

Service Directive 2 that regulates electronic payments in the EU market. Ultimately, success of 3DS 2.0

highly depends on active participation of both issuers and merchants in the 3DS 2.0 program.

NEW SERVICES

EMVCo is constantly improving the 3DS 2.0 specifications to enable more advanced services and

customer authentication options. We follow the latest enhancements to 3DS and keep our customers

up-to-date on our UL Transaction Security blog at https://blog.ul-ts.com.

For further information on NFC applications and mobile payments,

please contact: TRANSACTIONSECURITY@UL.COM or visit UL-TS.COM

page 16

UL HAS WRITTEN MORE THAN

1,600 STANDARDSDEFINING SAFETY, SECURITY, QUALITY AND SUSTAINABILITY

3 OUT OF 4 U.S. CONSUMERS ARE FAMILIAR WITH THE UL MARK

UL SERVES

1 OUT OF 3 FORTUNE 500 COMPANIES

UL REACHES MORE THAN

1 BILLION GLOBAL CONSUMERS ANNUALLY WITH SAFETY MESSAGES

UL OPERATES IN MORE THAN

143COUNTRIES

AND ACROSS MORE THAN

20 INDUSTRIES

500+ BANKS20+ PAYMENT SCHEMES50+ GOVERNMENTS AND PUBLIC TRANSPORT OPERATORS60+ MOBILE NETWORK OPERATORS

UL’S PRODUCT SUSTAINABILITY CERTIFICATION MARKS ARE REFERENCED OR PREFERRED IN

SPECIFICATIONS AND PURCHASING GUIDELINES AROUND THE GLOBE

IN 2015 ALONE UL PARTICIPATED IN 508 SEIZURES, ELIMINATING MILLIONS OF DOLLARS OF COUNTERFEIT PRODUCTS FROM THE MARKET

UL WORKS TO PROTECT THE MARKET FROM COUNTERFEIT GOODS

UL MARKS APPEAR ON MORE THAN

UL HAS ENHANCED TRANSACTION SECURITY FOR:

900+ SUSTAINABLE PRODUCT

22 BILLIONPRODUCTS GLOBALLY

UL SOFTWARE IS USED BY

10,000 ORGANIZATIONS IN OVER 20 INDUSTRIES

MORETHAN

ABOUT US

UL fosters safe living and working conditions for people everywhere through the application of science to solve safety, security and

sustainability challenges. The UL Mark engenders trust enabling the safe adoption of innovative new products and technologies.

Everyone at UL shares a passion to make the world a safer place. We test, inspect, audit, certify, validate, verify, advise and train and

we support these efforts with software solutions for safety and sustainability.

UL's Transaction Security division guides companies within the mobile, payments, and transit domains through the complex world

of electronic transactions.

UL is the global leader in safeguarding security, compliance, and global interoperability. Offering advice, training, compliance

and interoperability services, security services, and test tools, during the full life cycle of your product development process or the

implementation of new technologies.

UL’s people proactively collaborate with industry players to define robust standards and policies. Bringing global expertise to

your local needs. UL has accreditations from industry bodies including Visa, Mastercard, Discover, JCB, American Express, EMVCo,

UnionPay International, PCI, GCF, GlobalPlatform, NFC Forum, and many others. To learn more about us, visit UL-TS.com.

3DS 1.0 3DS 2.0

Authentication process is limited to in-browser

paymentsAUTHENTICATION

CHANNELS

Supports in-browser and in-app authentication

processes

Authentication is performed in a separate

pop up window which increases friction of

the customer and introduces vulnerability to

phishing and ‘man in the middle’ attacksAUTHENTICATION

PROCESS

It is possible to embed the authentication process

in the merchant’s website or mobile application

that makes customer experience smother and

reduces the risk of phishing and

‘man in the middle’ attacks

Any transaction requires an

authentication challenge

RISK-BASED

AUTHENTICATION

Risk -based authentication allows

frictionless transactions

Primarily static and hardware-heavy

authentication methods are possible

AUTHENTICATION

METHODS

Out-Of-Band authentication is possible and allows

advanced authentication methods,

including biometric

It is designed solely for payments

PURPOSE

3DS 2.0 supports non-payment cases

Each card brand provides their specifications

SPECIFICATIONS

Specifications are governed centrally by EMVCo.

The cards brands are likely to issue specific

requirements on top of the EMVCo specifications.

It is not compatible with 3DS 2.0

It is not compatible with 3DS 1.0. Even if 3DS 1.0 is

already implemented, issuer’s and merchant’s

systems must be upgraded to support 3DS 2.0

MAIN DIFFERENCES BETWEEN 3DS 1.0 AND 3DS 2.0

page 17

page 18

ACRONYM EXPLANATION

3DS Standards 3 Domain Secure Standards

ACS Access Control Server

AH Authentication History

CSC Common and Secure Communication

CNP Transactions Card-Not-Present transactions

CVM Cardholder Verification Methods

DS Directory Server

DS CA Directory Server Certificate Authority

EBA European Banking Authority

EMV Europay, Mastercard and Visa

ID & V Identification & Verification

JSON JavaScript Object Notation

MPI Merchant Server Plug-in

OOB Out-Of-Band

OTP One Time Password

PAN Permanent Account Number

PSD2 Payment Service Directive 2

RTS Regulatory Technical Standards

SCA Strong Customer Authentication

SDK Software Development Kit

TLS Transport Layer Security

XML Extensible Markup Language

ACRONYMS

UL-TS.COM

©2017 UL LLC. All rights reserved. This white paper may not be copied or distributed without permission. It is provided for general information purposes only and is not intended to convey legal or other professional advice.