Why Stripe Disputes Get Lost Even With Full Verification

Introduction

A merchant does everything the payment processor recommends. Radar rules are tuned to flag risky transactions. CVC and ZIP verification are both switched on. The transaction clears without a hitch. Weeks later, a dispute lands in the dashboard: "transaction not authorized by cardholder." The evidence is submitted, the case is reviewed, and the merchant still loses the money.

This is one of the most frustrating realities of running an online business that accepts card payments. It isn't a bug in Stripe, and it isn't necessarily a sign that your fraud settings are wrong. It's a structural feature of how card networks assign liability, and it exposes a gap that no amount of address or security-code checking can close on its own. This article breaks down why that gap exists, where 3D Secure fits into the picture, and what a realistic fraud-prevention strategy looks like once you accept that some disputes are simply not preventable through verification alone.

Table of Contents

1. What CVC and ZIP Checks Actually Verify
2. The Friendly Fraud Problem
3. Why Radar Rules Have a Ceiling
4. Recommended Radar Rule Configurations
5. How 3D Secure Shifts Liability
6. The Real Cost of Forcing 3DS on Every Payment
7. A Practical Framework for Applying 3DS Selectively
8. Building an Irrefutable Dispute Evidence Package
9. Common Mistakes Merchants Make
10. Best Practices for Reducing Chargeback Losses
11. Key Takeaways
12. References
13. Conclusion

What CVC and ZIP Checks Actually Verify

CVC (the three or four-digit code on the card) and AVS (address verification, which checks the billing ZIP or postal code) were never designed to confirm that the person entering a payment is the legitimate cardholder. They confirm something narrower: that the person typing in the numbers has physical or written access to the card and its billing details.

That distinction matters more than it sounds. If a cardholder hands their card to a partner, a roommate, or an employee, that second person can pass every one of these checks perfectly. The CVC matches because it's printed on the card. The ZIP code matches because the cardholder told them what it is, or because it's public knowledge tied to a shared address. None of this proves consent for a specific transaction happening right now, it only proves the data lines up.

Card networks built these checks in the 1990s and 2000s to fight a different problem: bulk card-number theft and remote guessing attacks, where a fraudster has a stolen card number but not the physical card or the cardholder's personal details. Against that threat, CVC and AVS work well. Against a person who was voluntarily given the card, they are close to irrelevant.

The Friendly Fraud Problem

The scenario described at the start of this article has a name in the payments industry: friendly fraud, sometimes called first-party misuse. It covers any case where the actual cardholder or someone they gave explicit access to, completes a purchase, and the cardholder later disputes it as unauthorized.

Friendly fraud typically shows up in a few recognizable patterns:

• A subscription the cardholder forgot about, disputed instead of cancelled.
• A shared card used by a family member or partner, followed by a dispute after a falling-out or lack of communication.
• A legitimate purchase where the buyer simply doesn't recognize the billing descriptor on their statement.
• Deliberate abuse, where a buyer receives the goods or service and then disputes the charge specifically to get a refund without returning anything.

From the card network's perspective, all of these usually get coded the same way: "transaction not recognized" or "not authorized." The bank issuing the card has little incentive to dig deeper, because provisional credit protects the cardholder immediately, and the dispute process defaults to trusting the cardholder's account of events unless the merchant can prove otherwise.

This is the core asymmetry merchants run into. Verification tools prove that correct data was entered. They do not prove intent, and disputes are ultimately a question of intent and consent, not data accuracy.

Why Radar Rules Have a Ceiling

Stripe Radar is a risk-scoring engine. It looks at signals like device fingerprinting, IP geolocation, velocity of transactions, email domain age, and known fraud patterns, and it assigns a risk score that rules can act on blocking, flagging for review, or requiring extra verification.

Radar is genuinely good at what it's built for: catching stolen card numbers being tested or used by someone with no relationship to the cardholder. Where it hits a ceiling is exactly the friendly fraud case. If the purchase comes from a device the cardholder has used before, from a familiar location, with no unusual velocity, Radar has no reason to flag it. The transaction is low risk by every signal Radar tracks, because the actual cardholder authorized the card to be used, even if not for this specific purchase.

Radar scores the likelihood that a transaction is criminal fraud from a stranger. It does not, and cannot, score the likelihood that the person who owns the card will later regret or dispute a purchase they personally enabled. Tuning Radar rules more aggressively will reduce stolen-card fraud. It will do very little against friendly fraud, and pushing the rules too far usually just blocks legitimate customers instead.

Recommended Radar Rule Configurations

Since Radar's default scoring won't catch friendly fraud on its own, the next step is translating that risk-based logic into rules you can actually deploy. Stripe's rule attributes distinguish between a numeric risk score (0–99) and an overall risk level (Normal, Elevated, Highest); the examples below use the categorical :risk_level: attribute, which is what supports values like 'elevated' and 'highest'.

1. Dynamic 3DS for Elevated Risk

