国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

面對五花八門的支付架構(gòu)圖，是否看得云里霧里？本文為大家總結(jié)了一套清晰的支付架構(gòu)圖，讓你快速掌握一套支付體系是怎么運轉(zhuǎn)的，一起來看看吧。

你是否因為工作中需要畫支付架構(gòu)圖，為怎么清晰的表達(dá)而煩惱呢？你是否對五花八門的支付架構(gòu)圖看的云里霧里？今天我給大家介紹一套簡單又清晰的支付架構(gòu)，讓你快速掌握一套支付體系是怎么運轉(zhuǎn)的。【老規(guī)矩，只看精華的同學(xué)直接翻到最后第四章看總結(jié)】

01 支付系統(tǒng)介紹

1.1 什么是支付系統(tǒng)

能夠?qū)崿F(xiàn)貨幣交換的軟件系統(tǒng)都可以被稱為支付系統(tǒng)，而我們這里介紹的是伴隨著電商業(yè)務(wù)而興起第三方支付機構(gòu)所使用的“收單支付系統(tǒng)”。它和傳統(tǒng)的“信匯、電匯、銀企直聯(lián)、商業(yè)匯票”等支付結(jié)算系統(tǒng)最大的區(qū)別就是“買賣交易和資金轉(zhuǎn)移都可以在線上完成”。

這種交易方式極大地提升了商品銷售的效率。他也是電商業(yè)務(wù)和平臺經(jīng)濟能興起核心基礎(chǔ)設(shè)施，因為順暢的收錢是任何商業(yè)模式成功的前提。

圖1：支付系統(tǒng)是電商經(jīng)濟的核心基礎(chǔ)設(shè)施

1.2 支付系統(tǒng)分層

支付系統(tǒng)的定位就是根據(jù)客戶商業(yè)訂單完成跨行的收付款，將資金最終轉(zhuǎn)移到收款人的賬戶里。因此整套系統(tǒng)按照“一個系統(tǒng)、兩個通道、三層架構(gòu)”來進(jìn)行劃分。

圖2：支付系統(tǒng)架構(gòu)分層

1.2.1 一個系統(tǒng)

為了實現(xiàn)買賣雙方的跨行收付款，支付平臺會把支付產(chǎn)品包裝成接口或支付頁面提供給客戶來使用，并通過系統(tǒng)的層層轉(zhuǎn)換來實現(xiàn)資金的跨行轉(zhuǎn)移到收款人賬戶里。因此，一個最簡單的支付系統(tǒng)由如下八個模塊組成。

圖3：支付中臺主要模塊

1.2.2 兩個通道

1）網(wǎng)關(guān)/終端（接入端）

它是支付系統(tǒng)的“接入端”，將支付產(chǎn)品通過接口、頁面、終端設(shè)備的形式提供給用戶進(jìn)行支付、開戶和認(rèn)證。同時訪問網(wǎng)關(guān)或者使用終端設(shè)備還要安裝“密鑰和證書”，以此來保證你支付的安全。

2）渠道（接出端）

它是支付系統(tǒng)的“接出端”，他負(fù)責(zé)對接三方、銀行、清算機構(gòu)的支付接口，把他轉(zhuǎn)換成標(biāo)準(zhǔn)支付產(chǎn)品提供給上層的產(chǎn)品使用。如果選擇對接了多家銀行相同的支付產(chǎn)品，他能根據(jù)“訂單、渠道、穩(wěn)定性”進(jìn)行動態(tài)的路由選擇。

1.2.3 三層架構(gòu)

1）產(chǎn)品層（深度支付包裝）

產(chǎn)品層是為了適應(yīng)不同場景的支付需求，把基礎(chǔ)支付產(chǎn)品包裝面成向不同場景的銷售產(chǎn)品，滿足各行業(yè)各對于支付的特殊需求。例如面向個人用戶的B2C、C2C支付，面向企業(yè)的B2B支付，以及面向金融機構(gòu)的消金支付等。因此產(chǎn)品層是對交易層的深度包裝，讓他更加適應(yīng)不同的場景的需求，方便用戶使用。

