Somewhere there is a person who will decide whether you keep the money you earned. They have never heard of you. They do not know your product, your story, or how many nights you spent building it. They have a queue, and your dispute is one item in it.

You spent three hours assembling your evidence. They will give it a fraction of that attention, and most of what you attached will never be looked at.

This isn't cynicism. It's how decisions get made when a person has a lot of similar cases and a limited amount of attention. Understanding it changes what a good response looks like.

The reviewer isn't your audience. The first page is.

When you respond to a Stripe dispute, your evidence goes to the cardholder's bank (the issuer) through the card network. Stripe has said publicly that it helps you present evidence, but it doesn't make the final call. The issuer does. And the issuer's analyst is working through many disputes, each with a customer's claim on one side and a merchant's packet on the other.

Behavioral science has a plain name for what happens next. People under load rely on heuristics. Herbert Simon called it satisficing: we stop searching once we find something that's good enough, instead of weighing every option. Daniel Kahneman and Amos Tversky's work on heuristics points the same direction. When attention is scarce, we judge by what is easiest to see.

For a dispute analyst, that means one thing: your first page is doing most of the work. If it answers the question in their head, the rest is confirmation. If it doesn't, the rest may never be read.

The question in the analyst's head

Every dispute reason code boils down to a single question. For fraud: did the cardholder authorize this? For product not received: did they get what they paid for? For subscription cancelled: did they cancel before this charge?

The analyst is not asking whether you are a good person or whether your product is wonderful. They are asking whether the claim holds up against the facts.

Most merchants answer a different question. They defend their business. They explain their refund policy, describe how hard they work, and express frustration at the customer. All of that may be true. None of it answers the question.

The discipline here is simple to state and hard to do: find the one question your reason code is really asking, and answer it in the first three lines.

Build a cover summary, not a pile

The most useful thing you can add to your evidence is the thing you probably haven't made: a short cover summary at the top of your response. Think of it as the abstract of a research paper. A reader who stops after it should still know your position and why it's credible.

A good summary has four parts:

  • The claim in one sentence. "The customer states they did not authorize this charge."
  • Your answer in one sentence. "The charge was made from a device and IP address that have completed three prior undisputed purchases, and the product was accessed within an hour of payment."
  • The two or three strongest exhibits, named. "See Exhibit A (login log), Exhibit B (prior payments), Exhibit C (signed terms)."
  • The timeline in a single line. "Paid March 3, first login March 3, support email March 9, dispute filed April 2."

Notice what's missing: adjectives, emotion, and argument about the customer's character. Just the question, the answer, and where to verify it.

Why order matters more than volume

There is a common instinct to attach everything, on the theory that more evidence is more persuasive. But a reader with limited attention doesn't average your exhibits. They sample them. A strong item buried on page nine competes with a weak item on page one, and the weak item is more likely to be seen.

Psychologists call the underlying effect serial position: people remember the first and last items in a sequence best. You can use this directly. Put your strongest evidence first. Put your second strongest last. Let the middle hold supporting detail.

Also label things. An image file named "IMG_4471" asks the reader to do work. A page titled "Exhibit B: Customer login on March 3 at 14:12 UTC, same IP as the payment" does the work for them. Every unit of effort you remove from the reader is a unit of goodwill you keep.

Make every exhibit pass the 'so what' test

For each item you plan to include, finish this sentence: "This shows that ___." If you can't, cut it.

A screenshot of your homepage shows nothing about this transaction. A screenshot of the checkout page showing the terms the customer accepted, with their order's timestamp, shows that they agreed. A raw server log with ten thousand lines shows nothing to a human reader. The same log trimmed to the three lines for this customer, with a highlighted row, shows they used the product.

Curating isn't hiding anything. It's translating your records into the language of the question being asked.

Write like someone who expects to be checked

The tone of your response is itself a piece of evidence. Calm, specific, verifiable language reads as credible. Heated language reads as a party with a grievance. If you're angry, that's understandable, but anger tells the analyst nothing about what happened.

Use dates, times with time zones, amounts, and identifiers. Say what you know and stop. If something is uncertain, don't paper over it. A single overreach that the reviewer can disprove casts doubt on everything around it.

Your next moves

  • Pull up your last lost dispute today and read only the first page of what you submitted. Ask whether a stranger could state your position in ten seconds. If not, rewrite that page as a four-part summary.
  • Write a reusable cover-summary template with blanks for the claim, your answer, your top exhibits, and a one-line timeline. Save it where you can reach it from your phone.
  • Rename your evidence files in a consistent pattern, such as "Exhibit A - login log - 2026-03-03". Do this for the next dispute, not after.
  • Apply the 'so what' test to every attachment in your next response and delete anything you can't finish the sentence for.
  • Rank your exhibits by how directly each answers the reason code's question, then put the best first and the second best last.

Where this leaves you

A dispute is rarely decided by who worked hardest. It's decided by whose file made the decision easy. That's a more forgiving standard than it sounds, because it rewards clarity instead of volume, and clarity is something you can practice.

This is the part of the work Argeback was built around. It pulls your disputes in, drafts a response that leads with the answer to the reason code's question, and files it before the seven-day deadline, all from your phone. If you'd like to see what a well-ordered first page looks like, you can look at it at https://argeback.lumenlabs.works.