How is it determined whether 3DS is triggered?
Factors for 3D Secure in hierarchical order
To understand how it is determined whether a transaction goes through 3DS, it is important to know the different factors that influence this. Keep in mind that to ensure you stay compliant, we will always apply 3D Secure if this is required by authentication regulations.
The following factors influence the triggering of 3DS, which are listed in a hierarchal order with the highest priority on top:
- If you are using any version before 69, the executeThreeD parameter set to true in your payment request indicates if you want to perform 3D Secure authentication for a transaction or not. If you are using a version from 69 onwards, the authenticationData.attemptAuthentication parameter set to true in your payment request indicates whether you want to perform 3D Secure authentication for a transaction.
- browserInfo parameter is required in your payment request. Refer to browserInfo for a specification of which fields to include in this object.
- Dynamic 3DS
Lastly, you can use Dynamic 3D Secure to configure rules for applying 3D Secure. You can set rules to either Always use 3D Secure, or Prefer not to use 3D Secure, which will only trigger 3DS if the issuing bank required it to complete the authorisation. This means that if you want to have more control over which transactions are processed with 3D Secure, for example if certain transactions are high-risk for your business, you can use Dynamic 3D Secure, which lets you set up rules to determine which payments are sent for 3D Secure authentication and which you prefer to be processed without.
For more information on which version of 3D Secure is triggered and when, refer to this article.
Was this article helpful?
The PSD2 SCA compliance guide
Be ready to apply strong customer authentication to your transactions.View PSD2 compliance guide