2）交易層（基礎(chǔ)支付包裝）

為使用者提供基礎(chǔ)的支付產(chǎn)品，包括充值、提現(xiàn)、收款、分賬、付款等支付服務(wù)，滿足多場景對支付的基本需求。他主要包括了收銀臺、交易系統(tǒng)、客戶系統(tǒng)三部分。

• 收銀臺：通過頁面形式讓用戶順暢的完成支付操作，無需關(guān)注支付的技術(shù)實現(xiàn)。
• 交易系統(tǒng)：交易層的“流程調(diào)度者”，它對業(yè)務(wù)場景提供方便的接口或頁面操作，讓使用者無需關(guān)注底層的復(fù)雜的處理邏輯，專注業(yè)務(wù)場景的支付需求的實現(xiàn)。
• 客戶系統(tǒng)：為用戶提供所需要APP或網(wǎng)站，讓用戶可以對自己的交易、賬戶、資金進(jìn)行管理。

3）核心層（原始支付服務(wù)）

“核心層”又叫“支付層”，是為交易層提供原始的賬務(wù)、渠道、清結(jié)算服務(wù)，他專注于內(nèi)部賬務(wù)邏輯和支付渠道的處理邏輯，并且核心層也代表了一個系統(tǒng)的核心能力，他決定了上層產(chǎn)品是否好用、好賣、好管（人們常說產(chǎn)品看著挺好，用著很差，一般是核心能力不足造成的）。

• 支付引擎：核心層的“流程調(diào)度者”，為交易系統(tǒng)提供賬務(wù)處理、渠道調(diào)用、對賬明細(xì)等處理。讓交易系統(tǒng)無需關(guān)注底層邏輯的使用，支付引擎全權(quán)負(fù)責(zé)了后端和事后的管理。
• 賬戶系統(tǒng)：持牌機構(gòu)由于要做清結(jié)算，因此會把會計賬務(wù)和資金賬戶放在一起進(jìn)行賬務(wù)登記。他在支付引擎的驅(qū)動下，完成記賬、核算等賬務(wù)操作。
• 清結(jié)算：負(fù)責(zé)與渠道的對賬和客戶資金結(jié)算的處理，也是對資金管理的核心模塊。

02 支付業(yè)務(wù)架構(gòu)

圖4：支付業(yè)務(wù)架構(gòu)

業(yè)務(wù)架：構(gòu)顧名思義就是面向業(yè)務(wù)場景提供的架構(gòu)圖，他主要目的就是讓非技術(shù)人員了解系統(tǒng)具有哪些能力，以及系統(tǒng)提供產(chǎn)品和管理能力是否符合期望。業(yè)務(wù)架構(gòu)一般分為兩張圖“架構(gòu)圖、流程圖”，架構(gòu)圖負(fù)責(zé)展示系統(tǒng)的功能結(jié)構(gòu)，流程圖負(fù)責(zé)展示功能之間關(guān)系。

從支付的業(yè)務(wù)架構(gòu)我們可以看到，相對于分層的架構(gòu)圖，實際的業(yè)務(wù)架構(gòu)有許多的輔助系統(tǒng)來支持支付業(yè)務(wù)的運行。不過支付業(yè)務(wù)核心閉環(huán)的還是支付服務(wù)中的8個模塊當(dāng)主角，下面我們來分別介紹下。

2.1 收銀系統(tǒng)

收銀臺系統(tǒng)就是以頁面的形式提供給用戶進(jìn)行收款操作，同時它也會面向不同的支付終端提供各種類型的收銀臺，我們按終端類型把它們分為五類。

1）H5收銀臺：這種是適配移動終端類型最多的收銀臺，由于它能夠?qū)崿F(xiàn)快捷、公眾號、H5、錢包、數(shù)幣等多種支付方式的聚合，因此也叫聚合收銀臺。支付方式能夠根據(jù)參數(shù)進(jìn)行展示和折疊，頁面樣式也支持自定義。

