ianbjacobs edited this page May 24, 2018 · 42 revisions

This is the home of the 3DS2 task force of the W3C Web Payments Working Group see meeting information.

STATUS: This is a draft. Questions? Ian Jacobs <ij@w3.org>.

The mission of the 3DS2 task force is to make it easier for merchants to support EMV® 3-D Secure authorization through Payment Request API.

Problem Statement

EMV 3-D Secure is a messaging protocol developed by EMVCo to enable users to authenticate themselves with their card issuer when making card-not-present (CNP) e-commerce purchases. It is designed to prevent unauthorized CNP transactions and to protect the payment ecosystem from CNP-related fraud.

There are several reasons a merchant may wish to support 3DS 2.x, including (but not limited to):

  • To reduce CNP-related fraud.
  • To increase approval rates.
  • It is required by Central Bank mandate (e.g., in India).

However, current ecosystem limitations raise obstacles to adoption:

  • Merchants need to integrate custom code and specialized UX elements; this integration can be complex.
  • Users may be required to authenticate multiple times, adding friction to checkout.

Flows

In order to understand the opportunity envisioned by this task force, it is useful to have a high-level view of potential 3DS 2.x flows expressed from the perspective of Payment Request API.

Each flow begins with the user pushing the “buy button” on the merchant site, causing the browser to display matching payment apps for user selection.

Flow 1: Third Party Payment App acts as 3DS 2.x requestor

  • The user selects a third party payment app that supports EMV 3-D Secure.
  • When launched, the payment app invokes the 3DS 2.x flow.
  • The ACS (Access Control Server) responds to the payment app:
    • In a majority of cases, it is expected that no user authentication will be required. In this case, the ACS sends the payment app an “Authentication Value” (AV), which is returned to the merchant in the Payment Request API response.
    • When card holder authentication/challenge is required, the ACS requests that the payment app authenticate the user. The payment app invokes user interface to authenticate the user. There may be multiple ways to authenticate the user. For example, the ACS might send a one-time-password (OTP) to the user’s phone, which the user enters into the 3DS challenge UI within the payment app, which then returns it to the ACS. If satisfied, the ACS sends the Authentication Value to the payment app.
  • The Authentication Value is returned to the merchant in the Payment Request API response.

Flow 2: Browser, as provider of payment credential, acts as 3DS 2.x requestor

  • The user chooses a credit card stored in the browser.
  • The browser initiates the call to a Directory Server (Directory Server), which in turn routes the call to an ACS.
  • The ACS sends a response to the browser:
    • When no authentication is required, the ACS sends an Authentication Value to the browser. The Authentication Value is returned to the merchant in the Payment Request API response.
    • When card holder authentication/challenge is required, the ACS requests that the browser authenticate the user. The browser invokes user interface to authenticate the user; the user interface may be part of the browser or another application. There may be multiple ways to authenticate the user. For example, the ACS might send a one-time-password (OTP) to the user’s phone, which the user enters into the 3DS challenge UI, which returns it to the ACS. If satisfied, the ACS sends the Authentication Value to the browser.
  • The Authentication Value is returned to the merchant in the Payment Request API response.

See Also

Goals

  • Scale. Support the scalable adoption of 3DS 2.x by having the browser and/or payment apps manage interactions with 3DS servers rather than merchants having to do so. Because there are so many more merchants than browser or payment app providers, this means that fewer parties need to manage the 3DS server interactions, making it easier to scale 3DS 2.x deployment.
  • User experience. Improve the user experience by optimizing the timing of strong authentication within the payment app.

Who Benefits from this Effort

  • Consumers benefit from reduced fraud and improved user experience. Authentication and selection of payment instrument can happen in a single experience rather than split up into disjoint interactions.
  • Merchants benefit from reduced fraud, higher approval rates, lower software development costs, and other benefits. It should also be easier for merchants and PSPs to work together by reducing the friction of communicating 3DS 2.x data.
  • Payment Systems/Payment Networks benefit from broader adoption of 3DS 2.x solutions may help reduce fraud.
  • Issuers may benefit from the reduced fraud and higher approval rate due to broader adoption of 3DS 2.x solutions.

Scope

  • The task force focuses on the secure communication of a 3DS 2.x payload and consistent user experience.
  • Deliverables of the task force:
    • May be designed to apply across a range of payment methods (including non-card payment methods).
    • Should not be designed to favor any particular network.
  • The task force does not define
    • A new 3DS format.
    • A protocol for payment handlers to communicate with a DS or ACS.
    • A (back end) protocol between merchants and gateways.
  • The task force may discuss how merchants express an ability, preference, or requirement to accept 3DS 2.x payments.
  • The task force may explore opportunities for browser functionality that can enhance the 3DS experience such as native UI handing and cryptography.

Deliverables

At a high level, the task force expects to specify how to use Payment Request API and related technologies to fulfill 3DS requirements. This may involve:

  • Definition of a “module”:
    • through which merchants indicate an ability, preference, or requirement for payment via 3DS;
    • that integrates with EMVCo 3DS data requirements; and
    • that may be used with multiple payment methods (including tokenized card payments).
  • Code examples illustrating use of the module
  • @@A prototype implementation?@@ To be confirmed!

FAQ

Do merchants determine when to invoke the 3DS 2.x flow?

Yes. We anticipate merchants will want to express a variety of needs, such as:

  • I can accept 3DS 2.x flow
  • I prefer 3DS 2.x flow
  • I require a 3DS 2.x flow

We do not yet know how the merchant will express those needs.

What is the relationship to EMVCo?

This task force was launched to foster collaboration between the W3C Web Payments Working Group and participants of EMVCo. The deliverables of this task force are expected to reflect the consensus of both organizations.

What is the relationship to W3C Web Authentication?

Beyond reducing merchant PCI DSS scope, there is some interest in fostering strong authentication to achieve transaction approval rates on the Web similar to "card present rates.”

Where authentication is initiated in the context of a Web page, it is expected that, once a W3C Recommendation, the Web Authentication API could fulfill 3DS requirements.

With this approach, would merchants still have business relationships with PSPs?

Yes. We expect merchants will still have business relationships with PSPs and need to manage back-end integration. This task force seeks to make it easier for merchants and PSPs to work together by reducing the friction of communicating 3DS 2.x data on the Web.

Could a 3DS 2.x flow eliminate some UX friction?

We hope. Current implementations of the W3C Basic Card payment method prompt users to enter their CVV (or similar) codes as part of authentication. It is possible that 3DS 2.x flows could enable superior customer authentication without the need to prompt users. This is a topic for discussion by the task force.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.