Keep the order story consistent across systems.

A store may confirm a purchase while inventory or fulfillment is maintained elsewhere. Staff then compare product codes, copy records and investigate stock differences by hand. The customer sees one order, but the business may see several disconnected versions of it. We map that path from the payment or order event through reservation, picking, shipping and a possible return. Each state needs a clear owner before software can reliably move it.

We decide which system owns products, stock, orders and fulfillment status. 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 integration design includes authorization, provider limits and the points where staff need to approve a substitution or correction. That makes the customer promise consistent with the operation rather than copying statuses blindly.

Events can arrive twice, out of order or after a provider outage. We define duplicate protection and bounded retries, then surface records that cannot be reconciled safely. A conflicting quantity should not silently become a new order; a failed shipment update should not disappear in a log. Reconciliation compares the systems at agreed points and provides an operator route to resolve the specific difference. The failure path is part of the deliverable, not an optional later enhancement.

Stock reservation, partial shipments, backorders, cancellations, refunds and returns depend on the business and its providers. We ask for representative orders, including exceptions, and agree which systems and people act in each case. The first release can focus on a narrow flow if that creates a reliable result. We do not promise real-time synchronization or a particular reduction in manual work without testing the actual APIs, data quality and operating process.