不論是線上還是線下，我們每天都在和支付打交道；在這個系統(tǒng)里面，交易只占據(jù)了其中很少一個環(huán)節(jié)，但因為資金的重要性，其復雜程度比很多產(chǎn)品都要細節(jié)很多。

我們每天都在進行著交易，上班通勤你在與城市地鐵公司交易，就餐你在和外賣平臺、商家交易，工作中點個咖啡小憩你在與自助售賣機商家交易，加班晚了你在與打車平臺交易。

那我們每天所進行的交易他是如何完成支付的呢，支付系統(tǒng)又是如何來適應(yīng)千變?nèi)f化的交易場景的呢？下面我們來介紹下支付系統(tǒng)中交易的設(shè)計。

【老規(guī)矩，覺得比較簡單和啰嗦的請翻到最后看總結(jié)】

一、支付交易介紹

前面我們已經(jīng)介紹過了，支付是交易的一部分，訂單是信息流支付是資金流，交易系統(tǒng)通過信息和資金的匹配來完成交易履約。這么說有點抽象，我們通過大家熟悉的電商購物流程來介紹下。

圖1：電商交易履約流程

1. 交易鏈路

我們做交易設(shè)計的時候聽到最多的就是“要掌握交易全鏈路”，易鏈路就是一個個的場景化流程，從用戶挑選商品就開始記錄交易，到后面支付和履約完成。

從上圖可以看到整個過程并不是平面的而是像套娃一樣層層嵌套，因為這里面涉及的系統(tǒng)非常多（商品系統(tǒng)，履約系統(tǒng)、物流系統(tǒng)、商家系統(tǒng)、支付系統(tǒng)、結(jié)算系統(tǒng)等），任何一個節(jié)點沒有銜接上交易鏈路就會斷裂引發(fā)用戶和商戶的投訴。

支付系統(tǒng)的交易在其中起到了承上啟下的作用，他首先就是要與場景適配，其次要做到上下游流程的準確銜接。因為現(xiàn)在移動支付的交易都是全程線上化、自動化的，如果出現(xiàn)交易鏈路異常除了干瞪眼，就只有限流和事后補救了。所以支付交易在不出問題時可能誰也不知道你存在，出了問題連老板都要被嚇一跳的存在。

2. 訂單匹配

管理好交易鏈路后交易系統(tǒng)還要登記每個節(jié)點的過程信息這就是“訂單”。在整個過程中需要“交易單、支付單、物流單”三單匹配（事后根據(jù)履約結(jié)算對象不同，還有資金單、倉單、賬單、發(fā)票的核對與結(jié)算處理，我們這里主要說的是用戶側(cè)的單據(jù)）。

這里面交易單是大總管，支付單管錢，物流單管貨，因此在做交易設(shè)計的時候一定要明確清楚這里面的邊界關(guān)系，不能把交易單和支付單混問一談，否則就會做成一團亂碼。

3. 四個交易口訣

又是交易鏈路，又是訂單關(guān)聯(lián)系管理，有沒有簡單辦法直接掌握交易系統(tǒng)的精髓，當然有，其實都是業(yè)內(nèi)的一些共識，在這里我把一些常識性的規(guī)則介紹給大家。

圖2：四句口訣搞懂交易

1.3.1 支付三流合一

就是我們前面提到的“信息類、支付流、資金流”要能做到三流合一，即業(yè)務(wù)系統(tǒng)、支付系統(tǒng)、支付渠道，他們在訂單號、支付結(jié)果、賬務(wù)結(jié)果要實現(xiàn)最終的一致。那三個內(nèi)外部系統(tǒng)如何實現(xiàn)有效銜接，保證支付結(jié)果的準確，以及在異常情況下也能保障穩(wěn)定運行呢？

其實這在支付行業(yè)內(nèi)是有套標準范式的，掌握了這套標準范式，什么異常出現(xiàn)都出不了賬務(wù)損失。這就是收付款標準處理流程（我以前給人面試的時候，最喜歡用一些異常場景來看產(chǎn)品經(jīng)理這些基礎(chǔ)知識掌握的好不好）。

1）收款范式：（沒有結(jié)果，我就不給客戶結(jié)算）

收款是給用戶賬戶加錢，或者給商戶結(jié)算。因此為了保障資金安全，“在渠道沒有明確結(jié)果之前，我就不給客戶結(jié)算”。

這么處理的原因是收款會給客戶賬戶上加錢，因此只有明確成功后才能告知用戶，充值的時候用戶看到錢可能會去消費，商家看到錢可能會去發(fā)貨。如果不明的情況下給客戶賬戶加款就容易出現(xiàn)“資損”和“貨損”。

