The instinct that quietly costs you the case
When a chargeback lands, the first feeling is usually indignation. You know this charge was legitimate. You have the receipts — literally. So you gather everything: the order confirmation, the signup email, three support threads, the terms of service, a screenshot of the login history, the shipping label, the refund policy, a note explaining that this customer has ordered from you four times before. You attach all of it, because surely the person reviewing this will see the sheer weight of proof and rule in your favor.
That instinct is understandable, and it is often exactly why merchants lose disputes they should have won. Not because the evidence was weak — because there was too much of it, arranged in no particular order, and the one fact that actually decided the case was buried on page nine.
The question worth asking before you respond isn't what evidence do I have? It's how much evidence should I submit for a chargeback, and in what order? Those are different questions, and the second one is the one that wins.
Who reads it, and how little time they spend
To understand why less can beat more, you have to picture the actual reader. Your evidence doesn't go to a courtroom. In most cases it goes to an analyst at the issuing bank — the customer's bank — who is working through a queue of disputes, each governed by a specific card-network reason code, each with a checklist of what would justify reversing the provisional credit already handed to the cardholder.
This person is not hostile. They are busy. They are looking for a specific thing that maps to the specific claim on the specific reason code in front of them. If the code says product not received, they want proof of delivery or access. If it says unrecognized, they want to connect the cardholder to the purchase. They are pattern-matching against a rule, under time pressure, across many files. They are not going to read your story from the beginning.
Cognitive science has a name for what happens when you hand a time-pressed decision-maker more information than the task requires: cognitive load. Working memory is narrow — it can hold only a few elements at once — and every irrelevant document you add competes for that same narrow channel. Psychologists studying decision-making call the downstream effect choice overload or information overload: past a certain point, more inputs don't produce better decisions, they produce worse and slower ones, and often a fall back to the default. In a chargeback, the default is that the cardholder keeps the money.
Think about what that means. Every page that doesn't bear on the reason code isn't neutral. It's noise that dilutes your signal and raises the odds the reviewer stops looking before they reach the fact that would have won.
Signal, noise, and the reason code
The reason code is the whole game, and it's the thing sprawling evidence packs tend to ignore. A dispute isn't a general referendum on whether you're a good merchant. It's a narrow claim: this specific thing was wrong in this specific way. Your job is to rebut that claim — not to prove your overall trustworthiness.
So the first move is subtraction. Read the reason code. Ask what single question the reviewer has to answer to rule for you. Then ask, of each document you were about to attach: does this help answer that exact question? If it doesn't, it isn't supporting evidence. It's noise wearing the costume of thoroughness.
A "not as described" dispute is won by showing what was actually promised versus what was delivered — the product page, the item specifications, the customer's own acknowledgment. Your refund policy is irrelevant to it, and attaching the policy anyway signals that you don't quite know why you're winning. An "unrecognized charge" dispute is won by tying the cardholder to the transaction — matching name, IP, device, prior undisputed orders, the billing descriptor they'd see on their statement. Proof of delivery does nothing here, because receipt was never the question.
Matching evidence to the code isn't a formality. It's the difference between a reviewer who finds your answer in fifteen seconds and one who never finds it at all.
The one-screen rule
Here is a practical discipline: assume the reviewer will absorb roughly one screen before they decide whether your file is worth more of their attention. Write for that screen.
That means a short cover narrative at the very top — three or four plain sentences that state what the customer bought, that it was delivered or rendered, and the two or three concrete facts that prove it. Not adjectives. Facts with specifics: dates, an IP address, an AVS match, a timestamp, a quoted line from the customer's own email. Then, beneath that summary, the supporting documents in the order the narrative references them — so that when the reviewer wants to confirm a claim, the proof is exactly where they'd reach for it, not somewhere they have to hunt.
This is the same principle that makes a good brief readable: front-load the conclusion, then let the evidence follow the argument rather than the argument chasing the evidence. You are not hiding anything by being brief. You are making the winning fact impossible to miss.
A useful test before you submit: could a stranger who knows nothing about your business read your first paragraph and correctly guess how this dispute should be resolved? If yes, the rest of the file is just confirmation. If no, you've buried your own case.
When more evidence really is better
None of this means thin is good. There's a real difference between lean and incomplete. Some situations genuinely call for a fuller record — a returning customer for whom prior transaction history is itself the argument (the logic behind the networks' compelling-evidence standards for fraud disputes), or a subscription where the customer's continued use across billing cycles is the proof. In those cases the additional data isn't noise; it's the signal.
The rule was never "submit less." It's "submit only what bears on the claim, and put the strongest of it first." Sometimes that's three items. Sometimes it's ten. The discipline is the same either way: every piece earns its place by answering the reviewer's one question, and nothing rides along just because you happen to have it.
The quiet cost of the dump
There's one more reason the everything-at-once approach fails, and it's about you, not the reviewer. Assembling a forty-page pile feels like diligence, so you stop thinking. You never force yourself to name the single fact that wins. And if you can't name it, you probably haven't found it — which means the reviewer won't either.
The merchants who win consistently aren't the ones with the thickest files. They're the ones who can say, in one sentence, why they're right, and who make that sentence the first thing anyone sees.
Where this gets hard in real life
Knowing all this and doing it under a seven-day deadline, mid-week, between everything else your business demands, are two different things. The reason-code lookup, the subtraction, the ordered narrative — it's real work, and it's the work most merchants skip precisely when a dispute is least convenient. This is the part Argeback is built to carry: it reads the dispute and its reason code, pulls the facts that actually bear on that claim, drafts the response with the winning point up front, and files it before the deadline — from your phone, without you assembling a single PDF. It's the discipline of a lean, well-ordered case, applied every time, even during a busy week.
If you've been losing disputes you knew you should have won, it may not be your evidence. It may be the order. You can see how it works at https://argeback.lumenlabs.works.