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 3DS 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 3DS2, we automatically route the transaction via 3DS1.
- 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 3DS1.
- Fallback policy: if the card is enrolled for 3DS2 and the authentication could not be performed due to a technical glitch, by default we fall back to direct authorisation and don't continue with authentication. Note that this will soon be changed to default to direct refusal. Our support team can overwrite the default fallback policy for your merchant account to either fall back to 3DS1, 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?