Build your own order management system for e-commerce

What to look at first

OMS value appears when order volume grows and exceptions become expensive.

• Map order sources.
• Connect inventory and fulfilment.
• Define return rules.
• Expose status to support.

What the result should be

The business reduces manual coordination and gives customers clearer order updates.

Create one order model across sales channels

An OMS becomes relevant when webshop, marketplace, B2B and support use different statuses and identifiers. Normalise order, line, customer, payment, location, shipment and return while retaining source IDs. The OMS owns operational state; each channel still owns its presentation. Support can then follow one order without searching across screens.

• Channel, source ID and received time.
• Lines, bundles, discount, tax and currency.
• Payment, fraud review and holds.
• Inventory location, reservation and fulfilment route.
• Shipment, delivery, cancellation and return.

Represent inventory as reservations and events

Available stock is not simply the physical count. Account for reservations, safety stock, damage, allocated orders and incoming supply. Define when reservations begin and expire. Record movements as traceable events rather than overwriting one number. Reconcile warehouse and system regularly and stop selling when uncertainty exceeds the agreed threshold.

• On hand, available, reserved and inbound separately.
• Reservation policy by channel and product.
• Safety stock and oversell rules.
• Cycle counts and variance handling.
• Audit event per movement and order line.

Automate fulfilment through explicit exception handling

Normal orders can route by location, inventory, promise and cost. Surface address errors, partial stock, payment holds, restricted goods and label failures with an owner and recovery action. Orders must never disappear because an API call failed. Queues, retries, idempotency and an exception-led operations view belong in the core.

• Explainable routing priorities.
• Deliberate split-shipment and backorder rules.
• Queues for payment, address, inventory and carrier errors.
• Idempotent labels, pick tasks and status updates.
• Dashboard focused on blocked orders.

Treat returns as the reverse order journey

A return includes request, reason, authorisation, receipt, inspection, inventory decision and refund. Tie every returned item to its original line. Not every item goes back to saleable stock. Release refunds from verified receipt or defined policy and prevent duplicate payment. Share relevant progress with customer and support while finance confirms final processing.

• Return policy by product and market.
• Return ID tied to the original line.
• Inspection: resale, repair, damage or disposal.
• Controlled refund, replacement or credit.
• Return reason analytics by channel and product.

Connect payment, fraud review and order release

A submitted order is not automatically ready for fulfilment. Represent authorisation, capture, refund, chargeback and risk review as separate states. Define which payment methods release immediately and which require review. Consume verified webhooks only and reconcile provider transactions with order and finance. A delayed callback must never create a second order or shipment. Give customers an honest status without exposing internal fraud rules or sensitive signals.

• Payment ID and amount tied to the correct order version.
• Explicit hold for pending or suspicious payment.
• Idempotent capture, cancellation and refund.
• Daily reconciliation with provider and accounting.
• Owned manual review with deadline and audit history.

Make customer service part of the order architecture

Support needs one timeline for order, payment, inventory reservation, shipment and return. Customers see only relevant status and a realistic next step; technical codes become clear language. Notifications must follow confirmed events rather than assumptions. Give staff narrow actions such as correcting an address before release or resending confirmation. Repeated contact reasons should improve the workflow rather than become more free-text notes.

• One order timeline for fulfilment, support and customer.
• Localised message templates by state.
• Communication after accepted state transitions only.
• Narrow support actions with confirmation and logs.
• Reporting on contact reason, recovery time and repeat failure.

Roll out by channel and measure operating quality

Start with one channel and one fulfilment route before adding marketplaces, suppliers and warehouses. Test representative orders plus cancellation and return end to end. Measure release time, picking error, stock variance, late shipment, support contact and recovery. Let the OMS become authoritative for more channels only after stable reconciliation.

• Trial orders alongside the current operation.
• Daily order, payment, inventory and shipment reconciliation.
• Fallback for carrier or warehouse outage.
• Acceptance by fulfilment, support and finance.
• Phased retirement of old order flows.