本文跟大家探討一下支付核心的七個要點，一起來看看~

一、支付前置

著業(yè)務定制化對交易支付需求復雜度的增加，交易系統(tǒng)保證系統(tǒng)穩(wěn)定的同時，亦需靈活性以支持業(yè)務。但系統(tǒng)設計時，靈活和穩(wěn)定是矛盾的，穩(wěn)定意味著剝離變化，靈活意味著可配置化。

支付前置的職責即：解決支持業(yè)務變化的擴展性，將交易通過支付前置的配置轉化為后端支付系統(tǒng)能統(tǒng)一處理的模式，方便后端多樣化的記賬需求。

支付前置的定義

• 支付前置包裝后端支付核心系統(tǒng)的接口，包裝后對外提供的服務包括余額、 現(xiàn)金、網(wǎng)銀、快捷支付、出款及相關訂單的退款和控制接口；另提供后臺系統(tǒng)調用的服務包括確定性入款、登賬、凍結解凍、退票等，所有的支付行為都會以業(yè)務支付訂單的形式落地；
• 用戶在前端發(fā)起一次支付行為后，交易系統(tǒng)基于原始的交易訂單，對應生成一條付款訂單，通過這筆付款訂單和支付核心進行交互。

業(yè)務產(chǎn)品碼：

交易系統(tǒng)各類交易接口包裝成業(yè)務產(chǎn)品（提現(xiàn)、充值等）后，將對應的支付請求發(fā)送到支付前置系統(tǒng)，前置系統(tǒng)根據(jù)業(yè)務產(chǎn)品編碼和本身的支付業(yè)務配置關系，生成對應的業(yè)務支付訂單并處理后續(xù)流程。

支付產(chǎn)品碼：

由于即時到賬、擔保交易在業(yè)務規(guī)則上不同，但支付渠道側判斷均為支付，因此支付產(chǎn)品碼相同，但業(yè)務產(chǎn)品碼不同。這里的支付產(chǎn)品編碼配置來自于支付協(xié)議的配置，一個支付產(chǎn)品編碼代表著一個支付協(xié)議。

二、支付協(xié)議

支付協(xié)議即對支付模式、支付服務的封裝。

以收單支付為例，某個業(yè)務方在支付系統(tǒng)開設支付權限后，可理解為與支付系統(tǒng)本身簽署了收單支付協(xié)議，即可通過交易系統(tǒng)對外輸出擔保交易產(chǎn)品、即時到賬產(chǎn)品來使用收單支付的能力。

此時交易側定義的兩個業(yè)務產(chǎn)品碼，與支付側的收單支付產(chǎn)品編碼為多對一關系，交易系統(tǒng)調用前置系統(tǒng)時，根據(jù)交易產(chǎn)品代碼和支付協(xié)議的配置，對應生成一條收單支付的請求，前置系統(tǒng)根據(jù)該請求轉化為對應的付款訂單（支付協(xié)議的明細項，比如通過網(wǎng)銀、現(xiàn)金、快捷等方式發(fā)起支付），然后根據(jù)對應支付模式、業(yè)務支付類型生成業(yè)務支付訂單，且將業(yè)務支付訂單轉化為支付指令去執(zhí)行下游系統(tǒng)的流程。

提現(xiàn)協(xié)議：

1. 以秋秋老師的提現(xiàn)協(xié)議為例，提現(xiàn)的明細項關聯(lián)著業(yè)務方所傳遞的外部訂單號，代表著這次業(yè)務支付行為的原始訂單請求，對應著收付款人的信息；
2. 調用支付服務層的時，會有客戶權限校驗等判斷，通過的情況下此時去調用支付協(xié)議的配置信息落地一筆支付訂單，并基于該訂單生成對應的一筆或者多筆支付指令，接下來由指令去執(zhí)行調用下游系統(tǒng)的具體方式，若是調用清算通道則生成清算類的操作指令（調用通道，調用時間，通道需要的信息等），可稱為外部指令，若是要操作賬戶金額則生成賬務類的操作指令（具體賬戶、金額、借記還是貸記），可稱為內(nèi)部指令。

三、支付引擎

1. 支付引擎的類型

定義支付的原子級支付形態(tài)，所有的支付行為都是賬戶資金的流轉，可梳理出以下幾個支付類型：

• 充值：資金從外部資金源向內(nèi)部資金源轉移的支付動作；
• 提現(xiàn)：資金從內(nèi)部向外部資金源轉移的支付動作；
• 內(nèi)轉支付（轉賬）：資金在內(nèi)部賬戶轉移的支付動作，這里的定義和產(chǎn)品中定義的轉賬概念不同；
• 退款：充值的反向操作。

2. 指令

