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 0.6.0
- 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.
Reserve the full points liability before launch.
This model assumes every issued point is eventually redeemed. It exposes unit economics; it does not predict retention, breakage or incremental revenue.
- Points issued per order
- 800
- Face-value reserve per order
- €8.00
- Nominal reward rate
- 10.0%
- Contribution before rewards
- €32.00
- After full reward reserve
- €24.00
- Path to target reward
- 2 orders · €160.00 spend
Planning aid only. Excludes VAT, shipping, refunds, expiry, partial redemption, fraud, accounting treatment and legal requirements. It makes no revenue or retention forecast.
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. Show exact shopper value
Show the points attached to the current product next to the normal purchase controls instead of a vague rewards promise.
Continue in the guided product experience →
3. Close the accounting loop
The English demo email names the credited amount and order reference, then returns the shopper to the rewards area.
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 0.6.0 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.