Debugging specific 3DS transactions: 

Index: 

 

 

Finding My 3DS payment: 

There are two stages to an authenticated payment. The authentication phase and the authorization phase. If you are not seeing your payment in the Payments section under Transactions it’s likely that the payment was not fully authenticated and it’s still considered an Offer. For a better understanding of the difference between an Offer and a Payment please refer to this page.

 

To see if this is the case, try checking the PSP under the Offer section see image below: 

Offers.png

 

Understanding The 3DS payment: 

It is always recommended to view the 3DS panel on the payment page for understanding what is happening for any given transaction.

 

You can see an example of this panel below: 

3DS_Panel.png

From this panel generally only these 4 fields are needed for understanding what occurred with this transactions: 3DS requested, 3DS challenged, TransStatus, TransStatusReason

 

3DS requested 

These statuses indicate whether the card is enrolled in the 3D Secure program and if 3D Secure was offered. You can see a list of values here.

 

3DS challenged 

These statuses explain the result of the authentication process. You can see a list of values here.

 

TransStatus 

This indicates whether a transaction was authenticated, or whether additional verification is required. You can see a full list of values here.

 

TransStatusReason 

This is the reason code the bank gave as to why they are declining the authentication. You can see a list of the codes here.

 

Adyen error codes vs scheme or issuer codes:  

Response and error codes can come from Adyen or the schemes (Visa, Mastercard, WeChatPay etc.), or the customer's bank. It's important to distinguish where the code is coming from in order to best resolve the issue for the customer. 

 

TransStatus and TransStatusReasons Responses: 

TransStatusReason: 01 

This refers to “Card authentication failed.” What this means is that the bank is declaring the customer’s password to be incorrect. Generally this is resolved by having the customer reset their password with the bank. 

 

TransStatusReason: 06 

This refers "Invalid card number." This is generally fixed by having the customer try a different card or by updating their card in your system. 

 

TransStatusReason: 11

This refers to “Suspected fraud.” This means the bank is flagging the customer’s behavior as being suspicious. Generally the fastest way to resolve this is to have the customer contact their bank to resolve the flags. 

 

TransStatusReason: 14

​​This refers to “Transactions timed out at ACS.” The ACS is the bank's server and can be down temporarily from time to time. If this is the case the customer can retry the transaction again at a later time to pay. If this is a chronic or systemic issue it may be the case that there is an integration issue occurring that is causing the timeout and will have to be debugged as such. 

 

TransStatus: A : Attempted to Authenticate without a challenge: 

transStatus: A is an authentication response from the schemes (Mastercard, Visa) to inform the merchant that this transaction attempted Authentication however, at this stage the issuer was not ready or able to perform a strongAuthentication (ie. OTP/Password). Such transactions, when the schemes step in, do come with a successful liability shift.

 

What does "Invalid paRes from issuer" mean?

While trying a 3DS transaction, you may receive an API response with errorCode 105:

{
  "status":422,
  "errorCode":"105",
  "message":"Invalid paRes from issuer",
  "errorType":"validation"
}

You can see possible causes of this error in our errors documentation

  • Cause: The issuer returns an URL-encoded PaRes or MD.
  • Solution: URL-decode the PaRes and MD before submitting them in the /payments/details request.
  • Cause: The issuer returns the correct PaRes value, but the parameter name is different from PaRes, for example PaResponse or paRes.
  • Solution: Adyen only accepts this parameter as PaRes. If the issuer has returned something different, make sure that you change it to PaRes before submitting it in the /payments/details request.
  • Cause: The PaRes parameter is empty, or some other reason different from the above.
  • Solution: Ask your shopper to contact the issuing bank to report the error.

If you have checked the above link and ruled out any configuration mistakes in your integration, the issue lies with the cardholder's issuing bank.

If the error happens continuously, the shopper will need to contact their issuing bank.

 

Adyen Error Codes: 

"No form POST data"

The given message (Warnings / Errors: No form POST data.) will be displayed on your checkout page when the expected fields (MD and PaReq) were not received in the 3D authentication page. Please ensure you have followed the correct documentation link.

 

"3DS2 integration error, subsequent request received in different data region than the region that initiated the 3DS2 transaction"

This error code refers to using 2 endpoints from different regions.

As an example, making the initial /payments call with an AU endpoint and the subsequent /details call with an EU endpoint. 

To resolve this please check your API URLs in customer area by going to Customer Area >> Developers >> API URLs and make sure your integration is making these calls from the same region. 

 

Errorcode 701 with HTTP status 500 mean?

The 701 error with HTTP status 500 means the requestURL or header information is not valid. The following Checks should occur:

  • check the endpoint you are sending this request to.
  • check if the header Content-Type is correct.
  • check if this can occur if you are trying to do a 3DS2 transaction and the endpoint version you are pointing to doesn't support 3DS2 yet. 

How to solve this depends on your integration:

Note that you will already be able to support 3DS2 if you are able to support redirect-based authentication. Take a look at our 3D Secure authentication documentation for guidance on this!

 

Why are my transactions soft declined 

Why do I get an "Authentication required" response?

The AUTHENTICATION_REQUIRED response means the issuer mandates a strong customer authentication (SCA). This refusal is considered a soft decline. In case you are confronted with soft declines for the first time, you have to make sure your integration is able to handle 3D Secure. If you are still unfamiliar with PSD2 and 3D Secure, please find more information about what you need to do here: 3D Secure for regulation compliance and PSD2 SCA compliance guide.  

Currently the soft declines are present for Visa, Mastercard, American Express, Diners and Dankort with the errors and messages below: 

  • 1A : Authentication Required (Visa)
  • 65 : Authentication Required (Mastercard)
  • 130 : Authentication Required (American Express)
  • 103 - Customer Authentication Required (Diners)
  • 132  - Authentication required (Dankort)

If this happens, and your integration supports 3D Secure, we automatically retry the transaction on 3DS1 or 3DS2, unless you have specifically included the parameter executeThreeD set to false in the payment request.

 

Unauthenticated tokens 

One example of Authentication required refusal, is due to the initial payment not going through 3DS authentication. If your transaction is in scope of PSD2 regulations, it is required that the initial recurring payment is authenticated with 3DS2. If this is the case for your transaction, the payment information will have to be re-tokenized with strong customer authentication (SCA).  

 

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