Split shipping: is there any way to avoid summing the same flat rate twice? (warehouse + temporary pop-up location)

Payments + Shipping & Fulfilment
1

Hi everyone,

I’m setting this up for a client and I’m fairly sure I’m missing something, so I’d rather ask before I build a workaround I’ll regret.

Context

The store (not Plus — standard plan) normally ships everything from a single 3PL warehouse: home delivery €10, express €20. Once a year they open a physical pop-up store in Paris for a few weeks, and during that period they’d like to offer, on the pop-up’s selection only: click & collect (free) and a 2h bike courier within Paris (€5).

So: two locations. Warehouse = home/express. Pop-up = pickup + courier. Some products are in stock at both, some at only one.

Because the store is live with a lot of daily orders, I built this on two test products with two custom shipping profiles scoped to those products only, and turned split shipping on.

What happens at checkout

The order is split into two shipments and I get the “More shipping options” modal, which is actually good — the customer can pick a method per shipment.

image
image1301×1092 91.2 KB

But if the customer picks home delivery for both shipments, they’re charged €10 + €10 = €20 — even in the case where both items could physically have left the same warehouse in one box.

What I think I understand (please correct me)

From the docs, rates are combined per shipping profile / location group, and the single-flat-rate consolidation only applies within the same location group. If that’s right, then two profiles always means summed rates, regardless of which location actually fulfills.

Which leaves me with what feels like a forced trade-off:

  • One profile, one location group with both locations → single rate, no summing, but click & collect and the Paris courier get offered on warehouse-only items too, which is operationally impossible.
  • Separate profiles / location groups → correct eligibility per location, but rates always summed.

Is that reading correct, or is there a third configuration I haven’t thought of?

My actual questions

  1. Has anyone genuinely solved this natively? Any combination of fulfillable inventory settings, fulfillment priority, or location grouping that keeps per-location eligibility without summing?
  2. For those who went the app route (ShipMagic, Bespoke Shipping, ShipZip and others come up in older threads) — does any of them actually work with split shipping enabled, on a non-Plus plan, without Carrier Calculated Shipping? Most threads I found predate split shipping, so I don’t know if the workarounds still hold.
  3. I came across market-driven shipping and its rate consolidation, which looks like it addresses the summing directly: Feature preview for market-driven shipping — the documented example (“highest matching rate instead of adding”) seems to cover my home-delivery case. What I can’t tell from the docs is whether location conditions also control availability of an option, i.e. whether a “Click & Collect” option restricted to the pop-up location would stay hidden for items routed from the warehouse. Has anyone tested this in the feature preview? And is the October rollout something a live merchant can realistically opt into on a given date, or is it cohort-based?

Happy to share more of the config if useful. Thanks a lot.

Best regards,

Max COSTA

2

Hi Max, your reading is correct. On a non-Plus plan, rates combine (sum) across separate profiles/location groups, and single-rate consolidation only happens within one group. So the trade-off you described is real today: one group gives you consolidation but wrong eligibility, separate groups give you correct eligibility but summed rates. There isn’t a native fulfillment-priority or inventory trick that keeps per-location eligibility AND avoids summing at the same time.

A few concrete options:

  1. Market-driven shipping (the feature preview you found) is the right lever for the summing problem. Its “use the highest matching rate instead of adding them” behavior directly solves your home+home = EUR20 case. On availability: location/market conditions govern whether a rate shows, so a Click & Collect rate scoped to the pop-up should stay hidden for warehouse-routed items, but I’d strongly recommend confirming this yourself in the preview with your exact two-product test before relying on it. Rollouts like this are typically cohort-based rather than a fixed opt-in date, so don’t promise the client a specific go-live day.
  2. App route: the ones you listed (ShipMagic, Bespoke Shipping, ShipZip) generally rely on Carrier Calculated Shipping to override/merge rates. On the standard plan you don’t have CCS unless you pay the annual-billing upgrade or add it, so verify the plan requirement first. Behaviour with split shipping enabled varies, so ask each vendor directly whether they consolidate correctly per-shipment under split shipping today, not in a pre-split-shipping thread.
  3. Pragmatic workaround given the pop-up is only a few weeks/year: keep it simple and avoid the config risk. Offer pickup + Paris courier as free/low flat rates and accept the occasional double home-delivery charge, or absorb it with a shipping discount script/automatic discount during the pop-up window. For a few weeks of the year, the engineering risk of a complex rate setup on a high-volume live store often isn’t worth it.

