“hello，我是彬彬。”

這是支付系統設計的第二篇，這次講探討交易模塊的，還是延續同樣的結構，遵循產研實施過程的基本流程，從交易模塊的模塊定位、需求分析、方案設計等一步步拆解。以下正文敬請食用。

你有沒有遇到過這樣的問題？

• 公司業務模式一變或者新增其他的業務模式，交易模塊就得大改？

• 為什么都是交易模塊，電商的交易模塊和支付系統的交易模塊設計完全不同？

• 有的系統能輕松支持“購物車合單支付”，而有的連“拆單、退款”都做不好？

確實，在互聯網行業，“交易”這個詞被廣泛使用，但不同業務場景下的“交易模塊”有著天壤之別。

比如，我們在淘寶下單交易模塊負責的是訂單創建、庫存鎖定、商品優惠計算；而當我們用支付寶付款時，交易模塊負責的卻是支付路由、資金劃撥、風控攔截。

那么問題來了：為什么不同業務模式下的交易模塊設計差異如此之大？

答案很簡單：因為業務模式不同，決定了交易的本質不同。

電商交易關注的是商品與訂單的流轉，核心是商品流通，所以交易模塊要解決的是訂單履約問題；

而支付系統交易關注的是資金的流轉，核心是資金流通，所以交易模塊要解決的是支付成功率、資金安全、交易對賬的問題

一個是"物"的交易，一個是"錢"的交易，自然設計思路迥異。

01 交易的需求分析

不管是何種交易，交易模塊的核心目標是類似的：在業務場景中，安全高效地完成業務過程的流轉。

但不同業務場景對交易的需求不盡相同，開篇有提到，這里在展開下：

• 電商交易：主要是為了訂單履約（庫存、商品優惠、物流），比如淘寶購物下單；

• 支付交易：主要是為了資金處理（支付、退款、結算），比如支付寶支付下支付單，

• 金融交易：主要是為了資產劃轉（計息、資金核對、賬戶變動），比如基金申購贖回。

所以，對于不同的業務類型，交易的核心載體也不相同：

• 電商的交易模塊，核心是訂單；

• 支付的交易模塊，核心是支付指令；

• 金融的交易模塊，核心是資金賬戶處理。

一句話總結：交易模塊本質上是業務模式的抽象。

本文主要探討支付系統的交易模塊的設計方法，所以后續的交易都針對支付系統的交易模塊展開。

可以想象一下，如果支付系統沒有交易模塊，支付系統會是什么樣？

用戶發起支付請求后，直接調用銀行或支付公司接口完成扣款。

看起來簡單直接，其實有非常多的問題沒法解決，比如：

• 支付過程中斷怎么辦？

• 如果需要對同一筆資金進行多次處理怎么辦？

• 需要支持復雜的支付組合怎么辦？

• 需要記錄完整的資金流轉軌跡怎么辦？

這些都是交易模塊解決的問題，所以交易模塊存在的意義：它是支付系統鏈接業務系統和底層支付渠道的入口和“轉換層”；

支付系統交易模塊的核心作用，我個人認為有以下4個：

• 記錄交易行為：比如誰付錢？付給誰？付多少？狀態如何？

• 管理資金流動：比如錢怎么進、怎么出、怎么凍結、怎么結算？

• 支持業務擴展：比如能否支持合單？能否拆單、退款？能否適應新業務？

• 封裝統一能力和服務：比如能否一套接口對接所有支付渠道？能否適配各種支付產品的不同差異？

我們可以把支付系統交易模塊的核心定位基本概括為：

通過統一的接口，整合多維度的支付渠道和支付產品，鏈接業務需求和資金流轉，并保證全鏈路的一致性、安全性和高可用性。

所以交易模塊是支付系統中最復雜的核心模塊之一。

02 交易的系統設計

我們還是拿之前文章中典型的支付中臺的交易流程做開始，窺見交易模塊在整個支付系統的位置，窺全貌見細節。

2.1、交易核心流程

支付系統各模塊交互流程

從圖上我們可以看到，交易系統是業務系統請求處理的先鋒，業務系統需要按照標準接口，將支付請求給到交易系統，交易系統會落單，并將請求轉發到關聯模塊處理。

這個當然還不能解釋交易系統需要如何設計，還需要引申出交易模塊中的兩個核心概念：交易類型、交易模式。

上文提到交易模塊是業務模式的抽象，核心就是通過這兩個概念的組合完成通用的處理。

交易類型，主要針對資金流動方向的角度而言，可以簡單理解成主要是從付款方角度看到的資金處理，主要包括：

• 支付：定義為付款方扣款，

