支付系統伴隨着電子商務的出現而出現，爲各類電子商務經營活動實現在線收付款交易，以及管理交易資金等功能，是具有一定獨立性的內部系統模塊。

一、什麼是支付系統

自古以來，所有的商業活動都會產生貨幣的收款與付款行爲。在人類漫長的歷史長河中，記錄收付款行爲的方式不斷迭代：古代的賬房先生通過手工記賬，工業社會通過收銀機機械記賬……

今天，進入了互聯網時代的我們，商業行爲也一同進行了數字化與信息化的演變，成爲今天的「電子商務」。

支付系統伴隨着電子商務的出現而出現，爲各類電子商務經營活動實現在線收付款交易以及管理交易資金等功能，是具有一定獨立性的內部系統模塊。

• 平臺：開展電子商務經濟活動的主體。
• 業務系統：實現平臺用戶註冊、商品定價、營銷活動等相關功能。

平臺與業務系統的關係：業務系統將用戶購買行爲通過各種交易訂單的形式進行記錄，並交付支付系統進行處理，最終由支付系統完成收款與付款。

根據央行的現行規定，人民幣交易處理僅限於銀行及第三方持牌支付機構，因此支付系統在實現上述功能時，需要通過外部銀行、第三方持牌支付機構完成交易資金處理。因此，支付系統需要具備：

• 統一封裝處理的交易接口，以對接外部交易渠道，爲業務系統實現交易訂單處理的功能。
• 根據業務系統設置的資金分配規則，在一筆交易有多個收款方參與的情況下根據資金分配規則完成交易資金的自動化清分與結算，而後通過已對接的外部交易渠道完成劃付。
• 賬務數據記錄功能，上述的交易、清分、結算形成的資金變動信息，需要支付系統通過賬務數據記錄功能加以記錄，對交易資金進行統計並完成交易資金覈對等財會工作。

二、支付系統架構

支付系統的主要職責是處理業務系統發起的所有交易請求，包含收銀臺、交易系統、支付核心等模塊，根據各模塊不同的功能職責，可以將支付系統分爲業務層和支付層兩部分。

• 業務層負責爲業務系統提供收付款的操作界面以及處理業務系統提交的交易請求；
• 支付層負責通過支付渠道實時處理完成資金的收付款、記錄參與交易的賬戶間資金流轉情況並按照預定規則對賬戶所屬資金進行拆分與合併。

1. 業務層

業務層包含收銀臺、交易系統以及會員系統三個功能模塊：

（1）收銀臺

收銀臺即用戶日常付款前選擇渠道的頁面，是支付平臺提供的基本功能之一，主要職責是協助業務平臺完成支付交易，向用戶提供一致的交易體驗。一般情況下，根據不同終端類型定製標準化的收銀臺給到外部進行調用，保證各終端體驗一致且針對各端特定需求、場景來展現不同的支付方式。

①收銀臺的業務場景（邊界）一般分爲付款與充值兩部分：

• 付款即通過各類支付方式針對業務訂單發起付款，例如：用戶在天貓店購買一件衣服，確認訂單後自動跳轉至支付寶，引導用戶選擇對應的方式（餘額、花唄、銀行卡等）進行付款。
• 充值即用戶對賬戶進行餘額充值，例如：用戶登錄支付寶、微信或其他商戶自有錢包系統對賬戶餘額進行充值。

②支付渠道的服務模型，分爲以下幾個要點：

服務模型的概念：從支付公司角度來看，服務模型是決定商戶可以使用的交易形式（擔保收單、即時到賬等）、支付產品（快捷、網銀、代扣、POS 等）、簽約方式、階段週期（T+0、T+1、T+N 等）以及費率等核心問題的綜合體；

從電商平臺角度來看，電商公司內部使用的支付系統與支付機構相比複雜度較低，可通過參考支付公司服務模型，梳理不同業務、不同交易類型、不同結算週期以及不同支付渠道等複雜需求，搭建合理且滿足業務需求的服務模型，例如充值類交易，具有商城屬性的業務可配置擔保收單或即時到賬等交易類型。

服務模型的維度：

行業/服務維度：即從業務角度出發對支付產品進行劃分。

例如：螞蟻金融面向行業輸出交易、結算、會員、安全等服務，且爲不同的服務等級劃定標準，貫穿所有內部系統；普通非支付公司（以電商爲例），提供即時到賬、擔保收單等，基本上能滿足大多數的業務場景。

商品維度：針對不同行業的交易標的，由於交易價格、成本與利潤差異大，因此在業務層面不同的支付渠道要有不同的可用性標準。

一般情況下，商品本身與市場或行業掛鉤，例如喜馬拉雅在接入微信/支付寶時，業務所在行業爲視頻影音屬於虛擬商品，因此接入費率爲 1%，結算週期爲 T+7。

由此可得，支付公司針對不同商品本身的特性（例如風險等因素）在費率和結算週期上會進行一定的控制；同時，針對高風險行業會在支付方式、渠道層進行限制。

