How do you set up tag-based pricing rules on Shopify?

A tag-based pricing rule has three parts: a condition (which customer tag it applies to, e.g. wholesale), a scope (which product, variant, or collection it covers), and a price action (fixed price, percent off, or a quantity ladder). You tag the customer, write the rule, and a Shopify Functions app resolves the price on the product page and rewrites the cart line price via the Cart Transform API, so the same number flows through cart, Shop Pay, draft orders, and refunds. No theme code, no Plus requirement.

What happens when a customer has more than one pricing tag on Shopify?

A customer can carry several tags at once (wholesale, vip, staff). Without an explicit precedence model, two rules can both claim the same line and the result is undefined. A correct setup resolves the conflict deterministically: either a fixed priority order (staff beats vip beats wholesale), a lowest-price-wins rule, or a most-specific-scope-wins rule. Pick one model and apply it everywhere, so the same customer and the same cart always produce the same price.

Tag-Based Pricing Rules on Shopify: Setup and Conflict Resolution

Q: Can a tag-based pricing rule include quantity breaks?

Yes. A tier price and a quantity ladder are two layers of the same rule, not competing rules. The tag sets the base tier price; the quantity ladder adjusts it at thresholds (6+, 12+, 24+). The resolution order is: pick the winning tag first, then apply that tag's quantity ladder. The unit price the customer pays should match the order record exactly, so refunds and partial fulfillments use the price actually charged.

If you are still deciding whether tag-based pricing is the right pattern at all, start with the concept overview in Shopify customer tag pricing, explained. This post assumes you have picked the pattern and need to know how the rules actually behave once you have more than one of them. That is where most setups quietly break.

What a tag-based pricing rule is made of

A tag-based pricing rule has three parts. Keep them separate in your head and the rest of this gets easier.

Condition — the customer tag that triggers the rule. wholesale, vip, staff, distributor-a. The customer is tagged manually, by CSV import, or by a tagging app that watches spend or signup source.
Scope — what the rule covers. A single variant, a product, a collection, or the whole catalog. Scope is where most pricing mistakes hide, because a broad rule and a narrow rule can both match the same item.
Price action — what happens to the price. A fixed unit price, a percent off retail, or a quantity ladder (6+, 12+, 24+). One action per rule.

Read as a sentence: if a customer carries tag X, charge price Y for scope Z. One condition, one scope, one action. Tag in, price out.

For the rule to be worth anything, the price it produces has to hold past the product page. A rule that only changes the displayed number in Liquid reverts to retail in the cart and charges full price in Shop Pay, because Shop Pay never loads your theme. A rule that runs on Shopify Functions rewrites the cart line price in Shopify's own checkout pipeline via the Cart Transform API, so the resolved price flows through cart, Shop Pay, draft orders, the Shop app, and the order record. That last part matters for refunds: the order stores what the customer actually paid, not retail.

The part nobody mentions until tier two: overlapping tags

One rule is trivial. The problem is that Shopify customers can carry as many tags as you like, and a good customer often carries several. A founder who buys at wholesale, joined the VIP program, and is also on staff can legitimately hold all three tags:

customer.tags = ["wholesale", "vip", "staff"]

Now suppose you have three standing rules:

wholesale  →  40% off catalog
vip        →  25% off catalog
staff      →  fixed $1 over cost

All three match. All three want the same cart line. Which price does this customer pay? If your app does not have an explicit answer, the answer is "whichever rule the engine happened to evaluate last," which is to say: undefined, and different on different days. That is the bug that shows up as "a wholesale customer got charged retail" or "staff somehow paid less than cost on a clearance item." It is not a tagging mistake. It is a missing precedence model.

Three ways to resolve the conflict

There are only three sane models. Pick one, write it down, and apply it to every rule. The wrong move is to mix them.

Model	How it decides	Best when	Watch out for
Priority order	Each tag has a rank. Highest rank wins, ignore the rest. E.g. `staff > distributor > wholesale > vip`.	You have a clear hierarchy of customer types and want predictable, explainable pricing.	You have to maintain the ranking. A new tag with no rank is a silent gap.
Lowest price wins	Evaluate every matching rule, charge the cheapest result for that line.	You want the customer to always get their best entitled price with no ranking to maintain.	Margin. "Lowest always wins" plus a deep clearance rule can sell below cost. Pair it with a price floor.
Most specific scope wins	A variant-level rule beats a collection rule beats a catalog rule, regardless of tag.	You set special prices on specific SKUs that should override blanket tier discounts.	Two rules at the same specificity still tie — you need a tiebreaker, usually priority order.