Trigger 3DS verification when Stripe's overall risk level is elevated, or when there is a geographic mismatch between the card and the customer.

# Trigger 3DS if the overall risk level is elevated
Request 3D Secure if :risk_level: = 'elevated'

# Trigger 3DS if the IP address country does not match the card issuing country
Request 3D Secure if :card_country: != :ip_country:

2. Hard Blocks for High-Risk and Verification Failures

Do not allow high-risk payments or transactions that fail basic validation checks to reach the 3DS stage. Block them immediately to save processing fees and administrative overhead.

# Block payments at the highest risk level
Block if :risk_level: = 'highest'

# Block if the CVC check fails completely
Block if :cvc_check: = 'fail'

# Block if the postal code verification fails (where applicable)
Block if :address_zip_check: = 'fail'

# Trigger 3DS if this card has not been used before on this customer profile
Request 3D Secure if :is_new_card_on_customer:

Test any new rule against historical data before enabling it, since a rule that looks reasonable on paper can still block legitimate customers depending on your typical transaction mix.

How 3D Secure Shifts Liability

3D Secure (3DS) — the protocol behind Visa Secure, Mastercard Identity Check, and similar bank-side authentication flows, works differently from CVC or AVS. Instead of checking static data on the card, it routes the transaction to the cardholder's bank at checkout, and the bank authenticates the cardholder directly, often through a one-time passcode, a banking app approval, or biometric confirmation.

The practical effect that matters most to merchants is liability shift. Under card network rules, when a transaction is successfully authenticated through 3DS, the liability for a fraud-related chargeback generally moves from the merchant to the issuing bank. If a dispute later comes in coded as unauthorized use, and the transaction went through 3DS authentication, the merchant has a materially stronger position — in many cases the dispute can be won automatically, or the issuer absorbs the loss instead.

This matters specifically for the shared-card scenario. If the actual cardholder had to approve the transaction through their own banking app or one-time code, it becomes much harder for them to later claim the purchase was unauthorized, since the bank has a record of their direct approval. It doesn't make friendly fraud disappear entirely — a cardholder who authenticated the transaction themselves and now regrets it can still attempt a dispute, but it closes off the "I never approved this" defense far more effectively than CVC or ZIP matching ever could.

3DS authentication does not guarantee a dispute win. It changes who is liable for certain dispute categories (typically fraud-coded disputes), but disputes coded as "product not as described," "service not received," or similar non-fraud reasons are not automatically resolved by 3DS. Liability shift is a fraud-liability tool, not a universal shield.

The Real Cost of Forcing 3DS on Every Payment

Given that liability shift, the obvious instinct is to require 3DS on every single transaction. In practice, most payment teams don't do this, and there's a concrete reason why.

3DS adds a step to checkout: a redirect, a passcode entry, an app approval, or a wait for a push notification. Every additional step is an opportunity for the customer to abandon the purchase, get distracted, mistype a code, or simply give up if their bank's authentication flow is slow or confusing. Payment providers, including Stripe, generally acknowledge this as a checkout-friction tradeoff, and it tends to affect mobile users and international cardholders most, since their banks' authentication flows vary widely in polish.

The tradeoff, in plain terms:

• More 3DS coverage → stronger liability protection, lower fraud losses, but higher checkout abandonment and a worse experience for legitimate customers.
• Less 3DS coverage → smoother checkout, better conversion, but full liability exposure on every transaction that isn't authenticated.

There's no universal right answer here. A business selling low-margin, high-volume physical goods with tight conversion targets will weigh this differently than a subscription service selling access to something that's easy to dispute after the fact. The right setting depends on average order value, typical customer geography, historical dispute rate, and how much margin the business can absorb per lost dispute.

A Practical Framework for Applying 3DS Selectively

Rather than treating 3DS as all-or-nothing, most mature payment setups apply it conditionally. A few approaches worth considering:

Risk-based triggering. Use Radar's risk score (or an equivalent) to require 3DS only on transactions above a certain risk threshold, rather than every checkout. This targets friction at the transactions most likely to need it.

Value-based triggering. Require 3DS above a specific order value. Losing a $15 dispute is annoying; losing a $1,500 dispute is a different category of problem. Many merchants set a value threshold where the liability-shift benefit clearly outweighs the conversion cost.

Exemption-aware configuration. Under regulations like PSD2 in Europe, there are defined exemptions: low-value transactions, trusted beneficiaries, low-risk transaction analysis that allow skipping 3DS while still keeping some liability protection. Depending on your region and card network agreements, you may be able to use exemptions instead of blanket enforcement.

New customer vs. returning customer logic. First-time card usage on an account carries more uncertainty than a card that's completed several transactions without incident. Applying stricter checks to first-time or newly added cards, and lighter checks to established, low-dispute customers, is a common middle ground.

Subscription and recurring billing consideration. 3DS is typically required only on the initial transaction for recurring billing under most network rules, since the cardholder can't be expected to authenticate every renewal. Confirm this setup specifically for subscription products, since misconfiguration here is a frequent source of unnecessary declines.