指令即支付核心的工單號，前置的每筆支付訂單對應著一筆甚至多筆指令。指令里包含了這筆支付訂單是原始支付類型（充值、提現(xiàn)、轉賬、退款，指令一定是基于原始支付類型來生成的，任何支付行為都能被原子類型所支持），對應著的業(yè)務請求類型、支付方式、支付產(chǎn)品編碼、參與方信息（交易中收付款人的信息）、相關聯(lián)的支付指令信息（退款時用于關聯(lián)原支付指令）、支付服務流程等相關信息；由支付指令去調用支付服務流程時，再根據(jù)流程編排環(huán)節(jié)去確定何時生成賬務類操作指令和清算類操作指令。

舉例：用戶在電商網(wǎng)站購買一本書價格 100 元，通過支付寶付款，交易類型為擔保交易，在交易核心生成一筆擔保支付的訂單，調用支付核心系統(tǒng)時支付系統(tǒng)判斷該業(yè)務調用方對應已經(jīng)配置了「收單支付協(xié)議」，且根據(jù)對應協(xié)議生成一筆業(yè)務類型為第三方支付的支付訂單，基于此訂單生成了第一條充值的支付指令。

該指令在根據(jù)支付類型去調用服務流程時，先通過流程編排生成清算指令并調用（這里值得注意的是，先生成清算指令的原因在于需要先調用外部支付渠道，把錢收進來），用戶付款成功后再生成賬務指令并調用賬務核心，執(zhí)行內(nèi)部賬務入賬。

3. 服務流程

定義支付指令的執(zhí)行流程，將支付拆分成原子級支付類型，并對支付類型的流程進行編排，任何一個交易的請求，都能被上述四種基礎支付類型組合進而完成支付行為。

例如：一筆擔保收單的交易，用戶用支付寶等第三方支付完成了這筆交易，并在 7 天后確認收貨，平臺側 7 天后根據(jù)用戶的行為應該將該筆貨款打給了商戶。

這里我們將用戶的行為分為支付和確認收貨兩個動作，對應著在交易側這也是兩次請求，一次支付，一次結算：

• 在支付層對應收單支付協(xié)議；
• 在前置系統(tǒng)被拆分成了兩筆業(yè)務支付訂單，一筆是快捷支付（業(yè)務類型，類型自定義，可以叫第三方支付），一筆是余額轉賬（將資金從擔保賬戶結算到商家賬戶）；

而后分別生成兩條支付指令（充值和轉賬），充值代表著用戶的支行為，轉賬代表著用戶的確認收貨行為，因為從但保護結算到商家賬戶，可以定義為這是一筆賬戶之間的資金扭轉。

四、風控

風控是風險交易防范與控制的簡稱。支付系統(tǒng)設計中，提升自身的風控意識，在必要時為交易增加風控模塊，可以有效減少風險交易造成的資金損失。支付核心的風控模塊，一般位于交易處理的最前端，每筆交易通過風控模塊的檢驗后，才允許支付核心進行后續(xù)的交易處理。

是否設置風控模塊，需要評價投入產(chǎn)出比。當支付系統(tǒng)內(nèi)積累了一定量風險交易數(shù)據(jù)，并且已經(jīng)產(chǎn)生實際經(jīng)濟損失的情況下，則需考慮在支付系統(tǒng)內(nèi)設置風控模塊。

1. 業(yè)務規(guī)則

為支付核心設計交易流程和業(yè)務規(guī)則時，了解交易中可能發(fā)現(xiàn)的風險因素并注意異常環(huán)節(jié)，是攔截風險交易的有效途徑。對于一些常見的支付產(chǎn)品設計中，已經(jīng)形成了一些能夠有效防范風險交易的通用業(yè)務規(guī)則。

余額賬戶：

用戶使用余額賬戶進行首次充值時，必須通過賬戶信息的實名認證。由于用戶在銀行辦理銀行卡時，銀行一定會對持卡人的身份進行實名認證，所以對平臺余額賬戶使用者可以通過利用銀行或支付機構提供的銀行卡信息驗證接口，對用戶進行實名認證。

• 進行實名認證時，需要驗證姓名、身份證號、銀行卡號、手機號；完成實名認證后，用戶必須設置支付密碼，后續(xù)自消費和提現(xiàn)時，就可以使用支付密碼保證余額資金的安全。
• 用戶更換余額賬戶提現(xiàn)銀行卡時，必須對已綁定的銀行卡進行進行校驗，要求用戶輸入已綁定銀行的完整賬號和綁定手機號；同時新綁定的提現(xiàn)銀行卡，也必須和賬戶已驗證的身份信息一致。

以上措施，可有效防止用戶個人信息泄漏造成的余額賬戶資金損失。

2. 風控模型

風控模型，是依賴可獲取的交易信息和客戶信息，抽象出的風險交易特征。可用于抽象分析風險交易特征的主要有三類：

