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 hierarchical order with the highest priority on top:

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:

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

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

Direct refusal for 3D offered responses (transStatus): N: Not Authenticated or R: Authentication/ Account Verification Rejected.
Direct authorisation for the other 3D offered responses, that you can find in our Raw 3D Secure responses docs.

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.

For more information on how 3D Secure is triggered in general, refer to this article.