面對五花八門的支付架構圖，是否看得云里霧里？本文為大家總結了一套清晰的支付架構圖，讓你快速掌握一套支付體系是怎么運轉的，一起來看看吧。

你是否因為工作中需要畫支付架構圖，為怎么清晰的表達而煩惱呢？你是否對五花八門的支付架構圖看的云里霧里？今天我給大家介紹一套簡單又清晰的支付架構，讓你快速掌握一套支付體系是怎么運轉的?！纠弦幘?，只看精華的同學直接翻到最后第四章看總結】

01 支付系統介紹

1.1 什么是支付系統

能夠實現貨幣交換的軟件系統都可以被稱為支付系統，而我們這里介紹的是伴隨著電商業務而興起第三方支付機構所使用的“收單支付系統”。它和傳統的“信匯、電匯、銀企直聯、商業匯票”等支付結算系統最大的區別就是“買賣交易和資金轉移都可以在線上完成”。

這種交易方式極大地提升了商品銷售的效率。他也是電商業務和平臺經濟能興起核心基礎設施，因為順暢的收錢是任何商業模式成功的前提。

圖1：支付系統是電商經濟的核心基礎設施

1.2 支付系統分層

支付系統的定位就是根據客戶商業訂單完成跨行的收付款，將資金最終轉移到收款人的賬戶里。因此整套系統按照“一個系統、兩個通道、三層架構”來進行劃分。

圖2：支付系統架構分層

1.2.1 一個系統

為了實現買賣雙方的跨行收付款，支付平臺會把支付產品包裝成接口或支付頁面提供給客戶來使用，并通過系統的層層轉換來實現資金的跨行轉移到收款人賬戶里。因此，一個最簡單的支付系統由如下八個模塊組成。

圖3：支付中臺主要模塊

1.2.2 兩個通道

1）網關/終端（接入端）

它是支付系統的“接入端”，將支付產品通過接口、頁面、終端設備的形式提供給用戶進行支付、開戶和認證。同時訪問網關或者使用終端設備還要安裝“密鑰和證書”，以此來保證你支付的安全。

2）渠道（接出端）

它是支付系統的“接出端”，他負責對接三方、銀行、清算機構的支付接口，把他轉換成標準支付產品提供給上層的產品使用。如果選擇對接了多家銀行相同的支付產品，他能根據“訂單、渠道、穩定性”進行動態的路由選擇。

1.2.3 三層架構

1）產品層（深度支付包裝）

產品層是為了適應不同場景的支付需求，把基礎支付產品包裝面成向不同場景的銷售產品，滿足各行業各對于支付的特殊需求。例如面向個人用戶的B2C、C2C支付，面向企業的B2B支付，以及面向金融機構的消金支付等。因此產品層是對交易層的深度包裝，讓他更加適應不同的場景的需求，方便用戶使用。

2）交易層（基礎支付包裝）

為使用者提供基礎的支付產品，包括充值、提現、收款、分賬、付款等支付服務，滿足多場景對支付的基本需求。他主要包括了收銀臺、交易系統、客戶系統三部分。

• 收銀臺：通過頁面形式讓用戶順暢的完成支付操作，無需關注支付的技術實現。
• 交易系統：交易層的“流程調度者”，它對業務場景提供方便的接口或頁面操作，讓使用者無需關注底層的復雜的處理邏輯，專注業務場景的支付需求的實現。
• 客戶系統：為用戶提供所需要APP或網站，讓用戶可以對自己的交易、賬戶、資金進行管理。

3）核心層（原始支付服務）

“核心層”又叫“支付層”，是為交易層提供原始的賬務、渠道、清結算服務，他專注于內部賬務邏輯和支付渠道的處理邏輯，并且核心層也代表了一個系統的核心能力，他決定了上層產品是否好用、好賣、好管（人們常說產品看著挺好，用著很差，一般是核心能力不足造成的）。