• 退款：將資金退還給付款方

• 轉賬：將資金從A轉給B

• 充值：將自己的資金從銀行卡轉移到記賬賬戶

• 提現：從賬戶將資金劃轉到自己的銀行卡

• 代付：將資金付給別人的銀行卡

當然基于實際的支付業務，還有其他一些類型，可能不涉及資金變動，但也是要處理的交易，比如簽約，銀行卡綁卡進行四要素簽約，也可以是一種交易類型。

2.2、交易模式設計

交易模式，是針對“支付”這個交易類型的行為方式。淘寶首創的擔保交易，就是針對電商行業開創的非常了不起的一種交易模式。這個可以簡單理解成主要是從收款方角度看到的資金處理，常見的交易模式有：

• 即時到賬：用戶支付后，資金直接給到商家

• 擔保交易：用戶支付后，資金先要放在擔保賬戶，等確認收貨后才給到商家

• 預授權交易：用戶確認后，資金是先做凍結，后續才真實扣款

• 訂金模式：用戶先支付部分訂金，業務結束再收取后續尾款

不同的交易模式代表著用戶支付成功之后的資金處理流程不同，會影響后續的清結算和賬務處理。

我們拿典型的電商擔保交易舉例看下整體處理流程

擔保交易流程

• 交易收到業務系統請求，給到后續系統執行支付扣款

• 扣款成功后，因為是擔保交易，支付系統先行記賬到擔保賬戶或者商家待結算賬戶（根據平臺賬戶體系可能有區別）

• 用戶確認收貨，交易將訂單給到清結算

• 清結算清分商戶應結算金額及平臺分潤等各類費項，將資金分賬到對應賬戶

如果是即時到賬，那用戶支付完成之后，收單記賬完成會直接給到清結算，清分完成即時就給到了商戶賬戶。

交易模塊這兩個概念確定之后，后續的大部分業務場景基本在類型和模式上進行擴展就可以滿足。

另外通過上圖也可以提煉交易模塊提供出去的能力基本包括了：

• 正向的下單、支付；

• 逆向的關單、退款；

• 相應的查詢服務

2.3、交易內部分層

需說明，交易模塊是一個大模塊，本身其實也是可以分層的，一般典型的會分成兩層：

交易層：主要關心支付業務的受理，

關鍵業務信息包括：交易訂單ID、子交易訂單ID（如有）、交易類型、交易的狀態（待支付、支付中、支付成功/失敗；逆向的退款中、退款成功/失敗等）、交易金額、幣種、收款方、付款方、創建時間、更新時間、交易成功時間等

支付層：主要執行真實的支付動作，

主要的業務信息包括：支付單ID、關聯的交易單號、支付方式、渠道、實際支付金額、支付狀態、支付時間、更新時間等

渠道層是否算在交易，這個仁者見仁智者見智，但總體上肯定是大交易其中的一環。所以也暫時放在這。

一筆交易單可能有多筆支付單，同樣的一筆支付單也可能有多筆渠道單

2.4、交易系統案例分析

下面咱們挑兩個典型的交易場景，模擬下方案擴展

2.4.1、電商購物車案例分析

第一個典型的場景是電商業務的購物車。

購物車場景下，一筆業務訂單包含了多個不同商戶的商品，這就意味著在給商戶進行記賬和結算時，需要按照商戶維度分別清分結算，但用戶希望可以一筆就完成支付。這要求交易模塊具備合單支付的能力。

合單支付還是交易類型的一個擴充，在普通的支付類型之外，新增合單支付的場景。

1、業務系統到支付系統下單時，除了提供業務訂單外，還需要提供各子業務訂單信息，

2、交易系統會按照相應結構生成交易的主單和子單，

3、后續調用支付渠道時，是一筆渠道請求，

4、支付成功，分別更新各子交易訂單狀態和主交易訂單狀態

5、最后通知業務系統

支付系統內部后續給商戶進行清分和結算時，按照子交易訂單維度分別清分。

2.4.2、電商組合支付案例分析

第二個典型的場景是用戶分多次/多階段支付，比如用戶需要用余額和銀行卡組合支付。

這個場景下，業務系統到支付系統只需要下一次支付單即可，用戶在支付時選擇組合余額和銀行卡支付，這需要交易具有拆單支付的能力。

1、業務系統到支付系統下單，

2、交易按照用戶選擇的組合或者配置邏輯自行組合，分別生成主單和子單（詳細的拆分邏輯不一定是在交易受理層，也可能是在交易內部的其他層別，比如支付層，需要根據實際系統架構來）

