本文主要是從支付架構(gòu)、支付流程分析、支付核心邏輯、支付基礎(chǔ)服務(wù)、支付安全五個方面來詳細講述支付系統(tǒng)架構(gòu)

（1）、架構(gòu)的定義：架構(gòu)一定是基于業(yè)務(wù)功能來展開的，主要是制定技術(shù)規(guī)范、框架，指導(dǎo)系統(tǒng)落地；好的架構(gòu)是需要不斷演變和進化而來的。
（2）、架構(gòu)需要關(guān)注的基礎(chǔ)核心點主要是：安全、穩(wěn)定、可擴展。
（3）、構(gòu)建架構(gòu)時需要關(guān)注的點：目標客戶是誰、主要場景有哪些、流程是怎樣的、模型、職責(zé)有哪些、邊界在哪里以及設(shè)計。其中比較難以理解的點是困難及模型這兩塊。
（4）、架構(gòu)與業(yè)務(wù)需求的關(guān)系：架構(gòu)的產(chǎn)生來自于業(yè)務(wù)需求，業(yè)務(wù)需求進一步抽象形成架構(gòu)，架構(gòu)指導(dǎo)后續(xù)研發(fā)，研發(fā)最終成果解決業(yè)務(wù)需求的問題。整體是一個正向循環(huán)的關(guān)系。

一、支付架構(gòu)

二、支付流程分析

第一步：用戶選擇支付渠道，進入商戶客戶端；
第二步：商戶客戶端發(fā)送支付要素，到商戶服務(wù)端；
第三步：商戶服務(wù)端發(fā)起支付請求到渠道（個別渠道如支付寶是不需要此步驟）；
第四步：渠道返回支付憑證到商戶服務(wù)端；
第五步：商戶服務(wù)端返回支付憑證到商戶客戶端；
第六步：用戶調(diào)用支付寶控件完成支付。
第七步：一般渠道是采用異步通知方法來通知商戶，但是有些企業(yè)是在第六步支付完成之后，在C端會同步通知支付成功。如果以此結(jié)果來判斷支付是否成功，其實是不嚴謹會出問題的，應(yīng)當(dāng)調(diào)用渠道的支付接口來進行核查，然后以渠道返回的結(jié)果為準。

? ? ? ?在日常工作中，許多企業(yè)在選擇第四方服務(wù)商或者渠道的時候，會著重關(guān)注「并發(fā)」這個點，認為并發(fā)量需要達到上萬級才可以滿足日常需求，但實際上這個量級非常大，其實并沒有必要的。

若直接對接渠道可能會遇到的問題：

（1）、接口文檔升級、變更能及時得到通知；
（2）、有些業(yè)務(wù)沒有異步通知；
（3）、同一業(yè)務(wù)在不同渠道表現(xiàn)不一樣；
（4）、各種渠道的各自異常。

商戶的要求：

（1）、清晰的 API 、SDK 文檔；
（2）、安全；
（3）、所有應(yīng)用接口統(tǒng)一標準的異步通知；
（4）、保證出口 IP 穩(wěn)定（安全）。

在系統(tǒng)架構(gòu)設(shè)計時需要注意的一些要點：

（1）、提供規(guī)范的 API、SDK；
（2）、安全（通訊安全、數(shù)據(jù)安全）；
（3）、穩(wěn)定；
（4）、異步通知統(tǒng)一；
（5）、各渠道的異常；
（6）、及時了解渠道接口調(diào)整。

三、支付核心邏輯

? ? ? ?這里講一下，支付成功之后，我們會把訂單信息同步到財務(wù)系統(tǒng)，在賬務(wù)系統(tǒng)里我們設(shè)計了諸如轉(zhuǎn)賬、匯款等功能，在前期設(shè)計時會設(shè)計好賬務(wù)的生成規(guī)則，例如；一筆支付的請求會生成多筆賬務(wù)，對其字段進行區(qū)分，這樣方便管理和維護。

3.1、支付網(wǎng)關(guān)

? ? ? ?此處特指API網(wǎng)關(guān)，支付網(wǎng)關(guān)的功能：

? ? ? ?限流最好不要放到業(yè)務(wù)流程中做，會影響用戶的體驗。

支付網(wǎng)關(guān)的內(nèi)容：

（1）、唯一的請求入口；
（2）、統(tǒng)一的身份認證、簽名、加解密、流控；
（3）、API 調(diào)用計費；
（4）、API 的監(jiān)控、報警分析；
（5）、API 發(fā)布管理；
（6）、熔斷；
（7）、API 聚合；
（8）、協(xié)議轉(zhuǎn)換；

