Run PrestaShop loyalty, retention and referral programs

What we would do

We would start with the reason customers do not return, then choose the smallest reward you can fund and administer. The right route depends on your existing shop: its PrestaShop version, installed modules, checkout and theme, CRM and payment integrations, order and refund data, markets, currencies and the team handling exceptions. Check whether the tools you already use can meet the requirement before replacing them or adding another reward engine.

For a change to an existing programme, use a private staging copy with your real configuration and representative reward records. Isolate customer messages and live integrations, rehearse earning, redemption and returns, then make the planned switch with reconciled opening balances and a recorded return plan. Agree how rewards issued after the switch will be honoured if you restore the previous implementation.

If you want help choosing the route, the PrestaShop Module Selection & Fit Assessment can test candidates against your existing shop and the agreed reward lifecycle.

Choose a reward model you can explain

Start with one clear proposition. You can offer points convertible to a discount, spend/order-based tiers, a future-purchase voucher, free shipping or a discretionary thank-you. You can also improve retention without a formal programme by providing accurate products, reliable delivery and useful support. Write the offer in a sentence a customer can repeat, including what they must do and when they can use the benefit. Check the distance to the first reward against actual basket values and purchase intervals; a clear ratio still fails if your typical buyer is unlikely to reach it.

Points, vouchers, reward-wallet balances and trade credit are different records. A voucher is a cart discount. A reward wallet needs its own ledger and redemption rules. A credit account is borrowing capacity with limits and repayment obligations. A credit slip is a refund/accounting document, not automatically a voucher or money returned through a payment provider.

PrestaShop core provides customer groups and discount mechanisms, rather than a complete current points/referral engine. The old official Loyalty module was retired in the 2021 module retirement. Do not assume that it is a maintained option for PrestaShop 9. Choose a supported implementation and test its exact lifecycle.

For a simple illustrative ratio, one point per EUR 1 and 100 points for EUR 5 represent a 5% nominal reward before eligibility, rounding and redemption conditions. EUR 50 earns half of that EUR 5 reward; EUR 200 earns EUR 10 of nominal reward value. This arithmetic does not prove the reward is affordable.

Separate earning, validation, conversion and redemption

Use this lifecycle as a checklist for the implementation you choose:

1. Earn pending points: record the qualifying purchase and the earning basis. Define whether tax, shipping, discounted lines and already-rewarded amounts count.
2. Validate points: release them only when the configured conditions are met. An unpaid cart must not be equivalent to a settled order.
3. Convert: where the system uses points-to-voucher conversion, record that separate operation and consume or lock the converted balance.
4. Redeem: validate the generated voucher’s dates, customer, basket threshold, usage limits and product scope at checkout.
5. Reverse or adjust: handle cancellations, partial refunds and previously converted or redeemed rewards according to your published policy.

In the archived official conversion controller, the customer explicitly transforms available points into a customer-restricted cart rule. Order validation does not itself create that voucher. Its minimum-amount setting is a minimum eligible basket amount, not a minimum reward balance. Redemption categories and earning exclusions are separate concerns.

That legacy controller creates a nonempty FID voucher code and highlights it. Generating, suggesting and applying a voucher are separate actions. Native automatic cart-rule selection uses an empty code; restricting a coded rule to a customer does not automatically apply it.

Document the actual state selectors in your installed module. Point validity, point expiry, voucher start date and voucher expiry are separate policies. There is no universal twelve-month expiry requirement. Show any expiry and reminders clearly.

Qualifying states, delivery delays and returns

Define qualifying paid orders and excluded cancellation/refund cases explicitly. PrestaShop’s orders.valid is assigned from the current order state’s logable flag in PrestaShop 1.7.8 and 9.1. It is not an independent proof of payment, delivery or absence of refunds.

Track the return-period deadline separately from the “Payment accepted” and “Delivered” states. If you release rewards after a return period, keep them pending until the relevant delivery-based delay has elapsed and cancellation/refund checks pass. Use a delivered-status workflow backed by reliable operational data.

