PS PrestaShop Beginner

Recurring & Scheduled Orders — PrestaShop 8 & 9 Documentation

Install, schedule and run recurring orders: from the daily cron to the cart link sent to the customer.

Updated Module version 1.0.0

What the module does

The module lets your customers schedule the repetition of an order from their account: weekly, monthly, quarterly, yearly, or on a free interval expressed in days.

Before each due date, a scheduler emails the customer a secure link. When they click it, their cart is rebuilt at that very moment, and they are redirected to the standard checkout where they pay with the method of their choice.

No automatic charging. The module stores no payment method and triggers no debit. There is no recurring mandate to collect, no card to tokenise and no strong authentication to replay. The customer confirms and pays for every order themselves.

Installation

  1. In the back office, open Modules — Module Manager, then Upload a module.
  2. Drop the supplied ZIP file, or copy the dfrecurringorder folder into your shop’s modules/ directory.
  3. Click Install. Tables, admin tabs and default values are created automatically.
  4. Set up the scheduled task described in the next section. Without it, no reminder email will ever go out.

The module adds an Orders — Recurring orders menu made of three screens: the list of schedules, the sending history and the settings.

Setting up the scheduler

The module needs to be called once a day. A single daily run is enough: the scheduler processes every schedule that has reached its due date in one pass.

By URL

The module settings page shows the exact URL, token included. It looks like this:

https://your-shop.tld/module/dfrecurringorder/cron?token=YOUR_TOKEN

This URL works with the official PrestaShop Cron Tasks module, with an external cron service, or from a server crontab:

0 6 * * * wget -q -O - "https://your-shop.tld/module/dfrecurringorder/cron?token=YOUR_TOKEN"

From the command line

This is the recommended method on a dedicated server: it avoids web server execution timeouts.

0 6 * * * php /path/to/shop/modules/dfrecurringorder/cli/run.php --token=YOUR_TOKEN

The --id_shop=N option restricts the run to a single shop in a multistore context. Without it, every shop is processed.

Checking that it works

The settings page offers a Run the scheduler now button. It triggers an immediate pass and displays a report: schedules processed, emails sent and failures. The URL call returns the same report as JSON.

The token can be regenerated at any time from the settings page. Remember to update your crontab afterwards, otherwise the following calls will be rejected.

Module settings

Customer experience

  • Let customers create their own schedules — displays the “Schedule this order” button on the order detail and confirmation pages. Turn it off if you prefer to create schedules yourself from the back office.
  • Maximum schedules per customer — 0 for unlimited. The default is 20.
  • Minimum interval in days — prevents customers from creating schedules that are too close together.

Available frequencies

Each frequency is enabled or disabled independently: daily, weekly, biweekly, monthly, bimonthly, quarterly, semiannual, annual and custom in days. Only enabled frequencies appear in the customer form.

By default, weekly, biweekly, monthly, bimonthly, quarterly, semiannual and annual are active. Daily and the custom interval are off, as they mostly suit specific B2B cases.

  • Send the email X days before the due date — default value applied to new schedules. Customers can adjust it for their own. Three days is a good starting point: early enough to react, late enough to stay top of mind.
  • Payment link lifetime — in days, 14 by default. Past that point the link shows an expiry message and invites the customer to regenerate one from their account.
  • Skip unavailable products — enabled by default. See the edge cases section.
  • Send a copy to the merchant — useful during the run-in phase to check how emails actually render.

Scheduler

  • Schedules processed per run — 50 by default. Raise it if your daily volume exceeds that limit, or run the cron several times a day.
  • Delete all data on uninstall — off by default. See the Uninstalling section.

Customer side: scheduling an order

The journey always starts from an order already placed, which guarantees that products, address and carrier are consistent.

  1. The customer opens one of their orders from their history, or stays on the confirmation page right after a purchase.
  2. They click Schedule this order.
  3. They adjust quantities if needed. A quantity set to 0 removes the product from the schedule.
  4. They pick a frequency, the date of their next order and, optionally, an end date or a maximum number of orders.
  5. They save. A confirmation email summarises the schedule.

The schedule then appears under My account — My scheduled orders. From that screen the customer can at any time:

  • change the frequency, the date or the quantities;
  • pause and later resume, the next due date being recalculated into the future;
  • delete the schedule permanently;
  • click Order now to trigger their cart immediately without waiting for the due date.

