The strangest chargebacks are the ones where you were still waiting on them.

You sent the intake form in week one. You sent a reminder in week two. By week three you wrote, kindly, that you couldn't start the design until you had the logo files, the passwords, the answers to the questionnaire. Then silence. You kept the project slot open for a while, because that's what decent people do. Then a notification arrives: your client has disputed the charge. The reason, in effect, is that the services were never received.

It feels like being accused of leaving a party you were never allowed into. And the dispute system, left to its defaults, will treat it exactly that way.

Why the silent client files the dispute

It helps to understand what is probably happening on the other side, because it shapes your evidence.

People avoid tasks that make them feel behind. Behavioral scientists describe this as avoidance coping: when something triggers discomfort, such as a half-finished questionnaire or the guilt of having ignored three emails, the easiest short-term relief is not to look at it. The longer the silence, the more awkward breaking it feels. Eventually the client opens their card statement, sees your name next to a charge for something they never "got," and the dispute button offers a clean exit from the whole uncomfortable situation.

That's not necessarily malice. Often it's a person who stopped engaging and now reads the project as something that never happened. But a reviewer at the card network doesn't know any of that. They see a cardholder claiming services weren't provided, and a merchant who hasn't yet said anything.

Your job is to show, in plain chronological terms, that the work was available, the path to delivery was open, and the one missing ingredient was theirs to supply.

What the reviewer is actually deciding

In a "services not received" dispute, the question is narrow: did the merchant provide, or make available, what was paid for? The reviewer isn't judging whether you were a nice person or whether the client was flaky. They're looking for documentation that the service was either performed or that you were ready and able to perform it and were prevented by the customer.

That second half is the one most merchants forget to argue. They try to prove delivery, can't, because delivery never happened, and give up. But "I was ready and they didn't respond" is a legitimate story if it's documented. The key word is documented.

The dependency record

The single most valuable piece of evidence in this situation is what I'd call a dependency record: a clear showing of what you needed from the client, when you asked for it, and what happened next.

It has three layers.

1. The agreement that named the dependency. Somewhere, before payment, there should be a line stating that work begins once the client supplies certain things, whether that's access, files, approvals, or a completed brief. This can be in a proposal, an order confirmation, a checkout page, or a signed scope document. If the dependency was only mentioned later, it's weaker, but later messages still help.

2. The requests. Every message where you asked for the missing item, with timestamps. Emails, DMs, project-tool notifications, even a text. Show that you asked more than once and that the asks were specific, not vague nudges.

3. The silence. A simple record that no reply came, or that replies stopped at a certain date. Include the last message from the client, because it frames where the relationship went quiet.

Together these demonstrate something the reviewer can verify with their own eyes: the delay is attributable to the cardholder.

Prove the work was real, even if it wasn't finished

The dependency record explains why you didn't finish. You also want to show that you did something, or were ready to.

Anything that proves effort on their behalf counts:

  • Drafts, outlines, research notes, or partial deliverables created before the silence.
  • Calendar holds or booking records showing you reserved time for the project.
  • Internal work logs, tickets, or timestamps from your project tool.
  • Any deliverable you offered to hand over even in incomplete form.

For Stripe's evidence form, this kind of material fits naturally into the service documentation and customer communication fields, with the narrative explanation in the free-text field. Keep file formats readable; a screenshot of a project board that a reviewer can parse in ten seconds beats a forty-page export.

Show that the door was left open

A reviewer is more persuaded by a merchant who stayed reasonable. If you sent a final message, something like "I'm holding your project slot until this date; once I have the files I can begin and finish within X days," that single email does heavy lifting. It tells the reviewer you hadn't abandoned the client and that the path to getting what they paid for was still available to them.

If you never sent such a message, don't send one now pretending it's the old situation. Be careful here: contacting the customer after a dispute can be useful to resolve it, but never fabricate or backdate anything, and don't pressure them. Present exactly what happened and let the dates speak.

Build the one-paragraph narrative

A good response for this dispute fits in a few sentences, with the documents behind it. The shape looks like this:

The customer purchased [service] on [date]. As stated in [agreement], work begins once the customer provides [specific item]. We requested it on [dates], attached. The customer last responded on [date] and has not provided it since. We completed [any preparatory work] and remain ready to deliver upon receipt. The service was therefore available and its delay is attributable to the cardholder.

No adjectives. No complaints about how rude they were. The calm tone is itself a form of credibility.

Your next moves

  • Put the dependency in writing at checkout. Add one sentence to your proposal or order confirmation: "Work begins once we receive [files/access/answers]." Do it today; it becomes the foundation of any later dispute.
  • Create a request log. For every active project, keep a simple dated list of what you asked the client for and when. A shared note or spreadsheet is enough.
  • Send a "slot-holding" message at the two-week mark. State what you're waiting on, what you'll do once you have it, and how long you'll hold their spot. Keep it neutral and kind.
  • Screenshot threads before they scroll away. Capture the full email or chat history, with visible dates, into one folder per client. Project tools and inboxes archive and purge more quickly than you'd expect.
  • Mark your response deadline the moment a dispute lands. You generally have about a week to submit, and evidence can't usually be reworked once sent, so gather the dependency record first, then file once.

What this won't fix

It's worth being honest about limits. If your agreement was vague about what the client owed you, or you never asked clearly, the evidence will be thin, and no narrative can invent it. And if you truly didn't do the work you were paid for, a refund may be the right outcome. The point isn't to win every dispute; it's to avoid losing ones where the facts were on your side but the paperwork wasn't.

Most merchants in this spot lose by default. Not because the client was right, but because the response was never filed, or was filed as an angry paragraph with nothing attached.

Where Argeback fits

The hard part of this kind of dispute is rarely the argument. It's gathering a scattered trail of requests, reminders, and last-seen messages and turning it into a clean response before a clock you can't see runs out. Argeback pulls your Stripe disputes into one place, drafts an evidence-backed response from what you have, and files it ahead of the 7-day deadline, from your phone, so a quiet client doesn't turn into a quiet loss. If that sounds useful, you can take a look at Argeback.