What is the difference between did-not-arrive refund abuse and fake tracking ID refund abuse?

Did-not-arrive abuse relies on a false claim that the parcel never reached the customer, or was stolen, so the fraudster seeks a refund without returning goods. Fake tracking ID abuse manipulates the return process itself, usually by altering labels or addresses so tracking shows a bogus return as delivered. One attacks delivery claims, the other attacks return verification.

Why the Two Refund Frauds Are Not the Same Control Problem

Did-not-arrive refund abuse and fake tracking ID refund abuse both exploit trust in delivery evidence, but they break different parts of the refund workflow. The first targets the merchant’s assumption that a customer’s receipt claim is honest; the second targets the merchant’s reliance on tracking data and return logistics as proof of return. That distinction matters because each abuse pattern needs different verification points, escalation rules, and fraud signals, which is why generic “proof of delivery” logic often misses one of them. For broader control thinking, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful as a control catalogue for evidence handling, accountability, and logging, even though it does not describe retail refund fraud directly. In practice, many teams discover the difference only after one refund pattern keeps slipping through the same review queue that was built for the other.

How the Abuse Mechanisms Diverge in Practice

Did-not-arrive abuse usually starts with a claim about non-receipt, theft, or missing contents. The fraudster wants the merchant to accept that the parcel never arrived, or arrived in unusable form, so the refund is issued without a return. The key weakness is not the tracking number itself, but the merchant’s dependence on customer assertion when the delivery evidence is incomplete, ambiguous, or too costly to challenge.

Fake tracking ID refund abuse attacks a different control point. Here the fraudster creates a false return signal, often by using a counterfeit label, a misdirected address, or a tracking number that appears to validate the return even though the item was never properly sent back. The weakness is the merchant’s trust in the existence of tracking status rather than in a verified physical return intake. That means a system can look “successful” on paper while the returned item never re-enters the merchant’s custody.

Operationally, the two fraud types require different evidence. For did-not-arrive abuse, teams need to examine delivery confirmation quality, prior claim history, address anomalies, and whether the dispute pattern matches a customer-side receipt claim. For fake tracking ID abuse, the important question is whether the return object was actually received, inspected, and matched to the original order, not whether a tracking page showed movement. A useful control set separates outbound proof from inbound return proof, rather than treating them as interchangeable signals.

Did-not-arrive abuse focuses on the claim that delivery never happened.
Fake tracking ID abuse focuses on creating a false return trail.
One is resolved by strengthening delivery proof; the other by strengthening return intake verification.

The guidance breaks down when a merchant uses one tracking signal to stand in for both delivery and return confirmation.

Where the Edge Cases and Exceptions Create Confusion

Tighter refund verification often increases customer service friction, requiring organisations to balance fraud reduction against legitimate dispute handling. That tradeoff is especially visible when shipments are delayed, carriers scan inconsistently, or return processing is partly outsourced.

There is no perfect consensus on how much carrier data alone should count as proof. Some organisations treat carrier tracking as strong evidence for low-value claims, while others require secondary checks once refund velocity, address changes, or repeat disputes cross a threshold. The important distinction is that did-not-arrive abuse usually benefits from weak delivery confirmation, while fake tracking ID abuse benefits from weak return reconciliation. A claim can be genuine in one stage and fraudulent in another, so teams should avoid collapsing the full lifecycle into a single status flag.

Marketplace, dropship, and cross-border flows make the difference harder to see because the merchant may not directly control the carrier, the return address, or the inspection point. In those cases, the relevant question is not simply “did the package move,” but “which party had custody at each step, and what evidence proves that transition.” Where that chain is fragmented, the fraud risk rises because the same status update can be misread as proof of either delivery or return.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	6 — Access Control Management	Supports limiting abuse by tightening approval and verification flows.
	8 — Audit Log Management	Return and dispute workflows need auditable evidence to distinguish claim types.
	12 — Network Infrastructure Management	Fraud detection depends on reliable platform and workflow integrity signals.
Recommendation — Apply Control 6 to require stronger validation before issuing refunds. Use Control 8 to retain dispute and return evidence for review. Use Control 12 to preserve trustworthy order and return status data.
NIST CSF 2.0	PR.AC — Identity Management, Authentication, and Access Control	Refund approvals should be constrained to trusted and attributable workflows.
	DE.AE — Anomalies and Events	Repeat claim patterns and abnormal return signals are fraud indicators.
	RS.MI — Mitigation	Fraud cases need fast containment once false claims or false returns are confirmed.
Recommendation — Apply PR.AC to restrict refund actions to verified personnel and processes. Use DE.AE to flag unusual refund and return behaviour for review. Use RS.MI to stop fraudulent refund paths quickly once identified.
MITRE ATT&CK	T1656 — Impersonation	Refund fraud often depends on misrepresenting entitlement or transaction status.
Recommendation — Map impersonation-like refund claims to T1656 and investigate entitlement abuse.

Practitioner Guidance

What to prioritise: Separate delivery verification from return verification in policy, tooling, and investigations. If the team treats both as the same evidence problem, it will overfit controls to one abuse pattern and leave the other open.

What to verify: For did-not-arrive claims, verify whether the delivery signal is strong enough to support a refund decision, including address consistency and claim history. For fake tracking ID claims, verify physical return intake, item matching, and whether the recorded tracking event actually corresponds to the merchant’s custody of the product.

Decision rule: If the dispute is about non-receipt, investigate the outbound delivery path; if the dispute is about a return, investigate custody transfer and intake confirmation. Do not let a generic “tracking exists” check resolve both.

What practitioners underestimate: Fraudsters often exploit whichever step is easiest to automate or outsource, so the highest-risk gap is usually the handoff between carrier evidence and internal reconciliation, not the fraud label itself.

Practitioner takeaway: The best control design asks a simple question at each stage: what evidence proves customer receipt, and what evidence proves merchant re-custody?