第三方支付業務流程介紹

一 概述

可能你在使用支付寶時，感覺蠻簡單的，不外乎就是綁個卡，驗一下支付密碼，銀行卡的資金就被扣掉了；但是背後涉及的技術架構其實蠻複雜的，比如從外部合作來說，就涉及到了銀行，銀聯，網聯，商戶，用戶，公安，電信運營商，安全防控公司，伺服器運營商等等；如果從具體業務來說，大致分成入金類業務，出金類業務，清算對賬類業務，差錯處理類業務；因為支付業務涉及的方方面面很多，所以導致了技術架構蠻複雜的，所以本來試描繪一下支付系統的輪廓，能讓人對第三方支付有一個全貌的大致了解。

二 支付系統架構

1 支付系統的整體介紹

一般來說，支付系統從架構上來說，分為四層;分成網關層，核心層，產品層和運營支撐層；

網關層：網關一般是通過對銀行，銀聯，網聯，第三方支付的能力進行包裝然後提供原子能力給上層系統調用；比如接入網聯的快捷，網關，代付，清算對賬，差錯處理能力後，提供給其上層系統調用；另外網關一般還會維護路由系統(簡單來說，路由就是幫一筆交易通過一定規則比較後，選擇合適的道路到渠道側)。

核心層：支付系統的核心模塊，一般包括會員系統，風控系統，交易系統，收費系統，訂單系統，清算系統，賬務系統，簽約系統，數據系統等；

產品層： 通過對核心層提供的服務組合起來，大體來分，可以組合成入金類產品，比如組合成充值產品，轉賬產品等，還有出金類產品，比如提現產品，結算產品；然後通過介面，收銀台，錢包，官網，內部運營後台等具體產品系統來提供服務；

運營支撐層： 用來支持核心系統的服務， 包括運維監控系統、日誌分析系統等。

簡單來說，一筆交易進入第三方支付系統，首先會經過產品層，然後經過核心層，最後經過網關到達渠道側，同時支付機構還可以通過運營支撐層對這筆交易進行監控維護；

比如用戶買一個腎X，需要支付9998元，那麼調用支付機構的服務後進入收銀台，選擇快捷支付，那麼這個其實就是首先經過了產品層的收銀台，然後產品層收銀台的背後核心層也會參與本次交易，比如涉及到了會員系統，對該用戶會進行校驗，還涉及到風控系統，風控會對這筆交易進行判斷，能否放行，還涉及到了簽約系統，用戶選擇的銀行卡是否進行了簽約，還涉及到了收費系統，該筆交易手續費多少，還涉及到了訂單和交易系統，為該交易生成訂單，方便以後查詢核對；如果交易完成後，還涉及到清算對賬系統，該筆交易與渠道側進行對賬，商戶側對賬，內部對賬等，然後還會結算相應款項給商戶；最後還會經過網關層，網關會為該筆交易選擇合適的渠道進行資金轉移，然後調用合適渠道的能力進行業務處理；同時支付機構可通過運營支撐，對該交易進行監測管理。

2 網關層

上文已經提到過，網關主要是封裝各個渠道的差異，呈現統一的介面，然後提供給上層系統調用。同時路由一般也維護在網關層；這裡重點介紹一下路由。

簡單來說，路由就是找合適的路。支付機構一般會對接很多渠道，比如直連渠道，間連網聯，銀聯，還有其他第三方支付機構等，那麼一筆交易來了，到底該走哪條路呢，這就是路由乾的事。

路由一般分成人工路由，規則路由；人工路由指運營人員指定支付渠道和產品之間的映射關係，就是人工幫忙找路；規則路由就是按照業務要求設置各種路由規則，系統幫忙找路；

路由設計時，一般從以下方面進行考慮；費率，單筆費率，總額費率，階梯費率等；營銷策略，比如渠道側提供優惠，單筆優惠金額，單筆折扣比例，補貼總額度，活動時間等；交易限額，日限，筆限等；渠道類型，代扣，快捷，網銀，第三方支付等；銀行卡類型，借貸記類型，對公對私等；服務質量，掉單率，網路延遲等；

3 核心層

一般包括會員系統，風控系統，交易系統，收費系統，訂單系統，清算系統，賬務系統，簽約系統等；

交易系統：交易系統是一種組合能力，比如一筆交易進來，交易系統可能會調用會員系統，風控系統，充值產品，訂單系統，收費系統等等對該筆交易進行處理；

會員系統：包括對用戶、商戶的實名身份、銀行卡、基本信息、協議的管理；

訂單系統：對交易訂單的管理，比如單筆頂單，多筆訂單支付請求的處理，還有查詢訂單的處理等；

收費系統：支付機構的盈利方式之一，一筆交易通過第三方支付完成，總得給點過路費吧；收費系統一般按照單筆定額，單筆比例，混合收費，包月年封頂收費等進行；

