一文讀懂支付系統

支付系統是連線消費者、商家（或平臺）和金融機構的橋樑，管理支付資料，呼叫第三方支付平臺介面，記錄支付資訊（對應訂單號，支付金額等），金額對賬等功能，根據不同公司對於支付業務的定位不同大概有幾個階段：第一階段：支付作為一個（封閉）的、獨立的應用系統，為各系統提供支付功能支援。一般來說，這個系統僅限於為公司內部的業務提供支付支援，並且和業務緊密耦合。第二階段：支付作為一個開發的系統，為公司內外部系統、各種業務提供支付服務，支付服務本身應該是和具體的業務解耦合。

      支付是電商系統中核心

  我們先來看一下使用者完成一次購物需要進行那些操作：

通常消費者在手機APP或者網站都會涉及到支付相關的業務場景，使用者只需要簡單點選支付按鈕輸入支付密碼，就可以完成整個支付過程，那麼我就和大家一起來看看一個完整的支付系統有什麼功能組成和設計時需要考慮那些問題。

從上圖中我們可以看出真實的資金流向。首先當使用者產生支付行為時，資金從使用者端流向支付系統，退款時則相反，從支付系統迴流至使用者端。因此在整個交易過程中使用者端與支付系統是雙向資金的流動方式。對於支付系統而言，資金有進有出。從支付系統到商戶端就比較簡單了，在清算完成後支付系統負責將代收的資金結算給商戶，通常結算的操作可以線上上來完成（採用支付公司代付介面或者銀企直連線口來完成），也可以由公司財務透過線下手工轉賬的方式來完成，因此這種資金流動的方式是單向的。出於資金安全考慮，大多數公司通常這部分採用線下方式實現。

真實的資金流由支付公司按照約定期限（通常 T+1 ）結算到平臺公司對公賬戶中，然後再由平臺公司再按照交易明細進行二次清算後結算給對應的商戶。

支付系統

一個支付系統需要由哪些功能模組組成

1. 應用管理: 同時支援公司多個業務系統對接。

2. 商戶管理: 支援商戶入駐，商戶需要向平臺方提供相關的資料備案。

3. 渠道管理: 支援微信、支付寶、銀聯、京東支付等多種渠道。

4. 賬戶管理: 渠道賬戶管理，支援共享賬戶（個人商戶）及自有賬戶。

5. 支付交易: 生成預支付訂單、提供退款服務。

6. 對賬管理: 實現支付系統的交易資料與第三方支付渠道交易明細的自動核對（通常T+1），確保交易資料的準確性和一致性。

7. 清算管理: 計算收款交易中商戶的應收與支付系統收益。

8. 結算管理: 根據清算結果，將資金劃撥至商戶對應的資金帳戶中。

支付系統有幾個關鍵的核心流程：支付流程、對賬流程、結算流程

1. 使用者在商城選購商品併發起支付請求；

2. 商城將支付訂單透過B2C閘道器收款介面傳送至支付閘道器；

3. 使用者選擇網銀支付及銀行，支付平臺將訂單轉送至指定銀行閘道器介面；

4. 使用者支付完成，銀行處理結果並向平臺返回處理結果；

5. 支付平臺接收處理結果，落地處理並向商戶返回結果；

6. 商城接收到支付公司返回結果，落地處理（更改訂單狀態）並通知使用者。

一般而言支付系統會給商戶設定有“可用餘額”賬戶、“待結算”賬戶；系統在接收到銀行返回支付成功資訊會進行落地處理，一方面更改對應訂單狀態，另一方面在商戶待結算賬戶記入一筆金額；該筆金額，系統會根據結算週期從待結算賬戶--->“可用餘額”賬戶。

1. 使用者在商戶平臺發起退款申請，商戶核實退款資訊及申請；

2. 商戶登入支付平臺賬戶/或者透過支付公司提供的退款介面向支付平臺發起退款；

3. 支付系統會對退款資訊校驗（退款訂單對應的原訂單是否支付成功？退款金額是否少於等於原訂單金額？），校驗商戶賬戶餘額是否充足等；校驗不透過，則無法退款；

