-
Notifications
You must be signed in to change notification settings - Fork 9
Home
This was the repo of the Card Payment Security Task Force (of the Web Payments WG) regarding 3-D Secure, which created the draft document 3-D Secure 2 with Payment Request API.
In 2018, discussion Card Payment Security Task Force.
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.
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.
- 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.
- 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.
- 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.
- 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.
- 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.
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!
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.
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.
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.
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.
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.