What is 3D Secure? A Merchant Guide to 3DS Authentication

Key takeaways

• Learn how 3DS authenticates online cardholders and supports PSD2 SCA compliance.
• Understand frictionless and challenge flows, exemptions, and liability shift rules.
• Discover how to activate, optimise, and troubleshoot 3DS as a merchant.

Every online card payment carries an inherent risk because the customer isn’t standing in front of you to confirm they’re the one making the purchase. If a transaction turns out to be fraudulent, someone has to eat the loss and by default, that someone is the merchant. But 3D Secure authentication changes who pays in these cases.

3DS is an authentication protocol that verifies the cardholder’s identity with their issuer before a card-not-present transaction is authorised. For merchants in the EEA and UK, 3DS is how you meet Strong Customer Authentication requirements under PSD2. Everywhere else, it shifts liability away from you as a merchant and helps protect approval rates.

This article covers everything you need to know about how 3DS works in practice, where SCA exemptions let you skip the challenge, what the liability shift actually covers, and how to activate 3DS as a merchant. 
 

3DS is governed by EMVCo, which is jointly owned and operated by the major card networks (Visa, Mastercard, American Express, Discover, JCB, and UnionPay). Each of these schemes runs its own version of 3DS but uses the same underlying EMV 3DS protocol.

In action, 3DS might look like a customer checking out online and the bank sending a one-time password (OTP) to complete the transaction. Because the customer isn't physically in front of the merchant, this extra authentication adds a layer of security to verify the cardholder’s identity.

Remember, 3D Secure is used for authentication and works alongside fraud screening and risk scoring for maximum security. A 3DS transaction can still be flagged as fraud or declined by the issuer, but when implemented correctly, 3DS shifts liability in case something goes wrong. 

How 3DS authentication works?

3DS runs after the customer enters their payment details but before the issuer authorises the transaction. But how it works depends on the risk. Here's what a 3DS2 flow looks like in practice:
 

• The customer checks out by entering their card details on an online merchant’s payment page.
• Before anything visible happens on the front end, the merchant’s payment provider sends transaction data to the issuer for risk assessment. This data can include the device fingerprint, billing address, transaction amount, shopping behaviour, and more. The issuer uses all of this to score the transaction's risk.
• Based on the risk score, the issuer will either approve the authentication silently and authorise the transaction (frictionless flow) or ask the customer to verify their identity (challenge flow).
• If the challenge is required, the customer completes an extra authentication step like a biometric check through the banking app, a push notification, or an OTP sent via SMS.
• After authentication, the transaction continues through the normal payment authorisation process and either clears or declines. 

 
3DS frictionless vs challenge flow

3DS transactions can look different from customer to customer. Some transactions get approved behind the scenes, while others need an extra verification step.

Frictionless flow means the issuer approves the authentication based on risk data alone. The customer doesn’t get an extra prompt, and the transaction completes as if there’s no 3DS at all. This is the preferred flow for low risk transcations.

Challenge flow means the issuer needs more proof that the customer is who they say they are. The customer gets prompted to authetnicate and after they complete the 3DS challenge, the transaction continues. In general, under PSD2’s SCA requirements, a challenge is required when a transaction doesn’t qualify for an SCA exemption (outlined below).

The relationship between 3DS and SCA

Under PSD2, a customer must prove their identity using at least two of three factors: something they know, something they have, and something they are. This is regulated by SCA requirements and delivered by the 3DS protocol.

Previously, 3DS was used as an optional fraud prevention tool, but when PSD2 came into effect, 3DS2 became one of the most practical ways for merchants to meet SCA requirements on CNP transactions across the EEA and UK.

So when an issuer asks for a challenge through 3DS, they’re enforcing SCA. When a transaction goes through as frictionless, the issuer has decided it’s either low risk enough to apply an SCA exemption or the transaction is out of the SCA scope entirely.

Bypassing 3DS with SCA exemptions

SCA isn’t required on every transaction, and PSD2 bakes in exemptions to let low-risk transactions go through without a challenge. Merchants and acquirers can flag low-risk transactions during the auth request, but the issuer makes the final call.

