You sell online
The store takes the order, the warehouse fulfils it
The order comes in from PrestaShop, becomes a customer and a real sales order, is routed to the depot that actually holds the goods, picked on the handheld and shipped with its delivery note. Availability goes back to the storefront computed from the ledger, not copied off a screen.
Inbound orders, catalogue, prices, images, customers, stock, payments and refunds. Run end to end from cart to shipment on a live store.
With the module installed on the store, syncing three thousand variants goes from twenty-five minutes to a few seconds.
The store receives stock minus active reservations, for the depots that channel is actually allowed to sell.
Every call from the store carries its signature; without a valid one it does not get in and moves nothing.
Online sellers lose time in exactly two places: orders that arrive and then get retyped, and published availability that is not the real one — with the phone calls that follow. CargoNode does not add a dashboard on top of your store: it takes the order all the way to the shipping document, and sends back stock minus reservations, which is the only number you can promise a customer. The link to the online store is part of the Sales module, together with orders, customers and payments.
From the order on the store to the shipping document
The order does not land in a staging table: it becomes a customer (found or created) and a real sales order, with its lines, per-line VAT and the store’s shipping and discount amounts. From there it goes through the warehouse like any other order — reservation, pick wave, handheld, packing, shipment, delivery note — with no privileged lane and no second-class one. Ingestion is idempotent on the store’s own reference: if the same order arrives twice, the second time creates nothing. Orders are looked up by connector rather than by how they are named, so two stores on the same account never blur into one another.
- Customer found or created from the order, with the tax details the store collected
- A real sales order, with per-line VAT, order discount and shipping
- Idempotent on the store reference: a repeated order does not double up
- Picking, packing and shipping are the warehouse’s own, not a separate path
- Two stores on the same account stay separate, connector by connector
- Delivery notes numbered without gaps, per warehouse and per year
- The store hands over the orderSigned, and carrying the store’s own reference: if the same order arrives twice, the second one creates nothing.
- It becomes a customer and a sales orderThe customer is found or created; the lines carry line-level VAT, the order discount and the store’s accessory charges.
- It gets routedTo the depot that actually holds the goods, chosen among those that channel is allowed to sell.
- Reservation and pick waveFrom here it is an order like any other: it joins the warehouse round, not a separate track.
- Packing and shipmentItem-to-carton scan at the bench, multi-parcel shipments included.
- Delivery note and trackingThe delivery note comes out numbered without gaps, per warehouse and per year; the carrier code travels back to the store.
Which orders come in, and which come in but stay put
Store statuses answer two different questions, and treating them as one does damage. The first is whether the order comes in at all. The second is whether, once in, it should be fulfilled right away. An order in “payment error” should come in — you want to see it, you want the customer on file — but it should not commit stock, because committing stock means taking it off sale for something that may never close. So statuses are chosen twice: the ones that let an order in, and the subset that lets it in on hold. An order on hold reserves nothing, cannot be picked and does not move published availability; when the store changes its status it releases itself, and if the store no longer knows anything about that order the run tells you why instead of leaving it stuck in silence.
- One list of statuses decides what comes in, a second decides what comes in on hold
- An order on hold reserves no goods and does not lower published availability
- Release comes from the store, or from a bulk re-read of the orders still held
- An order the store no longer recognises is reported, with the reason
- In Sales it reads “held from the store”, which is not the same thing as a draft
- COMES INPayment acceptedreserves the goods, goes to picking
- COMES IN HELDAwaiting bank transferno reservation: the goods stay sellable
- COMES IN HELDPayment erroryou see it, it commits nothing
- STAYS OUTCancellednot in the first list
Held statuses are a subset of the ones that let an order in: an order that does not come in cannot be held. When the store changes the status, the order releases itself.
Published availability is recomputed on every reservation
What you publish is stock minus active reservations, computed at that moment and limited to the depots and owners that channel is genuinely allowed to sell — a third-party owner’s stock or a depot that does not serve the web will not inflate the storefront. There is no nightly job recomputing everything: when a reservation is created or released, the affected variant is flagged and the next run publishes only those, within about a minute. If the store answers badly the attempt is not repeated forever: failures are remembered, the wait grows between attempts, and an item the store says does not exist stops being retried and lands in a list of blocked rows, with a button to queue them again once you have fixed the cause.
- Published availability = stock minus active reservations, always recomputed
- Per-channel scope: which warehouses and which owners that store may sell
- Targeted push on the changed variants only, not a nightly sync of everything
- Growing back-off on transient errors, instead of retrying into the void
- An item the store no longer has: a permanent failure, not an eternal retry
- A list of blocked rows with a way out, instead of a queue that just swells
- AVAILABLE40 in stock − 12 reserved = 28only the depots that channel sells
- QUEUED12 variants touchednot the whole catalogue
- RETRYThe store does not answerthe wait grows with every attempt
- STOPPEDAn item the store no longer hasno further attempts
Stopped rows land in a list with a button to put them back in the queue: the queue then holds only work worth doing, instead of swelling with blind attempts.
The catalogue travels in the right direction
The storefront follows the back office, never the other way round: items, descriptions, categories, images and prices are published from CargoNode to the store. Prices come from the price list rather than from a field kept in two places, and the storefront remembers what it has already received, so republishing does not rewrite everything for nothing. Not everything in the catalogue has to go online, and that is an explicit per-item choice instead of a side effect. Where a consumption levy has to be added on top of the price, the arithmetic stays on this side — with its multipliers and its dated rate — and the store receives a finished amount, because a second implementation over there would be a second truth, bound to drift inside a compliance register.
- Items, descriptions, categories and images published from the back office
- Prices from the price list, with the header discount and per-line exceptions
- An explicit choice of what goes to the storefront and what stays in the warehouse
- The storefront remembers what it already has: only changes are republished
- Consumption levies are computed here and reach the store already worked out
- The total the customer paid stays the store’s total, even when the store rounds its own way
| The data | Born in | Travels to |
|---|---|---|
| Items, descriptions, categories, images | CargoNode | the store |
| Prices | the CargoNode price list | the store |
| Consumption levies | CargoNode, with its multipliers | the store, already computed |
| Published availability | the movement ledger | the store |
| Orders | the store | CargoNode |
| Order status and tracking | CargoNode | the store |
| The total the customer paid | the store | stays the store’s |
The line the store knows about and you do not
Sooner or later an order arrives containing an item that does not exist in the back office: created on the store and never mapped, or a brand-new combination. The wrong reaction is to reject the whole order, because the customer has paid and nearly all the goods are there. Here the line fails, not the order: it goes into a list of unmapped lines with everything the store knew about it — reference, name, quantity, price — the order waits in quarantine, and once the mapping exists it is replayed. There is no such thing as an order lost in silence, which is normally how an integration problem gets discovered: from the customer who calls.
- Soft failure per line: the order survives, the line waits
- The unmapped line keeps everything the store knew about it
- Map it and replay, without asking the customer to order again
- Mappings handle product combinations and multi-store setups
- No orders lost without anybody knowing
- LINE 1SKU-4471 · 2 unitsmapped
- LINE 2SKU-8890 · 1 unitmapped
- LINE 3PROMO-XMAS · 1 unitunmapped: code, name, quantity, price
The line fails, not the order. The third one waits for a variant; the moment you give it one, the whole order replays and the customer never notices.
Payments, returns and what travels back to the store
Traffic is not one-way. When the order is paid, when it ships, when it comes back, the store gets to know: order status, tracking reference, acknowledgements. A partial shipment does not close the case on the store — it updates the tracking and leaves the status alone — because moving an order to “shipped” on the first parcel while half the goods are still on the shelf is the fastest way to get a customer writing in. Refunds follow the same road: a return comes back into stock as a movement, and the credit note is a document, not a deleted line.
- Order status and tracking pushed back to the store
- Partial shipment: tracking is updated without declaring the order complete
- Acknowledgements back to the channel, so the same order is not pulled twice
- Payments and refunds reconciled on the order, not on a spreadsheet on the side
- A reference we generated is marked internal and never poses as a carrier tracking number
- PaidThe payment is reconciled against the order, not on a spreadsheet.
- The first parcel leavesTracking goes back to the store and the order stays open, because it is: half the goods are still on the shelf.
- The last parcel leavesOnly now does the order close on the store.
- Something comes backThe return re-enters the warehouse as a movement, and the credit note is a document — not a deleted line.
The module on the store, and what it actually changes
The link also works with PrestaShop’s standard web service, the way everyone does it: you query the store one resource at a time. The trouble with that approach is arithmetic — syncing three thousand variants costs six thousand calls and twenty-five minutes, and for those twenty-five minutes the storefront is describing a warehouse that no longer exists. The module installed on the store changes the nature of the relationship: the store speaks first and accepts bulk writes, so the same three thousand variants sync in seven calls and an order becomes a reservation immediately instead of up to ten minutes later. It touches no PrestaShop core file and uses no overrides, and the checkout never waits for our backend: the event is written to a queue inside the order transaction, and delivery happens after the customer has had their page. A store that stops selling because we are slow would be a bigger loss than any delay.
- Works without the module too, over the store’s standard web service
- With the module: bulk sync and immediate reservation instead of polling intervals
- No PrestaShop core overrides, no extra columns on its tables
- The checkout never waits for our backend: the queue lives inside the order transaction
- Pairing with a time-limited code, and signed calls in both directions
- A self-check that measures the price a customer sees, instead of comparing version numbers
| What changes | Web service only | With the module |
|---|---|---|
| Aligning three thousand variants | 6,020 calls, twenty-five minutes | 7 calls, a few seconds |
| Calls on a normal day | around 6,500 | around 150 |
| From order to reservation | up to ten minutes | immediately |
| The cart waits for our backend | never | never |
| Overrides of the PrestaShop core | none | none |
Frequently asked questions
We use Shopify (or WooCommerce). Is there a connector?
The adapter that has been built and run end to end, from order to shipment, is the PrestaShop one, with a module installed on the store. The plumbing underneath, though, is generic and holds for any channel — outbound queue with de-duplication, variant mapping, inbound tray, signed webhook, retry with growing back-off, unrecognised lines set aside rather than lost — and a different store plugs into that: it is adaptation work, not foundation work. Tell us what you run on and we will look at what it actually takes.
Can the store sell a unit that is no longer in the warehouse?
The window is narrowed as far as it can be: published availability is computed on active reservations, and the push fires when a reservation changes rather than on a fixed schedule. The window is not zero, though, because the store is a separate system. What does not happen is promising goods that are already committed: if two orders reach for the last unit, the second one is not given an impossible promise — it waits for incoming stock and gets allocated on the next receipt, in the order it joined the queue.
If your backend is down, does the store stop selling?
No, and that is a design constraint of the module: the checkout never waits for an answer from us. The event is written to a queue inside the store’s own order transaction, and delivery to CargoNode happens after the customer already has their page, with a timeout of a few seconds. If we are unreachable the queue drains later: no order is lost and no customer is left staring at a spinner.
Do we have to install something on the store?
It is not mandatory. Without the module you work over the standard web service, and it works: it just costs many more calls and a delay between the order and the reservation. With the module — PrestaShop 8.1 or later — the same operations become a handful of bulk calls and the reservation is immediate. The module touches no core file and uninstalls like any other.
Who is in charge, the store or CargoNode?
CargoNode. That is a decision, not an accident: the catalogue, the prices and the stock figures are governed on this side and the storefront receives them. The store remains the place where selling happens and where the customer buys, and it stays the origin of orders; but where a value is written in two places, the good one is the back office’s — otherwise the first mismatch turns into an argument about who is right.
What happens to an order containing an item we do not recognise?
It still comes in. The unknown line goes into a separate list with everything the store knew about it — reference, name, quantity, price — and the order waits in quarantine until you give that line a variant. Then it is replayed. That is the difference between a problem you can see on a screen and a problem you discover when the customer rings to ask where their parcel is.
Let’s run it against your store
Tell us which platform you are on, how many orders you take on a normal day and how many on the worst day of the year. We will show you the whole round — order, pick, shipment, availability going back — on your own items.
Talk to us