Java生鮮電商平臺-電商支付流程架構實戰
?
說明：我一直秉承的就是接地氣的業務架構實戰。我的文章都有一個這樣的核心。
1. 業務場景
2. 解決問題。
3.代碼實現。
4.代碼重構。
5.總結與復盤。
6.缺點與防范
?
一、場景描述
想必大家都曾遇到過這個問題，在電商購物的過程中，已經走到了最后一步：去支付。這個時候突然意識到商品數量不對，或者收貨信息選錯。
除此之外，用戶還存在之下返回的原因：
誤點擊，也就是說用戶還是想買的；
猶豫中點了返回，想買的欲望不是十分堅決；
堅決不買了。
二、可選方案
（1）目前幾乎所有主流電商平臺，在支付頁面點擊返回跳轉到訂單的待支付頁面。
?
?
（2）有一部分微商城，依然原路徑返回，不過依然生成了待支付訂單。
?
（3）原路返回，也不生成待支付訂單，不過作者目前并沒有找到此類型的案例。
?
三、為什么要有「待付款」狀態
1. 庫存計算
在電商系統中，前端頁面顯示的庫存與倉庫的實體庫存是不同步的，因而在商品出倉前要求前端的庫存進行「鎖定」即前端的減庫存。
關于庫存的鎖定，電商領域存在有兩種方案：
一種是拍下減庫存即生成訂單（待付款）減庫存，故此方案繞不過「待支付」；
一種是支付成功減庫存。
拍下減庫存存在的問題：
用戶可能拍下不買，不乏存在有用戶把拍下當收藏夾用，以致占用庫存，影響平臺的交易量。甚至存在更為極端的「惡拍」漏洞，競爭對手會把商品所有庫存全都拍掉，也不付錢，平臺的商品就全部被下架了。
支付成功減庫存存在的問題：
支付成功減庫存會碰到最嚴重的問題，是「超賣」。因為系統在付款成功之前，都不減庫存，所以總是會發生“短時間很多人都拍下，甚至都付錢了，但是系統卻發現庫存不夠了”。
買家拍下商品后，從提交付款到付款成功的之間是有時間差的，因為付款的動作是在幾個不同的系統之間傳信息。因此最后一件商品可能被多人拍下，這幾個人都可能付款成功。
淘寶的做法是把何時減庫存的決定權交給賣家，然后告知賣家兩個方案各自適應的場景。
2. 提高轉化
電商是通過交易驅動的產品類型，因此訂單的每一步都要考慮轉化率，提高轉化率是電商的基礎要求。
用戶在電商下單，大多都是會進行一番思考的，畢竟支付寶里的錢也不是河水流過來的。用戶在支付前總會有種種原因擱置付款，一般待支付訂單的有效時間為24小時以內，在這段有效時間內平臺就像一名促銷員一樣，告知你有未付款的訂單。
四、確定解決方案
結果是幾乎所有的電商都采用了從支付頁面返回跳轉至待支付的方案。
從用戶角度來考量：退回去修改信息（收貨信息、商品信息）一定是用戶真實存在的訴求。
在商家的角度：提高訂單的成交率，是第一要務。這個時候最好的辦法就是利用數據工具，做埋點和統計，根據各種情況出現的概率做出相應的決策。
?
?五：代碼方面
? ? ? ?QQ群
服務器環境)
