Getting Started With 3DS

Index: 

 

Common Questions: 

Is 3DS enabled on my Adyen account? 

Adyen enrolls payment methods into 3DS by default within 24 hours of the payment method creation. Therefore 3DS is enabled on Adyen accounts by default. 

 

Do I have to use 3D Secure?

The question of whether you have to use 3D Secure in your integration has several implications to keep in mind. Technically, you are not obliged to implement it, but because of the Payment Services Directive (PSD2), banks are required to perform strong customer authentication (SCA) for online payments. This means that if you decide not to implement 3D Secure, banks can refuse all transactions that require SCA, which can cause a drop in your authorisation rate.

With the rollout of PSD2, more and more issuers will start to send "soft declines". When this happens the issuer will respond to an authorisation request with Authentication required which means they mandate SCA on that transaction. If this happens, and you do not have included executeThreeD set to false in your payment request, we will do a retry for 3D Secure 1 or 3D Secure 2. If you do have executeThreeD set to false the end status of the transaction is refused. 

Please refer to our documentation on 3D Secure authentication and our 3D Secure for regulation compliance guide to learn more.

 

Can I still use my Dynamic 3DS rules with 3D Secure 2?

Yes, Dynamic 3DS can be used with both 3DS2 and 3DS1. Dynamic 3DS is used as a trigger for 3DS on the merchant or the company level as per the requirement of the merchant. After which Adyen's Authentication Engine decides between best routing for 3DS version, this is based on the performance of the particular card BIN on both 3Ds1 and 3Ds2.

Based on the performance the transaction are routed for maximum conversion rate.

 

Setting up my 3DS integration:

How do I implement 3DS to comply with PSD2?

How to implement 3D Secure depends on how you are currently integrated with Adyen. If you are unsure, refer to check which integration you are on.

Next, check if you need to do something to comply with PSD2 following our Integration guide and implement 3D Secure depending on your existing integration. 

 

How is determined if a transaction goes through 3DS1 or 3DS2? 

If your integration is 3DS2 ready, and you are sending along the required fields, it is still possible that a transaction will end up going through 3DS1.

This is the case because not all issuing banks are ready to handle 3DS2 yet, and even if they are, some issuing banks have a worse performance on 3DS2 transactions compared to 3DS1 transactions. To overcome this, our platform observes the performance on 3DS2 transactions and if a better performance is observed for 3DS1 for a specific issuing bank we route the transaction over 3DS1. 

 

How to indicate when to use native 3DS2?

To indicate that you are ready for 3DS2 native, include the allow3DS2 parameter in your payment request and set it to true. This means that we can present the identifyShopper or challengeShopper. If this is not included we will only send redirectShopper in the response.

For more information on 3D Secure indicators refer to our documentation here: 3D Secure indicators

 

Which fields should I send in the payment request for 3D Secure 2? 

To answer this question please refer to our API Explorer where we describe and detail all the different major types of requests that can be done to our endpoints. Depending if you are using a Checkout or Classic integration you can find the right fields to include in your request. Feel free to explore this page for other types of requests. For additional information on the necessary fields please refer to our documentation.

In addition to the regular parameters you provide on your 3D Secure 2 payment request, we recommend that you provide all available information to increase the likelihood of achieving a frictionless flow and a higher authorisation rate.

Updating my 3DS Integration To 3DS 2:

How do I test the different 3DS2 payment flows and response codes?

Different 3DS2 flows can be tested by using different cards for each flow. For example, you can test the web-based flow where the device fingerprint step is skipped, or the frictionless flow in which a fingerprint is performed but no challenge. For the different cards per scenario refer to Test 3D Secure 2 authentication.

 

Can I test 3DS 2 in Live?

For now, the best tools for testing 3D Secure 2 readiness are the Adyen Test environment and the 3D Secure 2 simulator.

In the coming months, you will start seeing transactions with 3D Version 2.x appearing in your transactions list for issuing banks that are ready to offer authentication via 3D Secure 2.

Backoffice.png

We choose these transactions based on optimization criteria such as issuer availability. As the industry progresses in the coming months in the adoption of 3D Secure 2, we will increase the volume that we route through 3D Secure 2.

Once integrated with 3D Secure 1 or 2, no action is required from your side to activate 3D Secure 2. Adyen’s Redirect SCA integration ensures that you are already covered from an integration point of view.

If you're currently not offering 3D Secure, please start integrating now.

 

How do I update my API version to support 3DS2?

The Adyen native 3DS2 integration requires a minimum version of our APIs to work.

