Dynamic 3D Secure

Set up rules to determine whether an eligible card payment should use  3D Secure authentication. 

Dynamic 3D Secure is not enabled by default, as it requires additional configuration on Adyen's end. Contact the Support Team to request enabling it for you.

When Dynamic 3D Secure is enabled, payments sent to the /authorise endpoint with browserInfo go through Dynamic 3D Secure rules. If a rule determines that 3D Secure should be used, the shopper is redirected for 3D Secure authentication. For information on setting up 3D Secure, see 3D Secure.

To mitigate any effects on conversion, you can configure these rules to determine which payments are sent for 3D Secure authentication, and which are processed without. 

Configuring Dynamic 3D Secure rules

If no Dynamic 3D Secure rules have been defined, all transactions will go through an /authorise3d call. By controlling when browserInfo is sent, you can maintain a 3D Secure routing logic.

To configure the rules, go to Customer Area > Risk > Dynamic 3D Secure.

You can configure the following criteria. These can also be combined to create nested rules. For example, you may decide to use 3D Secure for every transaction where the issuing card is from Mexico, has a risk score greater than 70, and a transaction value above $100. 



Issuer country

The country where the card was issued.

Shopper Country

The country of the shopper, based on the IP address submitted with the payment.

Payment Method

The card type (for example, Amex, Visa Platinum, etc. For more information, see PaymentMethodVariant).

Device Type

The type of device that submitted the transaction. You can indicate mobile, desktop, or tablet devices.

The transaction must have device data submitted with it for this feature to work.


The transaction value. When you configure this for a specific currency, the rule will automatically convert to other currencies. For example, a 20 EUR rule will automatically trigger for the equivalent amount in GBP.

Risk Score

Allows the targeting of 3D Secure for only transactions that meet certain risk score thresholds.

If a transaction's risk score is 100 or more, it is always rejected by RevenueProtect and, thus, will not use 3D Secure.

BIN and BIN Range

The first six digits on a credit card. This identifies the Issuing bank of the card. For more information, read Bank Identification Number (BIN).

You can target a set or range of BINs, to use 3D Secure only for transactions from certain issuing banks.

Risk Check Trigger Specific risk checks that trigger 3D Secure. By default, this only applies to payments with a fraud score between 1 and 100. Select Trigger on TRUST risk result to enable this for payments with a score 0 or below.

For each condition met, assign actions to use or drop 3D Secure authentication:

  • Use 3DS - If the condition is met, choose to apply 3D Secure Always or Never.
  • Drop 3DS - If the condition is met, choose to Never drop 3D Secure authentication or drop 3DS depending on the transaction status:
    • If 3DS directory lookup response U: Drop 3D Secure when authentication is unavailable.
    • If 3DS authentication response N: Drop 3D Secure when authentication has been denied.
    • If 3DS authentication response U: Drop 3D Secure when the card issuer is unavailable.

A few things to keep in mind when configuring Dynamic 3D Secure:

  • Rules are maintained at the merchant level. They will only effect payments for a specific merchant.

  • System-wide rules (for example, that all Maestro payments must use 3D Secure) will override the Dynamic 3D Secure rules.

  • Wherever possible, create several simple rules instead of combining many logic points into a single rule.

  • The sub-components of the rules must comprise an AND statement. If you want to use an OR statement, create a new rule.

  • Rules trigger in order, from first to last.

  • If no rules are triggered, a 3D Secure-enabled transaction will use 3D Secure.

BIN Groups

We provide and maintain 4 Dynamic 3DS BIN groups that allow you to categorize BINs based on patterns in PSP-wide data:

  • 3DS Mandated - Transactions without 3DS are frequently refused.
  • Issuer Not Enrolled - 3DS Authentication possible without shopper redirect (“Passive” 3DS & free liability shift).
  • Low Friction - BINs with user friendly 3DS flows: Low drop off rates and favorable auth rates.
  • High Friction - BINs with poor 3DS flows: High drop off rates and unfavorable auth rates.

We recommend enabling 3DS Mandated, Issuer Not Enrolled and Low Friction BINs with an "ALWAYS" rule, and High Friction BINs with a "NEVER" rule.

Rule configuration examples

Scenario 1

You are experiencing significant fraud in transactions above $200 in the U.S. and €250 in Germany. You decide to focus on high-risk transactions in these regions, but not use 3D Secure for other trustworthy transactions.

The rules you should set up are:

  1. ALWAYS use 3D Secure when transaction >= $200 AND risk score >50 AND issuing country = United States.

  2. ALWAYS use 3D Secure when transaction >= €250 AND risk score >50 AND issuing country = Germany.

  3. NEVER use 3D Secure.

The use of a NEVER rule should always be the last rule. This rule catches any scenarios that don’t match rule 1 and 2, and do not use 3D Secure.

Scenario 2

You are planning on expanding your business in the United States. You have previously used 3D Secure in the U.K. (where conversion rates are high), and you want to avoid using 3D Secure in the United States. All your traffic is from the U.K. and U.S.

Rules you should set up:

  1. NEVER use 3D Secure when issuing country = United States

Only a NEVER rule is needed since the default action is for transactions to use 3D Secure. With this setup, all U.K. transactions will use 3D Secure.