An out-of-stock product on a PrestaShop store has exactly two outcomes: the customer leaves, or the customer orders it anyway. The second only happens if you've told PrestaShop to allow it, and told the customer what they're actually buying. That's the whole job here. Pre-orders and backorders aren't a marketing idea you bolt on; they're a specific configuration on the Quantities tab of a product, plus a discipline about payment timing and communication that keeps the orders from turning into refunds and chargebacks later.
Last updated: June 2026.
This guide is narrowly about selling before you have stock in PrestaShop: the difference between a pre-order and a backorder, the exact back-office settings that switch it on, where PrestaShop's native support stops, and how to keep payment and fulfilment from becoming a mess. It is not about whether to show out-of-stock products at all, that's a separate decision covered in Out of Stock: To Hide or Not to Hide?, nor about when to reorder, which has its own formulas in When to Reorder Stock.
Pre-order vs backorder: same setting, different promise
Here's the part that confuses most merchants: PrestaShop has no toggle labelled "pre-order" and none labelled "backorder." Both run on the same underlying mechanism. "Allow ordering when out of stock." The difference is entirely in the promise you make to the customer, and that promise changes how you label the product, when you charge, and how you handle a delay.
| Pre-order | Backorder | |
|---|---|---|
| Stock history | Never been in stock, product not yet released | Was in stock, temporarily sold out, restock expected |
| Customer mindset | "I'm ordering early to guarantee I get it" | "I want this exact product and I'll wait" |
| Typical use | Launches, seasonal lines, limited editions | Bestsellers between shipments, slow-moving catalogue parts, supplier delays |
| Date you show | Release / availability date | Restock / "ships in X" estimate |
| Payment instinct | Often full upfront (commitment + cash to fund production) | Full upfront acceptable; the wait is usually shorter |
Grouping them under one generic "out of stock. Order anyway" label is where trust leaks. A customer who pre-ordered a not-yet-released item expects a wait; a customer who backordered their usual restock part does not, and if the page didn't make that clear, the second one opens a "where is my order?" ticket within 48 hours.
The native PrestaShop setting that switches it on
Selling out-of-stock products in PrestaShop is governed at two levels: a global default and a per-product override. You almost always want the global default OFF and the override ON for the handful of products that genuinely support it.
Global default (rarely the right place to switch it on)
Go to Shop Parameters → Product Settings, scroll to the Stock section, and you'll find "Allow ordering of out-of-stock products". This is the global fallback. Leave it set to deny. Flipping it on store-wide means every product that hits zero quietly keeps selling, including ones you can't actually restock, which is how you end up with orders you can never fulfil.
While you're on that screen, two neighbouring fields matter for pre-orders: the default "Label of in-stock products" and "Label of out-of-stock products with allowed orders". These supply the text the theme shows when you haven't set a per-product label, so the wording your pre-order customers read can be a store-wide default you forgot to edit. Set it to something honest like "Available to pre-order" rather than leaving PrestaShop's stock phrasing.
Per-product: the Quantities tab does the real work
Open the product, go to the Quantities tab, and find "When out of stock". It has three radio options:
- Deny orders, the product becomes unbuyable at zero stock (the default, and correct for most of your catalogue).
- Allow orders. This is the switch that turns a product into a pre-order or backorder. The Add to cart button stays live below zero quantity.
- Use default behavior, inherit the global setting above.
Underneath the technical layer, "Allow orders" writes the value 1 into the out_of_stock column of the ps_stock_available table for that product (Deny = 0, Use default = 2). The live stock figure lives in the quantity column of the same table, managed through the StockAvailable class, useful to know if you ever script bulk changes or audit why a product is or isn't orderable.
So what does this actually buy you? One radio button is the difference between an out-of-stock page that loses the sale and one that captures it. But the button alone makes a silent promise you haven't explained. Which is why the next two fields matter as much as the toggle.
Availability date and the per-product label
Still on the Quantities tab, set the Availability date field to your expected release or restock date, this writes to the product's available_date field and, in most themes, renders on the front office as "Availability date: …". This is your pre-order delivery estimate, shown before the customer commits.
Directly below, the "Label when out of stock (and backorders allowed)" field overrides the global text for this one product. Use it to set the promise precisely: "Pre-order, ships from March 15" for a launch, or "Backorder, next shipment in 2–3 weeks" for a restock. This single field is the cheapest insurance you have against confusion, because it's the exact text the customer reads next to the buy button.
Where PrestaShop's native support stops
The native mechanism is solid for the basics, but it's honest to name its limits before you build a campaign on it:
- It doesn't change the button text. Out of the box, the Add to cart button still says "Add to cart," not "Pre-order now." The label field above changes the stock message, but turning the button itself into a "Pre-Order" call to action means a theme template edit (the product page's add-to-cart block) or a module.
- It can't take a deposit. Native checkout charges the full cart total or nothing. There is no built-in partial-payment / deposit flow for "10% now, balance on shipping."
- It doesn't cap pre-order quantity. "Allow orders" lets the product sell into negative stock without limit, so a 500-unit limited edition can quietly take 800 orders unless you watch it.
- It treats mixed carts as one order. An in-stock item and a pre-order item land in the same order with one delivery, PrestaShop won't split them for you.
- Advanced stock management is gone. The old PS_ADVANCED_STOCK_MANAGEMENT warehouse/supplier system was deprecated and removed from the core in 1.7+; if you relied on it for supplier-order tracking behind backorders, that workflow now lives in third-party modules, not the core.
None of these is a dealbreaker for a small pre-order run, full payment upfront, a watchful eye on volume, and a clear label will carry you. They become real once pre-orders are a regular part of your business, at which point a dedicated module earns its place.
Payment timing: the decision that creates or kills the cash-flow win
When you charge is the single most consequential choice, because it sets your cash flow, your chargeback exposure, and your legal footing all at once. There are three models.
| Model | Cash flow | Chargeback / cancel risk | PrestaShop effort | Best for |
|---|---|---|---|---|
| Full payment at order | Immediate, funds the supplier order | Higher: long waits invite chargebacks; paid customers cancel less | None, native checkout | Most stores, shorter waits |
| Charge at shipping | None until you ship | Lower chargebacks; higher cancellations (no commitment); card may expire | High. Needs auth-and-capture handling your gateway/module supports | Long pre-orders where trust is fragile |
| Deposit + balance | Partial now, rest at shipping | Commitment without full-prepay resentment; deposit covers admin if they cancel | Highest. No native support, needs a module or custom flow | High-value items (roughly €500+) |
For most PrestaShop stores, full payment at order time is the practical default. It rides the native checkout, gives you cash to actually place the supplier order, and paying customers rarely cancel. The price of that simplicity is that you must be transparent about the timeline and refund fast if you can't deliver. The deposit model is genuinely better for anxious-making high-ticket items, but be honest that it isn't a setting, it's a build.
Customer communication: where these strategies actually fail
Pre-order and backorder strategies almost never fail on the mechanics, the toggle works. They fail on silence. Customers will wait patiently; they will not tolerate being surprised. Two of these touchpoints deserve specific PrestaShop notes.
- At the point of purchase: the label field carries the date and the "this is a pre-order" framing. If a cart mixes in-stock and pre-order items, the customer needs to see which ships now and which later, native PrestaShop won't flag this, so it's a template or module job.
- Order confirmation: the default order_conf email says nothing about a wait. Edit that mail template (under International → Translations → Email translations, or per-language mail files) to restate "this is a pre-order, expected [date]". Otherwise the first thing your pre-order customer reads is a standard "your order is confirmed" with no mention of the delay they agreed to.
- Status updates and delays: notify the moment you learn of a slip, not when the original date passes. Explain why, give a new date, and offer a no-questions cancellation. A custom order status (e.g. "Pre-order. Awaiting stock") makes these orders filterable in the back office so they don't get lost in the normal flow.
That custom-status idea is worth doing properly rather than ad hoc. Building and automating order states is its own topic, covered in Order Status Workflow in PrestaShop. And if you change a delivery date and need to re-send the updated confirmation, that small courtesy is exactly the feature in Resending Order Confirmations.
Fulfilment traps the toggle doesn't warn you about
Mixed orders
A customer buys one in-stock item and one pre-order item. PrestaShop hands you a single order with one delivery, and you choose how to resolve it:
- Ship separately, in-stock now, pre-order later. Best experience, doubles shipping cost. In PrestaShop, depending on your setup, you can partially mark products as shipped/delivered or issue a partial delivery slip; cleanly splitting one order into two independent fulfilments usually needs order editing or a split-order module.
- Hold everything, wait for all items, ship once. Saves shipping, delays the in-stock item and frustrates the customer.
- Prevent mixing. Keep pre-order products in their own catalogue path so carts don't combine. Simplest operationally, clumsiest for the buyer.
For most stores shipping separately wins, the satisfaction gain outweighs the extra postage. The mechanics of splitting and editing such orders are exactly what Order Editing and the broader Order Management workflows are about.
Overselling a limited run
Because "Allow orders" sells into negative stock without a ceiling, a 500-unit limited edition can take 800 pre-orders before you notice. Native PrestaShop gives you no per-product backorder cap, so the discipline is manual: monitor the quantity figure going negative, and flip the product back to Deny orders the moment you've sold your supplier's confirmed capacity. If pre-order runs are routine, this is precisely the gap a dedicated module closes with a hard limit.
Legal footing in the EU
Selling before you have stock puts you squarely inside EU consumer law, and the rules are specific enough to get wrong:
- The 14-day right of withdrawal runs from the delivery date, not the order date, so a pre-order doesn't start the clock until the goods arrive.
- The default maximum delivery time is 30 days from the order date unless a longer period was explicitly agreed. Which is exactly why your pre-order page must state the date before purchase, turning a long wait into something the customer agreed to rather than something you owe them.
- If you can't deliver in the agreed time, the customer can set a reasonable further deadline and, failing that, cancel for a full refund.
The practical takeaway loops back to the label field and the confirmation email: the timeline, the payment terms, and the cancellation policy all need to be visible before the customer pays. Transparency isn't just good service here. It's what keeps a 30-day pre-order on the right side of the rules.
Knowing whether it's working
Treat a pre-order programme like any other change, measure it rather than trust a gut feeling. Worth watching:
- Cancellation rate before fulfilment. If more than roughly 15% cancel before you ship, your waits are too long or your communication is too thin.
- Fulfilment accuracy. How often you ship on or before the promised date. Aim high; this is the number that decides whether pre-order customers ever come back.
- "Where is my order?" ticket volume on pre-order lines. A direct read on whether your status updates are landing.
- Repeat purchase rate for pre-order buyers versus the rest. If it's lower, the wait is costing you more than the captured sale was worth.
Pulling those order-level numbers out of PrestaShop for a spreadsheet is its own small task, CSV Exports for Orders and Invoices covers getting the data out cleanly.
Frequently asked questions
What's the difference between a pre-order and a backorder in PrestaShop?
Mechanically, nothing. Both run on the same "allow ordering when out of stock" setting. The difference is the promise you make. A pre-order is for a product that was never in stock yet (a launch, seasonal line, limited edition), where the customer expects to wait. A backorder is for something that was in stock, temporarily sold out, and is being restocked, where the customer expects a shorter wait. Label them differently, because grouping both under a generic "order anyway" message is where trust leaks.
Which exact setting lets customers buy an out-of-stock product?
Open the product, go to the Quantities tab, find "When out of stock", and choose Allow orders. That keeps the Add to cart button live below zero stock. The global fallback lives under Shop Parameters → Product Settings → Stock ("Allow ordering of out-of-stock products"). Leave that set to deny, and switch it on per-product only for the items that genuinely support it. Under the hood, "Allow orders" writes 1 to the out_of_stock column of ps_stock_available.
Does PrestaShop change the "Add to cart" button to "Pre-order" automatically?
No. The button still reads "Add to cart" out of the box. The per-product "Label when out of stock" field changes the stock message (set it to something like "Pre-order, ships from March 15"), but turning the button itself into a "Pre-order" call to action means a theme template edit on the product page's add-to-cart block, or a module.
Can I take a deposit instead of full payment on a pre-order?
Not natively. PrestaShop's checkout charges the full cart total or nothing, there's no built-in partial-payment flow for "10% now, balance on shipping." For most stores full payment upfront is the practical default: it rides the native checkout, funds the supplier order, and paying customers rarely cancel. A deposit model is genuinely better for high-ticket items (roughly €500+) but it's a build, a module or custom flow, not a setting.
How do I stop a limited run from overselling?
"Allow orders" sells into negative stock with no ceiling, so a 500-unit run can quietly take 800 orders. Native PrestaShop has no per-product backorder cap, so the discipline is manual: watch the quantity figure going negative and flip the product back to Deny orders the moment you've sold your confirmed supplier capacity. If pre-order runs are routine, that hard limit is exactly what a dedicated module adds.
When does the EU 14-day return window start on a pre-order?
From the delivery date, not the order date, so a pre-order doesn't start the clock until the goods actually arrive. Separately, the default maximum delivery time is 30 days from the order date unless a longer period was explicitly agreed, which is why your pre-order page must state the availability date before purchase. Showing that estimate up front (the Availability date field, surfaced cleanly with a tool like our estimated delivery display) turns a long wait into something the customer agreed to.
The short version
Selling before you have stock in PrestaShop is one radio button, "When out of stock → Allow orders" on the Quantities tab, wrapped in a discipline the button can't enforce for you. Set the availability date and a per-product label so the promise is explicit, charge full upfront unless you're dealing in high-ticket items, edit the confirmation email so it acknowledges the wait, watch the quantity figure so a limited run doesn't oversell, and keep your timeline on the right side of the EU's 30-day rule. Do that, and a stockout stops being a lost sale and becomes captured revenue, without the refunds and chargebacks that punish stores who flip the toggle and stay silent.