Index:
- Seeing 3DS trends in the payment lifecycle report
- Seeing 3DS trends with Authentication and Conversion report
- Specific Bank Failures - Seeing An Increase In "Authentication Required" For Specific Banks
- Strong Customer Authentication for recurring traffic
Seeing 3DS trends in the payment lifecycle report
The fastest way to understand and start to diagnose your 3DS authorization rates is with the Payment lifecycle page in your Adyen portal. Go to >> insights >> payment lifecycle:
You can now see Initiated Transactions, Failed Authentications, Authentications, Authorized, Full Funnel Conversion.
The Full Funnel Conversion indicates the success rate after 3DS drop offs and successful authorizations.
Some of the fields you can filter include payment methods, country, and shopper interaction. These filters can be used to see general trends with 3DS authorization rate.
An example of this would be seeing a soft decline on a specific transaction and then filtering by that transaction’s country to see if there is a broader trend in that country.
Seeing 3DS trends with Authentication and Conversion report
The Authentication report and the Conversion report report can be used for seeing trends. .
Conversion report:
The conversion rate report can be used to see potential issues with your integration. For example, low conversion rates are often indicative of potential issues with your integration.
This would be indicated by seeing threed_directory_response but no threed_authentication_response.
Authentication report:
The authentication report can be used for spotting potential broader issues that are happening with your account and 3DS.
The two most commonly used fields for diagnoses are raw_acquirer_response and trans_status_reason. The raw_acquirer_response can be used to see increased in soft declines while increases in specific numbers of trans_status_reason can indicate a broader problem happening in the account. To see what each trans_status_reason indicates you can view that here.
The authentication report can also be used to see transactions that went through Sca_retry and
Sca_retry: The authorization failed and the transaction is immediately retried with 3DS
Threeds2_fallback: The 3DS failed and the transaction is immediately retried with an authorization
Common Scenarios and How To Deal With Them:
Specific Bank Failures - Seeing An Increase In "Authentication Required" For Specific Banks
There are scenarios where a merchant may see an uptick of Authentication Required for a specific bank or specific region on their Adyen account. Currently PSD2 standards are in a transitional period. What this means is that there are times when a bank will switch from SCA not required to SCA required.
Adyen’s authentication engine does A/B test traffic to determine if the traffic would perform better if it went through authentication or not. However, if a bank switches from SCA not required to SCA required it is possible there can be a small bit of lag time before the engine has identified this traffic to be required.
This can happen with tokenization as well where a bank previously did not require the traffic to be authenticated and is now requiring it to be authenticated. The token will now be soft declined if it was initially authenticated when being tokenized. Note: This can be true even for MIT transactions or shopper not present transactions. See tokenization.
If this is indeed the case the merchant can add the specific affected BINs or, if this is happening more broadly, the merchant can add the issuer region to the Dynamic 3DS rules and set the 3DS preference to “Always”.
Strong Customer Authentication for recurring traffic
Initially enacted in the UK region region on March 16th regulation, some issuers started enforcing the challenge flow or SCA on initial recurring traffic. As a result, there has been an increase in "Authentication Required" and "Invalid transaction" responses for certain banks.
One such example: 