因此，為了保障資金的安全，收款業(yè)務(wù)需要先發(fā)往渠道，只有當渠道明確給出成功或者失敗的明確結(jié)果，再對本地賬務(wù)進行登記，訂單結(jié)果進行更新。這樣就確保在沒有明確的結(jié)果下，交易雙方都不能進行賬務(wù)處理，也就規(guī)避了上述長短款的風險。

圖3：收款交易范式

上圖就是收款的時序圖，大家可以結(jié)合我的介紹體會下這個處理結(jié)果。我就不做贅述了。

2）付款范式（錢抓手里，沒有結(jié)果，錢就不付）

付款的資金風險就更大了，因為跨行付款即結(jié)算錢會直接到別人口袋里面。所以付款的要點就是“把錢抓在自己手里，在渠道沒有明確結(jié)果之前我就不付款出去”。

基于這個原理，我們來看下圖，在付款流程中我們先把客戶賬戶上的付款金額扣下來，直到渠道支付成功后我們才更新本地狀態(tài)。如果遇到失敗，我們就需要通過沖正交易再把錢給客戶退回去。

這種先扣款，再轉(zhuǎn)發(fā)的方式能夠牢牢地把資金抓在自己手里，減少資金損失產(chǎn)生的風險。如果是面對比較大金額的付款我們一般會采用“多級審核”的方式，通過增加人工確認節(jié)點來保障資金支付的準確和安全。但是底層的支付流程和結(jié)算邏輯是始終不變的。

圖4：付款交易范式

四方或企業(yè)沒有線上賬務(wù)系統(tǒng)怎么處理？

其實更簡單，去掉賬務(wù)處理部分，在處理中狀態(tài)下不允許客戶再次支付就可以了。結(jié)算資金通過事后的賬實核對完成財務(wù)系統(tǒng)入賬即可。

1.3.2 跨系統(tǒng)三態(tài)

現(xiàn)在我們普遍采用了網(wǎng)絡(luò)的方式將不同的系統(tǒng)連接在一起，由于網(wǎng)絡(luò)通訊存在超時和異常中斷情況，因此所有需要跨系統(tǒng)進行處理的業(yè)務(wù)都要把這種異常情況考慮在內(nèi)，所以，涉及跨系統(tǒng)的業(yè)務(wù)處理都要設(shè)計“成功”、“失敗”和“處理中”這三個狀態(tài)，保持各系統(tǒng)間信息是一致的。這三個狀態(tài)按他生命周期又分為了“終態(tài)和運行態(tài)”。

1）終態(tài)：

終態(tài)就是生命周期結(jié)算的狀態(tài)。成功、失敗均為終態(tài)，在外部支付渠道沒有返回結(jié)果前均不能推定為終態(tài)。

2）運行態(tài)：

跨系統(tǒng)支付時需要將狀態(tài)置為處理中，有明確結(jié)果才能置為“終態(tài)”。

“處理中”這個狀態(tài)雖然能夠保障資金的安全，但是效率太低，也容易引發(fā)用戶的恐慌和投訴。因此，人們想到了下面這個方法。

1.3.3 異常查退合一

異常就是“處理中”不明賬務(wù)結(jié)果，需要通過補償措施來同步內(nèi)外部系統(tǒng)賬務(wù)信息，這樣才能讓交易盡快完成。要同步交易結(jié)果，一般是通過訂單信息和賬務(wù)結(jié)果兩種方式來處理的。

1）訂單查證：

這種方式以外部訂單狀態(tài)為準更新本方狀態(tài)。當出現(xiàn)“處理中”的訂單時，系統(tǒng)會自動運行一個查詢服務(wù)去渠道查詢處理結(jié)果，并將結(jié)果與本地的訂單進行更新和同步。

2）賬務(wù)沖退：

收款場景下，這種方式以本方賬務(wù)結(jié)果為準，讓渠道一側(cè)與本方保持一致。一般我們都是發(fā)起撤銷和退款。

1.3.4 差錯三賬調(diào)平

前面介紹的都是在交易發(fā)生時的處理方式，如果聯(lián)機交易一直無法得到解決，那就要采用事后處理的方式。日終對賬之后產(chǎn)生的差錯需要“以渠道為準”通過三種賬務(wù)策略進行調(diào)平處理。

1. 補賬：以渠道為準本方補計賬務(wù)或者更正訂單
2. 沖正：以渠道為準，本方賬務(wù)取消或者逆向記賬。
3. 掛賬：為了不影響正常業(yè)務(wù)的結(jié)算，有些異常賬務(wù)先掛賬到內(nèi)部戶，后面人工處理后進行核銷。

