Shopify bundle returns and partial refunds

Every bundle guide on this site ends with the same QA bullet: “refund one component before you buy traffic.” Nobody explains what you should expect to see. Then the first real return lands — a customer sends back the serum from a routine kit and keeps the travel bag — and support, finance, and the warehouse each improvise a different answer. The refund is wrong by $6, the returned unit re-opens the pack for sale before anyone inspected it, and the ticket becomes a chargeback.

This post owns that job: decide, before a pack goes live, how returning one component refunds, restocks, and re-opens pack availability — and pick the allocation mode and return policy that make the outcome defensible. It is not about designing the offer (BOGO, GWP, fixed-price kits) or the allocation math itself. It is about the week after the order.

Three things happen on a pack return, not one

A solo-SKU return is one decision: refund the line, restock or not. A component return from a pack triggers three, and each can go wrong independently:

• Refund amount — what the customer gets back for one line whose price was set by a pack discount, not a sticker.
• Restock — which location the unit lands in, and whether it should count as sellable at all yet.
• Pack availability — whether that restock re-opens a unit of the pack on the storefront, because pack stock is derived from component stock.

Merchants who sell packs as a fake “Kit” SKU with one line on the order face a fourth: there is no component line to refund, so someone types a manual amount and adjusts two inventory counts by hand — and one of them is forgotten before the weekend sale. The rest of this post assumes the pack expanded into real component lines at checkout.

The refund basis is the allocated line price

Shopify refunds a line at the price that line carried on the order — the discounted amount, including any share of an order-level discount allocated to it. For a pack, that price was decided by the allocation mode you chose for merchandising reasons. So the merchandising choice is also the returns policy, whether you meant it that way or not.

Use one kit for every example below: Cleanser $30, Serum $60, Travel bag $10 — $100 at natural prices.

Free item mode (gift absorbs the discount)

Bag marked free, pack sells for $90. Order lines read $30 / $60 / $0.00. Return the serum → $60 back, and the customer keeps a bag they paid nothing for. Return only the bag → $0 refund. Return the cleanser → $30. Paid lines refund at full sticker, which customers find intuitive; the exposure is entirely on the gift.

Spread mode (proportional discount)

Fixed price $79 — a 21% saving spread by price. Lines read $23.70 / $47.40 / $7.90, and because allocation runs in integer cents with largest-remainder rounding, those lines sum to exactly $79.00 — refund all three and you return the pack price to the cent with no orphan pennies. Return only the cleanser → $23.70, not the $30 the customer remembers from the PDP. This is the mode that generates “you shorted my refund” tickets unless the order confirmation and your policy already said the kit price is allocated across items.

Order-level application (Growth and Pro)

Same $79 kit, but the discount is applied on the order so lines read $30 / $60 / $10 with a −$21 order discount — accounting and some 3PLs prefer sticker lines. When you refund one line, Shopify prorates the order discount, so the cleanser refund still lands around $23.70. The difference is visibility: the receipt showed $30 on that line, so the gap is louder. Pick order-level for the books only if support is briefed on the proration, and confirm the exact figure in your test refund rather than assuming it.

Restock location decides whether the pack re-opens

When you restock a returned component, Shopify raises that variant’s on-hand at the location you pick. Better Bundles hears that change like any other stock event — sale, restock, manual adjustment — and recalculates the pack’s availability from the minimum across its components (inventory sync docs). Two consequences merchants miss:

• Restocking one serum into a counted, sellable location can put a pack back on sale instantly — before anyone checked the seal. If the unit is damaged, you just re-sold a kit you cannot ship complete.
• Restocking into a returns or quarantine location that the pack does not count (Settings → Inventory, or the bundle’s own location override) changes nothing on the storefront until the unit is promoted to a sellable location. That is the correct behaviour — treat it as a feature, not a bug.

Decision rule: returns land in a location the pack does not count; QC moves good units to a sellable location; only that move re-opens pack availability. If you run several locations, the same logic is the “returns is neither source nor destination” rule from location roles that keep transfers legal. Single-location stores can fake it with the “Restock” toggle: leave it off at refund time, then adjust inventory after inspection.