None of these approaches eliminates friendly fraud entirely. They're about controlling exposure, pushing authentication toward the transactions where liability shift actually changes the outcome, while keeping checkout fast for everything else.

Building an Irrefutable Dispute Evidence Package

When friendly fraud bypasses your defenses, your only recourse is the formal Stripe dispute process. Card issuers review evidence programmatically and manually, and to win, your evidence package must link the digital identity of the purchaser to the physical consumer of the product or service. Even with 3DS in place for some transactions, disputes will still happen, and evidence quality matters. Evidence that tends to perform better in review includes:

• Proof of delivery or service usage: shipment tracking with delivery confirmation, login timestamps, download logs, or usage records showing the product or service was actually accessed after purchase.
• Communication history: support tickets, emails, or chat logs referencing the order, especially anything showing the customer previously acknowledged the purchase.
• IP and device consistency: matching IP address, device ID, or account history across multiple orders from the same customer, which undercuts a claim that "someone else" made the purchase.
• Authentication records: if 3DS was used, include the authentication confirmation directly; this is often the single strongest piece of evidence for fraud-coded disputes.
• Clear terms acknowledgment: for subscriptions, evidence that the customer agreed to recurring billing terms and received renewal notifications.

What tends to perform poorly is evidence that only proves data matched (CVC, AVS results) without proving usage or intent, since that's exactly the gap friendly fraud exploits. AVS and CVC match results are worth including, but they should support a larger evidence package, not stand as the entire case.

Common Mistakes Merchants Make

• Treating Radar and AVS/CVC as complete fraud protection. They reduce one category of fraud (stolen card data) and do little against first-party misuse.
• Applying 3DS uniformly without measuring the conversion impact. Blanket enforcement can quietly erode revenue without a corresponding drop in disputes, if the disputes you're facing are mostly friendly fraud rather than stolen-card fraud.
• Submitting only transaction and verification data as dispute evidence. This proves the payment was processed correctly, not that the cardholder consented, which is usually the actual point in dispute.
• Ignoring dispute reason codes. Different dispute categories need different evidence. Evidence built for "unauthorized transaction" often won't address a "product not received" dispute, and vice versa.
• Not tracking dispute patterns by customer segment. Repeated disputes from the same billing descriptor, region, or product line are a signal worth investigating and adjusting Radar rules or 3DS thresholds around.

Best Practices for Reducing Chargeback Losses

• Apply 3DS selectively based on risk score, order value, or new-customer status rather than universally or not at all.
• Keep detailed usage and delivery logs for every order, even digital ones, since they're the strongest dispute evidence available.
• Make billing descriptors clearly recognizable, tied to your brand name, to reduce "I don't recognize this charge" disputes that aren't actually fraud.
• Send order confirmation and renewal notices proactively, especially for subscriptions, to reduce disputes rooted in forgotten purchases.
• Review dispute outcomes periodically to identify whether losses cluster around specific products, price points, or customer segments, and adjust Radar rules accordingly.
• Set realistic expectations: a small percentage of disputes, particularly friendly fraud, will be effectively unwinnable regardless of the evidence submitted. Budgeting for this as a cost of doing business is more sustainable than treating every loss as a process failure.

Key Takeaways

• CVC and ZIP/AVS checks confirm that entered data matches the card, not that the transaction was authorized by the cardholder for that specific purchase.
• Friendly fraud, where the actual cardholder or someone they gave the card to disputes a legitimate purchase, sits outside what verification tools are built to catch.
• Radar is effective against stolen-card fraud but has limited effect on friendly fraud, since the risk signals for a shared card often look identical to a legitimate purchase.
• 3D Secure shifts liability for many fraud-coded disputes from the merchant to the issuing bank, but only for transactions that go through authentication, and only for certain dispute categories.
• Applying 3DS selectively, based on risk, order value, or customer history, is usually more sustainable than enforcing it universally.
• Strong dispute evidence proves usage and consent, not just that verification data matched.

References

• Stripe: Fraud prevention rules (Radar)
• Stripe: Radar rules reference and supported attributes
• Stripe: 3D Secure authentication
• Stripe: Liability shift with 3D Secure

Conclusion

Losing a dispute after doing everything the payment processor recommends isn't a sign of a broken fraud strategy. It's a sign that verification tools and liability rules are solving different problems than the one friendly fraud creates. CVC and ZIP checks confirm data. Radar catches abnormal behavior. 3D Secure shifts who's on the hook for certain fraud claims. None of these was ever designed to determine whether a cardholder truly consented to a purchase made with their own card, by someone they gave it to.

The realistic path forward isn't finding one setting that eliminates disputes. It's layering these tools deliberately, tighter authentication where the stakes justify the friction, solid evidence practices for the disputes that do come in, and an honest acknowledgment that a portion of chargeback losses will remain outside what any merchant can fully control.