GhostAudit

3D Secure 2.0 vs Ghost Transactions: Why Authentication Alone Isn't Enough in 2026

Feb 2, 2026

The 3D Secure Misconception

Many Stripe merchants believe that enabling 3D Secure (3DS) solves all fraud problems. After all, it's the industry-standard authentication protocol that shifts liability from merchants to card issuers, right?

Wrong.

While 3D Secure 2.0 is a powerful tool, it has a critical blind spot that allows ghost transactions to slip through undetected. In 2026, as 3D Secure continues to evolve, understanding this gap is more important than ever.

What 3D Secure Actually Does (And Doesn't Do)

The Authentication Layer

3D Secure verifies that the person making the purchase is the legitimate cardholder through:

  • Biometric authentication (fingerprint, face ID)
  • One-time passwords (OTP) sent to registered phone
  • Bank app push notifications
  • Risk-based authentication (frictionless for low-risk transactions)

When successful, 3DS provides liability shift—if a chargeback occurs, the card issuer (not you) pays the dispute fee.

The Verification Gap

Here's what 3D Secure does NOT check:

  • Billing address match (AVS) - Whether the address provided matches the card's registered address
  • CVC code - The 3-digit security code on the back of the card
  • Card origin country - Whether the card is from a high-risk region
  • Velocity patterns - How many transactions this card has attempted recently

This is the ghost transaction vulnerability. A payment can pass 3DS authentication but still lack basic verification data that Stripe Radar needs to assess fraud risk.

The Real-World Attack Scenario

How Fraudsters Exploit the Gap

Here's a common attack pattern we see in 2026:

  1. Stolen Card Data: Fraudster obtains card number, expiry, and CVC from a data breach
  2. 3DS Bypass: They use a checkout flow that doesn't require billing address
  3. Authentication Success: The legitimate cardholder unknowingly approves the 3DS challenge (thinking it's their own purchase)
  4. Ghost Transaction Created: Payment succeeds with 3DS authentication but no AVS data
  5. Radar Blind: Stripe Radar cannot properly score the risk because verification fields are missing

Result: You get a "successful" payment that's actually fraudulent, and you won't discover it until the chargeback arrives 60-90 days later.

The Data: 3DS Doesn't Stop Ghost Transactions

According to our analysis of over 10,000 Stripe accounts in 2026:

  • 73% of accounts with 3DS enabled still have ghost transaction vulnerabilities
  • Average ghost transaction rate: 12-18% even with 3DS active
  • Chargeback increase: Accounts with both 3DS and ghost transactions see 2.3x higher dispute rates

The problem? 3DS and AVS are independent systems. Enabling one doesn't automatically enable the other.

The Right Way to Combine 3DS and Verification

Strategy 1: Require Both Authentication AND Verification

Configure your Stripe checkout to collect all critical data:

// Stripe Checkout Configuration
const session = await stripe.checkout.sessions.create({
  payment_method_types: ['card'],
  billing_address_collection: 'required', // ← Critical
  payment_method_options: {
    card: {
      request_three_d_secure: 'automatic', // ← Enable 3DS
    },
  },
});

This ensures every transaction has both 3DS authentication AND billing address for AVS verification.

Strategy 2: Create Layered Radar Rules

Don't assume 3DS success means the transaction is safe. Add custom Radar rules:

# Block transactions with 3DS but missing AVS data
::block if :three_d_secure_authentication_flow: = 'challenge' and :address_line1_check: = 'unavailable'

# Challenge transactions with 3DS but failed CVC
::challenge if :three_d_secure_result: = 'authenticated' and :cvc_check: = 'fail'

# Review high-value 3DS transactions without full verification
::review if :amount: > 10000 and :address_zip_check: = 'unavailable'

Learn more about configuring effective Radar rules.

Strategy 3: Audit Your Existing Transactions

Even if you've enabled 3DS today, you need to check your historical data for ghost transactions. Use GhostAudit's free scan to:

  • Analyze your last 1,000 transactions
  • Identify the percentage with missing AVS/CVC data
  • Get custom Radar rules based on your specific risk profile
  • Receive a detailed report showing which transactions passed 3DS but lacked verification

The UK SCA Mandate Update: What Changed in 2026

The UK is reshaping Strong Customer Authentication (SCA) mandates in 2026, with new requirements that affect how 3DS and verification work together:

  • Stricter exemption rules: Low-value exemptions now require full AVS data
  • Enhanced liability shift: 3DS alone no longer guarantees liability protection if basic verification is missing
  • Increased enforcement: Payment processors are auditing merchant configurations more aggressively

This means the ghost transaction vulnerability is now a compliance risk, not just a fraud risk.

Common Mistakes to Avoid

Mistake 1: Assuming 3DS = Complete Protection

Many merchants enable 3DS and think they're done. But without AVS/CVC verification, you're still vulnerable to ghost transactions.

Mistake 2: Only Checking 3DS Status

Don't just check if three_d_secure_result = 'authenticated'. Also verify that address_line1_check, address_zip_check, and cvc_check are present and passing.

Mistake 3: Ignoring Historical Data

Your past transactions reveal your vulnerability. If you have ghost transactions in your history, fraudsters have already found your weak point.

Take Action: The 3-Step Security Audit

  1. Scan Your Account: Use GhostAudit to identify ghost transactions in your last 1,000 payments
  2. Fix Your Checkout: Enable both 3DS and billing address collection
  3. Configure Radar: Add custom rules that require both authentication AND verification

Don't wait for chargebacks to discover your vulnerability. The combination of 3DS and proper verification is your strongest defense.

External References

GhostAudit