一、第三方支付產生的背景

最開始做第三方支付產品的公司是PayPal，也就是中文名為：貝寶（建議閱讀《支付戰爭》）。

國內的產生的背景是隨著網際網路電子商務發展起來的，阿里巴巴和慧聰網把線下的商務交易轉移到網際網路上，在1998年首易信支付開始做第三方支付，當時功能僅僅是把使用者的支付需求告知銀行，讓使用者在銀行的網上支付頁面完成支付這樣簡單的支付模式上。

在2005年，阿里巴巴的馬雲提出第三方支付平臺的概念（建議閱讀《螞蟻金服》）。

 

二、第三方支付牌照現狀

央行總計發出了272張支付牌照，截止2018年6月央行登出了29張第三方支付牌照，全國剩餘243張實際有效期242張，湖北藍天星主動登出支付牌照，央行網站未更新。

 

三、我國現代支付體系及第三方支付行業

 

 

3.1 第三方支付產品鏈：

 

3.2  支付行業與型別

第三方支付現在可以分為線上和線下支付兩個部分。線上支付分為基於PC端的網際網路支付和基於移動端的移動支付。線下支付中佔據最大市場份額的是銀行卡收單業務，其他還包括掃碼支付和預付卡業務等。第三方支付行業主要包括銀行卡收單，網路支付及預付費卡發行與受理三種主要的業務型別，進一步細分又分為線下收單，網際網路支付，移動支付，跨境支付等領域。

 

 

3.3  第三方支付參與者的主要盈利模式

產業鏈的不同環節賺取不同利潤。

第三方支付企業目前主要的盈利方式：電商交易商戶交易佣金；沉澱資金利息收入等。

銀行的核心業務是負債業務和資產業務，支付清算和電子銀行業務只是銀行中間業務中的一小部分，該類業務佔銀行業務收入的佔比非常小。

銀聯的核心商業模式有銀行卡收單跨行交易手續費分潤；ATM跨行取款收費；非金融機構支付清算；銀行卡發行品牌服務（類似冠名）。

商業銀行：銀行卡交易髮卡行手續費分潤；銀行卡交易收單行手續費分潤；電子銀行轉賬等手續費；快捷支付手續費分潤支付。

 

 

支付清算是第三方支付的主要業務，是幫助實現資金轉移支付的工具，銀行對電子銀行的業務的發展是為了更好的服務由資產業務和負債業務而產生的存量客戶；電子支付作為第三方支付的根基，其要做到以支付產品去吸引使用者，留住使用者，所以在支付產品的開發、流程的優化的迫切性要遠高於商業銀行。資產負債類業務在銀行電子支付業務之先，銀行並非一定要通過支付資料的開發擴充套件新的業務模式，其對資料資源的重視和利用程度不如第三方支付。下圖為第三方支付企業的盈利模式：

 

 

 

3.4 第三方支付企業市場規模

線上支付（PC端和移動端）：在2015年其市場規模超過20萬億。網際網路支付的爆發式增長先於移動支付，且在2015年兩者都實現了快速增長。近兩年，移動支付快於網際網路支付，顯示了手機端對使用者的粘性越大，且明顯感覺到移動支付的增長規模要遠超於PC端支付，在2016年市場規模有望達到28.7萬億。

 

 

線下支付：主要為POS收單業務，掃碼支付和預付卡支付等。掃碼支付和預付卡支付市場均在千億級別。

 

四、第三方支付系統整體架構

 

 

4.1 支付產品的主要分類

以下產品為絕大部分的支付公司所包含的產品：快捷支付（API快捷），網銀支付，收銀臺產品、代付（分為單筆和批量），代扣（分為單筆和批量），餘額支付（賬戶體系為前提的）。二級產品（公繳費：電話費，水電燃氣費，信用卡還款）、跨境支付等，信用支付。

注：代扣是其實是協議支付，信用卡預約還款也屬於協議支付。

快捷支付：是第三方支付提供介面，商戶使用介面包裝自己的支付產品，使產品擁有支付功能。

網銀支付：是在商戶的平臺上，通過第三方支付的呼叫介面跳轉到銀行的網銀頁面，讓使用者去支付的形式。

收銀臺：是第三方支付將快捷支付，網銀……等等支付功能集合到一個收銀臺內，供使用者選擇支付方式。

協議支付：包括代扣，信用卡預約還款，有線電視費定期扣費，渠道商和使用者簽訂的協議中協定了每個月聯絡扣款等，在使用者取消續約之後，就取消扣款等。在後臺呼叫的就是代扣的介面。這類是從使用者的卡上扣款到商戶或平臺，需要通用同意協議。

代付：將平臺或商戶的錢打給使用者。

 

 

支付產品的支付支付能力，對外提供的功能大致有如下：

 

 

名詞解釋：

預授權：預授權交易使用者受理方向持卡人的髮卡方確認交易許可。受理方將預估的消費金額作為預授權金額，傳送給持卡人的髮卡方。

簽約：在快捷支付和代扣等產品中，使用者在使用前，需要先完成簽約。簽約可以在渠道側進行，一般情況下在第三方支付公司會和銀行去簽約。在電商需要接入時，電商負責收集使用者的資訊，呼叫銀行和銀聯的介面進行簽約，簽約後，後續的支付行為就可以使用簽約號來進行，無需再輸入個人資訊。