• 支付引擎：核心層的“流程調度者”，為交易系統提供賬務處理、渠道調用、對賬明細等處理。讓交易系統無需關注底層邏輯的使用，支付引擎全權負責了后端和事后的管理。
• 賬戶系統：持牌機構由于要做清結算，因此會把會計賬務和資金賬戶放在一起進行賬務登記。他在支付引擎的驅動下，完成記賬、核算等賬務操作。
• 清結算：負責與渠道的對賬和客戶資金結算的處理，也是對資金管理的核心模塊。

02 支付業務架構

圖4：支付業務架構

業務架：構顧名思義就是面向業務場景提供的架構圖，他主要目的就是讓非技術人員了解系統具有哪些能力，以及系統提供產品和管理能力是否符合期望。業務架構一般分為兩張圖“架構圖、流程圖”，架構圖負責展示系統的功能結構，流程圖負責展示功能之間關系。

從支付的業務架構我們可以看到，相對于分層的架構圖，實際的業務架構有許多的輔助系統來支持支付業務的運行。不過支付業務核心閉環的還是支付服務中的8個模塊當主角，下面我們來分別介紹下。

2.1 收銀系統

收銀臺系統就是以頁面的形式提供給用戶進行收款操作，同時它也會面向不同的支付終端提供各種類型的收銀臺，我們按終端類型把它們分為五類。

1）H5收銀臺：這種是適配移動終端類型最多的收銀臺，由于它能夠實現快捷、公眾號、H5、錢包、數幣等多種支付方式的聚合，因此也叫聚合收銀臺。支付方式能夠根據參數進行展示和折疊，頁面樣式也支持自定義。

2）SDK收銀臺：這種是針對APP場景提供收銀臺，支持的支付方式與H5相同，不過體驗能夠做的更好，還能支持生物識別。當然這種支付方式需要和客戶的APP進行集成，使用起來比較復雜。

3）小程序收銀臺：這種主要是適配小程序場景，例如微信、支付寶、數幣等，但是由于小程序依賴于APP的運行環境，因此各種小程序支付方式要獨立分開。

4）WEB收銀臺：這種主要適配PC場景，分為個人網銀和企業網銀兩類，并且支付的額度比較高，相對安全性也有所提高，需要通過證書、UKey等方式進行支付。由于現在普遍使用移動端進行支付因此網銀支付的用在企業場景會比較多。

5）聚合收款碼：這類分為兩種，一種是碼牌他是基于收款賬戶包裝成一個收款二維碼，然后根據用戶掃碼的APP類型來適配調用微信還是支付寶的收銀臺，這種支付方式需要用戶自己手動輸入金額。另一種是商品碼，這種就是根據用戶購買的商品訂單的金額生成一個聚合碼，根據用戶APP類型來適配不同的渠道支付產品。這種支付方式用戶不需要輸入金額直接可以進行支付。收銀臺的形式有很多種了，主要還是看產品經理對于渠道支付產品特性的了解來包裝出多種多樣的形式。

2.2 交易系統

通過前面的介紹我們知道，交易系統是面向支付場景和用戶提供的服務，因此他主要職責是處理業務場景復雜多變的支付處理需求。交易系統在交易層扮演以下角色：

圖5：交易系統核心能力

1）產品的提供者交易系統負責給外部使用收銀臺，收款、付款、余額支付等交易方式，并且根據不同的場景提供擔保交易、合單支付、組合支付等分賬交易把資金分給交易的參與方。因此我們使用的支付產品其實都是交易系統提供的服務。

2）流程的調度者交易系統是處理客戶請求的流程調度者，他根據客戶提交的支付訂單進按照流程的先后順序調用收銀臺、客戶系統、支付引擎來完成支付處理。

2.3 客戶系統

顧名思義是為客戶提供服務的，因此他對內對外提供的功能會比較多，他主要會是面向客戶各種使用和登錄的入口來提供服務的。

