A chargeback gives you one reply and somebody else's deadline

The email arrives on a Friday afternoon. A customer has disputed a payment from three months ago. There is a deadline in the email, and it is closer than you expect.

Two things have already happened that nobody asked you about. The money has been taken back out of your account, and a clock has started that you did not start and cannot pause. Everything you do from here happens inside a window somebody else set, and you get to speak once.

This article is about that window: who actually sets it, why it is shorter than the number in any rulebook, and why the evidence that would win the argument had to be collected months before the argument existed.

The money leaves before the email arrives

The sequence surprises people because it inverts the order they expect. There is no accusation, then an investigation, then a debit. The debit is first.

Stripe describes it plainly: "To process a chargeback, the issuer creates a formal dispute on the card network, which immediately reverses the payment. This pulls the money for the payment—as well as one or more network dispute fees—from Stripe. After that, Stripe debits your balance for the payment amount and dispute fee." And the money stays gone for the duration: "These funds are held for the entire duration of the dispute."

How long is that duration? Stripe puts the issuer's evaluation at "usually 60-75 days, depending on the card network", the bank's review at up to three months, and the whole lifecycle at "2-3 months to complete". So the working assumption for a small business is that a disputed payment is out of reach for most of a quarter, whatever the outcome turns out to be.

Square describes the same shape in its own words, and adds the part that hurts if your balance is thin: it "withholds the disputed funds from the seller's Square account balance until the bank issues a final resolution on the case. If there are insufficient funds in the Square account balance, the funds are removed (debited) from the seller's most recently linked bank account."

Whatever your cash-flow model assumes about money that has already landed, this is the exception to it.

The deadline is a slice of somebody else's deadline

Here is the part that is genuinely not obvious, and it is worth sourcing properly rather than asserting.

Visa publishes its rulebook. In the edition dated 18 April 2026, the dispute resolution tables set out each stage of the process with a time limit attached. For the categories covering processing errors and consumer disputes, the stage called Dispute Response carries, in most markets, a time limit of "30 calendar days from the Dispute Processing Date", and the party the rule addresses is not you. It reads: "The Acquirer may initiate a Dispute Response as specified under the applicable Dispute condition."

The acquirer. The bank or processor on your side of the transaction. The network gives them thirty days.

Now look at what your processor gives you. Stripe: "When you receive a dispute notification, you have a limited window to respond (usually 7 to 21 days, depending on the card network)." Adyen publishes a table by scheme, and as of 21 July 2025 its own documentation states: "From 21 July 2025, the response timeframe for disputes opened on payments processed locally in the United States and Canada is 9 days. For disputes opened before this date in the United States or Canada, and for all other countries and regions, the response timeframe is 18 days."

Nine days, out of the network's thirty. The rest is the acquiring side's processing, packaging and submission time, and it is entirely reasonable that they keep some. But it means the deadline in your email is not the deadline in the rulebook. It is a portion of a portion, and the size of your portion is set by your processor rather than by the network.

That explains something merchants find maddening: two businesses on two processors, disputing the same kind of transaction under the same network rules, get different amounts of time. Neither is being treated unfairly. They are working to different numbers because different companies set them.

One more consequence of reading the network's own document: for fraud disputes, the tables have no Dispute Response stage at all. The move available to the acquiring side is a pre-arbitration attempt, on the same thirty-day limit. The process is not one shape with one name; it is several, and which one you are in determines what is even possible.

Calendar days, and the weekend is inside them

Short, but it changes the arithmetic more than anything else in this article.

The network's limit is expressed in calendar days. Not working days. A dispute notification that lands on a Friday afternoon in a business that closes at weekends has already spent two of its days before anyone reads it, and a public holiday takes another.

Set that against the nine-day window Adyen gives its American and Canadian merchants, and the practical figure for a small business is closer to five or six working days, during which somebody has to find the original order, the delivery confirmation, the correspondence, and whatever else the case needs. For a business where the person who knows all of that is also the person serving customers, that is not a comfortable amount of time. It is a plausible reason for a dispute to go unanswered by a business that had a perfectly good case.

One submission, and that part is not a quirk of your processor

It would be easy to assume the single-submission rule is one platform's design choice. It is not. Four processors, four sets of documentation, the same answer.

Stripe: "You've only one opportunity to submit your response. Stripe immediately forwards your response and all supporting files to the issuing bank. You can't edit the response or submit additional files, so make sure you've assembled all your evidence before you submit."

Adyen: "There is no opportunity later in the process to provide information or to update information you provided."

Square, describing what happens after submission: you "can no longer add or remove any evidence."

PayPal: "Submit all evidence at the same time, you may not have the opportunity to submit additional evidence."

So the window length varies by processor and the one-shot rule does not. That is a useful thing to hold in your head, because it inverts the usual instinct. The temptation on a Friday afternoon is to send something quickly and follow up with the rest on Monday. There is no follow-up. And sending early does not mean being judged early. Stripe forwards your response to the issuing bank straight away, but the issuer then takes "usually 60-75 days" to decide, and nothing on either side of that hurries the answer.

