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 hierarchal 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.
- Our support team can overwrite the default fallback policy for your merchant account to either fall back to 3D Secure 1, authorise or refuse.
- Parameters in the API request
threeDSVersionparameter in your payment request to indicate you want to use 3D Secure 2. The current supported version is 2.1.0. Refer to mpiData - threeDSVersion for more information.
For more information on how 3D Secure is triggered in general, refer to How is it determined whether 3DS is triggered?