How is it determined whether 3DS is triggered?

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:

  1. The executeThreeD parameter set to true in your payment request. This parameter indicates if you want to perform 3D Secure authentication for a transaction or not. 

  2. Transaction rules
    These are set by our Technical Support team and overwrite the Dynamic 3DS & Authentication Engine. This is not recommended.

  3. The browserInfo parameter in your payment request. This triggers our dynamic 3DS rule-set. This parameter is required for channel web. Refer to browserInfo for a specification of which fields to include in this object.

  4. 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 is 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 How is it determined which 3DS version is used, 3DS1 or 3DS2?

Was this article helpful?
0 out of 0 found this helpful