支付的典型架構
每個公司根據其業務和公司發展的不同階段，所設計的支付系統也會有所不同。我們先看看互聯網公司的一些典型的支付系統架構。
支付寶
先看看業內最強的支付寶系統，支付寶的支付系統整體架構設計
這個整體架構上並沒有與衆不同之處。在模塊劃分上，這個圖顯示的是最頂層的劃分，也無法告知更多細節。
但支付寶架構強點在兩個方面，一個是賬務處理，分爲內外兩個子系統，外部子系統是單邊賬，內部子系統走複式記賬。 不少支付平臺是從這裏得到啓發來搞定的對賬系統。
另一個亮點是柔性事務處理，利用消息機制來實現跨系統的事務處理，避免數據庫鎖導致的性能問題。
京東金融
來自京東支付平臺總體架構設計 。
京東金融是在網銀在線的基礎上發展起來的。
網銀在線的原班技術人員有不少來自易寶公司，在京東收購之後，又引入了支付寶的人才。因而從架構上受這兩個公司的影響很大。
去哪兒
來自去哪兒公司分享的支付產品架構
美團
來自美團的支付平臺規劃架構 。這是2015年的文檔。 2016年美團纔拿到支付牌照。 從這個架構，大家也能知道爲什麼美團必須拿到支付牌照。
這些架構文檔全部來自互聯網公開資料。 對於架構是否真實反映實際系統情況，需要大家自行判斷。 我們以這些文檔爲基礎，分析支付系統的應有的軟件架構。
參考架構
一般來說，支付系統典型架構會包含如下模塊：
支付系統從架構上來說，分爲三層;
- 支撐層： 用來支持核心系統的基礎軟件包和基礎設施， 包括運維監控系統、日誌分析系統等。
- 核心層： 支付系統的核心模塊，內部又分爲兩個部分： 支付核心模塊以及支付服務模塊。
- 產品層： 通過核心層提供的服務組合起來，對最終用戶、商戶、運營管理人員提供的系統。
支撐系統
支撐系統是一個公司提供給支付系統運行的基礎設施。 主要包括如下子系統：
- 運維監控： 支付系統在下運行過程中不可避免的會受到各種內部和外部的干擾，光纖被挖斷、黑客攻擊、數據庫被誤刪、上線系統中有bug等等，運維人員必須在第一時間內對這些意外事件作出響應，又不能夠一天24小時盯着。這就需要一個運維監控系統來協助完成。
- 日誌分析： 日誌是支付系統統計分析、運維監控的重要依據。公司需要提供基礎設施來支持日誌統一收集和分析。
- 短信平臺： 短信在支付系統中有重要作用： 身份驗證、安全登錄、找回密碼、以及報警監控，都需要短信的支持。
- 安全機制： 安全是支付的生命線。 SSL、證書系統、防刷接口等，都是支付的必要設施。
- 統計報表： 支付數據的可視化展示，是公司進行決策的基礎。
遠程連接管理、分佈式計算、消息機制、全文檢索、文件傳輸、數據存儲、機器學習等，都是構建大型系統所必須的基礎軟件，這裏不再一一詳細介紹。
支付核心系統
支付核心系統指用戶執行支付的核心流程，包括：
- 用戶從支付應用啓動支付流程。
- 支付應用根據應用和用戶選擇的支付工具來調用對應的支付產品來執行支付。
- 支付路由根據支付工具、渠道費率、接口穩定性等因素選擇合適的支付渠道來落地支付。
- 支付渠道調用銀行、第三方支付等渠道提供的接口來執行支付操作，最終落地資金轉移。
支付服務系統
支持支付核心系統所提供的功能。服務系統又分爲基礎服務系統、資金系統、風控和信用系統。
基礎服務系統提供支撐線上支付系統運行的基礎業務功能：
- 客戶信息管理：包括對用戶、商戶的實名身份、基本信息、協議的管理；
- 卡券管理： 對優惠券、代金券、折扣券的製作、發放、使用流程的管理；
- 支付通道管理: 通道接口、配置參數、費用、限額以及QOS的管理；
- 賬戶和賬務系統： 管理賬戶信息以及交易流水、記賬憑證等。這裏的賬務一般指對接線上系統的賬務，採用單邊賬的記賬方式。 內部賬記錄在會計覈算系統中。
- 訂單系統： 一般訂單系統可以獨立於業務系統來實現的。這裏的訂單，主要指支付訂單。
資金系統指圍繞財務會計而產生的後臺資金覈實、調度和管理的系統，包括：
- 會計覈算： 提供會計科目、內部賬務、試算平衡、日切、流水登記、覈算和歸檔的功能。
- 資金管理： 管理公司在各個支付渠道的頭寸，在餘額不足時進行打款。 對第三方支付公司，還需要對備付金進行管理。
- 清算分潤： 對於有分潤需求的業務，還需要提供清分清算、對賬處理和計費分潤功能。
風控系統是支付系統必備的基礎功能，所有的支付行爲必須做風險評估並採取對應的措施；信用系統是在風控基礎上發展的高級功能，京東的白條，螞蟻花唄等，都是成功的案例。
支付應用
支撐系統、核心系統和服務系統，在每個公司的架構上應該是大同小異的，都是必不可少的模塊。而支付應用是每個公司根據自己的業務來構建的，各不相同。 總的來說，可以按照使用對象分爲針對最終用戶的應用、針對商戶的應用、針對運營人員的運營管理、BI和風控後臺。
總結
這一章節簡單描述支付系統的整體架構。後續我們將以此爲基礎，分別介紹各個模塊的設計。
