If you have looked at return apps on the Shopify App Store, you have seen a lot of portals. Self-serve return start pages, prepaid label generation, drop-off network integrations, branded tracking pages; all genuinely useful, and all solving the same problem: making it easier and faster to process a return once a customer has already decided they want one.

None of that decides whether the return should have been a refund in the first place. That is a different question, and it is the one this post is about.

What we found scanning the category

We looked at the ten most significant apps in Shopify's Returns and Exchanges category: Loop Returns, AfterShip Returns, ReturnGO, Redo, Narvar, Happy Returns, Parcel Panel, Rich Returns, PostCo, and Return Prime. Every single one of them sells portal automation: labels, exchanges, store credit, tracking, in some combination. Not one of them sells a decision layer (something that looks at an incoming return and recommends which of exchange, store credit, refund, SKU fix, or manual review actually fits that case, before the money moves). Against a category of roughly 122 apps and a base of hundreds of thousands of Shopify stores doing meaningful order volume, that is a real, unoccupied wedge, not a marketing claim.

It also tells you something useful about where the category is heading. Redo gives its core return portal away for free at a $1.25B valuation: the portal layer itself is being commoditized. That is good news if you are choosing a portal on price, and it is exactly why "which returns should convert instead of refund" is the more durable problem to solve, not the label-printing part.

Portal-agnostic means no rip-and-replace

The practical consequence of that scan is a design decision: a decision layer should sit beside whatever return process you already run, not replace it. If you run Loop, Redo, AfterShip, or nothing formal at all, the question "should this specific return become an exchange, store credit, refund, or manual review" is the same question regardless of which portal (if any) prints the label afterward.

That is the stance Opstimal Return Rescue takes, and it is worth being precise about what that does and does not mean:

  • What the decision layer does. Reads the context of an incoming return (reason code, item, order and return history) and recommends an outcome with the reasoning attached, so a human can audit the call instead of trusting a black box. It also rolls that same signal up to the SKU level, so a size or fit issue that keeps recurring on one product shows up as a fixable root cause, not just another processed return.
  • What it does not do. It does not print shipping labels, schedule courier pickups, or run a branded self-serve start page for shoppers. Those are real, separate jobs, and if you do not already have something handling them, you still need a portal (free or paid) for that part. The decision layer is not a replacement for that mechanic; it is the layer that decides which lever the mechanic should pull.

That separation is also why "rip and replace" is the wrong frame here. Adding a decision layer next to an existing portal does not touch label printing, courier integrations, or the customer-facing return start page your shoppers already use. It changes what happens to the outcome of the request (refund, exchange, credit, or a human review), not how the shipment itself gets handled.

Billing you can actually predict

Portal-agnostic decision intelligence is one gap; billing trust is another, and it is worth naming because it shows up directly in how the category is reviewed. One of the larger returns apps in the category, AfterShip Returns, carries a 4.7-star rating on the Shopify App Store but scores 2.1 out of 5 on Trustpilot, largely on complaints about surprise billing. A high app-store rating and a low independent-review score on the same product is a signal worth taking seriously if you are picking a vendor you will be billed by every month.

Return Rescue's billing runs entirely through Shopify's own billing system: four published tiers, Starter ($29/month, 50 included returns), Growth ($99/month, 200 included), Scale ($299/month, 600 included), and Enterprise ($799/month, 2,000 included), each with a flat, published per-return overage rate if you go over your included allowance, and a 14-day trial on every tier. There is no custom quote step and nothing configured after the fact; what is on the App Store listing is what you are billed.

What exchange-first actually looks like on a single return

It helps to walk through one request instead of talking about the category in the abstract. A shopper orders a jacket, and it arrives a size too small: the most common apparel return reason, and squarely inside the 20-40% apparel return-rate range covered in the companion post. Under a refund-default flow, that request goes straight to a return label and a refund, the sale is gone, and the only thing left behind is a reason code nobody looks at again until the next size-related return shows up on the same product.

Under exchange-first handling, the same request is read for context first: it is a like-for-like size swap, the item is in stock in the size the shopper needs, and there is no return-history flag on the account. That combination is exactly the case an exchange is built for: the shopper gets the size they actually wanted, the sale stays in the business instead of leaving as a refund, and the store only pays the processing cost of the swap rather than the full cost of the sale. The reason code is also logged at the SKU level, so if that same jacket keeps generating size-related returns, it shows up as a fixable sizing or size-chart issue instead of disappearing into a pile of one-off refunds.

Not every request looks like that one. A shopper returning a final-sale item with a damage claim, or an account with an unusual pattern of returns relative to its order history, should not be pushed toward the same fast exchange path; that is exactly the manual-review bucket from the companion post, and routing it there deliberately is part of the same decision layer, not a separate system.

Does this slow the return down for the shopper?

It is a fair question, and the honest answer is: for the large majority of requests, no; the decision happens automatically, in the background, before the shopper ever sees a delay. The exchange or store-credit path resolves as fast as a refund would from the shopper's side; the only case that intentionally takes longer is the small manual-review bucket, and that is specifically the set of requests where a short delay is worth avoiding a bad outcome. Trading a few seconds of automated routing for a materially different outcome on the return (kept sale versus lost sale) is the entire point of adding a decision layer in the first place.

Running the numbers before you decide anything

None of this is an argument that exchanges or store credit are always the right call: a refund is sometimes exactly correct, and no honest decision layer should claim otherwise. What it changes is whether that choice gets made deliberately, return by return, instead of defaulting to a refund every time because that is what the portal's fastest path does.

If you have not already, it is worth reading the companion piece on the underlying math, What a return actually costs a Shopify store (and the three decisions that decide it), which walks through the industry-sourced cost ranges behind all of this. And if you want to see what a shift toward exchange-first handling could mean for your own store, the return-cost calculator takes your monthly orders, average order value, return rate, and cost-per-return assumption, plus a labeled assumption for what share of returns could realistically convert, and estimates your monthly return cost, a retained-margin range at that assumption, and which plan tier fits your volume. Every figure is explicitly an estimate built from the numbers you enter, not a guarantee about what will happen at your store.