2）SDK收銀臺：這種是針對APP場景提供收銀臺，支持的支付方式與H5相同，不過體驗?zāi)軌蜃龅母?，還能支持生物識別。當(dāng)然這種支付方式需要和客戶的APP進(jìn)行集成，使用起來比較復(fù)雜。

3）小程序收銀臺：這種主要是適配小程序場景，例如微信、支付寶、數(shù)幣等，但是由于小程序依賴于APP的運行環(huán)境，因此各種小程序支付方式要獨立分開。

4）WEB收銀臺：這種主要適配PC場景，分為個人網(wǎng)銀和企業(yè)網(wǎng)銀兩類，并且支付的額度比較高，相對安全性也有所提高，需要通過證書、UKey等方式進(jìn)行支付。由于現(xiàn)在普遍使用移動端進(jìn)行支付因此網(wǎng)銀支付的用在企業(yè)場景會比較多。

5）聚合收款碼：這類分為兩種，一種是碼牌他是基于收款賬戶包裝成一個收款二維碼，然后根據(jù)用戶掃碼的APP類型來適配調(diào)用微信還是支付寶的收銀臺，這種支付方式需要用戶自己手動輸入金額。另一種是商品碼，這種就是根據(jù)用戶購買的商品訂單的金額生成一個聚合碼，根據(jù)用戶APP類型來適配不同的渠道支付產(chǎn)品。這種支付方式用戶不需要輸入金額直接可以進(jìn)行支付。收銀臺的形式有很多種了，主要還是看產(chǎn)品經(jīng)理對于渠道支付產(chǎn)品特性的了解來包裝出多種多樣的形式。

2.2 交易系統(tǒng)

通過前面的介紹我們知道，交易系統(tǒng)是面向支付場景和用戶提供的服務(wù)，因此他主要職責(zé)是處理業(yè)務(wù)場景復(fù)雜多變的支付處理需求。交易系統(tǒng)在交易層扮演以下角色：

圖5：交易系統(tǒng)核心能力

1）產(chǎn)品的提供者交易系統(tǒng)負(fù)責(zé)給外部使用收銀臺，收款、付款、余額支付等交易方式，并且根據(jù)不同的場景提供擔(dān)保交易、合單支付、組合支付等分賬交易把資金分給交易的參與方。因此我們使用的支付產(chǎn)品其實都是交易系統(tǒng)提供的服務(wù)。

2）流程的調(diào)度者交易系統(tǒng)是處理客戶請求的流程調(diào)度者，他根據(jù)客戶提交的支付訂單進(jìn)按照流程的先后順序調(diào)用收銀臺、客戶系統(tǒng)、支付引擎來完成支付處理。

2.3 客戶系統(tǒng)

顧名思義是為客戶提供服務(wù)的，因此他對內(nèi)對外提供的功能會比較多，他主要會是面向客戶各種使用和登錄的入口來提供服務(wù)的。

1）服務(wù)端：服務(wù)端就是通過接口或者頁面向客戶提供服務(wù)，因此他是一種開放能力?？梢酝ㄟ^客戶或者服務(wù)商以接口對接的形式，將客戶服務(wù)嵌入到外部平臺的App、網(wǎng)站、小程序中，讓外部平臺具可以使用持牌機構(gòu)的賬戶能力進(jìn)行交易。

2）會員端（錢包）會員端是面向支付產(chǎn)品使用者（一般是消費者，買方）提供的支付服務(wù)，通過開通會員錢包賬戶存放自己的資金，并且也能通過錢包賬戶進(jìn)行充值、提現(xiàn)和轉(zhuǎn)賬。

3）商戶端：商戶端是面向商家的服務(wù)端，由收單機構(gòu)提供商戶APP或者商戶網(wǎng)站給商家提供，交易管理、賬單和回單、賬戶和資金管理等服務(wù)。

2.4 產(chǎn)品中心