市場維度：此處「市場」指的是指引客戶使用支付產品服務的場所，它可能是支付產品本身，亦可能爲相關公司或平臺的網站。例如某集團子公司、某公司投資的公司以及與該公司無關的外部公司等等，可分爲集團、內部以及外部等維度。

客戶維度：此處「客戶」指的是服務的具體使用者。可分爲個人客戶及企業客戶，通過支付系統內的會員系統進行區分。

付款方維度：付款方在整個業務過程中未核心角色，針對付款方用戶的特徵應建立以支付渠道收款方維度的模型，例如付款方的賬戶模型、安裝是否正式、證書等級等要素都決定着付款方的付款流程。

支付渠道維度：在電商平臺，跳轉到支付系統是，收銀臺根據付款方的參數規則，進而對該筆支付在收銀臺內可使用的支付渠道進行選擇。例如充值賬戶餘額不允許使用信用卡時，收銀臺在付款方付款時僅可展現借記卡等支付方式，喜馬拉雅在於支付寶等第三方支付公司交互式，下單接口裏一般含有做借貸分離的參數，該參數起到的作用就是可以指定付款方即用戶不可使用借記卡或信用卡。

業務渠道維度：業務端使用的入口，代表着客戶或者業務方和支付系統的交互方式。例如通過 PC 端跳轉到收銀臺、通過 App 跳轉到收銀臺以及純接口形式跳轉等等。

支付渠道各類配置：

1. 渠道配置：抽象收銀臺支付方式大類（第三方、網銀儲蓄卡、網銀信用卡、信用類（花唄、白條）等），對應每個大類下配置對應的落地渠道，再分別對適用場景進行匹配（ App、H5、PC 端、公衆號等等），不同的場景下應對應不同的支付方式。
2. 渠道參數配置：在業務進行中根據公司的具體情況，部分業務可能獨立運營，因此在獨立運營過程中財務需要就獨立業務傳入各支付渠道對應的密鑰及商戶 ID 等關鍵參數信息，以滿足業務方需要支付系統根據不同商戶信息調用對應渠道收款主體的需求。

（2）交易系統

交易系統本身是作爲支付系統外部處理業務邏輯的外圍系統。由於支付核心系統本身並非面向業務端且業務邏輯的多變性與複雜性，支付系統爲了兼顧穩定並能夠爲業務端提供靈活支持，因此需要在支付系統外層搭建面向業務端處理交易邏輯的交易系統。交易系統處理業務端的各種交易類型後，將業務信息轉化爲支付系統可識別的支付訂單並導入。

以擔保交易爲例，C 端用戶在天貓購買一件商品，成功支付後商家進行發貨，用戶確認收貨後平臺將貨款結算給商家。此處設計到「擔保交易支付」以及「確認收貨」環節，與支付系統內部的支付與結算步驟一一對應：

1. 用戶付款成功後對應交易的付款成功狀態；
2. 用戶確認收貨後對應交易的成功狀態。

從支付和收貨緩解可以看出，擔保收單交易就是講支付系統的支付基礎能力包裝後對外支持業務的一款產品。

交易系統的職責：

交易系統作爲支付系統的入口：

• 首先需要對接上層業務系統；
• 其次將支付系統的支付能力抽象出來，對外提供各類交易方式，例如下單、支付、修改金額、確認結算、退款、關閉交易以及查詢等能力；
• 最後，交易系統需要對各種交易類型進行定義，例如擔保交易、即時到賬、充值、提現等類型。

交易系統的場景（邊界）：

• 下單：生成交易訂單，確定交易參與；
• 退款：針對已支付的訂單進行退款，退款金額不得大於實際支付金額，積分的退款退回原積分賬戶，同時針對退款交易類型，會生成交易訂單號，關聯入款訂單；
• 修改金額：修改交易金額，對應生成新的支付訂單；
• 查詢：查詢交易結果、支付結果；
• 通知：通知上層業務系統交易狀態；
• 算費：通過算費子系統計算每筆訂單的手續費。

交易系統的交易類型：

• 即時到賬交易：買家在電商平臺選擇購買商品下單，付款成功後金額直接入賣家支付賬戶或者賣家銀行賬戶；
• 擔保收單交易：買家在電商平臺選擇購買商品下單，有部分金額爲擔保金額，買家付款成功後，擔保部分進入平臺方中間擔保賬戶，未擔保金額直接入賣家支付賬戶或者賣家銀行賬戶；
• 收單退款交易：買賣雙方在達成退款協議後，可針對及時到賬交易，訂金下定等已支付交易由商戶平臺發起退款請求；
• 普通轉賬交易：當平臺方需要對會員進行轉賬時，通過此接口實現金額的轉移；
• 合併支付交易：多筆交易訂單合併（並筆）付款，適用於購物車針對不同商家生成訂單的場景；
• 下訂交易：賣家和買家達成購買協議，先行支付部分訂金，該部分訂金在最終付款的時候可以被使用；
• 提現：客戶將支付賬戶的餘額提到客戶綁定的銀行卡賬戶，基於支付賬戶單筆或者批量付款；
• 凍結解凍：在交易前通過凍結能力將用戶的部分資金凍結，保障交易能正常進行，也可以由於某些原因（賬戶被盜、司法案件、反洗錢等），凍結用戶資金操作，保證用戶的資金安全；
• 充值：基於支付賬戶做餘額充值，將用戶的銀行卡賬戶資金充到用戶的支付賬戶餘額。

