When you support 3D Secure 2 in your website or mobile app, and send in a payment request, 3D Secure authentication can be triggered for the transaction.
To ensure that you stay compliant, we always authenticate transactions with 3D Secure if this is required by regulations such as PSD2 or other market specific regulations. To mitigate any effects on conversion, we do not trigger 3D Secure for out-of-scope transactions, or when the issuing bank does not enforce 3D Secure. For transactions within the scope of PSD2, we also handle requesting exemptions.
You can use Dynamic 3D Secure as well as parameters in your payment request to make sure 3D Secure is requested and, in special cases, to request a 3D Secure challenge. You can do this even if 3D Secure is not required by regulations or the issuer. This can be useful, for example, to make sure a liability shift takes place or to add more friction for high-risk transactions.
How it works
You can specify your 3D Secure preferences using Dynamic 3D Secure as follows:
- Use the default rule as the setting to indicate your general preference to request 3D Secure. You can set this to Prefer not or Always. When set to Prefer not, Adyen can still decide to send the payment through 3D Secure because the issuer requires it, to ensure compliance with regulations, or to improve conversion. When set to Always, we will always request 3D Secure on your behalf.
- Create more specific Dynamic 3D Secure rules. You can set conditions to determine for which payments to request 3D Secure authentication, and if you prefer to request a 3D Secure challenge.
Request 3D Secure
When you proactively request 3D Secure using Dynamic 3D Secure rules, you add an extra authentication layer to the payment flow. The transaction either goes through the challenge flow or the frictionless flow depending on the issuer.
This can reduce the risk of fraud because a transaction with a successful 3D Secure authentication will result in a liability shift. This way, you can use Dynamic 3D Secure rules to mitigate the risk for certain transactions.
It is important to understand that there is a trade-off. By requesting 3D Secure, you add friction. This friction impacts conversion because some shoppers might drop off. However, at the same time, if the authentication is successful, you reduce fraud and obtain a liability shift.
Request a challenge
Using Dynamic 3D Secure rules, you can set your preference to present a challenge even if the frictionless flow is available. Both a successful challenge flow and a successful frictionless flow result in a liability shift. By default, to optimize conversion, a transaction will use the frictionless flow if it is available.
Requesting a challenge is a way to add more friction because it requires additional shopper interaction. We recommend that you only set your preference to always request a 3D Secure challenge in special circumstances. This because the challenge adds significant friction and could lead to a higher shopper drop-off rate. Use it, for example, when you are experiencing extremely high fraud rates and requesting 3D Secure alone does not help.
Override using the payment request
Instead of using Dynamic 3D Secure, you can include parameters in your payment request directly to influence when to use 3D Secure, and if it is, if the shopper should be challenged.
Parameters sent in the payment request override any Dynamic 3D Secure rules that you have configured.
Include the following fields in the payment request to:
- Request 3D Secure authentication: authenticationData.attemptAuthentication.
For Checkout API v68 and earlier, use executeThreeD. - Present a challenge: threeDS2RequestData.threeDSRequestorChallengeInd. This parameter will only be used if 3D Secure is requested.
For Checkout API v67 or earlier, use threeDS2RequestData.challengeIndicator.
Configure the default 3D Secure rule
When you create a new company account or merchant account, the default rule is set to Prefer not.
Choose from the following possible settings:
- Always: Use 3D Secure whenever possible. With this rule, there will still be transactions that do not go through 3D Secure authentication, for example, when the issuer doesn't support 3D Secure yet, or when the card isn't enrolled.
- Prefer not: Do not apply 3D Secure authentication unless it is required by regulation or the issuer, or if it can help optimize performance.
Configure Dynamic 3D Secure rules
To be able to add or change the Dynamic 3D Secure rules, you need to have the following roles:
- Merchant change risk settings
- Management Dynamic 3D Secure Rules
There are few things to keep in mind when configuring Dynamic 3D Secure rules:
- Rules trigger in order, from first to last.
- You can configure rules on the company account, or on a merchant account. Rules configured on the merchant account have priority and only affect payments for that specific merchant account.
- Wherever possible, create several simple rules instead of combining many logic points into a single rule.
- Consider each separate condition that you specify within the rule as an AND statement. The rule will trigger if both conditions are met. However, when you select multiple values within a condition, the rule will trigger when any of these values are true.
To configure the rules:
-
Go to Customer Area > Revenue & risk > Dynamic 3D Secure.
-
Select Create new rule to make a new rule or select the name of the rule if you want to modify an existing rule.
-
Configure the criteria shown in the next table.
You can combine criteria 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 USD 100.
Criteria
Description
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, American Express, 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.Amount
The transaction value. When you configure this for a specific currency, the rule will automatically convert to other currencies. For example, a EUR 20 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 pre-authorisation fraud score is 100 or more, the transaction is refused with the refusal reason FRAUD 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
Each risk rule that you select will trigger 3D Secure. Only select risk rules that trigger before authorization.
By default, this only applies if the rule has a positive fraud score. If you also want rules with a negative fraud score to trigger 3D Secure, check the Trigger on TRUST risk result checkbox. -
For each condition met, assign actions to request 3D Secure authentication, and your preference to present a challenge:
- Request 3DS: If the condition is met, choose to apply any of the default 3D Secure rules (Prefer not or Always).
- Request challenge: If you set up a rule where Request 3DS is set to Always, you also have the option to set your preference to request a challenge (Prefer not or Always).
Setting request challenge to Always adds friction and can impact conversion negatively. We recommend to use this in special circumstances only.
-
When you have created your rule, add a name for the rule and select Save. If you have updated an existing rule, also select Save.
-
3D Secure rules are applied in the order listed. Move the most important rule to the top of the list, order the rest of the rules in the order that you want them to be applied in, and select Save.
Example scenarios
The following scenarios are some fictional examples to illustrate how you could set up Dynamic 3D Secure rules. You can create your own rules that follow your specific business needs and logic.
Scenario 1
You are planning on expanding your business in Canada. You have previously used 3D Secure in the UK (where conversion rates are high), and you want to avoid using 3D Secure in Canada. All your traffic is from the UK and Canada.
Rules you should set up:
- Dynamic 3D Secure rule: When the issuer country is Canada, then Prefer not to request 3D Secure.
- Default 3D Secure rule: Always request 3D Secure for all other transactions.
Only a Prefer not rule is needed since the default action is for transactions to use 3D Secure. With this setup, all UK transactions will use 3D Secure.
Scenario 2
You are experiencing significant fraud in transactions above USD 200 in the US. You want an extra layer of authentication for these payments and a liability shift.
Rules you should set up:
- Dynamic 3D Secure rule: When the amount is greater than USD 200 AND the issuer country is United States, then Always request 3D Secure and Prefer not to request challenge.
- Default 3D Secure rule: Prefer not to request 3D Secure authentication for all other transactions.
Scenario 3
After you have implemented the rule mentioned in scenario 2, you are still experiencing significant fraud in transactions above USD 200 in the US.
One of the card schemes reached out to you that the number of Notifications of Fraud is becoming too high. As an emergency measure, you want to make sure that you always trigger a 3D Secure challenge to increase friction.
Rules you should set up:
- Dynamic 3D Secure rule: When the amount is greater than USD 200 AND the issuer country is United States, then Always request 3D Secure and Always request challenge.
Setting request challenge to Always adds friction and can impact conversion negatively. We recommend to use this in special circumstances only.
- Default 3D Secure rule: Prefer not to request 3D Secure authentication for all other transactions.