There is a formatting trap sitting underneath all of this. Stripe's best practices warn that "The card issuer won't review a response containing any illegible text or data", and the page on responding adds that only one file per type of evidence may be submitted, so several documents of the same kind have to be combined into one before sending. A case that is strong on the facts can still be discarded for arriving in the wrong shape, and you find that out once.

If you would rather have somebody go through what your business would actually be able to produce inside a window that short, that is the process audit. $299, three business days, and a written map you keep whether or not you hire us.

Silence is now an answer

This is the part that matters most to a business running on automation, and it is recent enough that most advice has not caught up.

Stripe's Smart Disputes documentation says: "If you don't take any action, Smart Disputes automatically submits the pre-filled evidence packet just before the dispute times out. This ensures you don't miss any deadlines." The same page adds: "Each evidence packet contains data available to Stripe at the time we generate the packet, and you're responsible for making sure that data is accurate and complete."

Read that against "You've only one opportunity to submit your response."

Doing nothing used to mean losing by default, which was bad but at least unambiguous. Doing nothing now means an automated packet is assembled from whatever your integration happened to record, submitted on your behalf at the last possible moment, and your single opportunity is spent. You are responsible for the contents of a document you did not read.

This is a defensible design. Missing deadlines was the larger problem, and an automatic submission is better than an empty one. But it changes what a business owner needs to know from "what do I do when a dispute arrives" to "what does my system already say about this customer, and would I be happy submitting it unread". Those are different questions, and only one of them can be answered in advance.

The dispute events are precise and machine-readable, which is what makes ignoring them an automation problem rather than bad luck. Stripe's event list includes one for when a dispute is created, one for when funds are withdrawn, one for when they are reinstated, and one for when the dispute closes. The dispute record itself carries the date the evidence is due and whether that date has passed. An integration that listens only for successful charges will never learn that the money went back out.

The evidence was supposed to be collected months ago

Now the part that changes what you build, rather than what you do on the Friday.

On 15 April 2023, Visa changed the rules for a common category of fraud dispute. The date comes from Visa's own merchant FAQ, which states: "The Visa rule change is effective for pre-arbitration attempts processed on or after 15 April 2023." The same document explains what changed: "effective April 2023, Visa is updating dispute rules relating to fraud condition code 10.4. This updated rule invalidates a dispute if evidence provided supports that the cardholder (or authorized person) participated in the transaction."

The interesting part is what counts as that evidence. Visa's document lists an item description as mandatory, then requires at least two matching details across the disputed and undisputed transactions, drawn from the customer's account or login ID, the delivery address, the device identifier, and the IP address - with at least one of those two being a device identifier or IP address. And it requires two prior undisputed transactions from the same customer, in a band running from 120 to 365 days before the dispute was processed.

Sit with the shape of that requirement for a moment. The evidence that wins is a comparison between this transaction and two transactions from between four months and a year ago. It is data that had to be captured at the time of those earlier sales, when nothing was wrong, when nobody was thinking about disputes.

You cannot assemble it inside a nine-day window. You either recorded it or you did not. This is the strongest argument in the whole subject for treating your records as an asset rather than an archive, and it is not an argument anybody makes on the Friday the email arrives, because by then the answer is fixed.

Stripe's restatement of the rule adds two further conditions: the prior transactions must have had no fraud reported against them, and must have been processed "more than 119 calendar days and fewer than 366 calendar days prior to the disputed transaction processing date". Note that Stripe's page does not carry the effective date. If you want to know when this started applying, the answer is in Visa's document and not in your processor's.

You cannot refund your way out of it

The instinct, for a lot of small business owners, is entirely decent: the customer is unhappy, so give them their money back and end the argument.

It does not work, and it fails at the level of the software. Stripe states it directly: "You can't issue a refund outside the dispute process while the dispute is open." The refund button is not merely discouraged; the request is rejected by the platform, and the merchant who tries it learns the rule from an error message.

The window for that generous impulse is before the dispute exists, not after. Stripe puts it in one line: "If you issue a full refund on a charge before a dispute happens, the cardholder can't dispute it."

Which is a genuinely actionable piece of information, and it points at something operational rather than financial. The gap between an unhappy customer and a formal dispute is often days or weeks of the customer trying to reach you. Any automation that shortens the time between a complaint arriving and a human seeing it is, among other things, dispute prevention. That is a less exciting way to frame a support inbox than most, and a more honest one.

There is a related trap for anyone tempted to automate the response. A rule that says "dispute arrives, refund the customer" does not merely fail to help; it errors out, and depending on how it was built, it may fail silently, leaving everyone believing the matter was handled.

Winning still costs money

The arithmetic of disputes is not the arithmetic of the transaction, and getting this wrong leads businesses to fight cases that were never worth fighting.

Stripe charges a fee for receiving a dispute, and the sentence about returning it carries a condition worth quoting in full: "Stripe returns the dispute countered fee if you win the dispute. Unless otherwise stated in your Stripe contract, we never return the dispute received fee." A separate support page is blunter still: "The dispute received fee can't be avoided once a cardholder initiates a dispute."

