起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識從0到1構建電商平臺之訂單系統（2）：支付訂單
上一篇筆者為大家介紹了訂單系統中關于提交訂單操作相關的問題：《從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協議。
期待老師寫關于結構化能力、商業洞察、需求洞察、抽象能力、架構能力、逆向思維等方面的文章?。?！
為什么會有鎖定庫存和扣除庫存兩種狀態，他們起到的效果其實是一樣的，都是讓前端顯示的可售庫存-1，其他用戶無法購買到這件商品，那么是不是可以在提交訂單的時候就扣除庫存，而不是鎖定庫存，如果訂單取消，那么再歸還庫存，這樣還能少一個狀態，簡化流程，也可避免一些該狀態下的衍生問題。
鎖定可以恢復，但是扣除就不能恢復
扣除也可以恢復呀，反正記錄了扣除的數量，到時候相應的增加對應數量不就等于恢復嗎
1、支付后，多個子訂單的變成“待發貨”狀態，那要是其中部分商家發貨了，部分商家還沒有發貨。請問母訂單的訂單狀態時什么？
已發貨？待發貨？部分發貨？
2、那如果部分發貨中有的商品已經收貨了是待評價，部分商品待收貨，那子訂單狀態是什么？
待評價？待收貨？部分收貨？
2-1、母訂單的狀態又是什么？
3、如果收貨的商品中有部分（數量）售后，那又會不會影響到商品的在狀態顯示？如果會，那又會不會繼續傳承到子訂單和母訂單的狀態呢？
支付后拆單是對不同商家一并支付的情況（購物車下單），所以拆了之后就沒有你說的這個母訂單了
所以你下面的這些問題不成立了
http://www.aharts.cn/pd/2976600.html
http://www.aharts.cn/pd/3298531.html
你可以看一下我的這兩篇文章
待付款就拆單了，不然后面任意選擇性支付，和未支付已支付的商品處理賊煩.一個總單對應子單，支付后未支付的形成新的一個總單
對頭，從后端的角度來說處理起來確實很煩
是否能下架商品第三種方案：
可以下架，后續用戶下單時提示商品已下架無法下單，向商家端提供已生成訂單且處于待支付狀態的訂單數量，讓商家決定這部分訂單是否可付款繼續流轉下去。
考慮場景：下架商品時，因為待支付訂單自動取消時長為30分鐘，這30分鐘內已經生成大量待支付訂單，針對于這部分訂單商家允許客戶繼續支付及后續流轉。
對，相當于就是加了一個判斷，支付時間大于下架時間的訂單會標注出來，商家可以看見，如果要取消可以主動與用戶聯系
比如，用戶3點59提交了訂單，此時創建了訂單，4點01支付成功，但4點00的時候商家下架了該商品，此筆訂單就標注出來告知用戶
作者寫鎖定庫存這塊，我覺得支付后鎖定庫存適合“搶購或者大型活動”時使用，讓用戶有緊迫感，不趕緊支付商品就有被搶光的風險；正常場景還是提交就鎖定更友好；
是的，所以得看具體的業務場景；如果一個平臺有兩種鎖庫存的方式，不同的業務場景一定要提醒清楚用戶，不然會引起糾紛的，畢竟涉及到錢的事
當年淘寶就因為這個事情好像爭執了很久…
寫的很棒！
謝謝，哈哈
用戶側拆單的原因是什么？
不是用戶拆單，是用戶下單的時候可能選擇了多個商家的商品一起下單，平臺會進行拆單。平臺最終是要把訂單推送給商家，由商家聯系發貨。結算的時候也是和商家單獨進行結算的
是這樣的，用戶側也拆單的主要原因我認為是，因為每個商家是單獨發貨，用戶更關心訂單的物流情況，拆單之后查看物流、聯系賣家操作上會更方便一些，頁面更清楚一些，其他的原因我暫時就沒想到了
這樣對用戶來說體驗好嗎？
你的出發點是物流查詢，物流查詢可以以其他的方式展示啊，比如多個物流單號，點擊以后進入物流詳情頁中（可能有更優的方案）
用戶側待付款訂單拆成多筆支付，這個就很扯了….購物車里面不就是多筆訂單合并付款，你現在還要整成多筆待支付，會不會有點反人類….
用戶側拆單是根據商家來拆的，不同商家是不同的訂單，用戶側沒有子訂單的概念，也沒有說待付款的需要拆成子訂單去付款
第一，商家發物流的情況有很多，比如一個商品拆分成多個包裹，多個商品合并成一個包裹進行發貨，碰到這種情況查看物流的時候就需要告知用戶哪些商品在哪個包裹里，再加上多個商家，頁面就會更亂；功能是可以做，只是看有沒有必要
第二，既然商家端都拆了，用戶端拆了之后，取消訂單，確認收貨等操作會更清晰一些，現在主流的設計都是確認收貨/取消訂單都是對訂單而不是單個商品，如果多商家都放在一個訂單里，比如有些商家一直沒貨需要很久才發貨，另外一個商家的貨早就收到了，確認收貨就確認不了，商家也就結算不了，如果設計成能對單個商家收貨，那這不更亂了嗎，既然如此，商家看到的是子訂單，用戶看到的也是子訂單
第三，在后端代碼那里，一般都是提交訂單之后，就創建訂單，這個時候就需要拆分成子訂單，寫入數據庫，而不是支付之后才拆，如果是支付之后再拆，那么待付款的訂單就進入不了商家后臺，也就不能進行訂單改價等操作，說到這里，訂單改價也是影響用戶端拆分訂單的因素之一，支付只能對訂單支付，如果訂單處于待付款的時候不拆，商家改價在后端邏輯來說就會很麻煩，功能是可以做，只是看有沒有必要，簡單的事就是直接一拆就好了，如果不拆反而會衍生很多問題，就需要做更多的事去解決
文章里面說的是：用戶在客戶端上看到的是多個子訂單，如果沒付款，是需要對子訂單單獨付款的
如果是沒付款，單從用戶端來說，的確不該拆單！
在后端代碼那里，一般都是提交訂單之后，就創建訂單，這個時候就需要拆分成子訂單，寫入數據庫，而不是支付之后才拆，如果是支付之后再拆，那么待付款的訂單就進入不了商家后臺，也就不能進行訂單改價等操作，訂單改價也是影響用戶端拆分訂單的因素之一，支付只能對訂單支付，如果訂單處于待付款的時候不拆，商家改價在后端邏輯來說就會很麻煩，功能是可以做，只是看有沒有必要，簡單的事就是直接一拆就好了，如果不拆反而會衍生很多問題，就需要做更多的事去解決
每個電商平臺都不一樣，有的會記錄待支付的訂單狀態（PC），有的只會記錄支付取消的狀態，但是不管是記錄待支付的狀態還是支付取消的狀態，對于后端來說，必然會拆單。但是對于APP用戶來說，他還沒完成支付，沒必要拆單，而且你拆單就意味著， 之前的一筆訂單，他再次支付，需要支付N次（N個店鋪），這個體驗相都不用想，肯定不好。
像淘寶京東都是待付款時就會拆單，可以自己試一下，他們為什么這么設計我不清楚，但是可以確定的是他們一定是踩過各種坑才這樣做的，對于我們來說只能借鑒他們的做法，這樣對公司肯定是最負責的，然后自己只能盡量去分析他們為什么這么做，為什么不這么做，分清楚哪些是必須這樣做，哪些是這樣做更好，像用戶端拆單這塊，我認為是這樣做更好，暫時沒找到必須這樣做的理由
京東淘寶在沒支付完成之前，用戶看到的永遠只有一個訂單，不會分開顯示的。
這么說吧，拆單是必然的，但是在沒支付完成前，用戶是感知不到的。我覺得我們想法差不多，但是沒溝通清楚！
我剛剛試了一下，待付款的訂單，淘寶會拆，京東不會拆，但是淘寶支持訂單改價，京東我查了一下好像不支持；淘寶訂單的自動取消是24小時，京東是30分鐘，我猜想可能京東是支付后才后臺進行拆單，這時子訂單才會進入商家后臺，可能業務場景不一樣吧，京東希望用戶盡快付款，而淘寶會留時間給用戶與商家協商
說到支付N次這個問題，哪種方案更好還是要看具體業務場景，就像我剛剛說的，比如要改價之類的操作，肯定下單就拆的方案會好很多，當然在支付頁面就退出的發生頻次肯定比改價的場景多得多，但是我認為用戶并不會因為這一小點就放棄這個平臺，因為這是用戶自己的選擇
當然，我的想法肯定有一定的局限性，這些都是我們的推測，我也只能盡量去推測他們為什么這么做的意圖 ??
我認為這個和改價的關系不是很大，更重要的是淘寶和京東的經營模式不太一樣，
不用去推測他們的意圖，你要考慮你準備給用戶什么樣的體驗
用戶一次能干完的事情，你非要用戶干好多遍，而且是重復的，是不是make trouble了？
設計不能完美解決用戶的訴求，但是也別制作麻煩啊
第一，推測大廠的產品意圖再來設計，對公司來說是最負責的，因為大廠肯定踩過無數的坑才會最終成型，比如我們平臺的經營模式更接近于淘寶，而在邏輯設計上更偏向于京東，如果不去推測他們意圖，只知其然而不知其所以然，如果在流程上出問題了，這個責任就大了，雖然自己的推測不一定是對的，但是至少自己思考過了，權衡過了，而不是盲目的去借鑒
第二，像待付款訂單拆單，看起來只關乎用戶體驗，背后說大點和平臺的定位有關，不然為什么淘寶就拆了，難道淘寶的產品經理不會考慮用戶體驗嗎？至少在我看來，我會同時關注數據的完整性，后端的開發邏輯，數據庫的結構設計，而不是僅僅考慮用戶的操作體驗；比如提交訂單后訂單其實是拆了，這個時候如果用戶端不拆實際上就是套了一層殼子，看起來是一層殼子，涉及到金錢的功能，背后的邏輯都很復雜，而且容易出錯，像我們之前開發時間相當緊，做個權衡，現階段沒必要，用戶也不會因為沒有這層殼子而放棄我們平臺
??