The merchant who has nothing to ship
A furniture store fighting a "never arrived" dispute has it easy, in one narrow sense. There is a carrier. There is a tracking number. There is a scan at the door, sometimes a photograph of a box on a porch, occasionally a signature. The whole machinery of physical logistics exists, in part, to answer a single future question: did the customer get the thing they paid for?
Sell a software license, a course, a PDF, an API key, or a month of access to something, and that machinery vanishes. Nothing leaves a warehouse. No truck moves. When the cardholder tells their bank "I never received what I paid for," you reach for the tracking number that doesn't exist — and feel the floor drop out.
This is the quiet trap of digital goods. The product is easy to deliver and nearly impossible to prove you delivered. And the dispute category that punishes you for it — Visa's 13.1, Mastercard's equivalent under reason code 4855, both labeled some version of "Merchandise or Services Not Received" — is one of the most common reasons digital merchants lose money they earned.
You are not proving a delivery. You are proving an access.
The first mental shift is the most important one, and most merchants never make it.
A physical merchant proves arrival: the object crossed a threshold into the customer's possession. You cannot prove that, because nothing physical ever arrived. What you can prove is something better suited to how digital products actually work: that the customer reached the thing. Logged in. Downloaded the file. Streamed the video. Activated the key. Opened the lesson.
Digital delivery isn't a moment of handoff; it's a record of contact. The product sat on your server, the customer's device came and touched it, and your systems wrote that contact down. The entire job of a "not received" response for digital goods is to surface those records and lay them next to the transaction.
Card networks already understand this. Visa's dispute rules explicitly contemplate digital delivery and accept, as evidence, things no carrier ever provides: the IP address used to access the goods, the device's identifiers, the email or account the product was delivered to, geolocation data, and timestamps showing the customer used what they're now disputing. The rails were built with you in mind. Most merchants just never read that part of the rulebook.
The evidence you already have but don't collect
Here is the uncomfortable truth: the evidence to win these disputes is usually generated automatically and then thrown away, or buried somewhere nobody thinks to look during the seven days you have to respond.
Walk through what your own systems quietly record every time someone buys:
The delivery event itself. The email that sent the download link or license key — with its send timestamp and, ideally, an open or click event. The webhook that provisioned the account. The order confirmation. This establishes that you handed over access, and exactly when.
The access event. This is the strongest card in the deck and the one merchants most often forget. Login timestamps. Download logs. Session records. Streaming minutes watched. API calls made against the key. Course modules marked complete. Each of these says the same devastating thing: the person disputing this charge used what they bought.
The identity thread. The account email. The IP address at signup and at each login. The device fingerprint. When the IP or device used during purchase matches the IP or device used to access the product later — and matches the cardholder's general location — you've quietly closed the loop between "who paid" and "who used it."
None of this requires new infrastructure. It requires knowing, before a dispute lands, which tables in your own database hold the timeline.
Build the timeline, not the argument
When you assemble the response, resist the urge to write a persuasive letter. The bank analyst reviewing your case is not a jury you can move with eloquence. They are matching your evidence against a checklist, often in a couple of minutes, often across a stack of dozens of disputes. Rhetoric is noise. A clean chronology is signal.
The structure that wins looks less like an essay and more like a flight recorder:
Purchase at a timestamp, from an IP, on a device, tied to an email. Delivery of access at a timestamp, to that same email. Then — the moment that usually settles it — the customer returning to use the product: logging in three days later, downloading the file twice, watching forty minutes of the course, calling the API two hundred times across a week. Each line stamped, each line tied back to the same identity.
A customer who genuinely never received anything does not generate that trail. The trail's mere existence is the argument. You're not claiming they received it; you're showing them holding it.
The two failure modes
Digital "not received" disputes split into two stories, and they call for different evidence.
The first is honest confusion. The customer bought, the access email hit a spam folder, they assumed the purchase failed, and they disputed it instead of emailing you. Here your delivery records — we sent the key to this address at this time — plus any sign they eventually found and used it will resolve things. Often a copy of the original delivery email is enough.
The second is friendly fraud: the customer received and used the product, then disputed it anyway, betting you won't have the receipts. This is where access logs are lethal. Someone claiming they got nothing while your server shows them logged in last Tuesday is not a sympathetic case to any analyst. The usage record doesn't just rebut the claim; it quietly characterizes the disputer.
Knowing which story you're in tells you which evidence to lead with. Lead with delivery for confusion, lead with usage for friendly fraud.
Why the seven days decide everything
There's a structural cruelty to all of this. The evidence is strongest the moment the dispute arrives and decays from there — not because the data disappears, but because you do. The deadline to respond is short, the records are scattered across your auth system and your email provider and your analytics, and pulling a coherent timeline together by hand is precisely the kind of task a busy operator postpones until it's expired.
Most digital chargebacks aren't lost on the merits. They're lost to silence — the merchant never responded, the bank ruled by default, and a winnable case became a write-off because nobody had two free hours during the week the clock was running. The product was delivered. The proof existed. It just never got assembled in time.
Where this leaves you
If you sell anything digital, do one thing before your next dispute: find out, today, exactly where your delivery and access logs live and how fast you can pull a single customer's timeline. That knowledge — not eloquence, not luck — is what turns a "not received" dispute from an automatic loss into a routine win.
That speed is the whole reason Argeback exists. It ingests your Stripe disputes the moment they land, pulls the delivery and access trail into a clean, evidence-backed response, and files it before the deadline closes — from your phone, in the gap between two other things. The records were always yours. Argeback just makes sure they show up to the fight on time. If a winnable dispute has ever quietly expired on you, that's the problem it was built to end — argeback.lumenlabs.works.