One question, and only one

Of all the reason codes a Stripe merchant will face, product_not_received is the most clarifying, because it asks a single, answerable question: did the thing the customer paid for actually reach them? Not whether they liked it, not whether they authorized the purchase — just whether it arrived. That narrowness is good news. It means you don't have to argue intent or interpret a vague complaint. You have to prove a delivery, and delivery either happened or it didn't.

This is one of the more winnable disputes for merchants who keep records, and one of the more frustrating to lose, because losing it usually means the proof existed and wasn't assembled in time. Let's walk through what actually wins it.

What the customer is claiming

When a cardholder files a "product not received" — also phrased as "merchandise or services not received" depending on the network — they're telling their bank that they paid and got nothing. Sometimes that's true: a package was lost, a digital delivery failed, a service was never rendered. Sometimes it's friendly fraud — the genuine customer received the order and disputed anyway, perhaps because they forgot, perhaps because disputing was easier than returning. From the bank's seat the two look identical, and your job is the same in both cases: demonstrate that delivery occurred.

Because the claim is about arrival, your evidence has to be about arrival. This is where merchants go wrong with adjacent-but-irrelevant proof — a receipt showing the customer paid (nobody's disputing that they paid), or proof of the customer's identity (nobody's disputing who bought it). Those answer questions that weren't asked. The bank wants to see the parcel reach the destination.

The evidence that actually wins it

For a physical good, the core of your case is the carrier's record:

  • The carrier name and tracking number, so the bank can verify independently rather than take your word.
  • A delivery confirmation showing the shipment was marked delivered — ideally with a date and the delivery address.
  • The shipping address, matched against the cardholder's billing address. This is the quiet linchpin. If you can show the parcel went to the same address the cardholder verified with their own bank, you've connected the delivery to the customer, not just to some location. A delivery to the billing address is dramatically harder to argue against than a delivery to an unrelated drop point.
  • Date stamps that line up — order date, ship date, delivery date — forming a coherent sequence.

For a digital product or service, the equivalent evidence is access and usage: server logs showing the download completed or the account was activated, login timestamps, the email confirming access was sent and to which address, and any record of the customer actually using what they bought. A customer who claims they never received access but logged in four times has refuted their own dispute, and your logs are the proof.

Build the timeline, don't just dump the proof

Evidence wins, but only when a reviewer can read it quickly. An issuing-bank reviewer spends very little time per case, so hand them a story, not a pile. Write a short, factual, chronological account and let the attachments back each line:

The customer placed order #1043 on May 2. We shipped via the carrier on May 3 under tracking number [X]. The carrier's record shows the parcel delivered to the customer's billing address on May 6. The customer first contacted us on May 21 — fifteen days after delivery — and at no point requested a return or reported a missing package before filing this dispute.

That last sentence quietly matters. The gap between delivery and complaint, and the absence of any prior "where's my order" message, is itself evidence that the customer received the item and disputed for some other reason. You're not accusing them; you're laying out a timeline the reviewer can verify against your attachments and draw the obvious conclusion from.

What weakens an otherwise strong case

A few avoidable things sink winnable "not received" disputes. Shipping to an address that doesn't match the billing address, with no explanation, invites the argument that someone else received the goods. Tracking that shows "in transit" or "label created" but never "delivered" proves you sent something into the system, not that it arrived — and that gap is fatal. Vague carrier records with no date or destination give the reviewer nothing to verify. And, most common of all, missing the deadline so the entire case is never read.

If your tracking genuinely shows the parcel was not delivered — lost in transit, returned, stuck — then this is a dispute you'll likely lose, and honestly should, because the customer's claim is true. Recognizing that early saves the effort of fighting an unwinnable case and lets you resolve it as a goodwill refund or reshipment instead. Knowing which "not received" disputes are real and which are friendly fraud is half the skill.

The prevention that compounds

Because this reason code turns on records you either kept or didn't, the merchants who win it consistently are the ones who made good shipping records automatic long before any dispute. Always capture tracking. Prefer carriers that provide delivery confirmation. Ship to the billing address when you can, or document clearly when a customer asks you not to. Send a delivery notification the customer will remember, which both reduces honest "I never got it" confusion and creates another timestamp for your file. None of this is exotic; it's just the difference between reconstructing a delivery under deadline pressure and having the proof already sitting in order.

Do that, and the next "product not received" dispute stops being a scramble. The carrier already documented the delivery. You just have to present it, in order, before the clock runs out.

Where Argeback fits

Argeback is built for exactly this kind of reason-code-specific fight. When a product_not_received dispute lands in your Stripe inbox, it doesn't hand you a blank file picker — it asks the questions that win this claim: the carrier and tracking number, the delivery confirmation, whether the shipping address matched billing, the date of first customer contact. It assembles those answers into the clean chronological narrative a reviewer can verify, packages the structured evidence, and files via the Stripe disputes API in one tap, with deadline alerts so the case is never forfeited unread. The issuing bank still decides whether the delivery proof carries the day. Argeback makes sure that proof is the proof you actually submit.