4. 支付系統在商戶可用餘額賬戶扣除金額，並將退款訂單傳送至銀行，銀行完成退款操作。注意：對於閘道器收款的訂單退款，各銀行要求不一，有些銀行提供的退款介面要求原訂單有效期在90或180天，有些銀行不提供退款介面；針對超期或者不支援介面退款的訂單，支付公司透過代付通道完成退款操作。

對於收單金額未結算，還在“待結算”賬戶的訂單，如果出現退款情況，業務流程和上述流程差不多，只是從待結算賬戶進行扣款。

        對賬，我們一般稱為勾兌，支付系統的對賬，包含著兩個層面：

1. 支付系統內部間的對賬，支付系統一般是分散式的，整個支付系統被拆分成了多個子系統，如交易系統、賬戶系統、會計系統、賬戶系統，每個子系統在處理各自的業務，系統間的對賬，就是以上系統的核對，用於修正內部系統的資料不一致。

2. 支付系統與渠道的對賬，這裡的渠道泛指所有為支付系統提供代收付業務的渠道，如：第三方支付公司、銀行、清算中心、網聯、銀聯等。

系統間的對賬比較好理解，這裡主要講支付系統與渠道間的對賬。支付系統與渠道間的對賬，又包含2個維度：

1. 資訊流勾對：即業務對賬／交易對賬，主要是就收單交易的支付資訊與銀行提供的資訊流檔案進行勾兌。資訊流的勾地能發現支付系統與銀行系統間的掉單、兩邊由於系統間的原因導致的同一筆交易支付金額不一致（可能性很小）或者支付狀態不一致。資訊流勾兌一般用來恢復掉單資料，可透過補單或者具體系統問題排查解決。

2. 資金流勾對：即資金對賬，主要就收單交易的支付資訊與銀行提供的資金流資訊進行勾兌。資金流的勾兌能發現支付系統在銀行的帳戶資金實際發生的變動與應該發生的變動的差異，比如長款（銀行多結算給支付系統）和短款（銀行少結算給支付系統）。

說了這麼多，就出現來4個對賬檔案，支付系統資訊流檔案、支付系統資金流檔案、銀行資訊流檔案、銀行資金流檔案。業務對賬（勾兌）就是支付系統的資訊流檔案與銀行的資訊流檔案勾兌，資金對賬即支付系統的資金流檔案與銀行的資金流檔案勾兌。

1、資訊流勾對的差異處理

• 支付系統資訊流沒有，而銀行有的差異，可能是因為支付系統交易資料的丟失、銀行的掉單，如果是銀行的掉單，由支付公司的運營登入銀行網銀確認後，做補單處理，並將差異表中該記錄核銷。

• 支付系統資訊流有，而銀行沒有的差異，此種情況一般不會發生，因為支付系統所有的交易資料都是取銀行返回狀態的資料。

2、資金流勾對對差異處理

• 支付系統資金流沒有，而銀行有的差異。可能原因如下：1、銀行日切晚與支付系統核心賬務系統；2、支付系統賬務核心系統與其他系統間的掉單。一旦出現，則會出現長款（即銀行不應該結算而實際結算）的現象，對於因日切導致的差異，在第二天的對賬中系統會對平，其他原因的，需要技術排查。

• 支付系統資金流有，而銀行沒有的差異，可能是因為銀行日切早於支付系統的核心賬務系統，一旦出現，會出現短款（銀行應結算而實際未結算）的現象，銀行日切導致段差異，會在下一天與銀行的勾對中，將此筆差異勾對上，如果是非日切導致的原因，就需要找銀行追款了。

總結就是，業務對賬，即資訊流對賬，支付系統的交易流水與銀行的交易流水間核對，保障支付交易完整入賬。資金對賬，即資金流對賬，支付系統的入賬流水與銀行的結算流水間核對，保障銀行入賬流水與實際入賬資金的匹配。

