京東搞出的一個產(chǎn)品 bug？
昨天星球里有個同學(xué)向我提了一個問題，我還跟她討論了幾個回合，是關(guān)于電商產(chǎn)品中「好友代付」場景下的設(shè)計邏輯問題。
她在做產(chǎn)品的過程中為了對標(biāo)同類產(chǎn)品的實現(xiàn)邏輯，專門測試了京東和淘寶的「代付」功能。在使用京東 App 的好友代付功能時發(fā)現(xiàn)，針對同一個訂單竟然可以支付兩次。
我先說下什么叫「好友代付」。
簡單說，就是你在京東或淘寶上買東西的時候，在支付環(huán)節(jié)可以選擇讓他人幫你付款。
在淘寶上，是選擇支付寶好友代付。京東里，是選擇微信好友代付。
以京東為例，選擇代付功能后會跳轉(zhuǎn)到微信，選擇某個好友發(fā)送后，對方會收到一個付款鏈接。
點擊這個鏈接進去，看到的是一個付款頁面。
場景明確了，接下來我跟你們說下她是怎么發(fā)現(xiàn)同一個訂單能同時支付兩次的。
首先，還原下業(yè)務(wù)經(jīng)過。
她使用的是京東旗下的「京喜」小程序下單購買的非自營商品，活動單價 1 元。
然后，她提交訂單并選擇了找人代付功能。注意，在好友代付成功之前，作為下單人的她還是可以繼續(xù)支付訂單的。
接下來，將兩臺手機放到一起同時點擊支付，此時調(diào)起了支付窗口，同時輸入支付密碼后支付成功。
也就是說，針對同一筆訂單完成了兩次付款。
顯然，這不是一個正常現(xiàn)象，同一筆訂單不應(yīng)該能被重復(fù)支付。
隨后，她使用下單人的賬號發(fā)起了訂單退款，代付方退款成功了，可下單人沒有退款。
通過截圖可以看到，兩筆訂單都是支付成功的，而且對應(yīng)的商品訂單號是一樣的，支付時間也是一樣的。
這就奇怪了，為什么同一筆訂單能支付兩次呢？為什么發(fā)起退款后，只有代付方成功退款了呢？
我先說結(jié)論吧。
這可能不是一個技術(shù)層面的 bug，但肯定是一個產(chǎn)品層面的 bug。
第一，之所以能實現(xiàn)好友代付，是因為訂單模塊和支付模塊是解耦的，二者通過訂單號和交易流水號關(guān)聯(lián)。
在技術(shù)上，兩個模塊可以實現(xiàn)獨立。在組織上，訂單團隊和收銀臺支付團隊也可以獨立。
第二，作為特殊場景下的極端測試場景，當(dāng)同一個訂單被下單方和代付方同時發(fā)起支付時，理論上是需要做并發(fā)判斷的，要有一個鎖死機制，不能讓同一筆訂單被支付兩次。如果發(fā)生，那就是個業(yè)務(wù) bug。
第三，既然是個業(yè)務(wù)流程中不允許存在的 bug，在產(chǎn)品設(shè)計環(huán)節(jié)就應(yīng)該從邏輯上避免。
所以，在發(fā)起支付時需要對訂單狀態(tài)進行判斷，只允許一筆支付訂單產(chǎn)生。既然出現(xiàn)了這個問題，顯然是個產(chǎn)品 bug。
之所以說不是技術(shù)層面的 bug，是因為這筆異常訂單最終都完成了系統(tǒng)退款。
回到前面說的退款問題。
在一段時間后，下單人的退款也完成了，只不過比代付方的退款延遲很久。
針對這個現(xiàn)象，可能的情況也有多種。比如商家審核延遲、系統(tǒng)異常延遲、固定腳本檢測退款訂單或者是運營人員發(fā)現(xiàn)后的手工處理。
總之，從用戶體驗的角度看，這肯定是一個 bad case，也是一個產(chǎn)品 bug。
那么，導(dǎo)致這個問題出現(xiàn)的原因是什么呢？
這里，我斗膽猜測一下。
前面提到了，這是京東旗下「京喜」業(yè)務(wù)下的訂單。按照京東的特點，不同的垂直業(yè)務(wù)可能有自己的產(chǎn)品研發(fā)體系，他們的業(yè)務(wù)系統(tǒng)會在京東訂單中臺的基礎(chǔ)上做二次邏輯開發(fā)。
舉個例子，京東健康也是京東的垂直業(yè)務(wù)，因為屬于醫(yī)藥場景下的特殊訂單，業(yè)務(wù)流程和普通商品交易有些區(qū)別。所以，他們的訂單流程實際上也是基于京東主交易流程系統(tǒng)上的二次開發(fā)，邏輯底層調(diào)用的也是京東的交易中臺系統(tǒng)。
因此，這個訂單可能也是垂直業(yè)務(wù)的產(chǎn)研團隊進行的二次處理。而他們在調(diào)用中臺支付接口時沒有對訂單狀態(tài)進行判斷和檢測。
另外一種可能，就是好友代付功能下的訂單狀態(tài)判斷缺失。
因為在這個場景下，極小概率會出現(xiàn)下單方和代付方同時支付的情況，只有極端測試的時候會出現(xiàn)。
既然概率足夠小，那很可能在設(shè)計和開發(fā)階段就忽略了?；蛘邲]有被忽略，只是因為優(yōu)先級不高而暫時沒有加上。
當(dāng)然，在真實的用戶使用場景下，這個問題出現(xiàn)的概率并不高。但不管怎么說，既然能出現(xiàn)，那就說明確實是系統(tǒng)的漏洞。
作為一個大體量的產(chǎn)品，再下的問題也可能被放大。哪怕是 0.001% 的出現(xiàn)概率，放在一個日單量如此巨大的產(chǎn)品上，也不是一個小數(shù)。
以上，只是我的猜測，并不構(gòu)成結(jié)論。
訂單編號也在圖里了，京東訂單中臺的產(chǎn)品同學(xué)如果看到了可以去查下這一單的具體交易情況。
如果確實是問題，就趕緊 fix 一下吧。
如果你也在設(shè)計類似的交易系統(tǒng)產(chǎn)品，同類的問題也可以思考下如何避免。
做產(chǎn)品之所以好玩，其中一點就是透過現(xiàn)象找邏輯。
················· 唐韌出品 ·················
同樣的問題，在美團的產(chǎn)品上就沒存在。
可能很多人對交易系統(tǒng)產(chǎn)品不是很了解，因為我做過，所以我知道其中的復(fù)雜性。
說實話，平臺類電商的交易系統(tǒng)可能是所有產(chǎn)品中復(fù)雜程度最高的一類，如果有機會做一次，鍛煉意義還是挺大的。