Product
13
READING TIME
3D Secure: what it is, how it works, and prevents fraud
Table of contents
What is 3D Secure?
3D Secure (also called 3DS) is an authentication protocol that adds a layer of security to online card payments. Its purpose is to confirm that the person making the purchase is actually the cardholder, helping to prevent fraud.
It is called 3D because three domains are involved in the authentication process (the 3-Domain model):
Acquirer domain (the acquirer is the bank or payment provider that supplies the virtual POS).
Issuer domain (the bank that issued the card).
Interoperability domain (the card scheme, for example Visa or Mastercard).
During a payment, these three actors exchange information to decide whether the transaction must be authenticated and how to do it.
If 3D Secure is triggered, the issuing bank will request proof of identity from the buyer. This may be a one-time code sent by SMS, a validation request in the bank’s app, or biometric authentication.
In this way, an additional security step is added to ensure that the person making the purchase is the legitimate cardholder.
In short, 3DS is a protocol that, when triggered, asks the buyer to complete an additional authentication step, such as entering a code received by SMS or approving the payment in their banking app (and not just entering the card number and CVV at checkout).
It is important to note that 3DS also has a frictionless flow, where no additional action is required from the user. Based on factors such as the device or type of purchase, the system can determine with a high level of confidence that the user is legitimate. We will cover this in more detail below.
Benefits of using 3D Secure
3DS offers several advantages for both merchants and buyers.
Benefits for merchants:
Fraud reduction.
By requiring authentication at the time of payment, the likelihood that a stolen card is used decreases significantly.Fewer chargebacks.
Because the transaction was completed using 3D Secure, it is assumed that the legitimate cardholder authorized the payment. This allows the liability shift to apply, meaning responsibility for certain fraud cases transfers from the merchant to the issuing bank.Regulatory compliance.
When 3DS is used, the merchant complies with Strong Customer Authentication requirements under PSD2.
Benefits for buyers:
Greater protection against fraudulent card use.
Cardholders know that even if someone has their card details, they will not be able to complete the payment without access to the required authentication method (for example, an SMS or mobile notification).
How does 3D Secure work in a transaction?
3D Secure is triggered midway through the payment process, after the buyer has entered their card details on the checkout page and before the issuing bank authorizes the transaction.
This is the process for a payment through Zru:
The buyer enters their card details and CVV on the checkout page (the checkout page belongs to the Zru environment).
Zru sends the card and transaction data to the processor used by the merchant (Redsys, Stripe, Adyen, dLocal, etc.).
The processor decides whether 3D Secure is required, based on predefined variables and rules (payment amount, merchant profile, etc.).
In some cases, the processor does not initiate 3DS, but once the transaction is sent to the issuing bank, the bank itself may determine that the fraud risk is high and require 3DS authentication.
If 3DS is triggered, two scenarios are possible:
a. 3DS Frictionless: authentication happens in the background. The issuing bank receives contextual information about the transaction, analyzes it, and allows the payment to continue without showing any additional step to the buyer.
b. 3DS Challenge: the buyer must complete authentication and prove they are the cardholder.If there is a challenge, the buyer authenticates using one of the following methods, depending on the bank:
a. Approval in the banking app
b. Biometric authentication (fingerprint or Face ID)
c. A one-time password (OTP) sent via SMS or another channelThe payment continues: once authentication is completed, the issuing bank moves to the authorization phase, approving or declining the payment based on funds, limits, fraud risk, etc.
Why there is sometimes no challenge and a frictionless 3DS is performed
This can be surprising, as many people associate 3D Secure with a bank verification request. However, there are cases where 3DS is performed without showing a challenge.
To decide this, the issuing bank performs a risk assessment. Variables such as the transaction amount, customer history, purchasing behavior, device, country, merchant category, or common fraud patterns are taken into account.
If the bank considers the transaction to be low risk, it may allow it to proceed through a frictionless flow.
3DS1 and 3DS2: differences
Since Visa launched 3D Secure in 2001, the protocol has evolved to adapt to new regulatory requirements, technological improvements, and changes in consumer behavior.
3DS1: the beginning
Visa introduced the first version of 3D Secure in 2001 under the name Verified by Visa. Other schemes such as Mastercard and American Express later followed.
It was a major step forward in combating online fraud. However, as ecommerce grew and transaction volumes increased, several limitations emerged: additional steps in the checkout process causing friction and user frustration, poor user experience, static passwords that customers often forgot, etc.
3DS2: a more integrated model
Version 2 of the protocol was published in 2016, but its widespread adoption in Europe began in 2019, driven by PSD2 and Strong Customer Authentication requirements, which came into force in 2021.
Key improvements introduced by 3DS2 include:
Optimized user experience, as authentication no longer requires redirection to external pages, which can improve conversion.
Dynamic authentication, eliminating the need for customers to remember static passwords, with banks using app notifications or SMS instead.
Frictionless flow, where many low-risk transactions are approved without any additional action from the buyer. For example, low-value payments or recurring payments after an initial authentication may not require a challenge.
Increased security, as it complies with PSD2 in Europe.
What to consider to maintain good conversion with 3D Secure
Metrics to monitor
As we have seen, using 3D Secure is important for regulatory compliance in Europe, reducing fraud risk, and limiting chargebacks.
However, adding an extra step to the checkout flow can affect conversion rates.
For this reason, merchants should measure the impact of 3DS and monitor key metrics such as:
Challenge rate: the percentage of transactions that require visible authentication.
Challenge abandonment rate: the percentage of users who do not complete authentication.
Authorization rate after authentication: the percentage of authenticated payments that are ultimately approved.
Comparison between frictionless and challenge flows and their real impact on conversion.
Reviewing authentication failure types (for example, Zru error codes) to understand whether the customer did not complete authentication, left the screen, or the authentication itself failed.
Cases where 3D Secure may be deactivated
Although it is generally recommended to use 3D Secure to protect against fraud, there may be exceptions where it is possible not to activate it.
First, in order for the processor not to trigger 3DS, the merchant must request this from the acquiring bank (the one providing the virtual POS), and the acquirer has the final decision.
Additionally, even if the acquiring bank approves transactions without 3DS, the issuing bank always has the final say. If it considers the transaction high risk, it will not allow it to proceed without authentication.
It is important to consider that disabling 3DS may increase fraud and chargebacks, so each case must be evaluated carefully.
Some scenarios where merchants may consider not activating 3DS include:
Low-risk transactions, such as small amounts or cases where the merchant already knows the buyer.
In some countries where customers are not accustomed to authentication protocols and conversion may drop significantly. In such cases, the merchant can use Zru’s fraud rules to trigger 3DS only when the risk is higher.
MOTO transactions.
How to activate and manage 3D Secure in Zru
Using 3DS in Zru is straightforward and is part of each card payment connection the merchant has configured.
Activating 3D Secure within orchestration
From the orchestration section, when creating a payment flow, you simply select the type of 3D Secure to apply:
Agnostic*.
The processor’s own 3DS (in the example image, Adyen).
The processor’s 3DS with challenge always forced, even if the processor would not request it because the fraud risk is low.
No 3DS (note that the PSP or acquiring bank must pre-approve transactions without 3D Secure for that terminal).
*If you want to use Agnostic 3D Secure, it must be selected when creating the orchestration flow:
Activating 3DS based on fraud risk
In Zru, 3DS can be activated only from a fraud score defined by the merchant. Let’s see how it works.
For example, a merchant may define the following setup:
One of the conditions for not activating 3DS is that the transaction fraud score is below 40. If it is above 40, 3DS must be activated.
The fraud score is a value that each merchant can define in the Zru panel, based on variables such as the card BIN, issuing country, whether the card is being used for multiple purchases, etc. The higher the score, the higher the fraud risk.
This would be the orchestration flow:
In this way, 3D Secure is activated only for transactions with a fraud score above 40 points.
3D Secure vs Agnostic 3D Secure
Agnostic 3DS is a 3DS service that allows authentication to be performed before selecting a processor. This means that 3D Secure does not depend on a specific processor and can later be used with any processor.
Let’s compare a flow with and without Agnostic 3D Secure.
Without Agnostic 3D Secure
If a payment is first sent to processor A and, if it fails, retried with processor B, processor A will trigger authentication, and processor B will also have to do so.
In this case, the customer experience would be:
The buyer enters their card details at checkout.
He receives a notification from their bank to authenticate.
Because processor A fails, he receives another notification to authenticate again.
This process may not be fully smooth for the buyer.
With Agnostic 3D Secure
In the same scenario with two processors, authentication is performed once using Agnostic 3DS before sending the payment to processor A.
If processor A fails, the transaction is sent to processor B without requiring another authentication. The buyer authenticates only once, making the process much simpler.
Conclusion
3D Secure is part of the day-to-day operations of any business that accepts online card payments. It helps protect against fraud and is essential in the payment process. However, it can also impact conversion.
With Zru, 3DS is managed within orchestration through rules, allowing it to adapt to each payment flow based on business needs and fraud criteria. This gives payment teams control and enables them to optimize fraud prevention and conversion in a flexible way, without requiring technical changes.
Product
13
READING TIME
3D Secure: what it is, how it works, and prevents fraud
Table of contents
What is 3D Secure?
3D Secure (also called 3DS) is an authentication protocol that adds a layer of security to online card payments. Its purpose is to confirm that the person making the purchase is actually the cardholder, helping to prevent fraud.
It is called 3D because three domains are involved in the authentication process (the 3-Domain model):
Acquirer domain (the acquirer is the bank or payment provider that supplies the virtual POS).
Issuer domain (the bank that issued the card).
Interoperability domain (the card scheme, for example Visa or Mastercard).
During a payment, these three actors exchange information to decide whether the transaction must be authenticated and how to do it.
If 3D Secure is triggered, the issuing bank will request proof of identity from the buyer. This may be a one-time code sent by SMS, a validation request in the bank’s app, or biometric authentication.
In this way, an additional security step is added to ensure that the person making the purchase is the legitimate cardholder.
In short, 3DS is a protocol that, when triggered, asks the buyer to complete an additional authentication step, such as entering a code received by SMS or approving the payment in their banking app (and not just entering the card number and CVV at checkout).
It is important to note that 3DS also has a frictionless flow, where no additional action is required from the user. Based on factors such as the device or type of purchase, the system can determine with a high level of confidence that the user is legitimate. We will cover this in more detail below.
Benefits of using 3D Secure
3DS offers several advantages for both merchants and buyers.
Benefits for merchants:
Fraud reduction.
By requiring authentication at the time of payment, the likelihood that a stolen card is used decreases significantly.Fewer chargebacks.
Because the transaction was completed using 3D Secure, it is assumed that the legitimate cardholder authorized the payment. This allows the liability shift to apply, meaning responsibility for certain fraud cases transfers from the merchant to the issuing bank.Regulatory compliance.
When 3DS is used, the merchant complies with Strong Customer Authentication requirements under PSD2.
Benefits for buyers:
Greater protection against fraudulent card use.
Cardholders know that even if someone has their card details, they will not be able to complete the payment without access to the required authentication method (for example, an SMS or mobile notification).
How does 3D Secure work in a transaction?
3D Secure is triggered midway through the payment process, after the buyer has entered their card details on the checkout page and before the issuing bank authorizes the transaction.
This is the process for a payment through Zru:
The buyer enters their card details and CVV on the checkout page (the checkout page belongs to the Zru environment).
Zru sends the card and transaction data to the processor used by the merchant (Redsys, Stripe, Adyen, dLocal, etc.).
The processor decides whether 3D Secure is required, based on predefined variables and rules (payment amount, merchant profile, etc.).
In some cases, the processor does not initiate 3DS, but once the transaction is sent to the issuing bank, the bank itself may determine that the fraud risk is high and require 3DS authentication.
If 3DS is triggered, two scenarios are possible:
a. 3DS Frictionless: authentication happens in the background. The issuing bank receives contextual information about the transaction, analyzes it, and allows the payment to continue without showing any additional step to the buyer.
b. 3DS Challenge: the buyer must complete authentication and prove they are the cardholder.If there is a challenge, the buyer authenticates using one of the following methods, depending on the bank:
a. Approval in the banking app
b. Biometric authentication (fingerprint or Face ID)
c. A one-time password (OTP) sent via SMS or another channelThe payment continues: once authentication is completed, the issuing bank moves to the authorization phase, approving or declining the payment based on funds, limits, fraud risk, etc.
Why there is sometimes no challenge and a frictionless 3DS is performed
This can be surprising, as many people associate 3D Secure with a bank verification request. However, there are cases where 3DS is performed without showing a challenge.
To decide this, the issuing bank performs a risk assessment. Variables such as the transaction amount, customer history, purchasing behavior, device, country, merchant category, or common fraud patterns are taken into account.
If the bank considers the transaction to be low risk, it may allow it to proceed through a frictionless flow.
3DS1 and 3DS2: differences
Since Visa launched 3D Secure in 2001, the protocol has evolved to adapt to new regulatory requirements, technological improvements, and changes in consumer behavior.
3DS1: the beginning
Visa introduced the first version of 3D Secure in 2001 under the name Verified by Visa. Other schemes such as Mastercard and American Express later followed.
It was a major step forward in combating online fraud. However, as ecommerce grew and transaction volumes increased, several limitations emerged: additional steps in the checkout process causing friction and user frustration, poor user experience, static passwords that customers often forgot, etc.
3DS2: a more integrated model
Version 2 of the protocol was published in 2016, but its widespread adoption in Europe began in 2019, driven by PSD2 and Strong Customer Authentication requirements, which came into force in 2021.
Key improvements introduced by 3DS2 include:
Optimized user experience, as authentication no longer requires redirection to external pages, which can improve conversion.
Dynamic authentication, eliminating the need for customers to remember static passwords, with banks using app notifications or SMS instead.
Frictionless flow, where many low-risk transactions are approved without any additional action from the buyer. For example, low-value payments or recurring payments after an initial authentication may not require a challenge.
Increased security, as it complies with PSD2 in Europe.
What to consider to maintain good conversion with 3D Secure
Metrics to monitor
As we have seen, using 3D Secure is important for regulatory compliance in Europe, reducing fraud risk, and limiting chargebacks.
However, adding an extra step to the checkout flow can affect conversion rates.
For this reason, merchants should measure the impact of 3DS and monitor key metrics such as:
Challenge rate: the percentage of transactions that require visible authentication.
Challenge abandonment rate: the percentage of users who do not complete authentication.
Authorization rate after authentication: the percentage of authenticated payments that are ultimately approved.
Comparison between frictionless and challenge flows and their real impact on conversion.
Reviewing authentication failure types (for example, Zru error codes) to understand whether the customer did not complete authentication, left the screen, or the authentication itself failed.
Cases where 3D Secure may be deactivated
Although it is generally recommended to use 3D Secure to protect against fraud, there may be exceptions where it is possible not to activate it.
First, in order for the processor not to trigger 3DS, the merchant must request this from the acquiring bank (the one providing the virtual POS), and the acquirer has the final decision.
Additionally, even if the acquiring bank approves transactions without 3DS, the issuing bank always has the final say. If it considers the transaction high risk, it will not allow it to proceed without authentication.
It is important to consider that disabling 3DS may increase fraud and chargebacks, so each case must be evaluated carefully.
Some scenarios where merchants may consider not activating 3DS include:
Low-risk transactions, such as small amounts or cases where the merchant already knows the buyer.
In some countries where customers are not accustomed to authentication protocols and conversion may drop significantly. In such cases, the merchant can use Zru’s fraud rules to trigger 3DS only when the risk is higher.
MOTO transactions.
How to activate and manage 3D Secure in Zru
Using 3DS in Zru is straightforward and is part of each card payment connection the merchant has configured.
Activating 3D Secure within orchestration
From the orchestration section, when creating a payment flow, you simply select the type of 3D Secure to apply:
Agnostic*.
The processor’s own 3DS (in the example image, Adyen).
The processor’s 3DS with challenge always forced, even if the processor would not request it because the fraud risk is low.
No 3DS (note that the PSP or acquiring bank must pre-approve transactions without 3D Secure for that terminal).
*If you want to use Agnostic 3D Secure, it must be selected when creating the orchestration flow:
Activating 3DS based on fraud risk
In Zru, 3DS can be activated only from a fraud score defined by the merchant. Let’s see how it works.
For example, a merchant may define the following setup:
One of the conditions for not activating 3DS is that the transaction fraud score is below 40. If it is above 40, 3DS must be activated.
The fraud score is a value that each merchant can define in the Zru panel, based on variables such as the card BIN, issuing country, whether the card is being used for multiple purchases, etc. The higher the score, the higher the fraud risk.
This would be the orchestration flow:
In this way, 3D Secure is activated only for transactions with a fraud score above 40 points.
3D Secure vs Agnostic 3D Secure
Agnostic 3DS is a 3DS service that allows authentication to be performed before selecting a processor. This means that 3D Secure does not depend on a specific processor and can later be used with any processor.
Let’s compare a flow with and without Agnostic 3D Secure.
Without Agnostic 3D Secure
If a payment is first sent to processor A and, if it fails, retried with processor B, processor A will trigger authentication, and processor B will also have to do so.
In this case, the customer experience would be:
The buyer enters their card details at checkout.
He receives a notification from their bank to authenticate.
Because processor A fails, he receives another notification to authenticate again.
This process may not be fully smooth for the buyer.
With Agnostic 3D Secure
In the same scenario with two processors, authentication is performed once using Agnostic 3DS before sending the payment to processor A.
If processor A fails, the transaction is sent to processor B without requiring another authentication. The buyer authenticates only once, making the process much simpler.
Conclusion
3D Secure is part of the day-to-day operations of any business that accepts online card payments. It helps protect against fraud and is essential in the payment process. However, it can also impact conversion.
With Zru, 3DS is managed within orchestration through rules, allowing it to adapt to each payment flow based on business needs and fraud criteria. This gives payment teams control and enables them to optimize fraud prevention and conversion in a flexible way, without requiring technical changes.