• For a cancellation before conversion, remove or invalidate the pending points as implemented.
• For a partial refund, recalculate the eligible earning basis rather than assuming the whole order must disappear.
• For converted rewards, decide how an unused voucher is reduced or revoked.
• For an already-redeemed reward, document any permitted balance adjustment or future offset. Do not promise that a refund status reverses every related record automatically.

Process the customer’s refund separately from loyalty adjustments. For an EU withdrawal refund, the original payment method generally applies unless the consumer expressly agrees otherwise, without incurring a reimbursement fee, under Article 13 of the Consumer Rights Directive. A voucher cannot simply replace that refund because it is convenient.

Use the appropriate native discount mechanism

Modern group management is under Shop Parameters > Customer Settings > Groups. A blanket reduction normally follows the customer’s default group. Adding a second group membership alone does not select that group’s blanket discount.

For example, you might design Bronze, Silver and Gold tiers with different pricing or shipping privileges. Set thresholds from your own margin and purchasing data. Native groups do not automatically promote customers when spend crosses those thresholds. To give a tier free shipping, create a cart rule with Free shipping enabled under Actions and the tier's customer group selected under Conditions.

You can design different qualification policies. Consider these two illustrations: One grants 5% off a later order after EUR 100 of eligible spend, 10% after EUR 300 and ongoing free shipping after EUR 500. Another uses an entry tier below EUR 200 in a year, Silver from EUR 200 to below EUR 500 and Gold from EUR 500. These are alternative examples, not defaults or validated margin recommendations. Define whether a percentage is a one-order voucher or an ongoing group benefit, and whether qualification can later expire.

Loyalty Discounts System implements configured tier qualification and group assignment; use its module help for setup.

Smart Dynamic & Scheduled Discounts provides scheduled pricing campaigns and group targeting; use its module help for those settings.

Loyalty + Credit Revolution provides tier/privilege and credit-account capabilities; consult its module help for limits, terms and repayments.

For early access, category group-access controls are distinct from product catalogue/search visibility. The native product visibility setting is not a customer-group access selector.

Budget rewards and control stacking

Compare prices and costs on the same tax and currency basis. With a EUR 65 selling price and EUR 39 product cost, gross profit is EUR 26 before other costs. A 10% discount reduces the selling price to EUR 58.50 and gross profit to EUR 19.50. Fulfilment, payment, returns, support and marketing costs still need to be deducted.

If acquisition cost were EUR 80 and each undiscounted order contributed EUR 26 before other costs, four such orders would recover that acquisition cost in the simplified example. Actual repeat orders can carry additional acquisition or retention spend. The example is not a forecast or a 4:1 realised return on a discount.

A EUR 100 product with EUR 82 cost retains EUR 3 gross profit after a 15% discount. Other variable costs may consume that remainder. A fixed nominal reward percentage is therefore not automatically sustainable across your catalogue.

1. Set validity dates, total quantity and per-customer limits on each campaign voucher.
2. Set the minimum basket amount, including whether tax and shipping count.
3. Distinguish products that qualify the cart from products receiving the reduction. Use the appropriate Actions scope, such as selected products, to protect other lines.
4. Configure pairwise compatibility between cart rules and priorities. A lower priority number can win a conflict; the engine does not simply choose the largest monetary saving.
5. Test group reductions, specific prices and cart rules together. Cart-rule compatibility settings do not switch off an independent group reduction.

For example, successive 10% and 5% reductions produce a 14.5% reduction if both apply in that sequence. Inspect the actual final price, taxes and shipping. Native percentage vouchers do not provide a general maximum-discount-amount field; a fixed-amount reward can make the nominal ceiling explicit.

Worked example: protect a low-margin line

Put the EUR 65 item costing EUR 39 and the EUR 100 item costing EUR 82 from the examples above into the same basket. A 15% campaign across both leaves only EUR 3 gross profit on the low-margin item before other costs. Making that item qualify the basket does not mean it should receive the reduction: choose eligible reduction lines explicitly, then inspect each line's final price.

Include sale products, then repeat as a tier customer whose group already reduces the product price, adding a birthday code, a free-shipping benefit and another promotional code. A campaign exclusion alone does not establish that the group's ongoing price is affordable. Keep the line totals and remaining contribution with your test results, including shipping and payment costs.

