Item-not-received chargebacks are lost to silence, not to fraud

The problem

A small online store gets a dispute notice: the buyer told their bank the parcel never arrived. The seller has a tracking number, a delivery scan and probably an email where the buyer said thanks. That evidence lives in the store admin, the carrier site, the inbox and sometimes a helpdesk.

Assembling it takes an evening, and the processor's deadline is short. So many sellers either respond late, respond with a bare tracking link, or accept the loss. They lose the sale, the goods, the shipping cost and a dispute fee, and a rising dispute rate puts their payment account at risk.

Existing chargeback services mostly target larger merchants and often charge a share of recovered funds, which feels expensive on small orders. Processor dashboards give an upload form, not an assembled case.

Constraints

• Budget: a flat, low monthly cost. A percentage of every win is a hard sell.
• Skills: the seller is not a developer. Setup must be connecting accounts, nothing more.
• Data: tracking quality varies by carrier. Some give a delivery scan only, some add signature or location.
• Deadlines: the processor's due date is fixed and earlier than people assume.
• Format: processors limit evidence by field, file type and size.
• Trust: a submitted rebuttal is a statement to a bank. It cannot contain a claim the seller cannot back up.
• Privacy: customer emails and addresses must not be retained longer than the case needs.

System design

Most of this system should be deterministic.

• Intake: a webhook on dispute creation (for example disputes/create on the store platform) writes a case row with the reason code and due date.
• Collector: plain code pulls the order, fulfillment, carrier tracking events, refund history and prior orders from the same customer. Each item gets an evidence ID.
• Checklist: a static table maps reason code to required evidence. For item not received, that means shipped-to address, delivery scan, and whether the delivery postcode matches.
• Gap detector: flags missing or contradictory evidence, and recommends accepting when the case is weak. That recommendation is a rule, not a model judgment.
• Correspondence scan: this is where an LLM belongs. It reads emails tied to the order number and extracts lines where the buyer acknowledges receipt, quoting them verbatim with message IDs.
• Narrative draft: a model writes the rebuttal from the assembled facts only. A validator rejects any sentence that does not cite an evidence ID, and checks that quotes match the source text exactly.
• Review: the seller sees one screen with evidence, draft and deadline, edits, and approves. Submission through the processor API is deterministic and idempotent per case.

Trade-offs

It does not prevent disputes. Better delivery confirmation and clearer billing descriptors do that, and they are a separate product.

It never auto-submits. That costs the seller a few minutes per case, which I think is right for a statement made to a bank under their name.

The model's role is small on purpose. Most wins come from complete evidence on time, not from eloquent prose, so I would rather the narrative be plain and fully cited than persuasive.

What I would build first

One platform, one processor, one reason code: item not received. A webhook, a carrier tracking lookup through a single aggregator, the checklist, and a generated evidence packet plus draft text sent to the seller by email with the due date in the subject line.

No submission API yet. The seller pastes and uploads.

Dispute outcomes take longer than two weeks to arrive, so I would measure what moves sooner: the share of disputes answered before the deadline, and the time from notice to response.

When a deadline drives the outcome, assemble the evidence with deterministic code and let a model only write prose that cites what the code found.