On 17 June 2025, Stripe introduced a second fee, charged for countering a dispute rather than for receiving one. That one is returned if you win. The company's stated reason is that "In recent years, card networks have increased fees for handling disputes."

The effect of that change on behaviour is easy to predict: a merchant hit with a first chargeback learns that the received fee is paid no matter what, that responding costs a second fee, and that the cheapest course on a small amount is to block the customer and eat the loss.

Then there are the figures almost nobody watches until they are a problem, and there are two of them. Stripe notes that "All disputes, whether they're won or lost, count towards your dispute rate", and separately that the networks' monitoring programs work from a second measure: "The credit card processing industry standard recognizes dispute activity above 0.75% as excessive", with a sudden spike or a steep upward trend able to trigger a monitoring program before that threshold is reached. Winning does not remove a dispute from either count. A business that wins every case it fights and attracts too many of them is still in trouble with its processor.

So the honest calculation on any individual dispute is: the amount, minus a non-refundable fee, minus the hours, multiplied by a probability that Stripe's own guidance describes soberly - "Even in the most favorable cases, it's very difficult to overturn a disputed payment." Sometimes the answer is to fight. Frequently it is not, and there is no shame in the arithmetic. Accepting a dispute, Stripe notes, "isn't considered an admission of wrongdoing".

Who actually decides

There is a harder question underneath all of this, and it deserves an honest answer rather than a tidy one: who actually decides. Stripe says the outcome "is at the sole discretion of the account owner's bank", and that it "doesn't have influence over the outcome". Visa's rulebook tells a longer story, describing a multi-stage cycle running through dispute, response, pre-arbitration and arbitration, with the later stages decided by the network rather than the issuer. And Stripe separately notes that it "doesn't support the arbitration phase for disputes, which means that you can't escalate disputes to arbitrators through our platform."

The reconciling reading is that the first decision belongs to the issuing bank, the later stages belong to the network, and your processor may not take you to them. Which is a longer answer than "the bank decides", and a more useful one if you are deciding how much to invest in a case.

The only thing fully automatable is giving up

A small detail from Visa's glossary, and one of those facts that says more than its size.

The rulebook defines a service called Rapid Dispute Resolution as "A pre-dispute resolution service that provides the ability for Merchants and Payment Facilitators to automate the acceptance of liability for a disputed Transaction."

The network has a named, defined, end-to-end automated path for conceding. Contesting a dispute has no equivalent, because contesting requires judgement about specific evidence in a specific case, and no rulebook can automate that.

This is not a criticism of anybody. It is an accurate description of where the line falls between what software can do for you and what it cannot, and it is worth knowing before you go looking for a tool that makes disputes go away. The automatable parts are: noticing that a dispute exists, telling a human within hours rather than days, and assembling the evidence that already exists into one place. The deciding stays with a person. That boundary is the same one described in what happens when your automation gets something wrong, and it moves less often than people hope.

What to check in your own setup

Find out where a dispute notification actually lands. Not in theory: which inbox, whose phone, and how quickly it would be seen on a Friday evening. In a window measured in calendar days, notification speed is most of the game.

Ask your processor for your number, in days, in writing. Not the network's number and not a range from a documentation page. Yours, for the schemes you accept. If it is nine days, plan for five working ones.

Find out what your system would submit if you did nothing. If your processor assembles and files a packet on your behalf, look at what it would contain for a recent order. That document is your one submission.

Check what you record at the time of sale. The historical evidence the rules now recognise has to exist before the dispute does. Whether your systems keep it is a decision somebody made years ago, probably without knowing they were making it.

Put a rule around refunds and complaints. The generous refund only works before a dispute is opened. Anything that shortens the gap between a customer complaining and a person answering is worth more here than anything that happens afterwards.

Watch both figures, not just the cases. Wins count towards them too, and the one the networks' monitoring programs use is not the same one your dashboard leads with. If nobody at your business knows either number, that is the first thing to find.

When this stops being a settings question

For a business with a handful of disputes a year, the checks above are the whole job. Know where the email lands, know your number in days, and know what you would send.

It stops being that when the dispute has to touch more than one system. The payment lives with the processor, the order in the shop, the delivery evidence with the courier, the conversation in an inbox, the accounting entry somewhere else again, and the answer has to be one document assembled from all five inside a week that includes a weekend. That is not a settings problem. It is the same class of problem as the order that was cancelled after the invoice went out, where one event has to propagate across systems that each hold a different piece of it, except that here there is a clock and it belongs to somebody else.

Working out whether you need a checklist or a build is what the process audit settles: what can be automated, in what order, and what each piece is worth, in writing, in three business days.

Nothing here is legal or financial advice, and the rules differ by card network and by country.

Related: work out when your marketplace money actually lands covers the other way money you have earned turns out not to be money you have, and orders stopped arriving, and the other end stopped calling covers what happens when the events that would have told you go unheard.