Shopify Bundles will silently sell at the Wrong Price! Why isn’t this automatic?

AI-generated summary

The issue is that Shopify’s native Bundles app creates a separate bundle product variant with its own fixed price, so changing a component product’s price does not automatically update any bundles that contain it. This can leave bundles selling at outdated prices unless merchants manually find and update each affected bundle.

Several replies confirmed this is documented Shopify behavior, not a bug, but agreed an optional pricing rule would be useful. Suggested rules include fixed price, sum of component prices, fixed discount, or percentage discount; others cautioned that automatic repricing should not be the default because different merchants may intend different pricing logic.

Workarounds proposed include third-party bundle apps with dynamic pricing, spreadsheet/API bulk syncs, AI-assisted updates, or a custom webhook-based job. The most relevant technical suggestion for the original need is to use Shopify’s Admin API productParents lookup on component variants after a products/update webhook, calculate the sum of current component prices, and update the parent bundle variant price.

The original poster clarified they only need straight component-price summing for stockkeeping and prefer not to pay for another app. No native Shopify solution was identified; the discussion remains open with custom automation as the closest workaround.

We are using the Shopify Bundles App and noticed that it appears to be missing a crucial pricing option.

Currently, the bundle price stays fixed even if a component products price changes. Forcing us to manually update every single bundle variant in our store which uses that component… a needlessly tedious and time consuming task. Like seriously why??

Example: a bundle is priced at €49.90. If a price of one of its components is increased by +€5, the bundle still remains €49.90. We then have to manually find and update the bundle price.

With multiple bundles, this creates lots of manual required high risk labor as if a bundle is missed in the manual updates, this bundle will be sold at a incorrect price.

A simple by me proposed solution would be a checkbox in the bundle settings:

:check_box_with_check: Automatically update bundle price based on current component prices

Shopify could then recalculate the bundle price automatically while optionally maybe even giving options to preserve the defined bundle discount % or fixed amount.

Merchants who want a fixed bundle price could simply leave this disabled. But in my opinion such a setting should have been the default behavior.

I would really appreciate it, if you could bump this post and add your opinion and ideas for this. As this is a huge issue for us and I imagine everyone using the Shopify Bundles App will run into this problem sooner or later. Thanks for your time and help. I really appreciate it ^^

I looked into this, and unfortunately you’re right. Shopify confirms that if a component product price changes, the bundle price doesn’t update automatically. Their current solution is to manually update the bundle price: Shopify Bundles documentation

Maybe Shopify will address it, but from experience, when they release apps, they tend to move on quickly and not do much updating since it’s only meant to help people starting off, and that’s were 3rd party apps come in.

If you have a lot of bundles suggest using one that supports dynamic/percentage pricing instead. Kaching Bundles is one I usually use on client stores.

Hello @Yannik_Pipek, @Michael-Thomas is right that Shopify Bundles has no live link between component price and bundle price today. If switching apps isn’t worth it for you, a lighter workaround before jumping to a different app: pull your bundle-to-component mapping into a spreadsheet with Matrixify (or the Admin API directly if you’re comfortable with that) and run a scheduled export/re-import that recalculates bundle prices off current component prices, so it’s a weekly bulk sync instead of manually hunting down every affected bundle by hand.

If this helped, please mark it a solution

Michael-Thomas is right that there is no live link, but before you commit to a scheduled full export there is a reverse lookup in the Admin API that most people miss, and it turns this from a weekly sweep into something that fires on the actual price change.

On ProductVariant there is a productParents connection, documented as the list of products that have variants containing this variant as a component. So the query you want is not bundle to components, it is component to bundles. Subscribe to products/update, take the variants that came back, ask each one for its productParents, and you have exactly the bundles affected by that one price change. No scanning the catalogue.

To seed the list the first time, the products search filter has_variant_with_components:true returns every bundle parent in the store in one pass.

Two things that will bite. The products/update webhook fires on almost any edit and not just price, so you need to keep your own last known component price and compare, otherwise you recalculate everything every time someone touches a tag. And the price you are writing sits on the parent variant, so it is a normal productVariantsBulkUpdate. The lock people hit with bundles is that only the app which assigned the components can manage the component list, which is a different thing from the parent price, but I would still point it at one throwaway bundle before letting it loose on 200 of them.

Where none of this helps is deciding what the new price should be. If your bundle is component sum minus 10 percent, it is arithmetic. If the 49.90 was chosen because it is 49.90, no automation will guess that, and the honest fix is storing the intended rule as a metafield on the bundle so the job has something to recompute from.

Are your bundle prices formula based or hand picked? That decides whether this is worth building at all.

I agree that having this as an optional pricing rule would be useful, but I wouldn’t call the current behavior an incorrect price.

The bundle is its own product with its own price. Shopify actually documents that changing the price of a component does not update the bundle price and that the bundle price has to be updated separately.

There is also no universally correct price for Shopify to automatically choose. If two products total €55 and the bundle is €49.90, then one component increases by €5, should Shopify preserve the €5.10 discount, preserve the percentage discount, or keep the promotional bundle price at €49.90? Merchants could reasonably want any of those.

Where I think your suggestion makes a lot of sense is as an optional pricing strategy:

  • Fixed bundle price

  • Sum of component prices

  • Component total minus a percentage

  • Component total minus a fixed amount

Then Shopify could recalculate automatically for merchants who specifically want component-driven pricing, while leaving existing fixed-price bundles alone.

I definitely wouldn’t make automatic repricing the default though. A component price change automatically altering potentially dozens of live product prices could create just as many problems in the opposite direction.

