支付系統

概述

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

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

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

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

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

01.完整的支付系統包括如下功能：

應用管理: 同時支援公司多個業務系統對接。 商戶管理: 支援商戶入駐，商戶需要向平台方提供相關的資料備案。 管道管理: 支援微信、支付寶、銀聯、京東支付等多種管道。 賬戶管理: 管道賬戶管理，支援共享賬戶（個人商戶）及自有賬戶。 支付交易: 生成預支付訂單、提供退款服務。 對賬管理: 實作支付系統的交易資料與第三方支付管道交易明細的自動核對（通常T+1），確定交易資料的準确性和一緻性。 清算管理: 計算收款交易中商戶的應收與支付系統收益。 結算管理: 根據清算結果，将資金劃撥至商戶對應的資金帳戶中。

02.核心流程

03.支付流程說明

使用者在商城選購商品并發起支付請求； 商城将支付訂單通過B2C網關收款接口傳送至支付網關； 使用者選擇網銀支付及銀行，支付平台将訂單轉送至指定銀行網關界面； 使用者支付完成，銀行處理結果并向平台傳回處理結果； 支付平台接收處理結果，落地處理并向商戶傳回結果； 商城接收到支付公司傳回結果，落地處理（更改訂單狀态）并通知使用者。 一般而言支付系統會給商戶設定有“可用餘額”賬戶、“待結算”賬戶；系統在接收到銀行傳回支付成功資訊會進行落地處理，一方面更改對應訂單狀态，另一方面在商戶待結算賬戶記入一筆金額；該筆金額，系統會根據結算周期從待結算賬戶--->“可用餘額”賬戶。

04.退款流程說明

使用者在商戶平台發起退款申請，商戶核實退款資訊及申請； 商戶登入支付平台賬戶/或者通過支付公司提供的退款接口向支付平台發起退款； 支付系統會對退款資訊校驗（退款訂單對應的原訂單是否支付成功？退款金額是否少于等于原訂單金額？），校驗商戶賬戶餘額是否充足等；校驗不通過，則無法退款； 支付系統在商戶可用餘額賬戶扣除金額，并将退款訂單發送至銀行，銀行完成退款操作。注意：對于網關收款的訂單退款，各銀行要求不一，有些銀行提供的退款接口要求原訂單有效期在90或180天，有些銀行不提供退款接口；針對超期或者不支援接口退款的訂單，支付公司通過代付通道完成退款操作。 對于收單金額未結算，還在“待結算”賬戶的訂單，如果出現退款情況，業務流程和上述流程差不多，隻是從待結算賬戶進行扣款。

05.支付系統要點

