從0到1構(gòu)建電商平臺之訂單系統(tǒng)(2):支付訂單
上一篇筆者為大家介紹了訂單系統(tǒng)中關(guān)于提交訂單操作相關(guān)的問題:《從0到1構(gòu)建電商平臺之訂單系統(tǒng)(1):提交訂單》,提交訂單之后,接下來要做的是“支付訂單”。
電商平臺主要會涉及商家系統(tǒng)、商品系統(tǒng)、訂單系統(tǒng)、售后系統(tǒng)、會員系統(tǒng)、營銷系統(tǒng)、財務(wù)系統(tǒng)、數(shù)據(jù)系統(tǒng)等。我會把訂單系統(tǒng)的文章拆分成三篇,本篇是第二篇。
雖然每個公司的具體需求與業(yè)務(wù)場景不一樣,我們平臺的功能需求可能其他平臺不盡相同,但整個訂單的產(chǎn)生到結(jié)束的,主要有以下3個流程:
上一篇文章我們是寫的是提交訂單這一步操作,當(dāng)用戶把訂單提交后此時后臺會有兩步操作:
1)拆單
由購物車進(jìn)入提交訂單頁面時可能有多商家多商品的情況,一旦提交了訂單就會涉及到拆單(不管是否成功支付),一般來說最簡單的是按商家拆,拆完后分別流轉(zhuǎn)至相應(yīng)的商家后臺,用戶在客戶端的訂單列表也會看到多個子訂單;如果業(yè)務(wù)場景要求的話可以再按倉庫等維度拆,這里不做展開;
2)生成賬單
生成賬單的目的是為了記錄該筆母訂單的金額,如商品金額、抵扣總金額、各商品分別抵扣金額、用戶需支付金額等,用戶將要支付的是母訂單的賬單,當(dāng)該筆賬單已完成,則各子訂單狀態(tài)跳轉(zhuǎn)為待發(fā)貨;
注意,如果用戶在支付頁面退出,此時賬單也會隨著商家拆分成各子賬單,因?yàn)橛脩艨梢栽谟唵瘟斜砝锓謩e對拆分后的子訂單進(jìn)行支付
下面是支付頁面的字段和各項(xiàng)判斷流程:
一、支付方式
1. 支付寶/微信等三方支付
由開發(fā)同學(xué)對接好三方支付平臺的接口即可,這里不做展開。
2. 余額支付
用戶在平臺會通過一定的方式獲取余額(非充值,也非用來抵扣的金幣,是一種支付方式),此時有2種情況:
1)金幣完全抵扣
當(dāng)金幣能完全抵扣時,在支付頁面可以只顯示余額支付;因?yàn)榇藭r支付金額雖然為0,但需要選擇余額支付并輸入支付密碼,目的是為了防止被他人盜用(當(dāng)用戶選擇支付寶/微信支付時需輸入支付密碼,相當(dāng)于已經(jīng)起到了防止作用)
2)金幣非完全抵扣/未抵扣
此時用戶只能選擇一種支付方式,但如果余額小于支付金額只能選擇支付寶/微信。
二、?判斷流程與思考
1. 鎖定庫存:兩種方案
1)提交訂單即鎖庫存
這樣做的優(yōu)點(diǎn)是用戶的體驗(yàn)較好,我提交了訂單這個商品就是我的了,我可以慢慢付款;
缺點(diǎn)是可能會導(dǎo)致真正有購買需求的用戶無法購買,比如甲用戶先提交訂單鎖定了庫存他還在考慮中,不一定會買,但是乙用戶想立即購買確發(fā)現(xiàn)沒貨了(也不排除有人惡意下單鎖定庫存)
所以待付款訂單一般都會有剩余支付時間,比如30分鐘,到了時間自動取消訂單并釋放庫存,或者在添加商品的sku時設(shè)置單人限購數(shù)量,這樣一個賬號只能在某一段時間內(nèi)購買n次,同時技術(shù)上也可以做限制,同一ip只能購買n次
2)支付成功才鎖庫存
這樣做的優(yōu)點(diǎn)是可以篩掉惡意下單的情況;缺點(diǎn)是用戶的體驗(yàn)會差一些,可能付款慢一點(diǎn)就會失去購買的機(jī)會。
我們平臺采用的是a方案,可以根據(jù)不同的業(yè)務(wù)場景選擇不同的方案。
2. 是否能下架商品?
進(jìn)入支付頁面說明該訂單已生成,且處于待付款狀態(tài),此時需要注意的是此時商家是否能下架商品。
1)能
可能會導(dǎo)致用戶在已經(jīng)支付訂單時提示商品已下架,因?yàn)榇藭r訂單已經(jīng)生成,處于待付款狀態(tài);只有讓系統(tǒng)自動取消該訂單,但對用戶是比較不友好的
2)不能
對商家是不友好的,因?yàn)榕袛鄺l件為訂單處于待付款,此時用戶可能不付款退出,訂單也會處于待付款;
衍生的情況就比較麻煩了,哪怕待付款訂單自動取消的時間為30分鐘,也會存在不斷有用戶下單,商家就可能一直不能下架商品,后續(xù)的問題可能會更大,但如果此時限制其他用戶不能下單,那么就在技術(shù)與商家的操作上都會比較復(fù)雜(具體的操作這里不做展開)。
我暫時沒有想更好的解決方案,采用的第一種方案。
3. 驗(yàn)證sku信息是否更改
當(dāng)訂單處于待付款時商家修改了sku(下架商品 – 編輯商品 – 工作人員審核上架),該訂單同樣不能付款,因?yàn)楹痛藭r的商品信息甚至金額可能和之前發(fā)生了改變,與之衍生的可能就是商家與用戶的糾紛。
注意:如果采用的是商家不能下架商品的方案,則這一點(diǎn)就不用驗(yàn)證(所以2、3兩點(diǎn)沒在流程圖上體現(xiàn)出來)。
4. 是否支付成功
支付成功即生成待發(fā)貨訂單,立即鎖定庫存。
支付失敗則還是為待付款訂單,然后開始倒計(jì)時;一般平臺商品庫存充足倒計(jì)時可長一點(diǎn),對用戶會友好一點(diǎn),庫存不怎么充足或者平臺上入駐的小商家居多,平臺無法控制商家的庫存或者下架之類的操作;
如果也考慮到時間給用戶帶來的緊迫感的話,時間可以短一些;時間一到訂單狀態(tài)就應(yīng)變成已關(guān)閉狀態(tài),用戶無法支付,同時釋放庫存。
訂單成功支付后就需要商家處理訂單了,同時用戶也可以進(jìn)行一些操作,下一篇“處理訂單”。
本文由 @張璨 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于CC0協(xié)議。
期待老師寫關(guān)于結(jié)構(gòu)化能力、商業(yè)洞察、需求洞察、抽象能力、架構(gòu)能力、逆向思維等方面的文章?。?!
為什么會有鎖定庫存和扣除庫存兩種狀態(tài),他們起到的效果其實(shí)是一樣的,都是讓前端顯示的可售庫存-1,其他用戶無法購買到這件商品,那么是不是可以在提交訂單的時候就扣除庫存,而不是鎖定庫存,如果訂單取消,那么再歸還庫存,這樣還能少一個狀態(tài),簡化流程,也可避免一些該狀態(tài)下的衍生問題。
鎖定可以恢復(fù),但是扣除就不能恢復(fù)
扣除也可以恢復(fù)呀,反正記錄了扣除的數(shù)量,到時候相應(yīng)的增加對應(yīng)數(shù)量不就等于恢復(fù)嗎
1、支付后,多個子訂單的變成“待發(fā)貨”狀態(tài),那要是其中部分商家發(fā)貨了,部分商家還沒有發(fā)貨。請問母訂單的訂單狀態(tài)時什么?
已發(fā)貨?待發(fā)貨?部分發(fā)貨?
2、那如果部分發(fā)貨中有的商品已經(jīng)收貨了是待評價,部分商品待收貨,那子訂單狀態(tài)是什么?
待評價?待收貨?部分收貨?
2-1、母訂單的狀態(tài)又是什么?
3、如果收貨的商品中有部分(數(shù)量)售后,那又會不會影響到商品的在狀態(tài)顯示?如果會,那又會不會繼續(xù)傳承到子訂單和母訂單的狀態(tài)呢?
支付后拆單是對不同商家一并支付的情況(購物車下單),所以拆了之后就沒有你說的這個母訂單了
所以你下面的這些問題不成立了
http://zhangjingwei.cn/pd/2976600.html
http://zhangjingwei.cn/pd/3298531.html
你可以看一下我的這兩篇文章
待付款就拆單了,不然后面任意選擇性支付,和未支付已支付的商品處理賊煩.一個總單對應(yīng)子單,支付后未支付的形成新的一個總單
對頭,從后端的角度來說處理起來確實(shí)很煩
是否能下架商品第三種方案:
可以下架,后續(xù)用戶下單時提示商品已下架無法下單,向商家端提供已生成訂單且處于待支付狀態(tài)的訂單數(shù)量,讓商家決定這部分訂單是否可付款繼續(xù)流轉(zhuǎn)下去。
考慮場景:下架商品時,因?yàn)榇Ц队唵巫詣尤∠麜r長為30分鐘,這30分鐘內(nèi)已經(jīng)生成大量待支付訂單,針對于這部分訂單商家允許客戶繼續(xù)支付及后續(xù)流轉(zhuǎn)。
對,相當(dāng)于就是加了一個判斷,支付時間大于下架時間的訂單會標(biāo)注出來,商家可以看見,如果要取消可以主動與用戶聯(lián)系
比如,用戶3點(diǎn)59提交了訂單,此時創(chuàng)建了訂單,4點(diǎn)01支付成功,但4點(diǎn)00的時候商家下架了該商品,此筆訂單就標(biāo)注出來告知用戶
作者寫鎖定庫存這塊,我覺得支付后鎖定庫存適合“搶購或者大型活動”時使用,讓用戶有緊迫感,不趕緊支付商品就有被搶光的風(fēng)險;正常場景還是提交就鎖定更友好;
是的,所以得看具體的業(yè)務(wù)場景;如果一個平臺有兩種鎖庫存的方式,不同的業(yè)務(wù)場景一定要提醒清楚用戶,不然會引起糾紛的,畢竟涉及到錢的事
當(dāng)年淘寶就因?yàn)檫@個事情好像爭執(zhí)了很久…
寫的很棒!
謝謝,哈哈
用戶側(cè)拆單的原因是什么?
不是用戶拆單,是用戶下單的時候可能選擇了多個商家的商品一起下單,平臺會進(jìn)行拆單。平臺最終是要把訂單推送給商家,由商家聯(lián)系發(fā)貨。結(jié)算的時候也是和商家單獨(dú)進(jìn)行結(jié)算的
是這樣的,用戶側(cè)也拆單的主要原因我認(rèn)為是,因?yàn)槊總€商家是單獨(dú)發(fā)貨,用戶更關(guān)心訂單的物流情況,拆單之后查看物流、聯(lián)系賣家操作上會更方便一些,頁面更清楚一些,其他的原因我暫時就沒想到了
這樣對用戶來說體驗(yàn)好嗎?
你的出發(fā)點(diǎn)是物流查詢,物流查詢可以以其他的方式展示啊,比如多個物流單號,點(diǎn)擊以后進(jìn)入物流詳情頁中(可能有更優(yōu)的方案)
用戶側(cè)待付款訂單拆成多筆支付,這個就很扯了….購物車?yán)锩娌痪褪嵌喙P訂單合并付款,你現(xiàn)在還要整成多筆待支付,會不會有點(diǎn)反人類….
用戶側(cè)拆單是根據(jù)商家來拆的,不同商家是不同的訂單,用戶側(cè)沒有子訂單的概念,也沒有說待付款的需要拆成子訂單去付款
第一,商家發(fā)物流的情況有很多,比如一個商品拆分成多個包裹,多個商品合并成一個包裹進(jìn)行發(fā)貨,碰到這種情況查看物流的時候就需要告知用戶哪些商品在哪個包裹里,再加上多個商家,頁面就會更亂;功能是可以做,只是看有沒有必要
第二,既然商家端都拆了,用戶端拆了之后,取消訂單,確認(rèn)收貨等操作會更清晰一些,現(xiàn)在主流的設(shè)計(jì)都是確認(rèn)收貨/取消訂單都是對訂單而不是單個商品,如果多商家都放在一個訂單里,比如有些商家一直沒貨需要很久才發(fā)貨,另外一個商家的貨早就收到了,確認(rèn)收貨就確認(rèn)不了,商家也就結(jié)算不了,如果設(shè)計(jì)成能對單個商家收貨,那這不更亂了嗎,既然如此,商家看到的是子訂單,用戶看到的也是子訂單
第三,在后端代碼那里,一般都是提交訂單之后,就創(chuàng)建訂單,這個時候就需要拆分成子訂單,寫入數(shù)據(jù)庫,而不是支付之后才拆,如果是支付之后再拆,那么待付款的訂單就進(jìn)入不了商家后臺,也就不能進(jìn)行訂單改價等操作,說到這里,訂單改價也是影響用戶端拆分訂單的因素之一,支付只能對訂單支付,如果訂單處于待付款的時候不拆,商家改價在后端邏輯來說就會很麻煩,功能是可以做,只是看有沒有必要,簡單的事就是直接一拆就好了,如果不拆反而會衍生很多問題,就需要做更多的事去解決
文章里面說的是:用戶在客戶端上看到的是多個子訂單,如果沒付款,是需要對子訂單單獨(dú)付款的
如果是沒付款,單從用戶端來說,的確不該拆單!
在后端代碼那里,一般都是提交訂單之后,就創(chuàng)建訂單,這個時候就需要拆分成子訂單,寫入數(shù)據(jù)庫,而不是支付之后才拆,如果是支付之后再拆,那么待付款的訂單就進(jìn)入不了商家后臺,也就不能進(jìn)行訂單改價等操作,訂單改價也是影響用戶端拆分訂單的因素之一,支付只能對訂單支付,如果訂單處于待付款的時候不拆,商家改價在后端邏輯來說就會很麻煩,功能是可以做,只是看有沒有必要,簡單的事就是直接一拆就好了,如果不拆反而會衍生很多問題,就需要做更多的事去解決
每個電商平臺都不一樣,有的會記錄待支付的訂單狀態(tài)(PC),有的只會記錄支付取消的狀態(tài),但是不管是記錄待支付的狀態(tài)還是支付取消的狀態(tài),對于后端來說,必然會拆單。但是對于APP用戶來說,他還沒完成支付,沒必要拆單,而且你拆單就意味著, 之前的一筆訂單,他再次支付,需要支付N次(N個店鋪),這個體驗(yàn)相都不用想,肯定不好。
像淘寶京東都是待付款時就會拆單,可以自己試一下,他們?yōu)槭裁催@么設(shè)計(jì)我不清楚,但是可以確定的是他們一定是踩過各種坑才這樣做的,對于我們來說只能借鑒他們的做法,這樣對公司肯定是最負(fù)責(zé)的,然后自己只能盡量去分析他們?yōu)槭裁催@么做,為什么不這么做,分清楚哪些是必須這樣做,哪些是這樣做更好,像用戶端拆單這塊,我認(rèn)為是這樣做更好,暫時沒找到必須這樣做的理由
京東淘寶在沒支付完成之前,用戶看到的永遠(yuǎn)只有一個訂單,不會分開顯示的。
這么說吧,拆單是必然的,但是在沒支付完成前,用戶是感知不到的。我覺得我們想法差不多,但是沒溝通清楚!
我剛剛試了一下,待付款的訂單,淘寶會拆,京東不會拆,但是淘寶支持訂單改價,京東我查了一下好像不支持;淘寶訂單的自動取消是24小時,京東是30分鐘,我猜想可能京東是支付后才后臺進(jìn)行拆單,這時子訂單才會進(jìn)入商家后臺,可能業(yè)務(wù)場景不一樣吧,京東希望用戶盡快付款,而淘寶會留時間給用戶與商家協(xié)商
說到支付N次這個問題,哪種方案更好還是要看具體業(yè)務(wù)場景,就像我剛剛說的,比如要改價之類的操作,肯定下單就拆的方案會好很多,當(dāng)然在支付頁面就退出的發(fā)生頻次肯定比改價的場景多得多,但是我認(rèn)為用戶并不會因?yàn)檫@一小點(diǎn)就放棄這個平臺,因?yàn)檫@是用戶自己的選擇
當(dāng)然,我的想法肯定有一定的局限性,這些都是我們的推測,我也只能盡量去推測他們?yōu)槭裁催@么做的意圖 ??
我認(rèn)為這個和改價的關(guān)系不是很大,更重要的是淘寶和京東的經(jīng)營模式不太一樣,
不用去推測他們的意圖,你要考慮你準(zhǔn)備給用戶什么樣的體驗(yàn)
用戶一次能干完的事情,你非要用戶干好多遍,而且是重復(fù)的,是不是make trouble了?
設(shè)計(jì)不能完美解決用戶的訴求,但是也別制作麻煩啊
第一,推測大廠的產(chǎn)品意圖再來設(shè)計(jì),對公司來說是最負(fù)責(zé)的,因?yàn)榇髲S肯定踩過無數(shù)的坑才會最終成型,比如我們平臺的經(jīng)營模式更接近于淘寶,而在邏輯設(shè)計(jì)上更偏向于京東,如果不去推測他們意圖,只知其然而不知其所以然,如果在流程上出問題了,這個責(zé)任就大了,雖然自己的推測不一定是對的,但是至少自己思考過了,權(quán)衡過了,而不是盲目的去借鑒
第二,像待付款訂單拆單,看起來只關(guān)乎用戶體驗(yàn),背后說大點(diǎn)和平臺的定位有關(guān),不然為什么淘寶就拆了,難道淘寶的產(chǎn)品經(jīng)理不會考慮用戶體驗(yàn)嗎?至少在我看來,我會同時關(guān)注數(shù)據(jù)的完整性,后端的開發(fā)邏輯,數(shù)據(jù)庫的結(jié)構(gòu)設(shè)計(jì),而不是僅僅考慮用戶的操作體驗(yàn);比如提交訂單后訂單其實(shí)是拆了,這個時候如果用戶端不拆實(shí)際上就是套了一層殼子,看起來是一層殼子,涉及到金錢的功能,背后的邏輯都很復(fù)雜,而且容易出錯,像我們之前開發(fā)時間相當(dāng)緊,做個權(quán)衡,現(xiàn)階段沒必要,用戶也不會因?yàn)闆]有這層殼子而放棄我們平臺
??