1）服務端：服務端就是通過接口或者頁面向客戶提供服務，因此他是一種開放能力?？梢酝ㄟ^客戶或者服務商以接口對接的形式，將客戶服務嵌入到外部平臺的App、網站、小程序中，讓外部平臺具可以使用持牌機構的賬戶能力進行交易。

2）會員端（錢包）會員端是面向支付產品使用者（一般是消費者，買方）提供的支付服務，通過開通會員錢包賬戶存放自己的資金，并且也能通過錢包賬戶進行充值、提現和轉賬。

3）商戶端：商戶端是面向商家的服務端，由收單機構提供商戶APP或者商戶網站給商家提供，交易管理、賬單和回單、賬戶和資金管理等服務。

2.4 產品中心

產品中心是包裝對外銷售產品的一個配置中心，并且商戶相關的簽約產品、計費信息、交易限額等都可以通過的靈活的模版來進行配置。它的作用如下：

1）提高配置效率通過模板化的配置工具來提高商戶產品的配置效率，讓商戶快速的使用產品。

2）快速組裝新產品其實一個新的支付產品，需要重新開發的新特性不會太多，其中大部分都是基礎支付產品的復用。所以通過組件化的配置工具，通過少量的新特性開發就能快速搭建一個新的銷售產品出來。這樣一方面減少了產品的重復開發，另一方面成熟的功能多，新產品也比較穩定。

2.5 支付引擎

支付引擎顧名思義是支付的發動機，他負責所有系統與賬戶、渠道的支付流程處理。

圖6：支付引擎核心能力

1）支付提供者它對交易層的“交易系統”、“客戶系統”、“收銀臺”等屏蔽了底層支付賬務、支付渠道管理的復雜性，讓交易層可以專注于業務場景，即使底層渠道更換，賬務進行調整，交易層也不會受到影響。

2）流程調度者有了支付引擎這個大當家，流程處理相關的“臟活累活”都由他來負責。賬戶、渠道、清結算就可以各司其職做好本職工作，如果涉及其他系統協作，通知“支付引擎”去干就可以了。

2.7 賬戶系統

賬戶系統又叫賬務系統，賬戶系統。他一般系統包含了賬務和賬戶兩部分，其中賬務部分負責為支付引擎提供記賬服務、記錄資金變動情況，賬戶部分用來對賬戶進行管理，記錄并呈現賬戶的余額情況。

1）賬務管理

• 記賬服務：該服務面向支付引擎提供記賬、余額更新、查詢和賬戶控制等服務。并將自身的賬務流水提供給清結算系統進行核對。
• 會計服務：按照會計規范設置科目和分錄，為記賬服務提供反應賬戶間資金變動的會計數據。
• 核算服務：按照會計準則核對當天的資金賬務和庫存現金情況，確保賬務準確和真實。

2）賬戶管理

是對資金賬戶的管理，他分為“客戶賬戶”和“內部賬戶”兩部分，客戶賬戶是存放客戶自有資金的賬戶，他是提供給客戶使用的。內部賬戶是用來給持牌機構內部登記資金賬務的賬戶，也叫內部戶、過渡戶等。

2.8 清結算系統

又稱為對賬系統，結算系統，他負責與支付渠道進行賬務核對，差錯處理、手續費的清分和客戶資金的結算。同時對于資金歸集、劃撥等無法在實時交易中完成的結算操作，也是由清結算系統負責處理的。

03 支付架構流程

支付系統對于交易處理性能和資金結算效率要求都比較高，因此它采用的是流水線作業方式，在支付架構的流程上表現出來的是兩條主干交易鏈路，實時交易鏈路和日終結算鏈路。

3.1 流水線作業

整個支付系統就像一個工廠車間一樣，他通過實時和日終兩條流水線分別處理實時交易和日終資金結算，這樣的處理方式很好平衡了交易指令和資金到賬時間不平衡的問題。

圖7：支付流水線作業