:blush: Hi @Yannik_Pipek,

While waiting for Shopify to add this to the native Bundles app, you can use 3rd-party bundle apps.

  • They usually support dynamic pricing. The bundle price is calculated from the current component prices, so it updates automatically when a product price changes.
  • They can do exactly what the Shopify Bundles app does & even provide more features.

2 good apps I recommend:

Hope this helps!

Hey Yannik,

I think this problem could potentially be solved using an AI agent connected to your Shopify store.

For example, using Manager For Shopify (a product which I have built), you could ask your AI:

“Find all bundles that contain this product. The product price has increased by €5, so update the affected bundle prices while maintaining their current discount percentage.”

The AI can inspect your Shopify products and bundle relationships, find all affected bundles, calculate the new prices, and update them for you through Shopify.

This would eliminate the need to manually search through every bundle and significantly reduce the risk of accidentally selling a bundle at the wrong price.

Manager For Shopify is a desktop application that lets you connect your Shopify store and use AI agents like ChatGPT or Claude to manage and make changes to your store using natural language.

You can check it out at: https://manager.vikasmaur.com

I think @Maximus3’s point is the key one: the hard part isn’t recalculating the bundle price, it’s deciding which pricing rule has authority.

Once that rule is explicit — fixed price, fixed discount, percentage discount, component sum — the downstream recalculation can be deterministic.

I’d still want to see the exact affected bundle prices before they’re written, because one component change can fan out into a much larger production change set.

The missing automation matters, but the first decision is which rule should have authority for each bundle: fixed price, fixed amount off, fixed percentage off, or a minimum contribution margin. I’d map component price changes into every parent bundle and flag the ones that fall below the margin floor; some should reprice, while others may no longer deserve to stay in the assortment. Which bundles promise a specific saving to the customer, and which are mainly sold for convenience or a complete-use case?

The failure mode I’d want to eliminate is not just “price changed,” but “which bundle prices are now stale and why.” If a component price can affect multiple bundles, I’d keep an explicit bundle pricing rule and an exception list rather than relying on someone remembering every parent product.

For example, store per bundle whether its intended rule is fixed price, component sum, fixed discount, or percentage discount. When a component changes, calculate the expected price for every affected bundle and show a before/after diff. Only the rows whose expected price differs need review or update. That gives you an audit trail and avoids silently changing bundles that were intentionally fixed at €49.90.

I’d also include effective date and last-reviewed component price, because BFCM or temporary component promotions can otherwise cause the automation to “correct” a bundle that was meant to stay stable.

About how many component-price changes do you make in a typical month, and roughly how many bundle variants can one component feed into? That would tell you whether this is an occasional checklist problem or a recurring bulk-reconciliation problem.

As Maximus3 pointed out, Shopify Bundles works this way because it creates a net-new product variant in your store with its own fixed price. Once created, that price is completely disconnected from the components.

If you want the bundle price to always reflect the live component prices, the most reliable solution is to use a bundle app that doesn’t create new variants at all. Instead, these apps group the actual component products together on the product page and apply a discount rule (like 10% off or €5 off) at checkout.

Because the customer is adding the actual components to their cart, any price change you make to a component instantly updates the bundle’s final price. There is no syncing, API webhooks, or manual updating required.

(I build a bundle app called Packmate, so I’m biased, but it works exactly this way. It shows the bundle via a theme app embed and applies the discount automatically at checkout, keeping your bundle prices perfectly in sync with your live component prices.)

Hi @Yannik_Pipek,

If you are looking for this functionality while it’s not available in Shopify Bundles, there are third-party bundle apps that support dynamic bundle pricing based on component product prices.

One option is Profit Bundles & Mystery Boxes, which can help automate bundle pricing and avoid manually updating bundle prices whenever component prices change.

Hope this helps for a workaround in the meantime!

@Maximus3 answer is correct, the shopify bundles creates a separate variant that carries a price of its own, so there’s nothing for it to recalculate from. The fix isn’t syncing that price faster, the solution is working it out at checkout from whatever the components cost right now.

That’s how NeatBundles does it. The part I think is actually useful for you is that the pricing rule listed above is just a setting on each bundle: fixed price, sum of components, sum minus a %, or sum minus a fixed amount. A Cart Transform function applies it at checkout, so a component price change shows up in the bundle on the next order with nothing to update.

With your numbers: if the components add up to €55 and you want €49.90, set it to “minus €5.10”. Bump one component by €5 and the bundle becomes €54.90 on its own, still ending in .90. If you’d rather keep the % saving, use percentage off instead, but then you lose the round number (€55 minus 10% is €49.50)

Hey, thanks for getting back to me. I know some 3rd party bundle apps can do this. But to be honest, I don’t think we should be forced to pay for a custom app here. Having correct bundle prices is fundamental. We just spend days setting up bundles which we now have to delete again to use a 3rd party or to create a custom app or integration of some sort to fix this. It’s been quite frustrating.

Personally we only need a strait forward addition of all component prices without any formula to create a discount as we use bundles for component stockkeeping.

Since you only need the sum of the component prices and no discount formula, you can keep Shopify Bundles for the stock link and skip switching apps.

When a component price changes, look up which bundles use that component (productParents on the variant), add the current component prices, and write that total onto the bundle’s parent variant. A small custom job on the products/update webhook does it. Nothing fancy to store, just “sum of components”.

That keeps the stockkeeping you already set up and stops you hunting every bundle by hand after a price change. Test it on one throwaway bundle first before letting it touch the live catalogue.