If you are using our Checkout API (with or without Secured Fields) you will need to upgrade to at least version 41 (e.g. https://checkout-test.adyen.com/v41/payments).

If you are using our Classic API (with or without client-side encryption) you will need to upgrade to at least version 40 (e.g. https://pal-test.adyen.com/pal/servlet/Payment/v40/authorise).

Our newer API endpoints are backward compatible with older versions of the endpoint, so you can expect all current functionalities you are using to continue to be supported.

 

How does Adyen’s 3DS engine work: 

How is it determined whether 3DS is triggered?

To understand how it is determined whether a transaction goes through 3DS, it is important to know the different factors that influence this. Keep in mind that to ensure you stay compliant, we will always apply 3D Secure if this is required by authentication regulations.

The following factors influence the triggering of 3DS, which are listed in a hierarchal order with the highest priority on top:

  1. The executeThreeD parameter set to true in your payment request. This parameter indicates if you want to perform 3D Secure authentication for a transaction or not.

  2. browserInfo parameter is required in your payment request. Refer to browserInfo for a specification of which fields to include in this object.

  3. Dynamic 3DS
    Lastly, you can use Dynamic 3D Secure to configure rules for applying 3D Secure. You can set rules to either Always use 3D Secure, or Prefer not to use 3D Secure, which will only trigger 3DS if the issuing bank required it to complete the authorisation. This means that if you want to have more control over which transactions are processed with 3D Secure, for example if certain transactions are high-risk for your business, you can use Dynamic 3D Secure, which lets you set up rules to determine which payments are sent for 3D Secure authentication and which you prefer to be processed without. 

For more information on which version of 3D Secure is triggered and when, refer to How is it determined which 3DS version is used, 3DS1 or 3DS2?

 

How is it determined which 3D Secure version is used, 3D Secure 1 or 3D Secure 2?

To understand which 3D Secure version is used for a transaction, it is important to know the different factors that influence the routing decision. The following factors influence the routing, which are listed in a hierarchal order with the highest priority on top: 

  1. Authentication Engine
    Our authentication engine decides on the 3D Secure version, exemptions and automatically retries where possible. In more detail, it routes the transaction following these rules:
    1. Checks if the card is enrolled - If the card is not enrolled for 3D Secure 2, we automatically route the transaction via 3D Secure 1.
    2. Checks if the BIN is performing well - If the card is enrolled for 3DS2, but our authentication engine records unacceptable low conversion for that BIN, we route the transaction via 3D Secure 1.

  2. Fallback policy: if the card is enrolled for 3D Secure 2 and the authentication could not be performed due to a technical glitch, by default we fall back to
    1. Direct refusal for 3D offered responses (transStatus): N: Not Authenticated or R: Authentication/ Account Verification Rejected. 
    2. Direct authorisation for the other 3D offered responses, that you can find in our Raw 3D Secure responses docs.

  3. Parameters in the API request
    Include the threeDSVersion parameter in your payment request to indicate you want to use 3D Secure 2. We do not recommend using this field in the API request unless you are aware of the cardBin performance between 3DS1 vs 3DS2.

  4. 3DS1 deprecation and 3DS2 migration
    Schemes are enacting 3DS1 deprecation and 3DS2 migration strategies in some regions and expect Adyen to comply, which can impact the routing decision. Please refer here and here for further information. 

For more information on how 3D Secure is triggered in general, refer to How is it determined whether 3DS is triggered?

 

3DS with recurring transactions: 

Can I use 3DS with recurring transactions?

For Subscription and UnscheduledCardOnFile transactions, the shopper is not present, and therefore the shopper cannot complete the additional authentication layer. This means that for these type of transactions 3DS is not possible, and a liability shift cannot occur. 

 

How does 3DS work for tokenization / recurring payments?

For CardOnFile recurring payments, where the shopper is present, it is possible to use 3DS. 

For Customer Initiated Transactions (CIT) that are in scope SCA is required, therefore these transactions will go through 3DS. For Merchant Initiated Transactions (MIT) SCA is not required (but instead verified in the background via the networkTxReference). For the different tokenization type of payments this means:

  • One-off payments - CardOnFile - CIT so will go through 3DS
  • Subscriptions - Subscription - MIT so will not go through 3DS
  • Automatic top ups and other non-fixed schedule contracts - MIT so will not go through 3DS

At the time of the CIT a networkTxReference is generated that points to the initially authenticated transaction. In MIT this token is then used to verify the authentication. If a merchant is tokenizing with us, we will store and handle the networkTxReference for them.

 

CIT_MIT_Sheet.png

 

Was this article helpful?
0 out of 0 found this helpful