在清結算部分，系統按照設定好的清結算規則自動將錢款結算給商戶。完善的運營會計體系幫助財務進行精細化核算，提高財務效率。與支付渠道自動進行對賬，確保賬務正確，在異常情況下能及時定位問題並處理。系統更是能對商戶進行個性化的費率配置或賬期配置，方便靈活。系統的價值不僅體現在支付清結算方面，同時更是提升了運營管理效率。支付清結算系統可以有效幫助運營、財務、開發以及管理人員。對於運營人員，系統可幫助處理平臺的運營工作，包括各類支付管理，商戶、會員管理，營銷活動的資料統計等，全面提高運營效率。針對財務人員，可以協助完成資金對賬、會計處理，出入款管理，賬務差錯處理等，大部分工作由系統自動處理，減少人工處理，提高資金處理效率。一套靈活便捷的配置後臺供開發人員快速調整系統以適應新的業務，並能方便對系統進行維護，如渠道接入、費率配置、賬期調整等，提高開發效率。系統提供資金流轉過程中各個環節的資料，能夠從各個維度進行核算和分析，形成對管理人員的決策支援，從而提高決策效率。

在支付系統中，支付閘道器和支付渠道的對接是最繁瑣重要的功能之一，其中支付閘道器是對外提供服務的介面，所有需要渠道支援的資金操作都需要透過閘道器分發到對應的渠道模組上。一旦定型，後續就很少，也很難調整。而支付渠道模組是接收閘道器的請求，呼叫渠道介面執行真正的資金操作。每個渠道的介面，傳輸方式都不盡相同，所以在這裡，支付閘道器相對於支付渠道模組的作用，類似設計模式中的wrapper，封裝各個渠道的差異，對閘道器呈現統一的介面。而閘道器的功能是為業務提供通用介面，一些和渠道互動的公共操作，也會放置到閘道器中。

支付系統對其他系統，特別是交易系統，提供的支付服務包括簽約，支付，退款，充值，轉帳，解約等。有些地方還會額外提供簽約並支付的介面，用於支援在支付過程中綁卡。 每個服務實現的流程也是基本類似，包括下單，取消訂單，退單，查單等操作。每個操作實現，都包括引數校驗，支付路由，生成訂單，風險評估，呼叫渠道服務，更新訂單和傳送訊息這7步，對於一些比較複雜的渠道服務，還會涉及到非同步同通知處理的步驟。

支付閘道器前置是對接業務系統，為其提供支付服務的模組。它是所有支付服務介面的整合前置，將不同支付渠道提供的介面透過統一的方式呈現給業務方。這樣接入方就只需要對接支付閘道器，增加和調整支付渠道對業務方是透明的。 支付閘道器前置的設計對整個支付系統的穩定性、功能、效能以及其他非功能性需求有著直接的影響。

在支付閘道器中需要完成大量的操作，為了保證效能，這些操作都儘量非同步化來處理。支付閘道器前置應保持穩定，儘量減少系統重啟等操作對業務方的影響。支付閘道器也避免不了升級和重啟。這可透過基於Nginx的LBS(Load Balance System)閘道器來解決。LBS在這裡有兩個作用： 一個是實現負載均衡，一個是隔離支付閘道器重啟對呼叫的影響。 支付閘道器也採用多臺機器分散式部署，重啟時，每個伺服器逐個啟動。某臺伺服器重啟時，首先從LBS系統中取消註冊，重啟完成後，再重新註冊到LBS上。這個過程對呼叫方是無感知的。

為了避免介面受攻擊，在安全上，還得要求業務方透過HTTPS來訪問介面，並提供防篡改機制。防篡改則透過介面引數簽名來處理。現在主流的簽名是對介面引數按照引數名稱排序後，做加密和雜湊，參考微信的簽名規範。

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

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

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

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

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

  03  路由選擇

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

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

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

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

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

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

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

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

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

每一筆交易都需要記錄流水，並登記到個人和機構的分戶賬戶上，統計和分析也需要根據交易流水來更新相關資料。 而個人和機構賬戶總額更新、交易流水記錄以及庫存的處理，更是需要事務處理機制的支援。 從效能角度， 可以弱化了事務處理的要求，採用訊息機制來非同步化和交易相關的資料處理。

• 在支付閘道器前置的主流程中，僅記錄交易流水，即將當前的請求儲存到資料庫中。

• 完成資料記錄後，傳送MQ出來，記賬、統計、分析，都是接收MQ來完成資料處理。

