The evidence that would have won your next chargeback is being deleted right now, by systems you set up yourself, on schedules you agreed to and forgot. The server log that shows the customer logged in twice after delivery rotates out at thirty days. The support inbox auto-archives at ninety. The session data that proves the buyer was sitting at the same IP address they'd used for the last four purchases was never written down at all, because nothing in your checkout flow had a reason to write it down.

The dispute, meanwhile, is going to arrive in month four.

This is the quiet asymmetry at the heart of chargebacks, and almost nobody structures their business around it. A cardholder can often reach back roughly 120 days from the transaction — sometimes from the expected delivery date, which pushes it later still — to open a dispute. You then get a window measured in days to answer it. Long fuse, short response. By the time the dispute notification lands in your dashboard, you are not gathering evidence. You are excavating it. And you are excavating a site you never bothered to preserve.

Why we systematically under-invest in evidence we'll need later

There's a well-documented reason this keeps happening, and it isn't laziness.

Behavioral economists call it present bias: the tendency, formalized in the work of George Ainslie and later David Laibson on hyperbolic discounting, to weight immediate costs far more heavily than future benefits, and to discount those future benefits steeply the further out they sit. Setting up structured logging costs you an afternoon today. The payoff is a probabilistic win, four months from now, on a dispute that may never come. Every rational-feeling instinct in your body says later. And the thing about later is that it's where the deadline lives too.

Stack a second mechanism on top of it. When the dispute finally arrives, your first move is to reconstruct the transaction from memory. I remember this one — they emailed, they were happy, they used it for weeks. But human memory is not a recording. Frederic Bartlett showed nearly a century ago that recall is reconstructive: we rebuild a memory each time from fragments plus our current expectations. Elizabeth Loftus's misinformation research showed how easily that rebuild absorbs details that were never there. Your memory of the transaction is not evidence. It is a plausible story shaped by the fact that you now badly want to win.

A card issuer's reviewer does not want your story. They want artifacts with timestamps.

Evidence has a shelf life, and it's shorter than the dispute window

Here is the thing worth internalizing: chargeback evidence is not one category. It's three, and only one of them survives on its own.

Durable evidence persists without effort. The Stripe charge record. The invoice. The signed contract. This is the evidence everyone remembers, which is why everyone submits it, which is why it rarely decides anything — the issuer already knows a charge occurred. That was never in question.

Decaying evidence exists now and won't later. Server access logs. Application session records. Email threads in a support inbox with a retention policy. CDN or download logs. Anything living in a system with a rotation window shorter than 120 days is, functionally, evidence you do not have.

Ephemeral evidence exists only at the moment of the transaction and is gone a second later unless something catches it. The IP address the customer checked out from. The device fingerprint. The exact version of the terms of service displayed on the page. The timestamp of the checkbox tick. Whether the billing descriptor they'd later fail to recognize was even shown to them.

The disputes you lose are almost never lost on durable evidence. They're lost in the second and third categories — where the argument you needed to make was available, briefly, and nothing caught it.

Visa's Compelling Evidence 3.0 framework, live since April 2023, makes this concrete in a way that should make every merchant slightly uncomfortable. For certain fraud disputes, you can defend yourself by showing two prior undisputed transactions from the same cardholder, between 120 and 365 days old, that share at least two matching data points with the disputed one — IP address, device ID, account ID, or shipping address. Read that again. The rule hands you a genuinely powerful defense against the hardest category of dispute, and then quietly conditions it on data you had to have been capturing, and retaining, for up to a year before you knew you'd need it.

Merchants who log those identifiers can invoke it. Merchants who don't, simply can't. Not "argue it poorly" — can't. The evidence doesn't exist.

The fire drill that tells you the truth

If you want to know your real exposure, don't audit your policy. Audit your recall.

Open your dashboard, pick a single order from about four months ago — not a memorable one, an ordinary one — and set a twenty-minute timer. Assemble everything you would send to defend it. The customer's IP at purchase. Their login or download history after delivery. The support thread. The terms they agreed to, in the version they saw. Proof of what was delivered, when.

Most people find the timer irrelevant, because they hit a wall in six minutes. That wall is your true chargeback posture, and it has nothing to do with how well you write rebuttal letters.

Your next moves

  • Run the four-month fire drill today. Pick one real order from ~120 days ago and try to build a complete evidence packet in twenty minutes. Write down every single thing you couldn't find. That list, not a template, is your project plan.
  • Check the retention windows on every system that touches a transaction — server logs, application database, email, helpdesk, file storage. Anything with a window shorter than 400 days is silently destroying evidence. Extend it. Storage is cheaper than a lost dispute plus the dispute fee.
  • Capture identity signals at checkout and attach them to the charge itself. Write the customer's IP address, device or session ID, and your internal account ID into the payment's metadata at creation time, so they travel with the charge and don't depend on you correlating three systems under deadline pressure later. This is precisely the data Compelling Evidence 3.0 asks for.
  • Version and timestamp your terms acceptance. Store which version of your terms and refund policy the customer affirmatively accepted, and when, as a record on their account. "Our policy says X" is weak. "This customer clicked accept on policy v3.2 at 14:07 UTC on March 4" is not.
  • Log post-purchase usage as a first-class event. Logins, downloads, API calls, feature use, delivery confirmations — with timestamps, retained for a year. A customer who claims they never received or never authorized a purchase, and who used it fourteen times afterward, has just handed you the dispute.

None of these takes a week. All of them are worthless the day after you need them.

The window you're actually working in

There's a version of chargeback management that's about writing persuasively under pressure. It's real, and it matters. But it sits downstream of a decision you make months earlier, on an ordinary Tuesday, when nothing is at stake and no one is watching: whether the boring, unglamorous act of writing something down happens or doesn't.

You cannot argue your way to evidence. You can only have preserved it, or not.

That's the half of the problem no tool can solve for you retroactively. What a tool can solve is the other half — the part where the dispute lands while you're mid-sprint or on a plane, the clock starts, and the evidence you carefully preserved sits in four systems that don't talk to each other. Argeback ingests your Stripe disputes the moment they open, pulls the evidence together, drafts a response built around what the reviewer actually reads, and files it before the deadline — from your phone, in the ten minutes you have. Do the logging this week. Then let something else watch the clock: argeback.lumenlabs.works.