Did-not-arrive fraud is a refund scam in which the buyer claims a package never arrived or was stolen after delivery. The objective is to obtain a refund without returning the product. This tactic is difficult to prove against when merchants rely on signatures, GPS data, or delivery photos alone.
Expanded Definition
Did-not-arrive fraud sits in the broader class of chargeback and refund abuse, but its defining feature is the false claim of non-receipt after a parcel has already been delivered. The dispute is usually framed as a delivery failure, loss, or theft, which shifts the burden onto the merchant to disprove a claim that may be hard to rebut if the only evidence is a signature, a carrier scan, or a doorstep photo.
The term is narrower than ordinary customer dissatisfaction because the intent is to secure a refund while keeping the item. It is also distinct from transit loss, where the seller or carrier genuinely cannot account for the parcel. For that reason, the key boundary is not whether a delivery event exists, but whether the customer is disputing a completed delivery with a fabricated receipt narrative. In merchant operations, the practical issue is evidentiary quality, not just fraud detection.
Industry guidance is broadly consistent that delivery proof should be assessed as a bundle of evidence rather than a single data point. Carriers, payment processors, and merchants often differ on what they consider sufficient, so the meaning of “not arrived” can vary across dispute workflows and claims handling.
Examples and Use Cases
Did-not-arrive fraud appears in many retail and marketplace workflows, especially where refund friction is low and delivery evidence is incomplete.
- A customer opens a support ticket claiming the parcel never arrived, then asks for a refund after the carrier tracking page shows “delivered.”
- A marketplace buyer disputes a transaction and asserts porch theft, even though the merchant has a delivery photo and geolocation scan.
- An address with repeated successful deliveries becomes the setting for a claim that a package was stolen immediately after drop-off.
- A subscription or low-value item is targeted because the refund amount is small enough that the merchant may prefer a quick concession over investigation.
- A merchant uses dispute rules to decide when proof of delivery is enough and when additional verification, such as customer history or carrier exception data, is needed.
One common tradeoff is speed versus evidentiary depth: a fast refund process improves customer experience, but it can also create a low-friction path for repeat abuse when the same delivery signals are treated as conclusive in every case.
For merchants building a control baseline, NIST’s control catalog is useful for thinking about evidence retention and monitoring discipline, even though it does not define this fraud type directly. The official source is NIST SP 800-53 Rev 5 Security and Privacy Controls.
Security Implications
Did-not-arrive fraud creates direct financial loss, but the broader security issue is trust erosion in refund and dispute handling. If merchants accept weak delivery evidence as definitive, abusive customers can learn which order types, carriers, or geographies are easiest to exploit. That can increase repeat claims, skew operational metrics, and quietly normalize weak exception handling.
The failure mechanism is usually evidentiary, not technical: a merchant relies on a single delivery signal that looks authoritative but does not answer the real question of receipt, control, or custody. A signature can be forged or obtained by another person, GPS data can show drop-off rather than possession, and delivery photos may prove presence at an address without proving the buyer received the item. Once those signals are treated as final, the dispute process can become easy to game.
The practical symptom is a pattern of high-confidence delivery evidence paired with persistent refund claims. At that point, the problem is not one isolated complaint but a control gap in how the merchant distinguishes genuine loss from opportunistic fraud.
Domain and Governance Relevance
In ecommerce and payments, did-not-arrive fraud matters because it sits at the boundary between customer service and loss prevention. Treating every non-receipt claim as a logistics issue can leave fraud teams without clear ownership, while treating every claim as hostile can create poor customer outcomes and avoidable dispute escalation.
The governance question is how delivery evidence is weighted, who can override a refund decision, and what history triggers additional review. That matters most where the merchant depends on third-party carriers, because the organisation does not fully control the final mile but still carries the financial and reputational impact of false claims.
For identity and access teams, the concept is mostly indirect. It becomes relevant only where refund abuse is tied to repeated account creation, synthetic customer behaviour, or misuse of trusted buyer profiles. In those cases, the underlying issue is still refund integrity, not identity security itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the technical controls, while PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM — Risk Management Strategy | Repeated refund abuse is a business and security risk that needs governance. |
| DE.CM — Security Continuous Monitoring | Patterns of repeated non-receipt claims are an observable abuse signal. | |
| Recommendation — Define refund-abuse thresholds and assign ownership for dispute escalation decisions. Monitor refund claims for repeat patterns and exception clustering. | ||
| CIS Controls v8 | 8.1 — Audit Log Management | Delivery and dispute evidence must be retained and reviewable. |
| 13.4 — Data Protection and Recovery | Fraud handling depends on preserving operational records from tampering or loss. | |
| Recommendation — Retain dispute and delivery evidence so investigators can reconstruct claim history. Protect order and delivery records so claim evidence remains trustworthy. | ||
| PCI DSS v4.0 | 10.2 — Audit Logs Enabled | Payment dispute handling benefits from complete, reviewable transaction records. |
| Recommendation — Keep transaction and chargeback records available for fraud review and evidence. | ||
Related resources from NHI Mgmt Group
- What is the difference between account takeover and new account fraud?
- Who is accountable when a SoD conflict leads to fraud or compliance failure?
- Why do conflicting access rights increase fraud risk more than broad access alone?
- Why do ecommerce AI agents complicate fraud detection and access governance?