完整的支付系統總體架構！

2017-12-04 08:57:44

整理於網絡

從產品分類、模塊功能和業務流程，瞭解支付產品服務的設計。

支付產品模塊是按照支付場景來爲業務方提供支付服務。這個模塊通常位於支付網關以後，支付渠道以前。 它根據支付能力將不一樣的支付渠道封裝成統一的接口，經過支付網關來對外提供服務。因此，從微服務的角度來講，支付產品自己也是一個代理模式的微服務，它透過支付網關響應業務方請求， 進行一些統一處理後，分發到不一樣的支付渠道去執行，最後將執行結果作處理後，經過支付網關再回傳給業務方。支付產品在支付系統架構圖中的位置，以下圖所示：

產品分類

在不一樣的公司因爲接入渠道和應用的差別，對支付產品分類略有不一樣。綜合支付場景和流程，支付產品能夠分爲以下幾類：

支付產品是由支付系統對支付渠道進行封裝而對業務方提供的支付能力。總體上來講，能夠提供以下支付產品：

1. 快捷支付

用戶在完成綁卡以後，在支付的時候，不須要再輸入卡或者身份信息，僅須要輸入支付密碼就能夠完成支付。對於小額度的支付，甚至能夠開通小額免密，直接完成支付。 這種支付方式不會打斷用戶的體驗，是目前主要的在線支付方式。通常快捷支付產品是經過封裝銀行或者第三方支付平臺提供的快捷支付接口或者代付接口來實現的。

2. 網銀支付

用戶在支付的時候，須要跳轉到銀行網銀頁面來完成支付。在網銀頁面，須要輸入用戶的卡號和身份信息。這種支付方式會中斷用戶當前的體驗，通常僅用於 PC Web 上的支付。 網銀支付是封裝銀行提供的網銀支付來實現。

3. 協議支付

協議支付也稱代收或者代扣，代收指渠道受權商戶能夠從用戶的銀行帳戶中扣款，通常用於按期扣款，不用於平常消費。好比水電煤氣、有線電視費。協議支付是經過封裝銀行、第三方支付提供的代扣或者快捷接口來實現。

4. 平臺支付

使用微信、支付寶等第三方支付平臺來完成支付。使用時，通常須要用戶預先安裝支付平臺系統（手機上），註冊並登陸到第三方支付平臺，而且已經在該平臺上完成綁卡等操做。 因爲微信、支付寶已經被大量使用，用戶也產生對這些平臺的信任，平臺支付每每是電商公司的主要支付方式。

5. 外卡支付

對於由海外支付的需求，還須要提供外卡支付支持。 國內很多支付渠道都能支持外卡支付，如支付寶全球購等。直接對接 Paypal，也是目前用的最多的外卡支付渠道。

6. 話費支付

對於有包月小額類型的支付，手機話費也是一個不錯的選擇。目前也有一些平臺能夠支持話費支付，好比虹軟、聯動優點等。

7. 虛幣支付

很多公司會有本身的虛擬幣，好比京豆、Q幣等。這些虛幣也能夠做爲一種支付方式。

8. 帳戶支付

也稱爲餘額支付、零錢支付等。 指爲用戶創建本地帳戶， 支持充值，以後可使用這個帳戶來完成支付。

9. 信用支付

如京東的白條，螞蟻花唄等，指使用信用帳戶進行透支，相似信用卡支付。

10. 代付

和代扣相反，代付是平臺將錢打給用戶。

模塊功能

支付產品根據其支付能力，對外提供不一樣的功能。總體上來講，通常支付產品須要提供以下接口：

1. 簽約和解約

在快捷支付、代扣等產品中，用戶在使用前，須要先完成簽約。簽約能夠在渠道側進行，通常第三方支付採用這種方式，當電商須要接入時，讓第三方給受權。 銀行和銀聯的簽約通常是在電商側進行， 電商側負責收集用戶的信息，調用銀行和銀聯的接口進行簽約。簽約後，後續的支付行爲就使用簽約號來進行，無需再輸入我的信息。 和簽約相對應，解約則是取消簽約關係。

2. 支付

支付是少不了的操做。 不一樣產品中支付行爲不同。快捷支付是在電商服務器上發起，請求渠道進行支付；網銀支付則是跳轉到銀行支付網關上進行; 而帳戶支付、虛幣支付，則是在本地進行的。

3. 撤銷和退款

有些渠道區分撤銷和退款，好比銀聯、農行等，撤銷指取消當天在渠道側未結算的交易； 而退款僅針對已經結算的交易。有些渠道則不做區分。

4. 查詢簽約狀態

對於須要簽約的交易，能夠經過這個接口來查詢簽約狀態。

5. 查詢訂單狀態

經過這個接口來查詢支付清單狀態以及退款的訂單狀態。

6. 預受權

預受權交易用於受理方向持卡人的髮卡方確認交易許可。受理方將預估的消費金額做爲預受權金額，發送給持卡人的髮卡方。

7. 預受權撤銷

