互聯網支付系統架構

大部分公司，只要想賺錢，就得上支付系統，讓用戶或者客戶有地方交錢。 當然，公司發展的不同階段，對支付系統的定位和架構也不同。整體上來說，我們可以把一個公司的支付系統發展分為三個階段：

1、支付系統：支付作為一個（封閉）的、獨立的應用系統，為各系統提供支付功能支持。一般來說，這個系統僅限於為公司內部的業務提供支付支持，並且和業務緊密耦合。

2、支付服務：支付作為一個開發的系統，為公司內外部系統、各種業務提供支付服務。支付服務本身應該是和具體的業務解耦合的。

3、支付平臺：支付作為一個可擴展的平臺， 公司內外部的用戶可以在此基礎上定製開發自己的服務。

這個劃分有點勉強。簡單說，支付系統是僅供內部使用的， 支付服務是支持公司內外部來調用的，支付平臺是可以在服務的基礎上定製各種場景支持的。

支付業務流程

區分兩個概念:支付和交易。支付是交易的一部分。一個簡單的交易過程包括:客戶下訂單，客戶完成支付，商家接收訂單，商家出貨。這裡僅考慮下訂單的流程。從軟件工程的角度， 我們首先需要明確下幾個參與者。

電商系統，指提供在線購物服務的系統。用戶在這個系統中完成交易。

支付系統，可以是電商系統的一個模塊，或者是個獨立的系統。這是本文的主角，用來完成支付過程。

用戶，在電商系統中敗家的那位。如果使用銀行卡做交易，那也被稱為持卡人。

用戶使用銀行卡交易時，發行這個銀行卡的機構稱為髮卡行，或者髮卡機構。

商家也需要一張卡，就是大家在淘寶開網店的時候要登記的銀行卡，最終需要把用戶給的錢打到這張卡上。

和髮卡機構相對應的，大家聽到最多的是收單機構。如支付寶，微信等第三方支付公司，介紹業務的時候總少不了互聯網收單的工作。它們把用戶訂單收起來，找髮卡行要錢，就有了收單業務。

主演都有了，下面就是如何演出支付這場大戲了。正常的流程應該是這樣：

1、用戶提交訂單到電商系統，電商系統對訂單進行檢驗，無問題則調起支付接口執行支付。注意這裡支付接口是在服務器端調起的。一般支付接口很少從客戶端直接調起。為了安全，支付接口一般要求用HTTPS來訪問，並對接口做簽名。關於支付接口的設計，我將另起博文介紹。

2、支付系統檢查參數有效性，特別是簽名的有效性。

3、根據用戶選擇的支付方式，以及系統支付路由設置，選擇合適的收單機構。這裡涉及三個概念，支付方式，支付路由。這又是一個槽點。簡單說，用戶可以選擇各種銀行卡支付，比如寧波銀行卡，但是你的支付系統沒有對接寧波銀行，那對這種卡，可以選擇你接入的，支持這個卡的收單機構來執行支付，如用微信或者支付寶等等第三方支付，或者銀聯支付等系統支持的方式來執行。這就是支付路由，根據用戶提供的銀行卡來選擇合適的收單機構去執行支付。常用支付方式還包括第三方支付，如微信支付寶等，這種情況下就不需要支付路由了。

4、調用收單接口執行支付。這是支付系統的核心。每個公司的收單接口都不一樣，接入一兩個收單機構還好，接入的多了，如何統一這些接口，就是一個設計難點。

5、支付成功，收單機構把錢打到商戶的賬戶上了。 商家就準備發貨了。 怎麼發貨，不是本文的重點。 這裡關注的要點是， 商家能收到多少錢？ 比如100塊錢的商品，用戶支付了100塊錢（運費、打折等另算），這100塊錢，還要刨去電商系統的佣金、支付通道的手續費，才能最終落到商家手裡。

這是個Happy流程，一切看起來都很美好，但實際上步步都是坑，一旦有地方考慮不周全，輕者掉單頻發，重者接口被盜刷，損失慘重。

