從零打造聚合支付系統(tǒng) 系列文章鏈接如下

從零打造聚合支付系統(tǒng)：一煎殷、淺談聚合支付的核心價(jià)值
從零打造聚合支付系統(tǒng)：二屯伞、建立領(lǐng)域模型
從零打造聚合支付系統(tǒng)：三、應(yīng)用微服務(wù)架構(gòu)
從零打造聚合支付系統(tǒng)：四豪直、打通任督二脈

上一篇分析了聚合支付為什么能做劣摇，本篇開始講講聚合支付系統(tǒng)怎么入手。

前言

在針對(duì)特定業(yè)務(wù)進(jìn)行分析設(shè)計(jì)時(shí)弓乙，首要的事情便是建立業(yè)務(wù)模型（又稱領(lǐng)域模型）末融。

領(lǐng)域模型，通常是業(yè)務(wù)人員與軟件工程師溝通的橋梁暇韧。

為了避免陷入專業(yè)名詞的泥沼中勾习，我并不打算運(yùn)用嚴(yán)格的領(lǐng)域模型語言來描述聚合支付系統(tǒng)的分析設(shè)計(jì)。盡管如此懈玻，但建模的思路的做法依然重要巧婶。

關(guān)于領(lǐng)域建模的重要性及基本原則，Eric Evans大神在《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)——軟件核心復(fù)雜性應(yīng)對(duì)之道》一書中有詳細(xì)闡述涂乌，有興趣的小伙伴可以閱讀的第一部分粹舵。

系統(tǒng)功能

上一篇中介紹過，聚合支付是為商戶提供支付“一站式”的服務(wù)骂倘。

聚合支付系統(tǒng)位于商戶與支付機(jī)構(gòu)或銀行之間，收斂商戶與支付機(jī)構(gòu)及銀行間的一切交互巴席。

一個(gè)聚合支付系統(tǒng)历涝，首先要具備支付、查詢漾唉、退款三個(gè)基本功能荧库，對(duì)應(yīng)用戶使用支付的三種基本操作；其次赵刑，為了確保各方交易記錄一致分衫，通常要以天為單位對(duì)賬，實(shí)現(xiàn)業(yè)務(wù)閉環(huán)般此；最后蚪战，根據(jù)對(duì)賬結(jié)果牵现，定期完成資金結(jié)算。

模塊劃分

建立一個(gè)最小的聚合支付系統(tǒng)邀桑，至少應(yīng)具備以下三個(gè)模塊（或子系統(tǒng)）：

• 核心支付模塊：完成支付瞎疼、查詢、退款三個(gè)基本功能壁畸，此三個(gè)功能屬于實(shí)時(shí)調(diào)用贼急，需要立即返回結(jié)果。每次調(diào)用傳遞的信息包含一個(gè)訂單捏萍。
• 對(duì)賬結(jié)算模塊：對(duì)賬是每天定時(shí)執(zhí)行太抓，需要將前一天的交易批量下載或上傳，并進(jìn)行比對(duì)令杈；清分結(jié)算則是匯總對(duì)賬結(jié)果走敌，并將結(jié)果提交給會(huì)計(jì)系統(tǒng)或銀行。
• 商戶管理模塊：商戶需要在聚合支付系統(tǒng)注冊(cè)这揣，需要申請(qǐng)接入悔常，需要查詢交易，需要下載配置信息等必要功能给赞。因此机打，需要此模塊實(shí)現(xiàn)與商戶間的交互，傳遞一些必要的信息片迅，這是三個(gè)模塊中唯一一個(gè)需要用戶界面的模塊残邀。

核心支付模型

接口信息

由上面圖可以看出，支付和退款是由商戶主動(dòng)發(fā)起的柑蛇。商戶調(diào)用接口時(shí)芥挣，實(shí)際上發(fā)送的是訂單信息（涉及支付的信息），聚合支付系統(tǒng)為其生成相應(yīng)的支付信息和退款信息耻台。

• 訂單信息：商戶ID空免，訂單號(hào)，商品名稱盆耽，商品描述蹋砚，訂單金額，支付方式摄杂，回調(diào)地址坝咐；
• 支付信息：支付流水號(hào)，支付金額析恢，支付結(jié)果墨坚，結(jié)算日期；

• 退款信息：退款流水號(hào)映挂，退款金額泽篮，退款結(jié)果盗尸，結(jié)算日期；

  
  

退款信息中包含退款金額咪辱，是由于實(shí)際支付中存在部分退款的需求（比如購買兩件東西有一件退款）

支付流程

上一篇中介紹過振劳，聚合支付首要解決是支付的“碎片化”的市場(chǎng)痛點(diǎn)。

為了吸引更多的商戶接入油狂，努力讓商戶接入變得更簡(jiǎn)單历恐。做一個(gè)產(chǎn)品歷來有Less Is More的設(shè)計(jì)原則。所以在設(shè)計(jì)支付流程時(shí)专筷，應(yīng)盡可能讓流程看起來簡(jiǎn)單易懂弱贼。

比如Ping++主頁上標(biāo)語的，“七行代碼接入聚合支付”磷蛹。 這看起來非常有吸引力吮旅。

通過仔細(xì)研究，市面上常用的支付手段味咳，其背后的流程庇勃，只有兩種。

