基礎(chǔ)向:從 0 開始學(xué)習(xí)支付系統(tǒng)架構(gòu)

16 評(píng)論 53824 瀏覽 369 收藏 15 分鐘
🔗 产品经理专业技能指的是:需求分析、数据分析、竞品分析、商业分析、行业分析、产品设计、版本管理、用户调研等。

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

流程圖:

  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ù)需求的問(wèn)題。整體是一個(gè)正向循環(huán)的關(guān)系。

一、支付架構(gòu)

二、支付流程分析

  • 第一步,用戶選擇支付渠道,進(jìn)入商戶客戶端;
  • 第二步,商戶客戶端發(fā)送支付要素,到商戶服務(wù)端;
  • 第三步,商戶服務(wù)端發(fā)起支付請(qǐng)求到渠道側(cè)(個(gè)別渠道如支付寶是不需要此步驟);
  • 第四步渠道返回支付憑證到商戶服務(wù)端;
  • 第五步商戶服務(wù)端返回支付憑證到商戶客戶端;
  • 第六步,用戶調(diào)用支付寶控件完成支付。

接下來(lái)是重點(diǎn),第七步一般渠道是采用異步通知方法來(lái)通知商戶,但是有些企業(yè)是在第六步支付完成之后,在C端會(huì)同步通知支付成功。如果以此結(jié)果來(lái)判斷支付是否成功,其實(shí)是不嚴(yán)謹(jǐn)會(huì)出問(wèn)題的,應(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í)并沒(méi)有必要的。

若直接對(duì)接渠道可能會(huì)遇到的問(wèn)題:

  • 接口文檔升級(jí)、變更能及時(shí)得到通知;
  • 有些業(yè)務(wù)沒(méi)有異步通知;
  • 同一業(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)里我們?cè)O(shè)計(jì)了諸如轉(zhuǎn)賬、匯款等功能,在前期設(shè)計(jì)時(shí)會(huì)設(shè)計(jì)好賬務(wù)的生成規(guī)則,例如;一筆支付的請(qǐng)求會(huì)生成多筆賬務(wù),對(duì)其字段進(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. 唯一的請(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)。

支付邏輯

主要是根據(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è)支付渠道。

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

  • 費(fèi)率:單筆費(fèi)率、總額費(fèi)率、階梯費(fèi)率;
  • 營(yíng)銷活動(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ù)來(lái)源

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

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

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

  • 第三方購(gòu)買
  • 央行征信
  • 芝麻信用
  • 合作數(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)部對(duì)賬
  • 原始賬單下載
  • 生成標(biāo)準(zhǔn)賬單
  • 對(duì)賬
  • 差錯(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)賬等等。

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

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

內(nèi)部對(duì)賬:

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

渠道賬單下載:

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

對(duì)賬:

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

賬單下載:

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

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

對(duì)賬:

對(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ò)。

差錯(cuò)處理

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

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

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

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

Webhook

公共推送服務(wù)

主動(dòng)查詢

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

場(chǎng)景:

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

補(bǔ)償:

  • 協(xié)調(diào)保證各模塊間數(shù)據(jù)的一致性;
  • 一般會(huì)跟重試、回滾、兜底來(lái)協(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ǔ)(防泄漏)
  • 密鑰管理(通過(guò)認(rèn)證接口獲取,只允許加載到內(nèi)存,不允許直接寫入配置文件)
  • 權(quán)限控制(防越權(quán)-非法訪問(wèn))
  • 數(shù)據(jù)的完整性(放篡改- 數(shù)據(jù)被惡意修改、非法篡改)

其他

  • 內(nèi)部接口認(rèn)證。
  • 避免內(nèi)部代碼未經(jīng)審核發(fā)布到托管平臺(tái)?。。?/li>
  • 數(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)載

題圖來(lái)自Unsplash,基于CC0協(xié)議

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 很專業(yè),厲害厲害!學(xué)習(xí)ing

    來(lái)自浙江 回復(fù)
  2. 這是高手!

    來(lái)自北京 回復(fù)
  3. 看完頂禮膜拜,邏輯清晰,講述利索不拖泥帶水,求干貨拆分詳細(xì)講解,設(shè)計(jì)技術(shù)類的流程希望有講解部分。

    來(lái)自廣東 回復(fù)
  4. 看著就賊特么專業(yè)

    來(lái)自浙江 回復(fù)
  5. 寫的非常好 ,一對(duì)比 自己寫的都是坑啊

    來(lái)自河北 回復(fù)
    1. 多謝認(rèn)可 ??

      來(lái)自上海 回復(fù)
  6. 對(duì)于架構(gòu)的整體情況有了了解,受教了。如果能重點(diǎn)講一下記賬對(duì)賬及結(jié)算就完美了

    回復(fù)
    1. 下一篇內(nèi)容更新財(cái)務(wù)對(duì)賬,也是基礎(chǔ)向的,敬請(qǐng)關(guān)注。 ??

      來(lái)自上海 回復(fù)
  7. 強(qiáng)烈關(guān)注

    來(lái)自北京 回復(fù)
    1. ?? 感謝關(guān)注,后續(xù)請(qǐng)多支持!

      來(lái)自上海 回復(fù)
  8. 大神,我關(guān)注你了,你能不能寫一些適合小白看的,這個(gè)看不懂??

    回復(fù)
    1. 感謝關(guān)注,未來(lái)會(huì)多寫一些基礎(chǔ)向的內(nèi)容。 ??

      來(lái)自上海 回復(fù)
  9. 這個(gè)是干貨

    來(lái)自浙江 回復(fù)
    1. 感謝認(rèn)可 ??

      來(lái)自上海 回復(fù)
  10. 只要敢發(fā)這種文章 我就敢好好品讀 必須贊賞!~

    來(lái)自浙江 回復(fù)
    1. ?? 多謝贊賞,繼續(xù)努力

      來(lái)自上海 回復(fù)
专题
14312人已学习13篇文章
交互设计是用户与产品以及他们使用的服务之间建立的有意义的关系。
专题
14876人已学习13篇文章
本专题的文章分享了搭建营销中心指南。
专题
14808人已学习13篇文章
用户画像,是根据用户的基本属性、用户偏好、生活习惯、用户行为等信息而抽象出来的标签化用户模型。本专题的文章分享了如何构建用户画像体系。
专题
14536人已学习12篇文章
数据库对于产品经理来说是一个既熟悉又陌生的概念,虽然产品设计中的数据基本都要与数据库交互,但平时的工作中也很少接触到数据库的具体操作和细节。本专题的文章分享了数据库的基础知识。
专题
44912人已学习22篇文章
可用又易用,产品逻辑和情感化体验两手抓,用户才会爱上你的产品。
专题
12529人已学习12篇文章
运营分很多类,流量运营、用户运营、内容运营…每一个环节都有特别关注的数据和指标。本专题的文章分享了互联网运营,应该分析哪些数据和指标。