如何避免攻擊者修改支付接口參數， 比如100塊錢的東西，改成10塊錢？

調用收單接口來執行最終實際支付時，如果支付失敗了，比如卡上沒錢了，怎麼辦？

收單接口把賬戶上的錢扣走了，但是通知支付系統的時候出錯了（比如網絡閃斷，或者支付系統重啟了），支付系統不知道這筆交易已經達成了，怎麼處理？

還有好多問題….

和錢打交道，在任何公司，都跑不掉財務部門。 那財務部門會關注哪些內容？ 當然，最重要的是賬務信息。 所有的交易都要記賬，按要求公司都需要定期做審計，每一筆帳都不能出錯。這當然不能等到審計的時候再去核對，而是每天都需要對賬，確保所有的交易支出相抵，也就是所說的把賬給平了。 這就有三種情況：電商系統和商家對賬；電商系統和支付系統對賬；支付系統和收單機構對賬。最為支付系統，我們僅關注後兩者的情況。

從軟件開發角度， 還有一些非功能性需求需要實現：

性能： 特別是秒殺的時候，如何滿足高頻率的支付需求？

可靠性：不用說，系統能達到幾個9，是衡量軟件設計功力的重要指標。 99%是基礎， 99.999%是目標，更多的9哪就是神了。

易用性：支付中多一個步驟，就會流失至少2%的用戶。 產品經理都在削尖腦袋想想怎麼讓用戶趕緊掏錢。

可擴展性： 近年來支付業務創新產品多，一元購、紅包、打賞等，還有各種的支付場景。 怎麼能夠快速滿足產品經理的需求，儘快上線來搶佔市場，可擴展性對支付系統設計也是一個挑戰。

可伸縮性：為了支持公司業務，搞一些促銷活動是必須的。 那促銷帶來的爆發流量，最佳應對方法就是加機器了。 平時流量低，用不了那麼多機器，該釋放的就釋放掉了， 給公司省點錢。

支付的典型架構

所以支付的坑還不少，我們先看看互聯網的頭牌們是如何設計支付系統的？ 先看看某團的：

再看某Q旅遊公司的的：

對比下某東金融的：

最後看看業界最強的某金服金融的：

整體上來說， 從分層的角度，支付系統和普通的業務系統並沒有本質的區別，也是應用、服務、接口、引擎、存儲等分層。 在應用層，支付系統一般會提供如下子系統：

1、支付應用和產品.(應用層)： 這是針對各端（PC Web端、android、IOS)的應用和產品。 為各個業務系統提供收銀臺支持，同時支付作為一個獨立的模塊，可以提供諸如銀行卡管理、理財、零錢、虛擬幣管理、交易記錄查閱、卡券等功能；

2、支付運營系統(應用層)： 支付系統從安全的角度來說，有一個重要的要求是，懂代碼的不碰線上，管運營的不碰代碼。這對運營系統的要求就很高，要求基本上所有線上的問題，都可以通過運營系統來解決。

3、支付BI系統(應用層): 支付中產生大量的數據，對這些數據進行分析， 有助於公司老闆們瞭解運營狀況，進行決策支持。

4、風控系統(應用層)：這是合規要求的風險控制、反洗錢合規等。

5、信用信息管理系統(應用層)：用來支持對信用算法做配置，對用戶的信用信息做管理。

其他各層功能：

1、支付服務層：為上述各端系統提供API。這些API也可以提供給業務系統直接使用。

2、接口層：和各相關係統對接的接口，其中最重要的是和支付渠道對接的支付網關。

3、引擎層： 包括統計分析、風控、反洗錢、信用評估等在後臺運行的各個系統。

4、存儲層： 各種持久化的數據庫支持。

這其實也是普通互聯網應用系統架構，沒有什麼特別之處。比如微服務如何體現，如何滿足性能需求等，在這個視圖中無法體現出來。這只是個軟件角度的高層視圖，後續我們對各個主要模塊進行分解，從分解視圖中可以知道如何滿足非功能性需求。