Posting to see if anyone’s found a workaround for this, because we’ve hit a dead end with both Shopify and our subscription app.
Setup: Shopify Plus, custom shipping function at checkout offering two couriers, a cheaper standard option and a pricier premium option (different couriers, different price points). Customers can pick either on their first order, including on a subscription.
The problem: Once an order is a recurring subscription, Shopify’s checkout automatically displays a “recurring shipments” message telling the customer all future orders will ship via the cheapest available rate, regardless of which courier they actually selected. So if a customer pays extra for the premium option, the checkout is simultaneously telling them their subscription will default to the cheap one. Completely contradictory and confusing, so we can’t run it live as is.
What we’ve checked:
- Shopify support: confirmed this recurring shipments message is expected platform behaviour and there’s currently no way to remove, edit, or override it.
- Our subscription app (Skio): confirmed the shipping method selected at first checkout isn’t persisted to recurring orders, it defaults to cheapest, and there’s no native way to lock it. They said they’re hearing this from other merchants too, so we’re clearly not the only ones stuck on it.
Current workaround is just offering a single courier and removing choice altogether, which works but isn’t ideal.
Before we write this off, has anyone actually cracked this? Specifically interested in:
- Any way to suppress or edit the recurring shipments checkout message via Checkout UI extensions or Checkout Blocks
- Any subscription app (Skio, Recharge, Loop, etc.) that does persist the original shipping method choice to renewals
- Any workaround via metafields or shipping functions that reapplies the customer’s original selection at renewal
Appreciate any pointers, happy to share more detail on our setup if useful.
You’ve isolated a platform boundary, not just a Skio setting. Shopify’s current subscription documentation explicitly says that after the initial delivery, recurring shipments default to the least expensive available shipping method. So suppressing the sentence would only hide the same renewal behavior, not fix it:
https://help.shopify.com/en/manual/products/purchase-options/subscriptions/considerations
Checkout UI/Blocks can add UI or capture an attribute, but an attribute alone does not change the subscription contract’s delivery method. The technically credible fix has to happen at contract level: the app that owns the contract would need to carry the customer’s selected courier/rate into the contract deliveryMethod and deliveryPrice, then commit that update. Shopify exposes those contract-update mechanics to the owning subscription app:
Before changing apps, I’d run one redacted contract test and compare:
- the origin order’s selected shipping-line title/code;
- the resulting subscriptionContract deliveryMethod and deliveryPrice.
If the premium selection is absent from the contract, that proves the exact gap. The useful yes/no question for Skio, Recharge or Loop is: “Can you persist the first-order selected shipping rate into the subscription contract for renewals?” — not merely whether they can display both rates at initial checkout.
Two details would narrow the smallest safe workaround: do both couriers use the same fulfillment location/profile, and can Skio expose or update the contract deliveryMethod after creation? I would not spend more time trying to edit the platform sentence until that contract-level persistence question is answered.
This is really useful, thanks for taking the time. Confirms what we suspected but couldn’t get a straight answer on from either Shopify or Skio.
Quick update on the two questions:
Fulfilment location/profile: Same for both. Everything ships from a single 3PL, so no split there.
Contract-level persistence: This is exactly the gap, and we’ve already confirmed it with Skio directly. The initial order correctly carries the DPD rate through to the origin order when a customer selects it, but Skio doesn’t persist that selection into the subscriptionContract’s deliveryMethod/deliveryPrice on renewal. Renewals just default to cheapest. So it’s confirmed as a genuine platform/app limitation on their end, not something we can configure around.
One nuance worth adding: actual courier assignment at the warehouse end is handled by us regardless of which shipping line is shown at checkout, so the rate the customer sees and pays isn’t necessarily what dictates which courier physically picks up the parcel. That’s a separate internal routing decision. So our real problem is purely the price/message mismatch at checkout, not the courier itself.
@woodnwheels11 The nuance in your last post is the important bit, and I think it opens a door rather than closing one.
If courier assignment happens internally at the 3PL regardless of what was chosen at checkout, then what youre really selling at checkout isnt two couriers. Its two price tiers. The customer is choosing a service level and paying accordingly, and the physical routing is your decision either way.
That matters because it means you dont need the shipping rate to carry the choice at all.
Subscription contracts persist line items reliably. Thats the entire mechanism. What they dont persist, as youve now confirmed with Skio, is the delivery method. So youre currently storing the thing you care about in the one field that doesnt survive a renewal, while the field that does survive sits unused.
Move the premium tier off the shipping line and onto the contract as a line item. Something like Priority Handling as its own product, added to the subscription alongside the goods. It renews because line items renew. The price sticks because line item prices stick. And you stop fighting the platform entirely.
Then offer one shipping rate at checkout. The recurring shipments message becomes true rather than contradictory, because with one rate the cheapest available rate is the one they picked. The sentence you cant edit stops being a problem the moment it stops being wrong.
Two honest caveats.
Tax treatment changes. Shipping and goods are not always treated the same, and moving a charge from a shipping line to a product line can change what gets charged and how its reported. Worth ten minutes with whoever does your VAT before you build it.
And the harder one. If a customer pays extra for a named premium courier but routing is decided internally, thats worth looking at separately from this thread. Framing it as priority handling rather than a specific carrier is more accurate to what you actually deliver, and it happens to be the framing that makes the line item approach work. So the fix and the accuracy question point the same way, which doesnt happen often.
The dangerous part here is that nothing necessarily “fails” technically—the mismatch may only become visible when a customer who paid for premium shipping gets something different.
I’d want an exception check comparing what the customer selected/paid for against the shipping method that the recurring order actually receives, rather than discovering the mismatch from a complaint.
Founder disclosure: I’m building VedaSuite around this broader operational-exception idea—detecting mismatches early, showing the evidence and prioritising what needs attention. We don’t currently claim to fix this specific subscription-shipping behavior, but this is exactly the category of silent discrepancy we’re interested in. vedasuite.in
Hey @woodnwheels11, to make MayraApps’ line-item idea concrete: Skio’s API can add a product to a subscription contract as a recurring line item, not just a one-time add-on, so “Priority Handling” rides along on every renewal without ever touching the shipping line. Just confirm with Skio support that the add-on renews on the same cadence as your main product before you build the flow around it.
Hi there @woodnwheels11
This is mostly a limitation on how subscription shipping rates are stored rather than the shipping function. As a practical solution you can capture a customer’s preferred courier as subscription or customer metadata at initial checkout, then reference that value in your renewal subscription workflow to decide the renewal shipping method.
Regarding the checkout messaging, UI extensions cannot override the recurring shipment notice generated by Shopify platform. If the renewal workflow is not able to consume that stored preference, having one shipping rate for subscriptions might be your best bet.