支付系统-系统架构
本文主要是從支付架構(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é)
- 上一篇: 论文浅尝 | 基于多模态关联数据嵌入的知
- 下一篇: 应用实践 | 南方科技大学研发基于新型冠