How to Prevent Dropshipping Overselling in PrestaShop
Dropshipping overselling happens when your PrestaShop store accepts more units than the supplier can allocate. A frequently updated feed helps, but it cannot guarantee that stock remains available while other retailers are ordering.
Build a policy that combines supplier availability, your unconfirmed commitments, a safety buffer and a maximum feed age. This guide provides a worked calculation and the failure cases to test with whoever maintains your stock integration.
The formulas below are proposed operating rules. PrestaShop does not automatically apply this complete policy merely because a supplier is assigned to a product.
1. Define the Meaning of Every Stock Figure
Ask the supplier what its quantity represents: physical units, available-to-order units, units after reservations or an approximate availability band. Record the answer with the feed timestamp and warehouse scope.
Next, define your own open commitments. These are orders your shop has accepted but that the supplier's reported quantity may not yet reflect.
Do not subtract the same reservation twice. If the supplier's available figure already excludes your accepted order, subtracting that order again understates stock. If it does not, ignoring the order overstates stock.
Create a small data dictionary:
| Value | Meaning in this example |
|---|---|
| Supplier availability | Units available before our newly submitted orders |
| Unreflected commitments | Our orders not yet deducted from that figure |
| Buffer | Units withheld to absorb uncertainty |
| Selling cap | Maximum units we choose to expose |
| Source time | Time the supplier measured the quantity |
Resolve ambiguous fields before choosing a buffer. A large buffer cannot repair an unidentified unit of measure or a feed covering the wrong warehouse.
2. Calculate the Publishable Quantity
Use a non-negative quantity and cap it when appropriate. For the definitions above, a practical proposed rule is:
Publishable quantity = max(0, min(selling cap, supplier availability − unreflected commitments − buffer))
Suppose the supplier reports 20 units, five units are committed by your shop but not reflected in the report, the buffer is four and the cap is eight. The underlying remainder is 11, so the published quantity is eight.
If the supplier later reports six units while those five commitments still remain unreflected, the calculation becomes six minus five minus four. Publish zero rather than a negative quantity.
Have the integration owner show how the formula maps to your actual feed and order data. Keep the original supplier value in a traceable record so support can explain why the shop published a different number.
This policy reduces exposure; it does not reserve the supplier's remaining stock. Keep the supplier acceptance check in the order workflow.
3. Choose Buffers by Product Risk
Use different policies for different stock behaviour. A slow-selling item with stable availability does not necessarily need the same buffer as a heavily advertised seasonal product sold by many retailers.
Consider update frequency, supplier order rejection history, sales velocity and the time required for acknowledgement. Review buffers after actual exceptions rather than making them permanent guesses.
An illustrative starting sheet might use a small fixed buffer for stable accessories and a larger buffer plus a selling cap for fast-moving gifts. Label those initial values as hypotheses to review during the pilot.
Avoid copying a supplier quantity of 10,000 directly into the storefront when the supplier uses it as a code for “usually available.” Convert availability bands only under a documented policy, or use a different customer promise that reflects the uncertainty.
4. Add a Freshness Limit
Record both the supplier's source time and your last successful processing time. A file downloaded recently may still contain yesterday's measurements.
Define a maximum acceptable age for each route. When the source is older, switch to the agreed fallback instead of presenting the old number as current.
| Feed condition | Proposed operating response |
|---|---|
| Valid and within the agreed age | Apply the normal quantity calculation |
| Valid but too old | Stop new sales or use an explicitly approved conservative fallback |
| Missing timestamp | Treat freshness as unknown and investigate |
| Download failed | Retain evidence and trigger the stale-data policy when its limit is reached |
| Unexpected empty file | Quarantine the update rather than assuming a full stock change |
Choose the fallback with the merchant and integration owner. Automatically setting everything to zero can disrupt sales, while retaining stale positive values can accept unfulfillable orders; the appropriate behaviour must be deliberate.
Put an alert owner and response time beside the policy. An alert that nobody reviews is not a stock control.
5. Handle Missing Products and Large Changes Explicitly
Agree whether a missing row means discontinued, temporarily omitted or unavailable. Do not interpret absence as a business event unless the feed contract says so.
Set review thresholds for unusual changes. For example, a feed that normally contains 2,000 references and suddenly contains 200 should require investigation before it becomes the new catalogue truth.
Check for duplicate references and unexpected units. Two rows for the same variant may represent different warehouses or an accidental duplicate; summing them blindly can double availability.
Keep product mapping at variant level. Ten blue trays do not cover an order for ten black trays, even if both share a product name.
For the engineering behind controlled updates, use the existing resumable imports guide. The merchant policy here defines what the integration should publish and when it should stop.
6. Protect Against an Older Update Replacing a Newer One
Ask the integration owner to demonstrate how source versions or timestamps are compared. A delayed older feed should not overwrite a quantity derived from a newer accepted snapshot.
Run a clear example: process a 10:30 report showing eight units, then attempt to process a delayed 10:00 report showing 20. The expected result is that the older report does not restore 20 units as current availability.
Keep this separate from the rule for retries. Reprocessing the same accepted snapshot should not repeatedly subtract the same commitments or produce a different quantity without a new input.
If scheduled jobs maintain stock, review the existing reliable cron jobs guide with the technical owner. The observable business result is one consistent current stock decision.
7. Test the Customer-Facing Out-of-Stock Behaviour
When the policy publishes zero, check the product page, combination selection and checkout. Confirm whether your installed out-of-stock configuration blocks ordering or intentionally allows backorders.
For deadline-sensitive gifts, an unnoticed backorder setting can defeat the purpose of setting the quantity to zero. Test the exact promoted combination and customer route.
Run two near-simultaneous test purchases against the last available unit using a controlled environment. Ask the technical owner to verify the resulting orders and quantities under your installed checkout and payment flow.
Do not claim a buffer alone prevents concurrent checkout races. It is one layer in a process that also needs correct shop-side reservation and supplier acceptance behaviour.
8. Measure Exceptions and Adjust the Policy
Track supplier rejection rate, affected units, stale-feed incidents and the time until staff respond. Review the products that generate exceptions, not just the total count.
If buffers are repeatedly exhausted before the next update, shorten the accepted feed age, lower the cap or reassess the route. If quantities remain unnecessarily restricted, investigate whether commitments are being subtracted twice before reducing buffers.
During holiday campaigns, connect these checks to the delivery cutoff policy. A product can still have physical stock after the point when the supplier can deliver it for the occasion.
Keep each policy change dated with its reason. This makes it possible to compare outcomes and reverse a change that reduced sales without addressing the actual problem.
9. Common Overselling Problems and Fixes
| Problem | Likely cause | What to check or change |
|---|---|---|
| Availability jumps after a delayed job | An older snapshot overwrote a newer one | Compare source versions before publishing |
| Stock is always lower than expected | Reservations were subtracted twice | Reconcile supplier quantity semantics and commitments |
| Feed appears fresh but orders are rejected | Download time was mistaken for source time | Check when the supplier measured stock |
| Zero-stock products remain purchasable | Backorders are enabled | Test the exact out-of-stock configuration |
| One colour oversells while another is plentiful | Mapping is at product rather than variant level | Use exact combination references |
10. Stock Policy Checklist
- Supplier quantities, units and warehouse scope are defined.
- Commitments are subtracted exactly once where appropriate.
- Buffers and caps have an owner and review date.
- Source age is checked independently of download time.
- Missing and malformed data follow explicit rules.
- Older updates cannot replace newer accepted data.
- Zero-stock and last-unit checkout cases have been checked.
- Supplier acceptance remains part of every order's workflow.
Frequently Asked Questions
How often should I update dropshipping stock?
Use a frequency justified by supplier changes, order volume and the consequences of a stale quantity. Updating frequently helps only if the source itself is current and the order acceptance process is reliable.
Does a stock buffer guarantee that I will never oversell?
No. A buffer reduces exposure to changes between updates, but other retailers and concurrent orders can still consume stock. Confirm allocation with the supplier and handle rejections explicitly.
Should I set every product to zero when a feed fails?
Follow the fallback agreed for that route and feed age. A short outage and an unexplained stale source may justify different actions, but neither should leave staff unaware of the state.
Why is downloaded data not necessarily fresh?
The file may have been generated long before you retrieved it. Record the supplier's measurement or version time as well as the successful download time.
Can I use the same buffer for every supplier?
You can start with a simple policy, but review it against each supplier's behaviour. Different reservation rules, update schedules and rejection histories often require different limits.
What should I check when stock looks too low?
Check for double subtraction of commitments, incorrect units and overly restrictive caps before changing the buffer. A traceable calculation makes those causes easier to distinguish from a genuine shortage.