上一篇筆者為大家介紹了訂單系統中關于提交訂單操作相關的問題：《從0到1構建電商平臺之訂單系統(1)：提交訂單》，提交訂單之后，接下來要做的是“支付訂單”。

電商平臺主要會涉及商家系統、商品系統、訂單系統、售后系統、會員系統、營銷系統、財務系統、數據系統等。我會把訂單系統的文章拆分成三篇，本篇是第二篇。

雖然每個公司的具體需求與業務場景不一樣，我們平臺的功能需求可能其他平臺不盡相同，但整個訂單的產生到結束的，主要有以下3個流程：

上一篇文章我們是寫的是提交訂單這一步操作，當用戶把訂單提交后此時后臺會有兩步操作：

1）拆單

由購物車進入提交訂單頁面時可能有多商家多商品的情況，一旦提交了訂單就會涉及到拆單（不管是否成功支付），一般來說最簡單的是按商家拆，拆完后分別流轉至相應的商家后臺，用戶在客戶端的訂單列表也會看到多個子訂單；如果業務場景要求的話可以再按倉庫等維度拆，這里不做展開；

2）生成賬單

生成賬單的目的是為了記錄該筆母訂單的金額，如商品金額、抵扣總金額、各商品分別抵扣金額、用戶需支付金額等，用戶將要支付的是母訂單的賬單，當該筆賬單已完成，則各子訂單狀態跳轉為待發貨；

注意，如果用戶在支付頁面退出，此時賬單也會隨著商家拆分成各子賬單，因為用戶可以在訂單列表里分別對拆分后的子訂單進行支付

下面是支付頁面的字段和各項判斷流程：

一、支付方式

1. 支付寶/微信等三方支付

由開發同學對接好三方支付平臺的接口即可，這里不做展開。

2. 余額支付

用戶在平臺會通過一定的方式獲取余額（非充值，也非用來抵扣的金幣，是一種支付方式），此時有2種情況：

1）金幣完全抵扣

當金幣能完全抵扣時，在支付頁面可以只顯示余額支付；因為此時支付金額雖然為0，但需要選擇余額支付并輸入支付密碼，目的是為了防止被他人盜用（當用戶選擇支付寶/微信支付時需輸入支付密碼，相當于已經起到了防止作用）

2）金幣非完全抵扣/未抵扣

此時用戶只能選擇一種支付方式，但如果余額小于支付金額只能選擇支付寶/微信。

二、?判斷流程與思考

1. 鎖定庫存：兩種方案

1）提交訂單即鎖庫存

這樣做的優點是用戶的體驗較好，我提交了訂單這個商品就是我的了，我可以慢慢付款；

缺點是可能會導致真正有購買需求的用戶無法購買，比如甲用戶先提交訂單鎖定了庫存他還在考慮中，不一定會買，但是乙用戶想立即購買確發現沒貨了（也不排除有人惡意下單鎖定庫存）

所以待付款訂單一般都會有剩余支付時間，比如30分鐘，到了時間自動取消訂單并釋放庫存，或者在添加商品的sku時設置單人限購數量，這樣一個賬號只能在某一段時間內購買n次，同時技術上也可以做限制，同一ip只能購買n次

2）支付成功才鎖庫存

這樣做的優點是可以篩掉惡意下單的情況；缺點是用戶的體驗會差一些，可能付款慢一點就會失去購買的機會。

我們平臺采用的是a方案，可以根據不同的業務場景選擇不同的方案。

2. 是否能下架商品？

進入支付頁面說明該訂單已生成，且處于待付款狀態，此時需要注意的是此時商家是否能下架商品。

1）能

可能會導致用戶在已經支付訂單時提示商品已下架，因為此時訂單已經生成，處于待付款狀態；只有讓系統自動取消該訂單，但對用戶是比較不友好的

2）不能

對商家是不友好的，因為判斷條件為訂單處于待付款，此時用戶可能不付款退出，訂單也會處于待付款；

衍生的情況就比較麻煩了，哪怕待付款訂單自動取消的時間為30分鐘，也會存在不斷有用戶下單，商家就可能一直不能下架商品，后續的問題可能會更大，但如果此時限制其他用戶不能下單，那么就在技術與商家的操作上都會比較復雜（具體的操作這里不做展開）。

我暫時沒有想更好的解決方案，采用的第一種方案。

3. 驗證sku信息是否更改

當訂單處于待付款時商家修改了sku（下架商品 – 編輯商品 – 工作人員審核上架），該訂單同樣不能付款，因為和此時的商品信息甚至金額可能和之前發生了改變，與之衍生的可能就是商家與用戶的糾紛。

注意：如果采用的是商家不能下架商品的方案，則這一點就不用驗證（所以2、3兩點沒在流程圖上體現出來）。

4. 是否支付成功

支付成功即生成待發貨訂單，立即鎖定庫存。

支付失敗則還是為待付款訂單，然后開始倒計時；一般平臺商品庫存充足倒計時可長一點，對用戶會友好一點，庫存不怎么充足或者平臺上入駐的小商家居多，平臺無法控制商家的庫存或者下架之類的操作；

如果也考慮到時間給用戶帶來的緊迫感的話，時間可以短一些；時間一到訂單狀態就應變成已關閉狀態，用戶無法支付，同時釋放庫存。

訂單成功支付后就需要商家處理訂單了，同時用戶也可以進行一些操作，下一篇“處理訂單”。

本文由 @張璨 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。