Returns: Build vs Buy, and Why Fraud and Abuse Are Not the Same Problem

Return fraud costs US retail about $14 billion a year. Return abuse costs about $86 billion^[1]. Six times bigger, almost entirely legal, and it needs the opposite solution.

Nearly every returns vendor pitches you on fraud, because fraud has villains and villains sell software. Then the product they hand you is a portal, which addresses neither. Let's separate the three problems properly and then decide what's worth building and what's worth buying.

What the primary data actually says, including the bit vendors skip

The National Retail Federation, with Happy Returns (a UPS company), put US returns at $849.9 billion in 2025, or 15.8% of sales. Online returns ran higher at an estimated 19.3% of online sales^[2].

Now the part that gets left out of every vendor deck. That's down from 2024, when returns were $890 billion at a 16.9% rate^[2]. Down in absolute dollars and down as a percentage of sales.

So if you've read that "returns are exploding," you've read vendor marketing. The primary data says returns fell. I'd have bet the other way before checking, which is a decent reminder to check.

The three-way split that changes your decision

Appriss Retail's 2026 Total Retail Loss Benchmark, built from 250 million unique customer identifiers plus a poll of over 1,000 consumers, breaks $796 billion of total retail loss down. Of $706 billion in merchandise returned in 2025, 14.2% (about $100 billion) was preventable loss from fraud and abuse. Within that, abuse accounts for 12% and outright fraud for 2%^[1].

Appriss sells the analytics that address this loss, so read the totals as directional. The ratio is the useful bit, and it's the thing nobody argues with: abuse dwarfs fraud.

Three distinct problems, then.

Fraud. Fake receipts, stolen goods, empty boxes, counterfeit swaps. Criminal. Small. NRF's own figure is that 9% of all returns are fraudulent, with 71% of retailers reporting increases in overstated quantity, 65% in empty box schemes and 64% in decoy returns^[2].

Abuse. Wardrobing, bracketing, serial returning, returning worn goods. Legal, or at least not criminal, and about 45% of consumers think "bending the truth" on a return is acceptable when they're unhappy with a purchase^[2].

Cost. The ordinary, honest returns. Most of your returns volume. Shipping, labour, inspection, restocking, markdown on anything not resaleable. This is the biggest number by far and it's the one a portal actually helps with.

Does this affect you enough to spend money?

Four numbers. Work them out before reading the vendor section, because they determine the answer entirely.

Your return rate, by category. Apparel and footwear run far above the 19.3% online average; hard goods run below it. A blended number hides everything.

Your cost per return, fully loaded. Return shipping plus labour plus inspection plus the write-down on anything that can't go back to full price. Most merchants dramatically undercount the last one.

Your exchange rate versus refund rate. This is the single number that decides whether returns software pays for itself, because a swapped exchange retains revenue and a refund doesn't.

Your resaleable percentage, and the lag. How many returned units go back to full-price saleable, and how many days does it take. Eleven days in a returns bin is eleven days of stock you can't sell but your system thinks you can. NRF's returns research is a reasonable benchmark to compare your own numbers against, particularly the generational split: Gen Z shoppers averaged 7.7 online returns in twelve months, more than any other group^[14].

If your return rate is under 8% and you process fewer than 50 returns a month, you don't need software. You need a good email template and a clear policy page. I'd say that to a vendor's face.

What we found: the pricing is priced on the wrong unit

We went through published pricing pages across the main returns platforms. One pattern dominates and it's worth naming.

Loop lists Essential from $155/month, Advanced from $272/month, and Enterprise on quote. Advanced adds Shop Now, Instant Exchange, bonus credit and fraud prevention^[3]. The included return volumes aren't stated on the page.

AfterShip Returns publishes tiers with hard return counts: Essentials at $11/month for 20 returns, Pro at $59/month for 100, Premium at $239/month for 200, with overage at roughly $0.50 to $1.00 per return^[4]. Their own help documentation sets out how the models work^[5].

