Java生鮮電商平臺-商家支付系統與對帳系統架構實戰

Java生鮮電商平臺-商家支付系統與對帳系統架構實戰

 

說明：關於生鮮電商平臺，支付系統是鏈接消費者、商家（或平臺）和金融機構的橋樑，管理支付數據，調用第三方支付平臺接口，記錄支付信息（對應訂單號，支付金額等），金額對帳等功能，根據不一樣公司對於支付業務的定位不一樣大概有幾個階段：

第一階段：支付做爲一個（封閉）的、獨立的應用系統，爲各系統提供支付功能支持。通常來講，這個系統僅限於爲公司內部的業務提供支付支持，而且和業務緊密耦合。

第二階段：支付做爲一個開發的系統，爲公司內外部系統、各類業務提供支付服務，支付服務自己應該是和具體的業務解耦合。

      支付是電商系統中核心

 

 

咱們先來看一下用戶完成一次購物須要進行那些操做：

 

 

一般消費者在手機APP或者網站都會涉及到支付相關的業務場景，用戶只須要簡單點擊支付按鈕輸入支付密碼，就能夠完成整個支付過程，那麼我就和你們一塊兒來看看一個完整的支付系統有什麼功能組成和設計時須要考慮那些問題。

01

支付系統的做用

 

 

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

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

 

 

支付系統

一個支付系統須要由哪些功能模塊組成？

 

01

完整的支付系統包括以下功能：

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

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

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

帳戶管理: 渠道帳戶管理，支持共享帳戶（我的商戶）及自有帳戶。

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

對帳管理: 實現支付系統的交易數據與第三方支付渠道交易明細的自動覈對（一般T+1），確保交易數據的準確性和一致性。

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

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

02

核心流程

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

支付流程

 

 

支付流程說明

用戶在商城選購商品併發起支付請求；

商城將支付訂單經過B2C網關收款接口傳送至支付網關；

用戶選擇網銀支付及銀行，支付平臺將訂單轉送至指定銀行網關界面；

用戶支付完成，銀行處理結果並向平臺返回處理結果；

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

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

通常而言支付系統會給商戶設置有「可用餘額」帳戶、「待結算」帳戶；系統在接收到銀行返回支付成功信息會進行落地處理，一方面更改對應訂單狀態，另外一方面在商戶待結算帳戶記入一筆金額；該筆金額，系統會根據結算週期從待結算帳戶--->「可用餘額」帳戶。

退款流程說明

用戶在商戶平臺發起退款申請，商戶覈實退款信息及申請；

商戶登陸支付平臺帳戶/或者經過支付公司提供的退款接口向支付平臺發起退款；

支付系統會對退款信息校驗（退款訂單對應的原訂單是否支付成功？退款金額是否少於等於原訂單金額？），校驗商戶帳戶餘額是否充足等；校驗不經過，則沒法退款；

支付系統在商戶可用餘額帳戶扣除金額，並將退款訂單發送至銀行，銀行完成退款操做。注意：對於網關收款的訂單退款，各銀行要求不一，有些銀行提供的退款接口要求原訂單有效期在90或180天，有些銀行不提供退款接口；針對超期或者不支持接口退款的訂單，支付公司經過代付通道完成退款操做。

對於收單金額未結算，還在「待結算」帳戶的訂單，若是出現退款狀況，業務流程和上述流程差很少，只是從待結算帳戶進行扣款。

對帳流程

 

 

說明

        對帳，咱們通常稱爲勾兌，支付系統的對帳，包含着兩個層面：

支付系統內部間的對帳，支付系統通常是分佈式的，整個支付系統被拆分紅了多個子系統，如交易系統、帳戶系統、會計系統、帳戶系統，每一個子系統在處理各自的業務，系統間的對帳，就是以上系統的核對，用於修正內部系統的數據不一致。

支付系統與渠道的對帳，這裏的渠道泛指全部爲支付系統提供代收付業務的渠道，如：第三方支付公司、銀行、清算中心、網聯、銀聯等。

 

 

支付系統與渠道間的對帳

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