產(chǎn)品中心是包裝對外銷售產(chǎn)品的一個配置中心，并且商戶相關(guān)的簽約產(chǎn)品、計費信息、交易限額等都可以通過的靈活的模版來進(jìn)行配置。它的作用如下：

1）提高配置效率通過模板化的配置工具來提高商戶產(chǎn)品的配置效率，讓商戶快速的使用產(chǎn)品。

2）快速組裝新產(chǎn)品其實一個新的支付產(chǎn)品，需要重新開發(fā)的新特性不會太多，其中大部分都是基礎(chǔ)支付產(chǎn)品的復(fù)用。所以通過組件化的配置工具，通過少量的新特性開發(fā)就能快速搭建一個新的銷售產(chǎn)品出來。這樣一方面減少了產(chǎn)品的重復(fù)開發(fā)，另一方面成熟的功能多，新產(chǎn)品也比較穩(wěn)定。

2.5 支付引擎

支付引擎顧名思義是支付的發(fā)動機，他負(fù)責(zé)所有系統(tǒng)與賬戶、渠道的支付流程處理。

圖6：支付引擎核心能力

1）支付提供者它對交易層的“交易系統(tǒng)”、“客戶系統(tǒng)”、“收銀臺”等屏蔽了底層支付賬務(wù)、支付渠道管理的復(fù)雜性，讓交易層可以專注于業(yè)務(wù)場景，即使底層渠道更換，賬務(wù)進(jìn)行調(diào)整，交易層也不會受到影響。

2）流程調(diào)度者有了支付引擎這個大當(dāng)家，流程處理相關(guān)的“臟活累活”都由他來負(fù)責(zé)。賬戶、渠道、清結(jié)算就可以各司其職做好本職工作，如果涉及其他系統(tǒng)協(xié)作，通知“支付引擎”去干就可以了。

2.7 賬戶系統(tǒng)

賬戶系統(tǒng)又叫賬務(wù)系統(tǒng)，賬戶系統(tǒng)。他一般系統(tǒng)包含了賬務(wù)和賬戶兩部分，其中賬務(wù)部分負(fù)責(zé)為支付引擎提供記賬服務(wù)、記錄資金變動情況，賬戶部分用來對賬戶進(jìn)行管理，記錄并呈現(xiàn)賬戶的余額情況。

1）賬務(wù)管理

• 記賬服務(wù)：該服務(wù)面向支付引擎提供記賬、余額更新、查詢和賬戶控制等服務(wù)。并將自身的賬務(wù)流水提供給清結(jié)算系統(tǒng)進(jìn)行核對。
• 會計服務(wù)：按照會計規(guī)范設(shè)置科目和分錄，為記賬服務(wù)提供反應(yīng)賬戶間資金變動的會計數(shù)據(jù)。
• 核算服務(wù)：按照會計準(zhǔn)則核對當(dāng)天的資金賬務(wù)和庫存現(xiàn)金情況，確保賬務(wù)準(zhǔn)確和真實。

2）賬戶管理

是對資金賬戶的管理，他分為“客戶賬戶”和“內(nèi)部賬戶”兩部分，客戶賬戶是存放客戶自有資金的賬戶，他是提供給客戶使用的。內(nèi)部賬戶是用來給持牌機構(gòu)內(nèi)部登記資金賬務(wù)的賬戶，也叫內(nèi)部戶、過渡戶等。

2.8 清結(jié)算系統(tǒng)

又稱為對賬系統(tǒng)，結(jié)算系統(tǒng)，他負(fù)責(zé)與支付渠道進(jìn)行賬務(wù)核對，差錯處理、手續(xù)費的清分和客戶資金的結(jié)算。同時對于資金歸集、劃撥等無法在實時交易中完成的結(jié)算操作，也是由清結(jié)算系統(tǒng)負(fù)責(zé)處理的。

03 支付架構(gòu)流程

