SCA and 3DS 2

Introducing Strong Customer Authentication and 3DS 2

Strong Customer Authentication (SCA) is part of the PSD2 (Payment Services Directive) regulation in Europe. SCA aims to increase the security of electronic payments by requiring customers to authenticate themselves based on the use of elements categorized as knowledge (i.e. something only the user knows), possession (i.e. something only the user possesses) and inherence (i.e. something the user is).

One of the solutions for providing SCA, is 3DS 2 (also known as EMV 3D Secure). As the successor to 3DS 1, it has been designed to provide for a more secure and user-friendly authentication experience. With 3DS 2, data (such as device information) transmitted in the background is mostly enough to authenticate without an extra step for the customer. It’s only when the provided information does not suffice to determine the risk-level of the transaction that an extra authentication step may be required.

Where 3DS 1 Fell Short

In a 3DS 1 flow, you redirect the customer to an authentication page on their bank’s website, where they are prompted to enter a password associated with the card or a verification code sent to their phone. While it is a solid authentication step, this redirect flow is rather clunky (it’s not supported natively in app and in web flows) and is confusing to customers. As a result, legitimate customers drop out of the payment flow thereby impacting your acceptance rates and bottom line.

Exemptions to Strong Customer Authentication

There are circumstances in which you may want to exempt a user from an SCA flow. One example would be a merchant-initiated transaction (MIT) with a user’s stored card credentials (in which case the SCA flow has already been completed as part of the consent transaction). Other examples include transactions identified as low-risk or transactions with a low value.

Exempting users from an SCA flow is useful since it increases the chance that the transaction will proceed frictionless (that is, without an additional authentication step) and thus decreases user drop-outs. To exempt a user from an SCA flow, you may need to indicate your intention to do so in the Create Authorization or Create Charge request. Bear in mind that the decision of whether to grant the exemption lies with the card issuer. If granted, the chargeback liability shifts back to you (as the merchant).

3DS 2 Transaction Flows

When implementing a 3DS 2 transaction flow, you have three options to choose from:

• The PaymentsOS 3D Secure Authentication service. This service is integrated into PaymentsOS and has been designed to handle the entire 3D secure authentication flow for you. Using the PaymentsOS 3D Secure Authentication service greatly simplifies the process of implementing a 3D secure flow and reduces your PCI scope. For more information and instructions on implementing the service, see 3D Secure Authentication service.

• An external MPI for authorizing a card using 3DS 2. If you use an external MPI for handling the 3D secure authentication flow, then you simply pass the 3DS data returned from the external MPI in the three_d_secure_attributes.external object of a Create Authorization or Create Charge request..

• A 3DS 2 flow as part of your PaymentsOS transaction flows. When choosing this option, you must pass all relevant information in the three_d_secure_attributes.internal object of a Create Authorization or Create Charge request. Depending on the provider you integrated with, you then either handle the remainder of the 3DS 2 authentication process yourself or let the provider handle it for you. See 3DS 2 Internal Transaction Flows below.

3DS 2 Internal Transaction Flows

Rather than using the PaymentsOS 3D Secure Authentication service, you may also choose to implement a 3D secure flow yourself as part of your payment flows integrated with PaymentsOS. There are two types of 3DS 2 internal flows:

• Self-handled. This flow is fully handled by you. See 3DS 2 Self-handled Flow.

• Provider-handled. This flow is fully handled by the provider you integrated with. See 3DS 2 Provider-handled Flow.

3DS 2 Self-handled Flow

In a 3DS self-handled flow, you must implement the 3DS flow logic yourself. There are three types of 3DS self-handled flows (the response received from the issuer following your initial Authorization or Charge request will determine the flow that you must invoke):

• 3DS data collection flow: In this flow, data (such as device information) transmitted in the background is enough to authenticate without an extra step for the customer.

• 3DS data collection and challenge flow: This flow is the complete 3DS flow. It is similar to the 3DS data collection flow but includes an additional authentication step (challenge) that will be invoked if the information provided in the data collection step does not suffice to determine the risk-level of the transaction.

• 3DS challenge only flow: In this flow, the customer is immediately redirected to an authentication step (challenge).

Let’s take a look at each of those flows in more detail.

3DS Data Collection Flow

In this flow, device data is used to authenticate the customer. This flow is frictionless, in that authentication occurs under the hood and no extra authentication step is needed for the customer.

The following image illustrates the 3DS Data Collection flow:   The flow is as follows:

1. Create a new Authorization or Charge request.

   In the three_d_secure_attributes.internal object, pass in additional information that will help the card issuer assess the fraud risk level of the transaction. The response will include a redirection resource with an operation_type field whose value is data_collection, indicating that data collection is required. The authorization will have a status of Pending.

2. Initiate the data collection process and pass the data to the issuer, as explained in Initiating the Data Collection Process. Under the hood, a communication session will be opened to the issuer and the issuer will collect the browser or device information from the user. The device or browser information will be used in combination with the data passed in the three_d_secure_attributes.internal object to authorize the payment (see the next step).

