Blog · Guide

How to test your tier pricing survived the Scripts migration

Scripts stop executing June 30, 2026. The migration risk isn't the rebuild — it's shipping a fix that looks right on the product page and charges full retail at checkout. Here is the parity test that catches it before your customers do.

7 min read · Updated June 2026

The one failure mode that matters

Most tier-pricing migrations don't fail loudly. They fail quietly: the discounted price renders on the product page, the merchant ships it, and then a wholesale buyer gets charged full retail in Shop Pay and emails support. By then the order is placed and the refund queue is forming.

This happens because a price can be changed in two fundamentally different places. Liquid theme code changes what is displayed. The pricing pipeline — Shopify Functions and the Cart Transform API — changes what is charged. A Script ran in the pipeline, which is why it held everywhere. A theme-code "replacement" does not, and the gap is invisible until checkout. The test plan below exists to make that gap visible on a development store, before June 30, instead of in production after.

The parity principle

A tier price is correct only if the same number appears in all five places Shopify touches money. Test each one as a tagged customer, logged in, on a development store:

SurfaceHow to checkPass condition
Product pageView the PDP while logged in as the tagged customerShows the tier price, not retail
CartAdd to cart, open the cart drawer and the full cart pageLine price and subtotal use the tier price
Shop PayProceed to checkout and open Shop Pay specificallyTier price holds — this is the one that breaks
Draft orderCreate a draft order in admin for the same customerResolves the tier price without manual edits
Order & refund recordPlace the order, then issue a partial refundRefund is calculated from the price paid, not retail

The fastest read is the Shop Pay check. Shop Pay skips your theme entirely, so if a price was faked in Liquid, Shop Pay charges retail every time. One add-to-cart and one Shop Pay open will tell you whether your migration is real or cosmetic.

The step-by-step plan

  1. Inventory the old Script first. List every tag, every tier price, every quantity break, and every product or collection the Script touched. This list is your acceptance test — you are checking the new path against it, line by line. Because Scripts editing locked on April 15, 2026, you cannot tweak the old Script during the cutover, so the inventory has to be captured before it stops executing.
  2. Rebuild on a development store. Recreate the rules in Shopify Functions or a Functions-based app. Keep the dev store data close to production: same tags, same representative SKUs, same quantity ladders.
  3. Run the five-surface check per tier. For each customer group, walk the table above end to end. A tier that passes the PDP but fails Shop Pay is not a pass.
  4. Test the edges (next section). Per-variant pricing, stacked quantity breaks, and the untagged-customer case are where blanket discounts quietly diverge from real tier pricing.
  5. Cut over before June 30. Verify the new path independently — you cannot run it live against an editable Script anymore — then switch.

The edges that hide bugs

  • Per-variant resolution. A SKU with five sizes can carry five different tier prices. Test a multi-variant product, not just a single-variant one — a rule that looks right on a simple product can collapse all variants to one price.
  • Stacked quantity breaks. If distributor-a gets a fixed unit price and a 6+/12+/24+ ladder, add 5, then 6, then 12 units and confirm the price steps at the right thresholds.
  • The closed-loop case. Open the same product in an incognito window with no login. An anonymous or untagged customer must see retail. A tier price the public can read is a discount waiting to leak.
  • Refund and partial fulfillment. Refund one unit of a multi-unit tiered order. The refund should reflect what the customer paid. If it refunds at retail, the order record stored the wrong number.

When a test fails

If the price reverts to retail in cart or Shop Pay, the pricing is running in the theme, not the pipeline — the fix is to move the logic into Functions / Cart Transform, not to patch more Liquid. If the PDP is wrong but checkout is right, it's a display-resolution issue (often the App Proxy lookup) and is lower severity. If the order record stores retail, refunds and fulfillments will be wrong even when checkout looked correct — treat that as a blocker, because it is the one customers notice after the sale. Whatever the failure, you want to find it in a log, not a screenshot from an angry buyer. That is the case for an audit log and rule-level rollback: a bad rule becomes a click to undo instead of a support incident.

Honest scope

This test plan is for standing tier pricing — multiple customer groups, each owed a different price, every day. If your "tier pricing" was one flat percentage for one group, Shopify's native automatic discounts may cover it, and the test is simpler. If you need a quote-and-approve workflow, that is a CPQ or native-B2B job, not a tag-pricing one. Match the test to what you actually run.

Rebuild and test on a dev store →


Related on TagTier