在現代數位化經濟中，第三方支付結算系統扮演著至關重要的角色，為線上交易提供便捷、高效的清分和結算服務。本文將深入探討支付結算系統的架構設計，特別是其核心的兩條耦合鏈路——線上交易鏈路和日終核算鏈路，以及它們如何共同支撐起整個支付生態系的穩定執行。透過詳細解析支付系統的分層架構、業務架構和處理流程，讀者將獲得對支付系統工作原理的全面了解。
我們這裏說介紹的支付就是三方支付使用的支付結算系統，他能夠為買賣雙方進行線上的交易、清分和結算功能。很多人覺得支付架構不好畫，其實還是因為不得要領，因為支付系統做的是清結算業務，因此在架構表現上就是以賬務為核心的兩條耦合鏈路。
一、兩條耦合鏈路之所以要設計成耦合的交易鏈路，是因為資金不能像指令一樣在網路上傳輸，因此我們跨行線上交易都是采用的待結算方式。
待結算就是先即時讓指令傳輸，並以記賬的形式登記處理結果，此時客戶看到的資金是待結。資金到賬後支付系統根據銀行清算檔，把賬務資訊轉化成給客戶結算的資金，此時客戶看到的資金可用。
圖1：支付架構的兩條耦合鏈路
1. 線上交易鏈路
線上交易是指令從閘道器到渠道跨行收付款，在這過程中會使用到收銀台來進行支付、會員系統驗證客戶身份。整個過程系統會把指令的往來收付結果在賬務系統記賬；此時客戶查詢的余額並不能提現，而是待結算。
2. 日終核算鏈路
日終銀行清算後，對賬系統將銀行清算檔與支付數據進行核對，確認無誤後給客戶結算資金、渠道清算平賬。最終完成總賬的匯總核算，實作資金與賬務的最終一致。
為什麽是耦合的？
看到這裏是不是覺得這張圖很眼熟？是的，這就是銀行會計的「收付實作制」；這也是我提出資訊、賬務、資金的支付三流合一原因。
二、支付的分層架構支付系統是按客戶訂單完成跨行收付款，並將資金最終轉移到收款人的帳戶裏。因此整套系統按照「一個系統、兩個通道、三層架構」來進行劃分。
圖2：支付系統架構分層
1. 一個系統
為了實作買賣雙方的跨行收付款，支付平台會把支付產品包裝成介面或支付頁面提供給客戶來使用，並透過系統的層層轉換來實作資金的跨行轉移到收款人帳戶裏。
2. 兩個通道
（1）閘道器/終端（接入端）
它是支付系統的「接入端」，將支付產品透過介面、頁面、終端裝置的形式提供給使用者進行支付、開戶和認證。同時存取閘道器或者使用終端裝置還要安裝「金鑰和證書」，以此來保證你支付的安全。
（2）渠道（接出端）
它是支付系統的「接出端」，他負責對接三方、銀行、清算機構的支付介面，把他轉換成標準支付產品提供給上層的產品使用。如果選擇對接了多家銀行相同的支付產品，他能根據「訂單、渠道、穩定性」進行動態的路由選擇。
（3）三層架構
①產品層（場景化包裝）
產品層是為了適應不同場景的支付需求，把基礎支付產品包裝成面向不同場景的支付產品，滿足不同行業對於支付的需求。例如面向個人使用者的B2C、C2C支付，面向企業的B2B支付，以及面向金融機構的消金支付等；因此產品層是基礎產品的場景化包裝，方便不同使用者使用。
②交易層（基礎支付產品）
為使用者提供基礎的支付產品，包括充值、提現、收款、分賬、付款等支付服務，滿足多場景對支付的基本需求。他主要包括了收銀台、交易系統、客戶系統三部份。
③核心層（原始支付服務）
「核心層」又叫「支付層」，是為交易層提供原始的賬務、渠道、清結算服務，他專註於內部賬務邏輯和支付渠道的處理邏輯，並且核心層也代表了一個系統的核心能力，他決定了上層產品是否好用。這裏主要包括了支付引擎、賬務核心、對賬中心三部份。
三、支付業務架構
圖3：支付業務架構
業務架構顧名思義就是面向業務場景提供的架構圖，他主要目的就是讓非技術人員了解系統具有哪些能力，以及系統提供的能力是否符合期望。業務架構一般分為兩張圖「架構圖、流程圖」，架構圖負責展示系統的功能結構，流程圖負責展示功能之間關系。
從支付的業務架構我們可以看到，相對於分層架構，實際的業務架構有許多的輔助系統來支持支付業務的執行。不過支付業務核心閉環的還是支付服務中的8個模組當主角，下面我們來分別介紹下。
1. 收銀系統
收銀台系統就是以頁面的形式提供給使用者進行收款操作，同時它也會面向不同的支付終端提供各種型別的收銀台，我們按終端型別把它們分H5收銀台、SDK收銀台、小程式收銀台、WEB收銀台、聚合收款碼為五類。收銀台形式有很多種了，主要還是依托於支付場景包裝，讓使用者能夠更順暢的支付。
2. 交易系統
透過前面的介紹我們知道，交易系統是面向支付場景和使用者提供的服務，因此他主要職責是處理業務場景復雜多變的支付處理需求。
圖4 交易系統核心能力
（1）支付服務提供者
交易系統是支付服務的提供者，他負責給外部使用收款、付款、余額支付等交易方式，並以訂單的形式記錄支付的處理過程。
（2）交易服務提供者
據不同的場景它還提供擔保交易、合單支付、組合支付等分賬交易把資金分配給交易的參與方。因此我們使用的支付產品其實都是交易系統提供的服務。
3. 客戶系統
顧名思義是為客戶提供服務的系統。客戶註冊的時候都是會員角色。隨著客戶開出的帳戶不同就有了不同的身份。例如客戶開出基本帳戶就是使用者角色，如果申請支付產品開出特約商就是商戶角色。因此在系統上表現為面向C端的使用者錢包，面向B端商戶平台，以及提供技術對接的開放平台。
4. 產品中心
產品中心是包裝對外銷售產品的一個配置中心，並且商戶相關的簽約產品、計費資訊、交易限額等都可以透過靈活的樣版來進行配置。它的作用就是提高配置效率，透過元件化的配置工具，能快速搭建一個新的支付產品出來提供給客戶使用。
5. 支付引擎
支付引擎顧名思是支付的發動機，他負責所有系統與帳戶、渠道的支付流程處理。
圖5 支付引擎核心能力
（1）支付提供者
它對交易層的「交易系統、客戶系統、收銀台」等遮蔽了底層支付賬務、支付渠道管理的復雜性，讓交易層可以專註於業務場景，即使底層渠道更換，賬務進行調整，交易層也不會受到影響。
(2）流程排程者
有了支付引擎這個大當家，流程處理相關的「臟活累活」都由他來負責。帳戶、渠道、清結算就可以各司其職做好本職工作，如果涉及其他系統協作，通知「支付引擎」去幹就可以了。
6. 賬務中心
賬務中心又叫帳戶系統、賬務核心。他一般系統包含了賬務、會計、總賬三部份。賬務對外提供記賬服務，並且即時更新客戶帳戶余額。會計部份用來登記會計賬簿、更新內部帳戶余額。總賬是日終的匯總核算服務，總賬平衡後當天的業務才算結束。
7. 對賬中心
又稱為清結算系統，資金系統，他負責與支付渠道進行賬務核對，差錯處理、手續費的清分和客戶資金的結算。同時對於資金歸集、劃撥等無法在即時交易中完成的結算操作，也是由清結算系統負責處理的。
四、支付架構流程由於支付系統對於交易處理效能和資金結算效率要求都比較高，因此它采用的是流水線作業方式。從前面介紹的兩條耦合鏈路我們知道，在支付架構的流程上表現出來的是線上鏈路、結算鏈路兩條鏈路。
圖6：支付系統流程圖
1. 線上交易鏈路
線上交易鏈路從「閘道器」到「渠道」形成一條支付請求的處理流水線，客戶、收銀台、帳戶和清結算各節點按部就班的處理流水線傳遞過來的資訊，完成客戶資訊校驗，資金帳號獲取，收銀台展示，賬務登記，渠道路由和跨行收付款操作。
2. 日終結算鏈路
結算鏈路又叫清結算流程，他針對日間的即時交易，進行對賬和清結算等處理，只有日終處理完了，一天的交易才算完畢。
下面我們就按照這兩條鏈路來詳細介紹他的處理機制。
五、線上交易鏈路1. 收單流程
收單業務是第三方支付的核心業務，他場景化比較豐富，因此系統流程也會相對復雜些。我們針對「API收款」、「收銀台收款」和「小程式收款」幾種典型場景進行介紹。
（1）快捷支付（API直接支付）
快捷的API支付，首次發送簡訊驗證碼繫結開戶銀行卡，收單機構會提供一個協定號給商戶保存；後續簡訊驗證碼可免，透過傳送綁卡時的協定號就能完成免密扣款。具體流程見下圖：
圖7 快捷支付流程
（2）收銀台支付（本地收銀台支付）
收銀台支付包含H5支付、SDK支付（整合在APP內），由於他可以包裝比較多的支付方式在收銀台上，因此又叫「聚合收銀台」。我們這裏介紹的場景是使用者在收銀台上選擇本地繫結的銀行卡，因此，透過快捷支付就能完成扣款，無需跳轉到第三方。具體流程見下圖：
圖8 本地收銀台支付流程
（3）小程式支付（渠道收銀台支付）
以小程式支付為代表的，APP支付、微信H5支付、公眾號支付、掃碼支付等，都需要跳轉到渠道方收銀台上輸入密碼並完成支付。這種支付方式對客戶來說比較安全，但是也比較封閉，因此在互動體驗上也復雜了不少。具體流程見下圖：
圖9 渠道收銀台支付流程
從上圖可以看到以「交易」和「支付」為流程排程者的優勢就出來了，他們可以任意的客製支付流程，從而滿足復雜場景對於支付的處理要求。
2. 余額支付
余額支付就是以帳戶余額為基礎的「充值、提現、轉賬到戶、轉賬到卡」的交易。
（1）帳戶充值（充值API）
帳戶充值與收單流程基本類似，就是在充錢需要判斷帳戶和繫結銀行卡是實名認證後的同名帳戶。具體流程見下圖：
圖10 帳戶充值流程
（2）帳戶提現（代付API）
提現是充值的反向交易，因此他獲取計費資訊、校驗綁卡同名與充值基本是相同的，區別在於它記賬方式不一樣。他采用先扣客戶余額，然後發送渠道付款，這樣資金處理比較安全。
圖11 帳戶提現流程
（3）轉賬到銀行卡（代付API）
轉賬到卡又稱為「代付業務」，它和「提現」在支付、賬務和渠道處理上是類似的，區別在於它的收款人不是本人。
圖12 轉賬到卡付款流程
六、日終結算鏈路日間即時支付交易完成後，日終清結算開始上場了。我們前面收單交易、充值交易等跨行收款交易資金還要結算給客戶和商家，並且要給商家提供賬單，這樣一天的業務才算完成，下面我們來介紹下日終的清結算處理流程。
圖13 日終清結算流程
1. 系統對賬
下載渠道、支付系統、交易系統對賬檔進行對賬。先核對渠道賬務，再對交易賬務並按商家帳戶維度進行交易清分和手續費扣收。
2. 差錯調賬
完成對賬後如果有差錯，以渠道為準在「帳戶系統」內調平本方賬務差錯。
3. 渠道清算
當日對賬無誤後，根據當日的應收應付的軋差金額和渠道銀存帳戶的期末余額，在帳戶系統內登記當日清算賬務。
4. 商戶結算
當日對賬無誤後，根據每個商戶、客戶的待結算資金進行結算，收款資金在他們帳戶上就可以使用了。（因為是以渠道方為準，渠道清算和商戶結算沒有必然的先後順序，所以只要賬務對平就可以進行）
5. 商戶提現
商戶結算完成後如果商戶設為自動提現，系統在T+1日自動完成商戶的打款操作，並生成商戶結算賬單。
6. 賬務核算
渠道清算和商戶結算完成後，帳戶系統的核算模組對當天的賬務進行總分核算、匯總平衡，最終生成報表。當日的交易也就處理完成了。
七、總結最後我們來總結下，支付系統架構層面的表現出來的就是「線上鏈路、日終鏈路」聯調鏈路。由於跨行收付款時，指令和資金到賬時效的不匹配，采用了日間記賬的方式來記錄待結算資金，透過日終清結算來給客戶結算跨行資金。
線上交易透過「閘道器、交易、收銀台、客戶、支付、渠道」6個模組是了跨行收付款和賬務登記。日終鏈路透過「支付、對賬、賬務、會計」這6個模式完成跨行資金的清結算。
