Visa Compelling Evidence 3.0: How Subscription Founders Win Friendly Fraud Disputes

Visa Compelling Evidence 3.0 is a rule framework that lets you deflect certain fraud-coded disputes by proving the cardholder is a repeat customer. Instead of debating whether one specific charge was authorized, you show a trail of prior undisputed transactions from the same person, on the same device or IP, with the same account. For subscription founders, who hold months of customer history by default, it is the strongest weapon against friendly fraud that has ever existed.

The catch: it only works if you kept the receipts, literally. The data has to exist before the dispute arrives. This post is about what to log starting today, and how to use it when a 'this was not me' dispute lands.

Why fraud codes are the friendly fraud hiding spot

When a customer disputes a subscription charge they actually made, their bank rarely files it as 'I changed my mind'. It goes in as fraud, typically Visa reason code 10.4, other fraud in a card-absent environment. From the bank's side, 'I do not recognize this charge' and 'my card was stolen' start in the same bucket.

That is brutal for honest merchants, because fraud disputes are historically the hardest to win. You are asked to prove a negative: that the cardholder, who says they did not do it, actually did. Before CE 3.0, your evidence was mostly about the single disputed transaction. Now the rules let you zoom out to the whole relationship.

How CE 3.0 actually works

The core mechanic: if you can show at least two prior transactions from the same cardholder that were not disputed, that share key data elements with the disputed transaction, and that fall within the program's time window, the liability picture changes. The shared elements Visa cares about are things like device fingerprint, IP address, and account login credentials.

Think about what that means for a SaaS. A customer who signed up eight months ago, logged in from the same laptop ever since, and paid seven successful invoices is about as 'known' as a cardholder gets. Under the old rules, their 'not me' dispute was a coin flip. Under CE 3.0, your history is the argument.

• •Two or more prior undisputed transactions on the same account, within the program window.
• •Matching core data elements between those transactions and the disputed one: device, IP, login credentials.
• •Records you can actually produce: timestamps, IPs, device identifiers, invoice history, delivery or usage proof.

The data to start logging today

Most founders already have half of this without realizing it. The discipline is storing it in a form you can export during a 7-to-10-day dispute window, not hunting through logs while the deadline burns.

• •Signup record: timestamp, email, IP address, and the user agent or device fingerprint if you can capture it.
• •Login history: timestamps and IPs, which most auth systems already record. Make sure you can export per-user.
• •Billing history: every invoice and charge ID, which Stripe gives you, plus the receipts you sent for each one.
• •Usage proof: last-active dates, key actions, anything showing the product was actually used after signup.
• •Communication trail: receipts, renewal reminders, and dunning emails, with the amounts and dates they named.

That last one deserves emphasis. A dunning email that says 'your $49 payment failed, we will retry on Thursday' is evidence the customer was told, in writing, exactly what would be charged and when. When Thursday's retry succeeds and a 'fraud' dispute shows up a month later, that email is part of your compelling evidence. This is one more reason silent retries are expensive in ways that never show on a pricing page.

Working a dispute with CE 3.0 in mind

When a 10.4 dispute lands on a subscription account, run this sequence. First, check the history: how many successful prior charges, same card, same customer. If you have two or more clean ones, you are in CE 3.0 territory. Second, pull the matching elements: signup IP, recent login IPs, device info, and usage records. Third, assemble the communication trail: receipts, renewal notices, dunning emails. Fourth, submit through Stripe's dispute flow with a short cover note that frames the evidence as a repeat-customer relationship, not a one-off charge. Write like a claims adjuster will read it, because one will.

Two habits make this dramatically easier. Keep a dispute evidence template pre-drafted, with slots for the data above, so a dispute is a fill-in exercise rather than a writing project. And respond to every winnable dispute. Each ignored dispute is lost revenue plus ratio damage you did not have to take.

"Friendly fraud says 'prove this customer knew'. Your own logs are the proof, if you kept them."

What CE 3.0 does not cover

Keep the limits in view. CE 3.0 targets fraud-coded disputes. It does nothing for 'credit not processed', 'canceled recurring', or 'product not received' codes, which still get fought the classic way: cancellation confirmations, refund records, delivery and usage proof. If your dispute mix is mostly service codes rather than fraud codes, your fix is operational, not evidentiary.

Mastercard has been moving in the same direction with its own first-party trust initiatives, letting merchants share purchase history to deflect friendly fraud. The details differ by network, but the strategic point is identical: the card networks have accepted that first-party misuse is a structural problem, and they are handing merchants with good records the tools to fight it. Founders who kept sloppy records get none of the benefit.

The bigger picture

CE 3.0 does not replace prevention. With Visa's VAMP threshold at 1.5% for merchants since April 2026, every dispute still counts against you even when you win, so descriptors, receipts, renewal warnings, and easy cancellation remain the first line. But for the disputes that arrive anyway, the era of helplessly eating friendly fraud is over. Subscription founders sit on the best evidence in payments. Start logging like it.

And if your failed-payment emails currently go out from a no-reply robot, fix that too. StayPaid sends them from your own address, written like a person, which recovers more revenue and builds exactly the communication trail these dispute rules reward.

If you take one action from this post, make it the boring one: open your database schema this week and confirm you are actually persisting signup IP, login IP history, and device identifiers, with retention long enough to cover your dispute window. Everything else in the CE 3.0 playbook is assembly work you can do under deadline. Missing data is the one failure you cannot fix retroactively, and it is the reason most founders who could win their friendly-fraud disputes never even try.

Worth saying plainly: none of this makes disputes fun, and none of it gets your ratio to zero. Some customers will dispute no matter how good your records are, because their bank's app makes 'report a problem' one tap and 'email the merchant' a scavenger hunt. What good records change is the ending. Instead of a sinking feeling and an automatic accept, a dispute becomes a 20-minute task with a template and a decent win rate. Over a year, that shift is worth real money, and more importantly, it takes the fear out of a part of the business that scares founders into ignoring it.