? ? ? ?上述內(nèi)容除了必要意外，其他不放在業(yè)務(wù)層做，也是為了更好的用戶體驗。

3.2、支付邏輯

? ? ? ?主要是根據(jù)請求的參數(shù)進行靜態(tài)檢驗和業(yè)務(wù)邏輯校驗，避免系統(tǒng)異常。

（1）、適配渠道的參數(shù)校驗：長度、類型、格式；
（2）、訂單的支付狀態(tài)：是否支付；
（3）、訂單的有效期等等。

要點：
? ? ? ?一般商戶是不需要做支付路由，大部分都是指定了最終的某個支付渠道。
? ? ? ?但也有些沒有指定了某個最終的渠道，比如銀行卡的支付可以選擇哪個第三方支付來完成支付，還有微信線上線下的封裝，這個時候就涉及到支付路由規(guī)則配置。

支付路由規(guī)則配置：

（1）、費率：單筆費率、總額費率、階梯費率；
（2）、營銷活動：固定時間單筆優(yōu)惠、單筆滿減、單筆這款、直接補貼；
（3）、額度限制：單筆額度、時間范圍內(nèi)總額度；
（4）、服務(wù)指標：失敗率、平均響應(yīng)時間、異常率、TPS；
（5）、特殊配置：特殊要求（比如某渠道能快速結(jié)算）。

3.3、支付風(fēng)控

? ? ? ?要點：梳理清楚業(yè)務(wù)風(fēng)險，分析風(fēng)險原因，制定風(fēng)險防范規(guī)則。

（1）數(shù)據(jù)來源

內(nèi)部數(shù)據(jù)：

（1）、用（商）戶信息
（2）、交易數(shù)據(jù)
（3）、賬戶數(shù)據(jù)
（4）、黑名單
（5）、設(shè)備、位置信息
（6）、日志數(shù)據(jù)

外部數(shù)據(jù)：

（1）、第三方購買
（2）、央行征信
（3）、芝麻信用
（4）、合作數(shù)據(jù)

（2）風(fēng)控流程

事前：

（1）、入網(wǎng)審核
（2）、風(fēng)險評估
（3）、單筆限額設(shè)置
（4）、單日限額設(shè)置
（5）、頻次設(shè)置

事中：

（1）、實時分析
（2）、多維度判斷
（3）、拒絕
（4）、攔截 – 進一步驗證– 人工介入
（5）、延遲操作（例如用戶大額提現(xiàn)，需要時間段進行復(fù)核）

事后：

（1）、數(shù)據(jù)分析
（2）、巡查、警告
（3）、降低評級
（4）、升級防范措施
（5）、邏輯完善
（6）、反饋至事前、事中規(guī)則中

3.4、賬務(wù)系統(tǒng)

（1）、賬務(wù)生成
（2）、內(nèi)部對賬
（3）、原始賬單下載
（4）、生成標準賬單
（5）、對賬
（6）、差錯處理

? ? ? ?賬務(wù)生成后首先進行內(nèi)部對賬，后進行原始賬單下載，再生成標準賬單，進行對賬之后進行差錯處理。

內(nèi)部流程如圖：

訂閱交易信息；
根據(jù)交易事件查詢生成賬務(wù)的規(guī)則。

交易事件：支付、退款、轉(zhuǎn)賬等等。

（1）、根據(jù)規(guī)則生成賬務(wù)明細；
（2）、將賬務(wù)明細落地。

對賬流程：

內(nèi)部對賬：
（1）、保證賬務(wù)和交易信息配對
（2）、一條交易信息有多條賬務(wù)信息

渠道賬單下載：

（1）、下載；
（2）、賬單標準化（對賬字段統(tǒng)一）；
（3）、落地標準化賬單。

對賬：

（1）、賬務(wù)和標準賬單對賬雙向?qū)~；
（2）、差錯處理。

? ? ?

?對賬部分：
（1）、獲取核對文件；
（2）、以賬務(wù)系統(tǒng)為準來逐筆比對（以某個字段為準進行比對）；
（3）、數(shù)據(jù)一致標記成功，數(shù)據(jù)不一致標記差錯。

反向操作：
（1）、以渠道賬單為準來逐筆比對；
（2）、數(shù)據(jù)一致標記成功，數(shù)據(jù)不一致標記差錯。