支付系統(tǒng)對于交易處理性能和資金結(jié)算效率要求都比較高，因此它采用的是流水線作業(yè)方式，在支付架構(gòu)的流程上表現(xiàn)出來的是兩條主干交易鏈路，實時交易鏈路和日終結(jié)算鏈路。

3.1 流水線作業(yè)

整個支付系統(tǒng)就像一個工廠車間一樣，他通過實時和日終兩條流水線分別處理實時交易和日終資金結(jié)算，這樣的處理方式很好平衡了交易指令和資金到賬時間不平衡的問題。

圖7：支付流水線作業(yè)

1）實時流水線實時流水線，通過“網(wǎng)關(guān)”到“渠道”的交易流水線，處理源源不斷從網(wǎng)關(guān)發(fā)過來的支付請求，最終發(fā)往支付渠道完成客戶的跨行收付款處理。

2）日終流水線日終流水線又叫清結(jié)算流程，它針對日間的實時交易，進(jìn)行對賬和清結(jié)算等處理，只有日終處理完了，一天的交易才算完畢。

3.2 支付架構(gòu)流程

圖8：支付系統(tǒng)流程圖

3.2.1 兩條主鏈路

1）實時交易鏈路

實時交易鏈路從“網(wǎng)關(guān)”到“渠道”形成一條支付請求的處理流水線，客戶、收銀臺、賬戶和清結(jié)算各節(jié)點按部就班的處理流水線傳遞過來的信息，完成客戶信息校驗，資金賬號獲取，收銀臺展示，賬務(wù)登記，渠道路由和跨行收付款操作。

2）日終結(jié)算鏈路

以清結(jié)算系統(tǒng)為起點，通過自動任務(wù)獲取渠道和交易層的數(shù)據(jù)進(jìn)行對賬與差錯核對，然后通過支付核心與賬戶系統(tǒng)交互完成渠道清算、商戶結(jié)算、內(nèi)部核算操作，最終為客戶生成對賬單后完成一天的業(yè)務(wù)處理。

3.2.2 實時雙驅(qū)動

為了既能處理業(yè)務(wù)的復(fù)雜場景，又能處理渠道和賬務(wù)的復(fù)雜支付邏輯，系統(tǒng)采用了“雙發(fā)驅(qū)動”的模式，臟活累活全都給“交易”和“支付”去處理，兩者配合讓整條流水線上的各個模塊有效的協(xié)作起來。

1）交易系統(tǒng)（交易發(fā)動機）

是交易層的交易流程調(diào)度者，他負(fù)責(zé)業(yè)務(wù)場景中的各種復(fù)雜交易場景的流程處理。

2）支付系統(tǒng)（支付發(fā)動機）

是核心層的支付流程調(diào)度者，他負(fù)責(zé)支付賬務(wù)、渠道調(diào)用的流程處理。

3.2.3 日終做日清

負(fù)責(zé)日終后的對賬和結(jié)算處理的流程，驅(qū)動支付系統(tǒng)完成渠道清算，商戶結(jié)算，最終為商戶生成結(jié)算賬單和回單，完成整個支付業(yè)務(wù)的閉環(huán)。

3.2.4 其他保持獨立

其他的“客戶”、“賬戶”、“收銀臺”、“渠道”四個模塊接受這兩個流程的驅(qū)動去各自完成自己的事情就可以了。這樣就這樣可以保持交易鏈路清晰，避免多模塊之間調(diào)用不清造成混亂。

下面我們通過幾個典型業(yè)務(wù)，對支付系統(tǒng)模塊間的協(xié)作關(guān)系進(jìn)行詳細(xì)的介紹：

3.3 收單流程

收單業(yè)務(wù)是第三方支付的核心業(yè)務(wù)，他場景化比較豐富，因此系統(tǒng)流程也會相對復(fù)雜些。我們針對“API收款”、“收銀臺收款”和“小程序收款”幾種典型場景進(jìn)行介紹。

3.3.1 快捷支付（API直接支付）

圖9：快捷支付收款流程

