Mastering E‑Commerce Order Systems: Architecture, Statuses, and Reverse Flows

Order Center is the hub of an e‑commerce backend system; it reads data from multiple modules, processes it, and passes it to the next stage, making the order module essential for any e‑commerce platform.

Orders are the core of a company's survival and profit, and the order system is the carrier that supports order processing, so its design is crucial.

1. Order Architecture

Understanding the order system starts with its information architecture, which provides an overall view.

2. Order Status

Definition: To meet organizational division of labor and improve efficiency, the system splits the entire transaction process into several controllable stages.

1. Forward Order Status

Pending Payment: After the user submits an order but before payment; inventory is locked and an automatic timeout cancellation is set.

Pending Shipment: After payment, waiting for the merchant to ship.

Pending Receipt: After shipment, waiting for the user to receive.

Completed: After the user confirms receipt, the transaction is finished.

Cancelled: Cancelled before payment; either timeout without payment or user‑initiated cancellation.

After‑sale: User requests refund before shipment, or requests return/exchange after shipment.

2. After‑sale Order Status

Pending Review: After a return/exchange request, waiting for review. If the order has not been pushed to the warehouse, it can be approved directly; otherwise it returns to the normal flow if not approved.

Pending Return to Warehouse: After review approval, waiting for the user to return the goods.

Pending Refund: After successful return to warehouse, waiting to refund the user.

Pending Exchange to Warehouse: After exchange request approval, waiting for the user to send the exchanged item.

Exchange Outbound: After exchange is received, an outbound order is generated.

After‑sale Success: After successful return and refund, the after‑sale status moves to transaction closed.

3. Order Placement Flowchart

1. Security check during order processing to detect blacklisted users or abnormal purchase behavior; abort if abnormal.

2. Retrieve product information (SKU, specifications, price) from the product center.

3. Retrieve promotional information (coupons, campaigns) from the marketing center and calculate discount.

4. Get member benefits (points, coupon conditions) from the member center.

5. Verify inventory in the scheduling center and lock regional stock according to scheduling rules.

6. Split the order into sub‑orders according to split rules (merchant, warehouse, order type, etc.), calculate freight based on templates, and compute the payable amount (product amount + freight – discounts).

3. Discount Allocation

Definition: Distribute the total order discount to each SKU for settlement.

Actual payment = Product amount (total SKU amount) + Freight – Total discount

Total discount = Promotion discount + Coupon discount + Virtual currency deduction

Allocation is based on the proportion of each product.

Example: An order contains items A, B, C, D, E from stores A and B, with free shipping. Items A and D participate in a cross‑store “spend 200, save 40” promotion (Promotion 1); items B and C participate in a “spend 100, save 10” promotion (Promotion 2). The user also uses a ¥100 cash coupon.

Order discount = 40 + 10 + 100 = ¥150.

According to the discount allocation principle, the discount for each item is:

4. Order Splitting

Definition: To facilitate shipping and settlement, the system splits a user order into multiple delivery orders based on rules such as logistics and warehouse.

Different stores: In multi‑store platforms, orders are split by store for financial settlement and logistics.

Different warehouses: If items are stocked in different warehouses, the order is split according to warehouse ownership, selecting the warehouse based on regional logistics timeliness.

Different categories: Certain product attributes (fragile, oversized) require separate packaging, leading to split.

Logistics factors: Carriers impose weight or volume limits per package; the system calculates total weight/volume per SKU and splits when limits are exceeded.

Product value: High‑value or cross‑border items may need splitting due to customs limits.

The forward order flow is relatively straightforward, involving data exchange among product, logistics, member, warehouse, and content modules.

The reverse order flow is more complex because each forward stage can trigger a reverse task, and different nodes have different handling rules.

Reverse Order Flow

Definition: Handles returns and refunds that occur during the order process. Both user‑initiated and merchant‑initiated triggers exist.

User‑initiated

1. Cancel Order While Pending Payment

Two cases: user cancels voluntarily or system auto‑cancels after timeout, changing status to Cancelled. No customer service review is needed.

2. Cancel Order While Pending Shipment

If the order is cancelled after payment but before shipment, the system must check whether the order has been pushed to the warehouse. If not, stop pushing; if already pushed, intercept at the WMS. If interception fails, the cancellation is rejected; if successful, the order is cancelled, the refund process starts, and the warehouse receives a return order.

3. Return After Pending Receipt / Transaction Completed

After the user submits a return request, customer service reviews it. Upon approval, the system provides return address, generates a return inbound order, and refunds after warehouse receipt. Full returns move the original order to closed; partial returns keep the original order in its current state while creating a separate after‑sale order for the returned items.

Note: When financial data is involved in reverse flows, it must not be modified directly in the original order to ensure data authenticity and traceability.