解約：解除簽約關係，銀行不再到期扣款。

撤銷：在渠道側（電商或商戶）對未結算的交易發起撤銷本交易的請求；

退款：針對已經結算的交易或者未結算的交易發起退款請求。（不同的支付機構要求不同）

查詢簽約狀態：對於需要簽約的交易，可以通過介面查詢簽約狀態。

查詢訂單狀態：通過介面查詢支付訂單狀態及資訊（任何訂單都可查詢交易狀態）

對賬：通過FTP或者HTTP的方式提供對賬檔案供商戶側對賬。

餘額查詢：查詢商戶的交易賬戶的餘額，避免由於餘額不足導致交易失敗。

 

4.2 支付業務流程

除了對賬、查單外，每個操作實現的主流程，一般會包括引數校驗，支付路由，生成訂單，風險評估，呼叫渠道服務，更新訂單和傳送訊息這7步，對於一些比較複雜的服務，還會涉及到非同步同通知處理的步驟。

 

 

1、執行引數校驗

所有的支付操作，都需要對輸入引數執行引數校驗，避免介面受到攻擊。

驗證輸入引數中各欄位的有效性驗證，比如使用者ID，商戶ID，價格，返回地址等引數。

驗證賬戶狀態：交易主體，交易對手等賬戶的狀態是可交易的狀態。

驗證訂單：如果設計到預訂單，還需要驗證訂單號的有效性，訂單狀態是未支付。為了避免使用者快取某個URL地址，還需要校驗下單時間和支付時間是否超過預定的時間間隔。

驗證簽名：簽名也是為了防止介面被偽造。一般簽名是使用分發給商戶的Key對來輸入引數拼接成的字串做MD5Hash 或者RSA 加密，然後作為一個引數隨其他引數一起提交到伺服器端。

 

2、根據支付路由尋找合適的支付服務

根據使用者選擇的支付方式確定用來完成該操作的合適的支付渠道。使用者指定的支付方式不一定是最終的執行支付的渠道。

比如使用者選擇工行信用卡來執行支付，但是我們沒有實現和工行的對接，而是可以通過第三方支付，比如支付寶，微信支付，易寶支付，或者銀聯來完成。那如何選擇合適的支付渠道，就通過支付路由實現。支付路由會綜合考慮收費、渠道的可用性等因素來選擇最優方案。

 

3、評估交易風險

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

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

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

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

4、生成交易訂單

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

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

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

6、更新訂單

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

7、傳送訊息

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

8、非同步通知

如上述流程，其中涉及到呼叫遠端介面，其延遲不可控。如果呼叫方一直阻塞等待，很容易超時。引入非同步通知機制，可以讓呼叫方在主執行緒中儘快返回，通過非同步執行緒來得到支付結果。對於通過非同步來獲取支付結果的渠道介面，也需要對應的在非同步通知中將結果返回給呼叫方。

非同步通知需要呼叫方提供一個回撥地址，一般以http或者https的方式。這就有技術風險，如果呼叫失敗，還需要重試。而重試不能過於頻繁，需要逐步拉大每一次重試的時間間隔。在非同步處理程式中，訂單根據處理結果變更狀態後，也要發訊息通知相關係統。

4.3 支付寶系統架構設計

圖示為支付寶頂層設計：

 

一：賬務處理。在記賬方面，涉及到內外兩個子系統，外部系統是單邊賬，滿足線上效能需求；內部子系統走複式記賬，滿足財務需求。在清結算這個章節中也是基於這個模型來詳細介紹如何記賬，對賬和平賬。

 

 

另一個亮點是柔性事務處理，利用訊息機制來實現跨系統的事務處理，避免資料庫鎖導致的效能問題。

4.4 京東支付系統架構設計

 

4.5 去哪兒的支付系統架構設計

 

 

4.6  支付系統從架構上說，分三層

1、支撐層

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

包括：運維監控，日誌分析，簡訊平臺，安全機制，統計報表，遠端連線管理，分散式計算，訊息機制，全文檢索，檔案傳輸，資料儲存，機器學習等。都是構建大型系統所必須的基礎軟體。

2、核心層

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

包括：使用者從支付應用啟動支付流程；支付應用根據應用和使用者選擇的支付工具來呼叫對應的支付產品來執行支付；支付路由根據支付工具、渠道費率、介面穩定性等因素選擇合適的支付渠道來落地支付；支付渠道呼叫銀行、第三方支付等渠道提供的介面來執行支付操作，最終落地資金轉移。

3、產品層

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

服務系統：

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

基礎服務系統

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

客戶資訊管理：

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

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

支付通道管理：通道介面，配置引數，費用，限額以及QOS（Quality of Service 服務質量）的管理；

賬戶和賬務管理

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

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

資金系統

指圍繞財務會計而產生的後臺資金核實、排程和管理的系統，包括：會計核算：提供會計科目、內部賬務、試算平衡、日切、流水登記、核算和歸檔的功能。

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

清算分潤

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

風控系統

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

 

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