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

  1. 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:
    1. 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.
    2. 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.

  2. 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
    1. Direct refusal for 3D offered responses (transStatus): N: Not Authenticated or R: Authentication/ Account Verification Rejected. 
    2. Direct authorisation for the other 3D offered responses, that you can find in our Raw 3D Secure responses docs.
  3. Our support team can overwrite the default fallback policy for your merchant account to either fall back to 3D Secure 1, authorise or refuse.

  4. Parameters in the API request
    Include the threeDSVersion parameter 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?

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