快捷支付：又叫“協(xié)議支付、簽約扣款等”（俗稱為代扣，因為比較容易和早期的裸代扣混淆，因此這么說的人并不多）?？旖莓a(chǎn)品的特點就是，持卡人需要先四要素簽約綁卡（姓名、手機號、身份證、銀行卡）進(jìn)行四方簽約（持卡人、收單機構(gòu)、清算組織、發(fā)卡銀行）

上圖是一個快捷API扣款的流程，他的主要特點如下：

1）首筆短驗，后續(xù)可免首次簽約需要輸入短信驗證碼來確認(rèn)用戶授權(quán)，后續(xù)扣款短驗和直接扣款都支持。因此首筆簽約時通過“客戶系統(tǒng)”向“渠道”發(fā)送請求，通知“發(fā)卡銀行”向客戶手機發(fā)送短信驗證碼。

2）先渠道扣款，再賬戶記賬為了保證資金的安全收款交易普遍采用，第三方扣款成功后，再給客戶賬戶或者商戶賬戶記賬。這樣可以確保渠道未支付成功的時候，資金不被客戶挪用。因此，“支付系統(tǒng)”先通過“渠道”進(jìn)行跨行扣款，如果返回結(jié)果為成功就去“賬戶系統(tǒng)”完成記賬處理。

3）流程順暢，渠道可路由整個過程從簽約、短驗、支付，按照產(chǎn)品、交易、支付、渠道的按照線性化的流程處理，因此支付過程雖然較多，但是比較順暢。同時，由于渠道完全按照收單機構(gòu)的指令執(zhí)行，因此在用戶主動支付的場景下（用戶每次都可會輸入驗證碼）渠道是可以路由的。

3.3.2 收銀臺支付（本地收銀臺支付）

收銀臺支付包含H5支付、SDK支付（集成在APP內(nèi)），由于他可以包裝比較多的支付方式在收銀臺上，因此又叫“聚合收銀臺”。我們這里介紹的場景是用戶在收銀臺上選擇在收單機構(gòu)綁定的銀行卡，這種場景收單基本通過快捷支付就能完成扣款，無需跳轉(zhuǎn)到第三方。

圖10：本地收銀臺支付流程

該流程的特點如下：

1）跳轉(zhuǎn)收銀臺完成支付用戶（付款人）下單后，收單機構(gòu)給客戶返回收銀臺地址，客戶跳轉(zhuǎn)到收銀臺上完成支付。因此交易系統(tǒng)負(fù)責(zé)按照用戶下單和使用的支付產(chǎn)品生成收銀臺地址，返回給用戶完成下單后的支付操作。

2）在客戶系統(tǒng)獲取“綁卡協(xié)議號”如果用戶選擇銀行卡付款，需要去“客戶系統(tǒng)”檢查綁卡信息，并獲“綁卡協(xié)議號”（短信簽約時渠道返回的協(xié)議號）然后通過渠道扣款。

3）通過協(xié)議號完成扣款交易系統(tǒng)拿到協(xié)議號之后，通過支付引擎、支付渠道將協(xié)議號傳給開戶行，開戶行完成扣款后原路返回，將結(jié)果通知給客戶。需要說明的是，這里的協(xié)議號按照“用戶、收單機構(gòu)、清算機構(gòu)、開戶銀行”四者關(guān)系生成，任何一方出現(xiàn)變化都需要重新簽約。

3.3.3 小程序支付（渠道收銀臺支付）

以小程序支付為代表的，APP支付、微信H5支付、公眾號支付、掃碼支付等，都需要跳轉(zhuǎn)到渠道方收銀臺上輸入密碼并完成支付。這種支付方式對客戶來說比較安全，但是也比較封閉，因此在交互體驗上也復(fù)雜了不少。

圖11：渠道收銀臺支付流程

該流程的主要特點如下：

1）下單獲取參數(shù)首先通過用戶下單向渠道方（微信、支付寶）獲得收銀臺的參數(shù)，以便后續(xù)跳轉(zhuǎn)準(zhǔn)備。

