Fighting a Chargeback Is an Evidence Job

The email arrives on a Tuesday and it is almost never about the money. Forty pounds, an order from five months ago, a customer who has bought from you four times. The bank has taken the money back and you have somewhere between nine and forty days to say why they should not have.

Most small sellers respond to that email by writing a paragraph. They explain that the customer ordered it, that it was delivered, that there was no complaint at the time. It is all true and it almost always loses, because a dispute is not an argument. It is a form with required fields, adjudicated by people who never see your paragraph.

What follows is the shape of the process, what actually counts as evidence, and the narrow place where automation helps.

What is representment, and who decides it?

Representment is the stage where you re present the transaction to the issuing bank with evidence that it was legitimate. The decision is made by the issuer against scheme rules, not by your payment provider and not by anyone you can call.

This matters because sellers routinely misdirect their frustration. Your acquirer or payment platform is a conduit. If it followed the rules of your merchant agreement, the UK's Financial Ombudsman Service is explicit in its guidance on disputed transactions that it is unlikely to uphold a complaint against the acquirer, even when the merchant is an innocent victim of fraud. The ombudsman also lists what it expects to see in a dispute file: how the transaction was made, electronic audit trails, card verification details, security procedure documentation and CCTV where it exists.

Read that list again with a small online shop in mind. Almost every item is something that is either captured automatically at the moment of sale or lost forever. There is no CCTV on a website. The equivalent is your logs.

What actually counts as evidence?

Data elements that link the disputed purchase to purchases the same cardholder never questioned. Not sincerity, not history you describe in prose, not the fact that you are a decent trader.

Visa's Compelling Evidence 3.0 route makes the requirements concrete, and reading them teaches you more about dispute defence than any general advice. Stripe's documentation of the CE 3.0 flow sets out the qualifying criteria: the dispute must carry network reason code 10.4, there must be at least two previous undisputed payments on the same payment method, and those payments must fall between 120 and 364 days before the disputed one. They must be genuinely paid and undisputed, and they cannot be validation charges.

Then comes the matching rule, which is the part worth memorising. The disputed transaction and both prior transactions must share either two main evidence elements, or one main element plus one secondary element. The main elements are the customer purchase IP address and the device fingerprint or device identifier. The secondary elements are the shipping address, the customer email address and the customer account identifier. Device fingerprint plus device identifier does not count as two, since they describe the same thing.

Notice what is absent from that list. Your invoice. Your delivery confirmation. Your correspondence with the customer. Those matter in other dispute categories, and the documentation is clear that you should fill in the standard evidence fields as well, because they are what gets used if the CE 3.0 submission is judged ineligible. But for the specific and common case of a customer claiming they never made a card absent purchase, the winning argument is a data match rather than a story.

How long have you actually got?

Less time than the calendar suggests, and a different amount depending on which card was used. This is the detail that turns a winnable dispute into a lost one while you are on holiday.

Adyen's documentation of dispute timeframes lays out the stages. A cardholder typically has 120 calendar days from the transaction to raise a dispute, which stretches to 540 for Visa and Mastercard in delayed fulfilment situations such as pre orders or travel. Before a chargeback there may be a Request for Information, where the response window runs 13 to 30 days depending on the scheme. Once a chargeback is raised, the merchant response window runs from 9 to 40 days from the notice date, with Visa at 9 or 18 days and Mastercard at 40. After you submit, a final ruling lands somewhere between 20 and 80 days later.

Two practical consequences follow. First, the shortest window in that range is nine days, which is less than one holiday. If disputes go to an inbox only you read, build a second route. Second, the cardholder's window is longer than most small shops keep detailed logs, which is the quiet reason many disputes are indefensible: the evidence expired before the dispute arrived.

The stages, and what you can influence at each

This table is assembled from the timeframe and evidence documentation together, because neither source presents the process from the seller's point of view.

The row that repays attention is the first one. A request for information is a chance to end the matter cheaply, and plenty of sellers treat it as a formality or miss it entirely. It is also the stage where a clear order record, sent promptly, does the most work per minute spent.

Why does the same dispute get judged differently on two cards?

Because each scheme writes its own rulebook, and your payment provider is translating between them. The customer experience is identical and the merchant obligations are not.

The clearest illustration is the response window. Mastercard allows 40 days to defend a chargeback. Visa allows 9 or 18, with the shorter figure applying to transactions in the United States and Canada from 21 July 2025. A seller with a single internal process built around the longer deadline will lose Visa cases without ever understanding why, because nothing in the notice announces that this one is different.

Reason codes differ too, and the evidence that satisfies one does not satisfy another. A claim that goods were not received wants tracking and a delivery confirmation. A claim of unauthorised card absent use wants the identity match described earlier. A claim that the goods were not as described wants your listing, your policy and any correspondence. Filing the same bundle for all three is the most common wasted effort in small shop dispute handling, and it produces a losing record that feels like bad luck.

Alternative payment methods add a third set of rules. Adyen's documentation notes that Klarna expects a response within 14 days for consumer reason codes, and as little as 96 hours for high risk orders. Four days is not a deadline you meet by accident.

