.png?width=365&height=122&name=BTLogo%20(1).png)
3D Secure (3DS) has yet to take hold in the United States, with about 3% of e-commerce transactions using it in 2025.
Many U.S. stores do not use 3DS often because of the fear that customers will cancel their orders due to the extra verification steps. This is a stark difference from Europe and the UK, where 3DS is the backbone of Europe’s Payment Services Directive 2 (PSD2) regulation.
The U.S. has no such mandate. Issuing banks aren’t required or incentivized to accept the liability that comes with 3DS. Merchants and fintech platforms rarely build 3DS into their payment flow. Instead, they lean on basic fraud checks that confirm the cardholder but leave the platform at risk of chargebacks.
It’s that gap where the conversation about 3DS in the U.S. ends for most companies; If it’s not mandated, it’s not worth the engineering time.
But the absence of a mandate doesn’t mean there’s an absence of a valuable use case. Effective 3DS implementations in the U.S. can be built around transaction optimization, recovering declines, and protecting high-risk verticals.
This is the use case for 3DS worth understanding.
What is 3D Secure?
3DS is an authentication protocol that adds a verification step between a cardholder and their card issuer during an online transaction. The "3D" refers to the three domains involved in the process: the merchant and their acquiring bank, the cardholder's issuing bank, and the network infrastructure that connects them
When a transaction runs through 3DS, the issuer gets a chance to confirm the cardholder is who they say they are, either instantly and invisibly (frictionless authentication) or through a challenge like a one-time passcode (step-up authentication).
What matters most to a platform is when a transaction is successfully authenticated through 3DS, the liability for chargebacks shifts from the platform to the card issuer.
This difference is why 3DS shows up as a requirement in regulated markets like the EU.
Why is 3DS treated differently in the United States?
If 3DS shifts liability, and improves issuer confidence, why wouldn’t adoption be higher?
The short answer is because nobody is making them.
Unlike with PSD2, the United States has no equivalent mandate. Issuing banks aren't required to accept the liability shift that comes with 3DS, and many are reluctant to do so. Even when a merchant runs a transaction through 3DS, some issuers will still decline it rather than take on the fraud liability.
The path of least resistance, which consists of fraud checks and address verification services (AVS), is a workable setup for many transactions. It also shows why 3DS in the United States can get filed away as unnecessary instead of a realistic option.
The Overlooked 3DS Use Case
Rather than ask, “Should every transaction go through 3DS?” the better question is, “Which transactions actually need 3DS, and why?”
The answers mean using 3DS as a tool inside your payment workflows, not a hard-coded requirement. This can play out in two ways:
- Pre-authorization before the decline happens. This is layering 3DS in before a transaction is submitted for authorization based on how it’s scored for fraud. Transactions flagged in a gray area using Transaction Risk Analysis (TRA) scoring rather than simple pass/fail fraud checks or BIN-based rules can be routed to 3DS for issuer authentication before authorization.
- Post-authorization after a decline. If a transaction is declined, this doesn’t mean the end of the road, especially if it's a soft decline, which signals the issuer wants additional authentication rather than a flat refusal. Funneling that transaction through 3DS to get issuer authentication, then resubmitting, is effective in high-fraud markets or verticals.
Both flows work well in high-risk verticals where fraud risk is already elevated.
Airlines are great benchmarks with high transaction values, thin margins, and issuers that decline conservatively by default. In one example of implementing this flow through 3DS pre-authorization for an airline, approval rate lifts of 100 basis points were common.
Agnostic 3DS flows make this a reality without adding a second checkout integration. Treat 3DS as a modular setup, not baked into the authorization call itself. Create a token intent just to validate the card, and only then decide whether and how to convert that into a full transaction.
The 3DS step and the authorization step stay decoupled, which is exactly what makes the pre-auth and post-auth routing above possible in the first place.
Pulling off the pre-auth and post-auth routing generally means working with a PSP that supports 3DS through an external Merchant Plug-In (MPI) that is not tied to any processor. Authentication and authorization can then run independently rather than as a single, locked-together step.
If you're mapping out an agnostic 3DS flow and want to learn more about Basis Theory’s standalone 3DS, get started in the developer portal. This 3DS documentation can be a starting point.
