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

知了一笑發表於2022-07-03

新手打怵老手頭疼的業務;

一、業務背景

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

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

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

二、支付業務

1、流程拆解

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

如圖是對交易場景常見的分解,大致可以分為四個模組:

  • 賬面管理:對於開通支付功能的使用者,必須清晰的管理資金資訊;比如可用,凍結,賬單等;
  • 交易流水:整個資金管理的流水記錄,不侷限於交易場景,還有充值,提現,退款等;
  • 支付對接:通常流程中的支付功能都是對接第三方支付平臺來實現的,所以要做好請求和報文的記錄;
  • 訂單結構:比如在電商交易中,訂單模型的管理,拆單策略等,支付的商品規格等;

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

2、流程時序

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

  • 支付前:在商品下單時,構建訂單模型,根據拆單規則校驗庫存、商品狀態等,然後進行賬戶資金凍結,生成交易流水,此時的狀態都是待支付;
  • 支付對接:支付前業務模型初始化成功之後,構建第三方支付對接請求,發起付款流程,並記錄相應的請求動作和引數,等待支付結果的通知;
  • 支付後:根據支付結果的成功與否,執行相應的業務模型狀態更新,如果支付成功則交易記錄、凍結的資金、訂單結構與庫存等都需要做一系列更新;

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

3、結構設計

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

  • 賬面管理:三個核心維度,賬戶金額,可用餘額,凍結金額;
  • 交易記錄:儲存使用者的交易動作,但是可能會產生多個交易明細,典型的場景就是購物車下單;
  • 交易明細:通常因為訂單拆分,從而導致交易被拆分多條明細,進而將資金支付給不同商家;
  • 支付對接:請求第三方支付平臺時,需要記錄請求時引數,以及第三方回撥通知的報文;
  • 訂單記錄:在一筆訂單中可能存在多個拆分的子單,拆分策略也很多,比如倉庫,商家,品類等;
  • 訂單明細:管理每筆子訂單的資訊,下單的商品、規格、買賣雙方、單價、數量、金額等;

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

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

三、關聯業務

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

商品管理

  • 商品主體:維護商品各個維度的資訊,並提供各種規格選項,以及基礎的定價階梯,構建商品詳情描述;
  • 倉儲管理:訂單拆單之後,需要根據商品編號去校驗倉儲資訊,進行相應的庫存凍結以及支付後的倉庫發貨;

優惠券規則

  • 優惠券主體:為了適配更多的業務場景,需要對優惠規則有諸多的設計,比如滿減或折扣比例、按價格階梯優惠、有效期限制等;
  • 發放規則:支撐日常的運營活動,使用者生命週期的維護,以及渠道流量的轉化,提供使用者群營銷的基礎能力;

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

四、實踐總結

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

  • 業務模型:對業務有清晰的理解,並能拆分出核心的節點,設計出相應的流程時序和資料結構;
  • 事務管理:交易流程中常用TCC事務機制,即Try(預處理)、Confirm(確認)、Cancel(取消)模式;
  • 加鎖與重試:支付完成後發出支付成功的訊息,而後進行業務更新,通常需要對處理的訂單號加鎖,避免訊息重試機制引發資料問題;
  • 資金結算:涉及金額的計算,自然要求不能出現精度損失的問題,在一次交易中必須保證每筆資金可以通過對賬核驗;
  • 流程維護:流程本身是很難保證不出現錯誤的,需要在開發的時候,提供流程的視覺化介面,並且支援手動維護的機制;

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

五、參考原始碼

程式設計文件:
https://gitee.com/cicadasmile/butte-java-note

應用倉庫:
https://gitee.com/cicadasmile/butte-flyer-parent

相關文章