Merchant side: tracking schedules

Recurring orders list

For every schedule it shows the customer, the frequency, the number of products, the next due date, how many emails have been sent, how many orders were actually placed and the status. The orders column is the most useful metric: it tells you how many schedules genuinely turn into revenue.

The detail view of a schedule lets you send the payment link to the customer immediately, which is handy in support when a customer reports not having received their email.

Sending history

Every generated link produces a history row whose status evolves along the journey:

  • Sent — the email has gone out, the link has not been opened yet.
  • Link opened — the customer clicked and a cart was built.
  • Converted into an order — the cart became an order. The order reference is linked automatically.
  • Expired — the lifetime elapsed without an order.
  • Error — sending the email failed. Check the shop email configuration.

On the order page

A panel at the bottom of the order page lists the schedules created from that order, with direct access to their detail.

Understanding this mechanism helps you answer customer questions.

  1. When the email is sent, the module creates no cart. It only generates a 48-character random token, single use and time-stamped.
  2. When the customer clicks, the module checks the token and its expiry date.
  3. If the customer is not logged in, they are redirected to the standard login page then automatically brought back to their link. The link never authenticates the visitor by itself.
  4. Once identified, the cart is built from the schedule, with the prices, promotions, cart rules and stock of the moment.
  5. The customer is redirected to checkout. Clicking the same link again reuses the cart already created, as long as it has not become an order.

Because the cart is built on click rather than on send, it is always correct. A cart pre-generated when the email goes out would be wrong as soon as a price, a promotion or a stock level changed in between.

Edge cases

Product unavailable on the due date

With Skip unavailable products enabled, the product is simply left out and the remaining items stay orderable. The cart is only refused when no product at all is available: the customer then sees a message inviting them to contact you or edit their schedule.

If you disable this option, a stock-out blocks the cart rebuild. That behaviour suits shops whose orders must ship complete or not at all.

Address deleted between two due dates

If the delivery address stored in the schedule has been deleted by the customer, the module falls back to their first available address. The invoice address follows the same logic. The customer can always change the address during checkout.

Month ends

A monthly schedule started on 31 January does not drift. The module clamps the date to the last day of the month when it is shorter: 28 or 29 February, then 31 March. The original day is stored, so it is never lost.

Multistore

Every schedule is bound to the shop it was created on. Emails are sent with that shop’s identity, and the payment link points to its domain.

End of a schedule

A schedule ends automatically when the end date has passed or when the maximum number of orders is reached. It switches to the Finished status and stops sending emails, while remaining visible in the history.

Customising the emails

The module ships two templates, in French and English, each in an HTML and a plain text version:

  • dfro_reminder — the reminder sent before each due date, carrying the payment link.
  • dfro_created — the confirmation sent when a schedule is created.

They can be edited from Design — Theme and Logo — Emails, or directly in the module’s mails/ folder. The variables available in the reminder are: customer first and last name, schedule label and frequency, next order date, product table, estimated total, payment link, management link, link lifetime and shop name.

The total shown in the email is an estimate computed at send time, for information only. The amount actually charged is the one of the cart rebuilt on click. Never present that total as a price commitment.

Troubleshooting

No email is sent

Check in this order: that the scheduled task actually runs, that the token in your crontab matches the one shown in the settings, that at least one active schedule has reached its due date, and that the shop can send emails at all. The Run the scheduler now button isolates the problem quickly: if it sends the emails, the scheduled task is the culprit.

The token does not exist or was truncated by the mail client. Regenerate a link from the schedule detail view in the back office.

The customer loops on the login page

This happens when the link is opened while logged in with an account other than the recipient’s. The customer must log out, then reopen the link.

The rebuilt cart is empty

Every product in the schedule is disabled or out of stock. Check their state in the catalogue, or temporarily disable the skip-unavailable option to make the diagnosis explicit.

Uninstalling

By default, uninstalling keeps the tables and the schedules. A later reinstall therefore recovers all the data. To remove everything, enable the Delete all data on uninstall option before uninstalling the module.

That deletion is permanent and covers the schedules, their product lines and the full sending history. Back up your database before enabling it.

Was this page helpful?

Still stuck? Contact support