• 涉及到本地資金支付，比如錢包支付，會需要分散式事務處理，扣減賬號餘額，記賬，扣減庫存等，每個操作失敗，都要回滾。阿里有很不錯的分享，這裡不詳細描述。

• 當交易量上來後，需要考慮交易表的分表分庫的事情。分表分庫有兩個策略，按照流水號或者交易主體id來走。後者可以支援按使用者來獲取交易記錄。我們用的是前者。後者可以走elastic，確保資料庫專用。風控，信用和統計所需要的資料，透過MQ同步到歷史庫裡面。作為支付系統最有價值的資料，在儲存上做到專庫專用，無可厚非，畢竟儲存成本還是廉價的。

支付路由是一個複雜的話題。對支付系統來說，能支援的支付方式越多越好，不能由於支付方式的不支援斷了財路。現實中的支付方式多得難以置信。使用者隨時甩出一張你聽都沒聽說過的卡。如果一個銀行卡只有幾個使用者在用，那針對這個卡開發個對接有點得不嘗失。現在第三方支付的爆發，確實給開發支付系統省了不少事。但是公司不可能只對接一個第三方支付，如果這個渠道出問題了，或者鬧矛盾了，把連結給掐了，老闆還不欲哭無淚。總之，得對接多個渠道。對於交易量大的銀行，還得考慮直聯。

對於支付渠道，首先考慮的是接入哪些渠道。要對接的渠道按優先順序有：

• 第三方支付，對大部分應用來說，支付寶和微信支付都是必須的，一般來說，這兩者可以佔到90%以上的交易量。使用者不需要綁卡，授權後直接支付就行。各種平臺都支援，效能和穩定性都不錯。對於一些特殊業務，比如遊戲，企業支付，可以檢視一些專用的第三方支付平臺。

• 銀聯，它的存在，極大方便了和銀行的對接。和第三方支付主要不同在兩個地方一是需要綁卡，也就是使用者先把卡號，手機，身份證號提供出來。這一步會折損不少使用者。綁卡後，以後的支付操作就簡單了，使用者只需要輸入密碼就行。手機客戶端不需要像第三方支付那樣安裝SDK，都在伺服器端完成。當然，這是針對快捷支付。網銀支付還是挺麻煩的。銀聯接入也需要ADSS認證。

• 銀行：2018年2月9日銀監會公佈了最新權威數字：一共【4549家】開發性金融機構1家：國家開發銀行；政策性銀行2家：進出口銀行、農業發展銀行；5大國有銀行：工、建、農、中、交；郵儲銀行1家；全國性股份制商業銀行12家：招行、中信、興業、民生、浦發、光大、廣發、華夏、平安、浙商、渤海、恆豐；金融資產管理公司4家：信達、華融、長城、東方四大AMC；城商行134家；住房儲蓄銀行1家；民營銀行17家，如網商銀行；農商行1262家；農村合作銀行33家；農村信用社965家；村鎮銀行1562家；貸款公司13家；農村資金互助社48家；外資法人銀行39家；信託公司68家；金融租賃公司69家；企業集團財務公司247家；汽車金融公司25家；消費金融公司22家；貨幣經紀公司5家；其他金融機構14家。一般對接一個銀行預計有3周左右的工作量，大部分銀行需要專線接入，費用和頻寬有關，一年也得幾萬費用。不同銀行對接入環境有不同要求，這也是成本。

• 手機支付：比如蘋果的In-App支付， 三星支付、華為支付等， 這些支付僅針對特定的手機型號， 支援NFC等，根據業務需要也可以接入。

  總結

支付系統是一個繁雜的系統，其中涉及了各種錯綜複雜的業務流程，以上只是簡單介紹了支付系統我們能看見的一些問題和設計，還有後續的系統保障沒有寫出來，沒寫出來的才是關鍵部分，比如：支付系統監控（業務監控分類、渠道監控、商戶監控、賬戶監控）文章只是引子， 架構不是靜態的，而是動態演化的。只有能夠不斷應對環境變化的系統，才是有生命力的系統。所以即使你掌握了以上所有的業務細節，仍然需要演化式思維，在設計的同時，藉助反饋和進化的力量推動架構的持續演進。