2）跳轉(zhuǎn)收銀臺根據(jù)下單獲得參數(shù)返回給商戶端后跳轉(zhuǎn)到渠道方的收銀臺，用戶在渠道方的收銀臺上完成支付。此時商家對于用戶的操作情況是一無所知的，只能等待渠道方的通知。

3）回調(diào)返回結(jié)果當(dāng)用戶完成支付后，渠道方會主動發(fā)起一個回調(diào)通知給收單機構(gòu)，收單機構(gòu)把結(jié)果給商戶端。如果長時間沒有返回。有兩種處理方式來同步最終結(jié)果，一種是主動發(fā)起查詢支付結(jié)果，另一種是做個倒計時超時直接發(fā)起撤銷或者退款（類似12306購票）從這里我們就可以看到以“交易”和“支付”為流程調(diào)度者的優(yōu)勢就出來了，他們可以任意的定制支付流程，從而滿足復(fù)雜場景對于支付的處理要求。

3.4 余額支付

余額支付就是以賬戶余額為基礎(chǔ)的“充值、提現(xiàn)、轉(zhuǎn)賬到戶、轉(zhuǎn)賬到卡”的交易。

3.4.1 賬戶充值（充值A(chǔ)PI）

圖12：賬戶充值流程

1）它不是簽約產(chǎn)品充值和提現(xiàn)都是賬戶默認(rèn)具有的功能，因此在產(chǎn)品層只讀取計費信息即可。

2）同名卡才是充值充值必須要開通的賬戶和綁定的銀卡為同一個人，明確要經(jīng)過實名認(rèn)證。因此流程中訪問客戶系統(tǒng)既要驗證你的資金賬戶是否實名，也要驗證你的綁卡是否賬戶同名。

3）記賬入客戶待結(jié)算充值的賬務(wù)是入交易發(fā)起者的錢包賬戶，由于跨行收款D1到賬的原因，因此先計入客戶待結(jié)算或者凍結(jié)收款余額，等到日終結(jié)算的時候才能釋放資金。

4）渠道走快捷支付雖然是個充值產(chǎn)品但是底層通道走的是快捷支付扣款，因此整個支付處理流程與快捷是一樣的。

3.4.2 賬戶提現(xiàn)（代付API）

提現(xiàn)是充值的反向交易，因此他獲取計費信息、校驗綁卡同名與充值基本是相同的，區(qū)別在于它記賬方式不一樣。

圖13：賬戶提現(xiàn)支付流程

1）先凍結(jié)，后出款提現(xiàn)底層走的是跨行付款通道，他與收款不同是“實時結(jié)算”的，為了避免在銀行未入賬的情況下客戶使用資金，因此提現(xiàn)采用先凍結(jié)賬戶余額，再通過渠道向開戶行發(fā)送付款申請的方式。

如果付款成功，則將余額解凍后劃入清算賬戶待日終對賬后，由收單機構(gòu)完成跨行清算。如果付款失敗該怎么辦呢？解凍并釋放余額就可以了。

3.4.3 轉(zhuǎn)賬到銀行卡（代付API）

轉(zhuǎn)賬到卡又稱為“代付業(yè)務(wù)”，它和“提現(xiàn)”在支付、賬務(wù)和渠道處理上是類似的，區(qū)別在于它的收款人不是本人。另一個區(qū)別是這種API的代付屬于是支付產(chǎn)品，并且支付的額度也是受限的。因為代付產(chǎn)品額度較大的容易被作為清算接口使用，會造成業(yè)務(wù)風(fēng)險。

圖14：轉(zhuǎn)賬到卡支付流程

3.5 清結(jié)算流程

日間實時支付交易完成后，日終清結(jié)算開始上場了。我們前面收單交易、充值交易等跨行收款交易資金還要結(jié)算給客戶和商家，并且要給商家提供賬單，這天的業(yè)務(wù)才算完成，下面我們來介紹下日終的清結(jié)算處理流程。

圖15：日終清結(jié)算流程