關(guān)于差錯處理的詳細策略，我們會在“結(jié)算對賬”的文章中單獨介紹。

二、交易系統(tǒng)介紹

基于以上的交易規(guī)則我們再來看下交易系統(tǒng)是如何設(shè)計的。我們先來看下他在我們之前的業(yè)務(wù)架構(gòu)流程中屬于什么位置，上下游協(xié)作系統(tǒng)又有哪些。

圖5：交易在架構(gòu)中的位置

從上圖中我們可以看到，交易處于實時鏈路的中心位置，它負責接收網(wǎng)關(guān)發(fā)來的支付請求，將業(yè)務(wù)信息轉(zhuǎn)化為支付指令分別與“客戶系統(tǒng)”、“收銀臺”、“支付引擎”進行交互完成最終的支付，由此我們可以看到

1）交易即支付

交易系統(tǒng)負責訂單信息和支付指令的轉(zhuǎn)換，并且他也負責支付引擎的調(diào)用，因此交易與支付是相伴而生的。

2）交易場景化

交易接收來網(wǎng)關(guān)轉(zhuǎn)發(fā)的業(yè)務(wù)系統(tǒng)的請求，因此業(yè)務(wù)系統(tǒng)是什么樣的場景，交易系統(tǒng)就要配套的交付服務(wù)流程來負責處理。由此可見交易是一個場景化的模塊。

3）交易可擴展

我們常用的支付交易包含了“收款、分賬、轉(zhuǎn)賬、付款”，這些都是基礎(chǔ)交易功能，支付交易并不局限于此。

真實的支付交易系統(tǒng)既要實現(xiàn)標準化也需支持可擴展，“消金交易、B2B交易、保證金交易，分銷交易”等都只是子交易模塊而已，只要和業(yè)務(wù)系統(tǒng)劃分清楚邊界，都可以在交易層來擴展。

1. 業(yè)務(wù)架構(gòu)

交易系統(tǒng)在整個支付架構(gòu)中處于承上啟下的作用，它從接收訂單到訂單完成進行全鏈路的管理。我們的交易服務(wù)提供的是“收款、分賬、余額、付款”四個基礎(chǔ)服務(wù)，服務(wù)通過交易管理來進行配置，通過訂單系統(tǒng)來登記交易和結(jié)算信息。整個交易中心分為“接口、服務(wù)、接出”三部分，下面我們來一一介紹。

圖5：交易中心業(yè)務(wù)架構(gòu)

1）交易接口

這一層是對外提供的交易服務(wù)接口，收單網(wǎng)關(guān)、會員網(wǎng)關(guān)、收銀臺、客戶系統(tǒng)都可以通過這些接口來調(diào)用交易完成支付處理。

2）交易服務(wù)

按業(yè)務(wù)場景分模塊提供對應(yīng)基礎(chǔ)交易服務(wù)，這些交易服務(wù)根據(jù)交易類型按不同的交易鏈路和流程進行處理。

3）交易接出

根據(jù)交易處理流程的調(diào)度，對支付服務(wù)、客戶系統(tǒng)等內(nèi)部系統(tǒng)進行調(diào)用，完成從“支付、訂單、算費、驗證、回調(diào)”等一系列的操作，最終實現(xiàn)用戶的收付款和結(jié)算處理。

2. 交易功能

交易中心的整體功能包含了“收款、分賬、余額”和“付款”三部分基礎(chǔ)交易，這些基礎(chǔ)功能構(gòu)成了現(xiàn)在基于電商場景的支付交易。當然這些基礎(chǔ)功能也是具有很好的擴展性的，面向企業(yè)場景可以提供包裝出B2B支付，面向消金場景可以包裝出消金支付，面向投資理財可以包裝出理財支付產(chǎn)品。怎么包裝會在后面的場景案例中單獨介紹，這里我們先來熟悉最基礎(chǔ)的交易產(chǎn)品。

圖7：交易中心功能視圖

2.2.1 收款功能

收款即為收單，我們之前介紹收銀臺的時候已經(jīng)說過，交易功能統(tǒng)一收銀臺的方式來實現(xiàn)的，這里就不做贅述了。

2.2.2 分賬交易

分賬是電商業(yè)務(wù)和收單業(yè)務(wù)典型的交易功能，他可以按照“訂單分賬”或“余額分賬”作為資金來源向多個收款人分配資金。由于的時效性交易模式還可以分為“即時到賬模式”、“擔保交易模式”兩類。

1）即時到賬模式：

即時到賬就是收款完成后立即給收款人結(jié)算資金。如果收款人只有一個的情況下與收單交易是一樣的，如果多人的話就需要按照一定規(guī)則向多個人進行分賬了。

