Portreeve
explainer · 7 Sept 202610 min read

Return fraud: why the same person returns as a new account

Return fraud is an identity problem dressed as a policy problem. How wardrobing, empty-box claims and serial returners work, and how to link the repeaters.

Your return rate climbed, your margin fell, and when you pull the orders you find the same shape four times: one first name spelled three ways, four email addresses, two shipping addresses that differ by an apartment number, every order refunded. Return fraud reads as a policy failure from the finance side, so the instinct is to rewrite the policy. Policy is the wrong layer. Every control you have is keyed to an account, and the method of the person costing you money is to stop being that account.

Wardrobing, empty boxes, and the gap each one exploits

Wardrobing is buying an item, using it once, and returning it. It works because the item stays resalable-looking until someone inspects it, and inspection happens at the warehouse days after the refund is issued.

Most stores refund on the carrier's return scan, because making the customer wait for inspection is the fastest way to a support ticket and a chargeback. So the money leaves before anyone opens the box. The dress goes back with deodorant on the lining and gets graded a week later, by which point the refund has settled.

Empty box and wrong item are the same timing gap pushed one step further. The return scan says a parcel came back. It does not say what was in it. If your reverse logistics reconcile on scan rather than on weight or SKU, an empty jiffy bag is worth exactly as much as the headphones.

Item not received exploits an asymmetry you did not choose. Stripe's own prevention guidance for the product_not_received category is to "save shipping labels, and for high-value products consider requiring a signature upon receipt", which tells you how much an unsigned delivery scan is worth when you fight the dispute.

A delivery scan without a signature is weak evidence in your favour. A return scan is treated as strong evidence in the customer's favour. Both are the same kind of data from the same carrier, read in whichever direction costs you money. This is the return-side cousin of the pattern in friendly fraud, and the same person often runs both.

Bracketing is ordering the same jacket in three sizes and keeping one. It is not fraud. It is how people buy clothes online now, you priced it in when you offered free returns, and a customer who brackets every order and keeps a third of it may still be one of your better accounts. Bracketing turns into a problem when it stops being about fit: same SKU, three sizes, all three returned, four weeks running, four different emails.

Serial returners and the customer who just returns a lot

Merchandise returns ran 13.21% of US retail sales in 2024, and Appriss Retail's annual research put 15.14% of those returns in the fraudulent bucket. That leaves roughly six in seven returns as people returning things because clothes fit badly and screens look different in person.

A high personal return rate is a terrible signal on its own. The person who returns 40% of what they buy might be an abuser, or might be a size 12 who orders 10 and 12 every time and spends $4,000 a year with you.

Amazon has enforced on volume anyway, and the reporting on it is instructive. The Wall Street Journal found in 2018 that Amazon closes accounts over return activity, in some cases without warning and over a handful of returns, including a customer who said he had returned a computer drive that year and four items the year before. If a company with Amazon's data bans that customer, a rules table keyed on return count in your admin panel will do worse.

The signal is repetition across identities.

The account reset

Look at what your existing controls are attached to.

Per-account return caps: attached to the account. Store credit instead of refund after N returns: attached to the account. A customer blocklist: attached to an email, or an email and an address. Every one of them resets for the cost of one Gmail address and thirty seconds.

Merchants describe the result plainly in public. On the Shopify community forums, jodiabaazar lists the shapes their store sees, including "Returning Used or Emptied Products," customers who "falsely report missing deliveries to get a refund while keeping the product," and repeatedly using first-time buyer or referral discounts with different accounts.

Two things usually do not reset, because the abuser needs them to work.

The money has to land somewhere they control, so the card tends to persist. And the ordering happens on the same laptop or phone, because buying from a fresh device every time is real effort for a $180 refund. Everything cheap to change gets changed. The two expensive things stay.

Tightening the policy is a margin cut on your best customers

The standard advice when returns spike is to shorten the return window, add a restocking fee, and tag more inventory final sale. Shopify exposes all three in its return rules, down to the restocking percentage and final-sale exceptions by product or collection. They are the right tools for some categories. They are close to useless against the people you are angry at.

Shorten the window from 30 days to 14, and the wardrober does not notice. They wore the dress to the wedding on Saturday and shipped it back on Monday. Every wardrobing return is inside every window, because the whole scheme depends on the item still looking new.