賬單下載：

? ? ? ?這里提一句，在做異常處理這部分工作時，有的研發(fā)朋友寫代碼時遇到過類似的問題，例如：訂單在周末下單，但賬單周一才能查詢；等到周一時發(fā)現(xiàn)查詢不到，選擇立即重試 + X 分鐘后重試就結(jié)束了。
? ? ? ?這樣是不行的，因為銀行有的是 8 點之后可以查詢到，有的是 9 點之后，所以要選擇遞增時間重試，然后標記人工處理。

3.5、差錯處理

（1）、本地丟失：渠道賬單的數(shù)據(jù)未在賬務(wù)中查找到。
（2）、渠道丟失：賬務(wù)中的數(shù)據(jù)未在渠道賬單中查找到。
（3）、數(shù)據(jù)差錯：賬務(wù)與渠道某些對賬字段未能對上。

? ? ? ?此處需要注意的是，針對差錯都需要向渠道查詢每筆訂單信息再次確認，同時，有些渠道的交易成功時間本來就是有錯誤的。一般來說是件不會差錯很大，一般出現(xiàn)在跨日交易中，例如：當(dāng)天交易無賬單，先標記為差錯，第二天再改正。

四、支付基礎(chǔ)服務(wù)

（1）、Webhook
（2）、公共推送服務(wù)
（3）、主動查詢
（4）、補償
（5）、鏈路監(jiān)控

4.1、Webhook

4.2、公共推送服務(wù)

異步延時調(diào)用

場景：
（1）、訂單創(chuàng)建成功的時候會向服務(wù)推送主動查詢信息，如果訂單支付成功會通知服務(wù)取消后續(xù)的主動查詢，否則在過期時間點向渠道主動查詢訂單是否支付目的是避免渠道異步通知服務(wù)的異常。
（2）、退款創(chuàng)建成功的時候會向服務(wù)推送主動查詢信息，該服務(wù)會在一定的時間范圍內(nèi)多次查詢渠道直到有明確的結(jié)果返回（有些渠道沒有異步通知）。
（3）、轉(zhuǎn)賬也是類似的邏輯，但某些渠道只提供重試的功能，要注意冪等性。

補償：
（1）、協(xié)調(diào)保證各模塊間數(shù)據(jù)的一致性；
（2）、一般會跟重試、回滾、兜底來協(xié)調(diào)使用；
（3）、使用條件：系統(tǒng)異常、業(yè)務(wù)異常；
（4）、補償失敗報警人工干預(yù)。

4.3、鏈路監(jiān)控

展示信息：應(yīng)用、URL、調(diào)用方、調(diào)用時間、調(diào)用次數(shù)、調(diào)用失敗次數(shù)、本地平均耗時、總平均耗時、調(diào)用失敗平均耗時 、錯誤率、依賴度。

關(guān)注：Cache、SQL、HTTP、TCP

基本信息：

依賴度：

五、支付安全

5.1、數(shù)據(jù)安全

（1）、防竊聽、防越權(quán)防抵賴、防破壞、防篡改、防重放、防泄漏。
（2）、使用范圍：網(wǎng)絡(luò)、系統(tǒng)、應(yīng)用、業(yè)務(wù)等。

5.2、數(shù)據(jù)安全要點

（1）、加密通訊（防竊聽）
（2）、雙向簽名（防抵賴、防篡改）
（3）、敏感數(shù)據(jù)加密存儲（防泄漏）
（4）、密鑰管理（通過認證接口獲取，只允許加載到內(nèi)存，不允許直接寫入配置文件）
（5）、權(quán)限控制（防越權(quán)-非法訪問）
（6）、數(shù)據(jù)的完整性（放篡改- 數(shù)據(jù)被惡意修改、非法篡改）

5.3、其他

（1）、內(nèi)部接口認證。
（2）、避免內(nèi)部代碼未經(jīng)審核發(fā)布到托管平臺！！！
（3）、數(shù)據(jù)異常分析。
（4）、安全機構(gòu)合作。

5.4、注意點

（1）、使用 HTTPS 加密傳輸；
（2）、傳輸?shù)臄?shù)據(jù)使用簽名；
（3）、提交的數(shù)據(jù)是符合規(guī)則并且是不存在或者是未支付的；
（4）、支付成功以服務(wù)端異步通知為準。

?

?

總結(jié)

以上是生活随笔為你收集整理的支付系统-系统架构的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。