The word nobody tells you
When a chargeback lands and you click "submit evidence" in Stripe, it feels like you're filing an appeal — writing a letter, attaching some proof, and waiting for a verdict. That mental model is almost right, and the small part it gets wrong is why so many merchants misplay the whole thing.
What you're actually doing has a name that never appears on the Stripe button: representment. You are re-presenting the transaction. The first time the transaction was presented, it was your payment — money moved from the cardholder's account to yours. The chargeback reversed it. Representment is your formal statement, sent back through the card network, that the original transaction was valid and should stand.
That distinction matters because it tells you who you're talking to, what they can and can't consider, and why a persuasive story often loses to a boring one.
The transaction gets sent back, not judged fresh
Here is the chain, in order. A cardholder disputes a charge with their bank — the issuing bank, the one that put the card in their wallet. The issuer pulls the money back and sends the dispute, tagged with a reason code, down through the card network (Visa, Mastercard) to Stripe, which acts on behalf of the acquiring bank that holds your merchant account.
When you submit evidence, Stripe packages it and re-presents the transaction back up the same chain: acquirer, network, issuer. The evidence doesn't go to a neutral judge or to the network itself. It goes to the same issuing bank that filed the dispute — often the same department, sometimes a person, sometimes an automated rule set.
This is the fact that reframes everything. You are not persuading a referee. You are asking the customer's own bank to reverse a decision it already made on that customer's behalf. The bank will only do that if your evidence directly contradicts the specific reason the cardholder gave. Not "this customer seems dishonest." Not "we've had trouble with this person." It has to be: the reason code says X, and here is the record that makes X untrue.
Why the reason code is the whole game
Every chargeback arrives labeled. The label is a reason code — a compact classification like "fraud — card not present" or "services not provided" or "not as described." That code isn't bureaucratic decoration. It defines the only question the issuer will review.
Representment succeeds when your evidence answers that exact question and fails when it answers a different, better-sounding one. A "product not received" dispute is won with proof of delivery or access — a tracking event, a login timestamp, a download record. It is not won by explaining that your refund policy is generous and the customer was rude in email. That's a real story, but it rebuts a claim nobody made.
The network calls the counter-evidence you supply compelling evidence, and the term is more literal than it sounds. It has to compel a specific conclusion about the specific claim. Visa and Mastercard even publish, for certain reason codes, the categories of evidence that qualify — matching IP addresses, device fingerprints, prior undisputed purchases by the same cardholder. When your evidence lines up with those defined categories, representment is close to mechanical. When it doesn't, no amount of eloquence saves it.
The clock you're actually racing
Stripe surfaces a deadline — often around seven days, sometimes less — and it feels arbitrary until you see where it comes from. The card networks give the acquirer a fixed window to re-present a disputed transaction, and Stripe reserves buffer time inside that window to assemble and transmit your submission. Miss it and the representment never happens; the chargeback finalizes by default, and "by default" means you lose without anyone reading a word.
That's the quiet tragedy of chargebacks. A large share of them aren't lost on the merits. They're lost because no representment was ever filed — the email went to a spam folder, the deadline fell during a busy week, the merchant assumed refunding the customer had already closed it (it hadn't; a refund and a chargeback are separate rails that can both fire). The transaction was defensible. Nobody defended it in time.
What happens after you re-present
Submit your representment and the transaction goes back to the issuer, who reviews it against the cardholder's claim. One of two things happens. The issuer accepts your evidence and the funds return to you — the dispute resolves in your favor. Or the issuer stands by the cardholder, and now the two sides genuinely disagree about the facts.
That disagreement has its own next stage: pre-arbitration, and beyond it, arbitration, where the card network itself finally steps in as the decider and assesses fees against whoever loses. Most disputes never travel that far — the cost and fees make arbitration rare, reserved for high-value transactions where someone is confident. But knowing the ladder exists changes how you think about the first rung. Representment isn't a shot in the dark. It's the opening move in a defined process with defined evidence standards, and doing it precisely is what keeps you off the expensive rungs above.
Writing for a reviewer who has thirty seconds
Because representment is read by the issuer's dispute team, not by a jury, the craft of it is almost the opposite of persuasion. The reviewer may be processing hundreds of these. They are matching your submission against a checklist tied to the reason code. Your job is to make the match obvious in seconds.
That means leading with the single fact that rebuts the claim, stated plainly, with the record right behind it. A dated delivery confirmation for a "not received" claim. A signed terms acceptance and usage log for a "not as described" subscription the customer used for months. The AVS and CVV match, the IP that matches the cardholder's known location, for a "fraud" claim on a purchase the real cardholder made. Extra pages of context don't strengthen a clear match — they bury it, and a buried match reads as no match. In representment, the disciplined submission beats the thorough one.
Why the mechanics are the strategy
Once you see a chargeback as a re-presented transaction rather than an appeal, the confusing parts settle into place. The reason code isn't a formality — it's the entire scope of review. The deadline isn't Stripe being strict — it's the network's window minus processing time. The reviewer isn't unmoved by your fairness argument because they're callous — they're structurally unable to consider a claim that wasn't filed. And the evidence that wins isn't the most sympathetic. It's the piece that maps cleanly onto the one question on the table.
Merchants who internalize this stop writing letters and start assembling matches. They win more not because their case is stronger but because they're finally answering the question that was actually asked.
Where Argeback fits
This is exactly the work that's easy to get wrong under time pressure and easy to skip entirely on a full week. Argeback reads the incoming Stripe dispute, identifies the reason code and the specific claim behind it, pulls the records that map to that claim, and drafts a representment built to be matched in seconds — then files it before the network's window closes, all from your phone. It doesn't make your case more persuasive; it makes it more precise, which is the thing that actually moves an issuer.
If you've been losing disputes you could have won — or letting them finalize by default because the deadline slipped — it's worth seeing what a properly built representment looks like. You can start at argeback.lumenlabs.works.