What does a good dispute file look like?

Short, structured and specific to the reason code. A dispute reviewer is working through a queue, and the file that answers the question asked wins more often than the file that says more.

Put the identifying data first, because that is what the rules are written about: the transaction identifier, the date, the amount, the card's last four digits, and for a card absent fraud claim the matched elements with their values shown for both the disputed purchase and the prior ones. Then the fulfilment record: what was sent, when, to which address, with the tracking reference and its delivered status. Then the customer relationship: account creation date, previous orders, any support correspondence. Keep each to a line where a line will do.

Two habits improve a file more than any rewriting. Use the customer's own words where they exist, quoted from your support system with a date, rather than your characterisation of what they meant. And include the negative facts that help you, such as the absence of any complaint in the five months between delivery and the dispute, because an absence is checkable and an assertion of good faith is not.

The ombudsman's list is the right mental model even outside the United Kingdom. It asks how the transaction was made, what the electronic audit trail shows, what verification was performed and what security procedures applied. Those are questions about systems, and each one has a factual answer that you either have or do not.

Where does AI help, and where is it dangerous?

It helps at assembly and at checking. It is dangerous the moment it is asked to characterise a transaction, because a dispute file that contains a confident sentence you cannot support is worse than a thin file.

The assembly job is real and tedious. For a single dispute you need to find prior payments on the same card, confirm they fall inside the date window, confirm they were never disputed, pull the IP and device data from each, compare the fields, and produce descriptions of what was bought each time. Doing that by hand takes half an hour and is exactly the kind of multi step lookup a model with access to your order data does quickly. Whether the elements match is a deterministic question with a right answer, which is the condition under which automating is safe.

The checking job is the higher value one. Before you submit, something should verify that the bundle satisfies the rule rather than merely looks complete. Two secondary elements are not enough. A device fingerprint paired with a device identifier is not two elements. A prior transaction dated 100 days before the disputed one does not qualify. Each of those is a silent failure that turns a qualifying dispute into an ordinary one, and each is trivially checkable in advance.

What you should never automate is the narrative. A model asked to explain why a charge was legitimate will produce a plausible account of a delivery it has no knowledge of. Submitting that is not a shortcut, it is a false statement in a bank's file, and the same failure mode we described in using AI to check invoices for fraud applies here with sharper consequences.

The real fix is upstream, and it is boring

You cannot win disputes with data you did not record. Every element in the CE 3.0 list is captured at checkout or not at all, which makes dispute defence a configuration decision made months before any dispute.

Check, today, whether your checkout stores the purchase IP address, a device identifier or fingerprint, the email address as entered, and the shipping address as entered rather than as later corrected. Check how long those records are retained, because a 540 day dispute window against a 90 day log retention is a guaranteed loss. Check that your billing descriptor is stable, since prior transactions have to be recognisable as yours.

Retention deserves its own thought, because the instinct to minimise stored personal data runs straight into the need to defend a charge a year and a half later. The resolution is not to keep everything forever. It is to decide deliberately which fields you keep, for how long, and to say so in your privacy notice. We worked through that balance in what AI vendors keep and for how long, and the same reasoning applies to your own order records.

If you are setting up a shop rather than repairing one, this is the cheapest moment to get it right. A storefront built with an AI ecommerce store builder that writes the order schema and the checkout together can capture these fields from the first order, instead of you discovering the gap during your first dispute.

Should you fight every dispute?

No, and the arithmetic is unsentimental. A representment costs you time and sometimes a fee, and a lost pre arbitration can cost more than the transaction. Decide by category rather than case by case.

Disputes where you hold two matching elements and two qualifying prior payments are worth fighting, because the rule is mechanical and you either satisfy it or you do not. Disputes where the customer says the item never arrived and you have no tracking are not worth fighting, they are worth fixing in your shipping process. Disputes over goods that were genuinely late, damaged or misdescribed are a refund you should have given before the bank got involved.

Keep a simple count, because the count matters beyond the money. Dispute ratios influence how your acquirer views your account, and a rising ratio brings reserves, holds and sometimes termination, which we covered in how merchant risk scores lead to reserves and holds. Winning is good. Not generating the dispute is much better.

A short checklist you can run this week

Open your payment dashboard and find the last three disputes, including the ones you lost. For each, ask whether the required elements existed anywhere in your systems at the time. That single exercise tells you whether you have an evidence problem or a process problem, and they need different work.

Then set a reminder that beats your shortest window. Nine days from a notice you might not read for three is not much margin, and a dispute lost on a deadline is the most annoying kind, because the file would have won.

Finally, write down what your shop actually records at checkout. Not what the platform documentation says it can record, what yours does. Most sellers discover one missing field, usually the device identifier or the IP address, and fixing it takes an afternoon and pays for itself the first time a regular customer forgets what they bought.

The honest summary

Chargeback representment rewards preparation and punishes eloquence. The rules are specific, the windows are short and uneven, and the decision is made by someone who will never read your explanation. Capture the elements, keep them long enough, check the bundle against the rule before you submit, and concede the cases you were always going to lose. That is the whole discipline, and it is considerably duller than the advice industry around it suggests.