支付網關前置數據庫
支付網關前置是對接業務系統，爲其提供支付服務的模塊。它是全部支付服務接口的集成前置，將不一樣支付渠道提供的接口經過統一的方式呈現給業務方。這樣接入方就只須要對接支付網關，增長和調整支付渠道對業務方是透明的。 支付網關前置的設計對整個支付系統的穩定性、功能、性能以及其餘非功能性需求有着直接的影響。安全
在支付網關中須要完成大量的操做，爲了保證性能，這些操做都儘可能異步化來處理。服務器
支付網關前置應保持穩定，儘可能減小系統重啓等操做對業務方的影響。支付網關也避免不了升級和重啓。這可經過基於Nginx的LBS(Load Balance System)網關來解決。LBS在這裏有兩個做用： 一個是實現負載均衡，一個是隔離支付網關重啓對調用的影響。 支付網關也採用多臺機器分佈式部署，重啓時，每一個服務器逐個啓動。某臺服務器重啓時，首先從LBS系統中取消註冊，重啓完成後，再從新註冊到LBS上。這個過程對調用方是無感知的。微信
爲了不接口受攻擊，在安全上，還得要求業務方經過HTTPS來訪問接口，並提供防篡改機制。防篡改則經過接口參數簽名來處理。如今主流的簽名是對接口參數按照參數名稱排序後，作加密和散列，參考微信的簽名規範。架構
交易流水和記帳負載均衡
每一筆交易都須要記錄流水，並登記到我的和機構的分戶帳戶上，統計和分析也須要根據交易流水來更新相關數據。 而我的和機構帳戶總額更新、交易流水記錄以及庫存的處理，更是須要事務處理機制的支持。 從性能角度， 能夠弱化了事務處理的要求，採用消息機制來異步化和交易相關的數據處理。異步
● 在支付網關前置的主流程中，僅記錄交易流水，即將當前的請求保存到數據庫中。分佈式
● 完成數據記錄後，發送MQ出來，記帳、統計、分析，都是接收MQ來完成數據處理。性能
● 涉及到本地資金支付，好比錢包支付，會須要分佈式事務處理，扣減帳號餘額，記帳，扣減庫存等，每一個操做失敗，都要回滾。阿里有很不錯的分享，這裏不詳細描述。加密
● 當交易量上來後，須要考慮交易表的分表分庫的事情。分表分庫有兩個策略，按照流水號或者交易主體id來走。後者能夠支持按用戶來獲取交易記錄。咱們用的是前者。後者能夠走elastic，確保數據庫專用。風控，信用和統計所須要的數據，經過MQ同步到Hbase裏面。做爲支付系統最有價值的數據，在存儲上作到專庫專用，無可厚非，畢竟存儲成本仍是廉價的。
風控模塊
風控對支付的重要性怎麼強調都不過度。有些系統在風控出問題時能夠旁路風控，可是在支付系統中，風控出問題必須中止交易。 總體上，風控能夠分爲數據採集，數據分析，實時計算，規則配置，實時攔截等模塊。風控自己是個大話題，之後專門討論。又欠一個債。 但風控和交易的接口比較簡單。對每一次交易，風控通常返回三個結果:攔截，加強驗證，經過。經過指交易沒有問題，能夠直接放行。攔截則是阻止本次交易。加強驗證則是交易存疑，須要用戶進一步覈實身份才能繼續，好比輸入手機號或者身份證號，通常用於身份被盜用的場景。而人工覈實則是對交易有疑問，通常用於我的惡意消費滿場景。
支付路由
支付路由是一個複雜的話題。對支付系統來講，能支持的支付方式越多越好，不能因爲支付方式的不支持斷了財路。現實中的支付方式多得難以置信。用戶隨時甩出一張你聽都沒據說過的卡。若是一個銀行卡只有幾個用戶在用，那針對這個卡開發個對接有點得不嘗失。如今第三方支付的爆發，確實給開發支付系統省了很多事。可是公司不可能只對接一個第三方支付，若是這個渠道出問題了，或者鬧矛盾了，把連接給掐了，老闆還不欲哭無淚。總之，得對接多個渠道。對於交易量大的銀行，還得考慮直聯。
支付路由的做用是定義對用戶選用的銀行卡或者其餘支付方式，使用什麼渠道來完成支付。