1）實時流水線實時流水線，通過“網關”到“渠道”的交易流水線，處理源源不斷從網關發過來的支付請求，最終發往支付渠道完成客戶的跨行收付款處理。

2）日終流水線日終流水線又叫清結算流程，它針對日間的實時交易，進行對賬和清結算等處理，只有日終處理完了，一天的交易才算完畢。

3.2 支付架構流程

圖8：支付系統流程圖

3.2.1 兩條主鏈路

1）實時交易鏈路

實時交易鏈路從“網關”到“渠道”形成一條支付請求的處理流水線，客戶、收銀臺、賬戶和清結算各節點按部就班的處理流水線傳遞過來的信息，完成客戶信息校驗，資金賬號獲取，收銀臺展示，賬務登記，渠道路由和跨行收付款操作。

2）日終結算鏈路

以清結算系統為起點，通過自動任務獲取渠道和交易層的數據進行對賬與差錯核對，然后通過支付核心與賬戶系統交互完成渠道清算、商戶結算、內部核算操作，最終為客戶生成對賬單后完成一天的業務處理。

3.2.2 實時雙驅動

為了既能處理業務的復雜場景，又能處理渠道和賬務的復雜支付邏輯，系統采用了“雙發驅動”的模式，臟活累活全都給“交易”和“支付”去處理，兩者配合讓整條流水線上的各個模塊有效的協作起來。

1）交易系統（交易發動機）

是交易層的交易流程調度者，他負責業務場景中的各種復雜交易場景的流程處理。

2）支付系統（支付發動機）

是核心層的支付流程調度者，他負責支付賬務、渠道調用的流程處理。

3.2.3 日終做日清

負責日終后的對賬和結算處理的流程，驅動支付系統完成渠道清算，商戶結算，最終為商戶生成結算賬單和回單，完成整個支付業務的閉環。

3.2.4 其他保持獨立

其他的“客戶”、“賬戶”、“收銀臺”、“渠道”四個模塊接受這兩個流程的驅動去各自完成自己的事情就可以了。這樣就這樣可以保持交易鏈路清晰，避免多模塊之間調用不清造成混亂。

下面我們通過幾個典型業務，對支付系統模塊間的協作關系進行詳細的介紹：

3.3 收單流程

收單業務是第三方支付的核心業務，他場景化比較豐富，因此系統流程也會相對復雜些。我們針對“API收款”、“收銀臺收款”和“小程序收款”幾種典型場景進行介紹。

3.3.1 快捷支付（API直接支付）

圖9：快捷支付收款流程

快捷支付：又叫“協議支付、簽約扣款等”（俗稱為代扣，因為比較容易和早期的裸代扣混淆，因此這么說的人并不多）?？旖莓a品的特點就是，持卡人需要先四要素簽約綁卡（姓名、手機號、身份證、銀行卡）進行四方簽約（持卡人、收單機構、清算組織、發卡銀行）

上圖是一個快捷API扣款的流程，他的主要特點如下：

1）首筆短驗，后續可免首次簽約需要輸入短信驗證碼來確認用戶授權，后續扣款短驗和直接扣款都支持。因此首筆簽約時通過“客戶系統”向“渠道”發送請求，通知“發卡銀行”向客戶手機發送短信驗證碼。

2）先渠道扣款，再賬戶記賬為了保證資金的安全收款交易普遍采用，第三方扣款成功后，再給客戶賬戶或者商戶賬戶記賬。這樣可以確保渠道未支付成功的時候，資金不被客戶挪用。因此，“支付系統”先通過“渠道”進行跨行扣款，如果返回結果為成功就去“賬戶系統”完成記賬處理。

3）流程順暢，渠道可路由整個過程從簽約、短驗、支付，按照產品、交易、支付、渠道的按照線性化的流程處理，因此支付過程雖然較多，但是比較順暢。同時，由于渠道完全按照收單機構的指令執行，因此在用戶主動支付的場景下（用戶每次都可會輸入驗證碼）渠道是可以路由的。

