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

You're most likely curious to understand the implications of 3DS 2 for your transaction flow. The required implementation depends on whether you're using an external MPI (merchant plug-in) to authorize a card using 3DS, or whether this is done during the PaymentsOS transaction flow:

  • If you use an external MPI to authorize a card using 3DS 2, 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..

  • If the 3DS 2 flow is part of the PaymentsOS transaction flow, then you can pass all relevant information in the three_d_secure_attributes.internal object of a Create Authorization or Create Charge request and handle the remainder of the 3DS 2 authentication process as explained 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

So let's take a closer look at the 3DS transaction flow, when 3DS is part of the PaymentsOS transaction flow. The response received from the issuer following your initial Authorization or Charge request, determines the type of flow 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 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: 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

    T 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 Proxy Flow

A 3DS Proxy Flow is a 3DS flow handled in full by PaymentsOS and the provider that you transact against (if supported by the provider).

Note

This flow will be supported by specific providers only.

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.

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:

Country Statement
Austria Austria announced a temporary enforcement extension for Austrian cards. The enforcement should go into full effect by the end of September.
Belgium The Belgian regulator released a formal announcement setting out the Bank's expectations regarding the regulatory technical standard for SCA of online payments. No set timeline has been published as of now.
Denmark Denmark released an official announcement of an 18 month extension period for SCA. The FSA emphasized that the implementation period will not change the fact that the rules on strong customer authentication will enter into force on 14 September 2019.
Finland Finland announced a temporary enforcement extension for Finnish cards. The Financial Supervisory Authority will decide on the length of the transitional period this year after further consulting with the supervisors of other Member States.
France The French are also working on a phased implementation plan, and have released an official document breaking down their current status and plans ahead.
Germany Payment service providers based in Germany are allowed to make credit card payments on the Internet from September 14, 2019 initially without strong customer authentication. BaFin estimates that the card-issuing payment service providers in Germany are prepared for the new requirements, while companies that use credit card payments on the internet as payees might not be fully prepared yet.
Ireland Ireland released an announcement stating a migration period limited only to eCommerce transactions. Therefore no disruption to payments systems is anticipated.
Italy The Italian regulators also released an announcement stating a transitional migration period, although its length of delay has not yet been officially confirmed.
Luxembourg The Luxembourg regulator announced a temporary enforcement extension for Luxembourg cards. The financial institutions that wish to make use of the extension period are required to inform the CSSF and back their request with a proper migration plan and timelines.
The Netherlands The DNB (De Nederlandsche Bank) has released the regulator's intention to allow parties that were unable to prepare for SCA (for credit card transactions) a limited extension time - the amount of time hasn't been stated.
Norway The Norwegian regulator also announced a temporary enforcement extension for eCommerce and card payments. The payment service providers who need to extend their deadline are requested to contact the Financial Supervisory Authority.
Poland The Polish regulator also announced an extension for Polish cards, contactless payments, and eCommerce. A proper migration plan will need to be submitted by the relevant parties in order to benefit.
Slovenia Since the authentication of the majority of card payments made in online stores in Slovenia (and the wider EU) is currently protected only by a one-time password received via a text message, such method of authentication does not meet the requirements of SCA. To ensure compliance, the Bank of Slovenia allows an extension for Slovenian payment providers with registered office in Slovenia beyond the deadline of 14 September.
Sweden The Swedish regulator also published an announcement that allows extension beyond 14 September for SCA. The extension applies for eCommerce transactions made with card payment. A submission of a detailed plan will have to be submitted and should include the company's planned communication activities to inform e-merchants and payment service users about the new conditions.
UK The UK regulator announced a transitional 18 month period for SCA implementation on online card payments. ‍

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.

results matching ""

    No results matching ""