訂單是電商體系的核心，有了訂單才有業績和盈利，才有談發展、談夢想的可能性。之所以把訂單中心放在最後的部分講，除了為體現訂單中心的重要性，主要是因為訂單中心是建立在其他系統模塊的基礎上，只有理解了其他系統的產品設計，才能更透徹地理解訂單中心的運作。
訂單中包含商品、優惠、用戶、收貨信息、支付信息等一系列的訂單實時數據。通過訂單中心，實現對線上訂單、線下訂單及第三方訂單的管理，支持訂單接收、訂單自動合併與拆分、自動匹配倉庫、庫存控制、自動匹配快遞、結算與支付等訂單生命週期中的一系列協同作業。
依靠靈活多變的訂單產品設計架構，可滿足電商企業百萬級的訂單業務處理需求，提升訂單流轉的工作效率。
在訂單生成之後，會隨著訂單的流轉更新狀態。不同業務類型的訂單狀態，例如機票、服務訂單、商品服務訂單等，和最常見的純實物商品的訂單狀態會有所區別。以實物商品為例，我們來討論一下訂單狀態的流轉。訂單狀態主要有以下幾種類型。
（1）待付款：用戶剛提交訂單，尚未付款，等待用戶支付。由於待付款狀態會鎖定庫存，所以一般會設置超時自動取消（如0.5小時、1小時、24小時等時限）功能。
（2）待發貨：用戶付款之後，等待商家發貨。
（3）待收貨：商家已發貨，等待用戶收貨。
（4）交易成功：用戶確認收貨之後，訂單已完成交易。
（5）已取消：付款之前取消訂單。超時未付款或用戶取消訂單都會產生這種訂單狀態。
（6）售後中：用戶在付款後發貨前申請退款，或商家發貨後用戶申請退、換貨，都會產生這種訂單狀態。訂單售後狀態又分許多種，後面詳述。
（7）交易關閉：當售後完成後的訂單狀態。「已取消」的訂單狀態可以合併到「交易關閉」中。
訂單狀態的正常流轉是：１待付款、２待發貨、３待收貨、４交易成功。但訂單會有逆向流程，和發生的時間節點及類型相關，情況也很複雜多變。
訂單的售後狀態主要有以下幾種。
（1）待審核：用戶提交退貨、退款申請之後，等待審核的狀態。在用戶已付款待發貨的狀態下，訂單未推送至倉庫或者在倉庫攔截發貨成功，系統可直接審核通過。當審核不通過時，回到正常流程中。
（2）待退貨入庫：退貨申請審核通過，等待用戶退貨入庫。
（3）待退款：退貨入庫成功後，等待退款給用戶。
（4）待換貨入庫：換貨申請審核通過，等待用戶換貨入庫。
（5）換貨出庫中：換貨入庫之後，生成換貨出庫單，訂單出庫。
（6）售後成功：當退貨、退款成功或換貨成功之後，流轉至「售後成功」狀態。退貨、退款的售後成功在主流程下屬於「交易關閉」。
在售後管理中，還有一個值得思考的環節：多次售後。當換貨成功之後，在流程上還是允許客戶有售後環節的。那麼在產品設計中，就應該考慮允許用戶多次發起售後。另外系統應設置申訴週期，保證商家利益，例如：在發貨之後7天自動確認收貨，交易成功15天後售後通道關閉。