3.3.2 收銀臺支付（本地收銀臺支付）

收銀臺支付包含H5支付、SDK支付（集成在APP內），由于他可以包裝比較多的支付方式在收銀臺上，因此又叫“聚合收銀臺”。我們這里介紹的場景是用戶在收銀臺上選擇在收單機構綁定的銀行卡，這種場景收單基本通過快捷支付就能完成扣款，無需跳轉到第三方。

圖10：本地收銀臺支付流程

該流程的特點如下：

1）跳轉收銀臺完成支付用戶（付款人）下單后，收單機構給客戶返回收銀臺地址，客戶跳轉到收銀臺上完成支付。因此交易系統負責按照用戶下單和使用的支付產品生成收銀臺地址，返回給用戶完成下單后的支付操作。

2）在客戶系統獲取“綁卡協議號”如果用戶選擇銀行卡付款，需要去“客戶系統”檢查綁卡信息，并獲“綁卡協議號”（短信簽約時渠道返回的協議號）然后通過渠道扣款。

3）通過協議號完成扣款交易系統拿到協議號之后，通過支付引擎、支付渠道將協議號傳給開戶行，開戶行完成扣款后原路返回，將結果通知給客戶。需要說明的是，這里的協議號按照“用戶、收單機構、清算機構、開戶銀行”四者關系生成，任何一方出現變化都需要重新簽約。

3.3.3 小程序支付（渠道收銀臺支付）

以小程序支付為代表的，APP支付、微信H5支付、公眾號支付、掃碼支付等，都需要跳轉到渠道方收銀臺上輸入密碼并完成支付。這種支付方式對客戶來說比較安全，但是也比較封閉，因此在交互體驗上也復雜了不少。

圖11：渠道收銀臺支付流程

該流程的主要特點如下：

1）下單獲取參數首先通過用戶下單向渠道方（微信、支付寶）獲得收銀臺的參數，以便后續跳轉準備。

2）跳轉收銀臺根據下單獲得參數返回給商戶端后跳轉到渠道方的收銀臺，用戶在渠道方的收銀臺上完成支付。此時商家對于用戶的操作情況是一無所知的，只能等待渠道方的通知。

3）回調返回結果當用戶完成支付后，渠道方會主動發起一個回調通知給收單機構，收單機構把結果給商戶端。如果長時間沒有返回。有兩種處理方式來同步最終結果，一種是主動發起查詢支付結果，另一種是做個倒計時超時直接發起撤銷或者退款（類似12306購票）從這里我們就可以看到以“交易”和“支付”為流程調度者的優勢就出來了，他們可以任意的定制支付流程，從而滿足復雜場景對于支付的處理要求。

3.4 余額支付

余額支付就是以賬戶余額為基礎的“充值、提現、轉賬到戶、轉賬到卡”的交易。

3.4.1 賬戶充值（充值API）

圖12：賬戶充值流程

1）它不是簽約產品充值和提現都是賬戶默認具有的功能，因此在產品層只讀取計費信息即可。

2）同名卡才是充值充值必須要開通的賬戶和綁定的銀卡為同一個人，明確要經過實名認證。因此流程中訪問客戶系統既要驗證你的資金賬戶是否實名，也要驗證你的綁卡是否賬戶同名。

3）記賬入客戶待結算充值的賬務是入交易發起者的錢包賬戶，由于跨行收款D1到賬的原因，因此先計入客戶待結算或者凍結收款余額，等到日終結算的時候才能釋放資金。

4）渠道走快捷支付雖然是個充值產品但是底層通道走的是快捷支付扣款，因此整個支付處理流程與快捷是一樣的。

3.4.2 賬戶提現（代付API）

提現是充值的反向交易，因此他獲取計費信息、校驗綁卡同名與充值基本是相同的，區別在于它記賬方式不一樣。

圖13：賬戶提現支付流程