2）擔保交易模式：

擔保交易模式，又被稱為“延遲分賬模式”，按照交易類型分為“擔保支付”、“合單支付”、“組合支付”三種。按照分賬順序它又分為“支付時分賬”和“支付后分賬”兩種。交易類型我們后面介紹，這里我們先介紹下分賬順序。

• 支付時分賬：就是在支付前上傳需要向哪些收款人進行資金分賬的規(guī)則。
• 支付后分賬：就是支付前還不明確給誰分多少錢，因此收款后資金暫存在系統(tǒng)內(nèi)，等到明確了分賬方后再上傳。

3）結(jié)算方式

以上交易模式的結(jié)算方式又分為兩種“訂單結(jié)算”和“余額結(jié)算”兩種方式。

1. 訂單結(jié)算：又叫訂單分賬、空中分賬，顧名思義就是按照訂單金額進行分賬。他的資金是暫存在“擔保賬戶”中的，接收到分賬指令再給收款人結(jié)算資金。
2. 余額結(jié)算：又叫余額分賬，他的資金不是進入“擔保賬戶”，而是先到收款商家賬戶，然后進行分賬?？赡苡腥苏f這個行為是二清的，其實不然，很多加盟店、供應(yīng)鏈采銷場景中比較常見。例如：加盟店的商品都是總部供應(yīng)的，但是加盟店要給客戶開發(fā)票的話資金流就需要先過加盟店，再過總部。

具體采用什么處理方式還需要結(jié)合場景實質(zhì)來提供對應(yīng)的處理方案。

2.2.3 余額交易

余額交易又被稱為“錢包支付”功能，包括了充值、提現(xiàn)、轉(zhuǎn)賬和余額消費。

2.2.4 付款交易

付款交易包括單筆付款和批量付款，同時付款收款賬戶不同又分為“付款到卡”和“付款到戶”兩個功能。當然付款也有逆向處理退匯，同時針對批量付款也會提供回調(diào)通知用于需要長時間進行等待的場景。

三、分賬交易流程

下面我們通過幾個場景來介紹下其中比較復雜的分賬交易。前面我們介紹了“即時到賬交易”和“擔保交易模式”兩種，下面我們分別結(jié)合場景來給大家介紹他們的處理過程。

1. 即時到賬模式

即時到賬就是我們每天都在用的收款交易，它可以直接收款，也能收款成功后給商家進行分賬。我們看下即時到賬的處理場景。

圖8：即時收款交易訂單

一筆收款的交易訂單，包含了“1個費用項和4個結(jié)算對象”。費用項是手續(xù)費，結(jié)算對象有賣貨的商家、平臺的抽傭、物流的服務(wù)費、供貨的供應(yīng)商的商品成本。

圖9：即時分賬場景

上圖是收單機構(gòu)即時到賬的“一步式”交易流程。收單機構(gòu)先在渠道完成收款，成功后扣交易收手續(xù)費，資金經(jīng)過待清算往來戶后完成結(jié)算對象的分賬。這里可能有人會問為什么要過下“機構(gòu)往來賬戶”，因為這是筆訂單分賬，資金先經(jīng)過誰的賬戶都不合適，因此通過支付機構(gòu)的往來賬戶進行處理。

需要說明的是：其后我們的例子都是“訂單分賬”模式，余額分賬是先經(jīng)過“主商戶賬戶”然后再分，過程基本雷同我們就不再贅述了。

2. 擔保交易模式

這類交易電商平臺用中用的最多，因為下單和付款都是線上速度比較快，但商品發(fā)貨和物流需要時間因此在未收到貨之前會需要將資金凍結(jié)在擔保賬戶中，待用戶簽收貨物后再給交易參與方分賬。

這種模式根據(jù)實現(xiàn)的復雜度不同主要分為“擔保、合單與組合”。

3.2.1 擔保支付

圖10：擔保交易訂單

這是擔保交易模式的基礎(chǔ)形態(tài)，它的支付訂單與即時交易是一樣的，主要針對一筆商品訂單的收款和分賬處理，區(qū)別在于流程和資金處理的不同。

圖11：擔保交易分賬流程

上圖中我們看到收單機構(gòu)完成收款和手續(xù)費收取后，資金進入的是擔保賬戶，然后就把支付結(jié)果推送商家平臺，商家或者供應(yīng)商就能發(fā)貨了。有當客戶收到貨確認收款后交易平臺發(fā)起“交易確認”資金才會結(jié)算。

