Java生鮮電商平臺-電商支付流程架構實戰

Java生鮮電商平臺-電商支付流程架構實戰

 

說明：我一直秉承的就是接地氣的業務架構實戰。個人文章都有一個這樣的核心。

1. 業務場景

2. 解決問題。

3.代碼實現。

4.代碼重構。

5.總結與覆盤。

6.缺點與防範

 

1、場景描述

想必你們都曾遇到過這個問題，在電商購物的過程當中，已經走到了最後一步：去支付。這個時候忽然意識到商品數量不對，或者收貨信息選錯。

除此以外，用戶還存在之下返回的緣由：

誤點擊，也就是說用戶仍是想買的；

猶豫中點了返回，想買的慾望不是十分堅定；

堅定不買了。

2、可選方案

（1）目前幾乎全部主流電商平臺，在支付頁面點擊返回跳轉到訂單的待支付頁面。

 

 

 

 

 

（2）有一部分微商城，依然原路徑返回，不過依然生成了待支付訂單。

 

 

（3）原路返回，也不生成待支付訂單，不過做者目前並無找到此類型的案例。

 

3、爲何要有「待付款」狀態

1. 庫存計算

在電商系統中，前端頁面顯示的庫存與倉庫的實體庫存是不一樣步的，於是在商品出倉前要求前端的庫存進行「鎖定」即前端的減庫存。

關於庫存的鎖定，電商領域存在有兩種方案：

一種是拍下減庫存即生成訂單（待付款）減庫存，故此方案繞不過「待支付」；

一種是支付成功減庫存。

拍下減庫存存在的問題：

用戶可能拍下不買，不乏存在有用戶把拍下當收藏夾用，以至佔用庫存，影響平臺的交易量。甚至存在更爲極端的「惡拍」漏洞，競爭對手會把商品全部庫存全都拍掉，也不付錢，平臺的商品就所有被下架了。

支付成功減庫存存在的問題：

支付成功減庫存會碰到最嚴重的問題，是「超賣」。由於系統在付款成功以前，都不減庫存，因此老是會發生「短期不少人都拍下，甚至都付錢了，可是系統卻發現庫存不夠了」。

買家拍下商品後，從提交付款到付款成功的之間是有時間差的，由於付款的動做是在幾個不一樣的系統之間傳信息。所以最後一件商品可能被多人拍下，這幾我的均可能付款成功。

淘寶的作法是把什麼時候減庫存的決定權交給賣家，而後告知賣家兩個方案各自適應的場景。

 

2. 提升轉化

電商是經過交易驅動的產品類型，所以訂單的每一步都要考慮轉化率，提升轉化率是電商的基礎要求。

用戶在電商下單，大多都是會進行一番思考的，畢竟支付寶裏的錢也不是河水流過來的。用戶在支付前總會有種種緣由擱置付款，通常待支付訂單的有效時間爲24小時之內，在這段有效時間內平臺就像一名促銷員同樣，告知你有未付款的訂單。

 

 

4、肯定解決方案

結果是幾乎全部的電商都採用了從支付頁面返回跳轉至待支付的方案。

從用戶角度來考量：退回去修改信息（收貨信息、商品信息）必定是用戶真實存在的訴求。

在商家的角度：提升訂單的成交率，是第一要務。這個時候最好的辦法就是利用數據工具，作埋點和統計，根據各類狀況出現的機率作出相應的決策。

 

 五：代碼方面

       QQ羣