對已成功的預受權交易，在結算前使用預受權撤銷交易，通知髮卡方取消付款承諾。預受權撤銷交易必須是對原始預受權交易或追加預受權交易最終承兌金額的全額撤銷。

8. 預受權完成交易

對已批准的預受權交易，用預受權完成作支付結算。

9. 預受權完成撤銷

預受權完成撤銷交易必須是對原始預受權完成交易的全額撤銷。預受權完成撤銷後的預受權仍然有效。

10. 對帳

經過 FTP 或者 HTTP 方式提供對帳文件供商戶側對帳。

11. 餘額查詢

查詢商戶的交易帳戶的餘額，避免因爲餘額不足致使交易失敗。 注意，不是客戶的餘額。 固然，不是全部的銀行或者第三方支付都提供這個接口。

業務流程

上述操做，除了對帳、查單外，每一個操做實現的主流程，通常會包括「參數校驗，支付路由，生成訂單，風險評估，調用渠道服務，更新訂單和發送消息」這 7 步，對於一些比較複雜的服務，還會涉及到異步通知處理的步驟。

1. 執行參數校驗

全部的支付操做，都須要對輸入執行參數校驗，避免接口受到攻擊。驗證輸入參數中各字段的有效性驗證，好比用戶ID、商戶ID、價格、返回地址等參數。驗證帳戶狀態，交易主體、交易對手等帳戶的狀態是處於可交易的狀態。驗證訂單，若是涉及到預單，還須要驗證訂單號的有效性，訂單狀態是未支付。爲了不用戶緩存某個 URL 地址，還須要校驗下單時間和支付時間是否超過預約的間隔。驗證簽名，簽名也是爲了防止支付接口被僞造。 通常簽名是使用分發給商戶的 key 來對輸入參數拼接成的字符串作 MD5 Hash 或者 RSA 加密，而後做爲一個參數隨其餘參數一塊兒提交到服務器端，簽名驗證也能夠在網關中統一完成。

2. 根據支付路由尋找合適的支付服務

根據用戶選擇的支付方式肯定用來完成該操做的合適的支付渠道。用戶指定的支付方式不必定是最終的執行支付的渠道。好比用戶選擇經過工行信用卡來執行支付，可是咱們沒有實現和工行的對接，而是能夠經過第三方支付，好比支付寶、微信支付、易寶支付，或者銀聯來完成。那如何選擇合適的支付渠道，就經過支付路由來實現。支付路由會綜合考慮收費、渠道的可用性等因素來選擇最優方案。

3. 評估交易風險

檢查本次交易是否有風險。風控接口返回三種結果：阻斷交易、加強驗證和放行交易。阻斷交易，說明該交易是高風險的，須要終止，不執行第 5 個步驟；加強驗證，說明該交易有必定的風險，須要確認下是否是用戶本人在操做。這能夠經過發送短信驗證碼或者其餘能夠驗證用戶身份的方式來作校驗，驗證經過後，能夠繼續執行該交易。放行交易，即本次交易是安全的，能夠繼續往下走。

4. 生成交易訂單

將訂單信息持久化到數據庫中。當訪問壓力大的時候，數據庫寫入會成爲一個瓶頸。

5. 調用支付渠道提供的服務

全部的支付服務都須要第三方通道來完成執行。通常銀行渠道的調用比較簡單，能夠直接返回結果。而一些第三方支付，支付寶，微信支付等，則會經過異步接口來告知支付結果。

6. 更新訂單

對於同步返回的結果，須要在主線程中更新訂單的狀態，標記是支付成功仍是失敗。對於異步返回的渠道，須要在異步程序中處理。

7. 發送消息

經過消息來通知相關係統關於訂單的變動。風控，信用 BI 等，都須要依賴這數據作準實時計算。

8. 異步通知

如上述流程，其中涉及到調用遠程接口，其延遲不可控。若是調用方一直阻塞等待，很容易超時。引入異步通知機制，可讓調用方在主線程中儘快返回，經過異步線程來獲得支付結果。對於經過異步來獲取支付結果的渠道接口，也須要對應的在異步通知中將結果返回給調用方。 異步通知須要調用方提供一個回調地址，通常以 http 或者 https 的方式。這就有技術風險，若是調用失敗，還須要重試。而重試不能過於頻繁，須要逐步拉大每一次重試的時間間隔。在異步處理程序中，訂單根據處理結果變動狀態後，也要發消息通知相關係統。

支付系統架構總體設計

每一個公司根據其業務和公司發展的不一樣階段，所設計的支付系統也會有所不一樣。咱們先看看互聯網公司的一些典型的支付系統架構。

1. 支付寶

這個總體架構上並無不同凡響之處。在模塊劃分上，這個圖顯示的是最頂層的劃分，也沒法告知更多細節。 但支付寶架構文檔有兩個搞支付平臺設計的人必須仔細揣摩的要點。 一個是帳務處理，在記帳方面，涉及到內外兩個子系統，外部子系統是單邊帳，知足線上性能需求；內部子系統走複式記帳，知足財務需求，如記帳、對帳和平帳。