簽約系統：如果通過銀行卡進行快捷支付，簽約是需要進行簽約的，那麼銀行提供的簽約能力，解約能力等都由簽約系統提供；

清算，賬務系統指圍繞財務會計而產生的後台資金核實、調度和管理的系統，包括會計核算： 提供會計科目、內部賬務、試算平衡、日切、流水登記、核算和歸檔的功能。資金管理： 管理公司在各個支付渠道的頭寸，在餘額不足時進行打款，對第三方支付公司，還需要對備付金進行管理。清算分潤：對於有分潤需求的業務，還需要提供清分清算、對賬處理功能。

風控系統是支付系統必備的基礎功能，所有的支付行為必須做風險評估並採取對應的措施；信用系統是在風控基礎上發展的高級功能，京東的白條，螞蟻花唄等，都是成功的案例。風控系統一般進行三種校驗，交易放行，交易攔截，交易驗證增強；

4 產品層

通過對核心層提供的服務組合起來，大體來分，可以組合成入金類產品，比如組合成充值產品，轉賬產品等，還有出金類產品，比如提現產品，結算產品；然後通過介面，收銀台，錢包，官網，內部運營後台等具體產品系統來提供服務；

入金類產品整體上來說，可以提供如下能力：

(1)快捷，代扣支付

用戶在完成綁卡之後，在支付的時候，不需要再輸入卡或者身份信息，僅需要輸入支付密碼就可以完成支付。對於小額度的支付，甚至可以開通小額免密，直接完成支付。 這種支付方式不會打斷用戶的體驗，是目前主要的在線支付方式。

(2) 網銀支付

用戶在支付的時候，需要跳轉到銀行網銀頁面來完成支付。在網銀頁面，需要輸入用戶的卡號和身份信息。這種支付方式會中斷用戶當前的體驗，一般僅用於PC Web上的支付。 網銀支付是封裝銀行提供的網銀支付來實現。

(3)第三方支付

使用微信、支付寶等第三方支付平台來完成支付。使用時，一般需要用戶預先安裝支付平台系統（手機上），註冊並登錄到第三方支付平台，並且已經在該平台上完成綁卡等操作。 由於微信、支付寶已經被大量使用，用戶也產生對這些平台的信任，該類支付往往是電商公司的主要支付方式。

(4)賬戶支付

也成為餘額支付、零錢支付等。 指為用戶建立本地賬戶， 支持充值，之後可以使用這個賬戶來完成支付。

(5)信用支付

如京東的白條，螞蟻花唄等，指使用信用賬戶進行透支，類似信用卡支付。

出金類產品整體來說，就是提供轉賬、結算等能力

5 運營支撐層

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

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

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

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

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

統計報表： 支付數據的可視化展示，是公司進行決策的基礎。

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

三 支付業務商戶側流程

一般支付機構會通過介面，收銀台，錢包，官網等具象產品為商戶提供服務；那麼商戶側使用支付機構的服務一般涉及到以下幾方面。

1. 簽約和解約

在快捷支付、代扣等產品中，用戶在使用前，需要先完成簽約。商戶側負責收集用戶銀行卡的信息，然後調用支付機構的介面進行簽約，可能支付機構會調用銀行和銀聯的介面進行簽約。簽約後，後續的支付行為就使用簽約號來進行，無需再輸入個人信息。 和簽約相對應，解約則是取消簽約關係。

2. 支付

支付是少不了的操作。支付前，商戶需向支付機構下單，然後調用付款介面進行支付，一般提供快捷支付和網銀支付能力；

3. 撤銷和退款

商戶向支付機構下單或付款後，該筆訂單由於一些原因，並不想真的執行，那麼就可使用支付機構的能力進行撤銷或退款；

4. 查詢簽約狀態

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

5. 查詢訂單狀態

通過這個介面來查詢訂單狀態以及退款的訂單狀態。

6 對賬

通過FTP或者HTTP方式提供對賬文件供商戶側對賬。

四 支付業務中支付機構內部流程

一般會包括參數校驗，支付路由，生成訂單，風險評估，調用渠道服務，更新訂單和發送消息這7步，對於一些比較複雜的服務，還會涉及到非同步同通知處理的步驟。

1. 執行參數校驗

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

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

驗證賬戶狀態。交易主體、交易對手等賬戶的狀態是處於可交易的狀態。

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

驗證簽名。簽名也是為了防止支付介面被偽造。 一般簽名是使用分發給商戶的key來對輸入參數拼接成的字元串做MD5 Hash或者RSA加密，然後作為一個參數隨其他參數一起提交到伺服器端。如支付網關設計所介紹，簽名驗證也可以在網關中統一完成。

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

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

3. 評估交易風險

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

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

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

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

4. 生成交易訂單

將訂單信息持久化到資料庫中。

5. 調用支付渠道提供的服務

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

6. 更新訂單

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

7. 發送消息

通過消息來通知相關係統關於訂單的變更。風控，數據系統等，都需要依賴這數據做准實時計算。

8. 非同步通知

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