Quick answer: When orders or stock levels differ between an online store, marketplace and warehouse, first identify the failing handoff, preserve evidence and pause any bulk action that could duplicate orders or oversell stock. Assign a named owner across operations, IT and each software provider. Reconcile and replay records only after identifying the source of truth, payment state and synchronization rules. Blindly editing records on production is not a recovery plan.
An order may pass through a storefront, payment gateway, order-management platform, warehouse, carrier and marketplace. One system can show “received” while another remains “pending.” This guide is for online retail managers organizing an incident response with their IT team. It does not replace platform-specific documentation or grant IT authority over orders, payments or customer records.
Which symptoms justify an incident ticket?
- A paid order does not reach the order queue or warehouse after the normal sync interval.
- The same order appears twice, flips state, or is packed after cancellation.
- The storefront or marketplace shows more available stock than the warehouse has confirmed.
- A parcel has been handed to a carrier but its tracking ID has not returned to the sales channel.
- API calls fail in batches, credentials expire, a queue grows, or only one warehouse is affected.
Do not blame “the server” because an admin page is slow. Identify the channel, start time, number of affected orders, and whether money is at risk. For a storefront outage, use the relevant website management service; for a physical checkout/network outage, see our retail POS incident handoff guide.
The first 15 minutes: protect transactions and evidence
- Name an incident coordinator. Record the first observation, affected channels, estimated order count and the business decision-maker.
- Pause risky actions. Do not bulk-import, replay, edit stock or retry payments until the impact is understood. The retailer decides whether to pause a product or channel.
- Collect representative examples. Include successful, failed and suspected duplicate orders. Note IDs in each system, SKU, timestamps, state and tracking ID. Redact personal data in shared tickets.
- Capture system state. Review queue depth, integration logs, API responses, credentials, webhooks, DNS, network connectivity and provider status before changing settings.
- Coordinate messaging. Warehouse and customer service should work from one approved status; neither shipping nor refunds should be promised from guesswork.
Trace the failure through the data flow
Sales channel to order manager: inspect webhook delivery, API permissions, rate limits, status mapping and ignored records. Order manager to warehouse: inspect SKU mapping, warehouse assignment, stock reservations, deduction rules and queue delays. Warehouse to carrier: inspect label creation, tracking callbacks and cancellation handling. Return status to the sales channel: inspect retries, authentication and conflicting updates. Follow one correlation or order ID through all hops instead of comparing only the last screenshots.
Who owns each decision?
| Owner | Responsibility | Do not do independently |
|---|---|---|
| Sales and warehouse operations | Confirm source orders, physical stock, holds and customer priorities | Bulk-change transaction state without reconciliation |
| Internal or outsourced IT | Inspect connectivity, integration accounts, logs, queues and backup; coordinate tickets and change timeline | Decide refunds, cancellations or accounting changes |
| OMS/WMS/marketplace provider | Explain sync logic, check platform-side errors and support approved replay | Alter records outside the retailer’s authorization |
| Finance and customer service | Reconcile payments, communicate with customers and approve exceptions | Declare resolution from a single dashboard |
Recover without creating duplicate orders
Before replay, define the source of truth for each field: order, payment, stock and tracking. Export the affected record set and preserve its current state. Test a small batch; use a unique ID or idempotency mechanism when supported. Compare order count, value, stock before/after and new failures. The business owner signs off before full resumption. If rollback is unavailable or edit authority is unclear, escalate to the platform provider instead of experimenting on live data.
Acceptance checklist after recovery
- Representative and exception orders show consistent state across relevant systems.
- Payments are checked independently; no unexpected new order or refund appears.
- The warehouse confirms stock for affected SKUs, including reservations and returns.
- Queues return to their normal operating range, with no infinite retry loop.
- Remaining manual exceptions have an owner and deadline.
- A timeline, verified cause, changes made and preventive actions are recorded.
Prevent repeat incidents with operational controls
Monitor sync latency, API/webhook failure rate, queue depth and variance on important SKUs. Set alerts with a named recipient, least-privilege integration access, credential renewal, configuration backups and recovery drills. SKU-mapping or warehouse-rule changes need approval, testing and a rollback path. Alert thresholds should match actual order volume rather than an arbitrary universal number of minutes.
An IT support team can own the ticket, check the underlying infrastructure and coordinate vendors. Scope of access to an OMS, WMS or marketplace must be agreed in advance. Retailers with many branches can also use the checkout incident guide for in-store cases.
Frequently asked questions
The site shows stock but the warehouse has none. Where should we correct it?
First identify the authoritative stock record, reservations and sync delay. The warehouse confirms physical availability; the integration team determines why it did not reach the sales channel. Do not bulk-overwrite stock just to make two screens match.
Should we replay every order?
No, not until the cause and duplicate-prevention behavior are known. Export the failed set, replay a small controlled batch and reconcile it before proceeding.
Does IT Systems manage customer payments and orders?
Not by default. IT Systems can investigate infrastructure, logs and integration handoffs within an agreed scope. Decisions about orders, payments, stock and personal data remain with the retailer and authorized providers.
What should an incident report include?
Provide the start time, affected channels and warehouses, a few redacted order IDs, error screenshots, recent changes and business impact. Never put passwords or API tokens into an ordinary ticket.
Need an IT owner for order-sync incidents?
IT Systems can help map your storefront–order–warehouse flow, establish vendor responsibilities and define monitoring, tickets and acceptance checks. Contact our team to discuss your environment or call +84 28 3995 0359. A useful first conversation starts with a system diagram and a few customer-data-redacted examples.