1）系統(tǒng)對賬下載渠道、支付系統(tǒng)、交易系統(tǒng)對賬文件進(jìn)行對賬。先核對渠道賬務(wù)，再對交易賬務(wù)并按商家賬戶維度進(jìn)行交易清分和手續(xù)費扣收。

2）差錯調(diào)賬完成對賬后如果有差錯，以渠道為準(zhǔn)在“賬戶系統(tǒng)”內(nèi)調(diào)平本方賬務(wù)差錯。

3）渠道清算當(dāng)日對賬無誤后，根據(jù)當(dāng)日的應(yīng)收應(yīng)付的軋差金額和渠道銀存賬戶的期末余額，在賬戶系統(tǒng)內(nèi)登記當(dāng)日清算賬務(wù)。（后續(xù)清結(jié)算的文章中我將會詳細(xì)介紹）。

4）商戶結(jié)算當(dāng)日對賬無誤后，根據(jù)每個商戶、客戶的待結(jié)算資金進(jìn)行結(jié)算，收款資金在他們賬戶上就可以使用了。（因為是以渠道方為準(zhǔn)，渠道清算和商戶結(jié)算沒有必然的先后順序，所以只要賬務(wù)對平就可以進(jìn)行）

5）商戶提現(xiàn)商戶結(jié)算完成后如果商戶設(shè)為自動提現(xiàn)，系統(tǒng)在T+1日自動完成商戶的打款操作，并生成商戶結(jié)算賬單。

6）賬務(wù)核算渠道清算和商戶結(jié)算完成后，賬戶系統(tǒng)的核算模塊對當(dāng)天的賬務(wù)進(jìn)行總分核算、匯總平衡，最終生成報表。當(dāng)日的交易也就處理完成了。（后續(xù)清結(jié)算和會計文章中會詳細(xì)介紹）

04 總結(jié)：支付架構(gòu)四張圖

4.1 三層架構(gòu)

支付系統(tǒng)采用三層架構(gòu)來劃分，外三層是“場景、系統(tǒng)、渠道”，內(nèi)三層是“產(chǎn)品、交易、核心”，我們所說的支付架構(gòu)主要是系統(tǒng)層面內(nèi)三層的劃分，他由三部分組成：

圖16：支付系統(tǒng)分層

1）一個平臺：承載支付業(yè)務(wù)。

2）兩個通道：網(wǎng)關(guān)接入適配不同場景，渠道接出適配不同金融資源。

3）三層架構(gòu)：產(chǎn)品、交易、核心三層架構(gòu)，采用流水線方式處理源源不斷的支付請求。

4.2 八個模塊

支付中臺一般由八個模塊組成，他承載了支付業(yè)務(wù)核心的閉環(huán)功能，可以適應(yīng)不同場景的支付需求。

圖17：支付系統(tǒng)八個模塊

4.3 流水線作業(yè)

圖18：支付系統(tǒng)的流水線作業(yè)

1）實時流水線：從“網(wǎng)關(guān)”到“渠道”形成一條支付請求的處理鏈路，系統(tǒng)各模塊處理流水線傳遞過來的信息，最終的跨行收付款操作。

2）日終流水線：從其結(jié)算系統(tǒng)開始，處理每天渠道資金清算、商戶資金結(jié)算、賬務(wù)核算的處理流程，這樣才算完成一天的交易閉環(huán)。

4.4 支付流程

圖19：支付系統(tǒng)流程圖

1）兩條主鏈路：橫向的實時交易鏈路處理交易請求和與跨行收付款，縱向的日終結(jié)算鏈路處理賬務(wù)和清結(jié)算工作。

2）日間雙驅(qū)動：實時交易鏈路，由兩個流程調(diào)度者“交易、支付”來協(xié)調(diào)各個模塊來處理支付請求。

3）每天做日清日終交易鏈路，以清結(jié)算系統(tǒng)為起點，每天日終清結(jié)算系統(tǒng)和支付、賬戶模塊完成一天最終的賬務(wù)處理。