If protection must cover several discount mechanisms, Discount Exclusion Manager provides product, category and brand exclusions while eligible basket lines retain the promotion; verify its policy against your actual group pricing and vouchers.

Make repeat buying easier before adding incentives

Start with accurate descriptions and photography, timely order confirmation, understandable tracking, usable returns and support that resolves the issue. A resolved failure may repair the relationship; it does not guarantee greater loyalty than a purchase without a failure.

Use order-value, purchase-frequency and customer-lifespan measures to identify where improvement is possible. Base replenishment messages on the product’s real purchase cycle. For example, a customer who normally replenishes coffee every six weeks could be eligible for a reminder before that point. Treat the timing as a hypothesis to test. Compare buyers of replenishable goods with buyers of long-life products before scheduling messages. Suppress a reorder prompt when the relevant item was returned or the customer has already bought it again.

Separate replenishment, new-product messages and win-back sequences. You might show relevant arrivals first, then test a personal offer for a lapsed segment. A universal “lapsed after 60 days” rule does not fit every product.

Check a connector’s actual scope before building an automation: opted-in contact synchronisation, new purchase events and historical-order backfill are different capabilities. The Mailchimp Integration synchronises audience members. Plan purchase-history synchronisation separately. Before enabling a flow, inspect the actual event fields from a test purchase and refund, and check consent and unsubscribe handling. Points balances, tier changes and reward-expiry events also need explicit mapping; an order connector does not establish that those fields reach your marketing platform. Use the email-marketing guide to plan consent, recovery and order messages.

Estimated Delivery Date displays product-page delivery estimates; use its module help for supported placements.

Product and Store Reviews creates pending review reminders when an order enters a state with the delivery flag; check the sending workflow in its module help and confirm physical delivery before inviting feedback.

Explain earned and available rewards in the account area, cart and relevant follow-up messages. Display the converted reward value beside points, together with the conditions still needed to use it. Show estimated earnings as pending where appropriate, rather than presenting them as an immediately usable discount. A review, account or referral bonus requires an implementation that actually supports it. If you incentivise reviews, require honest feedback and follow the publication platform’s rules.

Design the friend’s discount and referrer’s reward

A referral scheme can reward the friend, the referrer or both. A two-sided example is “Give a friend 10% off; receive EUR 10 after their qualifying purchase.” These are example terms, not a recommended universal amount.

Compare the combined friend discount, referrer reward, fees, administration, fraud and returns with incremental contribution from referred buyers. Another channel’s acquisition cost is useful context, but being cheaper than an unprofitable channel is not enough.

Choose between a future voucher, wallet reward, gift, cash payment or a tiered reward. Cash is an immediate outflow; a future voucher affects a later purchase when redeemed. Both have costs. Neither guarantees better retention.

Apply the friend’s eligible first-purchase discount in the cart or during checkout, before the order is placed. Release the referrer’s reward later, after the qualifying paid-order, cancellation, return and delay checks. A discount cannot normally reduce the first checkout only after that same order is validated.

Worked scenario: a manual referral pilot

Anna wants to refer a friend. You can test the process without promising link tracking or an account dashboard:

1. Set a pilot reward budget and participation limit. Under Catalog > Discounts > Cart Rules, issue a distinct referral code, record Anna as its owner and configure the friend's benefit, dates, usage and basket conditions.
2. Check the friend's eligibility before checkout. A per-customer usage limit does not establish that this is their first purchase. If you cannot enforce that condition automatically, approve the friend manually and record any separate customer-restricted voucher's identifier against Anna in your referral register.
3. After purchase, match the redeemed cart-rule identifier to the referral register and record the customer, order, referrer and pending reward. Code use establishes attribution to the code, rather than proving a personal recommendation.
4. After the agreed paid-order, delivery-delay and return checks, issue Anna's customer-restricted reward and record its cart-rule identifier, value and expiry. Mark the qualifying order as processed so another staff member cannot reward it again.
5. Keep the reward linked to the referred order for later refunds and corrections. Reconcile issued and redeemed rewards against your pilot budget before inviting more participants.

