Ecommerce Order Management Software: An Order Is A State Machine

An order looks like a record. It is closer to a state machine, and most of the difficulty in ecommerce order management software comes from the fact that real orders refuse to move through their states in a straight line.

Half arrives Tuesday. A customer changes the address after the label prints. One item of four is returned. A payment captures but the stock was already gone. Software that models an order as a row with a status field handles none of these, and the gap gets filled by a spreadsheet and somebody's memory.

The states that actually exist

Most tools give you a status field with values like pending, paid, shipped, delivered, cancelled. That is a reasonable summary and it is not a model, because an order can be in several of those at once.

The states worth tracking separately:

Payment. Authorised is not captured, and captured is not settled. A refund is a separate object with its own state, not the payment state running backwards. If your system cannot tell the difference between authorised and captured, you cannot safely cancel before capture, and that is free money left on the table.

Allocation. Stock reserved against this order but not yet picked. This is what stops two customers buying the same last unit, and it is the state most commonly missing. Without it, stock only moves when the parcel leaves, which is far too late.

Fulfilment. Per line item, not per order. An order with four items can have two shipped, one on backorder and one cancelled. A single order-level shipped flag cannot say that, and every partial shipment turns into a manual note.

Return. Requested, authorised, received, inspected, refunded. Collapsing these into returned means you cannot answer where a specific return is, which is the only question anyone asks about returns.

The cases that break most systems

Partial shipment

Three of four items ship today, the fourth next week. Two shipments, two tracking numbers, one order. If the software has one tracking field, somebody is emailing the second number by hand and it does not appear on the order page.

Partial refund

The customer keeps three items and returns one. The refund is for that item, its share of tax, and some fraction of shipping that somebody has to decide. Getting the tax portion wrong on partial refunds is a quiet and persistent accounting problem.

Edits after payment

Adding an item to a paid order means a second charge. Removing one means a partial refund. Changing an address after a label exists means voiding that label and buying another. Every one of those is a financial transaction wearing the costume of an edit, and systems that treat order editing as editing a form will get it wrong.

Overselling

Payment succeeded, the stock is not there. Someone has to choose between backordering, substituting, partially refunding or cancelling, and the software should at minimum make that choice visible rather than leaving the order to sit in a queue looking normal.

What to check before choosing anything

Four questions, all answerable in a demo, all of which separate serious tools from status fields:

Can one order have more than one shipment, each with its own tracking number and its own set of line items? Can you refund a single line item and see what happened to the tax? Is there a state for stock that is reserved but not yet shipped? And does every change to an order leave a record of who made it and when?

A system that answers yes to all four will cope with the messy cases. One that answers no to any of them will cope until the first partial return, and then somebody starts keeping a spreadsheet.

Where this lives matters

Order management is usually sold as a separate product that sits between your store and your warehouse. That works, and it introduces the sync problem: two systems both believing they know an order's state, reconciling on a schedule, disagreeing in the gap.

The disagreements are not dramatic. An order shows as shipped in one system and paid in the other. A refund lands in one place and not the other. Nothing breaks loudly, and the numbers stop matching.

We keep orders in the same backend as the products, the stock and the shipments, which is our answer to that: line-level fulfilment, per-line refunds, stock allocated at payment rather than at pick, and an audit trail on every change. One system holds the state, so there is nothing to reconcile.

Where we are the wrong answer: if you run a real warehouse with pickers and bins, a dedicated warehouse management system does that better than we do. If your orders arrive from Amazon, eBay and a retail POS as well as your own store, a dedicated multichannel order manager exists to sit above all of them, and that is a genuine job we are not doing. And if your current setup handles partial shipments and partial refunds correctly already, this is not your bottleneck.

The short version

Stop thinking of an order as a status and start thinking of it as several states running at once: payment, allocation, fulfilment per line, and returns. Then ask whether the software can express a partial anything.

If you want to see how the order endpoints are shaped, the docs have them.