在支付系統中，支付網關和支付管道的對接是最繁瑣重要的功能之一，其中支付網關是對外提供服務的接口，所有需要管道支援的資金操作都需要通過網關分發到對應的管道子產品上。一旦定型，後續就很少，也很難調整。而支付管道子產品是接收網關的請求，調用管道接口執行真正的資金操作。每個管道的接口，傳輸方式都不盡相同，是以在這裡，支付網關相對于支付管道子產品的作用，類似設計模式中的wrapper，封裝各個管道的差異，對網關呈現統一的接口。而網關的功能是為業務提供通用接口，一些和管道互動的公共操作，也會放置到網關中。 支付系統對其他系統，特别是交易系統，提供的支付服務包括簽約，支付，退款，充值，轉帳，解約等。有些地方還會額外提供簽約并支付的接口，用于支援在支付過程中綁卡。 每個服務實作的流程也是基本類似，包括下單，取消訂單，退單，查單等操作。每個操作實作，都包括參數校驗，支付路由，生成訂單，風險評估，調用管道服務，更新訂單和發送消息這7步，對于一些比較複雜的管道服務，還會涉及到異步同通知處理的步驟。 01 網關前置 支付網關前置是對接業務系統，為其提供支付服務的子產品。它是所有支付服務接口的內建前置，将不同支付管道提供的接口通過統一的方式呈現給業務方。這樣接入方就隻需要對接支付網關，增加和調整支付管道對業務方是透明的。 支付網關前置的設計對整個支付系統的穩定性、功能、性能以及其他非功能性需求有着直接的影響。 在支付網關中需要完成大量的操作，為了保證性能，這些操作都盡量異步化來處理。支付網關前置應保持穩定，盡量減少系統重新開機等操作對業務方的影響。支付網關也避免不了更新和重新開機。這可通過基于Nginx的LBS(Load Balance System)網關來解決。LBS在這裡有兩個作用： 一個是實作負載均衡，一個是隔離支付網關重新開機對調用的影響。 支付網關也采用多台機器分布式部署，重新開機時，每個伺服器逐個啟動。某台伺服器重新開機時，首先從LBS系統中取消注冊，重新開機完成後，再重新注冊到LBS上。這個過程對調用方是無感覺的。 為了避免接口受攻擊，在安全上，還得要求業務方通過HTTPS來通路接口，并提供防篡改機制。防篡改則通過接口參數簽名來處理。現在主流的簽名是對接口參數按照參數名稱排序後，做加密和散列，參考微信的簽名規範。 02 參數校驗 所有的支付操作，都需要對輸入執行參數校驗，避免接口受到攻擊。 驗證輸入參數中各字段的有效性驗證，比如使用者ID,商戶ID,價格，傳回位址等參數。 驗證賬戶狀态。交易主體、交易對手等賬戶的狀态是處于可交易的狀态。 驗證訂單：如果涉及到預單，還需要驗證訂單号的有效性，訂單狀态是未支付。為了避免使用者緩存某個URL位址，還需要校驗下單時間和支付時間是否超過預定的間隔。 驗證簽名。簽名也是為了防止支付接口被僞造。 一般簽名是使用分發給商戶的key來對輸入參數拼接成的字元串做MD5 Hash或者RSA加密，然後作為一個參數随其他參數一起送出到伺服器端。 03 路由選擇 根據使用者選擇的支付方式确定用來完成該操作的合适的支付管道。使用者指定的支付方式不一定是最終的執行支付的管道。比如使用者選擇通過工行信用卡來執行支付，但是我們沒有實作和工行的對接，而是可以通過第三方支付，比如支付寶、微信支付、易寶支付，或者銀聯來完成。那如何選擇合适的支付管道，就通過支付路由來實作。支付路由會綜合考慮收費、管道的可用性等因素來選擇最優方案 04 風險評估 檢查本次交易是否有風險。風控接口傳回三種結果：阻斷交易、增強驗證和放行交易。 阻斷交易，說明該交易是高風險的，需要終止，不執行第5個步驟； 增強驗證，說明該交易有一定的風險，需要确認下是不是使用者本人在操作。這可以通過發送短信驗證碼或者其他可以驗證使用者身份的方式來做校驗，驗證通過後，可以繼續執行該交易。 放行交易，即本次交易是安全的，可以繼續往下走。 05 發送消息 通過消息來通知相關系統關于訂單的變更。風控，信用BI等，都需要依賴這資料做準實時計算。 06 更新訂單 對于同步傳回的結果，需要在主線程中更新訂單的狀态，标記是支付成功還是失敗。對于異步傳回的管道，需要在異步程式中處理。 07 異步通知 其中涉及到調用遠端接口，其延遲不可控。如果調用方一直阻塞等待，很容易逾時。引入異步通知機制，可以讓調用方在主線程中盡快傳回，通過異步線程來得到支付結果。對于通過異步來擷取支付結果的管道接口，也需要對應的在異步通知中将結果傳回給調用方。 異步通知需要調用方提供一個回調位址，一般以http或者https的方式。這就有技術風險，如果調用失敗，還需要重試。而重試不能過于頻繁，需要逐漸拉大每一次重試的時間間隔。 在異步處理程式中，訂單根據處理結果變更狀态後，也要發消息通知相關系統。 08 生成交易訂單 将訂單資訊持久化到資料庫中。當通路壓力大的時候，資料庫寫入會成為一個瓶頸。 09 交易流水和記賬 每一筆交易都需要記錄流水，并登記到個人和機構的分戶賬戶上，統計和分析也需要根據交易流水來更新相關資料。 而個人和機構賬戶總額更新、交易流水記錄以及庫存的處理，更是需要事務處理機制的支援。 從性能角度， 可以弱化了事務處理的要求，采用消息機制來異步化和交易相關的資料處理。 在支付網關前置的主流程中，僅記錄交易流水，即将目前的請求儲存到資料庫中。 完成資料記錄後，發送MQ出來，記賬、統計、分析，都是接收MQ來完成資料處理。 涉及到本地資金支付，比如錢包支付，會需要分布式事務處理，扣減賬号餘額，記賬，扣減庫存等，每個操作失敗，都要復原。阿裡有很不錯的分享，這裡不較長的描述。 當交易量上來後，需要考慮交易表的分表分庫的事情。分表分庫有兩個政策，按照流水号或者交易主體id來走。後者可以支援按使用者來擷取交易記錄。我們用的是前者。後者可以走elastic，確定資料庫專用。風控，信用和統計所需要的資料，通過MQ同步到曆史庫裡面。作為支付系統最有價值的資料，在存儲上做到專庫專用，無可厚非，畢竟存儲成本還是廉價的。 10 支付路由 支付路由是一個複雜的話題。對支付系統來說，能支援的支付方式越多越好，不能由于支付方式的不支援斷了财路。現實中的支付方式多得難以置信。使用者随時甩出一張你聽都沒聽說過的卡。如果一個銀行卡隻有幾個使用者在用，那針對這個卡開發個對接有點得不嘗失。現在第三方支付的爆發，确實給開發支付系統省了不少事。但是公司不可能隻對接一個第三方支付，如果這個管道出問題了，或者鬧沖突了，把連結給掐了，老闆還不欲哭無淚。總之，得對接多個管道。對于交易量大的銀行，還得考慮直聯。 11 管道接入 對于支付管道，首先考慮的是接入哪些管道。要對接的管道按優先級有： 第三方支付，對大部分應用來說，支付寶和微信支付都是必須的，一般來說，這兩者可以占到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等，根據業務需要也可以接入。

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