Choose automation based on order volume and review workload. Move from manual processing when reconciliation and review can no longer be completed reliably.

Specify attribution and the customer journey

1. Give each referrer a unique link or code, such as ?ref=abc123 or REF-ANNA-7F3.
2. Define first-touch or last-touch precedence, the attribution window and whether an entered code overrides a saved referral.
3. Define handling for guest checkout, account creation, returning buyers, another device, deleted cookies and consent requirements. A link alone does not guarantee later attribution.
4. Confirm the landing page explains the friend’s benefit and shows whether it is applied automatically or requires a code.
5. Keep attribution attached to the qualifying customer/order, then process each reward once using a durable event or order key.
6. Expose accurate pending, approved and redeemed rewards in the referrer’s account if the implementation supports them.

A 30-day attribution window or 90-day voucher life can be an example policy. Choose and publish the window and expiry for your own implementation. Test that redirects, campaign parameters and canonical handling preserve the actual referral token. Use an attribution implementation that reads and retains the referral token.

Make sharing practical with a copyable link, an editable suggested message and relevant sharing buttons. Do not send messages to a customer’s contacts without an authorised process. Ask first-time buyers after delivery and use; experienced returning customers can have a different invitation point.

Test a purchase without a browser return, a repeated payment notification, a cancelled order and a partial refund. Release rewards from qualifying purchases, rather than click counts.

Separate native voucher restrictions from abuse controls

Native cart rules provide customer restrictions, spend thresholds, dates, usage limits, product conditions and compatibility rules. They do not by themselves implement a general first-order-only referral engine, payment/address/IP matching or referral-graph checks.

• Prevent self-referral and repeated rewards for the same qualifying purchase.
• Validate first-purchase eligibility against the relevant customer and shop-sharing scope.
• Review duplicate identity, address, payment or network signals proportionately. Shared households and networks can be legitimate.
• Set reward caps and detect circular referrals or public coupon-code distribution where that breaches your terms.
• Keep an audit trail, a correction process and appropriate access/retention controls for fraud signals.

Verify which safeguards the chosen module implements. A manual voucher process needs manual attribution and review. A wallet or external reward provider needs its own reversal and reconciliation process rather than assumptions about cart rules.

Measure retention, redemptions and referral cost consistently

For a stated observation window, define repeat-purchase rate as purchasing customers with more than one eligible order divided by all purchasing customers. Report returning-order share separately. New registrations are not new purchasing customers, and an immature cohort has had less time to repeat.

This read-only example uses shop 1, a fixed period and valid = 1 as its explicitly limited eligibility rule. Replace that rule with your paid/refund policy for production reporting and use your actual table prefix.

SELECT COUNT(*) AS purchasing_customers,
       SUM(order_count > 1) AS repeat_customers,
       100.0 * SUM(order_count > 1)
         / NULLIF(COUNT(*), 0) AS repeat_purchase_rate_pct
FROM (
  SELECT id_customer, COUNT(*) AS order_count
  FROM ps_orders
  WHERE id_shop = 1 AND valid = 1
    AND date_add >= '2025-10-26 00:00:00'
    AND date_add < '2026-10-26 00:00:00'
  GROUP BY id_customer
) eligible_customers;

Use the same window and qualification rules for reports, tiers and experiments. Normalise spending to one reporting currency using historical order conversion information before summing; decide whether the basis includes tax, shipping, refunds and partial refunds. Scope shops or shared customers explicitly. The native Customers grid’s Sales amount is not an order-count column.

• Retention: time from first to second purchase, eligible orders per purchasing customer, average order value and cohort repeat rate.
• Rewards: earned/pending liability, vouchers issued, distributed and redeemed, discount value and remaining balances.
• Referrals: participating referrers, referred visits, attributed qualifying customers, reward/operating cost per acquired customer and subsequent contribution.
• Incrementality: compare eligible randomly held-out customers where feasible, allowing for returns and the normal repurchase cycle.

The cart-rule list’s Quantity is remaining availability, not a complete redemption report. Count actual uses from order-to-cart-rule records and track distribution separately. Financial aggregate reports do not automatically supply acquisition-channel attribution; join attributed orders and allocated costs in a suitable report.

