Everything you need to know about 3D Secure

3D Secure (3DS) isn’t new, but it’s also not the same as it was when it was introduced over two decades ago. If you’re looking into 3DS for the first time, or if you want to get more out of your current setup, this post is for you. And if you’re just looking to get a better understanding of the 3DS flow, you’re in the right place. We’ll explain what 3DS is, why businesses use it, and what to consider when building a strategy around it. We’ll also cover who provides 3DS services, and what to measure to make sure your implementation is working.

What 3D Secure is

3D Secure adds an authentication step to online card payments. Card networks introduced the first version in the early 2000s to primarily address card-not-present (CNP) fraud. CNP transactions have no physical card or signature to check, so issuers had no reliable way to confirm that the person making a purchase was the actual cardholder. 3DS solved this. It loops issuers into the checkout process so they can authenticate the customer before the transaction is authorized.

The original version (3DS1) redirected customers to static, and often unfamiliar-looking verification pages and asked for a password. Functionally it worked, but it hurt conversion and became somewhat infamous for it. 3DS2 was released in 2016 and fixed many of the issues with 3DS1. This current version is what most people think of when 3DS is mentioned. It supports risk-based authentication, so low-risk transactions can pass without any customer interaction (known as a frictionless flow), and it supports modern verification methods like biometrics and in-app approvals instead of static passwords.

How 3DS works

To understand 3DS, there are multiple parties and multiple systems to cover. There’s a quick reference at the end of this section, so don’t feel like you have to remember all the acronyms.

The parties and systems involved

3DS actually gets its name from the three domains the protocol is built on (acquirer, interoperability, and issuer). So the long form is Three-Domain Secure, and doesn’t really come from three security levels.

The acquirer domain includes the merchant, the 3DS Server (the system that constructs and sends authentication requests), and the acquiring bank. Most merchants use a third-party solution (through their PSP or a standalone provider) for 3DS rather than building their own.

The interoperability domain sits in the middle. It's the card network's infrastructure, specifically the Directory Server (DS), which each network (Visa, Mastercard, American Express, and others) operates independently. When an authentication request comes in, the directory server checks whether the card is enrolled in 3DS, identifies the right issuer system to send the request to, and routes it there. Its main job is coordination, it doesn't make authentication decisions itself (although some card networks, including Mastercard, can stand in for the issuer and return an authentication response if the issuer’s systems are down).

The issuer domain includes the cardholder, their device, the issuing bank, and the Access Control Server (ACS). The ACS is the issuer's authentication and risk engine, and the most consequential party in the flow from a fraud and conversion standpoint. The ACS evaluates each request against its own risk models and decides whether to approve it silently (a frictionless flow), require a challenge, or decline the request outright. If a challenge is triggered, the ACS coordinates and returns the result. Every issuer runs its own ACS, either in-house or through a vendor, which means frictionless rates, challenge rates, and error patterns vary by issuer.

What 3DS looks like to customers

Frictionless flows are essentially invisible to customers. The calls between the systems for the 3DS session still happen, but they resolve almost immediately. During a challenge flow, customers are shown a verification step. It’s usually a prompt from their bank's app, a fingerprint or face scan, or a one-time passcode. They complete the challenge and the transaction continues. When implemented well, the challenge happens within the checkout flow instead of redirecting the customer to a different page or domain.

What 3DS looks like to the different systems

A 3DS authentication is a sequence of messages passed between the three systems. The 3DS Server sends an Authentication Request (AReq) to the directory server, which routes it to the correct ACS. The ACS evaluates it and returns an Authentication Response (ARes). For frictionless transactions, that's the end. For challenge flows, the ARes signals a challenge is needed, and a Challenge Request/Response (CReq/CRes) exchange runs the actual verification with the cardholder. After that, a Results Request/Response (RReq/RRes) confirms the outcome back to the merchant's side.

There's also an optional step called the 3DS Method that runs before the AReq. It's kind of a hidden background process that lets the ACS collect device data ahead of time. Using it tends to improve frictionless rates, because it gives the ACS more information to work with when deciding whether a challenge is necessary.

