Catalog Promotions Feature

[mezzat11]

Is your feature request related to a problem? Please describe.
Vendure currently supports cart-level promotions that are applied during checkout, but it lacks native support for catalog-level promotions — that is, applying promotional discounts directly to product prices before the cart stage.

This makes it difficult to run storefront-visible promotions (e.g., "20% off all T-shirts") where customers can see the discounted prices directly in product listings or on product detail pages. This limitation affects merchandising, sales campaigns, and the overall user experience.

Describe the solution you'd like
I'd like to see Vendure support catalog-level promotions similar to Sylius Catalog Promotions, with features such as:

Ability to define promotional rules that adjust product prices at the catalog level, not just in the cart.

Discounted prices reflected in API responses (e.g., productVariant.priceWithTax, price) so they can be shown in the storefront.

Conditions and scopes such as:

Product collections, tags, or categories

Customer groups (e.g., VIP, logged-in users)

Time-based promotions (e.g., flash sales, seasonal discounts)

Support for stacking or prioritizing multiple catalog promotions.

Optional visibility labels (e.g., "Discounted", "On Sale") for the storefront.

Describe alternatives you've considered

Using cart promotions only — but this leads to a poor UX where customers only see discounts after adding items to the cart.

Custom logic on the storefront to simulate discounts — but this risks desynchronization between catalog and actual pricing logic.

Manual price overrides — but these are not scalable for short-term or dynamic campaigns.

Additional context
Sylius handles this very well with its Catalog Promotions module. Bringing similar functionality to Vendure would greatly enhance marketing capabilities, align promotions across the site, and reduce the need for front-end workarounds.

Thanks again for your amazing work on Vendure.

Best regards,

[mezzat11]

@dlhck Hi
continuing from our RMA discussion, I also wanted to raise the topic of catalog promotions as a key feature deserving of foundational support in the OSS edition.

In projects targeting real-world ecommerce (especially B2C in MENA), merchants consistently expect “catalog-wide” promotions — e.g., “Buy 1 Get 1”, “20% off all Jackets”, or “Flash Sale for Accessories” — applied before the cart, visible on PLP/PDP, and SEO-indexable.

As a strong reference, Sylius has a clean separation between:
• Cart Promotions (applied at checkout)
• Catalog Promotions (applied to product prices globally)

Their CatalogPromotion system allows:
• Conditions: product type, category, variant, inventory level, etc.
• Actions: fixed/percentage discount on product price
• Scope: entire catalog, filtered subsets
• Effects: computed price changes that are persisted or served dynamically for indexing and UI consistency

For Vendure, even a minimal core layer (e.g. CatalogPromotion, condition evaluation, price mutation at product query time) would:
• Enable rich frontend experiences (strikethrough prices, “on sale” labels)
• Improve SEO/ads support by exposing discounted prices statically
• Reduce need for complex cart-time-only workarounds
• Keep parity with other modern frameworks like Sylius, Shopware, and Saleor

[nicohps]

eligible-promotions-resolver.txt

This is indeed something we've been struggling with. We have a custom build solution for now.
This is the code for the eligiblePromotionsResolver (eligiblePromotions are the catalog promotions).
It's not perfect but it does the job for us. Below is the code and ChatGPT explanation of it :)
Public promotions are Vendure promotions that have a customField 'isPublicPromotion' set to true.

Explanation

🏷️ eligiblePromotions Resolver
This resolver fetches all public promotions that are potentially applicable to a specific ProductVariant. It does so by:

• Creating up to 15 mock orders (needed to test bulk promotions), each representing a possible purchasing scenario for the given product variant.
• Iterating through all public promotions fetched from EligiblePromotionService.
• For each mock order, it checks whether a promotion is eligible by calling promotion.test(ctx, order).
• If the test passes and the promotion hasn’t already been added, it's included in the result.

Purpose: To return a list of promotions relevant to a specific product variant, using mock orders to simulate different eligibility scenarios.

