Backorder
Selling an existing item while it is temporarily out of stock, then shipping the order when replenishment arrives.
See it
What it is
A backorder lets someone buy an existing product while its available stock is temporarily at zero, with fulfillment waiting for replenishment. That is the distinction from a preorder: a preorder is sold before its first normal availability or release, while a backorder fills a gap after the product has already been selling.
Reach for it when replenishment is credible, demand is worth capturing, and customers will accept the wait. Put the expected ship window on the product page, cart, checkout, receipt, and order status page. If the date is too uncertain to state, a back-in-stock notification is often the more honest choice.
Gotcha: new stock has to be allocated in a declared order. Without a queue, later orders can consume a restock before earlier backorders do. Use first in, first out unless the business explicitly promises another priority, and contact customers before a date slips. Mixed carts need a visible choice between waiting for one shipment and splitting the ready items out.
Ask AI for it
Add backorder support at the SKU and location level. When available to sell reaches zero, allow checkout only for SKUs with backorder_enabled and a dated replenishment record, label the button 'Backorder', and show the expected ship window on the product page, cart, checkout, and receipt. Store backordered quantity separately from on-hand inventory. When stock arrives, allocate it first in, first out by accepted-order timestamp inside a PostgreSQL transaction using `SELECT ... FOR UPDATE` so two workers cannot assign the same units. For mixed carts, offer ship-together and split-shipment choices with their costs. Stop accepting new backorders when the incoming quantity is fully allocated, and queue a customer notice before any promised date changes.