Redo vs. Route: Which Package Protection Model Wins?
Self-insuring beats both apps for mid-market stores past roughly 5,000 orders a month. A cart-transform Function charges your own protection fee, and the spread over 1–2% loss rates stays on your P&L (illustrative math). Between the apps, Redo wins when a returns portal should ride the same shopper-paid fee; Route wins for insurer backing and zero claims ops. Under 2,000 orders a month, charge nothing and reorder on goodwill.
Your profile — see how the verdict shifts
- Confidence
- Medium — The self-insure math rests on the 1–2% illustrative loss-rate envelope and your claims-ops capacity; both apps' model economics are illustrative, and a real underwriting need flips the verdict to Route
- Reference scenario
- $20M–$100M GMV · 5,000+ orders/mo · standard-value shipments · CX team in place
- As of
- August 2026
Decision at a Glance
| Your profile | Verdict | Why |
|---|---|---|
| Under 2,000 orders a month | WAIT | Charge nothing and reorder lost packages on goodwill as policy: claims volume is too small to fund a pool or justify per-order fees (illustrative threshold from the parent decision). |
| 2,000–5,000 orders a month, lean CX team | BUY | An app earns it here: vendor-run claims ops cost less than staffing a pool and workflow at this volume. Redo when the returns portal rides along, Route for insurer backing. |
| Past roughly 5,000 orders a month | BUILD | Self-insure: a cart-transform Function charges your own fee, claims pay from the pool, and the spread over 1–2% loss rates stays on your P&L (illustrative math). |
| High-value shipments (real underwriting need) | BUY | Route here: genuine insurer backing matters when single claims are large enough to hurt, which is exactly what a self-funded pool handles worst. |
What Redo vs. Route Actually Drives
| Outcome | Impact | How it works |
|---|---|---|
| Revenue — direct | Medium | Protection fees are collected revenue in the self-insured lane, and the spread over 1–2% loss rates lands on your P&L as margin (illustrative math). |
| Customer experience | High | A lost package handled fast is a loyalty moment and a denied claim is a churn letter; whoever runs claims owns that moment — you self-insured, the vendor on the app path. |
| Operational efficiency | Medium | Auto-reorder rules and goodwill thresholds decide whether claims are a workflow or a weekly firefight for the CX team, and that labor is the build lane's real recurring cost. |
| Data & insight | Medium | Loss rates by carrier, lane, and SKU are negotiating leverage with carriers and 3PLs; the lane you pick decides whether that ledger accrues to you or to a vendor's actuaries. |
Spend ceiling: Cap protection spend at the spread: fees collected minus claims paid at 1–2% loss rates is the whole economic pie (illustrative math). Any lane that hands most of that pie to a vendor should be buying real underwriting or real ops relief with it.
What buying enables (top apps)
- + Protection live in days with a proven checkout toggle and claims portal
- + Zero claims ops — the vendor absorbs tickets, disputes, and resolution labor
- + Real insurer backing on the Route path for shipments a self-funded pool shouldn't hold
- + On Redo's path, a returns portal funded by the same shopper-paid fee
What building additionally unlocks
- + The fee-minus-claims spread retained on your P&L instead of a vendor's (illustrative math)
- + A claims policy that is exactly your brand promise — auto-reorder rules and goodwill thresholds, no third-party denials
- + Loss-rate data by carrier and lane as owned negotiating leverage
- + A checkout with no injected protection widget — the Function runs server-side
Find Your Verdict in 3 Questions
Are you under roughly 2,000 orders a month?
Yes: Your verdict: WAIT — charge nothing and reorder lost packages on goodwill as policy; the volume can't fund a pool or justify per-order fees yet.
No: Go to question 2.
Can your CX team run claims — tickets, judgment calls, reorders — every week?
Yes: Your verdict: BUILD — self-insure with a cart-transform Function and pool ledger; past roughly 5,000 orders a month the retained spread outruns both apps (illustrative math).
No: Go to question 3.
Should the shopper-paid fee also fund a returns portal?
Yes: Your verdict: BUY — Redo; one per-order fee funds protection and returns together.
No: Your verdict: BUY — Route; insurer backing and vendor-run claims with zero ops load.
The TCC Scorecard — 12 Dimensions
TCC — Total Cost of Capability: what it actually costs to have this capability over three years, whichever way you get it. Each dimension is scored 0–5 for both paths. How we score →
| Dimension | Buy | Build | Why |
|---|---|---|---|
| Cost | |||
| Acquisition & implementation | Either app is live in days with a checkout widget; the self-insured Function, pool ledger, and claims workflow run $10,000–$25,000 to build (Deploi estimate, illustrative). | ||
| Recurring fees | Shoppers fund the fees in every lane; the difference is who keeps the spread over claims — the vendor keeps it on the app path, your P&L keeps it self-insured (illustrative model). | ||
| Maintenance & upgrades | Vendors run the widget, claims portal, and carrier disputes for you; the self-insured lane carries ~15–20% of build cost per year (Deploi estimate) plus claims-rule tuning. | ||
| Switching & exit | Protection accumulates little data worth migrating, so app exits are cheap by category standards; in-flight claims and shopper expectations are the only real snags, and the build lane has nothing to exit. | ||
| Risk | |||
| Vendor risk | Redo couples protection to its returns product, and shopper-funded models reprice as vendor economics move. Self-insurance has no vendor to lose. | ||
| Security & compliance surface | Claims put addresses and order details in a vendor's cloud, a modest surface by category standards; self-insured claims stay inside your helpdesk with no new processor added. | ||
| Platform-deprecation exposure | Checkout is the exposed surface: app widgets ride third-party checkout rules that keep tightening, while a cart-transform Function is a first-class Shopify primitive. | ||
| Value | |||
| Fit to requirement | Apps ship a proven toggle, claims portal, and resolution flows; the build lane matches your exact policy — auto-reorder rules, goodwill thresholds — with no vendor terms in between. | ||
| Time to market | Days for an app; 4–8 weeks for the Function, ledger, and claims workflow (Deploi estimate, illustrative). | ||
| Performance & scale | A protection widget is one more injected script in the most conversion-sensitive surface on the store; the Function runs server-side inside checkout with nothing extra to load. | ||
| Data ownership & AI-readiness | Loss rates by carrier, lane, and SKU are negotiating leverage with carriers and 3PLs; self-insured, that ledger is yours, while on the app path it becomes the vendor's actuarial asset. | ||
| Focus & opportunity cost | Claims ops lands on your CX team in the build lane — real tickets and judgment calls every week. Zero claims ops is the honest thing the apps sell. | ||
The App Landscape
| App | Status | Pricing | Best for |
|---|---|---|---|
| Redo | Live — Newer entrant pairing returns with checkout-funded coverage | Shopper-funded coverage model rather than flat SaaS | Stores that want returns and protection on one shopper-funded line |
| Route | Live — The insurer-backed category's best-known name: customer-paid toggle, claims portal, and a claims desk you never staff | Customer-funded per-order fees in a $1–$5 band, revenue-share economics (illustrative) | Zero claims ops and real underwriting on high-value shipments |
| Self-insured reorders (no-app lane) | Build lane — The lane head-to-heads hide: a cart-transform Function charges your fee, claims pay from the pool, and the spread stays on your P&L, per the parent shipping-protection decision | $10,000–$25,000 build (Deploi estimate, illustrative) | Stores past roughly 5,000 orders a month with a CX team that can run claims |
The Build Path
- Cart-transform Function + checkout toggle: A first-class Shopify Function adds your protection fee as an opt-in line at checkout — no injected widget, no third-party script in the conversion path.
- Claims workflow in your helpdesk: Claims become tagged tickets with auto-reorder rules and goodwill thresholds; your team resolves on your policy, not a vendor's terms.
- The pool ledger: Fees collected minus claims paid, tracked by carrier and lane — the loss-rate dataset that becomes carrier-negotiation leverage.
- Effort band
- $10,000–$25,000 build (Deploi estimate, illustrative) — lands in the $10–25K contact-form band; claims-automation depth pushes toward $25–75K
- Typical timeline
- 4–8 weeks for the Function, ledger, and claims workflow (Deploi estimate, illustrative); the apps are live in days
- Maintenance, honestly
- ~15–20% of build cost per year (Deploi estimate): checkout API version bumps, claims-rule tuning, and ledger reporting. No per-order fees to anyone.
- What you own — and what you take on
- You own: the fee, the spread, the claims policy, and loss-rate data by carrier and lane. You take on: weekly claims ops in your helpdesk and the catastrophic-loss tail a real insurer would otherwise hold.
3-Year Total Cost of Capability
| Buy (app path) | Build (custom path) | |
|---|---|---|
| Year 0 (setup) | $0–$1,500 (setup; shoppers fund the fees) | $10,000–$25,000 (Function + ledger + claims workflow) |
| Years 1–3 (recurring) | $0 software — the vendor keeps the fee-minus-claims spread | $4,500–$11,250 upkeep — your P&L keeps the spread |
| 3-year total | ≈$0–$1,500 software, plus the forgone spread | ≈$14,500–$36,250, offset by the spread retained |
- † All figures illustrative samples for the reference scenario — not quotes, not verified pricing.
- † Redo column (the winning app path when you buy): shopper-funded per-order fees at mid-market volume, with the vendor keeping the spread between fees and claims (illustrative).
- † Build column: a self-insured Function charging the same fee level, claims paid from the pool at 1–2% loss rates; three-year horizon.
What the Sticker Price Hides
On the buy path
- — The spread is invisible rent: fees minus claims stays with the vendor, and it grows with your volume (illustrative model)
- — Claims denials and slow resolutions damage your brand, not the vendor's — read the SLA before the logo goes at checkout
- — Checkout widgets ride third-party checkout rules; a platform tightening can force rework on the vendor's schedule
- — Bundled models couple two products — repricing or sunsetting one side reprices the other
On the build path
- — Claims ops is the hidden payroll line: real tickets and judgment calls every week, priced into the parent decision's threshold
- — The catastrophic-loss tail stays yours — a stolen pallet of high-value goods is what insurer backing is actually for
- — ~15–20% of build cost per year in upkeep (Deploi estimate)
- — Goodwill-reorder policy creep: without thresholds, the pool leaks into customer-service generosity
What Merchants Say
Shoppers push back on paid protection at checkout — the recurring theme is being asked to pay extra for delivery the store already promised, and the pushback lands on the brand, not the vendor.
Claims friction is the 1–2★ pattern on protection apps: denied or slow claims read as the merchant's failure even when a vendor runs the whole process.
If You Change Your Mind Later
If you bought and outgrow it
App exits are cheap by category standards: little accumulated data and no migration tax — turn the widget off, resolve in-flight claims, and checkout is clean within a week. The real exit question is shopper expectations: customers who paid for protection yesterday expect a policy answer tomorrow, so publish the replacement policy before removing the fee.
If you built and want out
Nothing is stranded: the Function, ledger, and claims playbook are yours, and retreating to an app later is a configuration change plus a policy note. The pool's loss-rate history keeps paying either way — it negotiates carrier rates and prices any future vendor's fee honestly.
When This Answer Changes
We're watching for:
- ▸ Order volume crossing roughly 5,000 a month — the parent decision's self-insure line (illustrative threshold)
- ▸ Checkout rules tightening on third-party widgets while Functions stay first-class
- ▸ Loss rates drifting above the 1–2% envelope — a carrier problem before it's a protection problem
Verdict change log:
No changes since first publication (August 2026).
Common Questions
Is Redo or Route better for shipping protection on Shopify?
Redo wins the app path when a returns portal should ride the same shopper-paid fee — two jobs funded on one per-order line. Route wins for insurer backing and zero claims ops, the honest reasons to buy. Past roughly 5,000 orders a month, self-insuring beats both: your fee, your pool, and the spread over 1–2% loss rates stays with you.
What is the difference between Redo's and Route's models?
Route sells insurer-backed package protection: shoppers pay premiums per order, and the vendor underwrites and resolves claims (model varies). Redo bundles a returns portal into the same shopper-paid fee, so one line funds two jobs. Neither charges the merchant a classic subscription. The structure underneath is identical: shoppers fund a pool, and the vendor keeps the spread over 1–2% loss rates.
How does self-insured shipping protection work on Shopify?
Self-insurance charges your own protection fee through a cart-transform Function at checkout, pays claims from the collected pool, and keeps the spread over 1–2% typical loss rates on your P&L (illustrative math). The build runs $10,000–$25,000 (Deploi estimate, illustrative) and needs a CX team willing to run claims. Past roughly 5,000 orders a month, the retained spread outruns both apps' economics.
Your Next Steps
If you're going with BUILD(matches your selected profile)
- Pull six months of lost and damaged claims; compute your true loss rate against the 1–2% envelope
- Scope the cart-transform Function, the opt-in default, and a fee level benchmarked against current app fees
- Stand up the claims workflow in your helpdesk with auto-reorder rules and goodwill thresholds
- Track the pool ledger monthly by carrier and lane; that data is carrier-negotiation leverage
- Set the catastrophic-loss line above which you still buy real insurance
If you're going with BUY
- Choose the model first: bundled returns (Redo) or insurer backing (Route) — verify terms
- A/B the protection widget's checkout impact before rolling it to the whole store
- Read the claims-denial terms and resolution SLA; denied claims land on your brand, not the vendor's
- Diary a re-decision at 5,000 orders a month — the self-insure math takes over (illustrative threshold)
Official Docs & Sources
- Checkout UI extensions — shopify.dev
- About product bundles — shopify.dev
Official documentation linked for verification — our verdicts and estimates are our own.
Related Decisions
Should You Build or Buy Shipping Protection on Shopify?
Shipping protection is a self-insure build for most mid-market Shopify stores past roughly 5,000 orders a month.
Should You Build or Buy a Shipping Rules Engine on Shopify?
A shipping rules engine is a buy for most mid-market Shopify stores; build a custom carrier-service engine when mispriced rates become a measurable margin leak.
Should You Build or Buy Your 3PL Integration on Shopify?
3PL integration is a buy when your 3PL maintains a real Shopify connector; build custom Fulfillment-API middleware when the warehouse is bespoke or EDI-only.
Should You Build or Buy a Branded Tracking Page on Shopify?
Branded order-tracking pages are a build once orders clear roughly 5,000 a month.
Should You Build or Buy a Returns Portal on Shopify?
A returns portal splits by return economics: WAIT on native for simple flows, BUY exchange-first in the mid-market, BUILD at 3PL scale.
Ready to keep the protection spread?
We'll compute your real loss rate, model Redo's and Route's economics against a self-insured Function, and tell you honestly which side of 5,000 orders a month you're on.
Contact us todayVerdict scored for the reference scenario above. Estimates are not quotes; both apps' model economics are illustrative verified, and the 1–2% loss-rate envelope is illustrative. The parent shipping-protection-insurance page settles the lane choice; this page decides the named head-to-head plus the self-insured lane it hides. Full scoring anchors: see the TCC methodology.
Read how we score these decisions (the TCC Framework). No affiliate links, no paid placement — no app vendor pays to appear here.