💸 promotionPrice Resolver
This resolver returns the discounted price of a ProductVariant if a promotion is applicable. It performs the following:

Creates a single mock order for the given variant with a quantity of 1.

• Applies all public promotions using orderCalculator.applyPriceAdjustments(...).
• Compares the prorated unit price (after promotions) with the original unit price.
• If there is a discount, it returns:
• priceWithTax: the discounted price (including tax if applicable),
• priceValidUntil: the soonest endsAt date of the applied promotions.

Purpose: To provide the storefront with a final promotion-adjusted price and its validity period, so the discounted price can be shown to users.

[mezzat11]

@dlhck @michaelbromley Looking for your feedback

[mezzat11]

🔍 Clarification: What Are Catalog Promotions?
This request is for catalog-level promotions, meaning discounts that directly affect product pricing before a product is added to the cart — visible on product listing pages (PLP), product detail pages (PDP), and search results.

Currently, Vendure supports cart-level promotions, but does not have built-in support for adjusting the actual catalog price as part of a promotional campaign.

📈 Why This Is Important
Catalog promotions are a core expectation in modern eCommerce platforms:

Magento: Has dedicated “Catalog Price Rules” for product-level discounts.

Sylius: Supports catalog promotions natively and independently of cart logic.

Shopify: Allows merchants to schedule and display sale prices across the storefront.

BigCommerce / Salesforce Commerce: Separate catalog and cart rules for flexibility.

💡 Most platforms treat catalog and cart promotions as complementary, with catalog discounts improving visibility and conversion during browsing, while cart promotions drive upselling at checkout.

💡 Suggested Design for Vendure
Catalog Promotion

Define promotions based on category, product, collection , customer groups, or facet conditions.

Support scheduled activation (start/end dates) and channel-specific scope.

Store effective promotional prices per variant (e.g., in a catalog_price table or cache).

Product Price Resolution

Override ProductVariant.priceWithTax logic to return discounted price if an active catalog promotion applies.

Optionally expose originalPriceWithTax for strikethrough display.

Frontend / API

API should return both discounted and original prices.

Support labels like “On Sale”, badges, or flags for frontend display.

Admin

Allow admins to bulk-apply catalog promotions (e.g., “20% off all summer collection”).

Support fixed or percentage-based overrides.

Channel and date filtering to allow campaign scheduling.

🔁 Interaction with Cart Promotions
When a product qualifies for both catalog and cart promotions:

Catalog price is applied first and shown in the storefront.

Cart promotion is applied afterward (e.g. “Spend $100, get 10% more off”).

Optional: Rules can block stacking if needed (e.g. “cannot combine with other discounts this can be configuration wise”).

This mirrors the behavior in Magento, Sylius, and other major platforms.

✅ Adding catalog-level promotion support would significantly improve Vendure's competitiveness for B2C use cases, especially where conversion visibility and sale campaigns are essential.

[michaelbromley]

Thanks for the suggestion @mezzat11.

The ability to easily see the promo price of a variant before it is added to the cart is indeed something that would be great to support.

The main reason we don't yet support it, is that it's a rather tricky one to do in a performant way, due to the way our promotions engine works. Evaluating all potential promotions in the ProductVariant.price resolver is not really practical when we consider that some shops might have a hundred active promotions, all of which would need to be evaluated.

So I like the idea of a separate query resolver that has the sole task of resolving the best promo price for a given list of variants.

There are still a number of technical & design challenges here. Because the current Promotion engine allows basically arbitrary code in the conditions & actions, so having them run in bulk eg on a product list page could become really bad for performance.

As you say, maybe a solution is to have a separate type of promotion that is very constrained in the type of logic it is allowed to contain, so we can guarantee (or at least be more confident of) acceptable performance, especially at scale.

[mezzat11]

@dlhck can this planned with your amazing achievement last time

[dlhck]

@mezzat11 this is such a big feature, I need to sit down with the team and scope this out first. Once we've that done I will update in here!