Narvar publishes no pricing at all. Quote only.

Here's the finding. Every one of these prices on return volume. Which means the vendor's revenue goes up when your returns go up, and your incentive is to reduce returns.

That's not a conspiracy. It's just a misaligned unit, and it explains why the marketing emphasises exchange conversion rather than return prevention. Exchange conversion keeps volume high and makes both parties happy. Genuine return reduction shrinks the account.

The number that actually decides build vs buy

Do this calculation. Take your monthly returns, multiply by your exchange rate today, and by your average order value. That's your current retained revenue. Now assume a portal lifts exchange rate by 10 percentage points, which is an optimistic but not absurd assumption.

At 200 returns a month, £60 AOV, moving from 15% to 25% exchange, that's 20 extra exchanges, about £1,200 of retained revenue monthly. Against $155 to $272 a month for Loop^[3], that's an easy yes.

At 40 returns a month and £30 AOV, the same 10-point lift is 4 exchanges and £120. Against $59/month plus overage^[4], that's marginal and you'd be buying it for the labour saving instead, which is a legitimate reason but a different one.

The number where this flips is somewhere around 100 returns a month for most merchants. Below that, build. Above it, buy.

What "build" actually means, and what it costs you

Build doesn't mean writing a returns platform. It means the minimum viable version, which is smaller than people think.

A form that takes an order number and email, validates against your order data, and captures the reason from a fixed list. A rule that auto-approves anything inside your window on a resaleable category. A generated label from your carrier's API. A status email. And a table that records what came back, why, and in what condition.

That's genuinely a week or two of work on most stacks and it gets you 80% of the operational benefit. What it doesn't get you is exchange conversion UX, which is where the platforms earn their money, because "swap for a different size" as a one-click flow is a genuinely well-designed thing that's hard to replicate cheaply.

Where build wins outright: you're on a platform the vendors ignore, you have unusual policy logic, or your return volume can't justify the price. Where build loses: you underestimate the label generation and carrier integration, which is always the part that takes three times longer than planned.

Platform by platform

Shopify

Native returns handle the basics: initiate a return from the order, generate a label in supported regions, restock on receipt. It's real and it's free, and a lot of merchants buying a returns app never tried it.

Where native stops is exchange logic and policy rules. If you want "exchanges free, refunds cost £4, worn items rejected, orders over 30 days credit-only," that's an app. Shopify's own documentation on refunding, cancelling and returning orders is the place to check what you already have before you buy something to replace it^[15].

Every major vendor has a first-party Shopify app, and the integration depth is genuinely better here than anywhere else. That's the honest advantage of being on Shopify for this specific job.

WooCommerce

Core Woo has no returns workflow at all. Orders have statuses and refunds have an admin action, and that's the extent of it.

Which sounds bad and is actually the best case for building, because you have complete database access and no platform constraints. A returns table keyed to order ID, a front-end form, a carrier API call and a couple of scheduled jobs gets you further than most Woo merchants realise. Woo's product and stock model is documented clearly enough to restock against without guessing^[16].

The vendors do reach Woo, but usually with the shallower integration. Ask specifically whether the app can create the refund and restock the item on your Woo store, or whether it only manages the customer-facing portal and hands you a list to process manually. That distinction is worth a lot of hours a month.

Magento and Adobe Commerce

Magento is the only one of the four with a genuinely mature native returns concept. RMA (Return Merchandise Authorisation) is built in, with statuses, item conditions and a customer-facing flow. It's dated in its UX and it's structurally sound.

The Magento pattern that works: keep RMA as the system of record because your ERP and finance already read it, and layer a better customer-facing portal on top if you need one. Replacing RMA entirely usually breaks something downstream that nobody remembers exists.

Adobe's inventory model matters here too, because a return has to land in a specific source before it becomes available to sell again^[6]. Getting that mapping wrong is how stores end up selling stock that's sitting in a returns bin.

BigCommerce