這種處理方式在外賣場景中較為多見，因為他是按每個店鋪來進行分賬的，多家店鋪就要下單獨單，因此一個訂單就能解決了（當然這里只是舉例并不是說外賣交易實際只有一個訂單）。但是現(xiàn)在普遍都希望用戶一次性在多個商家多買點商品，因此一個訂單不夠用了。

3.2.2 合單支付

合單支付又叫“合并支付”，他的意思就是“多個商家的訂單通過一種支付方式完成支付”。他是擔保支付的升級版。

圖12：合單交易訂單

從上圖可以看到這筆訂單在原先扣費金額結(jié)算信息上增加了多個商戶，這就需要給每個商戶都增加一個子交易訂單這樣每個商家就都能看到了自己的收款了。當然增加了子訂單這里的算費要比擔保交易又復雜了好多，還有逆向交易，卡券核銷也會同等增加難度。

圖13：合單交易分賬流程

合單過程資金處理與擔保交易是一樣的，只是訂單的計算比較復雜。

3.2.3 組合交易

組合支付就是“多個商家訂單通過多種支付方式或渠道進行付款”，這就是合單支付的升級版了，它常用的場景是“營銷活動”中。這種交易需要在收款支付方式的基礎(chǔ)上增加一個營銷賬戶，通過渠道和營銷賬戶兩種支付方式組合來完成支付。

圖14：組合交易訂單

組合支付的訂單與擔保交易是一樣的，區(qū)別主要在于增加了一個營銷補貼費用，這樣資金處理流程就會略微復雜些了。

圖15：組合交易流程

資金處理時增加了一個營銷賬戶用來存放營銷資金（也可以通過平臺商戶賬戶充值來做營銷款的支付）。當資金進入擔保戶后，平臺發(fā)起分賬，該過程“先從營銷賬戶中劃扣補貼資金到擔保戶，然后分賬給對應(yīng)的收款賬戶。

需要說明的是：組合交易定義雖然是允許多種支付方式和渠道，但是實際設(shè)計中最好“只有一種支付渠道、另外幾種支付方式是內(nèi)部的賬戶”。因為涉及多渠道收款并支付退款過程將非常復雜，甚至需要人工介入才能實現(xiàn)（例如醫(yī)療行業(yè)醫(yī)保和自費支付就是這種比較復雜的處理方式）。

四、交易退款流程

交易的逆向流程就是退款和退匯，退匯這個相對簡單就是接收一筆來賬打款，我們這里重點介紹的是收款交易的逆向流程退款。根據(jù)實現(xiàn)的難度不同我們針對不同的退款特性劃分了下等級。

1. 退款通用特性

退款的特性一句話就可以說完“原路返還”也就是從哪里來回到哪里去。話雖然簡單，但是實現(xiàn)起來可不容易因為“正向流程有多復雜，逆向流程就有多復雜，可能更加復雜”。

我們介紹下退款使用時具有的一些基礎(chǔ)特性：

• 退款資金需要原路退回到發(fā)起交易的卡或賬戶中。
• 僅有成功的訂單才能發(fā)起退款（處理中是撤銷）。
• 一筆訂單需要支持部分退款，即在訂單的金額內(nèi)需要支持多次退款。
• 退款具有有效期，超過有效期則不能發(fā)起退款。這種情況下需要有人工的方式來給客戶線下打款。
• 為了保障賬戶有足夠的資金退款，因此資金提現(xiàn)到卡時要賬戶內(nèi)要有部分留底資金來作為退款使用。

是不是覺得很簡單？因為這些都是通用規(guī)則，市面上的所有渠道都會支持。下面我們來介紹下有些優(yōu)秀的渠道能夠支持的特性。

2. 退款的結(jié)算

退款資金的結(jié)算的資金流依然遵從原路返還的特點，他主要分為三種“軋差退款、退款賬戶退款、混合退款”。

1）軋差退款：

這是最常用的退款方式，它是指在如果一筆訂單已經(jīng)發(fā)生了部分退款，那剩余的資金是收款與退款資金軋差后的金額。顯然這是一個比較合理的處理方式。

2）退款賬戶退款：

有些業(yè)務(wù)因為分賬后已經(jīng)在家已經(jīng)提現(xiàn)到銀行卡沒有足夠資金支持退款，或者超過了有效期但是又不想做線下打款。這種情況下提供留底資金或者指定賬戶退款是非常有必要的。

3）混合退款：

就是上述兩種情況的混合，即一筆訂單已經(jīng)部分退款并且賬戶上也沒有留錢，因此需要對指定賬戶軋差后進行退款。

這些就是退款方面考慮的比較完善的實現(xiàn)方式了，能做到這些都是比較優(yōu)秀的支付渠道了。當然永遠有做的更好的，下面我們來介紹一些做的更好的方案。

