Measure a promotion’s blast radius before it changes a live price.
PrestaShop already has cart rules and catalogue price rules. The harder job is controlling scope, stacking, contribution, timing and cleanup. Model those decisions, then inspect the exact NP Promo Pro workflow before buying.
- €99
- one-time licence, ex VAT
- 1.1.0
- current self-hosted release
- PS 8.2.5 / 9.0.3
- clean-install runtime checks passed
- 7
- shipped back-office and storefront languages
The rule type matters less than the control around it.
Define the catalogue scope
Name the exact shop, category, products, brand, supplier or customer group. An empty or misunderstood scope can touch far more prices than intended.
Set a contribution floor
Calculate the discount against contribution, not only revenue. Choose the minimum amount the merchant is prepared to retain after the promotion.
Model stacking explicitly
Existing specific prices, cart rules, group discounts and other modules can change the effective result. Test the combinations the store actually permits.
Plan the exit before launch
Assign an end time, redemption cap, reviewer and rollback test. Expiry is not enough if generated objects or caches remain after the campaign.
Build a promotion, inspect its native objects, then test the margin gate.
Change the effect, target, date and economics. This connected fixture reproduces the exact validation and CartRule / SpecificPrice compilation decisions in the sales package.
Connected dry-run decision
Release 1.1.0 enables apply only after the exact payload receives a signed 15-minute review token. Change any input and that review is invalidated.
Adjust the campaign, then generate an exact preview.
The current inputs match the signed review fingerprint.
The reviewed payload passed the gate in this browser-only simulation.
Buyer-lab simulation only — no store, CartRule or SpecificPrice is changed.
Ready for a staging checkout
Validation, date and sample eligibility pass. Confirm the exact theme, tax, shipping and module stack in staging.
SpecificPrice rows
Catalogue-scoped price edits write native product prices; targeted groups expand the rows on apply.
Dry-run object plan
Merchant-defined margin guardrail
The sample remains above your floor
That is one gate only: stage taxes, fees, returns, shipping, rounding and overlapping rules before launch.
Exact implementation notes
- • Targeted percentage/fixed prices, increments and fixed prices compile to SpecificPrice only, avoiding a double discount.
Browser-only deterministic fixture. It writes no CartRule, SpecificPrice or ledger row. It mirrors release 1.1.0 validation, compilation and signed-review gate; the margin layer uses only these values and predicts neither redemptions nor sales lift.
What this fixture proves
The exact 1.1.0 package passed clean-install runtime checks on PrestaShop 8.2.5 and 9.0.3. It includes ten effects, signed 15-minute previews, conflict blocking, exact reviewed snapshots and a generated-object ledger. Validate your own theme, checkout and rule overlaps on staging.
Build, preview and account for the generated objects.
1. Scope the rule before it touches a price
Choose the effect, catalogue or customer scope, date window, priority and stacking policy in one workspace. The merchant still owns the economics of the rule.
Open this exact product scene →
2. Preview the catalogue change
Review the intended old and new prices before applying a bulk flash-sale action, then keep the CSV as a bounded record of the planned change.
Open this exact product scene →
3. Let native time windows end the campaign
Inspect scheduled and active campaigns with their native start and end windows before relying on the storefront countdown or expiry behavior.
Open this exact product scene →
4. Account for generated rules and prices
Inspect the application ledger that counts CartRule and SpecificPrice objects created by the module, and test deletion or uninstall on staging.
Open this exact product scene →
Test the places where promotion rules usually surprise the operator.
| Failure point | Published product evidence | Your staging test |
|---|---|---|
| Scope expands unexpectedly | The campaign builder publishes explicit catalogue targeting and a dry-run preview before apply. | Use products that should match and products that must not; compare the preview count and exact list. |
| Discounts stack differently | Priority and stacking policy are visible rule settings; the module does not decide the merchant’s policy. | Exercise one existing specific price, group discount, cart rule and coupon in every allowed combination. |
| Checkout total differs | The workflow exposes the intended catalogue output, not a universal promise about every tax, currency or theme combination. | Verify product, cart, checkout, order and invoice totals for the store’s actual tax, currency and customer groups. |
| Campaign does not exit cleanly | The application ledger identifies the CartRule and SpecificPrice objects generated by the module. | Delete one staging campaign, clear relevant caches and verify prices, cart totals and generated-object counts return to baseline. |
Use native rules when they already cover the operating job.
Stay native for a simple rule
A single voucher, product reduction or catalogue price rule with a small known scope may need no extra module. Document it and test the cart.
Consider a module for an operating system
Multiple campaign types, repeated bulk repricing, shared targeting, dry-run review and generated-object accounting are an operating workflow rather than one rule.
A broader rule engine is useful only when the team can validate it.
Good fit · recurring controlled campaigns
The team repeatedly runs catalogue and cart promotions, has a margin floor and can review a dry-run before applying.
Conditional fit · existing promotion stack
Map every current writer to CartRule and SpecificPrice, then stage overlap and cleanup before replacing anything.
Poor fit · unsupported scope or promised uplift
Release 1.1.0 does not cover geo, currency, language, per-combination or wholesale-base targeting, and no promotion module can guarantee conversion or average-order growth.
Before a campaign reaches production
- Does a PrestaShop discount module guarantee more conversion or a higher average order?
- No. A module can apply and present a promotion, but buyer response depends on demand, products, price perception, traffic, competition and campaign design. Establish a baseline and measure attributable orders without assuming lift.
- Why not use PrestaShop native cart and catalogue price rules?
- Use them when they cover the job. NP Promo Pro is aimed at stores that need catalogue repricing and automatic cart promotions in one workflow, plus shared targeting, a signed 15-minute dry-run review and an application ledger. It should not replace a simpler native setup without a reason.
- What is the difference between a catalogue price edit and a cart promotion?
- Catalogue edits affect the price shown for matched products through SpecificPrice records. Cart promotions evaluate cart conditions and apply CartRule effects such as BOGO, 3×2, a cart-total reduction or free shipping. Test both storefront display and checkout totals.
- What is a safe discount percentage?
- There is no universal safe percentage. Use contribution margin rather than revenue alone, include tax, shipping, payment fees, returns and stacking, choose a merchant-approved floor, and model the maximum nominal exposure before launch.
- Which PrestaShop versions are currently covered?
- The exact NP Promo Pro 1.1.0 zip passed clean-install runtime checks on PrestaShop 8.2.5 and 9.0.3; its certified package range is 8.0.0–9.0.3. Theme, checkout and overlapping promotion interactions still require staging.
- How should I validate a campaign before launch?
- Use a staging clone and synthetic carts. Verify in-scope and out-of-scope products, group and currency combinations, taxes, rounding, stacking, start and end time, cache behavior, checkout, order, invoice and campaign deletion. Keep the dry-run export and rollback evidence.
- Are the campaign-lab values sent to Neuroplugin?
- No. Rule type, target, basket, margin, dates and effect values remain in this browser. With analytics consent, the site may count that the lab or a preset was used, never the private values entered.
Open the real promotion control path.
Inspect campaign scope, catalogue preview and the generated-object ledger. The product page keeps price, release identity, current scope limits and installation steps visible.