Native returns exist and are basic. Integrations with the main vendors are available. The pricing consideration is the same one that affects every BigCommerce decision: plan auto-upgrades at $30,000 and $100,000 trailing-twelve-month GMV, and a 0.9% overage above $33,333/month GMV on Scale^[7]. Returns reduce GMV, which is one of the few places where a high return rate quietly helps your platform bill.

Custom and headless

You're building regardless, so the question is only how much. Start with the data model, not the UI. A return needs: order reference, line items with quantities, reason code, requested outcome, approval state, carrier tracking, received-at timestamp, condition on inspection, and disposition. Get those nine fields right and everything else is presentation.

The mistake I see most: modelling a return as a negative order. It isn't. Refunds, exchanges, partial returns and rejected returns all behave differently, and squeezing them into an order record makes the reporting useless within a year.

The returns decision table

Your situation	Build or buy	Rough cost	The reason
Under 50 returns/month	Neither. Email template and clear policy	£0	Nothing to automate yet
50–100 returns/month, low AOV	Build the minimum portal	1–2 weeks dev	Exchange lift won't cover a subscription
100+ returns/month, AOV over £50	Buy	$155–272/mo[3]	Exchange conversion pays for it quickly
Low volume but want the labour saving	Buy the cheap tier	From $11/mo for 20 returns[4]	Watch the overage rate
On Magento with an ERP	Keep native RMA, improve the front end	Dev time only	RMA is the finance system of record
On WooCommerce	Build, or check the vendor can actually write back	Varies	Portal-only integrations save no ops time
Abuse is your main loss	Policy change, not software	£0	Abuse is 6× fraud and it's a policy problem[1]

How to reduce abuse without becoming a credit bureau

This is where I'd push back on the whole category. The instinct when abuse shows up is to score individual customers and block the bad ones. That instinct carries legal exposure most merchants haven't thought about.

The Retail Equation, owned by Appriss, is listed by the Consumer Financial Protection Bureau as a consumer reporting company^[8]. That listing exists because scoring individuals and denying them service on that basis is regulated activity in the US, with dispute rights attached^[9]. In the UK and EU, automated decision-making with legal or similarly significant effects sits under GDPR Article 22 and needs its own justification.

The economics point the same way as the law. Appriss's own data shows 90% of flagged consumers purchase again after a warning^[1]. A warning keeps the customer and changes the behaviour. A block loses both.

What actually works, in order of effect

Better product data. The most common return reason in apparel is fit, and the most common cause of fit returns is a bad size guide. Fix the size guide and you reduce returns at source. Unglamorous, free, and it beats every fraud model.

Charge for refunds, keep exchanges free. The single most effective policy lever available. It shifts the outcome without denying anyone their rights.

Bracket detection at the cart, not the return. Three sizes of the same item in one basket is a bracketing order. You can nudge at that moment. Once it's shipped, you've paid the cost already.

A soft warning on the third return in ninety days. Explicit, explained, disputable. Not a silent block.

Consistent enforcement of a published policy. Inconsistency is what generates the angry emails, not strictness.

The legal floor you cannot design around

If you sell to UK or EU consumers, your returns policy has a floor set by law and no amount of policy design gets under it. Our guide to what the law actually lets you do on returns and abuse sets out exactly where that floor sits, and how much room is above it.

In the UK, the Consumer Contracts Regulations 2013 give a 14-day right to cancel a distance purchase without giving a reason, followed by a further 14 days to send the goods back, with a refund due within 14 days of you receiving the goods or the customer providing proof of return, whichever is sooner^[10]. That right is statutory and cannot be reduced by your terms. Regulation 29 puts it plainly: the consumer may cancel a distance contract at any time in the cancellation period "without giving any reason, and without incurring any liability"^[11].

Two practical consequences most stores get wrong. First, "worn items cannot be returned" is not enforceable against a cancellation inside the cooling-off period, though you can deduct for diminished value if the customer handled the goods beyond what's needed to assess them. Second, if you failed to tell the customer about the cancellation right before purchase, the window extends dramatically.