另外一個是柔性事務處理，利用消息機制來實現跨系統的事務處理，避免數據庫鎖致使的性能問題。

2. 京東金融

京東金融是在網銀在線的基礎上發展起來的。 網銀在線的原班技術人員有很多來自易寶公司，在京東收購以後，又引入了支付寶的人才，於是從架構上受這兩個公司的影響很大。

3. 去哪兒

這些架構文檔所有來自互聯網公開資料， 對於架構是否真實反映實際系統狀況，須要你們自行判斷。 我們僅是以這些文檔爲基礎，分析支付系統應有的軟件架構。

參考架構

通常來講，支付系統典型架構會包含以下模塊：

支付系統從架構上來講，分爲三層;

• 支撐層： 用來支持核心系統的基礎軟件包和基礎設施， 包括運維監控系統、日誌分析系統等。

• 核心層： 支付系統的核心模塊，內部又分爲兩個部分： 支付核心模塊以及支付服務模塊。

• 產品層： 經過核心層提供的服務組合起來，對最終用戶、商戶、運營管理人員提供的系統。

1. 支撐系統

支撐系統是一個公司提供給支付系統運行的基礎設施。 主要包括以下子系統：

• 運維監控： 支付系統在運行過程當中不可避免的會受到各類內部和外部的干擾，光纖被挖斷、黑客攻擊、數據庫被誤刪、上線系統中有 bug 等等，運維人員必須在第一時間內對這些意外事件做出響應，又不可以一天 24 小時盯着。這就須要一個運維監控系統來協助完成。

• 日誌分析： 日誌是支付系通通計分析、運維監控的重要依據。公司須要提供基礎設施來支持日誌統一收集和分析。

• 短信平臺： 短信在支付系統中有重要做用，如身份驗證、安全登陸、找回密碼、以及報警監控，都須要短信的支持。

• 安全機制： 安全是支付的生命線。 SSL、證書系統、防刷接口等，都是支付的必要設施。

• 統計報表： 支付數據的可視化展現，是公司進行決策的基礎。

遠程鏈接管理、分佈式計算、消息機制、全文檢索、文件傳輸、數據存儲、機器學習等，都是構建大型系統所必須的基礎軟件，這裏再也不一一詳細介紹。

2. 支付核心系統

支付核心系統指用戶執行支付的核心流程，包括：

• 用戶從支付應用啓動支付流程；

• 支付應用根據應用和用戶選擇的支付工具來調用對應的支付產品來執行支付；

• 支付路由根據支付工具、渠道費率、接口穩定性等因素選擇合適的支付渠道來落地支付；

• 支付渠道調用銀行、第三方支付等渠道提供的接口來執行支付操做，最終落地資金轉移。

3. 支付服務系統

支持支付核心系統所提供的功能，服務系統又分爲基礎服務系統、資金系統、風控和信用系統。

基礎服務系統提供支撐線上支付系統運行的基礎業務功能：

• 客戶信息管理：包括對用戶、商戶的實名身份、基本信息、協議的管理；

• 卡券管理： 對優惠券、代金券、折扣券的製做、發放、使用流程的管理；

• 支付通道管理: 通道接口、配置參數、費用、限額以及 QOS 的管理；

• 帳戶和帳務系統： 管理帳戶信息以及交易流水、記帳憑證等。這裏的帳務通常指對接線上系統的帳務，採用單邊帳的記帳方式，內部帳記錄在會計覈算系統中。

• 訂單系統： 通常訂單系統能夠獨立於業務系統來實現的，這裏的訂單，主要指支付訂單。

資金系統指圍繞財務會計而產生的後臺資金覈實、調度和管理的系統，包括：

• 會計覈算： 提供會計科目、內部帳務、試算平衡、日切、流水登記、覈算和歸檔的功能。

• 資金管理： 管理公司在各個支付渠道的頭寸，在餘額不足時進行打款。 對第三方支付公司，還須要對備付金進行管理。

• 清算分潤： 對於有分潤需求的業務，還須要提供清分清算、對帳處理和計費分潤功能。

風控系統是支付系統必備的基礎功能，全部的支付行爲必須作風險評估並採起對應的措施；信用系統是在風控基礎上發展的高級功能，京東的白條，螞蟻花唄等，都是成功的案例。

4. 支付應用

支撐系統、核心系統和服務系統，在每一個互聯網公司的架構上都是大同小異的，都是必不可少的模塊。而支付應用是每一個公司根據本身的業務來構建的，各不相同。

整體來講，能夠按照使用對象分爲針對最終用戶的應用、針對商戶的應用、針對運營人員的運營管理、BI 和風控後臺。

近期熱文推薦：

1.Java 15 正式發佈， 14 個新特性，刷新你的認知！！

2.終於靠開源項目弄到 IntelliJ IDEA 激活碼了，真香！

3.我用 Java 8 寫了一段邏輯，同事直呼看不懂，你試試看。。

4.吊打 Tomcat ，Undertow 性能很炸！！

5.《Java開發手冊（嵩山版）》最新發布，速速下載！

以爲不錯，別忘了隨手點贊+轉發哦！