3. 其他退款情況

以下也是一些退款中比較特別的場景，有些還有點變態(tài)（屬于容易被研發(fā)打的需求）我這里也一并介紹下。

1）退款不退手續(xù)費：

這是一種比較常見的情況，有的渠道為了保持自己的利潤退款不返還手續(xù)費，如果再疊加分賬的情況下手續(xù)費的計算會非常的復雜。為了給用戶更好的體驗很多渠道就做了一些定制開發(fā)，讓用戶更好的使用。

• 設(shè)置手續(xù)費賬戶：設(shè)置指定賬戶扣收手續(xù)費，退款還是原訂單金額退回。
• 按比例承擔手續(xù)費：按比例每筆退款訂單承擔對應(yīng)比例的手續(xù)費。
• 最后一筆承擔手續(xù)費：因為收單都是一個付款人，因此只要知道手續(xù)費不退付款人也是能夠接受的。

2）退款金額超訂單：

原則上這種情況是不允許發(fā)生的，因為賬不平。實際該場景主要出現(xiàn)在分賬交易中。分賬方資金結(jié)算后如有幾個分賬方賬戶余額不足，這時就沒法退款了。這種情況就要使用到指定賬戶退款了，如果不支持可以給分賬方設(shè)置留底資金或者讓分賬方以充值的方式補充資金來完成退款。

3）退款金額超時效：

每個渠道都有退款時效要求，因為大量的歷史訂單存放在交易庫中支付效率會變得非常低。但是有些場景資金周轉(zhuǎn)周期就是比較長的如果渠道側(cè)不能支持的話（比如微信、支付寶這種國民App），需要支付系統(tǒng)做些定制開發(fā)了。

• 允許設(shè)置有效期：通過客戶上傳的訂單周期來定期關(guān)閉和歸檔訂單可以更好適應(yīng)不同行業(yè)的結(jié)算和退款周期。這樣資金周轉(zhuǎn)快慢的公司就都能夠適應(yīng)了，當然也不能無限制由著客戶胡來，支持一個財務(wù)年度還是有必要的。

最后提供一些退款渠道需要注意的一些特性，大家可以收藏保存。（20年整理的，大家使用時需要驗證下是否準確）

圖16：退款流程需要關(guān)注的部分信息

4.兜底辦法打款轉(zhuǎn)賬

如果以上方式全部都失效，還剩下最后一個辦法就是通過人工打款的方式給客戶退款。這種方式主要針對銀行卡更加適用。對于微信、支付寶這類三方錢包人力耗費就比較高，需要客服人員聯(lián)系到用戶然后轉(zhuǎn)賬給對方。此類辦法一般當做兜底方案提供給客戶處理。

五、交易設(shè)計方案

整個交易系統(tǒng)的流程介紹完了，是不是還差點什么？怎么實現(xiàn)呢？

下面我們把交易系統(tǒng)的設(shè)計方案來做個簡要的介紹。

1. 交易用例圖

圖17：收單交易服務(wù)

交易服務(wù)功能比較多，并且可以根據(jù)場景進行擴展，整個交易系統(tǒng)功能如上圖。上圖以收單功能為例來進行說明。具體收單交易功能結(jié)合之前的支付流程對照即可，這里就不再贅述了。

當然對于另外兩個付款、余額支付這套流程也適用只要把“分賬”部分（圖中粉色）改成對應(yīng)的“記賬、沖正”功能就可以了。

2. 訂單模型

圖18：交易訂單ER模型（灰色部分可選）

這塊看著比較偏技術(shù)，我結(jié)合收單場景來介紹下。

1）下單支付：

用戶下單后會創(chuàng)建一個交易訂單來登記用戶的交易信息。用戶在收銀臺確認訂單后提交支付，交易系統(tǒng)通過支付引擎向渠道發(fā)起支付，支付成功后調(diào)用賬戶系統(tǒng)生成結(jié)算單完成記賬。由于合單與組合支付的存在因此會生成多筆交易單和支付單，這種多對多關(guān)系需要有個交易單與支付單的轉(zhuǎn)化關(guān)系。

2）交易分賬：

收款成功后如果還要分賬，交易系統(tǒng)會根據(jù)結(jié)算對象生成多筆分賬訂單給收款人進行分賬，并最終完成記賬結(jié)算。

由于需要支持“購物車”這樣的合單支付場景，因此采用了一對多的主子單結(jié)構(gòu)。一個分賬訂單對應(yīng)一個商家，分賬子單對應(yīng)采購的每件商品。后面的退款與優(yōu)惠受此影響也需要按此結(jié)構(gòu)進行設(shè)計，當然很多交易平臺為了降低聯(lián)機交易的復雜度，在日終結(jié)算對賬的時候處理也可以。