If it were my client, I’d test market-driven shipping in the preview now on the two test products, and have the flat-rate-plus-discount fallback ready in case the rollout doesn’t reach the store in time for the pop-up. Happy to compare notes if you run the preview test.

3

Hey @MaxCosta ,

Your reading of the current delivery profile behavior is largely correct. With the existing product driven setup, splitting products across different profiles/location groups can result in the applicable rates being added, which makes your “€10 + €10” example difficult to avoid while also keeping the location-specific options restricted.

The new market driven shipping model does look much closer to the setup you’re trying to achieve. Shopify specifically supports both product conditions and location conditions within a shipping option. That means, in principle, you could have the Paris Click & Collect / 2h Courier rate restricted to the pop up location, while the warehouse uses the standard home/express rates.

It also addresses the rate combination issue: when multiple matching rates exist within the same shipping option, Shopify can apply the highest matching rate rather than simply adding them together.

The catch is that market driven shipping is currently still in feature preview. Shopify says merchant rollout begins October 1, 2026, with existing merchants able to opt in manually, while the feature preview itself is available on development stores for testing.

So I wouldn’t build a permanent workaround around it yet, but I would definitely test your exact two location setup in the feature preview. Your Click & Collect/location restriction scenario is actually a very good test case for the new model.

If you find my response helpful, please feel free to mark it as the solution.

Thank You !

4

Yes, you’ve diagnosed this correctly - Shopify sums shipping rates per shipping profile/location group, not per order. So whenever an order splits across two profiles (your 3PL warehouse and the pop-up), each profile calculates and charges its own rate independently, and there’s no native way to cap it at a single “highest rate wins” total. Putting everything in one profile fixes the summing but then every product shows all rates (including click & collect/courier on warehouse-only items), which isn’t accurate either.

A few practical options while you wait for native support:

  • Market-based shipping rates (rolling out ~October 2026) is meant to solve exactly this - it picks the highest matching rate instead of adding them, and lets you set location-based conditions. Worth keeping an eye on if your pop-up runs seasonally.
  • Shipping apps like Bespoke Shipping or ShipZip can apply custom rate logic (e.g., “if order ships from 2+ locations, charge only the higher rate”), but double-check they support split shipping specifically before installing.
  • If the pop-up is only live for short windows, some merchants just absorb the extra shipping cost with an automatic discount code during those weeks - clunky, but avoids overhauling your profile setup.

Hope that helps, and good luck with the pop-up! :slight_smile:

5

Hey @MaxCosta

hope you’re doing well!

Your understanding is correct. Native Shopify can’t both prevent rate stacking and keep shipping methods limited by location in this setup. Today, it’s essentially a trade-off. market driven shipping may improve this, but I’d wait for border availability before relying on it in production

6

Hey @MaxCosta, you’re right about rates summing across profiles, but you can do this inside one profile. Open the profile in Settings > Shipping and delivery and group the locations: the warehouse group keeps home 10 EUR and express 20 EUR, the pop-up group carries the 5 EUR Paris courier, so each shipment prices from its own group. Free click and collect is configured per location under Settings > Shipping and delivery > Local pickup, so it needs no rate. Shopify only adds two rates together when no single location can cover the whole cart, so stock the dual-availability items at the warehouse and ordinary orders stay on one rate. Test a cart of two warehouse items and check you get a single 10 EUR line.

7

HI @MaxCosta

