背景：

? ? 上個月接受資金池系統，月底又要出財務報表，一個月沒顧上看書，利用假期補上兩篇讀書筆記。也是對賬ping++的《支付系統白皮書》來看，現在所負責的支付系統是什么狀態，要往什么階段去演進。

一 支付系統概述

1.1 什么是支付系統

在古代隨著生產力的發展，有了剩余物品，有了貨幣，有了文字、數字，才有古老的會計（數量跟計量單位），反應了賬單的內容。?現代支付系統伴隨電子商務系統發展來生，提供了在線收付款交易以及管理交易資金的功能。

業務系統將用戶購買行為通過各種訂單的方式進行記錄，有支付系統進行處理，最終有支付系統進行收款與付款。通常收法律規定，一般公司是沒有持牌的第三方支付公司，所以需要跟銀行及三方支付對接完成交易資金的處理。

支付系統的三個特征：

1.同一封裝交易的接口，對接外部交易渠道，為業務系統實現交易訂單的處理功能。

2.根據業務系統設置的資金配置規則，根據資金配置規則完成交易資金的自動化清分和結算，然后通過已對接的外部交易渠道完成劃付。

3. 帳務數據的記錄功能：上述的交易、清分、結算形成的資金變動信息，需要支付系統通過賬務數據記錄功能加以記錄，對交易資金進行統計，并完成交易資金核對等財會工作。

***************************************

現有系統，對比下上面三個點：

1 業務系統進行訂單的計價、下單、派單的邏輯，結算系統抽傭后，有交易系統進行支付。

2.交易推送訂單的賬務信息到資金池（會員賬戶系統），資金池再推送到清分，清分走光大銀行的托管進行虛擬指令操作，資金池再進行結算，更新賬戶的可提現額度等，司機鑒權后發起提現申請。完成資金的劃付。

3. 目前只有資金池的賬戶系統，缺乏對應會計賬務數據，導致出財務報表異常困難，不能有效的支持，依賴BI的大數據平臺，通過hive的形式，效率低下，每到月底都需要人肉支持，疼點之一。

1.2 支付系統架構

? 支付系統主要職責是處理業務系統發起的交易請求，可以從各個組成模塊的職責，來分為業務層、支付層兩部分。

? ?

業務層：對接業務，提供支付的接口或者頁面（實際落地可以靈活，比如收銀臺有的業務線就想自己做頁面，那我們支付系統提供接口就好），處理業務系統提交的交易請求。

支付側：負責通過支付渠道完成實時的資金的收付款、記錄參與交易的賬戶間的流轉情況，按照預定規則對賬戶資金進行拆分合并。

1.2.1 業務層

業務層包含：收銀臺、交易系統、及會員賬戶系統。

收銀臺

及用戶常見的付款前選擇支付渠道的頁面，是支付平臺對外提供的基本功能之一，職責是協助業務平臺完成支付交易，想用戶提供一致的交易體驗。實際落地有提供頁面（FE），或者提供支付接口（業務側做頁面），或者提供二碼合一（微信、支付寶）的中轉碼等不同方式。

具體業務場景：包含支付與充值兩種。目前來說都是即時到賬的，（司機的實際到賬不一定，收凍結期及鑒權等限制）

支付：多種支付方式（包含三方跟優惠券）

充值：對于余額充值常見。

服務模型：這里考慮的因素很多，對于常見的小公司，對接主流的第三方（微信、支付寶即可），看看及時到賬或者擔保交易是否滿足業務需求。要不要對接網銀、或者三方pos轉賬等？需要實際業務考慮。很可能線下POS轉賬，運營人員不規范，月底對賬很麻煩，不如線上化方便。

交易系統

? 交易系統本身是作為支付系統的外部處理業務邏輯的外圍系統。支付系統本身相對穩定不是為了面向業務系統，為了滿足業務系統的多變復雜，交易系統起了將外部業務系統轉化為支付系統可識別的支付訂單并導入。

