Order & inventory synchronization
We connect storefront, inventory and fulfillment around stable identifiers and one owner per record, so stock and orders agree and every difference is surfaced for a person to resolve.
Illustration: store and back-office events interlock like the two sides of a zipper while the order reference runs the seam. A duplicate order event arrives late and is held beside the seam instead of locking in twice.
The customer sees one order. Every system behind it should see the same one.
The store confirms a purchase while stock and fulfillment live somewhere else. Staff compare product codes, copy records and chase stock differences by hand, and the customer sees one order while the business sees several disconnected versions of it. We map that path from the payment or order event through reservation, picking, shipping and a possible return, and give each state a clear owner before any software moves it.
We decide which system owns products, stock, orders and fulfillment status, and write it down before connecting anything. Mappings use stable identifiers and an explicit policy for missing or changed products. A received event is not the same as a completed warehouse action, so the flow records both. The design includes authorization, provider limits and the points where staff approve a substitution or correction, so the promise made to the customer matches what the operation can do.
Example
order reference ORD-example
storefront owns order, payment status, customer contact
inventory owns stock on hand, reservations
fulfillment owns pick, pack, shipment, tracking
matched on order reference and SKU, never product name
missing SKU held for review, not created as a new product
quantity conflict exception queue, owner: operations lead
event received recorded apart from warehouse action completedEvents arrive twice, out of order or long after a provider outage. We define duplicate protection and bounded retries, then surface any record that can’t be reconciled safely. A conflicting quantity should not silently become a new order, and a failed shipment update should not disappear in a log. The failure path is part of the deliverable, not an optional later enhancement.
| Lane | Order paid | Event repeats | Inventory down | Inventory back | Shipped |
|---|---|---|---|---|---|
| Storefront | 1 | Sends the same event again | Shows tracking to the customer | ||
| Integration | Stores the event by its reference | 2 | 3 | Releases the held event | |
| Inventory | Unavailable | 4 | |||
| Fulfillment | 5 | ||||
| Operator queue | Receives it only if retries run out |
Numbers trace one example order: the repeated event is matched to the record it already created, and the outage delays the reservation instead of losing the order.
The order reference and event identifier are checked first, so the second delivery is recorded and ignored instead of creating a second order or shipment.
Each update is compared with the state already recorded, so a late ‘pending’ cannot overwrite ‘shipped’.
The event waits with its reference and is retried within agreed limits. Past them, it reaches an operator queue with the affected order named.
Scheduled reconciliation compares the systems at agreed points and lifts the specific difference out for a person to resolve, with the evidence attached.
Stock reservation, partial shipments, backorders, cancellations, refunds and returns depend on your business and your providers. We ask for representative orders, including the awkward ones, and agree which system and which person acts in each case. Synchronization timing and any reduction in manual work are confirmed by testing your actual APIs, data quality and operating process.
When stock is reserved, and when it is released
How a partial shipment is recorded and explained to the customer
Whether a backorder is accepted, and for which products
Who may cancel an order, and what the other systems do next
How a refund or return changes stock and the order
When staff may substitute a product
The first release can focus on one narrow flow if that creates a reliable result.
The wider service for connecting storefront, inventory, fulfillment, accounting and CRM.
View Ecommerce integrationsOur planning guide to field-level ownership, identifiers and reconciliation.
Read the guide: Connecting orders, inventory and CRMWe work with the commerce platforms below and the inventory, fulfillment and accounting systems around them, after checking each one’s API, webhooks and limits against your flow.
Store events, inventory levels and fulfillment updates, connected within the platform’s documented limits.
View Shopify developmentOrders and stock from a WordPress store, with extensions and checkout planned as part of the same system.
View WooCommerce developmentComplex catalogs and stock rules, with the edition and extension landscape assessed first.
View Magento 2 developmentJoomla-based stores whose orders and stock need to reach the systems that fulfill them.
View HikaShop developmentSome of the teams we have worked with.
Across talent, fitness, mobility, payments and local commerce.It keeps the storefront, the inventory system and fulfillment in agreement about each order and each product’s stock. Each fact has one owning system, records are matched by stable identifiers, and differences are reconciled on purpose instead of being copied blindly from one system to another.
Timing depends on what your platforms offer: some send events as they happen, others allow only periodic checks within rate limits. We measure what your systems support, design for delayed and repeated updates either way, and agree with you how fresh stock needs to be for each channel.
By deciding which system owns available stock, when stock is reserved and how quickly other channels learn about a change, then testing those rules against busy periods and returns. No integration removes the risk entirely when systems update at different speeds, so we also define what happens to an order that can’t be filled.
The accepted order must remain durable and visibly pending. We plan bounded retries and an operator queue, then determine what the customer should be told. The correct behavior depends on your stock and fulfillment policy.
The integration should use stable event and order identifiers, with an idempotent processing boundary. We test repeat delivery and reconciliation against the actual systems before production.
Not necessarily. The first option is to connect the systems you already run and make their responsibilities explicit. Replacement makes sense only when a system can’t provide the records or access the process needs, and we make that case with evidence during scoping.
We treat the failure path as part of the build: duplicates, late updates and quantity conflicts are designed, tested and handed over with an operator route, not left for a later phase. Orvenant develops on Shopify, WooCommerce, Magento 2 and HikaShop and builds the integrations behind them, so one team owns the whole order path.
Continue exploring
B2B ecommerce for account-based catalogs, purchasing rules and repeat ordering. Turn your commercial process into a buying experience customers can follow.
View B2B ecommerce developmentAI automation for the work between your systems, and custom web applications, portals and websites for the people who use them. Commerce, mobile, search and hosting join the plan when the product needs them, and the first conversation needs no finished technical brief.
View ServicesShare one order that shipped late, twice or not at all, and the systems it passed through. We’ll trace where its story split and what it takes to keep it whole.
Technology names and marks belong to their owners.