A shopper orders a jacket on your website while a store assistant sells the last one in that size at the till. Each system records a clean sale. The trouble starts when the warehouse gets a pick request for a jacket it no longer has. Someone then has to phone the customer and apologize.
Omnichannel order management is the set of rules and systems that prevents that call. It takes in orders from every place you sell. In a typical retail setup that means a website, marketplaces and stores, and a B2B seller may add a wholesale portal. Stock in warehouses, stores and partner sites counts as one pool. One set of rules then decides where each order ships from and how a return goes back into stock. The software that runs those rules is usually called an omnichannel order management system, or OMS.
Most guides on this subject are written by companies that sell an OMS or a fulfillment service. We build commerce backends, so this one follows the order through the system the way an engineer would. Most of the space goes to the stock and routing rules, and to what happens when an event arrives twice or late. The vendor guides we read for this page do not cover how to test for those failures. We also think many retailers can run this inside the ecommerce platform they already have, and a later section explains when that is true.
Where multichannel order management ends and omnichannel begins
A multichannel order management system links separate channels to shared stock and one order list. Each channel still runs its own lane. A marketplace order is shipped, tracked and returned through the marketplace flow, and a web order follows the website's flow.
Omnichannel order management lets a single purchase cross channels. A customer can buy online and collect in a store, or bring a web order back to a till. Store staff then need to see the online order. The store's stock also has to count toward what the website can sell.
Both setups need the same connections to channels, stock and fulfillment. Omnichannel adds harder rules on top. The system has to know which store can promise an item to a web customer and when that store's stock is held. It also has to know which system issues the refund when a return crosses channels.
How an order moves through the order management process
Most setups split the work into four stages. Vendors give them different names, and the work inside each one is much the same from product to product.
Capture
The OMS pulls orders in from each channel, usually through APIs and webhooks, and turns them into one internal order format. That format has to absorb real differences between channels. One marketplace sends tax as a separate line, and another includes it in the price. A B2B portal adds a purchase order number and payment terms. When the format cannot hold a field, people start keeping it in notes and spreadsheets.
Capture is also where duplicate orders enter, because channels resend events when they do not get a quick reply. The failure cases later in this guide cover how to test for that.
Allocation and routing
Allocation promises specific units to the order. Routing picks where each line ships from. In most setups that is a warehouse or a store, and some lines go to a 3PL. Many platforms run both as one step, using rules that the merchant sets.
Fulfillment
The OMS sends pick instructions to a warehouse management system (WMS), a 3PL or a store. It then records shipments and tracking numbers, and it handles a partial shipment when one line is late. Shopify's FulfillmentOrder model shows how a platform represents this. Each fulfillment order groups the items that will ship from one location, and an order can have more than one. Each one also has its own status, such as on hold or closed. A support agent can then see which part of an order is stuck.
Returns and refunds
The OMS accepts returns from each channel, decides whether the item goes back on sale, and triggers the refund through the right payment provider. An omnichannel return adds two more decisions when a web order comes back to a store. The rules have to say which location gets the stock and which system pays out the refund.
Keeping inventory in sync across channels
For inventory sync, the OMS tracks several quantities for each item at each location. Before any number goes out to a channel, the team has to agree on what "available" means.
Stock on the shelf is one quantity. Stock held for an unfinished checkout is another, and stock already promised to a paid order is a third. Adobe Commerce makes the split visible. When an order is submitted, a reservation lowers the salable quantity, and the physical quantity at the source drops only when the order ships. A channel that reads the physical number will keep selling units that are already promised to someone else.
Each sale also has to reach every other channel before that channel sells the same unit. Stores add a delay of their own, because a till can sell the last unit while it is offline and report the sale later. Some teams hold back a small safety buffer per channel to absorb that gap. A buffer lowers the risk of an oversell. The system still needs a rule for the order that loses when two sales race for one unit. The oversell test further down checks that rule.
Returns feed stock back into the same numbers. A returned item should count as sellable only after someone checks it and the OMS marks it that way. If that status never reaches the other channels, the item sits on a store shelf while the website shows it as sold out.
Routing and allocation rules to write down first
Rules that live in someone's head turn into guesses during a build or a software setup. They work best as statements a developer could test, such as "marketplace orders never ship from store locations."
Platforms already handle the common routing rules. Shopify's order routing applies rules in sequence and needs two or more active locations. By default it avoids split fulfillments by picking a location that can ship every item. It also stays within the destination market when possible and ships from the closest location. Custom rules can use location data such as warehouse capacity or fulfillment speed. Adobe Commerce offers a Priority mode, which works through sources in a set order. Its Distance mode compares the delivery address with the location of each source instead.
What the platform leaves to you is the business policy behind each rule. Each channel needs clear answers on these points:
- Which locations can ship its orders.
- Whether it gets a reserved share of stock or competes for the shared pool.
- When stock is held: at basket, at checkout or only at payment.
- What happens when an order cannot be fully allocated. The usual choices are to split it, hold it or cancel the short lines.
Pricing rules belong in the same document, because they are also set per channel. They record the price list and currency for each channel, and whether its prices include tax. They also record which promotions apply and who can override a price. B2B channels add account-specific prices and payment terms. Our guide to B2B ecommerce best practices covers account pricing and payment terms in more depth.
Split shipments
When no single location can ship the whole order, the system may split it. In Shopify, for example, fulfilling only some of the items in a fulfillment order splits it in two. Two parcels usually cost more to send than one, and the customer has to follow two deliveries. A written rule should say when a split is acceptable, for example only when the customer chose faster delivery.
Pickup in store and ship from store
Store fulfillment turns each store into a stock location for web orders. In buy online, pick up in store (BOPIS), the customer collects the order at a store. In ship from store, staff pick and pack a web order in the store and send it out. Shopify's pickup feature shows the kind of rules involved. By default, it offers pickup only when the whole order is in stock at the chosen store. Store transfers can bring stock in from other locations, starting with the closest ones that have the item available. A customer can also have some items shipped and collect the rest as part of one order.
Store stock needs extra care in all of this. Shoppers move items around, and a till may report a sale late. A store that shows one unit online may then fail to find it on the shelf. The pickup rules should say what happens then, such as a transfer from another store or a message to the customer.
Dropship and third-party fulfillment
Some lines may ship from a supplier or a 3PL instead of your own stock. Shopify lets a merchant connect a third-party fulfillment service, and different items in the same order can use different fulfillment methods. The OMS then tracks a shipment it does not control. Its rules should say how long to wait for the partner's tracking update before someone follows up.
Connecting the OMS to ERP, WMS, POS and marketplaces
An OMS sits in the middle of your other systems, so most of the effort goes into integration. Three decisions shape each connection, and they are easier to settle early than after go-live.
Which system owns which data. The ERP usually owns financial records and product master data. The OMS owns the order and its status, and the WMS owns physical stock counts. When two systems disagree about a number, everyone needs to know which one wins.
Push or pull. Webhooks give near-real-time updates, but they can arrive twice or out of order. Scheduled polling is slower and easier to reason about. Many setups use webhooks for speed. A scheduled check then compares both systems and catches anything the webhooks missed.
What happens when the other side is down. Orders should wait in a queue and retry until the other system is back. Someone should get an alert when a queue keeps growing.
The POS and the marketplaces bring their own timing and formats. A till that sells offline creates the stock delay described earlier. Our post on connecting your POS to ecommerce covers that timing in more detail. Marketplaces each have their own API and order format, which is why the capture stage needs one internal format that every channel maps into.
Failure cases to test before you trust any OMS
These scenarios belong in a test environment before go-live, whether you buy a product or build one. A vendor or build partner can be asked to run them during the evaluation, with your own channels and rules.
Oversells
The test sells the last unit on two channels within seconds of each other. It then checks where stock was reserved, how fast the new quantity reached each channel, and what the system did with the second order. That losing order needs a written outcome. The usual choices are to cancel it and tell the customer, put the item on backorder, or pass the order to a person.
Duplicate orders
Channels and payment providers retry when they do not get a quick response. Shopify's developer documentation says an app might receive the same webhook more than once. It recommends idempotent processing, meaning a repeat has no extra effect, or checking the webhook ID against a stored list. The OMS should recognize the repeat and return the order it already created. A second order for the same purchase means a second pick, a second parcel and usually a refund later.
Payment events that arrive late or out of order
A shopper pays, then closes the browser before the order is created. In another version, the payment provider confirms a capture minutes after the system asked for it. The OMS should store a capture request and a confirmed capture as two separate facts, and the test checks that it does. It also checks that a paid checkout without an order is either finished or refunded.
Allocation failing after payment
The shopper's card is charged, and only then does the system find that the last unit went to another order. The outcomes written for the oversell test apply here as well, and a canceled order now also needs a refund. The test confirms that the refund goes out and that a person receives the alert.
Partial failure between systems
A call to a payment or shipping provider succeeds, then the database save that records it fails. A database transaction cannot wrap a network call to an outside provider, so this mismatch can happen in any system. The system should record the mismatch so that someone can reconcile it later.
When your platform is enough, and when you need a dedicated OMS
A retailer can often run omnichannel order management inside the ecommerce platform it already uses. Apps and platform settings may be all you need when one platform takes most orders and the other channels are small. The platform's routing rules also have to cover all your locations. The Shopify routing and pickup features described above are examples of how much a platform can handle.
These are the usual signs that a dedicated OMS is worth the cost:
- One channel oversells because another channel's sale has not reached it yet.
- Someone exports marketplace orders and types them into the ERP or warehouse system.
- Each channel has its own price list or currency, and those rules live in spreadsheets.
- Staff open three systems to find out where an order is.
- Adding a channel or a second warehouse feels like a project rather than a settings change.
- A return on one channel does not put stock back on sale for the others.
If only one of these applies, a better connector may fix it. If most apply, the deeper problem is that no single system owns the order.
From there, the choice comes down to three routes:
- Buying an OMS gets you multichannel order management software with pre-built connectors, though you still map data and test. The risk is that your process bends to the product, and edge cases need workarounds.
- Extending your platform fits when one platform holds most orders and the extra channels are simple. Over time, plugins can overlap and logic spreads across apps that no one owns.
- A custom order layer makes sense when your pricing, allocation or approval rules are part of how you compete. Contract pricing per B2B account and approval steps before an order can ship are typical examples. You then own the maintenance, testing and on-call work.
We think retailers with a standard order flow should buy, because setting up a product is usually faster and cheaper than building one. Many companies end up in between. They keep a commercial platform or ERP as the system of record. On top of it they build a thin order layer for the rules the products cannot express. That option is worth pricing before anyone agrees to replace everything.
Examples from our own work
Two of our commerce engagements show these problems in practice. Both were for private clients, so we describe the engineering and leave out business results.
In our multichannel commerce and order management case study, each selling channel sets its own prices and currency, along with its own warehouse preferences and order rules. All the storefronts still share one GraphQL API. Warehouse stock, checkout reservations and order allocations stay as three separate records, so an allocation promises the units while only a fulfillment lowers the physical count.
Payment could happen before the order existed in that system, so each request carries an idempotency key, a unique label that lets the system spot a repeat. When a checkout has already produced an order, its token leads straight back to that order. A capture request alone does not raise the amount charged, because the payment app still has to report the charge. Automatic checkout completion, the release of held funds and permission to fulfill unpaid orders are separate settings, each matched to the channel's payment policy.
Our configurable commerce, payments and inventory workflows project took a different route. Orders move through a state machine, a fixed set of stages with checks at each step, so a new storefront or extension cannot push an order forward without doing the required work. Stock is held by location, and an append-only ledger records each allocation and release along with sales and stock adjustments. The project also shows the allocation-after-payment case from the list above. Under the default payment-stage policy, a stock shortfall can leave an order both paid and placed. The order then emits an event that someone on staff has to handle.
What to bring to a vendor or build partner
Quotes are easier to compare when every vendor works from the same inputs:
- A list of every channel, with rough monthly order counts and how orders arrive today.
- Every system the OMS must connect to, and which one owns stock, prices and customer records.
- Your pricing, allocation and routing rules, written as testable statements.
- The failure cases above, with what you want to happen in each.
- The person inside your company who can settle disagreements between teams.
FAQ
What is omnichannel order management?
It is the process and software for handling orders from every sales channel as one flow. One set of rules manages stock across warehouses and stores, decides where each order ships from, and handles fulfillment and returns. That includes orders that cross channels, such as buy online, pick up in store.
What is the difference between multichannel and omnichannel order management?
Only omnichannel lets one purchase cross channels, such as buying online and returning in a store. A multichannel order management system shares stock and orders across separate channels, and each channel keeps its own flow. The integrations are similar, while the routing and returns rules are harder in an omnichannel setup.
Is multichannel order management software the same as an ERP?
An ERP usually owns finance, purchasing and product data. An OMS owns the order from capture to delivery. Some ERPs include order management features, and many businesses run both and connect them.
Can I use my ecommerce platform as an OMS?
Often you can, if most orders come through one platform and your other channels are small. Shopify has order routing rules, for example. Adobe Commerce reserves stock as soon as an order is submitted. It gets harder when several channels, warehouses or price lists need rules the platform does not support.
What are the stages of the order management process?
An order is captured first, then allocated and routed to a location. After that it is fulfilled, and any return or refund comes last. Omnichannel setups add rules for orders that cross channels, such as store pickup and in-store returns.
Why do retries cause integration problems?
Channels and payment providers retry when they do not get a quick reply, so one event can reach the OMS twice. Shopify's developer documentation, for example, says an app might receive the same webhook more than once. The system has to recognize repeats and handle payments that arrive before or after the order exists.
Next step
If you are weighing a commercial OMS against extending your platform or building an order layer, our ecommerce solutions and commerce engineering page explains how we approach this work. Our retail and commerce systems page shows the kinds of integrations we handle. When you have your channels and rules written down, you can get an estimate for your order management project.
