Selling out-of-stock products on Magento or Adobe Commerce comes in two shapes merchants constantly conflate. A backorder is an existing product you are temporarily out of and will ship when it arrives. A pre-order is a product not yet released that customers reserve ahead of launch. Native Magento handles backorders with a setting and has no real pre-order feature.
Pre-order and backorder are different problems
The words get used interchangeably, but the workflows diverge in ways that matter for inventory, payment, and customer expectations.
A backorder is for a product that normally exists in your catalog and is momentarily at zero stock. The customer orders it now, and you ship it as soon as your next replenishment lands. The expected wait is usually short and often uncertain, measured against a purchase order you already placed with a supplier.
A pre-order is for a product that has not launched yet. The customer is reserving a unit ahead of a known release or restock date. The wait is longer, the date is usually firm, and the commercial intent is different: you are gauging demand and capturing revenue before inventory exists, sometimes with a deposit rather than full payment.
Those differences drive real design decisions. A backorder can usually charge and confirm like a normal order. A pre-order often needs a distinct product label, an advertised availability date, a separate confirmation email, and sometimes deferred or partial payment. Native Magento covers the first case with a setting and does nothing purpose-built for the second. The same split exists on Shopify, Shopware, and BigCommerce, where pre-order is almost always an app rather than a core capability, and on Magento and Adobe Commerce it is an extension plus storefront work on Hyva.
What native Magento actually gives you
Native Magento has a backorder setting and no pre-order concept. Knowing exactly where the line falls saves you from buying an extension you do not need, or skipping one you do.
Backorders are configured under Stores, Configuration, Catalog, Inventory, in Product Stock Options. The Backorders field has three values:
- No Backorders: the default. Once salable quantity hits zero, the product is out of stock and cannot be ordered.
- Allow Qty Below 0: customers can keep ordering after stock reaches zero; salable quantity goes negative and you fulfill when replenished.
- Allow Qty Below 0 and Notify Customer: the same, but the storefront shows a backorder notice so the buyer knows the item is not in stock.
You can set this globally and override it per product, which is the right pattern; you rarely want every SKU backorderable. That is the whole native feature. There is no advertised ship-back date, no pre-order badge, no deposit handling, no separate pre-order transactional email, and no distinction between “temporarily out” and “not yet released.” For a store that just needs to keep taking orders on a fast-moving SKU between shipments, the native setting is enough. For anything resembling a real pre-order campaign, it is not.
The reservation trap that turns backorders into oversells
Here is the part most guides skip, and it is the one that costs money. Magento’s Multi-Source Inventory tracks a reservation for every order, decrementing salable quantity at order placement so two customers cannot buy the last unit. Backorders deliberately let salable quantity go negative, which means you are now operating the reservation system in exactly the mode where drift is most damaging.
If reservations fall out of sync, through a legacy extension writing stock directly, a manual database edit, or a partially failed order, a backorderable product can accept far more orders than you can fulfill in a reasonable window. The customer is promised a short wait and gets a long one, or a cancellation. This is not a reason to avoid backorders; it is a reason to keep reservation health under active watch when you enable them. Bemeir’s deep dive on Adobe Commerce inventory reservations explains how salable quantity is really calculated and how to detect and fix drift, and it should be required reading before you turn backorders on across a large catalog.
Multi-source stores add another layer: a global backorder flag does not know which source is short. Source-level backorder control (available through extensions such as the Wyomind approach) lets you allow backorders from one warehouse while blocking them at another, which matters when your fulfillment logic routes by location. How stock displays across those sources is its own storefront problem, covered in Bemeir’s guide to multi-source inventory on a Hyva storefront.
Native backorders versus a pre-order extension
When you outgrow the native setting, a pre-order or backorder extension (Amasty, Mageworx, Webkul, BSS, and FME all ship one) adds the campaign features native Magento lacks. The table shows what you gain.
| Capability | Native backorders | Pre-order or backorder extension |
|---|---|---|
| Keep selling at zero stock | Yes | Yes |
| Distinct pre-order state and label | No | Yes |
| Advertised availability or ship date | No | Yes |
| Custom add-to-cart button text | No | Yes |
| Deposit or partial payment | No | Often |
| Separate pre-order confirmation email | No | Usually |
| Per-source backorder control (MSI) | Limited | Yes (some) |
| Coming-soon before stock exists | No | Yes |
The honest read: if you only need to keep an order flowing on a temporarily empty SKU, the native setting is free and sufficient. The moment you want to advertise a launch date, take deposits, label products as pre-order, or send buyers a different message, you need an extension, and you need to confirm it is Hyva-compatible.
Fulfillment is where the promise is kept or broken
Selling the out-of-stock unit is easy. Delivering on the implied promise is the hard part, and three fulfillment decisions decide whether the customer forgives the wait.
Expected ship dates. A backorder with no date is a support ticket waiting to happen. Even an approximate window, tied to your supplier purchase order, sets expectations and cuts “where is my order” contacts. Pre-orders should carry a firm date and update it if the launch slips.
Mixed carts. When a cart holds one in-stock item and one backordered item, you must decide: ship the available item now and the rest later (a split shipment, with its extra shipping cost), or hold the whole order until everything is ready. There is no universally right answer, but there is a wrong one, which is not deciding and letting the behavior be accidental. This choice touches your carrier setup, your warehouse, and any third-party logistics provider; if you route fulfillment through a 3PL, the split-shipment rule has to be modeled in that integration, which Bemeir covers in its guide to connecting a 3PL to Magento and Hyva.
Payment timing. Charging in full for a product that ships in eight weeks raises chargeback and expectation risk, and in some jurisdictions, consumer-protection considerations. A deposit model or authorize-now-capture-on-ship pattern is cleaner for long-dated pre-orders, and it is exactly the kind of thing native Magento will not do for you.
The storefront work Hyva changes
Every backorder and pre-order decision eventually shows up on the product page, and on Hyva that is a rendering job rather than a Luma widget you drop in. Four surfaces need attention.
The stock status label is the first. On Hyva, whether a product shows “In stock,” “Backorder,” “Pre-order,” or “Coming soon” is driven by salable quantity and your extension’s state, rendered through the theme with inline Alpine.js. The add-to-cart button is the second: a pre-order should say so, so the buyer is never surprised at checkout. The availability date is the third, and it should be visible on the product page and carried into the cart and confirmation. The fourth is configurable products, where one variant may be in stock and another backordered; the storefront must reflect per-variant status as the shopper switches options, which means wiring stock state into the Alpine component that handles variant selection rather than assuming a single product-level flag.
Get these wrong and you get the worst outcome in ecommerce: a customer who thought they were buying something in stock, discovering at checkout or in the confirmation email that it ships in two months. Get them right and a backorder or pre-order becomes a revenue stream you would otherwise have lost to an out-of-stock page.
Pre-orders and backorders for B2B
For wholesale accounts the calculus shifts. B2B buyers are often more tolerant of lead times because they plan around replenishment cycles, which makes backorders and scheduled pre-buys genuinely useful rather than a last resort. A dealer reordering a staple SKU would usually rather place a backorder than see an out-of-stock page and buy elsewhere. This pairs naturally with requisition lists, negotiated lead times, and the company-account structure a B2B store already runs, and it is worth scoping backorder behavior deliberately for wholesale customer groups rather than inheriting the consumer setting. Designing that as one coherent system across the storefront, inventory, and fulfillment is the kind of work Bemeir does as a Magento and Adobe Commerce agency, drawing on the inventory and fulfillment vendors in its technology partner ecosystem. More on the team and its B2B focus is on the About Bemeir page, and on its Hyva work as the first US Hyva development Gold Partner.
FAQ
How do I allow backorders in Magento 2?
Go to Stores, Configuration, Catalog, Inventory, and under Product Stock Options set Backorders to either “Allow Qty Below 0” or “Allow Qty Below 0 and Notify Customer.” The notify option shows a backorder message on the storefront so customers know the item is not in stock. You can set this globally and override it per product, which is the recommended approach since you rarely want every SKU backorderable.
What is the difference between a pre-order and a backorder?
A backorder is for a product that normally exists but is temporarily out of stock; the customer orders now and you ship on your next replenishment. A pre-order is for a product not yet released; the customer reserves a unit ahead of a known launch date. Backorders usually charge and confirm like normal orders, while pre-orders often need a launch date, a distinct label, a separate email, and sometimes a deposit.
Does native Magento support pre-orders?
Not really. Native Magento supports backorders through a configuration setting, but it has no purpose-built pre-order feature: no advertised availability date, no pre-order label or button text, no deposit or partial-payment handling, and no separate pre-order email. For a genuine pre-order campaign you need an extension, and you need to confirm it is compatible with your Hyva theme.
Can backorders cause overselling?
Yes, if inventory reservations drift out of sync. Backorders deliberately let salable quantity go negative, so any reservation inconsistency, from a legacy extension writing stock directly, a manual database change, or a failed order, can let a product accept more orders than you can fulfill promptly. Keep reservation health monitored when backorders are enabled, especially on large or multi-source catalogs.
How should backorders and pre-orders display on a Hyva storefront?
On Hyva, stock status, the add-to-cart button text, and the availability date are rendered through the theme with inline Alpine.js rather than a Luma widget. The product page should clearly label a backorder or pre-order, show the expected date, and reflect per-variant status on configurable products as the shopper switches options, so no one reaches checkout thinking an out-of-stock item is in stock.
The bottom line
Backorders are a native setting; pre-orders are an extension plus real storefront and fulfillment design. The revenue is real, an out-of-stock page is a lost sale, but the risk is equally real: oversells from reservation drift, and customers who feel misled about when their order ships. Decide your mixed-cart and payment rules on purpose, watch reservation health when salable quantity can go negative, and build the Hyva product page so the availability promise is unmistakable before the buyer commits.