3DS quick reference

Some of these we’ve covered already, and some will come up in subsequent sections. If you want to know more about the 3DS specification, see the EMVCo site for more information.

Why businesses use 3D Secure

For many businesses, the short answer is that it’s required. Depending on where you operate, 3DS or a similar authentication solution is mandated (SCA requirements in the EU for example). 3DS is voluntary in some regions though too, including the US.

Outside of mandates, the most direct reasons for using 3DS are fraud prevention and liability shift. When a transaction passes 3DS authentication, liability for fraud-related chargebacks generally shifts from the merchant to the issuer. Chargebacks are expensive on their own, but there’s also the operational overhead of disputing them. When chargeback rates get too high, they can trigger card network chargeback-monitoring thresholds, which can bring fees or processing restrictions.

There's another benefit but it’s less obvious. 3DS lets you say “yes” to transactions you might otherwise decline. Fraud models are good, but they sometimes struggle in situations where they don’t have enough data to confidently flag a transaction as fraud or not. This often happens when:

• A customer checks out for the first time.

• A customer uses a “guest checkout” flow instead of logging in.

• The transaction is high-value and there’s no purchase history to rely on.

Without 3DS, it’s safer to decline these transactions or route them to a human for manual review, both of which add friction and potentially reduce revenue. With 3DS, you can push uncertain transactions through the authentication process instead. If it passes, you recover a sale you likely would’ve turned down, and you gain a positive signal about that customer for next time. If it fails, you learn something useful without taking on the risk. In other words, 3DS isn't only a fraud prevention tool. It's a way to take on more calculated risk.

To put this into perspective, FlightHub (an Evervault customer) implemented our 3DS product. They reduced fraudulent chargebacks by 33%, saw a 73% reduction in friendly fraud chargebacks, and cut roughly 65 hours of manual review per quarter. These numbers reflect both sides of the benefit: less fraud gets through, and fewer transactions are turned away out of caution.

3D Secure strategy considerations

The first fork in any 3DS strategy is whether it's mandated where you operate. This has a lot of impact on what you’re able to optimize for.

If 3DS is mandated

In mandated markets, you can't skip authentication on transactions. But what you can do is claim exemptions. An exemption has a defined set of conditions under which the regulation allows you to proceed with a transaction without full authentication. Transaction Risk Analysis (TRA) exemptions are the most common. These let you skip authentication on lower-risk transactions that fall below a certain value threshold (some of these also have fraud rate requirements).

The issue with exemptions is that they aren’t always granted. You request the exemption when the 3DS session is created, but the ACS (the issuer) decides whether to grant it. That's part of why the enrichment strategies we’ll cover later matter. Regardless of exemption status, the more confidence you can give the issuer that a transaction is legitimate, the less likely they are to override an exemption request with a challenge.

If 3DS isn't mandated

Without a mandate, you get to decide which transactions are worth authenticating but you need to find the right balance. If you run 3DS on every transaction, it can add unnecessary friction to low-risk purchases you might have approved anyway. But if you skip it completely, you miss out on liability shift.

A risk-based approach often works best to make the call. You should look at authenticating transactions that:

• Fall into gray zones that your fraud model struggles with.

• Involve a new or guest customer.

• Carry a higher-than-average order value.

• Show any other signal that would otherwise trigger a decline or manual review.

This is also where fail-on-challenge flows (covered a bit later) are useful. They let you attempt authentication to gain liability shift without forcing every uncertain transaction through a challenge.

Getting your authentication requests right

When 3DS is triggered, the goal at the request level is to give the issuer's ACS enough confidence in the transaction that it decides a challenge is unnecessary. There are a few aspects of the request to look at.

