Running a Sale in PrestaShop: Cart Rules, Specific Prices and Discount Strategies

Most PrestaShop merchants discover, usually the hard way, that the platform has not one discounting system but two — and they overlap just enough to cause real damage. You set a 25% specific price on a product, then run a "10% off everything" coupon for a campaign, and a customer quietly walks away with 32.5% off because the two stacked on top of each other. Or the reverse: you build a perfect cart rule, it never fires, and you spend an afternoon working out that a competing rule with a higher priority silently ate it. This guide is about the mechanics — which of PrestaShop's two discount engines to reach for, where each one lives in the back office, and the specific settings that decide whether your sale prints money or quietly erodes your margin.

The strategy questions — when to run a sale across the calendar, how to build urgency, how to schedule things to switch on and off by themselves — each have their own home, and we link to them as we go. This post stays on the tool itself: getting a sale correctly built and displayed in PrestaShop.

The two discount engines, and why the difference matters

PrestaShop applies discounts in two completely separate places in the codebase, and once you understand which is which, most of the confusion disappears.

A specific price (the SpecificPrice class) modifies the price of a product. It is baked into the price the customer sees on the product page, in listings, and in the cart — there is no code to enter and nothing to "apply". PrestaShop computes it inside Product::getPriceStatic(), which is why a specific price can drive the strikethrough "was/now" display automatically.

A cart rule (the CartRule class, the engine behind what older stores called "vouchers") works on the whole cart. It is evaluated at checkout, after the cart is assembled, and it can act on the order total, on shipping, or by adding a free gift. It can require a code or fire automatically, and it can be gated behind conditions a specific price simply can't express ("spend over €100", "only for the Wholesale customer group", "only on a first order").

The "so what" for you as a store owner: if the discount belongs to the product, use a specific price; if it belongs to the basket or the customer, use a cart rule. That single sentence resolves most of the "which one do I use?" questions before they start.

Building a specific price (product-level markdowns)

Open a product, go to the Pricing tab, and scroll to Specific prices → Add a specific price. The form looks busy, but the fields that actually decide behaviour are few:

• Apply to — leave the customer group, country, currency and shop on "All" for a normal public markdown. Narrowing the group is how you give Wholesale a different price from Retail without two product records.
• Available from / to — set both dates and PrestaShop activates and deactivates the price for you. You do not need to remember to switch it off; this is the simplest form of a scheduled discount, and for anything more elaborate (recurring windows, progressive markdowns) see scheduled discounts.
• Discount — choose Amount (e.g. €10 off) or Percentage, and critically pick tax included or tax excluded. Getting this wrong is the single most common specific-price mistake: a "€10 off" set tax-excluded comes out larger than the customer expects once VAT is added.
• Starting at [quantity] — set this above 1 to build a tiered "buy 5+ for €8 each" price. Leave it at 1 for a straight markdown.

Because the result is the price, PrestaShop draws the original crossed out next to the new one with no extra work — the visual that makes a markdown feel like a deal. One caveat worth knowing: a specific price always wins on the product page, so if you ever wonder why a product won't show its full price, an old, dateless specific price is the usual culprit. The bulk equivalent — discount an entire category or the whole catalogue by a rule rather than per product — is the Catalog Price Rules screen, which writes specific prices in bulk against conditions instead of one product at a time.

Building a cart rule (the coupon and basket engine)

Go to Catalog → Discounts → Cart Rules → Add new cart rule. The form has four tabs, and each one maps to a real decision:

• Information — the customer-facing name, an optional code (leave it blank and the rule becomes automatic), Highlight (PrestaShop nudges the customer to apply it in the cart), Partial use (lets leftover voucher value carry to a future order — turn this off for percentage discounts), and Priority, which decides the order rules are evaluated in when several could apply.
• Conditions — the gate. Limit to a customer group, a date range, a minimum amount, a carrier, specific products or categories, total quantity available, quantity per user, and "only the customer's first order". This is everything a specific price can't do.
• Actions — the payoff: a percentage or fixed-amount discount, free shipping, and/or a free gift (a specific product added at no charge). You can combine free shipping with a discount in a single rule.

Two settings here cause most of the "my coupon didn't work" tickets. The first is the silent one near the discount action: "Apply a discount to… Specific product" versus the order, and the tax included / excluded toggle, same trap as specific prices. The second is the "Total available" and "Total available for each user" caps on the Conditions tab — set "each user" to 1 for a one-per-customer code, and watch the global cap if a campaign suddenly stops redeeming.

Automatic vs code-based cart rules

