What 3D Secure Actually Does for a Card-Not-Present Merchant
“My processor mentioned 3D Secure. What is it actually doing for me?”
Priya Vasanth runs Northbridge Telehealth, a small virtual mental-health platform out of Minneapolis. Eight licensed therapists. Two psychiatrists handling medication management. About 1,400 active patients across Minnesota, Wisconsin, and the Dakotas. Every transaction is card-not-present by definition. Every payment runs through the patient portal — no walk-ins, no terminals, no swipes.
Last month her processor sent her a routine email about enabling 3D Secure. The email used a lot of acronyms. ECI codes. CAVV. Liability shift. Frictionless authentication. Priya read the email twice, set it aside, and asked the obvious question: what does this actually do, and is it worth turning on?
Her question is the right one — but the answers most processors give are either too brief to be useful or too technical to be readable. Here is the version that explains what 3D Secure does, what it does not do, and why a telehealth platform like Priya’s needs to think about it differently than an e-commerce store would.
What Is 3D Secure?
3D Secure is a payment authentication protocol that adds an identity-verification step between the cardholder and their issuing bank during a card-not-present transaction. The “3D” stands for three domains: the merchant’s domain, the issuer’s domain, and the interoperability domain that connects them. The protocol was developed by Visa in the early 2000s and has since been adopted as the industry standard across all major card networks.
The current version, EMV 3DS 2.x, is the one your processor is actually offering when they mention 3D Secure today. The original 3DS 1.0 was retired by most networks in 2022 — if a processor refers to “3DS 1.0” or “the old version,” it is no longer supported.
Each card network operates its own branded version of the same underlying protocol. Visa Secure on Visa cards. Mastercard Identity Check on Mastercard. American Express SafeKey. Discover ProtectBuy. The branding is different. The functional purpose is the same. When a processor says “we support 3D Secure,” they mean all four — the merchant does not enable each one separately.
The Authentication Flow, Without the Acronyms
When a patient enters their card on Priya’s checkout page and clicks pay, the transaction does not go straight to authorization. With 3D Secure enabled, a few things happen first:
The merchant’s payment system sends the card details and a package of contextual data to a central directory server — device type, browser, IP address, transaction amount, merchant category, time of day, billing patterns. Everything the system can see about the transaction without identifying the cardholder personally.
The directory server forwards that data to the cardholder’s issuing bank. The issuer runs the data through its own risk-scoring model — historical patterns for this cardholder, device fingerprinting, address consistency, transaction amount relative to typical behavior.
If everything looks normal — known device, recognized cardholder behavior, low-risk merchant, ordinary amount — the issuer returns a frictionless approval. The cardholder never sees anything. The transaction proceeds to authorization with the authentication signal attached. For well-configured U.S. deployments, more than 90% of 3DS transactions go this path.
If anything looks unusual, the issuer requests a challenge — typically a one-time code sent to the cardholder’s phone or a biometric prompt in their banking app. If the challenge succeeds, the transaction proceeds with the same authentication signal. If it fails or is abandoned, the transaction is declined or proceeds without the authentication flag, depending on the merchant’s configuration.
The Liability Shift
3D Secure is not just about reducing fraud. The genuinely commercially significant part is the liability shift. When a transaction is authenticated through 3DS and a fraud chargeback is later filed against it, financial responsibility for that chargeback shifts from the merchant to the cardholder’s issuing bank.
The logic is straightforward. Without 3DS, when a customer disputes a card-not-present transaction as fraudulent, the merchant is presumed liable — they accepted the transaction without proof of the cardholder’s identity. With 3DS, the issuer made the authentication decision. If the issuer was wrong, the issuer absorbs the loss.
For a merchant doing significant card-not-present volume, this matters. A typical fraud chargeback represents the lost transaction value plus a chargeback fee — typically $25 to $100 depending on the processor and the network. Across 23 disputes in a quarter at $200 average ticket, the difference between bearing the loss and shifting it to the issuer is roughly $5,000 in direct cost, plus the indirect cost of the time spent on dispute paperwork.
The networks publish detailed matrices of which authentication outcomes earn liability shift. Visa uses ECI 05 to indicate fully authenticated transactions and ECI 06 for “attempted” authentication where the issuer was not able to fully verify. Mastercard uses ECI 02 for authenticated. ECI 07 means no 3DS was attempted at all. The exact eligibility for liability shift depends on the specific ECI value and the network’s program rules — your processor’s documentation should provide the matrix that applies to your account.
Liability shift applies. Issuer absorbs fraud chargebacks.
Partial protection — varies by network program rules.
Merchant remains liable for fraud chargebacks.
What 3D Secure Does Not Cover
This is the part most “what is 3D Secure” explanations skip, and it is the part that affects Priya the most. The liability shift is real, but it is narrower than the marketing language suggests.
If a customer disputes a transaction with a “merchandise not received” reason code, or a “service not as described” code, or a “duplicate processing” code — none of those are fraud, and 3DS does not protect them. The dispute proceeds normally and the merchant is on the hook for the response.
When a legitimate cardholder claims they did not authorize a transaction they actually did make — buyer’s remorse, family-member fraud, subscription confusion — the issuer often codes it as fraud. The 3DS authentication on that transaction technically succeeded, because the legitimate cardholder really was the one who placed the order. But the issuer can still file the dispute, and the merchant has to represent the case with their own evidence. Friendly fraud remains the largest single source of merchant disputes regardless of 3DS status.
When a patient signs up for Priya’s monthly medication-management subscription, the first payment may be 3DS-authenticated. The recurring monthly charges that follow typically are not — they are merchant-initiated transactions, and the cardholder is not present at the moment of charge to authenticate. Network rules treat these as a separate category, and most do not extend liability shift to subsequent recurring charges. This is the single most important detail for any subscription business considering 3DS.
Even if a 3DS authentication succeeds on a prepaid card transaction, the network rules typically exclude prepaid cards from liability shift coverage.
Some processors offer a lighter-weight “Data-Only” 3DS mode that sends contextual data to the issuer for fraud screening without going through the full authentication flow. The data is useful for the issuer’s risk scoring but does not produce the authentication signal that triggers liability shift.
What This Means for Priya’s Business
The telehealth model creates a specific set of 3DS calculations that differ from a typical e-commerce business.
First transactions versus recurring charges. When a new patient signs up at Northbridge Telehealth, the first card transaction is the highest-value one to authenticate — it is the moment fraud is most likely, and it earns the full liability shift if 3DS authentication succeeds. The recurring monthly subscription charges that follow are lower-fraud-risk anyway (the card is now on file with consent) but also do not get the same liability protection. Configuring 3DS to challenge first transactions and skip recurring charges is the common pattern.
Account-takeover fraud risk. Telehealth platforms maintain patient accounts with stored payment methods. If a fraudster takes over an existing account and adds a new appointment or new prescription, the charge runs against the patient’s existing card-on-file — a merchant-initiated transaction. 3DS does not help here. Account-takeover prevention is a separate workstream from 3DS — multi-factor authentication on the patient login, anomaly detection on appointment-booking patterns, and out-of-band verification for prescription changes are the controls that matter.
FSA and HSA card complications. A meaningful percentage of telehealth payments come from health-savings or flexible-spending accounts. These cards run through the same networks as regular cards but have additional eligibility rules — only certain merchant category codes are permitted, and only certain charge types are reimbursable. 3DS authentication on an FSA card works the same way as on a regular card, but the liability shift rules apply normally; the FSA-specific eligibility rules are a separate matter handled by the IIAS (Inventory Information Approval System).
HIPAA and PCI DSS interaction. 3DS authentication operates entirely within the payment-processing layer — it does not touch protected health information. Priya’s HIPAA compliance work and her 3DS implementation work do not interact directly. Her processor’s PCI compliance posture matters for both, but 3DS adds no additional HIPAA exposure.
The U.S. CFPB’s guidance on card-not-present transactions notes that merchants bear primary responsibility for verifying cardholder identity in remote transactions. 3DS is one of the more direct mechanisms for meeting that standard at the network level.
3D Secure Does Not Replace AVS and CVV
A common confusion is treating 3D Secure as a replacement for the older fraud-screening signals. It is not. AVS (Address Verification Service) and CVV (Card Verification Value) still run on every authorization regardless of 3DS status. They provide additional fraud signals at the moment of authorization that 3DS does not duplicate.
The most common pattern for serious card-not-present operations is layered: AVS and CVV at authorization (catching the obvious fraud — stolen card numbers without matching billing data), 3DS authentication on top (verifying the cardholder is actually present), and risk-based rules in the merchant’s own gateway (catching velocity attacks, geographic anomalies, and known-fraudster fingerprints). Each layer catches different patterns. Removing any one of them weakens the overall posture.
Where AVS and CVV decisions sit at the merchant’s discretion (the issuer reports back; the merchant decides what to do), 3DS authentication is binary at the network level — either the transaction earned the authentication signal or it did not. The merchant’s job is to make sure the authentication actually fired, that the resulting ECI value matches what the network requires, and that the authentication artifacts (CAVV, transaction IDs) are stored for representment if a dispute later arises.
Frequently Asked Questions
Modern 3DS 2.x is designed to minimize friction. For well-configured U.S. deployments, more than 90% of authenticated transactions go through frictionless — the cardholder sees no additional step. The remaining 10% receive a challenge, typically a one-time code sent to their phone. Conversion impact is meaningfully smaller than it was under 3DS 1.0, where every transaction required a password prompt.
No. Unlike Europe, where PSD2 Strong Customer Authentication makes 3DS effectively mandatory for most card-not-present transactions, the U.S. has no equivalent regulation. 3DS in the U.S. is optional. Merchants who enable it earn the liability shift on qualifying transactions; merchants who do not retain liability for fraud chargebacks they otherwise would have shifted.
No. The liability shift only applies to fraud-coded chargebacks — typically Visa reason code 10.4 and Mastercard equivalent codes. Service-related disputes, merchandise-not-received claims, billing errors, and friendly-fraud disputes are not protected by 3DS. The merchant remains liable for representment in all of those categories regardless of authentication status.
More on Card-Not-Present Fraud Defense
Want to Know Whether 3D Secure Would Pay for Itself on Your Account?
Most merchants like Priya enable 3D Secure based on their processor’s recommendation without seeing the math behind it — what fraction of their card-not-present volume would actually earn liability shift, what their current fraud-chargeback exposure is, and whether the conversion-rate cost of the occasional challenge is outweighed by the chargeback savings. Send us your last processing statement and we will run the numbers for your specific volume and chargeback history.
Get Your Free Statement ReviewNo obligation • No pressure • Response within one business day