Defending Against Fraud Losses
- Preventing fraud and preventing fraud losses are different problems. Blocking stolen cards is one job. Not losing money on disputes is another.
- 3DS is your strongest friendly fraud defense. It shifts liability to the issuer. Use fraud rules to trigger 3DS on high-dispute segments instead of declining.
- Visa CE 3.0 can beat a 10.4 fraud dispute. But only if you stored IP, device and account data at transaction time. Checklist
- Evidence collection rules add zero checkout friction. They run silently, storing the data you'll need if a chargeback lands weeks later.
- Pre-transaction defenses stop the chargeback from ever being filed. Clear descriptors, visible terms, easy cancellation.
Preventing fraud means stopping criminals from using stolen cards at your store. Preventing fraud losses means not losing money when a chargeback arrives, legitimate or not.
Your highest-impact fraud prevention isn't technical. It's operational:
- Fix your billing descriptor (10 minutes) - see Descriptors and Comms
- Make cancellation easy (1 hour of product work) - see Refund Policy
- Send clear order confirmation emails (proof of purchase for representment)
Start with those fixes. Buy device fingerprinting or behavioral tools when a measured gap justifies the cost, not at a universal sales cutoff. Check what your processor already collects.
For third-party fraud, the answer is blocking: rules, ML, device intelligence. Friendly fraud is different. The real customer disputes a real purchase, so blocking does nothing. The customer IS legitimate. The answer is liability shift, evidence collection, and making a refund easier than a dispute.
Layer 1: 3DS as Liability Shift
3D Secure gets sold as a fraud prevention tool. For friendly fraud, it's a loss prevention tool. The real cardholder authenticates with their bank, then disputes, claiming "I didn't authorize this." The issuer bears the liability, not you.
When to Trigger 3DS for Loss Prevention
Use fraud rules to trigger 3DS on high-dispute segments. Not just high-fraud ones:
| Segment | Why This Segment Disputes | 3DS Impact |
|---|---|---|
| Digital goods | No physical proof of delivery, buyer's remorse | Liability shift on eligible fraud claims; track your own challenge rate |
| Subscriptions (renewal) | "I forgot I signed up," "I thought I cancelled" | Liability shift; send renewal reminder email as backup evidence |
| High-value + new customer | Highest dispute rate segment across all merchants | Liability shift; most issuers approve frictionless for verified cardholders |
| Customers with prior disputes | A past dispute in your own records flags repeat risk | Liability shift on the repeat; acceptable friction given history |
| Electronics, luxury, resellable goods | High resale value attracts "receive and dispute" abuse | Liability shift; combine with signature delivery |
What 3DS Protects (and What It Doesn't)
3DS liability shift covers fraud reason codes only (Visa 10.4, Mastercard 4837, Amex F29). It does nothing for "not received," "not as described," "cancelled recurring," or processing errors. So 3DS alone isn't enough, and you need the evidence layers below for everything it doesn't cover. See 3D Secure for the full list.
The Friction Tradeoff
3DS can add a step at checkout. With a frictionless flow, the issuer authenticates without asking the customer to act. Other transactions get a challenge: OTP, biometric, or a bank app notification. Authentication still needs to be followed by authorization.
For high-dispute segments, test the trade. Compare completed sales and fraud losses before and after on the same product and customer segment. Include lost margin, dispute costs and any liability shift. A higher dispute count alone won't tell you whether the trade pays.
If your fraud rules would decline a transaction, trigger 3DS instead. They authenticate, you keep the sale and get liability shift. They fail or abandon, you lose nothing a decline wouldn't have cost you. More in Building Fraud Rules: Rules That Trigger 3DS.
Layer 2: Evidence Collection at Every Stage
Evidence wins chargebacks. But you can't collect it after the dispute arrives. You've got to collect at every stage of the transaction, silently, with no friction on the customer.
Pre-Transaction: Set Expectations
These prevent the dispute from being filed in the first place.
| Action | What It Defeats | Effort |
|---|---|---|
| Clear billing descriptor | "I don't recognize this charge" | 10 minutes to fix in processor settings |
| Descriptor includes phone or URL | Customer contacts you instead of their bank | 10 minutes |
| Terms checkbox at checkout (not just a link) | "I didn't agree to this" claims | 1 hour dev time |
| Cancellation policy visible before purchase | "I didn't know I couldn't cancel" | Content update |
| Delivery timeline shown before buy button | "I expected it sooner" complaints | Content update |
| Renewal reminder email (7 days before charge) | "I forgot about this subscription" disputes | Email automation setup |
Customers saying they don't recognize your charge? Check your billing descriptor on a real statement. Fixing it takes 10 minutes. Compare recognition-related disputes before and after on the same product and payment channel. Check yours at Descriptors and Comms.
At Transaction Time: Collect Silently
These run in the background during checkout. The customer sees nothing.
| Data Point | Why You Need It | How to Collect |
|---|---|---|
| Device fingerprint | CE 3.0 matching against prior transactions | JavaScript SDK (Stripe, Sift, ThreatMetrix, or Sardine) |
| IP address | CE 3.0 matching + geolocation evidence | Server-side, every processor captures this |
| Account ID | CE 3.0 matching + proves account ownership | Your authentication system |
| Shipping address | CE 3.0 matching + delivery confirmation | Checkout form |
| Terms acceptance timestamp | Proves customer agreed to policy | Log the click event with timestamp and IP |
| Product page snapshot | Defeats "not as described" claims | Cache the product listing they saw at purchase time |
The CE 3.0 minimum. Match at least two data points across the disputed transaction and two earlier purchases on the same card, each more than 120 and no more than 365 days before the dispute. One match must be IP or device. Shipping address plus account ID alone won't qualify. Full checklist.
Every transaction you process today builds your CE 3.0 defense for disputes that arrive months from now. Not storing IP and device data against transactions? Start today.
"Are we storing device fingerprint and IP address with every transaction in a way we can query later? When a chargeback arrives, can we pull matching prior transactions for CE 3.0 submission within 24 hours?"
At Fulfillment: Prove Delivery
| Business Type | Evidence to Collect | What It Defeats |
|---|---|---|
| Physical goods (under $150) | Tracking number + carrier delivery confirmation | "Not received" (13.1) |
| Physical goods (over $150) | Tracking + signature confirmation | "Not received" (13.1) with stronger delivery records |
| Physical goods (over $500) | Tracking + signature + delivery photo | Delivery evidence; "not as described" also needs proof of what was supplied |
| Digital goods | Download timestamp + device/IP at download + access log | Fraud (10.4) via CE 3.0 |
| SaaS/subscriptions | Login timestamps + feature usage logs + API call logs | "I didn't use it" and "I cancelled" |
| Services | Completion confirmation + client sign-off + deliverable access logs | "Service not rendered" |
The $150 and $500 bands above are suggested starting points. Tune them to order value, losses and carrier costs; check your processor's evidence requirements.
Post-Purchase: Prove Engagement
Engagement after the purchase date is powerful in representment, because it proves the customer got value.
| Signal | Where to Find It | Representment Value |
|---|---|---|
| Customer logged in after purchase | Auth logs | Proves they accessed the product/account |
| Customer used the product | Usage analytics, API logs | Proves they received and engaged |
| Customer contacted support | Support ticket system | Proves they acknowledged the purchase |
| Customer left a review | Review platform | Proves they received and evaluated the product |
| Customer made a subsequent purchase | Transaction history | Proves ongoing relationship and satisfaction |
| Customer clicked renewal reminder email | Email analytics | Proves they were aware of the upcoming charge |
Layer 3: Visa Compelling Evidence 3.0
CE 3.0 is the strongest friendly-fraud defense on Visa. Qualify, and Visa gives you liability protection on the 10.4 dispute. Visa may also leave qualifying disputes out of your VAMP ratio. Full requirements.
How CE 3.0 Works
The customer says "I didn't make this purchase." CE 3.0 shows earlier purchases on the same card, from the same device or IP, that the issuer never reported as fraud. It makes the claim implausible.
You need two earlier purchases on the same card, each more than 120 and no more than 365 days before the dispute, with at least two matching data points, one of them IP or device. What proof each network accepts.
CE 3.0 in Practice
Disputed purchase: 15 January 2027
Dispute submitted and processed: 16 January 2027
Potential prior purchases: 10 July and 22 August 2026
Same card; no issuer fraud reports
Matching data on all three: public IP address and customer login ID
A 5 November 2026 purchase is too recent for the 120-day test.
Result: meets the history test on these facts. Your processor submits it.
How to Implement CE 3.0
| Platform | CE 3.0 Support | What You Need to Do |
|---|---|---|
| Stripe | Built-in (automatic for Radar users) | Enable Radar. Stripe automatically submits CE 3.0 data when available. |
| Adyen | Supported via dispute API | Store device fingerprint and IP. Submit via dispute response API. |
| Braintree | Supported via evidence submission | Collect and store device/IP data. Submit with representment. |
| Sift/Forter/Signifyd | Varies by integration | These vendors collect device data. Confirm they pass it to your processor for CE 3.0 submission. |
| Manual/other | Via Visa's VROL platform | You must collect, store, and submit the matching data yourself. |
Stripe attempts CE 3.0 on qualifying disputes if you use Radar. But Stripe can only use the data it has. If your checkout doesn't pass device fingerprint through Stripe.js, CE 3.0 can't match on device ID. Make sure your integration collects all four elements. Run stripe disputes list to see whether CE 3.0 fired on recent disputes.
Layer 4: Pre-Transaction Defenses
These stop the chargeback from being filed. They cost almost nothing, and they cut dispute volume before evidence or representment enters the picture.
Billing Descriptor
Your billing descriptor is the text on the customer's card statement. They don't recognize it, they call their bank. Track how often that happens in your own disputed orders.
| Bad Descriptor | Good Descriptor | Why |
|---|---|---|
| PAY*ACME | ACME WIDGETS 800-555-1234 | Customer recognizes the business name and can call you instead of their bank |
| STRIPE TRANSFER | MYSTORE.COM | Generic processor name tells the customer nothing |
| PMT*12345 | PETBOX MONTHLY BOX | Transaction ID is meaningless to a customer checking their statement |
Fix this today. It's 10 minutes in your processor's dashboard. See Descriptors and Comms.
Easy Cancellation
Hard-to-cancel subscriptions cause chargebacks. Can't find your cancel button? They call their bank instead.
There's an evidence bonus too: every self-service cancellation leaves you timestamped proof. When someone who never cancelled claims "I cancelled," you can show they didn't.
See Refund Policy Design: Making Cancellation Easy for the checklist, the post-cancellation flow, and proof logging.
Purchase Confirmation
Send a confirmation email or SMS immediately after purchase with:
- Business name (matching your billing descriptor)
- Product/service purchased
- Amount charged
- Expected delivery date
- How to contact you for help
- How to request a refund
That email does two jobs. It prevents "I don't recognize this" disputes, and it becomes evidence in representment.
Refund-Before-Dispute
A refund returns the sale amount. You may also lose processing fees and fulfillment costs. Stripe, for example, doesn't return the original processing fees. A chargeback reverses the sale too, with your processor's dispute fee and your response time on top. Compare your own costs before a dispute is filed. Once a formal chargeback is open, use the dispute case, not a separate refund.
| Customer Action | If Refund Is Easy | If Refund Is Hard |
|---|---|---|
| Unhappy with product | Requests refund before a dispute is filed; you return the sale and check retained fees and fulfillment costs | Calls bank, files dispute, the sale is reversed and dispute costs can follow |
| Forgot about subscription | Contacts you, you cancel and refund, they stay on good terms | Doesn't remember your company name, disputes, you lose the sale plus the fee |
| Didn't recognize charge | Sees your descriptor, finds your phone number, calls you | Calls bank, files "fraud" chargeback |
See Refund Strategy for the refund-vs-fight framework with worked dollar examples. Refund Policy Design covers the customer-facing language.
Putting It All Together by Business Model
Physical Goods
| Layer | Action |
|---|---|
| 3DS | Test on a high-loss segment; choose the amount and new-customer definition from your own fraud history |
| Pre-transaction | Clear descriptor, order confirmation with tracking ETA |
| At transaction | Collect device fingerprint, IP, account ID for CE 3.0 |
| Fulfillment | Tracking on every order. Start by testing signature over $150 and photo proof over $500; tune against losses and carrier costs |
| Post-purchase | Delivery confirmation email with "contact us if there's an issue" CTA |
Digital Goods / SaaS
| Layer | Action |
|---|---|
| 3DS | Trigger on all first purchases (highest dispute category) |
| Pre-transaction | Clear descriptor, instant confirmation with product access link |
| At transaction | Collect device fingerprint, IP, account ID. Log terms acceptance |
| Fulfillment | Log download timestamp, activation, and device at download |
| Post-purchase | Log every login, feature usage, and API call. This is your CE 3.0 goldmine. |
Subscriptions
| Layer | Action |
|---|---|
| 3DS | Trigger on initial signup. Subsequent renewals use stored credentials (no 3DS). |
| Pre-transaction | Clear descriptor with "MONTHLY" or "ANNUAL." Easy cancellation flow. |
| At transaction | Collect device fingerprint and IP at signup for CE 3.0 baseline |
| Renewal | Send reminder email 7 days before charge. Log email delivery confirmation. |
| Post-purchase | Log usage between renewals. A customer who logged in 15 times between charges didn't "forget" they were subscribed. |
Test to Run
Evidence collection audit, 30 days:
- Pick 10 recent chargebacks you lost.
- For each one, check what you had stored. Device fingerprint, IP, delivery confirmation, terms acceptance.
- Then ask whether CE 3.0 would have qualified. Two earlier purchases on the card, more than 120 and no more than 365 days before the dispute, with two matching data points, one of them IP or device?
- Record every case that would have qualified with data you could have collected. Prioritize gaps by recoverable amount, implementation cost and privacy requirements; a fixed count isn't the decision rule.
- Implement the missing collection points. Re-check in 30 days.
Success criteria: Your processor can explain which cases qualify, which fail and why. Track those results instead of assuming every shortfall is missing data.
Scale Callout
| Volume | Focus |
|---|---|
| Under $100K/month | Fix your billing descriptor. Enable 3DS on your highest-dispute product category. Start collecting device fingerprint and IP with every transaction. Track recognition-related disputes, fraud losses and evidence gaps before and after each change. |
| $100K-$500K/month | Add: evidence collection rules by business model. Set up renewal reminder emails. Enable CE 3.0 submission (confirm with your processor). Track CE 3.0 qualification rate monthly. |
| $500K-$1M/month | Add: selective 3DS on all high-dispute segments (not just high-fraud). Post-purchase activity logging. Monthly evidence audit on lost chargebacks. |
| Over $1M/month | Automated evidence assembly for representment. Real-time CE 3.0 qualification check when disputes arrive. A/B test 3DS on borderline segments. Dedicated dispute analysis. |
Where This Breaks
- True third-party fraud. Someone actually stole the card. No amount of evidence collection helps. The cardholder is the victim. This page is for friendly fraud and grey-area disputes. For stolen card prevention, see Building Fraud Rules and Device Fingerprinting.
- 3DS on recurring transactions. Liability shift applies to the initial authenticated transaction. Renewals are merchant-initiated, so they get none. That's why renewal reminder emails and usage logging matter for subscriptions.
- CE 3.0 cold start. New shop? Ask your processor whether qualifying history at other merchants is usable from disputes processed on 24 October 2026. If it can't use that route, build your own qualifying history.
- International transactions. Delivery confirmation standards vary by country. "Delivered" in the US means the carrier confirmed at the address. Elsewhere the last tracking update is "arrived at destination post office." For cross-border, use a carrier that confirms delivery in the destination country.
- Guest checkout and CE 3.0. No accounts means no account ID to match on. You can still match device fingerprint, IP, and shipping address, but you're down to three elements. Worth asking whether account creation fits your business.
- Over-triggering 3DS. Put 3DS on everything and your conversion drops. The goal is selective 3DS on high-dispute segments. Test before you widen it. See 3DS Rollout Strategy.
Next Steps
Just getting started?
- Fix your billing descriptor. 10 minutes. Compare recognition-related disputes before and after on the same product and payment channel.
- Enable 3DS on your highest-dispute segment. Biggest single impact.
- Confirm your processor is collecting device fingerprint and IP for CE 3.0.
Building your evidence system?
- Set up evidence collection rules. Zero friction, background capture.
- Review CE 3.0 requirements so you know what data you need.
- Audit 10 lost chargebacks and find your evidence gaps.
Fighting friendly fraud specifically?
- Understand the pattern. Why customers dispute legitimate purchases.
- Design your refund policy. A refund is cheaper than a chargeback.
- Build winning evidence packages. What issuers actually look for.
Related
- 3D Secure - Liability shift implementation and rollout
- Building Fraud Rules - Rules that trigger 3DS and evidence collection
- Compelling Evidence - CE 3.0 details and network requirements
- Winning Evidence - What issuers look for in representment
- Friendly Fraud - Why customers dispute and detection signals
- Refund Policy Design - Refund vs. fight decision frameworks
- Refund Strategy - Operational refund decisions
- Descriptors and Comms - Billing descriptor best practices
- Device Fingerprinting - Device intelligence for CE 3.0 data
- Chargeback Prevention - Full prevention hierarchy
- Chargeback Alerts - Pre-dispute resolution
- Network Programs - VAMP ratio and CE 3.0 exclusion
- Running Fraud Operations - Operational cadence
- Subscriptions & Recurring - Recurring billing compliance