Leaving the Code field empty turns a cart rule into an automatic discount — it applies the instant the conditions are met, with nothing for the customer to type. That is exactly what you want for "free shipping over €50" or "10% off this weekend, no code needed". A code, by contrast, is for targeted distribution: an email list, an influencer, a win-back to a specific segment. The mechanism is identical; the only difference is whether you fill in that one field.

Discount stacking — the setting that protects your margin

This is where unintended losses hide, so it deserves precision rather than a hand-wave. Three rules govern what happens when discounts meet:

• Specific prices always apply — they're the product's price, full stop. There is no "off" switch at checkout.
• A cart rule stacks on the already-reduced specific price by default. So a product at a 25% specific price, plus a 10% automatic cart rule, sells at roughly 32.5% off — not 35%, because the second discount is taken on the post-markdown price, but still deeper than you may have intended.
• To stop that, exclude discounted products on the cart rule itself: on the Actions tab use "Exclude discounted products" so the rule ignores anything already on a specific price. Between two cart rules, each rule's Priority and its conditions decide which fires; PrestaShop will apply multiple cart rules together unless their conditions or your exclusions prevent it.

Decide your stacking policy before the campaign goes live, not after the margin report comes in. A two-minute "exclude discounted products" tick is cheaper than a weekend of accidental 32.5%-off orders. Some products should never enter a sale at all — and there's a discipline for that, covered in why some products should never go on sale.

Making the sale visible

A discount the customer doesn't notice converts no better than full price. PrestaShop gives you some of this for free and leaves the rest to you:

• Strikethrough pricing — automatic for specific prices, on the product page and in listings. No configuration; it's the headline reason to prefer a specific price for a visible markdown over a hidden cart rule.
• The discount percentage flash — the default theme can render a "-25%" flag from a specific price. If your theme hides it, that's a template setting, not a missing feature.
• Sale badges on listings — for richer labels ("CLEARANCE", "LAST FEW", a custom "-30%"), our Custom Product Badges module overlays them on product images across category pages, where the strikethrough alone is easy to miss.
• Site-wide announcements — a campaign needs a banner the moment a visitor lands. Banner Revolution handles this without a designer in the loop.
• A dedicated sale destination — point a category or CMS page at your sale items so the offer has a URL you can put in an email and an ad.

If you want the sale itself to feel like an event — countdown timers, featured deal pages, urgency that doesn't tip into pressure — that's a topic of its own; start with flash sales without being manipulative and our purpose-built Sales Revolution.

A decision framework for the next sale

When you're about to build a promotion, run it through four questions and the right PrestaShop tool falls out:

• Is the discount tied to a product or to the basket? Product → specific price (and you get strikethrough free). Basket, spend threshold, or customer segment → cart rule.
• Does the customer need to do anything to get it? If it should "just happen", that's an automatic cart rule or a dated specific price. If it's earned or targeted, give the cart rule a code.
• Can it collide with another discount? If a specific price is live, decide stacking now: tick "exclude discounted products" on any cart rule that shouldn't compound it.
• Should it start and stop on its own? A simple window → the from/to dates on either tool. Recurring or progressive → scheduled discounts.

Bundles and gift cards — adjacent tools worth knowing

Two related mechanics often get mistaken for "a sale". A free gift cart rule is the native way to do "buy this, get that free", but for selling pre-priced multi-product sets as a unit, that's product bundling proper — see product bundling. And if a campaign is really about giving customers store credit rather than a markdown, gift cards for PrestaShop are a different instrument again — a cart rule of value the customer holds, not a discount you push.

Measuring whether the sale actually worked

The trap with sale measurement is celebrating revenue while profit quietly falls. After a promotion ends, look past the top-line number at four things in your stats: revenue versus the equivalent prior period (did the sale create demand or just pull forward orders that were coming anyway?), average margin per order (higher revenue at a thinner margin can mean less actual profit), new versus returning customers (did you acquire anyone, or discount people who'd have paid full price?), and the post-sale dip (a slump right after a sale ends is a sign you've trained customers to wait). Give it real volume before you judge — a few days of data will mislead you with normal week-to-week noise.

The honest summary: PrestaShop's two engines are simple once you stop treating them as one. A specific price is the product's price, with a free strikethrough and a date window. A cart rule is the basket's logic, with conditions, codes and the exclusion toggle that keeps two discounts from compounding into a margin you never agreed to. Get those mechanics right and the rest of promotion strategy — when to run sales across the year (the seasonal calendar), how to prep for the big ones (Black Friday automation) — is building on a foundation that won't leak.