3、交易各自調用不同的渠道完成支付，最后分別更新子交易單狀態后，再統一更新主交易單狀態。

這個拆單是支付系統自行處理的，需要有這個能力，但是業務側不一定有感知。

與合單支付不同的是，后續商戶記賬和結算時，要按照主交易單維度處理（當然也得根據拆分邏輯看），要不然商戶收到兩筆款，會有些疑問，雖然資金總額是一致的。

這里拋一個問題，如果使用同樣的支付方式比如銀行卡支付，碰到渠道限額不足，比如通道單筆限額1w，但用戶需要支付2w，這時候怎么處理？

想到這個問題是寫到這發現，拆單和合單的邏輯，在一套靈活的交易系統中非常常見，也呼應了上文一句話：一筆交易單可能有多筆支付單，同樣的一筆支付單也可能有多筆渠道單。

當然交易模塊也涉及到和風控、會員等系統的交互，而且交易本身也有分層，交易層、收銀層、支付層等等，不同公司有不同的模塊和概要設計，所以以上講的方案和設計也不一定完全符合所有的場景。

甚至有些功能的實現不一定是在支付的交易模塊實現，在業務側也不是沒有方案。所以又回到之前的一句話：產品要結合實際的場景和訴求，根據公司不同的階段和情況，找到適合的方案。一味的套用框架或設計，反而可能適得其反。

03 交易的指標體系

交易模塊雖然不像收銀臺，沒有對用戶的UI界面展示，但是交易如果有問題，會影響用戶的使用體驗。順利的情況下用戶無感，但是異常的情況下用戶就會有很明顯的體感。

用戶只會抱怨咱們收銀臺不好用，但我們自己知道問題其實是在交易環節。所以交易模塊的一套數據指標體系也是非常有必要的。

我個人覺得交易模塊的數據指標可以從以下兩個維度安排：

• 基礎交易指標

交易量：每分鐘/小時/天的交易筆數

交易金額：每分鐘/小時/天的交易總額

退款金額：每分鐘/小時/天的退款總額

成功率：成功交易占總交易的比例

退款率：退款金額占總交易金額的比例

平均耗時：從發起到完成的平均時間

這些指標看似簡單，但需要根據不同維度進行拆分分析，比如按支付渠道、按交易類型、按商戶等繼續細化。

• 進階交易指標

支付方式分布：各支付方式的占比及表現

時段分布：交易在不同時間段的分布情況

金額分布：不同金額區間的交易分布

失敗原因分析：失敗交易的錯誤類型分布，要按照交易失敗原因統計

這些指標可以幫助發現潛在問題，比如某渠道成功率突然下降，可能意味著該渠道接口出現異常。

同樣監控指標設計完成之后，需要建立實時看板，并設置關鍵指標的預警閥值。

04 結語

如果你正在設計或優化支付系統的交易模塊，建議可以從以下幾個方向開始：

• 梳理業務場景：列出所有需要支持的交易類型和模式，不僅僅是現在的，可預見的將來如果需要支持，也可以一并考慮；

• 設計核心定義：比如定義交易、賬戶等核心實體及其關系，特別是不同交易模式下對后續賬戶流轉過程的梳理；

• 繪制流程圖：將各種場景的處理流程通過時序或者泳道圖等畫出來，這樣可以查漏補缺看邏輯是否閉環，有沒有遺漏；

• 制定并完善監控方案：確定關鍵指標和監控方式，并建立完善看板。

另外交易系統有些坑，是可以規避掉的：

• 比如不要過度設計，保證模型的通用即可，梳理歸梳理，但不需要上來就把所有的交易模式都支持掉，可以分步驟迭代升級；

• 另外不要低估并發：支付場景往往有突發流量，要做好壓力測試，當然這個開發同學一般都會考慮；

• 最后再重申不要忘記監控：沒有監控的交易模塊就是在裸奔，產品不提需求，研發同學再沒有進行監控設計，那真的就是一出事故就直奔火葬場的節奏。

我個人是覺得支付系統沒有完美的設計，只有適合業務的設計，而適合的支付系統不是一下子設計出來的，是迭代出來的。

所以不需要追求一步到位，不要被各種"高大上"的方案迷惑，從業務本質出發，解決實際問題才是王道。

支付系統的交易模塊，雖然很復雜，但也不是無規律可循。只要咱們從業務出發，理清資金流向，不遺漏所有需要的交易類型和模式，有合理的狀態機，再做好通用可擴展的模型設計，我們一定可以得到一套穩定、靈活的交易系統。

更多的支付相關的內容大家可以關注彬彬的公眾號了解

【入群與支付同行交流，加我個人微信入群】