3-D Secure 2 with Payment Request API

Introduction

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 (3DS2), 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).

This specification defines a way to leverage 3DS2 in conjunction with [[payment-request]]. At a high level, it works as follows:

3DS2 flows involve risk analysis that takes as input information about the transaction, payee, and payer. The payee therefore creates a ThreeDSRequest that is part of the payment method-specific data in the PaymentRequest.
The payeeChallengeInd within the ThreeDSRequest contributes to the computation of which payment handlers the user agent should offer to the user.
Then the user selects a payment handler that supports 3DS2, the user agent provides relevant data to the payment handler to initiate 3DS flows. The details of how the payment handler initiates 3DS flows lies outside the scope of this specification.
Once the user has completed interactions with the payment handler, the payment handler returns a ThreeDSResponse as part of the PaymentResponse.

See how to use this specification within a payment method specification below.

Examples

The following example illustrates how the Tokenized Card Payment Specification [[tokenized-card]] could be enhanced to include support for the current specification.

Request Example

const methodData = [{
  supportedMethods: ["tokenized-card"],
  data: {
    supportedNetworks: ['mastercard', 'visa', 'amex', 'discover', 'jcb', 'unionpay'],
    supportedTypes: ['credit','debit'],
    keyProviderURL: 'https://pspKeyProvider.example/tokenizedCardPublicKey',
    payeeChallengeInd: mandated
    // Not yet shown: payeeData or whatever form it takes
  }
}];

const details = { ...total, etc.... };

new PaymentRequest(methodData, details);

The value required for payeeChallengeInd means that the payee requires that for this payment method, a payment handler must support 3DS2.

Response Example

{
 displayLast4: "***6789",
 displayExpiryMonth: "02",
 displayExpiryYear: "22",
 displayNetwork: "mastercard",
 encryptedDetails: "QWxobHZ4bU4yWkt1QUFFU05GWjRHb0FCRkE9PQ==",
 eci: "242", // for 3DS2
 av: "...28 character authentication value ...", // for 3DS2
 transStatus: "Y" // for 3DS2
}

ThreeDSRequest dictionary

This section describes payment method specific data that is supplied as part of the data argument to the PaymentRequest constructor.

        dictionary ThreeDSRequest{
                   ThreeDSChallengeInd          payeeChallengeInd;
        };

The ThreeDSRequest dictionary contains the following members:

payeeChallengeInd: This optional member represents the payee's preferences regarding 3DS flows for this payment method and this transaction. Absence of this member means that the payee has not expressed a preference regarding 3DS2 flows. That corresponds to a value of 01 for the threeDSRequestorChallengeInd in the 3DS2 specification.
payeeData: Need to specify required merchant/payee data and the form this should take (in terms of a dictionary).

ThreeDSChallengeInd enum

In the 3DS2 specification, the threeDSRequestorChallengeInd field enables the 3DS Requestor to express a preference regarding the challenge flow for a transaction. In the Web payments ecosystem, different parties may play the role of 3DS Requestor, including the payee and the payment handler. In this, specification the ThreeDSChallengeInd refers specifically to the preference of the payee, whether or not the payee is the 3DS Requestor. The values are defined to align with those of the 3DS2 specification, but refer specifically to payee preferences. Payment handler behavior will potentially depend on a number of factors: the payee preferences defined below, but also user preferences and other considerations as well.

          enum ThreeDSChallengeInd { "requested", "mandated", "none" };

"requested": The payee requests that, for this payment method and this transaction, the payment handler SHOULD conduct a 3DS2 flow. This is presumed to include both a frictionless flow and a challenge flow. This value corresponds to a value of 03 for the threeDSRequestorChallengeInd in the 3DS2 specification.
"mandated": The payee indicates that, for this payment method and this transaction, the payment handler MUST conduct a 3DS2 flow because it is mandated for the payee. This is presumed to include both a frictionless flow and a challenge flow. This value corresponds to a value of 04 for the threeDSRequestorChallengeInd in the 3DS2 specification.
"none": The payee requests that, for this payment method and this transaction, the payment handler SHOULD NOT conduct a 3DS2 flow. This value corresponds to a value of 02 for the threeDSRequestorChallengeInd in the 3DS2 specification.

From issue 8: Payment handlers will need shipping address, contact information, order number, merchant id, acquirer id, merchant name.

Updating payeeChallengeInd from onshippingaddresschange

From issue 8: The payee may wish to adjust payeeChallengeInd depending on the shipping address. Thus, for example, when onshippingaddresschange fires, the payee may wish to use updateWith() to update the payeeChallengeInd.

ThreeDSResponse dictionary

        dictionary ThreeDSResponse {
                       DOMString       av;
                       DOMString       eci;
                       DOMString       transStatus;
                       DOMString       transStatusReason;
           required    DOMString       dsTransID;
         };

av member: This optional member is a Payment Network-specific cryptographic value generated by the Access Control Server (ACS) to provide a way, during authorisation processing, for the authorisation system to validate the integrity of the authentication result. The value is a 28-character string. The value may be a 20-byte value that has been Base64 encoded, giving a 28-byte result.
eci member: This optional member is an Electronic Commerce Indicator, a Payment Network-specific string to indicate the results of user authentication.
transStatus member: This optional member indicates whether a transaction qualifies as an authenticated transaction or account verification. It is a 1-character string whose transaction status values are defined in [[EMVCO-3DS]].
transStatusReason member: In a failure scenario, this optional member explains why the transStatus member has the specified value (for example "01" means "card authentication failed"). It is a 2-character string whose values are defined in [[EMVCO-3DS]].
dsTransID member: This member is a universally unique transaction identifier assigned by the Directory Server (DS) to identify a single transaction. It is a 36-character string defined in [[EMVCO-3DS]].

How to Use this Specification within a Payment Method Specification

Security and Privacy Considerations

Data Gathered by the Payment Handler

The Working Group is discussing privacy implications related to payment handler data gathering.

User Privacy Preference for Strong Authentication

Dependencies

This specification relies on several other underlying specifications.

Payment Request: The PaymentRequest and PaymentResponse interfaces are defined in [[!payment-handler]]. That specification also defines these terms: data, updateWith() and onshippingaddresschange.
Payment Handler: The term payment handler is defined in [[!payment-handler]].
EMVCo 3-D Secure: The terms Electronic Commerce Indicator, Access Control Server, Directory Server, transaction status, frictionless flow, challenge flow, threeDSRequestorChallengeInd, 3DS Requestor, and Payment Networks are defined in [[EMVCO-3DS]].