對接第三方支付系統 為系統平台提供統一的支付中介軟體.
技術棧使用情況:springboot + mybaties + redis + rocketmq + mysql.
易拓展支援，而不是決策
少即是多, 側重成長性, 慎重修改api
支付系統主流程
這期間發生了什麼?
準備工作: 賬單結算完成,呼叫生成支付資訊介面.
第一步 : 客戶端點選確認支付 —> 請求後台預支付介面(檢查訂單狀態 )
第二步: 根據後台返回狀態碼 做後續處理
第三步: 可以拉起支付時 —> 拉起支付讓使用者選擇支付方式 —> 請求支付介面(檢查訂單狀態,獲取sdk 需要的簽名 )
第四步: 後台返回正確的簽名 客戶端拉起第三方支付 sdk 介面
第五步: 使用者使用支付工具 成功付款
第六步: 客戶端顯示支援成功並查詢後台支付狀態(如果非同步**未到後台 主動查詢第三方並更新訂單支付資訊)
那麼處理階段到底做了什麼呢?
第三步和第四步詳細講過程如下:
整個故事情節大概是這樣的
支付寶官網這樣說:
梳理一下步驟：
奉上支付寶 開發者文件:
0支付成功
411訂單已支付
413訂單已關閉
415校驗訂單資訊失敗(未到支付狀態/未查找到訂單)
420支付渠道錯誤
421mq廣播通知錯誤
999操作失敗
JS版設計模式
策略模式 定義一系列的演算法，並且把它們封裝起來，而且他們可以相互替換。這裡我舉個在專案中遇到的問題，比如說要驗證乙個物件中的屬性的值是否合法，一開始我是通過不停的else if，現在想想，真的有點蠢了。var validator 配置資料 config 錯誤資訊 messages validate...
模版設計模式
b 定義 b 在乙個方法中定義乙個演算法骨架，而將一些步驟延伸到子類中。其本質 把可變和不可變進行分類。可變部分延伸到子類來完成，不變部分交給父類定義成骨架 b 優點 b 1 可以使的子類可以在不改變演算法骨架的情況下，重新定義演算法中的某些步驟。2 模版方法通過把不變的部分搬移到超類，去除了子類中...
支付系統對賬設計
對賬系統作為支付系統中的基石系統,處於整個支付環節中的最後一層，主要用來保證我方支付資料與第三方支付渠道或銀行的資料一致性。在沒有對賬系統之前，財務在第二日手工核對前一日的應收與實收。倘若不一致，這就需要一一核對資料，找出不一致的資料。對賬系統出現之後，就可減少以這種繁瑣手工操作，財務只需要每天關注...