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

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

一、支付架構(gòu)

二、支付流程分析

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

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

若直接對(duì)接渠道可能會(huì)遇到的問題：

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

商戶的要求：

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

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

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

三、支付核心邏輯

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

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

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

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

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

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

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

3.2、支付邏輯

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

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

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

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

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

3.3、支付風(fēng)控

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

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

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

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

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

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

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

事前：

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

事中：

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

事后：

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

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

（1）、賬務(wù)生成
（2）、內(nèi)部對(duì)賬
（3）、原始賬單下載
（4）、生成標(biāo)準(zhǔn)賬單
（5）、對(duì)賬
（6）、差錯(cuò)處理

? ? ? ?賬務(wù)生成后首先進(jìn)行內(nèi)部對(duì)賬，后進(jìn)行原始賬單下載，再生成標(biāo)準(zhǔn)賬單，進(jìn)行對(duì)賬之后進(jìn)行差錯(cuò)處理。

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

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

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

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

對(duì)賬流程：

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

渠道賬單下載：

（1）、下載；
（2）、賬單標(biāo)準(zhǔn)化（對(duì)賬字段統(tǒng)一）；
（3）、落地標(biāo)準(zhǔn)化賬單。

對(duì)賬：

（1）、賬務(wù)和標(biāo)準(zhǔn)賬單對(duì)賬雙向?qū)~；
（2）、差錯(cuò)處理。

? ? ?

?對(duì)賬部分：
（1）、獲取核對(duì)文件；
（2）、以賬務(wù)系統(tǒng)為準(zhǔn)來(lái)逐筆比對(duì)（以某個(gè)字段為準(zhǔn)進(jìn)行比對(duì)）；
（3）、數(shù)據(jù)一致標(biāo)記成功，數(shù)據(jù)不一致標(biāo)記差錯(cuò)。

反向操作：
（1）、以渠道賬單為準(zhǔn)來(lái)逐筆比對(duì)；
（2）、數(shù)據(jù)一致標(biāo)記成功，數(shù)據(jù)不一致標(biāo)記差錯(cuò)。

賬單下載：

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

3.5、差錯(cuò)處理

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

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

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

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

4.1、Webhook

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

異步延時(shí)調(diào)用

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

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

4.3、鏈路監(jiān)控

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

關(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ù)安全要點(diǎn)

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

5.3、其他

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

5.4、注意點(diǎn)

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

?

?

總結(jié)

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

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