整理于網路
從產品分類、模塊功能和業務流程，了解支付產品服務的設計，
支付產品模塊是按照支付場景來為業務方提供支付服務，這個模塊一般位于支付網關之后，支付渠道之前， 它根據支付能力將不同的支付渠道封裝成統一的介面，通過支付網關來對外提供服務，所以，從微服務的角度來說，支付產品本身也是一個代理模式的微服務，它透過支付網關回應業務方請求， 進行一些統一處理后，分發到不同的支付渠道去執行，最后將執行結果做處理后，通過支付網關再回傳給業務方，支付產品在支付系統架構圖中的位置，如下圖所示：
產品分類
在不同的公司由于接入渠道和應用的差異，對支付產品分類略有不同，綜合支付場景和流程，支付產品可以分為如下幾類：
支付產品是由支付系統對支付渠道進行封裝而對業務方提供的支付能力，整體上來說，可以提供如下支付產品：
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開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/245029.html
標籤：Java