In practice most merchants want priority order as the default and most-specific-scope-wins as the override, with a price floor sitting underneath both so no combination ever sells below a number you set. Worked through the example above under "priority order with staff highest," the customer pays the staff price, and the wholesale and VIP rules are ignored for that line. Deterministic, explainable, and the same every time.

The test that catches this: create one test customer and give them every pricing tag you use at once. Add a product to the cart and open Shop Pay. If the price is the one your precedence model predicts, your rules resolve correctly. If it is something else — or if it changes between page loads — you have an undefined-precedence bug, not a tagging problem.

Layering a quantity ladder on a tier price

Quantity breaks are not a competing rule. They are a second layer inside the winning rule. The resolution order is: pick the winning tag first, then apply that tag's quantity ladder. So a distributor-a rule can carry both a base tier price and a ladder:

distributor-a, SKU 4471:
  base tier price   $18.00
  6+   units        $16.50
  12+  units        $15.00
  24+  units        $13.50

The customer is charged the ladder rung their cart quantity reaches, at the tier they won on tag precedence. The unit price the cart computes should match the order record to the cent, because refunds and partial fulfillments read from the order, not from the rule. If the ladder lives in display Liquid and the real charge is the flat price, a 24-unit refund pays back the wrong number and you find out in the support queue.

Guardrails every rule set needs

Precedence decides which price wins. Guardrails decide what the rules are never allowed to do. Four are worth setting before you go live.

A price floor. A hard minimum, per product or global, that no combination of tier price, quantity break, and stacked discount can cross. This is what keeps "lowest price wins" from selling below cost.
Closed-loop access. Anonymous and untagged customers must never resolve a tier price. A tier price the public can read is a discount waiting to leak. See staff pricing that doesn't leak.
Discount-code interaction. Decide explicitly whether a tagged customer can also stack a coupon on top of their tier price. Usually the answer is no for wholesale and yes for VIP — but it has to be a decision, not an accident.
Audit and rollback. When a rule misfires, you want to learn it from a log and revert the rule set, not reconstruct what happened from a customer screenshot. See pricing tier governance.

Setting it up without code

The mechanics are the same across Functions-based apps, and none of these steps touches your theme:

Tag the customers. Manually, by CSV, or automatically with a tagging app keyed to spend, signup form, or order history.
Write each rule as condition → scope → action. Keep scopes as narrow as the case allows; a blanket catalog rule is the one most likely to collide later.
Set the precedence model once, at the rule-set level: priority order, lowest-price-wins, or most-specific-wins, plus a price floor.
Test on a real customer account on a development store. Use the multi-tag test customer described above. Add to cart, open Shop Pay, place a draft order, issue a test refund.
Publish. The rules are live everywhere Shopify charges money, with no theme commit and no redeploy between edits.

On a development store, the first rule is roughly a 20-minute loop, because there is no theme deploy in the cycle. Adding the precedence model and a floor is a one-time setup, not a per-rule cost.

How the category lines up

Tag-based pricing rules are offered by several Shopify apps, and they are not all built the same way. The questions that separate them are the ones above: does the price hold in Shop Pay and the order record, or only on the product page; and does the app have an explicit precedence model when a customer carries more than one tag, or does it leave overlaps undefined. Wholesale Gorilla and Wholesale Pricing Now are common picks in this category and each is strong at the wholesale-catalog use case. When you compare options, run the multi-tag test customer through each one before you commit — that single test surfaces the precedence behavior faster than any feature list. Our side-by-side write-ups cover the trade-offs in detail: TagTier vs Wholesale Gorilla and the Shopify wholesale app comparison.

Honest scope

If you have one customer group and one rule, precedence never comes up and any of these apps is fine — this whole post is about the second tier and beyond. Tag-based pricing rules earn their keep when you have multiple standing customer groups, customers who legitimately belong to more than one, and a need for the price to be the same number every time across cart, Shop Pay, and refunds. If you need a quote-and-approve workflow with a sales rep, that is a CPQ job, not a pricing-rule job.

Test tag-based pricing rules on a dev store →

Tag-based pricing rules on Shopify