Worked scenario: more repeat orders, less contribution

Compare customers whose first qualifying purchase falls in the same period, separating those offered the reward from a comparable group without it. Give each cohort the same follow-up opportunity. If the rewarded cohort orders more often, check whether discounts, subsidised delivery, returns and messaging costs leave more contribution per acquired customer. More repeat revenue with less contribution is a reason to revise the offer, even when redemption looks healthy.

Do not make the comparison only between customers who redeemed and those who did not: the decision to redeem selects a different group. Record eligibility and offer assignment before the result, and retain the cohort definition so the next report uses the same basis.

Avoid a universal 30-day or 200-order judgment rule. Required observation depends on purchase cycle, cohort maturity, baseline rates and the effect you need to detect. Separate observational differences between members and nonmembers from a causal effect of the programme.

Rehearse the change and protect existing rewards

Use this checklist when installing, replacing or materially reconfiguring the implementation. Keeping an existing module also needs a rehearsal when its earning ratio, qualification rules or group handling change.

1. Record the starting position. Export customer identifiers, pending and available points, converted rewards, unused vouchers, expiry dates and tier assignments. Keep reward-wallet entries and trade-credit balances separate. Include shop and currency context, plus the terms under which existing rewards were earned.
2. Control outgoing work on staging. Redirect or disable reward emails, marketing exports, scheduled jobs and payment callbacks that could affect live customers. Use test identities to demonstrate the journey without sending real referral invitations.
3. Agree the mapping. Decide which system owns each balance and whether existing vouchers will remain redeemable or be replaced. Check customer and order identifiers, rounding and expiry. Do not let both implementations award the same purchase or count historic purchases again unintentionally.
4. Reconcile representative records. Include a pending purchase, a converted but unused reward, a redeemed reward, a partial refund, a guest referral and a customer with an existing wholesale group. Compare the result with the starting record and the written policy, including default-group pricing.
5. Exercise display and integrations. Check the real theme on mobile, the customer-account link, product and cart messages, checkout redemption and email wording. If an account link disappears, check whether the theme renders the relevant module hook, such as displayCustomerAccount, before assuming the balance has been lost.
6. Plan the live switch. Name the person controlling reward writes during cutover, reconcile changes since the staging snapshot, and enable only the intended earning process. Record how to restore the previous configuration while preserving rewards already issued or spent after launch.

Common failures and the first evidence to inspect

What to ask your developer or agency

• Which installed releases, theme, checkout, shops and currencies were tested, and where are the results?
• Which event earns, releases, converts and reverses each reward, and what prevents repeated processing?
• How are old balances, vouchers, expiry dates and wholesale memberships preserved through the switch?
• Which first-purchase, attribution and abuse checks are implemented, and which still require staff review?
• Where can staff trace an order to its reward, correct an exception and find the person responsible for reconciliation?

If no existing integration meets the agreed rules, the PrestaShop Custom Module Development Service can turn that lifecycle and its acceptance checks into a written development scope.

Questions owners ask

Do I need a points programme to retain customers?

No. If the repeat-purchase problem is unreliable delivery, poor support or inconvenient reordering, fix that first. A personal thank-you or a simple tier can be sufficient when your team can administer it reliably.

Can I keep rewards customers have already earned?

Make that an acceptance condition before changing systems. Reconcile points, vouchers and balances separately, test their expiry and redemption, and agree how unused rewards will be honoured.

Why is a customer in Gold but receiving no Gold discount?

Check their default group and the applicable price rules. Membership alone does not select the blanket reduction, and the final price needs a test with that customer's basket.

Can I start referrals with cart rules alone?

Yes, if you can handle code ownership, eligibility, delayed rewards and returns manually. Set the pilot limit from your review capacity; cart rules alone do not supply automatic first-purchase checks or link attribution.

Does a higher repeat-purchase rate prove the rewards pay?

No. Compare contribution after reward and operating costs over the same follow-up window, allowing for refunds. A cohort that would have returned anyway can redeem many vouchers without making the programme profitable.