Whatever software you buy, the policy it enforces has to sit above that floor. Several returns platforms let you configure policies that would be unlawful in the UK. They will not stop you.

What agentic checkout does to returns

Two things, one obvious and one not.

The obvious one: agent-driven purchases will have a higher return rate at first, because the agent is guessing at fit and preference on the buyer's behalf. Nobody has published data on this yet, and anyone claiming a number is making it up.

The non-obvious one is discovery. Google's Universal Commerce Protocol, launched 11 January 2026 with Shopify, Etsy, Wayfair, Target and Walmart as co-developers^[12], expects machine-readable return terms as part of the transaction data. So does the Agentic Commerce Protocol maintained by OpenAI and Stripe^[13].

Which means your return window stops being a page a customer reads and becomes a structured attribute an agent compares you on. If your merchantReturnDays isn't published in structured data, an agent evaluating you against a competitor who does publish it has to treat yours as unknown. Unknown loses.

What to do this week

1. Split last quarter's returns into fraud, abuse and ordinary cost. If you can't, that's the first finding.
2. Calculate cost per return fully loaded, including the write-down on non-resaleable units. Most merchants are out by a factor of two.
3. Measure your exchange rate. It's the number that decides build vs buy.
4. Measure return-to-saleable lag in days. Then subtract that stock from your available-to-sell.
5. Read your top three return reasons and fix the product page. Size guide, dimensions, material, a photo on a real person. Cheapest returns reduction there is.
6. Check your policy against the Consumer Contracts Regulations if you sell to UK consumers^[10].
7. Publish your return window in structured data. Ten minutes, and it's becoming a comparison attribute^[12].

The takeaway

Returns fell in 2025, in dollars and as a share of sales^[2]. Abuse is six times larger than fraud and needs policy rather than detection^[1]. And the vendors selling you a fix are priced per return, which is the one unit whose reduction costs them money.

None of that means don't buy. Above about 100 returns a month with a decent order value, a good portal pays for itself on exchange conversion alone. It means buy it for the exchange UX and the labour saving, which is what it's actually good at, and stop pretending a portal solves a policy problem.

What's your exchange rate? If you don't know it, that's the whole answer for now.

Sources

1. The 2026 Total Retail Loss Benchmark Report. Appriss Retail, February 2026. 250 million unique customer identifiers. Vendor-published; Appriss sells retail loss analytics.
2. Consumers Expected to Return Nearly $850 Billion in Merchandise in 2025. National Retail Federation with Happy Returns (a UPS company), 15 October 2025.
3. Loop Returns Pricing. Loop. Accessed 22 July 2026.
4. AfterShip Returns Pricing Plans. AfterShip. Accessed 22 July 2026.
5. AfterShip Returns Pricing Models and Plans. AfterShip Help Center. Accessed 22 July 2026.
6. Inventory Management introduction. Adobe Commerce documentation. Accessed 22 July 2026.
7. BigCommerce Pricing. BigCommerce. Accessed 22 July 2026.
8. The Retail Equation. Consumer Financial Protection Bureau, list of consumer reporting companies. Accessed 22 July 2026.
9. List of Consumer Reporting Companies. Consumer Financial Protection Bureau, 2025 edition (PDF).
10. Accepting returns and giving refunds: the law. GOV.UK. Accessed 22 July 2026.
11. The Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013, regulation 29. legislation.gov.uk.
12. Under the Hood: Universal Commerce Protocol (UCP). Google Developers Blog, January 2026.
13. Agentic Commerce Protocol specification. Maintained by OpenAI and Stripe. Spec version 2026-04-17.
14. 2025 Retail Returns Landscape. National Retail Federation. Accessed 22 July 2026.
15. Refunding, canceling, and returning orders. Shopify Help Center. Accessed 22 July 2026.
16. Managing Products. WooCommerce documentation. Accessed 22 July 2026.