Choose a PrestaShop loyalty module by testing the points economy first.
A points programme creates a real future liability. Use your own order value and margin, inspect the merchant and shopper workflow, then decide whether a native module, a hosted platform or no programme at all fits the store.
- €129
- one-time licence, ex VAT
- PS 8.0–9.0.3
- published tested boundary for release 1.1.3
- 3
- redemption workflows to evaluate
- 7
- shipped UI and email languages
Design the programme before choosing the software.
What earns value?
Define eligible orders, products, groups and lifecycle states. Decide when points are pending, available, reversed or expired.
What liability do points create?
Translate points per euro and point value into a face-value reserve. Compare that reserve with contribution margin at full redemption.
How can shoppers redeem?
Vouchers, gifts and cash requests have different margin, accounting, fraud and legal consequences. Enable only the paths the store can operate.
Who operates the programme?
Assign ownership for cron health, refunds, manual adjustments, support, email deliverability, GDPR requests and programme changes.
Use the product before you decide.
Switch between the merchant and shopper journeys, open each real PrestaShop 9 screen and inspect exactly what the module adds. These are current QA captures, not concept art.
Follow one order from points earned to voucher eligibility.
Change the earning rule, campaign, order state and redemption thresholds. The connected path reproduces the deterministic arithmetic and validation gates in the exact sales package.
Connected order decision
Points are released to the wallet
The paid/loggable state moves the order reward to available and makes it eligible for the voucher gate below.
Exact earning trace
- 01Base · floor(order × points/€)800 pts
- 02Campaign extra0 pts
- 03Before order cap800 pts
- 04Removed by cap0 pts
The example keeps positive contribution after reserving the full voucher face value.
Voucher eligibility
The configured voucher can be created
Programme, identity, thresholds, balance and point value all pass the 1.1.3 preview gates.
Browser-only deterministic fixture. It writes no ledger entry and creates no CartRule. It mirrors 1.1.3 arithmetic and validation order; tax, expiry, fraud, actual redemption, refunds and legal/accounting treatment remain outside this lab.
What this fixture proves
The exact 1.1.3 package contains floor-based earning, campaign multiplier and bonus, an optional per-order cap, pending/available/cancelled ledger states and customer-bound voucher gates. Verify the complete workflow in staging before launch.
Follow one reward from configuration to customer evidence.
1. Configure before publishing
Separate the required economy and tier decisions from optional campaigns, payout and Reward Shop work.
Continue in the guided product experience →2. Give shoppers a clear wallet
Show balance, progress and redemption actions in the same language as the live storefront.
Continue in the guided product experience →
3. Let shoppers choose a real gift
Render the real eligible-product catalogue and points actions on the storefront’s locale route.
Continue in the guided product experience →
Ask for evidence at the failure points—not only a feature list.
| Question | Published evidence | Your staging test |
|---|---|---|
| What happens on refund or cancellation? | The product page documents pending, available, reversal and expiry operations. | Place, validate, refund and cancel one staging order; reconcile the wallet after each state. |
| Who owns customer and points data? | The module stores its ledger in the shop database and registers GDPR export and erasure hooks. | Export and erase one synthetic customer on staging; inspect every module row and backup path. |
| What fails when scheduled work stops? | The install path identifies cron as the driver for release, reminder and expiry work. | Pause cron, verify the visible delay, restore it and confirm idempotent catch-up without duplicate credits. |
A loyalty module is not automatically the right growth tool.
Good fit · repeatable purchase cycle
Customers have a realistic reason to return, the margin can fund a transparent reward reserve, and someone owns ongoing programme operations.
Conditional fit · replacing a hosted platform
Export the exact data, integrations and workflows you use today. Do not assume a native module reproduces a hosted ecosystem feature for feature.
Poor fit · one-off purchase categories
If customers rarely need the category again, tiers and points may add cost without a credible return journey. Fix acquisition or service instead.
Native, hosted and migration paths need different evidence.
NP Rewards Pro vs LoyaltyLion
Compare only the verified operating model, data location, integration boundary and your current quote.
Hosted vs self-hosted loyalty
Use an integration and ownership checklist instead of assuming feature parity between platforms.
Before the programme goes live
- Does a PrestaShop loyalty module guarantee more repeat purchases?
- No. Software can operate points, tiers and messages, but repeat purchase depends on product fit, service, timing, margin and programme design. Establish a baseline and evaluate attributable behaviour after launch.
- What is a safe reward rate?
- There is no universal safe percentage. Use contribution margin rather than revenue margin, model the full face value at 100% redemption, include tax and shipping effects, then have finance approve the rule.
- Does NP Rewards Pro work on PrestaShop 9?
- Release 1.1.3 publishes a tested boundary from PrestaShop 8.0.0 through 9.0.3. That is evidence for those versions, not a blanket promise for every future release; verify the current product page before upgrading.
- Can points be redeemed for cash?
- The optional cashout-request workflow is off by default. The module records and processes requests but does not make cash redemption lawful or compliant by itself. Validate legal, tax, KYC, invoicing and payment requirements first.
- Where does the loyalty data live?
- NP Rewards Pro stores its operational ledger in the merchant’s PrestaShop database and implements PrestaShop GDPR export and erasure hooks. The merchant still owns backups, access control, retention and lawful processing.
- How should I validate the module before launch?
- Use a staging clone. Test earning, release, refund, cancellation, expiry, voucher redemption, email delivery, cron interruption, GDPR export/erasure and any migration with synthetic customers before enabling the public programme.
Open the real three-step rewards workflow.
Check the launch workspace, product-page value and customer email. Price, compatibility boundary, release identity and install path stay visible on the product page.