聊聊支付流程的設計與實現邏輯

一、業務背景

通常在業務體系中，都會或多或少的涉及到支付相關的功能；對於一些經驗欠缺同學來說，最緊張的就是面對這類支付結算的邏輯，因爲流程中的任何細節問題，都可能引發對賬異常的情況；

錯誤發生之後，再想去修復流程，花費的時間成本又是高昂的，還牽扯錯誤數據的調平問題，最終很可能引發亂賬算不清的結果，然後需要人工介入手動處理；

在支付場景中，不但涉及諸多的複雜業務，結算規則，超長的流程，第三方對接，其中更是涉及到諸多技術細節，比如：事務管理、異步處理、重試機制、加鎖等；下面來分析具體的細節邏輯。

二、支付業務

1、流程拆解

面對複雜業務的時候，最基本的能力就是要懂得把流程拆成模塊，做好各個模塊管理，再考慮如何銜接起整個流程，從而形成解決問題的思路和經驗；

如圖是對交易場景常見的分解，大致可以分爲四個模塊：

• 賬面管理：對於開通支付功能的用戶，必須清晰的管理資金信息；比如可用，凍結，賬單等；

• 交易流水：整個資金管理的流水記錄，不侷限於交易場景，還有充值，提現，退款等；

• 支付對接：通常流程中的支付功能都是對接第三方支付平臺來實現的，所以要做好請求和報文的記錄；

• 訂單結構：比如在電商交易中，訂單模型的管理，拆單策略等，支付的商品規格等；

這裏只是從一個常規的交易流程中去分析，實際的細節描述會遠比圖例複雜，雖然業務細節各不相同，但是處理思路是大體相通的；再根據各個模塊設計流程時序圖，規劃好節點之間的銜接和協作；

2、流程時序

通過時序圖的設計，來分析各個節點在銜接協作時應該如何處理，在支付業務中，通常分爲支付前、支付對接、支付後三個核心階段：

• 支付前：在商品下單時，構建訂單模型，根據拆單規則校驗庫存、商品狀態等，然後進行賬戶資金凍結，生成交易流水，此時的狀態都是待支付；

• 支付對接：支付前業務模型初始化成功之後，構建第三方支付對接請求，發起付款流程，並記錄相應的請求動作和參數，等待支付結果的通知；

• 支付後：根據支付結果的成功與否，執行相應的業務模型狀態更新，如果支付成功則交易記錄、凍結的資金、訂單結構與庫存等都需要做一系列更新；

實際上對業務有清晰的理解和拆分之後，再做好時序流程的設計，這樣就已經讓一個複雜的場景看起來簡單許多了，之後就是設計各個節點的數據結構；

3、結構設計

基於上面的業務場景分析和拆解，以及流程時序圖的呈現，可以很容易輸出一份基礎維度的結構設計，下圖可以作爲參考：

• 賬面管理：三個核心維度，賬戶金額，可用餘額，凍結金額；

• 交易記錄：存儲用戶的交易動作，但是可能會產生多個交易明細，典型的場景就是購物車下單；

• 交易明細：通常因爲訂單拆分，從而導致交易被拆分多條明細，進而將資金支付給不同商家；

• 支付對接：請求第三方支付平臺時，需要記錄請求時參數，以及第三方回調通知的報文；

• 訂單記錄：在一筆訂單中可能存在多個拆分的子單，拆分策略也很多，比如倉庫，商家，品類等；

• 訂單明細：管理每筆子訂單的信息，下單的商品、規格、買賣雙方、單價、數量、金額等；

即使單看上面的簡單設計，都能感覺到支付業務的複雜性，更何況還會疊加紅包或滿減等優惠規則之後，其複雜程度可想而知；

當然如果有明確的開發規範，在複雜版本中，所有開發必須輸出業務的分解拆分思路，時序和結構設計，在統一評審之後再落地編碼，這樣即便是複雜的業務也會有極大的質量保證。

三、關聯業務

上面單從支付的主邏輯去分析流程，實際上涉及到的業務遠不止流程中提到的這些，以常見的電商場景爲例，交易中還存在商品管理、庫存管理、物流管理，支付對接還會涉及優惠規則嵌入等等；

商品管理

• 商品主體：維護商品各個維度的信息，並提供各種規格選項，以及基礎的定價階梯，構建商品詳情描述；

• 倉儲管理：訂單拆單之後，需要根據商品編號去校驗倉儲信息，進行相應的庫存凍結以及支付後的倉庫發貨；

優惠券規則

• 優惠券主體：爲了適配更多的業務場景，需要對優惠規則有諸多的設計，比如滿減或折扣比例、按價格階梯優惠、有效期限制等；

• 發放規則：支撐日常的運營活動，用戶生命週期的維護，以及渠道流量的轉化，提供用戶羣營銷的基礎能力；

這裏簡述的商品和優惠券業務，都是與支付流程有緊密的聯繫，比如拆單後庫存不足，需要移除該商品；優惠券在支付中的使用策略，以及退款時的處理方式等；

四、實踐總結

最後從技術實現的角度，總結一下支付流程中的一些關鍵問題：

• 業務模型：對業務有清晰的理解，並能拆分出核心的節點，設計出相應的流程時序和數據結構；

• 事務管理：交易流程中常用 TCC 事務機制，即 Try(預處理)、Confirm(確認)、Cancel(取消) 模式；

• 加鎖與重試：支付完成後發出支付成功的消息，而後進行業務更新，通常需要對處理的訂單號加鎖，避免消息重試機制引發數據問題；

• 資金結算：涉及金額的計算，自然要求不能出現精度損失的問題，在一次交易中必須保證每筆資金可以通過對賬覈驗；

• 流程維護：流程本身是很難保證不出現錯誤的，需要在開發的時候，提供流程的可視化界面，並且支持手動維護的機制；

很多複雜的業務場景管理，都需要一個長期的迭代過程，但是前提需要牢牢把握住核心的邏輯；對業務的認知是一個由繁入簡的過程，而業務的實現是一個由淺到深的過程，即分析與理解，到落地實現，再到探索與創新。

作者：cicada_smile

來源：https://blog.csdn.net/cicada_smile/article/details/125586542

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/fr_nEvTRBGYnZsqNu4A72w