The main SCA exemptions to bypass 3DS are:

• Transaction risk analysis (TRA) – The acquirer or issuer’s fraud rates are low enough to apply TRA based on transaction value. The amount depends on the fraud rate, but in general, for transactions over €500, TRA doesn’t apply. 
• Low value payment (LVP) – Transactions under €30 can skip SCA, but only up to 5 consecutive exempt transactions, or a cumulative €100 value before SCA is required again. 
• Merchant-initiated transaction (MIT) – Purchases like subscription renewals, recurring billing, and other transactions where the customer isn’t present at the time of the charge. The initial transaction must involve SCA, but the recurring MITs are often exempt.
• Trusted beneficiary – The customer can whitelist merchants through their bank so that future transactions can skip SCA. 
  Secure corporate payments – Some B2B transactions on dedicated corporate cards can be exempt. 

Fraud liability shift under 3DS

One of the main reasons merchants run 3DS even when SCA isn’t necessarily required is the liability shift. With a successful 3DS authentication, if the transaction is disputed as fraud later, the chargeback liability shifts from the merchant to the issuer.

Without 3DS, fraud chargebacks are the merchant’s responsibility, meaning you’ll eat the cost of goods, the chargeback fee, and any penalties by the scheme if your merchant fraud rate gets too high. But under 3DS, the issuer authenticates the cardholder, so they’re responsible for any losses.

This is true even for frictionless flows where there’s no challenge. As long as the transaction is authenticated by 3DS and the issuer returns a successful authentication, liability shifts away from the merchant regardless of a visible challenge.

However, it’s important to remember that the liability shift only covers fraud disputes. Chargebacks for non-receipt, product not as described, duplicate processing, or authorisation errors remain under the merchant’s scope of liability, regardless of 3DS.

Additionally, if you flag an exemption and the issuer soft declines, but you don’t try it again through 3DS, the original transaction isn’t considered authenticated. This means you, as the merchant, are liable for any future fraud disputes. 

3D Secure across merchant scenarios

As a merchant, it’s important to understand when (and why) 3DS comes into play because authentication doesn’t behave the same across every transaction type. Here are some common merchant scenarios and 3DS expectations:

• One-off CNP transactions – This is a standard scenario where a customer enters card details, and 3DS runs either a frictionless or challenge flow. 
• Recurring payments and subscriptions – The first transaction is authenticated with 3DS and SCA. Subsequent renewals run as MITs and don’t need 3DS so long as the original mandate is intact.
• Tokenised payments – When a customer pays using a digital wallet like Apple or Google Pay, SCA is handled at a device level through biometrics, so 3DS isn’t usually triggered again at checkout.
• Cross-border transactions – 3DS still applies if either the issuer or acquirer is in the EEA or UK. Outside that scope, 3DS is optional but still affects the fraud liability shift.

Activating 3D Secure as a merchant

Merchants can enable 3DS through their payment provider or acquirer. The process normally looks something like this:

• Confirm your PSP supports EMV 3DS2. This is essential as many issuers no longer support 3DS1.
• Enable 3DS at the account or processor level. Most modern PSPs like Planet have 3DS on by default for EEA and UK traffic.
• Pass as much data as possible in the authentication request to promote frictionless flows. Consider elements like the device fingerprint, billing address, email, shipping data, and the customer’s shopping history. The more information the issuer has, the more likely they’ll approve it as frictionless.
• Configure exemption logic. As a merchant, you get to decide whether to request TRA, LVP, or MIT exemptions and how to handle soft declines.
• Before going live with 3DS, test the flow in a sandbox. Most PSPs will allow you to run a few transactions in challenge and frictionless modes with test cards.

3DS is one part of the CNP fraud setup. Your PSP’s fraud screening, network risk signals, and your own risk rules run alongside it.

Why 3DS fails and what to do about it?

3DS can fail at several points along the flow for a variety of reasons. Some of the most common ones are:
 

