Stock Reservation in E-commerce — Why It Matters

A customer drops the last unit into their cart and heads to checkout — and at that exact moment someone else buys it in another channel. Who’s right? Which of them gets the item, and which one hears “sorry, we just ran out”? The answer to that question comes from stock reservation — the mechanism that decides whose unit is whose before the parcel ever leaves the warehouse.

In this guide we break reservation down to its parts: what it actually is, when to place it, how it works step by step, and which pitfalls (timeouts, abandoned carts, stuck reservations) can quietly break it. This isn’t another overselling article — here we focus on the mechanism that stops overselling behind the scenes.

What stock reservation is

A reservation is a temporary hold on a unit for a specific order or cart, before the goods physically leave the warehouse. The reserved unit still sits on the shelf, but the system stops offering it to anyone else — it’s “promised” to someone who is mid-purchase.

The whole mechanism boils down to one equation worth memorizing:

Available stock = physical stock − reserved stock

That distinction is the heart of it. You have 10 units on the shelf, 3 are reserved against open orders — so you offer 7 for sale, not 10. Without that split the system would offer all 10, even though 3 are already promised to someone. Exactly this gap between “what’s in the warehouse” and “what I can still sell” is what protects you from overselling.

When to place the reservation

The most important design decision is when the unit drops out of the available pool. There are three typical moments, each with a different trade-off:

1. On add-to-cart — safest for the customer finishing the purchase, but risky: most carts are abandoned, so you’d lock up goods for people who never pay. Requires a short timeout (see below).
2. On order placement — the sweet spot. The unit drops the moment the order is confirmed, before shipping. It closes the “sold but not yet shipped” window without locking goods for mere browsers.
3. On payment capture — most cautious for the seller (you only reserve what’s paid), but it leaves a gap: between placement and payment, someone else can buy the same unit.

For most multichannel stores the sensible default is reservation on order placement, optionally a short cart reservation for scarce goods (tickets, limited editions, last units on promotion). The timing choice isn’t a detail — it determines how wide the double-sell window is.

How reservation works step by step

Let’s trace the full life cycle of a single unit from order to shipment:

1. An order arrives for a given product/variant (from Allegro, your store, any channel).
2. The system checks available stock (physical minus already reserved). If a unit is there, it places a reservation; if not, the order goes to backorder or is rejected.
3. A reservation record is created: which variant, how many units, for which order, a timestamp, status “active”.
4. Available stock drops by the reserved quantity, and that new, lower number is what the other channels see. The unit still physically sits in the warehouse.
5. Picking and packing — a warehouse worker pulls the goods. The reservation still protects them, so nobody can “outbid” for them in the meantime.
6. Shipment — at dispatch the reservation closes out: physical stock drops for real, and the reservation record is settled (consumed). The equation balances again.

The whole point lives in steps 3–5: throughout the time between “customer bought” and “parcel left”, the unit is invisible to other buyers, even though it hasn’t physically shipped yet. That’s the piece that eliminates the most common overselling window — we covered it more broadly in the guide on how to avoid selling products you don’t have in stock.

Pitfall one: abandoned carts and timeouts

If you reserve at the cart stage, you hit a classic problem: 7 out of 10 carts never turn into a purchase. If every reservation held goods indefinitely, your store would soon show “out of stock” despite a full warehouse — because all your stock would be hanging in dead carts.

The rescue is a reservation timeout — a validity period after which a held unit automatically returns to the available pool:

• Short cart hold — typically 10–30 minutes. Enough to finish payment, and an abandoned cart frees the goods almost immediately.
• Unpaid order — a longer timeout (e.g. 24–72 h, depending on payment method), after which the reservation expires if payment hasn’t arrived.
• Automatic release — crucially, expiry must work on its own, in the background. You can’t rely on someone manually “cleaning up” abandoned reservations.

Without timeouts, reservation turns from a tool that protects stock into one that artificially suppresses it — and you lose sales on goods you actually have.

Pitfall two: stuck reservations and stock drift

The second family of problems is reservations that got stuck — neither consumed (by shipment) nor released (by timeout). Where they come from:

• A cancelled order where nobody released the reservation — the unit hangs locked “in a vacuum”.
• A return or complaint — goods come back to the warehouse, but reserved stock wasn’t settled correctly.
• An integration error or connection timeout mid-reservation — a half-created order, uncertain stock.
• Duplicate events — the same sale counted twice by a repeated webhook or retried request.

The effect is always the same: reserved stock grows above the real figure, and available stock drops artificially. That’s why reservations need hygiene: automatic release on cancellation, correct settlement of returns, resilience to repeated events (idempotency), and periodic reconciliation — comparing the sum of reservations against open orders to catch “orphaned” records. If you’re only just laying the warehouse foundations, start with simple, orderly records — we described it in the piece on a simple warehouse system for an online store.

Reservation, multichannel and variants

Reservation only makes full sense with one shared stock across all channels. If Allegro counts its own units and your store counts its own, a reservation in one place won’t stop a sale in the other. So the foundation is central stock and consistent SKUs as a shared key — the same product and variant code on every side.

Two things that are easy to forget:

• Reserve at the variant level, not the product level. Size M hitting zero can’t leave an offer reading “product available”. Each variant has its own stock and its own reservation pool.
• Propagate the new available stock to all channels as fast as possible. Reservation lowers the number at the source, but the other channels have to learn about it before they sell the unit again — hence the value of frequent, ideally event-driven synchronization.

In practice, Sellaro pulls products and variants from all connected channels (PrestaShop, Sylius, WooCommerce; more added on request) into a shared inventory view, and the automation engine runs on domain events in a WHEN→IF→THEN model — so a stock decrease can immediately trigger an action (email/SMS notification, webhook, log entry). Integrations are read-only — Sellaro writes nothing back to the store.

Frequently asked questions

How does reservation differ from deducting stock?

A reservation is a temporary hold — the unit still sits in the warehouse, it just stops being offered to others. The stock deduction happens later, at shipment, when the goods actually leave. Reservation fills exactly the gap between “bought” and “shipped”.

Is reserving on add-to-cart a good idea?

It can help for scarce goods, but there’s a catch: most carts are abandoned, so without a short timeout (10–30 min) you’ll lock up stock for people who never pay. For most stores, reservation on order placement is the safer default.

What happens to a reservation if the customer doesn’t pay?

It should expire automatically after the set timeout and release the unit back to the available pool. It’s essential this happens on its own, in the background — otherwise unpaid orders suppress your available stock indefinitely.

Is reservation needed with a single sales channel?

Yes, though it’s less critical. Even in a single store, the window between order placement and shipment lets you sell the same unit twice under heavier traffic. With multichannel selling, reservation stops being optional and becomes a necessity.

Summary

Stock reservation is a temporary hold on a unit for an order before it leaves the warehouse — a mechanism that enforces a simple but crucial equation: available = physical − reserved. Well-designed reservation settles who gets the last unit, closes the “sold but not shipped” window, and protects against overselling. To work, it needs three things: the right timing for placing it, timeouts that free abandoned carts, and hygiene that catches stuck and orphaned reservations. And on top — one shared stock and consistent SKUs, so the reservation applies across every channel at once.

Want to run shared stock and see reservation-aware availability in one place? Calculate your cost with Sellaro — we’ll add a missing integration for free as part of your plan.