在網際網路產品運營中，有很多小夥伴或許會遇到這樣的困擾：產品好不容易推出來了，流量成本節節攀升，使用者的活躍度、留存度卻持續下降。

因此在瞬息萬變的網際網路產品環境中，需要研發接入支付系統來加入商業行為的閉環，支付系統能夠幫助企業更好地實現商業化，利用那些為使用者而生的支付體系產品，實現使用者積累、商業變現。

對於支付系統，有針對不同行業的支付系統，有支付寶，微信支付，paypal的通用閘道器支付，也有聚合了不同閘道器的聚合系統。

不論你是對支付行業感興趣，亦或自己研發支付系統，本篇內容會對你有價值。

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

支付產品模組是按照支付場景來為業務方提供支付服務。這個模組一般位於支付閘道器之後，支付渠道之前。 它根據支付能力將不同的支付渠道封裝成統一的介面，通過支付閘道器來對外提供服務。所以，從微服務的角度，支付產品本身也是一個代理模式的微服務，它透過支付閘道器響應業務方請求， 進行一些統一處理後，分發到不同的支付渠道去執行，最後將執行結果做處理後，通過支付閘道器再回傳給業務方。

支付產品在支付系統參考架構圖中之位置，請看下圖所示：

產品分類

在不同的公司由於接入渠道和應用的差異，對支付產品分類略有不同。綜合支付場景和流程，支付產品可以分為如下幾類：

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

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. 評估交易風險

檢查本次交易是否有風險。風控介面返回三種結果：阻斷交易、增強驗證和放行交易。

1) 阻斷交易，說明該交易是高風險的，需要終止，不執行第5個步驟；

2) 增強驗證，說明該交易有一定的風險，需要確認下是不是使用者本人在操作。這可以通過傳送簡訊驗證碼或者其他可以驗證使用者身份的方式來做校驗，驗證通過後，可以繼續執行該交易。

3) 放行交易，即本次交易是安全的，可以繼續往下走。

4. 生成交易訂單

將訂單資訊持久化到資料庫中。當訪問壓力大的時候，資料庫寫入會成為一個瓶頸。

5. 呼叫支付渠道提供的服務

所有的支付服務都需要第三方通道來完成執行。一般銀行渠道的呼叫比較簡單，可以直接返回結果。一些第三方支付，支付寶，微信支付等，會通過非同步介面來告知支付結果。

6. 更新訂單

對於同步返回的結果，需要在主執行緒中更新訂單的狀態，標記是支付成功還是失敗。對於非同步返回的渠道，需要在非同步程式中處理。

7. 傳送訊息

通過訊息來通知相關係統關於訂單的變更。風控，信用BI等，都需要依賴這資料做準實時計算。

8. 非同步通知

如上述流程，其中涉及到呼叫遠端介面，其延遲不可控。如果呼叫方一直阻塞等待，很容易超時。引入非同步通知機制，可以讓呼叫方在主執行緒中儘快返回，通過非同步執行緒來得到支付結果。對於通過非同步來獲取支付結果的渠道介面，也需要對應的在非同步通知中將結果返回給呼叫方。 非同步通知需要呼叫方提供一個回撥地址，一般以http或者https的方式。這就有技術風險，如果呼叫失敗，還需要重試。而重試不能過於頻繁，需要逐步拉大每一次重試的時間間隔。 在非同步處理程式中，訂單根據處理結果變更狀態後，也要發訊息通知相關係統。

支付系統架構整體設計

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

支付寶

我們先看看業內最強的支付寶系統。架構圖如下：這個整體架構上並沒有與眾不同之處。在模組劃分上，這個圖顯示的是最頂層的劃分，也無法告知更多細節。 但支付寶架構文件有兩個搞支付平臺設計的人必須仔細揣摩的要點。 一個是賬務處理。在記賬方面，涉及到內外兩個子系統，外部子系統是單邊賬，滿足線上效能需求；內部子系統走複式記賬，滿足財務需求。在清結算這個章節中也是基於這個模型來詳細介紹如何記賬、對賬和平賬。另一個亮點是柔性事務處理，利用訊息機制來實現跨系統的事務處理，避免資料庫鎖導致的效能問題。

京東金融

來自京東支付平臺總體架構設計 。如下圖：京東金融是在網銀線上的基礎上發展起來的。 網銀線上的原班技術人員有不少來自易寶公司，在京東收購之後，又引入了支付寶的人才。

因而從架構上受這兩個公司的影響很大。

去哪兒

美團的支付平臺架構

來自美團的支付平臺規劃架構 。這是2015年的文件。 2016年美團才拿到支付牌照。 從這個架構，大家也能知道為什麼美團必須拿到支付牌照。

這些架構文件全部來自網際網路公開資料。 對於架構是否真實反映實際系統情況，需要大家自行判斷。 我們以這些文件為基礎，分析支付系統的應有的軟體架構。

參考架構

一般來說，支付系統典型架構會包含如下模組：

支付系統從架構上來說，分為三層;

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

2. 核心層： 支付系統的核心模組，內部又分為兩個部分： 支付核心模組以及支付服務模組。

3. 產品層： 通過核心層提供的服務組合起來，對終端使用者、商戶、運營管理人員提供的系統。

支撐系統

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

1. 運維監控： 支付系統在下執行過程中不可避免的會受到各種內部和外部的干擾，光纖被挖斷、黑客攻擊、資料庫被誤刪、上線系統中有bug等等，運維人員必須在第一時間內對這些意外事件作出響應，又不能夠一天24小時盯著。這就需要一個運維監控系統來協助完成。

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

3. 簡訊平臺： 簡訊在支付系統中有重要作用： 身份驗證、安全登入、找回密碼、以及報警監控，都需要簡訊的支援。

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

5. 統計報表： 支付資料的視覺化展示，是公司進行決策的基礎。

遠端連線管理、分散式計算、訊息機制、全文檢索、檔案傳輸、資料儲存、機器學習等，都是構建大型系統所必須的基礎軟體，這裡不再一一詳細介紹。

支付核心系統

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

1. 使用者從支付應用啟動支付流程。

2. 支付應用根據應用和使用者選擇的支付工具來呼叫對應的支付產品來執行支付。

3. 支付路由根據支付工具、渠道費率、介面穩定性等因素選擇合適的支付渠道來落地支付。

4. 支付渠道呼叫銀行、第三方支付等渠道提供的介面來執行支付操作，最終落地資金轉移。

支付服務系統

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

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

1. 客戶資訊管理：包括對使用者、商戶的實名身份、基本資訊、協議的管理；

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

3. 支付通道管理: 通道介面、配置引數、費用、限額以及QOS的管理；

4. 賬戶和賬務系統： 管理賬戶資訊以及交易流水、記賬憑證等。這裡的賬務一般指對接線上系統的賬務，採用單邊賬的記賬方式。 內部賬記錄在會計核算系統中。

5. 訂單系統： 一般訂單系統可以獨立於業務系統來實現的。這裡的訂單，主要指支付訂單。

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

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

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

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

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

支付應用

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

總體來說，可以按照使用物件分為針對終端使用者的應用、針對商戶的應用、針對運營人員的運營管理、BI和風控後臺。

總結

本篇為大家描述支付系統的整體架構。後續我們會將以此為基礎，分別介紹各個模組的設計。