3）優(yōu)惠核銷：

交易過程中如果涉及到卡券、積分的核銷，交易系統(tǒng)在創(chuàng)建訂單時就會生成優(yōu)惠訂單，支付完成或者支付分賬完成后核銷這筆訂單并進行記賬結(jié)算。

4）退款交易：

退款是支付的逆向交易，并且有多次退款的場景，因此發(fā)起退款前先要關(guān)聯(lián)“原交易訂單”，然后生成對應(yīng)的退款單進行退款并完成記賬結(jié)算。

5）計費信息：

交易計費單是登記向客戶收取的手續(xù)費收入，渠道計費單是登記渠道扣收的手續(xù)費。由于交易單和支付單之間的關(guān)系比較復雜容易出現(xiàn)計費算不清的問題，因此兩個計費單統(tǒng)一按照“交易訂單號”進行關(guān)聯(lián)保持計費信息前后一致。并且一筆交易對應(yīng)的收款、退款都會進行匯總登記，這樣每筆交易的不管退多少次款都能算清楚了。

以上內(nèi)容比較復雜，剛接觸支付的同學不必全部搞明白，只要清楚他們之間的關(guān)系就可以了。

3. 交易狀態(tài)

交易狀態(tài)控制著交易過程一步步的往下推進完成收付款，狀態(tài)是訂單和賬務(wù)處理的重要信息，良好的訂單信息可以保證資金的安全和交易過程中異常、正向、逆向都能順暢的閉環(huán)運轉(zhuǎn)。交易狀態(tài)根據(jù)“交易類型”分為了“收款、分賬、退款、付款”四部分。

圖19：支付交易狀態(tài)

5.3.1 收款狀態(tài)

1）支付狀態(tài)

收款的狀態(tài)包含了“收單和充值”業(yè)務(wù)的，這類交易平時我們用的比較多。一般會給調(diào)用下單和調(diào)用收銀臺留個“初始”狀態(tài)，用戶在收銀臺上支付就處于“待支付”狀態(tài)了，這個時候除了用戶誰也不能對這個訂單進行操作了。

2）撤銷狀態(tài)

收單業(yè)務(wù)在處理中可以進行撤銷，例如用戶“不（手）?。ㄙv）心”在支付的時候把收銀臺關(guān)閉了，那需要設(shè)計一個自動查詢?nèi)蝿?wù)來撤銷這筆訂單，當然這個操作由交易平臺主動發(fā)起。

5.3.2 分賬狀態(tài)

分賬狀態(tài)我們平時接觸的就不多了，只有在確認收款時候才會有所感知。它主要在即時分賬和擔保分賬時會用到；

1）即時分賬

即時分賬是收款和分賬“一步式”完成的，因此在待支付狀態(tài)下就要進行。當分賬成功后支付狀態(tài)也調(diào)整為“支付成功”。如果分賬失敗那就麻煩了，需要做對應(yīng)的重新分賬處理，交易系統(tǒng)要同時判斷“支付狀態(tài)”和“分賬狀態(tài)”然后再進行處理。

2）擔保分賬

擔保分賬是先收款，等業(yè)務(wù)側(cè)履約完成后再分賬，因此在支付成功狀態(tài)下發(fā)起。如果分賬失敗與即時分賬一樣要支持重新分賬。

5.3.3 退款狀態(tài)

退款狀態(tài)我們平時接觸的也比較多，當我們退貨的時候使用的就是退款處理流程。退款與撤銷不同之處在于它只能在支付成功的時候才能發(fā)起。

收款的退款是比較簡單的，分賬的退款相對麻煩，只有當“分賬中”狀態(tài)時不允許退款（其實很短暫過程），其他不管成功、失敗都要能支持退款的逆向操作。（這部分我們在退款交易中單獨介紹）

5.3.4 付款狀態(tài)

付款業(yè)務(wù)相對獨立，它主要負責控制提現(xiàn)、單筆的支付處理。由于大金額付款資金風險比較高，因此處理起來也是比較謹慎的。

1）預(yù)扣款處理

我們前面介紹了付款相對收款多了一個預(yù)扣款和失敗后的沖正，因此節(jié)點上增加了付款申請這個操作狀態(tài)，其作用就是用戶提交支付前可以做對應(yīng)的“經(jīng)辦與審核操作”。如果涉及多級審核，需要新增審核狀態(tài)來控制和管理支付狀態(tài)。

審核節(jié)點存在長期不處理的情況，因此如果是付款申請狀態(tài)可以直接撤銷。

