交易系統(tǒng)設(shè)計全景，需求、設(shè)計、指標(biāo)體系

“hello，我是彬彬。”

這是支付系統(tǒng)設(shè)計的第二篇，這次講探討交易模塊的，還是延續(xù)同樣的結(jié)構(gòu)，遵循產(chǎn)研實施過程的基本流程，從交易模塊的模塊定位、需求分析、方案設(shè)計等一步步拆解。以下正文敬請食用。

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

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

• 為什么都是交易模塊，電商的交易模塊和支付系統(tǒng)的交易模塊設(shè)計完全不同？

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

確實，在互聯(lián)網(wǎng)行業(yè)，“交易”這個詞被廣泛使用，但不同業(yè)務(wù)場景下的“交易模塊”有著天壤之別。

比如，我們在淘寶下單交易模塊負(fù)責(zé)的是訂單創(chuàng)建、庫存鎖定、商品優(yōu)惠計算；而當(dāng)我們用支付寶付款時，交易模塊負(fù)責(zé)的卻是支付路由、資金劃撥、風(fēng)控攔截。

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

答案很簡單：因為業(yè)務(wù)模式不同，決定了交易的本質(zhì)不同。

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

而支付系統(tǒng)交易關(guān)注的是資金的流轉(zhuǎn)，核心是資金流通，所以交易模塊要解決的是支付成功率、資金安全、交易對賬的問題

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

01 交易的需求分析

不管是何種交易，交易模塊的核心目標(biāo)是類似的：在業(yè)務(wù)場景中，安全高效地完成業(yè)務(wù)過程的流轉(zhuǎn)。

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

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

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

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

所以，對于不同的業(yè)務(wù)類型，交易的核心載體也不相同：

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

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

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

一句話總結(jié)：交易模塊本質(zhì)上是業(yè)務(wù)模式的抽象。

本文主要探討支付系統(tǒng)的交易模塊的設(shè)計方法，所以后續(xù)的交易都針對支付系統(tǒng)的交易模塊展開。

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

用戶發(fā)起支付請求后，直接調(diào)用銀行或支付公司接口完成扣款。

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

• 支付過程中斷怎么辦？

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

• 需要支持復(fù)雜的支付組合怎么辦？

• 需要記錄完整的資金流轉(zhuǎn)軌跡怎么辦？

這些都是交易模塊解決的問題，所以交易模塊存在的意義：它是支付系統(tǒng)鏈接業(yè)務(wù)系統(tǒng)和底層支付渠道的入口和“轉(zhuǎn)換層”；

支付系統(tǒng)交易模塊的核心作用，我個人認(rèn)為有以下4個：

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

• 管理資金流動：比如錢怎么進(jìn)、怎么出、怎么凍結(jié)、怎么結(jié)算？

• 支持業(yè)務(wù)擴展：比如能否支持合單？能否拆單、退款？能否適應(yīng)新業(yè)務(wù)？

• 封裝統(tǒng)一能力和服務(wù)：比如能否一套接口對接所有支付渠道？能否適配各種支付產(chǎn)品的不同差異？

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

通過統(tǒng)一的接口，整合多維度的支付渠道和支付產(chǎn)品，鏈接業(yè)務(wù)需求和資金流轉(zhuǎn)，并保證全鏈路的一致性、安全性和高可用性。

所以交易模塊是支付系統(tǒng)中最復(fù)雜的核心模塊之一。

02 交易的系統(tǒng)設(shè)計

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

2.1、交易核心流程

支付系統(tǒng)各模塊交互流程

從圖上我們可以看到，交易系統(tǒng)是業(yè)務(wù)系統(tǒng)請求處理的先鋒，業(yè)務(wù)系統(tǒng)需要按照標(biāo)準(zhǔn)接口，將支付請求給到交易系統(tǒng)，交易系統(tǒng)會落單，并將請求轉(zhuǎn)發(fā)到關(guān)聯(lián)模塊處理。

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

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

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

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

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

• 轉(zhuǎn)賬：將資金從A轉(zhuǎn)給B

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

• 提現(xiàn)：從賬戶將資金劃轉(zhuǎn)到自己的銀行卡

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

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

2.2、交易模式設(shè)計

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

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

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

• 預(yù)授權(quán)交易：用戶確認(rèn)后，資金是先做凍結(jié)，后續(xù)才真實扣款

• 訂金模式：用戶先支付部分訂金，業(yè)務(wù)結(jié)束再收取后續(xù)尾款

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

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

擔(dān)保交易流程

• 交易收到業(yè)務(wù)系統(tǒng)請求，給到后續(xù)系統(tǒng)執(zhí)行支付扣款

