Debugging 3DS Integration Issues

Index: 

 

Common 3DS Integration Question: 

Is my integration using 3D Secure?

The quickest way to check in the Customer Area if you use 3D Secure is to log in to your account and navigate to Transactions > Payments.

 

From the Payments page, use the configuration wheel on the right side of the column headers 

mceclip1.png

to add the additional columns: 

  • 3D authenticated;
  • 3D offered; 
  • Liability indicator.

You are using 3D Secure if the Payments page looks like: 

mceclip1.png

with some transactions with a check under Liability indicator and letters under 3D offered and 3D authenticated. Please refer to our Raw 3D Secure responses docs to understand the meaning of those letters.

 

You are probably not using 3D Secure if the Payments page looks like :

mceclip0.png

with a cross under Liability indicator and no letter under 3D offered and 3D authenticated. 

 


Do I have to integrate 3DS2 if I have a working 3DS1 integration?

If you are using our Checkout SDKs, HPP, Plugins, or APIs with 3D Secure 1 integration, you are already PSD2 SCA-compliant and you don't need to do anything. You can also already support 3D Secure 2 through the same redirect authentication.

We also have existing solutions to support 3D Secure 2 authentication natively within your app or payment form. This will enable a frictionless flow in which the acquirer, issuer, and card scheme exchange all necessary information in the background through passive authentication using the shopper's device fingerprint. The transaction is completed without further shopper interaction. If you decide to implement native 3D Secure 2 authentication in addition to your 3D Secure 1 integration, refer to our 3D Secure implementation options.

 

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.

 

Debugging Common Integration Issues:

Why are my 3DS payments not being completed?

Most of the issues we see in 3D Secure payments that are not being completed happen during the redirection from the (issuers) 3D authentication page back your website. When payments are processed using 3D Secure 1 authentication, shoppers are redirected to the issuing bank webpage to process with the authentication. During this type of payments, you need to make 2 requests to our endpoints in order to complete the payment flow. During the first request, you will provide the clients card detail information and in the second, the 3D authentication information.

  • In case of integrating with Classic API the calls will be:
  • In case of integrating with Checkout API v66 and below the calls will be:

At the points where the redirection from the issuers 3D authentication page back to your website, Adyen does not have visibility on the way the bank is providing the expected parameters (MD and PaRes) back to the merchants webstore, as this is outside of our network logging system. The expected fields should be passed on using a HTTP POST message to the returnUrl / TermUrl but sometimes this is not the case.

In order to help with the troubleshooting, please double check:

  • After the redirection from the bank to the webstore, are you receiving the MD and PaRes fields? Are they coming with HTTP POST or HTTP GET?
  • For those uncompleted payments, are you managing the second call to Adyen? What is the raw response you are getting from us?

In case of integrating with Checkout API v67 and above, the above is not applicable, so please refer to our release notes for further information on the updated 3D Secure flow. 

 

In addition to this, in case this is the issuer bank is not providing the parameters due to technical issues on their side, you can always adjust the 3D requirements on Adyen side by making use of the Dynamic 3D Secure tool explained in our documentation here: Dynamic 3D Secure.

 

Why is my transaction not going through 3DS2?

If the transaction you are trying to do is not going through 3DS2, and you are not getting back the 3DS2 specific resultCodes, this is probably because one of the required fields for 3DS 2 is not sent along in the payment request. 

Please refer to our documentation 3D Secure authentication to for a detailed explanation on which fields to include to initiate a 3DS2.0 transaction: Checkout API or Classic API.

 

How do I implement 3D Secure using redirect?

To complete a card payment with 3D Secure authentication, the shopper needs to verify the payment with their bank. For 3D Secure 1, this usually involves entering a unique password or SMS code on their bank's website. For 3D Secure 2, the shopper's identity may be verified using passive, biometric, or a two-factor authentication approach.

A detailed explanation on how to implement 3D Secure using redirect authentication can be found here: 3D Secure 1 and 2 redirect authentication


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