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

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

上一篇分析了聚合支付為什么能做，本篇開(kāi)始講講聚合支付系統(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)域模型語(yǔ)言來(lái)描述聚合支付系統(tǒng)的分析設(shè)計(jì)。盡管如此，但建模的思路的做法依然重要。

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

系統(tǒng)功能

上一篇中介紹過(guò)，聚合支付是為商戶提供支付“一站式”的服務(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í)際支付中存在部分退款的需求（比如購(gòu)買兩件東西有一件退款）

支付流程

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

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

比如Ping++主頁(yè)上標(biāo)語(yǔ)的，“七行代碼接入聚合支付”。 這看起來(lái)非常有吸引力。

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

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

需要先授權(quán)再支付，主要是因?yàn)樯唐酚嗁?gòu)的界面（由商戶提供）與支付操作界面（由支付機(jī)構(gòu)提供）不屬于同個(gè)界面，或者不在同個(gè)APP中，甚至不在同一臺(tái)設(shè)備上。

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

與需要授權(quán)的原因相反，無(wú)需授權(quán)操作，是因?yàn)椴恍枰诓煌缑嫔蟻?lái)回跳轉(zhuǎn)。線下購(gòu)物通常是如此。

查詢與退款流程

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

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

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

對(duì)賬模式

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

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

結(jié)算賬戶模型

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

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

為了保證在銀行系統(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)：

• 由于可能存在分潤(rù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)域的開(kāi)發(fā)人員進(jìn)行設(shè)計(jì)和開(kāi)發(fā)了。

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

與此同時(shí)，還要注意輸出模型要可落地。例如，以上的分析夾雜了一些面向?qū)ο蚍治龅氖址?，因此不適合采非面向?qū)ο蟮恼Z(yǔ)言來(lái)實(shí)現(xiàn)。

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