Recurring & Scheduled Orders — PrestaShop 8 & 9 Documentation

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.

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.

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.
• Theme icon set — the icons shown in the customer account. The PrestaShop Classic theme uses Material Icons, while many commercial themes load FontAwesome instead. Pick the one your theme actually loads, or no icon at all. An icon that shows up as a stray word in the customer account simply means this setting does not match your theme.
• Products excluded from scheduled orders — a comma-separated list of product ids. These products are never copied into a schedule, and never added to a rebuilt cart. See the section on gifts and cart rules.

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.

Emails and payment link

• 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.

Offering recurrence during checkout

By default the customer schedules an order after the fact, from an order already placed. Two optional features let you offer recurrence earlier, at the moment of purchase. Both are disabled on install: enabling them is a decision, not a side effect of an update.

Checkout option

A “Turn this purchase into a recurring order” checkbox appears on the cart page and at the top of the payment step, followed by a frequency selector listing only the frequencies you have enabled. The customer ticks it, picks a rhythm, and carries on with the order as usual.

The choice is stored against the cart, not in the session. That matters with payment methods that redirect the customer to an external page: the order is often validated in a payment callback where the customer session no longer exists, and a choice held in session would be lost without any warning.

The schedule is only created once the order has been validated. Addresses, carrier and currency therefore come from a real order, and a payment retry cannot produce two schedules. The first due date is computed from the order date, according to the chosen frequency.

Product page notice

A short notice tells the visitor the product can be ordered on a recurring basis and explains the principle in two plain sentences. Products on the exclusion list never show it.

If nothing shows up

Both displays rely on standard PrestaShop attachment points. Some themes, and most one-page checkout modules, do not provide all of them. The module configuration page lists those attachment points with their status and offers a button to register them again. If one stays inactive after that, your theme or checkout module simply does not expose it.

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.

How the payment link works

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.

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.

Gifts and cart rules

A product given away by a cart rule is never copied into the schedule. That is deliberate: the gift was not chosen by the customer, and the cart rule adds it on its own every time the cart is rebuilt and the conditions are met. Keeping it in the schedule would put it in the cart twice.

The gift therefore keeps being granted normally at each due date, and it follows the current state of your rule: change the threshold or the gift product, and scheduled orders reflect it immediately.

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, each in an HTML and a plain text version, in seven languages: French, English, Spanish, Italian, Portuguese, German and Polish:

• 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.

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 link shows “Invalid link”

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.