Somewhere there is a person who will decide whether you keep the money from a sale you are certain was legitimate. They have never heard of your business. They have a queue. And what they are looking at, in the moment your file opens, is a pile: a receipt, three screenshots, a tracking page, an email thread exported as a PDF, a policy link. Every item is true. Nothing in the pile says what happened.

Most merchants who lose disputes they should have won did not lack evidence. They lacked a sequence. The facts were there, but the reviewer had to assemble the story themselves, and a tired stranger with a queue will not do that work for you. They will do the easy thing, which is to side with the bank's record of the customer's claim.

This piece is about one fix: a chargeback evidence timeline, a single page that tells the reviewer what happened, in order, with every line pointing to proof.

Why order persuades when volume doesn't

People understand events as stories. Psychologists have long noted that we make sense of the world by linking happenings into cause and effect, and that a coherent sequence feels more credible than the same facts scattered. You have probably felt this in reverse: a witness whose account jumps around sounds unreliable even when each sentence is accurate.

A dispute is a credibility contest conducted on paper. The customer's side is a single, tidy sentence: I didn't get it. I didn't authorize it. It wasn't as described. Your side, if it arrives as a pile, is a dozen fragments that each need interpreting. A one-sentence claim beats a dozen fragments almost every time, because the claim is easy to hold in your head.

The timeline levels that. It gives your side a shape as simple as theirs, except yours has receipts.

What a timeline actually is

It is not a rebuttal letter. A letter argues. A timeline reports. Think of it as the incident log a good engineer writes after an outage: timestamp, event, source. No adjectives.

Each line has three parts:

  • When the event happened, with date and, where it matters, time and timezone.
  • What happened, in one plain sentence.
  • Where the proof lives, named by exhibit so the reviewer can find it.

A fragment of one might read:

Mar 3, 14:02 UTC. Customer completes checkout, accepting terms via checkbox. (Exhibit A: order record with consent log)

Mar 3, 14:05 UTC. Confirmation email sent to the address on the order. (Exhibit B: email delivery record)

Mar 6. Carrier marks package delivered to the shipping address on the order. (Exhibit C: carrier tracking page)

Mar 19. Customer writes to support asking about an unrelated feature. (Exhibit D: support thread)

Apr 2. Dispute opened with the reason "product not received."

Read that last line again. Nothing in it is an accusation. It simply places the dispute at the end of a sequence where the customer engaged normally for weeks. The reviewer draws the inference themselves, and an inference a person reaches on their own is far stronger than one you hand them.

Anchor it to the claim, not to your whole business

The timeline should be built backward from the dispute's reason. Stripe shows you the reason the cardholder gave, and different reasons make different moments matter.

If the claim is that the customer never received something, the pivotal events are the shipment, the delivery confirmation, and any contact afterward. If the claim is that the charge was unauthorized, the pivotal events are the match between the person who ordered and the person who has used the product, and any prior undisputed purchases. If the claim is a subscription they say they cancelled, the pivotal events are the signup consent, the reminders you sent, and whether any cancellation request exists at all.

Everything else is noise, and noise has a cost. Leave out the history of your company, your general philosophy of customer service, and the three screenshots that are interesting but irrelevant. A shorter timeline with eight strong lines beats one with thirty.

Include the line that hurts you

Here is the part merchants resist. If something in the record is awkward, such as a late shipment, a support reply that took four days, or a refund promised and not yet sent, put it in the timeline, plainly, and show how you handled it.

The reviewer will see the awkward fact anyway, in the customer's materials or in your own attachments. If your timeline omits it, the omission looks like concealment, and it taints every other line. If your timeline includes it, you look like the careful party in the room. Candor is a credibility signal precisely because it costs you something.

Do not editorialize about it. "Mar 8. Customer reported the item arrived two days after the estimated date. Support apologized and offered a partial refund the same day." Facts, then the response.

Use timestamps your systems actually recorded

A timeline is only as good as its sources. Pull times from system records, not memory: your order log, your payment record, your email provider's delivery data, the carrier's scan history, your app's own event logs. Round numbers and reconstructed dates are easy to spot and easy to doubt.

Watch timezones. A purchase at 11:50 p.m. in one zone is the next day in another, and an inconsistency of a day inside your own document gives a reviewer a reason to distrust the rest. Pick one timezone, label it, and stay with it.

Your next moves

  • Open your most recent dispute and write only the reason on a blank page. Underneath it, list the three events that would prove or disprove that exact claim. Those are your anchors.
  • Build a skeleton template today with the columns When / What / Proof, and save it where you can find it at 9 p.m. on a bad day. Reuse beats reinvention.
  • Pull timestamps from systems, not memory. For one past order, find the order log, email delivery record and any support messages, and note which of them you can export with a time attached. Fix the gaps now, before a dispute depends on them.
  • Add the awkward line. For your last dispute, ask what the customer would point to, and write it into the timeline in neutral language along with your response.
  • Number your exhibits to match. Label each attachment A, B, C and make sure every timeline line cites one. A line with no proof behind it should be cut or the proof found.

Keep it to a page

The discipline of one page is what makes the format work. If you cannot fit the story on a page, you are probably telling more than the dispute needs. Aim for something a reviewer can read in under a minute and still come away knowing what happened, when, and where to check.

Then end it. No closing plea, no paragraph of indignation. The last line is the dispute itself, set in its place after all the things that came before.

The part machines are good at

Building a timeline is tedious in a specific way: it means opening several systems, copying timestamps, converting zones, and doing it again under a deadline that does not move. That is exactly the sort of work that gets postponed until the last evening, and then rushed.

This is the problem Argeback was built around. It pulls in your Stripe disputes, assembles the supporting records into an ordered, evidence-backed response, and files it before the seven-day deadline, with the review happening on your phone rather than at a desk you may not be near. If you would rather not rebuild the same chronology from scratch every time, you can look at how it works at https://argeback.lumenlabs.works. The timeline itself is yours to write by hand whenever you like; the point is that the story gets told in order.