從實際的下單支付場景為例：用戶支付對應的交易狀態為支付成功。司機確認后訂單狀態為交易的成功狀態。在觸發后續動作。

從支付跟確認兩個環節來看，交易系統是把支付系統的基礎支付能力包裝后對外支持業務的一款產品。

交易系統的職責：

對接上層業務系統（）

抽象支付系統能力，對外提供接口：如下單、支付、修改金額、確認訂單完成，退款以及查詢能力。

定義各種交易類型，如擔保交易，及時到賬，充值、提現等。

交易系統的邊界

下單：生成交易訂單，確定交易參與。

?退款：已支付訂單進行退款，退款金額不得大于原來支付金額，通常退回原賬戶（三方超時退款或者原賬戶注銷等改為人工操作），關聯入款訂單。

修改金額：通常對于未支付訂單，修改交易金額，去支付。

查詢：查詢交易結果，支付結果。

通知：通知上層業務系統交易狀態。

算費：通過子系統計算每筆定單的手續費（我理解平臺抽傭子系統的入口也在這里）

交易系統的交易類型：

及時到賬交易：電商平臺那種買家付款成功直接進入賣家賬戶。

擔保收單交易：買家支付金額進入平臺的擔保賬戶，

收單退款交易：可對已支付交易發起退款，實際入口不一定在用戶端。

合并支付交易： 多筆訂單進行合并付款，購物車中多個不同商家生成訂單。（復雜在于訂單如何匹配營銷進行拆分子訂單）

充值：把用戶的三方資金充值到用戶的賬戶余額。

提現：用戶賬戶余額提現到用戶綁定的銀行卡賬戶（需要做四要素的鑒權）

凍結解凍：除正常業務需求設置賬期（T+N）外，還可以對涉及某些原因（違法），對賬戶進行凍結不可提現，保證資金安全。

業務類型：

收單交易：支付入款類型交易，付款人收款人兩個角色。

充值交易：賬戶充值類交易，付款人收款人是同一個人，從外部賬戶到內部賬戶。

出款交易：基于賬戶做提現，付款人收款人是同一個人，從內部賬戶到外部賬戶。

退款交易：收單入款交易的反向流程。

?

會員系統（賬戶系統）

?非平臺類只對接支付即可，平臺類需要有賬戶系統，包含用戶信息（可以在CRM），綁定銀行卡信息，賬戶流水等。

1.2.2 業務層

業務層包含支付核心，賬務核心，清算核心。

支付核心

支付核心的職責：通過后端的清結算、會計、賬務等系統統一協作，讓前端支付產品跟關注本身業務邏輯。同時通過標準化的支付指令定義，統一前端支付產品的支付請求入口，提供各類產品使用的基礎支付服務。

支付系統的邊界

支付服務：封裝底層支付系統的接口，提供多個支付方式進行的組合支付。

支付服務流程：具體定義支付、充值、提現等原子類型，并對服務流程進行編排。

支付指令：通過支付協議加工得到支付指令，包含后續操作全部要素。

支付協議：包含產品支付流程、收付款信息，對應的支付渠道信息。

目前：欠缺的的是財務系統、會計系統、核算對賬系統。靠月底手動導報表去跟財務對賬。

圖上的交易與支付拆分開，目的是為了體現出支付系統的核心支付能力，產品層管關注產品本身邏輯，將后端標準化的邏輯交由支付層跟結算層來處理。做到了標準與靈活的兼顧。

財務核心

?根據業務系統的要求設計相匹配的賬戶類型，管理各類賬戶，記錄賬戶的資金變動，同時按照公司內部的財會規范提供反應各賬戶資金變化的會計數據，負責將自身記錄賬務流水與支付渠道結算資金和結算流水進行核對，并處理對賬中的差錯處理。

清算核心

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

?

總結

以上是生活随笔為你收集整理的《支付系统白皮书》读书笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。