SCA and 3DS 2

The information provided in this topic will allow you to familiarize yourself with 3DS 2 at a high-level and get ready for transitioning your implementation to support 3DS 2 in your transaction flow. You can also read our blog post for a more in-depth overview of Strong Customer Authentication (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).

Note

The provider you are transacting against may offer fraud protection services for analyzing a transaction's risk level.

3DS 2 Transaction Flows Overview

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 xxx below.

Note

If you use an external MPI (merchant plug-in) to authorize a card using 3D Secure, then you can pass the 3DS data returned from the MPI in the object object of a Create Authorization or Create Charge request. However, not all the providers you transact against may be able to receive this data. You should thus configure a route rule to direct the request to a provider that can process data received from an external 3DS service. For more information, see Routing Transactions to a Provider Supporting External 3DS

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:

Can I use either flow?

No. The type of flow you can use, depends on the provider you integrated with. To see whether a provider supports a specific flow type, first find the provider you're looking for (you can filter on Transaction Type Cards and Features 3DS 2.0 Internal to find only those providers supporting a 3DS 2 Internal flow). Then open the relevant provider topic; the Notes column in the Features table will list the type of 3DS 2.0 Internal flow that is supported.

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).

Notes:

  • In some cases you may receive a synchronous response of Succeed or Failed when invoking the initial Create Authorization or Create Charge request (for instance, if the transaction was exempted from SCA). In this case, proceed with a regular transaction flow.
  • The flows above are flows that you handle yourself. However, in some cases PaymentsOS and some providers may also handle the entire 3DS flow for you. For more information, see 3DS Proxy Flow.

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

3DS Data Collection Flow

In this step, 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: 3DS Data Collection Flow The flow is as follows:

  1. Create a new Authorization or Charge request.

    In the three_d_secure_attributes.internalobject, 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.

    Implementing a Timeout Check

    We recommend you implement a 10 second timeout for obtaining the notification response. If a timeout occurs, invoke the Continue Authentication Flow or Continue Charge Flow request and pass a three_d_secure_attributes.internal.data_collection_completed_ind value of N.

  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:

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:

3DS Challenge 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).

Can I always use this flow?

No. This flow is supported by specific providers only. To see whether a provider supports a specific flow type, first find the provider you're looking for (you can filter on Transaction Type Cards and Features 3DS 2.0 Internal to find only those providers supporting a 3DS 2 Internal flow). Then open the relevant provider topic; the Notes column in the Features table will list the type of 3DS 2.0 Internal flow that is supported.

The following image illustrates the 3DS Proxy flow: 3DS Proxy 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 3DS proxy to handle the 3DS flow.

After the 3DS proxy 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 three_d_secure_attributes.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.

There are a number of fields that are optional in a 3D secure 2 authentication flow (your request will not fail if not provided), but should be passed to increase your approval rates. Those fields are the following:

  • All browser information fields, passed in the authentication_attributes object of the 3D Secure Authentication request body.
  • All phone number (home, work and mobile) fields, passed in the authentication_attributes object of the 3D Secure Authentication request body.
  • The address_match field, passed in the authentication_attributes object of the 3D Secure Authentication request body.
  • Shipping and billing address fields, passed in the request body of the Create Payment request.

SCA Enforcement Timelines

SCA enforcement is scheduled to go into full effect in the EEU on January 1 2021. In the UK, the FCA have confirmed they will delay full enforcement until 14 September 2021.

We recommend that you make all of the necessary arrangements according to the date on which the regulations will take effect.

results matching ""

    No results matching ""