1. 交易信息：該筆交易自身的信息要素，例如交易類型、交易金額、交易時間、支付賬號等信息；
2. 客戶信息：發(fā)起該筆交易的平臺用戶信息，包括用戶使用的設備類型、設備編號、用戶定位信息、用戶手機號、手機號歸屬地等；
3. 歷史數(shù)據(jù)：用戶在平臺發(fā)生過歷史交易，其歷史交易的交易信息和用戶信息。

通過對已發(fā)生的風險交易，分析上述信息即可抽象出風控模型，供風控模塊識別風險交易。

3. 風控運營

對于風控模塊識別出的風險交易，根據(jù)危害程度的等級不同，分為「事前攔截」和「事中審核」兩種處理機制。

• 對于明確一定屬于風險交易的交易請求，采用事前攔截的處理機制，支付核心收到后，由風控模塊直接拒絕交易。
• 對于無法確認是否屬于風險交易的，進入風控模塊的待審核交易列表，由風控專員對可疑交易進行人工審核。審核后認為是風險交易的，則拒絕交易；審核后不屬于風險交易的，由支付核心繼續(xù)后續(xù)的交易處理。

五、內(nèi)部控臺

支付核心需要為內(nèi)部的運營、財務、管理層，提供查看交易數(shù)據(jù)的可視化管理網(wǎng)站。

1. 交易操作

• 業(yè)務運營人員，需要對支付系統(tǒng)中已經(jīng)發(fā)生的交易進行檢索，確認某一具體交易的交易狀態(tài)；
• 對于某一筆具體交易，進行退款操作；
• 內(nèi)部控臺要為業(yè)務運營人員提供交易操作入口。

2. 交易數(shù)據(jù)展示

管理層希望了解整個平臺的業(yè)務運作情況，支付系統(tǒng)通過內(nèi)部控臺提供交易總額、訂單轉化率、支付渠道占比等可視化的數(shù)據(jù)圖表，直觀展示交易數(shù)據(jù)的變化情況。

3. 報表下載

將歷史交易數(shù)據(jù)整理為交易報表，供相關人員以下載的方式直接獲取。

4. 權限控制

支付系統(tǒng)的交易數(shù)據(jù)屬于敏感信息。首先，內(nèi)部控臺要限制僅可以通過公司內(nèi)網(wǎng)訪問，并控制可以查看數(shù)據(jù)的人員數(shù)量，具有數(shù)據(jù)查看權限的人員，需要對數(shù)據(jù)安全和資金安全負責；其次，和用戶有關的卡號、姓名等信息，要做脫敏顯示，預防泄露用戶信息。

六、報表

支付系統(tǒng)負責將交易數(shù)據(jù)，定期整理為報表，供有關人員下載使用。

1. 交易報表

按照固定的時間周期，將支付系統(tǒng)中已成功處理的交易流水，生成交易報表。交易報表展示的交易流水，需要按照交易系統(tǒng)支持的交易服務類型，分別生成交易報表。

支付交易、充值交易、出款交易，在交易數(shù)據(jù)信息上各不相同，需要分別出具獨立的交易報表；一般按照日、周、月為時間維度，固定出具交易報表；交易報表中除了提供交易流水明細，還需要提供該時間周期內(nèi)的匯總數(shù)據(jù)，方便使用者快速了解這個時間段內(nèi)的交易情況。

交易報表的結構關系為：

2. 結算報表

支付系統(tǒng)的清算核心對賬戶中資金進行結算時，生成結算報表，供運營或財務進行付款前的確認或者作為付款憑證作為后續(xù)查賬、審核的依據(jù)。結算報表的屬于來自于清算核心提供的結算數(shù)據(jù)，面向內(nèi)部人員使用的結算報表可以根據(jù)本系統(tǒng)的業(yè)務需求，增加其他信息字段，更好的了解結算交易信息。

3. 財務報表

賬務核心分賬戶來管理資金，賬戶記錄了所屬會計科目和賬務記錄，賬務記錄標明了賬戶的資金收支情況。按照公司的財務報表編制期間需求，對同一類會計科目的賬戶，分別統(tǒng)計該報表編制期間內(nèi)收入和支出金額，生成財務報表。

七、交易監(jiān)控

支付系統(tǒng)的穩(wěn)定性十分重要，一旦因為故障出現(xiàn)交易中斷，會對整個平臺的收入造成重大影響。

• 監(jiān)控支付渠道的交易穩(wěn)定性：支付系統(tǒng)對接的外部渠道，監(jiān)控支付渠道的接口響應時間和成功交易占比這兩個重要指標，來監(jiān)控支付渠道的穩(wěn)定性。
• 監(jiān)控支付核心處理交易的穩(wěn)定性：主要監(jiān)控支付核心處理交易的平均時間，保證支付系統(tǒng)的穩(wěn)定信息。

交易監(jiān)控中發(fā)現(xiàn)的異常告警，以短信、郵件等方式及時通知負責人員處理交易異常信息，盡早恢復交易。

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

本文由 @支付學院 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)允許，禁止轉載。

題圖來自 Unsplash，基于CC0協(xié)議。