• Challenge preference indicators: use these to tell the ACS whether you prefer the transaction to be challenged or not. The ACS still decides, but expressing a preference (particularly a preference against challenging on transactions you're confident in) increases the odds of a frictionless outcome.

• Enrichment data: include this data to improve the ACS's ability to make the frictionless call in the first place. Device data (collected through the 3DS Method mentioned earlier), cardholder verification signals, and other contextual data give the ACS more information to work with. The specific fields available can be dense and vary by provider and network, but the principle is the same. The more legitimate signal you send, the less the ACS has to guess.

• Fail-on-challenge: with Evervault, use this flow to attempt authentication to secure a liability shift, but automatically skip the challenge and proceed to authorization if one would otherwise be required. This is a useful middle ground for businesses that want the liability protection when it's available, without forcing every customer through a challenge.

Handling 3DS failures

Understanding and acting on 3DS failures can be difficult. The 3DS protocol and specification isn’t easy to understand, and there are multiple points at which a 3DS authentication can fail. Evervault’s 3DS solution makes the process easier, but if you’re using or evaluating another provider, you might have to do some digging.

3DS responses carry structured status codes that tell you what happened and why. Understanding and handling declines mostly comes down to knowing where to look for these status codes. Every authentication response carries a top-level transStatus code, which is a good place to start. Check this first, since it tells you what kind of outcome you're dealing with before you dig into the specific reason.

If the status comes back N, U, or R, you need to find out the reason. The transStatusReason code tells you this. The codes below are grouped into a handful of practical categories.

Request and data issues

Card and account status issues

ACS availability and technical issues

Frequency and decoupled authentication issues

If you see codes 15 through 18 (low, medium, high, and very high confidence), they aren't actually failures. This is an example of where the 3DS protocol is difficult to understand. These values indicate how confident the ACS is in its decision. For example, if the transStatus is R (Rejected by the issuer), and the transStatusReason is 18 (very high confidence), the ACS is telling you it’s confident in its decision. You can use this data to inform your own risk decisioning, and to improve your 3DS requests (e.g., if confidence is low, find out if there’s more data you can share in your requests to improve confidence for future requests).

The next set of errors is at the card brand level. Mastercard and Visa both use the 80s range for their codes, but the numbers don’t mean the same thing. A code 81 from Mastercard (an accepted acquirer exemption) and a code 81 from Visa (an ACS timeout) are unrelated, so always confirm the card brand before interpreting a code in this range.

Mastercard-specific codes (80–88)

Visa-specific codes (80–90)

Following this troubleshooting flow (checking transStatus, then transStatusReason, then card brand errors) hopefully tells you enough about the failure to resolve the issue. It also tells you where you stand on liability shift. Whether the shift occurs depends on the combination of what you requested (a full authentication, an exemption, etc.), what the ACS decided to do, and how that decision was carried out. The codes tell you where in that chain something didn't go the way you wanted, which is what makes them useful for more than just debugging. They’re signals you can use in your own 3DS strategy.

Retrying declined payments without repeating 3DS

Retrying a declined payment through a different PSP is a common recovery pattern. It's sometimes referred to as cascading payments, payment cascading, or just retries. There are different strategies for it, but the idea is that you retry a declined payment with different PSPs until it finally succeeds. The process gets a little more complicated when 3DS is involved.

To make it work well, you need a PSP-agnostic 3DS solution. When you try a transaction through a PSP using their 3DS solution, you usually can't carry that 3DS authentication (the Electronic Commerce Indicator, cryptogram, and other metadata) to a different PSP if the transaction is declined. You could potentially use the secondary PSP's 3DS solution as well, but that means the customer has to complete multiple 3DS sessions, which isn't a great customer experience. It introduces a lot of friction and risks the customer dropping off completely.

Even if you're integrated with multiple PSPs already, you need to make sure they support "bring your own 3DS" solutions. There's decent support for it, but it can come with caveats or specific integration configurations, so check with your providers to make sure it's possible.

3DS Requestor Initiated (3RI) transactions

3RI transactions (supported on 3DS version 2.2+) confirm account information and cardholder authentication without the cardholder being present. They’re used for recurring transactions (subscriptions, utility bills, etc.) and decoupled authentication requests. 3RIs are closely tied to merchant-initiated transactions (MITs).

MITs and customer-initiated transactions (CITs) are card network concepts. CITs have the cardholder present during the payment flow. The customer enters their card details, initiates the payment, completes the 3DS challenge flow if needed, and the transaction continues. With MITs, there’s usually some agreement or consent between the customer and the business that allows the business to collect and use card details for future transactions. At collection time, if 3DS authentication is required, it’s completed then. When it’s time to charge the customer, an MIT is initiated (with no involvement from the cardholder) and a 3RI is used for authentication (it sort of carries over the initial authentication into the MIT).

3RIs are genuine authentication attempts. Even though they have a connection to a previous authentication, 3RIs can still succeed, fail, etc. This means that liability shift is also impacted by their result.

3DS Data Only

3DS Data Only doesn’t get talked about a lot, but it can be a powerful option in certain scenarios. It technically uses the 3DS rails, but it’s more of a card network mechanism (Visa has Visa Data Only, Mastercard has Data Share Only). What happens is that you share transaction data with the issuer through the 3DS rails, and the issuer factors that information into their own risk-based authorization decision.

These flows aren’t about authenticating the cardholder (the process is invisible to customers and there’s never a challenge displayed). There’s no liability shift and fraud liability stays with you. What you’re doing is giving the issuer a rich set of data they wouldn’t otherwise have, in an effort to increase the chance that they approve the transaction. 3DS Data Only flows are commonly used in situations where 3DS isn’t mandated, or when you know a transaction is exempt from something like SCA in Europe.

Delegated authentication

Delegated authentication (different from decoupled authentication) changes who authenticates the cardholder. The issuer hands SCA responsibility to a third party, like a merchant, a payment gateway, or a digital wallet. That party authenticates the customer with its own method, device biometrics, or a passkey, and attests to the issuer that authentication happened. This lets a merchant skip the redirect or embedded challenge screen that most 3DS implementations rely on. The authentication experience can live inside the merchant's app, using the fingerprint or face recognition set up on the customer's device.

Delegated authentication isn't a universally available option. It requires either a bilateral agreement with a specific issuer, like the one Stripe has with Wise, or participation in a scheme-level program (like Mastercard's Identity Check Express or Visa's Payment Passkey). That makes it a better fit for large merchants, or payment companies with mobile-first audiences like gambling or crypto. They have the scale to negotiate these relationships, and their customers are comfortable authenticating inside an app. There's a trade-off though: delegated authentication shifts fraud liability to whoever performs the authentication instead of the issuer. A merchant taking this on is trading a smoother checkout experience for more fraud risk.

3D Secure solutions and their implications

Up to this point, we’ve focused a lot on core 3DS concepts. As you define your 3DS strategy, you eventually have to look at providers and how 3DS authentications will be carried out. This is largely about deciding whose 3DS server to use, and there are a few categories to cover.

Payment service providers (PSPs)

Most PSPs provide 3DS solutions as part of their platform. This is the lowest-effort path if you're only using one PSP. There’s no separate vendor relationship, and 3DS is already wired into your existing checkout flow. The tradeoff is that you're tied to how that PSP implemented 3DS, which can mean less control over challenge flows, exemption logic, and enrichment. It also causes a lot of friction if you ever want to switch PSPs or add a second one.

Standalone providers

If you work with multiple PSPs, or you want more control over how 3DS behaves, standalone providers let you handle 3DS independently of any specific processor. You integrate once and can apply the same authentication logic and challenge experience regardless of which PSP handles the payment. This is generally the fastest path to a well-implemented setup without owning the underlying complexity yourself, since a standalone provider has already been through the certification process.

Not all 3DS providers actually build their own 3DS Server. Many of them wrap someone else’s instead. You can use the EMVCo-approved products directory to figure out if the vendors you’re talking to have their own server or not. Search for the vendor using the Keywords field, and then check the Component Type to see whether they have a valid license. If they don't, they're reselling you somebody else's solution.

It’s recommended to use a vendor that runs their own EMVco server. They have more control over the product, and they have direct relationships with the card schemes and ACS providers.

Building your own solution

You can build and operate your own 3DS Server (this is what Evervault does), but it’s costly at a few different levels. You first have to complete EMVCo's formal approval process. You have to register with a recognized test platform, complete pre-compliance tasks, and then complete formal compliance testing through an accredited lab. After passing, you receive EMVCo's Letter of Approval. After that, you have to complete certification with each card network you want to support. These certifications take months and have to be renewed.

If you go this route, you’re taking on the entire certification and maintenance burden yourself in exchange for maximum control over the implementation. For most businesses, it doesn’t make sense or isn’t feasible from a resourcing standpoint.

Payment method considerations

3DS doesn't work the same across all the ways customers can pay with a card. On cards directly (we’ll clarify in a moment), the flow is the one described throughout this post: the customer enters card details, completes a challenge if required, and the transaction continues.

With network tokens, the underlying card number is replaced with a token, but authentication still happens the same way structurally. This gets more interesting with MITs. You may be able to reuse an authentication from an earlier cardholder-present transaction rather than running a fresh challenge for every subsequent charge.

With Apple Pay and Google Pay, the wallet itself typically handles authentication as part of the payment flow. This often means that a separate 3DS challenge either isn't triggered, or is satisfied by the wallet's own authentication mechanism. The wallet is, in effect, serving the same purpose as 3DS. This is worth understanding if you're comparing acceptance rates or challenge rates across payment methods.

Reusing authentication data

We covered 3RIs and MITs already, but it’s worth understanding what enables them. There are also other use cases that reuse authentication data other than recurring charges and subscriptions.

There’s an allowable time window between authentication and authorization. Some businesses use that window to finish other parts of their own transaction logic. They might use it to confirm inventory, finalize dynamic pricing, or complete other dependent processes before submitting for authorization. If your business has any kind of delay between "we've confirmed this customer and card" and "we're ready to charge them," it's worth understanding how long that window can safely stay open. Ideally, you finish the whole process as quickly as possible (a few seconds or minutes), but you’ll need to check with your own providers and your own integrations to figure out what’s possible.

How to know whether your 3DS solution is working

After you’re live with whatever 3DS solution you choose, the way to evaluate it is mostly the same. You should track success rates, challenge rates, average time to completion, and error rates (as well as their causes). Success rate tells you how often authentication is actually resulting in a usable outcome. Challenge rate (and its inverse, frictionless rate) tells you how much friction your setup is introducing. Time to completion tells you how much of a delay that friction is actually costing you, particularly on challenge flows. You might also want to track:

• Challenge abandonment rate: if it’s high, it might just be detecting fraud but it could also be customers dropping off. If the latter, you might want to share more information or guidance on the authentication process.

• Frictionless approval and decline rates: if you see high declines, you might be able to share more data in your AReqs to improve the chance of success.

• 3DS protocol versions: you can track which versions are used to make sure you support them, and set up fallback retry logic for the ones you don't. A BIN lookup can surface which protocol version an issuer supports ahead of time. Most modern PSP 3DS solutions handle this automatically.

These numbers are most useful when you break them down, rather than looking at blended figures. If you can, track them by issuer, card brand, country, device (browser vs. mobile), etc. Blended numbers can often hide issues. For example, a drop in your overall success rate might really be a sharp decline with one specific issuer, which is invisible until you segment the data.

Wrapping up

3DS isn't a toggle you flip once and forget about. When it’s implemented well, it's an ongoing set of strategic decisions that impact your checkout flow, fraud numbers, and revenue. Hopefully the fundamentals in this post help you build out your strategy, whether you’re implementing 3DS for the first time, or improving your current setup.

Integrating multiple PSPs is the norm today for just about any business that wants to accept payments globally. Evervault makes that possible while avoiding the pains of vendor lock-in. This includes our own 3D Secure product, which works across all your PSPs. We built our 3DS solution from scratch, and we run our own 3DS server. It’s not just a wrapper around the 3DS spec sheet, it’s an intentional abstraction that we built to simplify how developers integrate 3DS.