信息流勾對：即業務對帳／交易對帳，主要是就收單交易的支付信息與銀行提供的信息流文件進行勾兌。信息流的勾地能發現支付系統與銀行系統間的掉單、兩邊因爲系統間的緣由致使的同一筆交易支付金額不一致（可能性很小）或者支付狀態不一致。信息流勾兌通常用來恢復掉單數據，可經過補單或者具體系統問題排查解決。

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

說了這麼多，就出現來4個對帳文件，支付系統信息流文件、支付系統資金流文件、銀行信息流文件、銀行資金流文件。業務對帳（勾兌）就是支付系統的信息流文件與銀行的信息流文件勾兌，資金對帳即支付系統的資金流文件與銀行的資金流文件勾兌。

 

 

覈對的差別處理

一、信息流勾對的差別處理

支付系統信息流沒有，而銀行有的差別，多是由於支付系統交易數據的丟失、銀行的掉單，若是是銀行的掉單，由支付公司的運營登陸銀行網銀確認後，作補單處理，並將差別表中該記錄覈銷。

支付系統信息流有，而銀行沒有的差別，此種狀況通常不會發生，由於支付系統全部的交易數據都是取銀行返回狀態的數據。

二、資金流勾對對差別處理

支付系統資金流沒有，而銀行有的差別。可能緣由以下：一、銀行日切晚與支付系統核心帳務系統；二、支付系統帳務核心系統與其餘系統間的掉單。一旦出現，則會出現長款（即銀行不該該結算而實際結算）的現象，對於因日切致使的差別，在次日的對帳中系統會對平，其餘緣由的，須要技術排查。

支付系統資金流有，而銀行沒有的差別，多是由於銀行日切早於支付系統的核心帳務系統，一旦出現，會出現短款（銀行應結算而實際未結算）的現象，銀行日切致使段差別，會在下一天與銀行的勾對中，將此筆差別勾對上，若是是非日切致使的緣由，就須要找銀行追款了。

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

結算流程

 

 

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

03

關鍵表設計

 

 

04

支付系統要點

在支付系統中，支付網關和支付渠道的對接是最繁瑣重要的功能之一，其中支付網關是對外提供服務的接口，全部須要渠道支持的資金操做都須要經過網關分發到對應的渠道模塊上。一旦定型，後續就不多，也很難調整。而支付渠道模塊是接收網關的請求，調用渠道接口執行真正的資金操做。每一個渠道的接口，傳輸方式都不盡相同，因此在這裏，支付網關相對於支付渠道模塊的做用，相似設計模式中的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來走。後者能夠支持按用戶來獲取交易記錄。咱們用的是前者。後者能夠走elasticSearch，確保數據庫專用。風控，信用和統計所須要的數據，經過MQ同步到歷史庫裏面。做爲支付系統最有價值的數據，在存儲上作到專庫專用，無可厚非，畢竟存儲成本仍是廉價的。

10

支付路由

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

11

渠道接入

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

支付寶&微信，對大部分應用來講，支付寶和微信支付都是必須的，通常來講，這二者能夠佔到90%以上的交易量。用戶不須要綁卡，受權後直接支付就行。各類平臺都支持，性能和穩定性都不錯。由於支付寶和財付通資金流充足，他們在每一家銀行都有大量的備付金，在後臺交易有別於其餘第三方平臺。

第三方平臺，在對接中和支付寶&微信同樣方便快捷。

銀聯，它的存在，極大方便了和銀行的對接。和第三方支付主要不一樣在兩個地方一是須要綁卡，也就是用戶先把卡號，手機，身份證號提供出來，這一步會折損很多用戶。綁卡後，之後的支付操做就簡單了，用戶只須要輸入密碼就行。手機客戶端不須要像第三方支付那樣安裝SDK，都在服務器端完成。固然，這是針對快捷支付，網銀支付仍是挺麻煩的，

銀行：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等，根據業務須要也能夠接入。

網聯：2017年8月，央行支付結算司印發《中國人民銀行支付結算司關於將非銀行支付機構網絡支付業務由直連模式遷移至網聯平臺處理的通知》。通知表示，自2018年6月30日起，支付機構受理的涉及銀行帳戶的網絡支付業務所有經過網聯平臺處理。

總結

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

 

聯繫QQ：137071249

QQ羣：793305035