中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

流程圖：

1. 架構(gòu)的定義：架構(gòu)一定是基于業(yè)務(wù)功能來展開的，主要是制定技術(shù)規(guī)范、框架，指導(dǎo)系統(tǒng)落地，好的架構(gòu)是需要不斷演變和進(jìn)化而來的。
2. 架構(gòu)需要關(guān)注的基礎(chǔ)核心點(diǎn)主要是：安全、穩(wěn)定、可擴(kuò)展。
3. 構(gòu)建架構(gòu)時(shí)需要關(guān)注的點(diǎn)：目標(biāo)客戶是誰、主要場景有哪些、流程是怎樣的、模型、職責(zé)有哪些、邊界在哪里以及設(shè)計(jì)。其中比較難以理解的點(diǎn)是困難及模型這兩塊。
4. 架構(gòu)與業(yè)務(wù)需求的關(guān)系：架構(gòu)的產(chǎn)生來自于業(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ā)起支付請求到渠道側(cè)（個(gè)別渠道如支付寶是不需要此步驟）；
• 第四步渠道返回支付憑證到商戶服務(wù)端；
• 第五步商戶服務(wù)端返回支付憑證到商戶客戶端；
• 第六步，用戶調(diào)用支付寶控件完成支付。

接下來是重點(diǎn)，第七步一般渠道是采用異步通知方法來通知商戶，但是有些企業(yè)是在第六步支付完成之后，在C端會(huì)同步通知支付成功。如果以此結(jié)果來判斷支付是否成功，其實(shí)是不嚴(yán)謹(jǐn)會(huì)出問題的，應(yīng)當(dāng)調(diào)用渠道的支付接口來進(jìn)行核查，然后以渠道返回的結(jié)果為準(zhǔn)。

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

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

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

商戶的要求：

• 清晰的 API 、SDK 文檔；
• 安全；
• 所有應(yīng)用接口統(tǒng)一標(biāo)準(zhǔn)的異步通知；
• 保證出口 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)里我們設(shè)計(jì)了諸如轉(zhuǎn)賬、匯款等功能，在前期設(shè)計(jì)時(shí)會(huì)設(shè)計(jì)好賬務(wù)的生成規(guī)則，例如；一筆支付的請求會(huì)生成多筆賬務(wù)，對其字段進(jìn)行區(qū)分，這樣方便管理和維護(hù)。

支付網(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. 唯一的請求入口；
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)。

支付邏輯

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

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

要點(diǎn)：

一般商戶是不需要做支付路由，大部分都是指定了最終的某個(gè)支付渠道。

但也有些沒有指定了某個(gè)最終的渠道，比如銀行卡的支付可以選擇哪個(gè)第三方支付來完成支付，還有微信線上線下的封裝，這個(gè)時(shí)候就涉及到支付路由規(guī)則配置。

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

支付網(wǎng)關(guān)的目的——省錢。

支付風(fēng)控

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

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

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

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

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

• 第三方購買
• 央行征信
• 芝麻信用
• 合作數(shù)據(jù)

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

事前：

• 入網(wǎng)審核
• 風(fēng)險(xiǎn)評(píng)估
• 單筆限額設(shè)置
• 單日限額設(shè)置
• 頻次設(shè)置

事中：

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

事后：

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

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

• 賬務(wù)生成
• 內(nèi)部對賬
• 原始賬單下載
• 生成標(biāo)準(zhǔn)賬單
• 對賬
• 差錯(cuò)處理

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

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

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

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

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

對賬流程（實(shí)現(xiàn)方式之一）

內(nèi)部對賬：

• 保證賬務(wù)和交易信息配對
• 一條交易信息有多條賬務(wù)信息

渠道賬單下載：

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

對賬：

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

賬單下載：

這里提一句，在做異常處理這部分工作時(shí)，有的研發(fā)朋友寫代碼時(shí)遇到過類似的問題，例如：訂單在周末下單，但賬單周一才能查詢；等到周一時(shí)發(fā)現(xiàn)查詢不到，選擇立即重試 + X 分鐘后重試就結(jié)束了。

這樣是不行的，因?yàn)殂y行有的是 8 點(diǎn)之后可以查詢到，有的是 9 點(diǎn)之后，所以要選擇遞增時(shí)間重試，然后標(biāo)記人工處理。

對賬：

對賬部分：

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

反向操作：

1. 以渠道賬單為準(zhǔn)來逐筆比對；
2. 數(shù)據(jù)一致標(biāo)記成功，數(shù)據(jù)不一致標(biāo)記差錯(cuò)。

差錯(cuò)處理

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

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

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

• Webhook
• 公共推送服務(wù)
• 主動(dòng)查詢
• 補(bǔ)償
• 鏈路監(jiān)控

Webhook

公共推送服務(wù)

主動(dòng)查詢

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

場景：

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)賬也是類似的邏輯，但某些渠道只提供重試的功能，要注意冪等性。
4. ……

補(bǔ)償：

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

鏈路監(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

基本信息

依賴度

五、支付安全

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

防竊聽、防越權(quán)防抵賴、防破壞、防篡改、防重放、防泄漏。

使用范圍：網(wǎng)絡(luò)、系統(tǒng)、應(yīng)用、業(yè)務(wù)等。

數(shù)據(jù)安全要點(diǎn)

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

其他

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

注意點(diǎn)

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

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

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