Exchanges: a size swap is not a pack return

“Wrong size on the hoodie in the starter kit” is the most common pack ticket in apparel. Exchanging it is not one motion, because the replacement is a solo variant that carries no pack discount. Three defensible paths:

1. Like-for-like swap at the same price — refund the component at its allocated price and issue the replacement on a draft order with a manual discount to the same allocated price. Net cash movement zero; two documents.
2. Return the component, upsell nothing — refund the allocated price and let the customer buy the right size at full price. Honest, but it feels like a penalty for a fit issue; use only when the pack saving was small.
3. Return the whole pack — refund every line, restock through QC, customer re-buys the pack in the right size. Cleanest inventory, slowest for the customer.

If size exchanges on one component are frequent, that is design feedback, not a support problem: the pack probably needs a size option on the hero, which is the variant tree question. Prefer the refund flow over editing the placed order for component swaps — order edits interact with pack discounts differently, and you do not want to discover how during a live ticket.

Failure modes worth a line in the runbook

• Gift-only returns with paid return shipping — a $0.00 line has no refund value; do not buy a return label for it. Tell the customer to keep it.
• Hero returned, gift kept, policy silent — the customer did nothing wrong; you priced the gift as free and never wrote the exception. Decide now: require the gift back above a hero value, or accept it.
• Damaged unit restocked straight to sellable — pack re-opens; next kit ships short; second refund. Route returns through a non-counted location.
• Refund issued without restock, unit shelved anyway — component stock and pack availability both read low; you turn away sales you could fill. Pair every physical put-away with an inventory adjustment.

Write the pack return policy before launch

Pick the allocation mode with the refund in mind, then write the policy in plain language. Working rules we apply when reviewing pack setups:

• Use free item mode when the gift is low-cost and you are happy for “return the hero, keep the gift” to be a marketing cost. State that free items have no refund value.
• Use spread mode when every component is a real product with real COGS. State that bundle savings are allocated across items and partial returns refund the allocated price shown on the order.
• Use order-level application only when accounting or a 3PL needs sticker lines — and brief support on prorated refunds before the first order, not after.
• Require the whole pack back when the pack price only makes sense as a set (a curated gift box, a dated seasonal set). Say so on the PDP.
• For same-SKU multipacks, allow returning N-of-M units at the allocated per-unit price — equal units allocate equally, give or take a cent from rounding.

A policy paragraph most stores can adapt (check it against your jurisdiction’s consumer rules): “Bundle savings are allocated across the items in the bundle. If you return part of a bundle, we refund the discounted price shown for that item on your order. Free gift items have no refund value and can be kept. Some bundles must be returned complete; those are marked on the product page.”

The 15-minute pre-launch refund test

Do this once per allocation mode you use, on a real paid test order (a 100% discount code hides the money you are trying to check):

1. Place a paid order for the pack. Confirm the order shows every component line with its allocated price and that the lines sum to the pack price.
2. Refund one component only. Read the refund amount Shopify proposes before you confirm — it should match the allocated line, not the sticker. Write the number in the runbook.
3. On that refund, restock to your returns/quarantine location (or leave “Restock” off). Check the pack’s storefront availability did not change.
4. Move the unit to a sellable location (inventory adjustment). Check pack availability rose by the expected amount and that the reserve buffer still holds.
5. Open the refund notification the customer received. Does the wording explain why the amount is not the PDP price? Fix the template if not.
6. Repeat with the whole pack: refund every line, confirm the total equals the pack price to the cent.

If step 2 produces a number nobody on the team can explain in one sentence, change the allocation mode or the policy before you buy traffic — it is far cheaper than re-training support after the first fifty orders. Setup and preview live in Create your first bundle and the discount modes docs.

Measure return rate per pack, not per SKU

Better Bundles reports attribute units sold and discounts given from paid orders (reports docs). Put Shopify’s refund and return data for the same pack next to those numbers before you scale it. A pack with strong units and a partial-return rate double the component’s solo rate is telling you something: the wrong companion, the wrong size story, or a gift customers do not want. Fix the pack; do not fix the policy to hide it.