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 wins 70-85% of qualifying fraud disputes. But only if you collected device fingerprint, IP, and account data at transaction time.
- 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, prevents 20% of disputes) - see Descriptors and Comms
- Make cancellation easy (1 hour of product work, prevents 10-15% of disputes) - see Refund Policy
- Send clear order confirmation emails (proof of purchase for representment)
That's it. Don't buy device fingerprinting or behavioral analytics until you're past $250K/month. Those three are free, and they cover most of the preventable disputes at your volume.
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 fraud claims; 60-90% go frictionless |
| 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 | 40% of disputers dispute again within 60 days | 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 adds a step at checkout. But 3DS 2.0 with rich data runs 60-90% frictionless. The issuer approves silently and the customer sees nothing. The other 10-40% get a challenge: OTP, biometric, or a bank app notification.
For high-dispute segments, the trade is almost always worth it. Say you drop 2-5% of conversion on a segment. If that segment throws 3x the disputes, you come out ahead.
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-20% of disputes) | 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 |
More than 10% of your chargebacks coded "unrecognized"? Your billing descriptor is wrong. Fixing it takes 10 minutes, and it can cut your dispute rate by 20-30%. 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. You need two of four data elements matching: IP, device ID, shipping address, account ID. They have to match between the disputed transaction and two or more prior undisputed transactions on the same card, at least 120 days prior. One of the two matches must be IP address or device ID. Shipping address plus account ID alone won't qualify. See Compelling Evidence 3.0.
Every transaction you process today builds your CE 3.0 defense, for disputes that arrive 3-6 months from now. Not storing device fingerprints 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 strong evidence |
| Physical goods (over $500) | Tracking + signature + delivery photo | "Not received" and "not as described" |
| 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" |
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 available today. Qualify, and your win rate on fraud chargebacks jumps to 70-85%. Qualifying disputes can also come out of your VAMP ratio.
How CE 3.0 Works
The customer says "I didn't make this purchase." CE 3.0 shows a history of undisputed purchases from the same device and location. It makes the claim implausible.
You need 2+ prior undisputed transactions on the same card, 120-365 days old. At least two of four data elements have to match. IP address, device fingerprint, shipping address, or user account ID. One of the two must be IP address or device ID. See What proof each network accepts for the full requirements and network details.
CE 3.0 in Practice
Disputed transaction (January 15):
Card: ****4242
Device: fp_abc123
IP: 98.76.54.32
Account: user@email.com
Amount: $299
Prior undisputed transactions:
Aug 10: ****4242, fp_abc123, 98.76.54.32, user@email.com, $49
Sep 22: ****4242, fp_abc123, 98.76.54.32, user@email.com, $89
Nov 5: ****4242, fp_abc123, 98.76.54.32, user@email.com, $129
CE 3.0 match: Device (fp_abc123) + IP (98.76.54.32) + Account (user@email.com)
3 of 4 elements match. 3 prior undisputed transactions.
All within 120-365 day window.
Result: CE 3.0 qualified. Submit with representment.
Expected win rate: 70-85%.
TC40 excluded from VAMP ratio.
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. That's how 10-20% of chargebacks start.
| 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 costs you about 3% of the transaction, the interchange you don't get back. A chargeback costs the whole sale plus a fee. That fee runs $0 to $30, most commonly $15, and then there's your time. Easy, fast refunds keep customers off the phone with their bank.
| Customer Action | If Refund Is Easy | If Refund Is Hard |
|---|---|---|
| Unhappy with product | Requests refund, you process it, costs $3 on a $100 order | Calls bank, files dispute, you lose the $100 and the fee on top |
| 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 | Trigger on orders > $200 from new customers |
| 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. Signature required over $150. Photo proof over $500 |
| 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. 2+ prior undisputed transactions with matching elements?
- More than 3 of 10 would have qualified on data you never collected? You've got gaps.
- Implement the missing collection points. Re-check in 30 days.
Success criteria: CE 3.0 qualification rate on new fraud disputes rises above 50%. If it doesn't, your integration isn't passing enough data elements.
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. These three actions cover 80% of the value. |
| $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 businesses have no transaction history to match against. It takes 120+ days of collecting before anything qualifies. Start now, and CE 3.0 protects you in 4-6 months.
- 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, prevents 10-20% of disputes.
- 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