1）先凍結，后出款提現底層走的是跨行付款通道，他與收款不同是“實時結算”的，為了避免在銀行未入賬的情況下客戶使用資金，因此提現采用先凍結賬戶余額，再通過渠道向開戶行發送付款申請的方式。

如果付款成功，則將余額解凍后劃入清算賬戶待日終對賬后，由收單機構完成跨行清算。如果付款失敗該怎么辦呢？解凍并釋放余額就可以了。

3.4.3 轉賬到銀行卡（代付API）

轉賬到卡又稱為“代付業務”，它和“提現”在支付、賬務和渠道處理上是類似的，區別在于它的收款人不是本人。另一個區別是這種API的代付屬于是支付產品，并且支付的額度也是受限的。因為代付產品額度較大的容易被作為清算接口使用，會造成業務風險。

圖14：轉賬到卡支付流程

3.5 清結算流程

日間實時支付交易完成后，日終清結算開始上場了。我們前面收單交易、充值交易等跨行收款交易資金還要結算給客戶和商家，并且要給商家提供賬單，這天的業務才算完成，下面我們來介紹下日終的清結算處理流程。

圖15：日終清結算流程

1）系統對賬下載渠道、支付系統、交易系統對賬文件進行對賬。先核對渠道賬務，再對交易賬務并按商家賬戶維度進行交易清分和手續費扣收。

2）差錯調賬完成對賬后如果有差錯，以渠道為準在“賬戶系統”內調平本方賬務差錯。

3）渠道清算當日對賬無誤后，根據當日的應收應付的軋差金額和渠道銀存賬戶的期末余額，在賬戶系統內登記當日清算賬務。（后續清結算的文章中我將會詳細介紹）。

4）商戶結算當日對賬無誤后，根據每個商戶、客戶的待結算資金進行結算，收款資金在他們賬戶上就可以使用了。（因為是以渠道方為準，渠道清算和商戶結算沒有必然的先后順序，所以只要賬務對平就可以進行）

5）商戶提現商戶結算完成后如果商戶設為自動提現，系統在T+1日自動完成商戶的打款操作，并生成商戶結算賬單。

6）賬務核算渠道清算和商戶結算完成后，賬戶系統的核算模塊對當天的賬務進行總分核算、匯總平衡，最終生成報表。當日的交易也就處理完成了。（后續清結算和會計文章中會詳細介紹）

04 總結：支付架構四張圖

4.1 三層架構

支付系統采用三層架構來劃分，外三層是“場景、系統、渠道”，內三層是“產品、交易、核心”，我們所說的支付架構主要是系統層面內三層的劃分，他由三部分組成：

圖16：支付系統分層

1）一個平臺：承載支付業務。

2）兩個通道：網關接入適配不同場景，渠道接出適配不同金融資源。

3）三層架構：產品、交易、核心三層架構，采用流水線方式處理源源不斷的支付請求。

4.2 八個模塊

支付中臺一般由八個模塊組成，他承載了支付業務核心的閉環功能，可以適應不同場景的支付需求。

圖17：支付系統八個模塊

4.3 流水線作業

圖18：支付系統的流水線作業

1）實時流水線：從“網關”到“渠道”形成一條支付請求的處理鏈路，系統各模塊處理流水線傳遞過來的信息，最終的跨行收付款操作。

2）日終流水線：從其結算系統開始，處理每天渠道資金清算、商戶資金結算、賬務核算的處理流程，這樣才算完成一天的交易閉環。

4.4 支付流程

圖19：支付系統流程圖

1）兩條主鏈路：橫向的實時交易鏈路處理交易請求和與跨行收付款，縱向的日終結算鏈路處理賬務和清結算工作。

2）日間雙驅動：實時交易鏈路，由兩個流程調度者“交易、支付”來協調各個模塊來處理支付請求。

3）每天做日清日終交易鏈路，以清結算系統為起點，每天日終清結算系統和支付、賬戶模塊完成一天最終的賬務處理。