What a 14-day window catches is the customer who was travelling for work, plus the one whose partner had the parcel and forgot to mention it. You have taxed the honest majority and left the target untouched.

A restocking fee has the same shape with an extra cost: it converts returns into disputes. A shopper who expected a full refund and got 85% of one has a live grievance and a card issuer who will listen, and Stripe's product_unacceptable bucket is right there.

Blocking the shipping address is the one that looks smartest and ages worst. Addresses are shared by households, roommates, apartment buildings with one street number, university halls, offices, parcel lockers, and package forwarders. Block on address alone and you will eventually decline the sister of the person who defrauded you, at Christmas, and hear about it. An address tells you where the parcel went. Plenty of people share one.

Return fraud detection is a question of which keys you trust

The move is to make history follow the human being across whatever account they are wearing this week. That means grading your keys by how hard they are to change.

Hard keys cost the abuser something to rotate. The card fingerprint is the strongest one you get for free: Stripe returns a stable fingerprint on the card object that is the same for the same card number within your account, so a "new customer" paying with the card from three refunded orders is not a new customer, and you never see or store the PAN to use it.

A device fingerprint is the second, because the browser signature stays put across cleared cookies and new email addresses, which is what device fingerprinting is for. Phone number is third, when you collect it, because a real number costs real money to churn.

Soft keys inform a decision and must never create a link by themselves. IP is the obvious one. Carrier-grade NAT, corporate egress, university networks, and every VPN mean an IP address groups strangers together all day long.

A normalized shipping address is soft for the same reason, with a twist: it is a strong confirmer and a weak linker. Same address plus same card fingerprint is a person. Same address plus nothing else is a building.

The rule that keeps this safe is to require two independent hard keys before you treat two accounts as the same person, and to treat one hard key plus one soft key as worth a look rather than a conviction. Under that rule, the fourth new customer with the first customer's card and the first customer's device inherits three refunded orders' worth of history at the moment they check out.

Decide at checkout, not at the returns desk

At the returns desk you have already shipped the goods, paid the outbound label, and in most flows already refunded. Your options there are all bad and all retroactive.

At checkout you still have every option, and most of them are not "decline." Ship it with signature required. Ship it and flag the order so the return gets weighed and inspected before the refund clears. Hold the order for an hour and let a human look. Cap the order at one size per SKU. Offer store credit rather than a card refund for that specific order.

All of those cost the abuser their economics and cost an honest shopper a mild inconvenience at worst, which is the trade you want when you are wrong.

Portreeve is the abuse firewall I built for this decision. One call at checkout_attempt returns allow, review, or block with reason codes in under 100 ms, and the identity graph links accounts across hashed keys (email, device fingerprint, card fingerprint, phone), so confirmed abuse on one account marks the whole linked cluster while IP stays a soft signal that never links accounts on its own. A review never blocks the shopper: the order goes through, the event lands in a queue in the dashboard, and a later deny reaches your server on a signed webhook, which is what makes it safe to flag aggressively. You write the outcome back as confirmed_abuse, false_positive, or chargeback on the event, the free tier is 1,000 screened events a month with no card, and the handling verdicts guide and reason codes reference cover what to do with each verdict.

Close the loop, and be careful who you convict

A cluster is only as good as the outcomes you write back to it.

When the warehouse opens the jiffy bag and finds a phone charger where the phone should be, that is a fact about the person, and it belongs on the cluster within the hour rather than in a Slack thread. Reason codes are how you audit what the decision was based on afterwards, which matters the first time a customer emails to ask why their order was held. The principle holds whatever you use, including a Postgres table you write yourself.

Then build the escape hatch before you need it. Two rules do most of the work.

Never convict on a shared-resource key alone. A household shares an address, a family shares a card, a couple shares a laptop. The teenager returning trainers is not the parent who ran an empty-box claim in March, and a system that cannot tell them apart will cost you both.

Keep the harshest outcome for cases where you have a confirmed result rather than a suspicion. Everything below that threshold should route to review, which is reversible, rather than to a decline, which is not. False positives in returns are unusually expensive, because the person you just refused is by construction someone who buys enough to have a return history.

If you want to see what this looks like on your own traffic, start on the free tier and screen your checkouts for a month before you change a single line of your return policy. No card required.

← Back to all posts