2）付款結(jié)算

在付款時都會先置為“付款中”，如果全部成功則為“付款成功”，如果失敗完成沖正后關(guān)閉付款訂單。

有人會說如果用戶想重新發(fā)起該怎么辦呢？要重新發(fā)起，反正原支付系統(tǒng)訂單到終態(tài)就“壽終正寢”了，用戶操作便利性和管理流程性的需求“由業(yè)務(wù)系統(tǒng)或者商戶工作臺去處理”，交易系統(tǒng)不再理會。訂單生命周期結(jié)算就不能“再詐尸了”，付款不是鬧著玩的，打死不改。

3）退匯處理

退匯是匯款業(yè)務(wù)比較常見的一種異常情況，是因為對手銀行校驗?zāi)愕氖湛钊诵畔o法入賬的處理方式。他的特點是會先告訴你收款成功，然后再把錢打回付款人賬戶。（人行大小額普通貸記強制清算的原因，這個可以看我以前的文章）。

以上的付款主要介紹的是單筆付款，批量付款要復雜的多。它要在“單筆付款狀態(tài)”的基礎(chǔ)上增加一套“批量任務(wù)管理”來控制交易的步點。限于篇幅批量處理后面在介紹代發(fā)薪資、批量放款的時候再單獨介紹吧。

六、總結(jié)

由于交易是場景化的，并且可以根據(jù)場景進行無窮無盡的擴展，因此今天的內(nèi)容比較多，我們挑重點來總結(jié)下吧。

6.1 交易四個口訣

1）支付三流合一

就是“業(yè)務(wù)系統(tǒng)”、“支付系統(tǒng)”、“支付渠道”要能夠有效銜接，“交易流”、“支付流”、“資金流”的訂單號、狀態(tài)、金額要保障最終一致。三流合一有兩個重要的范式也要記住，

• 收款范式：沒有結(jié)果，我就不給客戶結(jié)算。
• 付款范式：錢抓手里，沒有結(jié)果，錢就不付出去。

2）跨系統(tǒng)三狀態(tài)

任何跨系統(tǒng)的交易都要設(shè)置三種狀態(tài)“成功、失敗、處理中”，其中成功、失敗稱為“終態(tài)”，“處理中”稱為運行態(tài)，支付系統(tǒng)的賬務(wù)處理只能根據(jù)終態(tài)來進行最終的資金結(jié)算處理，處理中的狀態(tài)都不能進行結(jié)算。

3）異常查退合一

由于經(jīng)常會有處理中的狀態(tài)出現(xiàn)，為了保障客戶資金到賬的時效性，因此需要做異常的查退處理來實現(xiàn)支付結(jié)果盡快一致。

• 訂單查證：這種方式以外部訂單狀態(tài)為準更新本方狀態(tài)。
• 賬務(wù)沖退：收款場景下，這種方式以本方賬務(wù)結(jié)果為準，通過撤銷和退款讓渠道一側(cè)與本方賬務(wù)保持一致。

4）差錯三賬調(diào)平

如果處理中一直得不到解決，只能通過日終對賬來保障結(jié)果同步了，這就是最終一致性要求。差錯處理主要有三種方式。

• 補賬：以渠道為準本方補計賬務(wù)或者更正訂單
• 沖正：以渠道為準，本方賬務(wù)取消或者逆向記賬。
• 掛賬：為了不影響正常業(yè)務(wù)的結(jié)算，有些異常賬務(wù)先掛賬到內(nèi)部戶，后面人工處理后進行核銷。

6.2 交易分賬模式

交易的分賬模式很多，通常會把它分為即時到賬模式和擔保交易模式。

1）即時到賬模式

就是收款和分賬一步完成，資金直接到收款方的賬戶。這種面對面快速交易比較常見。

2）擔保交易模式

就是收款后資金先暫存在擔保賬戶，待收款方履約后再做結(jié)算。這種電商履約場景較為常見。擔保交易模式主要分為三種“擔保支付、合單支付、組合支付”實現(xiàn)難度也逐個遞增。

6.3 分賬交易流程

分賬交易流程有四種，這里做了一個表格歸納總結(jié)了他們的特性

6.4 退款交易流程

退款交易流程是支付的逆向流程，正向流程有多復雜，退款流程就有多復雜。這部分掌握基礎(chǔ)退款規(guī)則就行了，其他退款處理方式本文給出了一些參考方案，具體落地都需要設(shè)計者具體事情具體分析。

6.5 交易設(shè)計方案

主要是幾張圖由場景到最終實現(xiàn)的關(guān)聯(lián)關(guān)系要能夠理解。