商城業務流程小結

最近近半年時間，都在作公司的自有商城，因爲開始的時候，設計的不是很合理，致使後來代碼比較雜亂，業務流程交叉，非常鬱悶。。。因此抽時間作個小總結，本人小菜，高手請略過。。。。

1.支付

1.1 支付

a)接收商品信息和用戶信息

b)生成訂單

c)向支付系統提交支付

d)支付成功，插入支付表，向第三方下單，接收下單結果，下單成功，更新訂單表爲成功；下單失敗，退款

e)支付失敗，插入支付表，更新訂單表狀態爲：失敗

1.2 退款

a)加載訂單表，支付表和接口配置表

b)判斷訂單表狀態，成功或者在途狀態的訂單，能夠退款，其餘狀態的訂單不作退款處理。

c)向支付系統提交退款交易

d)根據退款結果，插入支付表記錄，而後更新訂單表狀態爲已退款。

2.遊戲點卡

a)向用戶展現商品數據

b)接收用戶提交的購買信息。 

c)對用戶提交的信息進行驗證，包括商品單價、總價、數量等等，對非法信息進行記錄，並決絕該次請求。

d)合法交易，轉到支付頁面，進行支付。

e)接收第三方的交易結果的通知，根據結果，若是成功，更新訂單狀態爲成功，若是    失敗，進行退款。

f)定時查詢訂單爲在途狀態的交易，向第三方提起查詢請求，根據結果，若是成功，更新訂單狀態爲成功，若是       失敗，進行退款。

***注意***

c步驟，必定不要相信用戶提交的數據，都要嚴格進行驗證。

e和f步驟，有可能幾乎同時執行，這時候，先執行的那個，首先把訂單狀態改成「修改中」。由於兩個流程在修改 時都會讀取訂單狀態，只能修改「在途」狀態的訂單。這樣就避免出現重複退款的可能。

3.點券（天貓，京東）

點券的業務和點卡的類似，重點注意要驗證用戶提交的信息的合法性。

兩種點券實驗了兩種不一樣的下單方式。

a)當用戶在前臺頁面選擇要購買的商品數量，點擊提交的時候，後臺自動鎖定相應數量的商品，用戶完成支付後，完成出庫。後臺開啓一個線程去查詢用戶放棄的商品，解鎖。（缺點：效率低； 優勢：保證提交後必定有貨）

b)用戶可直接購買任意數量的商品，在商品出庫的時候，若是商品數量不足，提示用戶「庫存不足」。（缺點：體              驗很差； 優勢：效率高）

4.總結

注意驗證數據合法性。

原文地址：http://blog.csdn.net/Mchange/article/details/19918625