Yes, your reading of the current setup is basically correct, but there is an important distinction with Shopify’s upcoming market-driven shipping that changes the answer.

With your current setup

Your two-profile approach is causing the €10 + €10 behaviour because the products are being evaluated as separate delivery groups/profiles.

Shopify’s current split-shipping model can create separate delivery groups when products come from different locations or shipping profiles.

So with:

  • Warehouse → Standard €10 / Express €20
  • Pop-up → Click & Collect €0 / Courier €5

You need the location/profile separation to prevent the pop-up methods appearing for warehouse-only products. But that separation also means you can end up with multiple shipping options being charged separately.

There isn’t a native legacy-profile configuration I’d recommend that simultaneously gives you:

  1. location-specific eligibility,
  2. click & collect only from the pop-up
  3. €5 courier only from the pop-up,
  4. €10 standard delivery from the warehouse, and
  5. one €10 charge when two products can ship together from the same warehouse.

That’s the limitation you’re running into.

The interesting part: Market-driven shipping

This is precisely one of the problems Shopify is trying to address.

In the new model, shipping options belong to a Market, and each option can have product conditions and location conditions. So you can have, conceptually:

STANDARD
├── Warehouse → €10
└── Pop-up → €10

CLICK & COLLECT
└── Pop-up → €0

2H COURIER
└── Pop-up → €5

The location conditions determine where a rate applies, so you don’t have to expose Click & Collect simply because a product happens to be in the same product grouping.

And importantly, when multiple matching flat/order-value rates are inside the same shipping option, Shopify uses the highest applicable rate rather than adding them together. Shopify’s own example is essentially:

Warehouse 1 = $5
Warehouse 2 = $8
Both in cart = $8, not $13

So your desired warehouse case can become:

Product A → Warehouse → Standard €10
Product B → Warehouse → Standard €10

Customer pays → €10

rather than €20.

And yes, your Click & Collect concern is addressed

This is the particularly relevant part for your question.

Shopify explicitly says location conditions control which rates apply to which fulfillment locations.

So the intended configuration would be:

Shipping option: Standard
Warehouse: €10
Pop-up: €10

Shipping option: Express
Warehouse: €20

Shipping option: Click & Collect
Pop-up only: €0

Shipping option: 2H Courier
Pop-up only: €5

Therefore, you shouldn’t have to expose Click & Collect for warehouse-fulfilled items merely because the product is in the same shipping configuration.

That’s actually one of the main reasons Shopify introduced location conditions in this model.

One caveat about the rollout

As of now, August 2026, Market-driven shipping is still a feature preview. Shopify says:

  • Feature preview: July 2026

  • Merchant rollout begins: October 1, 2026

  • All merchants: targeted for July 1, 2027

So October isn’t a date where you can necessarily say “my store will definitely switch on October 1.” Shopify describes it as a rollout, and existing merchants can opt in as it becomes available.

For your live client store, I wouldn’t rebuild the current shipping architecture around the preview yet. I’d test the exact configuration in a development store first.

One more important limitation

Market-driven shipping doesn’t magically make every shipping option consolidate.

Shopify’s current documentation says that across different shipping options, rates still sum. For example:

Standard = €10
Oversized = €8

Total = €18

The consolidation applies when the applicable rates are within the same shipping option. For flat/order-value rates, the highest applicable rate is used.

So for your client, I’d deliberately put the two warehouse/pop-up versions of ordinary delivery under one “Standard” shipping option, rather than creating separate Standard options.

Bottom line

For the current legacy shipping-profile system: your diagnosis is correct; there isn’t a clean native configuration that gives you all of those requirements simultaneously.

For Market-driven shipping: this is very close to exactly the use case Shopify is designing it for. You can combine product + location conditions for eligibility while keeping related flat rates under one shipping option so they don’t unnecessarily stack.

I would therefore not spend a lot of time building a complicated workaround app for this particular problem yet. Test the market-driven configuration on a dev store first. If it reproduces your two-product scenario correctly, that is likely the cleanest long-term solution.