Magento has two promotion engines that look alike and behave differently. A catalog price rule changes a product’s price before the cart, so shoppers see the discount while browsing. A cart price rule applies in the cart based on its contents, optionally behind a coupon. Choosing the wrong one is where promotions go wrong.
The confusion is understandable because both live under Marketing then Promotions, both use conditions, and both have a priority field. But they run at different stages, cache differently, and stack according to rules that trip up even experienced teams. This guide is how we think about them on Magento and Adobe Commerce development projects, including the part most articles skip: how each behaves under full page cache on a Hyva storefront.
The core difference: when each rule applies
The single fact that explains everything else is timing. A catalog price rule is calculated and indexed ahead of time and becomes the product’s price. A cart price rule is evaluated live when the cart contents change.
| Catalog price rule | Cart price rule | |
|---|---|---|
| When it applies | Before add to cart, on the product price | In the cart, based on cart contents |
| Visible while browsing | Yes, shows as the product price | No, only in cart and checkout |
| Coupon codes | Not supported | Optional, manual or auto-generated |
| Conditions based on | Product attributes only | Cart attributes, subtotals, quantities, products |
| Can discount shipping | No | Yes |
| Precomputed / indexed | Yes, into the catalog rule index | No, evaluated at runtime |
Per Adobe’s catalog price rules documentation, catalog rules do not use coupon codes precisely because they trigger before a product is placed in the cart. That is why a “20 percent off all outdoor furniture” sitewide sale is a catalog rule: you want the reduced price to show on category and product pages. By contrast, a “spend 100 dollars, get free shipping” or “use code SAVE15” offer is a cart rule, documented in Adobe’s cart price rules guide, because it depends on the whole cart and can carry a coupon.
Conditions, coupons, and what each can discount
The two engines expose different levers, and matching the offer to the right engine starts with what the offer needs to know.
Catalog price rules see only product attributes. You can target by category, attribute set, color, brand, or any product attribute, and set a start and end date so the sale begins and ends on its own. What they cannot do is react to the cart: they do not know the subtotal, the quantity, or whether a coupon was entered.
Cart price rules see the cart. As the Cloudways technical guide to both rule types lays out, they support product attributes, cart subselections, quantity and subtotal conditions, and cart attributes, plus optional coupons with auto-generation for length, format, and prefix. They can also discount shipping, which catalog rules cannot. The trade-off is visibility: a cart rule discount does not appear until the qualifying items are in the cart.
A simple test settles most cases. If the shopper should see the lower price while browsing, it is a catalog rule. If the discount depends on cart contents, needs a coupon, or touches shipping, it is a cart rule.
Priority and Discard Subsequent Rules: how stacking really works
Both rule types have a Priority field, and both have a Discard Subsequent Rules toggle, but they behave within their own engine, not across the two. This is the most misunderstood part.
Priority is a number where lower means higher precedence. When several rules of the same type qualify, Magento processes them in priority order. Discard Subsequent Rules is the stacking control:
- Discard Subsequent Rules set to No lets qualifying rules stack, so a product can receive more than one discount.
- Discard Subsequent Rules set to Yes stops processing after that rule, so no lower-priority rule of the same type applies.
The trap is that Discard Subsequent Rules only stops rules that come after it in priority order, within the same engine. It does not stop a rule with a higher priority (a lower number) that already ran, and it does not stop the other engine. A catalog rule and a cart rule can both apply to the same product at the same time, because they run at different stages. If a customer sees a 20 percent catalog discount and then a 10 percent cart coupon stacks on top, that is the two engines doing exactly what they were told, not a bug.
There is a real bug worth knowing about, though. Adobe has acknowledged and patched a defect where Discard Subsequent Rules did not behave correctly for cart price rules in some versions. If your stacking looks wrong and your logic is correct, confirm you are on a version or patch level where that fix is present before spending hours on the rule configuration.
To make stacking predictable, we set explicit priorities on every rule rather than leaving them all at the default, and we decide deliberately which rules are allowed to combine. Leaving priorities equal and Discard Subsequent Rules off is how unintended double discounts reach production.
How catalog price rules are indexed
Catalog price rules are not evaluated live. They are applied by an indexer and written into a price index, which is why a new catalog rule sometimes does not show until the index updates. After saving a catalog rule, Magento needs to reprocess catalog rule prices, and on a large catalog that is not instant.
This ties directly into indexing mode. On a production store running Update by Schedule, catalog rule prices refresh with the indexer cron rather than immediately on save, so there can be a short delay between saving a sale and seeing it live. If a catalog rule is not showing at all, the first checks are whether the rule is active, within its date range, applies to the right customer group and website, and whether the catalog rule index has actually run. Keeping cron and indexers healthy is foundational here, which we cover in Adobe Commerce cron and indexer health. For sales that need to start and stop on exact dates without a manual reindex scramble, content staging is the cleaner tool, covered in content staging and preview on Hyva.
Cart price rules, by contrast, are not indexed. They run when the cart totals are collected, which is why they never have an indexing delay but also why they can add per-request work on a busy cart.
Why the two rules cache differently on Hyva
This is the part that matters on a fast storefront and the part most guides ignore. Full page cache and the two rule types interact in opposite ways.
A catalog price rule price is part of the cached product page. Because the rule is indexed into the price and rendered server-side, the discounted price sits inside the full page cache and serves to every visitor with no per-request cost. That is ideal: a sitewide catalog sale is effectively free to display at scale.
A cart price rule outcome cannot be cached, because it depends on the individual cart. On a Hyva storefront the cart and its totals are private content, loaded per session rather than baked into the cached page. Hyva fetches this customer-specific data client-side through its section data mechanism rather than punching holes in the cached HTML the way legacy Luma leaned on ESI. The practical consequences:
- A catalog discount shows instantly on a cached page.
- A cart discount appears only after the private cart data loads, so a promotional message tied to a cart rule must render from that private layer, not from cached HTML.
- Hard-coding a cart-rule banner into a cached block will show it to everyone, including carts that do not qualify.
If you are building promotional messaging, the rule of thumb is that anything driven by cart contents belongs in the private, client-loaded layer. Our guide to full page cache and Varnish on Hyva explains how Hyva favors private content over ESI hole-punching, and customer segments and dynamic personalization on Hyva covers the related pattern for segment-based content. For B2B stores, remember that shared catalog and tier pricing are a separate mechanism again, covered in wholesale tier pricing and shared catalog price lists.
Which rule to reach for
A quick decision guide for the common promotions:
- Sitewide or category sale, price visible while browsing: catalog price rule.
- Buy X get Y, tiered cart discount, spend threshold: cart price rule.
- Coupon code campaign: cart price rule, with a specific or auto-generated coupon.
- Free or discounted shipping: cart price rule.
- Customer-group pricing that should show on the product page: catalog price rule scoped to the group.
- Flash sale with exact start and stop times: catalog price rule, ideally through content staging.
Where other platforms sit, and where we fit
Promotion models differ by platform, and it is worth knowing the shape when you compare. Shopify splits automatic discounts from code discounts and, on Plus, adds scripting for complex logic; Shopware uses its own rule builder for promotions; and BigCommerce exposes promotions through both the admin and its API. Magento’s two-engine model is more granular than most, which is its strength for complex merchandising and its complexity for teams new to it.
Getting promotions right on a Hyva storefront is as much about caching and rendering as it is about the rule configuration, which is why we treat it as a build concern rather than an afterthought on Hyva development projects. If you want background on the team behind this work, about Bemeir covers our history as the first US Hyva Gold Partner, our technology partner ecosystem covers the tools that extend native promotions, and Bemeir is where a conversation starts.
Frequently asked questions
Can a catalog price rule and a cart price rule apply to the same product at once?
Yes. They run at different stages, so a catalog rule can lower the shelf price and a cart rule can then apply an additional discount at checkout. This is expected behavior, not a fault. If you do not want them to combine, you have to design around it, because Discard Subsequent Rules only controls stacking within one engine, not across both.
Why is my catalog price rule not showing on the storefront?
Usually one of four reasons: the rule is inactive or outside its date range, it is scoped to a different customer group or website, the catalog rule index has not run yet, or full page cache is serving an old page. Confirm the rule settings, reindex catalog rule prices, and flush the cache. Catalog rules depend on indexing, so on Update by Schedule there can be a short delay after saving.
Does the discard subsequent rules setting stop all other discounts?
No. It stops lower-priority rules of the same type from applying after it, in priority order. It does not stop a higher-priority rule that already ran, and it does not affect the other engine. A cart rule cannot discard a catalog rule and vice versa. Be aware that Adobe has patched a bug where this setting misbehaved for cart rules in some versions.
Do cart price rules slow down a Hyva storefront?
Catalog rules do not, because they are indexed into the cached page. Cart rules are evaluated live when totals are collected, so a cart with many active rules adds some per-request work, but this happens in the private, client-loaded layer on Hyva rather than in the cached HTML, so it does not affect the cached browsing experience.
How should I schedule a time-limited sale?
For a catalog sale with exact start and end times, use content staging rather than relying only on the rule dates and a manual reindex. Staging schedules the change and updates the index cleanly, so the sale starts and ends on time without someone flushing caches at midnight. Cart rules have their own date range and do not need staging in the same way.
