The customer who disputed a charge they used 61 times

There's a particular kind of quiet that follows a chargeback email. You open your laptop, pull up the account, and there it is: the customer logged in 61 times. Opened the dashboard the morning they filed the dispute. Exported a report at 9:14 a.m., then at 9:40 a.m. told their bank they never authorized the charge.

Both things are true at once. They used your software. They also disputed it. And the uncomfortable part isn't that someone lied — it's that you're about to lose anyway, because the bank can't see what your server can. The customer's word arrives as a sworn claim. Your product's entire history sits in a database nobody asked for.

That gap is the whole game. And for software, it's the most winnable gap there is — if you know what to pull.

Why policies lose and logs win

Most merchants fighting a SaaS dispute reach for the wrong weapon. They paste in their terms of service, their cancellation policy, a screenshot of the pricing page. All of that answers a question nobody asked. The bank isn't adjudicating whether your policy is fair. On a fraud-coded dispute, it's deciding one thing: did this cardholder actually transact and receive what they paid for?

A policy is an assertion. A login record is behavior. Card networks weigh them differently on purpose. Visa's dispute framework — the one Stripe surfaces as "compelling evidence" — explicitly lets a merchant submit proof that the cardholder used the service: IP addresses, device identifiers, login timestamps, and evidence linking the account to the person who paid. The logic is behavioral economics in its plainest form. Stated intentions are cheap and easy to revise after the fact; revealed behavior — what someone actually did, logged at the moment they did it — is expensive to fake and nearly impossible to retcon.

So the strongest SaaS chargeback evidence is almost never the document you wrote. It's the data your product generated while the customer was busy getting value from it.

What "use" actually looks like to a reviewer

A dispute reviewer spends a minute or two on your case, maybe less. They aren't reading a novel. They're pattern-matching for a few signals that the cardholder is the account holder and that the account was active. Your job is to hand those signals over already connected.

  • Login timestamps that bracket the charge. A record of the account signing in before the purchase, on the purchase date, and — most damning for a fraud claim — after the dispute was filed. Someone defrauded of a subscription does not keep logging in.
  • IP and device continuity. The same IP range or device fingerprint across the signup, the payment, and later sessions. A stolen card used by a stranger doesn't produce a consistent six-month device history.
  • The AVS and CVV match from the transaction itself. If the billing address and security code matched at checkout, that's baked into the Stripe record. It quietly destroys the "I never had this card" story.
  • Actions that only the real user takes. Password resets they completed, invites they sent to coworkers, data they exported, settings they changed, support tickets they opened from the account email.

Notice the shape here. You're not proving your product is good. You're proving a specific human, holding a specific card, showed up and did things. That's a question of fact, and facts are what reviewers are allowed to act on.

The records that vanish if you wait

Here's the trap. The evidence that wins is the most perishable thing you own. Session logs roll over. Some analytics tools retain raw event data for only 30 or 90 days. If a customer's account gets deleted on cancellation — which many SaaS products do automatically for privacy hygiene — the login history that would have won the dispute disappears with it, often before the dispute even lands.

And disputes arrive late. A cardholder can file months after the charge. So the moment you most need your logs is frequently the moment your own retention settings have already shredded them. The quiet tragedy of SaaS chargebacks is how many are lost not to a weak case but to a DELETE query that ran on schedule.

Your next moves

  • Export the account's full activity log today, before you draft a word. Pull login timestamps, IP addresses, and any feature events for the disputed customer. Save it as a file now — not when the deadline looms and the data may be gone.
  • Find the three timestamps that matter and put them first: login just before the charge, activity on the charge date, and any login after the dispute was filed. Lead your evidence with those, not with your policy.
  • Check your data retention settings this week. If analytics or session logs expire in under 180 days, extend them, or set up a monthly export of login and billing-event data to cold storage so a late dispute still has proof.
  • Stop auto-deleting accounts on cancellation. Soft-delete instead — flag the account inactive but keep the usage history for at least six months. That one change preserves your evidence for the disputes that haven't happened yet.
  • Grab the AVS/CVV result from the original Stripe charge and quote it in your rebuttal. It's a one-line fact that pre-empts the "it wasn't me" claim at no cost to you.

Stitch the facts into a story a reviewer can follow

Raw logs don't win on their own; a reviewer won't do your assembly for you. The move is to narrate the data in three or four sentences: This account was created on [date] from IP X with a matching AVS/CVV. The cardholder logged in on 61 occasions, including the day of purchase and twice after the dispute was filed. They exported data on [date] and sent two team invitations. Attached are the login records and event logs. Then attach the file. You've converted a database into a timeline, and a timeline into a fact pattern the bank is permitted to rule on.

That's representment done right — not louder arguing, but tighter evidence, pointed at the one question that decides the case.

Where this gets hard, and where Argeback helps

The reason sound cases still lose is rarely ignorance. It's time. The 7-day Stripe deadline collides with the week you're shipping, hiring, or simply underwater — and pulling logs, finding the three timestamps, writing the narrative, and filing cleanly is exactly the kind of task that slides until it's too late. That's the failure mode this whole article is really about.

Argeback is built to close that gap. It ingests your Stripe disputes, assembles the evidence-backed response around the facts that actually move reviewers, and files it before the deadline — from your phone, in the gap between two meetings. You keep the judgment; it carries the scramble. If the last dispute you lost was one you should have won, see how it works at argeback.lumenlabs.works.