How can a shop stop two channels selling its last item?

Define the stock that can actually be promised

A stock screen showing “one available” is only a view at a moment in time. The online checkout and a counter till can both read that view before either writes an order. If each treats the display as a promise, two customers may believe they bought the same unit. The owner first needs a rule for what constitutes sellable stock: a specific variant at a specific location, physically present, undamaged, and not already committed to a customer. A product family total is too broad when sizes, colours or warehouse locations cannot substitute for one another. Shopify's inventory model likewise distinguishes an inventory item, a location, and quantities in different states. That model is useful as a vocabulary even if the shop uses another system.

Write down who may change each quantity. A web shop, point of sale, marketplace connector and warehouse spreadsheet cannot all act as an unquestioned source of truth. If one system owns the available quantity, every sales channel needs a timely way to reserve against it; if a platform owns it, other channels must respect that platform's confirmed result. Keep a record of physical receipts, sales, returns, damage and manual corrections with a reason and operator. A nightly total alone cannot explain a discrepancy. Decide whether a customer cart is merely interest or a time-limited hold. Reserving on every cart view can hide stock indefinitely; reserving only after payment may expose a competing purchase. The chosen moment should be explicit in customer messaging and staff instructions.

Make the final claim an atomic decision

The decisive operation is not reading the number but changing it under a concurrency rule. In a database owned by the retailer, the reservation can update a matching stock row only when sufficient uncommitted quantity remains, within a transaction. Another design locks the row, checks the state, then updates it before committing. PostgreSQL documents that a row lock blocks conflicting writers until the transaction ends; the application still needs to check the updated quantity and handle a failed attempt. The transaction should be short. It should not wait for a customer to type card details while holding a database lock. A successful reservation has its own identifier, order reference, quantity, location and expiry or conversion rule.

For a platform integration, use the platform's concurrency mechanism instead of treating a cached quantity as authoritative. Shopify documents compare-and-swap behaviour for certain inventory mutations: a change based on an expected previous quantity fails when that quantity has become stale. It also distinguishes inventory states, including reserved and safety stock. These are platform capabilities, not a promise that simply enabling an integration will coordinate an independent till. The shop must test what its particular checkout, point of sale and connector do when the previous quantity is stale. If a channel cannot ask for a confirmed reservation, the owner may allocate a separate channel quota or show a conservative availability message. Such a quota needs deliberate transfers and regular reconciliation; it cannot magically increase the shared physical stock.

Follow one last-unit sale through both channels

Consider a shop with one sellable kettle in its Central store and no suitable replacement elsewhere. At 14:00 a customer begins online checkout. At nearly the same time a staff member scans the kettle at the counter. The website's earlier “one left” display is informative, not a guarantee. Both channels request the same stock claim. If the counter receives confirmation first, the online attempt must receive an unavailable result before an irrevocable order confirmation. It should retain the customer's other cart items, explain that the kettle changed availability and offer a back-in-stock request or a different item. The counter receipt then links to the confirmed stock movement. If the web order wins, the till must warn the cashier before taking payment or handing over the item.

Now add a payment delay. A reservation may be created while a payment attempt remains unresolved. The system needs a policy for how long the hold lasts, what confirms it, and what happens if a late payment success arrives after the hold expires. Releasing the hold just because the browser closes would be unsafe if payment remains in progress; holding it forever would make the displayed stock misleading. An operator should see an exception queue for ambiguous states, with the payment reference and stock claim shown together. A staff member should not quietly create a second order to “fix” the first. This example is a design rehearsal, not a description of a platform's default checkout or a universal hold duration.

Recover from interrupted and manual changes

A reservation request can succeed at the stock service while the caller loses the reply. A blind retry that creates another hold will make the item appear twice committed. Give each attempted purchase a stable request identifier and make a retry return the existing result where possible. Record the transition from requested to reserved, paid, released, cancelled or manually reviewed; forbid a transition that would release stock twice. A failed payment and a cancelled order are different events, and a refund does not always mean a returned item is sellable. Staff should record the physical return inspection before restocking. When an order crosses systems, keep the system references together so a reviewer can trace the transaction without searching several inboxes.

Reconcile physical and digital stock on a schedule proportionate to sales volume and risk. Compare each channel's open claims, fulfilled orders, pending payments and manual corrections to the location's stock record. Investigate negative quantities, expired holds still blocking stock, confirmed orders with no stock movement and stock movements with no order. The repair should be a documented adjustment or corrected state transition, not simply typing the expected total over the current one. Shopify's compare-and-swap advice is relevant here: a stale overwrite can erase a legitimate intervening sale. When the records conflict, pause new promises for the affected item or use an explicit manual availability check until the conflict is resolved.

Test the failure paths before opening sales

Run a controlled test with a variant that has one sellable unit. Submit two purchases from separate channels at nearly the same time and confirm that only one receives a stock promise. Repeat with a lost network reply, a payment that completes late, a cancelled order, a damaged return and a manual count correction. Check the customer message as well as the ledger: a technically rejected reservation can still be harmful if the customer was sent a confirmation first. Test each location separately and include any marketplace or phone-order path that bypasses the main checkout. Use test payment and non-public stock so the rehearsal does not create a real customer obligation.

Give staff a short decision card for exceptions. It should identify the stock owner, where to see the reservation and payment references, who may release or correct a claim, and when to contact the customer. A developer can build locks and queues, but the owner must decide what a customer is promised when data is uncertain. The acceptance criterion is a traceable answer to “who owns the last unit now?” across every channel. If the answer cannot be reconstructed from a single test transaction, adding a dashboard will only display uncertainty more attractively. Start with one high-risk item and one competing pair of channels, learn from the failed cases, then extend the rules to the rest of the catalogue.

For a multi-location shop, define whether a customer is buying stock from one named branch or asking the business to source it from any branch. A transfer in transit is not the same as an item ready for collection. If the website pools every location, it must consider travel time, transfer responsibility and the possibility that a counter customer buys the item before staff pick it. The confirmation should state the fulfilment promise that the system has actually secured. When stock is uncertain, an enquiry or request to confirm availability is more honest than an immediate purchase promise. Review both successful and failed reservations with customer service: the best technical lock still needs a clear explanation when a shopper loses the race for the last unit. Capture that explanation in the transaction record so staff can resolve a complaint without guessing which screen the customer saw.