• 扣款成功后，因為是擔(dān)保交易，支付系統(tǒng)先行記賬到擔(dān)保賬戶或者商家待結(jié)算賬戶（根據(jù)平臺賬戶體系可能有區(qū)別）

• 用戶確認(rèn)收貨，交易將訂單給到清結(jié)算

• 清結(jié)算清分商戶應(yīng)結(jié)算金額及平臺分潤等各類費項，將資金分賬到對應(yīng)賬戶

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

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

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

• 正向的下單、支付；

• 逆向的關(guān)單、退款；

• 相應(yīng)的查詢服務(wù)

2.3、交易內(nèi)部分層

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

交易層：主要關(guān)心支付業(yè)務(wù)的受理，

關(guān)鍵業(yè)務(wù)信息包括：交易訂單ID、子交易訂單ID（如有）、交易類型、交易的狀態(tài)（待支付、支付中、支付成功/失敗；逆向的退款中、退款成功/失敗等）、交易金額、幣種、收款方、付款方、創(chuàng)建時間、更新時間、交易成功時間等

支付層：主要執(zhí)行真實的支付動作，

主要的業(yè)務(wù)信息包括：支付單ID、關(guān)聯(lián)的交易單號、支付方式、渠道、實際支付金額、支付狀態(tài)、支付時間、更新時間等

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

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

2.4、交易系統(tǒng)案例分析

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

2.4.1、電商購物車案例分析

第一個典型的場景是電商業(yè)務(wù)的購物車。

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

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

1、業(yè)務(wù)系統(tǒng)到支付系統(tǒng)下單時，除了提供業(yè)務(wù)訂單外，還需要提供各子業(yè)務(wù)訂單信息，

2、交易系統(tǒng)會按照相應(yīng)結(jié)構(gòu)生成交易的主單和子單，

3、后續(xù)調(diào)用支付渠道時，是一筆渠道請求，

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

5、最后通知業(yè)務(wù)系統(tǒng)

支付系統(tǒng)內(nèi)部后續(xù)給商戶進(jìn)行清分和結(jié)算時，按照子交易訂單維度分別清分。

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

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

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

1、業(yè)務(wù)系統(tǒng)到支付系統(tǒng)下單，

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

3、交易各自調(diào)用不同的渠道完成支付，最后分別更新子交易單狀態(tài)后，再統(tǒng)一更新主交易單狀態(tài)。

這個拆單是支付系統(tǒng)自行處理的，需要有這個能力，但是業(yè)務(wù)側(cè)不一定有感知。

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

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

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

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

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

03 交易的指標(biāo)體系

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

用戶只會抱怨咱們收銀臺不好用，但我們自己知道問題其實是在交易環(huán)節(jié)。所以交易模塊的一套數(shù)據(jù)指標(biāo)體系也是非常有必要的。

我個人覺得交易模塊的數(shù)據(jù)指標(biāo)可以從以下兩個維度安排：

• 基礎(chǔ)交易指標(biāo)

交易量：每分鐘/小時/天的交易筆數(shù)

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

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

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

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

平均耗時：從發(fā)起到完成的平均時間

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

• 進(jìn)階交易指標(biāo)

支付方式分布：各支付方式的占比及表現(xiàn)

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

金額分布：不同金額區(qū)間的交易分布

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

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

同樣監(jiān)控指標(biāo)設(shè)計完成之后，需要建立實時看板，并設(shè)置關(guān)鍵指標(biāo)的預(yù)警閥值。

04 結(jié)語

如果你正在設(shè)計或優(yōu)化支付系統(tǒng)的交易模塊，建議可以從以下幾個方向開始：

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

• 設(shè)計核心定義：比如定義交易、賬戶等核心實體及其關(guān)系，特別是不同交易模式下對后續(xù)賬戶流轉(zhuǎn)過程的梳理；

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

• 制定并完善監(jiān)控方案：確定關(guān)鍵指標(biāo)和監(jiān)控方式，并建立完善看板。

另外交易系統(tǒng)有些坑，是可以規(guī)避掉的：

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

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

• 最后再重申不要忘記監(jiān)控：沒有監(jiān)控的交易模塊就是在裸奔，產(chǎn)品不提需求，研發(fā)同學(xué)再沒有進(jìn)行監(jiān)控設(shè)計，那真的就是一出事故就直奔火葬場的節(jié)奏。

我個人是覺得支付系統(tǒng)沒有完美的設(shè)計，只有適合業(yè)務(wù)的設(shè)計，而適合的支付系統(tǒng)不是一下子設(shè)計出來的，是迭代出來的。

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

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

更多的支付相關(guān)的內(nèi)容大家可以關(guān)注彬彬的公眾號了解

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