• 第一種我稱之為授權(quán)支付：用戶首先需要通過商戶后臺(tái)到支付機(jī)構(gòu)申請(qǐng)支付授權(quán)槽驶，然后使用授權(quán)碼（通常是一個(gè)類似于Token的串）調(diào)起支付功能责嚷，最后在輸入密碼完成支付。這種支付方式流程如下掂铐，常見的APP支付罕拂、PC網(wǎng)頁支付、手機(jī)掃碼支付等支付方式都適用此流程全陨。

需要先授權(quán)再支付爆班，主要是因?yàn)樯唐酚嗁彽慕缑妫ㄓ缮虘籼峁┡c支付操作界面（由支付機(jī)構(gòu)提供）不屬于同個(gè)界面，或者不在同個(gè)APP中辱姨，甚至不在同一臺(tái)設(shè)備上柿菩。

• 另一種我稱之為直接支付：用戶將帶有自己身份信息的一個(gè)信息串，通過商戶發(fā)送到支付機(jī)構(gòu)雨涛，商戶在發(fā)送過程中加上訂單和支付信息枢舶，直接完成支付。常見的線下購物刷卡支付镜悉，掃碼槍掃條碼支付都適用此流程。

與需要授權(quán)的原因相反医瘫，無需授權(quán)操作侣肄，是因?yàn)椴恍枰诓煌缑嫔蟻砘靥D(zhuǎn)。線下購物通常是如此醇份。

查詢與退款流程

查詢與退款由于完全是后臺(tái)請(qǐng)求稼锅，因此流程相對(duì)來說則簡(jiǎn)單些吼具。

通常來說退款并不能立即確定成功或失敗，因此大部分機(jī)構(gòu)都是采用異步通知的方式告知退款結(jié)果矩距。

對(duì)賬結(jié)算模型

對(duì)賬模式

對(duì)賬模塊會(huì)每天定時(shí)將前一天的多方交易記錄下載拗盒，并進(jìn)行比對(duì)，以確保各方記錄一致锥债。

聚合支付系統(tǒng)對(duì)賬有兩種模式陡蝇，一種是由商戶主動(dòng)上傳記錄的，另一種是商戶不上傳交易記錄哮肚。其差別如下登夫。

結(jié)算賬戶模型

根據(jù)監(jiān)管部門要求涣楷，聚合支付通常要避免“二清”問題。即不允許聚合支付機(jī)構(gòu)在沒有相應(yīng)資質(zhì)的前提下抗碰，先代商戶收錢狮斗，再將分給各個(gè)商戶。

資金結(jié)算要交給有相應(yīng)資質(zhì)的機(jī)構(gòu)來完成改含，一般會(huì)委托給銀行來完成情龄。

為了保證在銀行系統(tǒng)中各個(gè)賬戶中的結(jié)算金額可靠，遇到不一致時(shí)可追溯錯(cuò)誤捍壤，因此骤视，需要在對(duì)賬結(jié)算模塊內(nèi)建立一套虛擬賬戶體系，與銀行系統(tǒng)中的賬戶一一對(duì)應(yīng)（做同步）鹃觉。

關(guān)于如何建闕金融賬戶體系专酗，可以參考此篇文章《金融結(jié)算系統(tǒng)的基礎(chǔ)業(yè)務(wù)之賬戶體系結(jié)構(gòu)分析》

由于聚合支付系統(tǒng)并不是真的要建立一套完整的賬戶體系，其目的只是與外部系統(tǒng)的賬戶保持同步而己盗扇，因此祷肯，可將賬戶體系精簡(jiǎn)如下。

圖中有如下要點(diǎn)：

• 由于可能存在分潤疗隶，一筆交易可能按規(guī)則記入多個(gè)賬戶佑笋，因此，交易記錄（相當(dāng)于憑證）與賬戶明細(xì)（收支）是一對(duì)多的關(guān)系斑鼻。
• 余額由于有期初與期末的概念蒋纬，如果每期做一條記錄，則一個(gè)賬戶根據(jù)時(shí)間不同可能有多條余額記錄，因此賬戶與余額也是一對(duì)多的關(guān)系蜀备。

總結(jié)

至此关摇，搭建一個(gè)最小聚合支付系統(tǒng)的領(lǐng)域模型已經(jīng)基本完成，以上的知識(shí)己經(jīng)足夠一個(gè)從未涉足支付領(lǐng)域的開發(fā)人員進(jìn)行設(shè)計(jì)和開發(fā)了碾阁。

領(lǐng)域建模的精髓在于输虱，模型本身是發(fā)展的，隨著對(duì)業(yè)務(wù)理解的深入和業(yè)務(wù)需求的變化脂凶， 模型也會(huì)隨之進(jìn)行變更宪睹，逐漸變的完善。

與此同時(shí)艰猬，還要注意輸出模型要可落地横堡。例如，以上的分析夾雜了一些面向?qū)ο蚍治龅氖址ü谔遥虼瞬贿m合采非面向?qū)ο蟮恼Z言來實(shí)現(xiàn)命贴。

在后面的文章中，我會(huì)詳細(xì)地描述如何應(yīng)用微服務(wù)架構(gòu)將系統(tǒng)一步步實(shí)現(xiàn)食听，以及討論為什么要使用微服務(wù)架構(gòu)胸蛛。請(qǐng)看下文。