• Wrong OTP entered – The customer inputs the wrong code. They’re usually able to retry.
• OTP not received – Maybe the customer’s phone number is outdated, or there’s a delay in SMS delivery. Switching to in-app authentication usually solves this 3DS failure.
• Authentication timeout – The customer didn’t complete the 3DS challenge in time, which causes it to fail. 
• Issuer ACS down – In rare instances, the Access Control Server on the issuer side is unavailable. All the merchant can do is retry.
• Card not enrolled in 3DS – Also less common, but possible with niche issuers.
• Soft decline (SCA required) – The issuer rejected the exemption request and is asking for a 3DS challenge. Retry the transaction with 3DS.
• Hard decline during authorisation – The issuer declined the transaction during authorisation, not authentication. This is a fraud or risk decision and shouldn’t be retried for security reasons.

For 3DS failures on the merchant end, it’s recommended to log the result code to understand whether it’s an issue with authentication or authorisation and then to retry accordingly. 

What’s new in EMV 3DS 2.3?

3DS 2.3 was released by EMVCo in October 2021, and adoption is still rolling out. It’s not mandated under PSD2, but it’s highly recommended for merchants to stay up to date with evolving technology and authentication features for both security reasons and the overall customer payment experience.

The main changes in 3DS 2.3 are:
 

Better support for decoupled authentication – Introduced in 3DS 2.2, decoupled authentication moves the challenge outside the checkout flow so the customer can authenticate in their banking app later and the transaction still completes. It's extra useful for stored credentials and recurring payment scenarios.

Secure payment confirmation (SPC) – This allows the browser to handle the 3DS challenge using FIDO and WebAuthn credentials, which reduces friction by using biometrics already set up on the device.

Better data sharing – Expanded data elements give issuers more to risk score on, which can lift frictionless rates.

Multi-card flows – 3DS 2.3 has better support for split payments and multiple card scenarios in a single checkout flow.

Enhanced exemption handling – More explicit ways to request exemptions on the merchant side.

Due to the uneven rollout, it’s well worth confirming your PSP supports the current 3DS 2.3 protocols rather than assuming it’s live everywhere.

Thinking about the future of 3D Secure authentication

When considering the future of 3DS authentication, it’s evolving in two directions.

The first is less friction. Frictionless rates continue to climb as issuers get better at risk scoring with more data from the merchant side. Web APIs like Secure Payment Confirmation (SPC) and biometric flows will slowly replace OTP, with an ultimate endgame of invisible authentication for all low-risk transactions.

The other direction is a broader scope of coverage. The European Commission published proposals for PSD3 and the Payment Services Regulation (PSR) in June 2023, which would tighten some SCA exemption rules and expand authentication into more transaction types. The proposals are still working through EU legislation without final timelines confirmed. 3DS will continue to be the protocol, but the rules around when it’s required will shift.

For merchants, the most practical implications involve keeping your PSP current on 3DS versions, pushing more data into authentication requests and revisiting exemptions frequently instead of setting and forgetting them. Doing this enables you to strike a balance between payments secure enough to shift liability and frictionless enough that good customers never feel it. 

FAQs

What does 3DS stand for?

3DS stands for Three Domain Secure. The three domains are the issuer domain, the acquirer domain, and the interoperability domain, which is the card network infrastructure that connects the issuer and acquirer.

Is 3DS the same as SCA?

3DS and SCA are directly related but not the same. SCA is the regulation that requires merchants to authenticate customers, while 3DS is the protocol used to deliver it. 

Does 3DS shift liability?

One of the main benefits of merchants using 3DS is the fraud liability shift. When a 3DS authenticated transaction is disputed as fraud, liability shifts from the merchant to the issuer. This is one of the main reasons merchants use 3DS, even when it’s not required by SCA. 

Does 3DS apply to Apple Pay and Google Pay?

When a digital wallet is used, SCA is carried out by device biometrics. The wallet token is treated as authenticated, and due to this, there’s usually no need for 3DS authentication at checkout. 

Do all cards support 3DS?

Most consumer cards support 3DS. Some commercial or prepaid cards might have inconsistent support, though this normally comes from the issuer side, not the PSP.