Debugging Specific 3DS Error Codes



Understanding Adyen error and response 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. 

For Adyen error and response codes it's best to work directly with Adyen. These are commonly occur as integration or API issues.   

For other error and response codes, there will be cases where we have insight into the problem. However, schemes and banks are separate from Adyen we do not always have complete information and therefore can't definitely know why these things happen.

An example would be a bank returning 05: Do Not Honor. This is a generic error code that does not give much more information as to what problem occurred during the transaction. If this is the case, it's usually best to have the customer reach out to their bank to get more information. 



Acquirer Responses: 

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.


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: 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:

  "message":"Invalid paRes from issuer",

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

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.


When debugging problems it’s best to check the TransStatusReason code first. This will provide the most amount of information. 


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!




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