Industry insights
INR Fraud: When the Package 'Never Arrived' Isn't What It Seems
Item-not-received claims look like return fraud in your finance ledger but behave nothing like it in your detection model. Here's the signal set that separates a porch-pirate victim from a serial INR filer, and why most stores lump both into 'fraud loss' and never break them apart.
Your return-fraud dashboard is clean. Return rate is steady, your scoring model is catching the obvious bracketers and wardrobers, and your chargeback ratio is under 1%. Then you look at the finance report and your refund spend is up 18% year over year, and nobody on the operations team can explain why.
The answer, for shipping-heavy stores, is almost always the same. It isn't hiding in your returns. It's hiding in a category most Shopify dashboards don't even surface as a distinct line item: item-not-received claims. INR fraud. The customer says the package never arrived, your carrier says it was delivered, and somebody eats the loss.
The reason this sits in a blind spot is that INR fraud and return fraud look identical on a P&L (both end in a refund) but they behave completely differently upstream. The signals that catch return fraud mostly don't fire for INR. And the signals that do catch INR aren't in most merchants' scoring models at all.
Why INR is its own fraud category, not a subtype of return fraud
A return-fraud claim requires the product to physically come back (or at least for the customer to claim it did). There's a return object in Shopify. There's a reason code. There's often a tracking number on the return leg. A scoring model has many places to hook into: did the stated reason match the product category, is this the customer's fifth "wrong size" return this quarter, did the return shipment actually show delivery movement or just a label creation.
An INR claim has none of that. There's no return, because there's no product to return. The claim isn't inside Shopify's returns domain. It lives in customer service tickets, email threads, and sometimes directly in a chargeback. The only hard facts you have are the original order, the shipment tracking, and the customer's word that they never saw the package.
This matters because the two fraud shapes draw on entirely different data sources. Return fraud lives inside order + return history. INR fraud lives inside delivery telemetry + address history + claim-rate patterns. A detection model built only for the first will never see the second.
The signals that actually separate legitimate INR from abuse
Porch piracy is real. Carriers deliver to wrong addresses. Packages get stolen from apartment lobbies, pulled off boats on delivery days, lifted by "follow the UPS truck" teams in urban neighborhoods. Most INR claims your team gets are legitimate, and refusing them makes you the kind of store customers warn each other about.
The abuse sits at the margin, and it's detectable. Here's the signal set that matters.
Delivery confirmation quality. "Marked as delivered" is not the same across carriers. A USPS scan can be as vague as "delivered to mailbox." A FedEx signature-required delivery with a photo of the package on the porch is a different piece of evidence entirely. An INR claim against a signed-for shipment with a GPS-coordinate match to the shipping address is a claim you should scrutinize hard. An INR claim against a USPS "delivered" scan at an apartment complex with no photo is much more likely to be real.
Your scoring needs to weight the delivery evidence, not just accept "delivered = refuse claim" or "not delivered = approve claim." In practice that means pulling the carrier's detailed event log, not just the final status field Shopify shows you.
Claim-to-order ratio per customer. The single highest-signal feature for INR fraud. A customer with a 3% INR claim rate across their order history is either extraordinarily unlucky or systematically filing false claims. You need at least 3-5 orders from a customer before this signal is informative, but it sharpens fast after that. In our own data, customers with 2+ INR claims in their first 10 orders have a 40-60% probability of filing another within 90 days.
Address history. INR fraud has address signatures. An address that's appeared on 3+ different customer accounts, each of which has filed at least one INR claim, is almost certainly either a reshipper destination or a coordinated fraud node. A mailbox-service address (UPS Store, PostScan Mail) filing an INR claim is a 10x higher base rate than a residential address.
Time-to-claim distribution. Legitimate INR claims cluster at 2-7 days after the expected delivery date. The customer was traveling, or didn't check the mailbox, or assumed the package was still in transit. Fraudulent INR claims cluster bimodally: either within 24 hours of the "delivered" scan (the abuser moves fast) or 25+ days later (right at the chargeback window deadline). A claim filed at hour 3 after the delivery scan for a $200 order is behaviorally different from one filed at day 4.
Order value + category. INR fraud concentrates on resellable goods. A $60 accessory that shows up as an INR claim is suspicious but possible. A $400 electronics item with a 90-day warranty that's selling on eBay next week is a different matter. Your scoring should weight claim volume by category resale value, not just by dollar amount.
Payment method correlation. Prepaid cards and, increasingly, BNPL-financed orders have elevated INR rates. The logic is straightforward: a prepaid card has no ongoing relationship between the payment instrument and the customer, and BNPL separates the refund from the original payment in ways that reduce the friction of filing a false claim.
Why most stores don't separate INR from return fraud in their numbers
Pull the last twelve months of refunds issued at a typical Shopify store. Categorize them by the refund reason your team entered. You'll find most of the INR-category refunds sit under reasons like "customer did not receive," "lost in shipping," or the generic "other" bucket.
In the finance system, these roll up into "refunds" alongside actual return refunds. In the fraud tool, they don't show up at all, because there was no return record to score. The loss is real (it shows up as a P&L line) but it's been invisibly mixed into the return-fraud category, and as a result it looks like the fraud tool is performing worse than it is.
The first step for shipping-heavy merchants is to break the ledger apart. Count INR refunds as their own category. Measure them as a percentage of shipped orders, not as a percentage of returns. A 0.8% INR-refund rate is healthy. A 2.5% rate means you have a specific problem that a return-fraud tool isn't solving, and mixing them together means you can't tell.
What the detection model needs to do differently
A scoring model built for returns runs on the return webhook. It sees the return request, pulls the customer's history, and fires signals. An INR-aware model needs different entry points.
Trigger on the claim, not the refund. The moment a customer reports a missing package, typically via a support ticket, is the first point the model has enough information to score. If you're using a helpdesk that can tag tickets by category (most can), an INR tag should trigger a scoring pass on that customer and order before anyone on the team decides how to respond.
Score on the delivery telemetry, not just the order. The model should pull the carrier's detailed event log for the shipment in question. Multiple delivery attempts, address changes, forwarded packages, and out-for-delivery-to-delivered gaps are all informative.
Maintain per-customer claim history across both return refunds and INR refunds. If a customer's pattern is "one return every 3 months and one INR claim every 6 months," the return-fraud side looks quiet but the INR side is telling you something. Most tools track these in separate tables that never get joined.
RefundSentry's spec 056 handles INR signals inside the same scoring pipeline as return signals: the customer's repeat not-received claims, repeat claims at the same address, and claims on parcels that tracking shows as delivered all feed the same risk score. The output is a single customer-level view that doesn't artificially split by claim type, which is how the fraud actually behaves in the wild.
The operational playbook
Once you're measuring INR fraud as a distinct category, the response playbook is different from return fraud too.
For low-risk INR claims, approve and refund, and consider the carrier-claim question separately (it's a different post, but the short version: you are often leaving carrier insurance money on the table). The vast majority of INR claims are legitimate and need to be handled fast, because slow INR resolution is a top driver of chargebacks in shipping-heavy verticals.
For medium-risk INR claims, require additional evidence before refunding. Ask for confirmation that the customer checked with neighbors and building management. File a carrier trace. Wait 3-5 days before issuing the refund to see if the package turns up. Most fraudulent claims give up at this point because the friction isn't worth the fight.
For high-risk INR claims (repeat claimants, addresses on your watchlist, high-ticket electronics), require a police report, decline the claim, and be prepared to defend a chargeback. The evidence bundle for chargeback representment on an INR dispute is specific and defensible if you have delivery telemetry with photos or signatures. Win rates above 60% are achievable against INR representments with the right packet.
The takeaway
INR fraud isn't a subtype of return fraud. It lives on different signals, triggers on different events, and needs different detection logic. Most Shopify merchants lump the losses together, watch their refund line item climb, and blame "rising fraud" without ever breaking out which bucket is actually responsible.
If you're running a shipping-heavy store and your refund rate is creeping up faster than your return rate, split the categories. Count INR claims separately. Measure the claim-to-order ratio per customer. Pull the delivery telemetry before the refund decision, not after the chargeback arrives. The detection stack for INR fraud exists. It just doesn't live in the same tooling most stores have deployed for returns.