3. After receiving a notification from the card issuer indicating that the analysis of the user’s device or browser information has been completed, invoke the Continue Authentication Flow or Continue Charge Flow request to continue the authentication process.

4. When authentication is completed, we will update the status of the Authorization or Charge request.

3DS Data Collection and Challenge Flow

This flow is the complete 3DS flow. It is similar to the 3DS data collection flow but includes an additional authentication step (challenge) that will be invoked if the information provided in the data collection step does not suffice to determine the risk-level of the transaction.

The following image illustrates the 3DS Data Collection and Challenge flow:

 The flow is as follows:

1. Complete the 3DS data collection flow until step 3. The response of this step will indicate that a challenge is required and will include a challenge URL.

2. Open the challenge URL to allow the user to complete the additional authentication step. After the user completed the step, we will redirect the user to the merchant_site_url.

3DS Challenge Only Flow

In this flow, the customer is immediately redirected to an authentication step (challenge).

The following image illustrates the 3DS Challenge Only flow:

The steps in the flow are as follows:

1. Create a new Create Authorization or Create Charge request. In the three_d_secure_attributes.internal object, pass in additional information that will help the card issuer assess the fraud risk level of the transaction. Also pass in a merchant_site_url, to which the user will be redirected when authentication is completed. The response will indicate that a challenge is required and will include a challenge URL. The authorization will have a status of Pending.

2. Open the challenge URL to allow the user to complete the additional authentication step. After the user completed the step, we will redirect the user to the merchant_site_url.

3DS 2 Provider-handled Flow

A 3DS Provider-handled Flow is a 3DS flow handled in full by PaymentsOS and the provider that you transact against. All you need to do is supply enough information to help the card issuer assess the fraud risk level of the transaction. The provider will then handle all the remaining 3D Secure steps, such as collecting device information for constructing a fingerprint or redirecting the user to a challenge step (if needed).

The following image illustrates the 3DS 2 provider-handled Flow:

The steps in the flow are as follows:

1. Create a new Authorization or Charge request. In the three_d_secure_attributes.internal object, pass in additional information that will help the card issuer assess the fraud risk level of the transaction. Also pass in a merchant_site_url, to which the user will be redirected when authentication is completed.

   The response will indicate that a redirect is required and will include a redirection URL. The authorization will have a status of pending.

2. Open the redirection URL to allow the provider to handle the 3DS flow.

After the provider completed the 3DS flow, we will redirect the user to the merchant_site_url.

Initiating the Data Collection Process

To initiate the data collection process do the following:

1. Create a JSON object holding a threeDSMethodNotificationURL field (this is your notification URL to which the issuer will send the completion status of the data collection process) and a threeDSServerTransID field (this is the 3DS transaction ID you receive in the provider_data.three_d_secure_result.internal.three_d_secure_server_transaction_id field returned in the response of a Create Authorization or Create Charge request).

   {
       "threeDSMethodNotificationURL": "http://urlforreceivingapproval",
       "threeDSServerTransID": "4c9a869e-2e75-4b1b-9bc4-3635edbb5973"
   }
   

2. Format the object using Base64 encoding.

3. Render a hidden HTML iframe in the cardholder’s browser containing a form with a field named threeDSMethodData. Store the Base64url JSON Object in the field and send the form via HTTP POST to the redirection URL received in the redirection.url field in the response of the Create Authorization or Create Charge request.

   

Setup and Configuration Considerations

When implementing your 3DS 2 flow, you should take the following into account:

• PaymentsOS may not yet a support 3DS 2 flow with all providers. We thus strongly recommend you configure routing rules in your PaymentsOS account to route payments to a provider supporting 3DS 2 authentication. Refer to the relevant provider guide to determine whether 3DS 2 is supported.

• There may be some additional fields (such as billing and shipping address) in a Create Payment request that are required for a 3DS flow.

3DS 2.0 API Fields

See the three_d_secure_attributes.external and three_d_secure_attributes.internal object fields in the Create Authorization or Create Charge request, for an overview of the fields you can pass in an external or internal 3DS 2 flow.

Note that there may be some existing fields (such as billing and shipping address) and additional fields in a Create Payment request that are required for a 3DS flow. There may also be additional provider-specific fields that you will need to pass in a Create Authorize or Create Charge request.

SCA Enforcement Timelines

While SCA requirements are scheduled to go into full effect on 14 September 2019, some countries have released official statements following the European Banking Authority published opinion, which discusses an extension for SCA implementation for eCommerce and card payments. Here is a breakdown of the different European countries and their statements:

What should you do as a merchant?

As you can see from the above, the enforcement of SCA in Europe will be gradual and the majority of regulators will allow merchants an extension period for card payments and eCommerce (please check your country’s specific requirements). Since there is still some obscurity regarding the exact extension time and implications, we recommend that you make all of the necessary arrangements to be compliant on time (i.e. 14 September 2019). Learn more about it here.