交易系統的交易特性歸類：

①實效性：

• 全額實時到賬：即時到賬類交易，付款後實時到賬；
• 部分確認支付、部分即時到賬：擔保收單類交易，這裏分爲部分擔保的場景，只有指定金額部分需要確認結算；
• 全額確認支付：全額擔保交易，電商交易場景下需用戶確認收貨後纔會將全部貨款結算給賣家。

②交易系統的支付形式：

• 單筆支付交易：單筆支付行爲，用戶基於一筆訂單發起付款；
• 合併支付交易：多筆合併支付行爲，用戶基於多筆訂單發起合併付款；

③業務類型：

• 收單交易：支付入款類型交易，付款人收款人分別是兩個角色；
• 充值交易：賬戶充值類交易，付款人和收款人都是同一個人，由外部賬戶到內部賬戶；
• 出款交易：基於賬戶做提現，付款人和收款人都是同一個人，由內部賬戶到外部賬戶；
• 退款交易：收單入款交易的反向流程。

（3）會員系統

會員系統是完整的支付平臺內極其重要的基礎模塊之一，負責管理支付系統內部的交易主體。會員系統保存了客戶在支付系統內部賬號的實體信息，爲客戶建立了統一的、以會員 ID 爲標識的會員基本信息、關係信息（會員和賬戶、會員和操作人、會員與銀行卡）視圖。

一般情況，會員在支付系統內部分爲個人會員和企業會員（默認企業會員有商戶權限），以電商平臺爲例，C 端用戶爲個人會員，B 端商戶爲企業會員：

• 通常，企業會員會配置一定的業務參數，比如結算週期、接口權限、支付方式配置等（開通商戶權限的情況下）；
• 在大多數互聯網公司，支付系統僅需要對接支付渠道的模塊，在沒有獨立平臺化的情況下，不太會出現需要獨立的賬戶體系。

2. 支付層

支付層包含支付核心、賬務核心以及清算核心三個部分。

（1）支付核心

下方的內容介紹了支付核心的職責、邊界以及系統架構三個部分。

支付核心的職責：

支付系統的職責爲通過支付核心與後端清結算、會計、賬務等系統的統一協作，讓前端支付產品可以更關注產品本身的邏輯，而減少對清分、對賬、儲值等後端服務的考量及動作；同時通過標準化的支付指令定義，統一前端支付產品的支付請求接口，提供適應各類產品使用的基礎支付服務。

支付核心的邊界：

• 支付服務：負責對後端支付系統的接口進行業務包裝，同時實現使用多個支付方式進行組合支付的功能；
• 支付服務流程：對各支付類型的支付服務流程進行定義，具體定義爲充值、提現、內轉支付（轉賬）、退款等原子類型，並實現對基礎服務的流程編排；
• 支付指令：發起訂單後，通過協議和協議明細項加工得出支付指令，需具備進行後續操作處理的全部要素信息；
• 支付協議：根據產品設立支付協議，因此支付協議的關鍵要素包含產品碼及支付編碼，定義着產品的處理流程、收付款信息、對應的支付渠道信息。

支付核心的系統架構：

如圖，將交易和支付分開，主要是爲了體現出支付系統的核心支付功能，能夠爲會員提供豐富的支付服務：支付核心定義原子支付類型；服務層提供支付業務能力，例如出款、轉賬、紅包、代金券、餘額、現金等；產品層能夠更加關注產品本身的邏輯，將後端標準化的邏輯交由支付層和清算層來處理，這樣就能做到靈活和標準兼顧。

（2）賬務核心

賬務核心的功能爲，根據前端業務系統的要求設計相匹配的賬戶類型、管理各類賬戶、記錄賬戶資金變動等，同時，按照公司內部的財會規範提供反映各賬戶間交易資金變化情況的會計數據；並且負責將自身記錄賬務流水與支付渠道結算資金和結算流水進行覈對，對對賬結果中出現的差錯交易進行差錯處理。

（3）清算核心

清算核心負責維護客戶參與交易時的清分、結算規則，並按照已配置的規則完成交易資金的清分與結算操作。

《支付系統設計白皮書》由 PingPlusPlus支付學院（ID：pingxxpi）出品。

本文由 @支付學院 原創發佈於人人都是產品經理，未經允許，禁止轉載。

題圖來自 Unsplash，基於CC0協議。