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

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

那我們每天所進行的交易他是如何完成支付的呢，支付系統又是如何來適應千變萬化的交易場景的呢？下面我們來介紹下支付系統中交易的設計。

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

一、支付交易介紹

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

圖1：電商交易履約流程

1. 交易鏈路

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

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

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

2. 訂單匹配

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

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

3. 四個交易口訣

又是交易鏈路，又是訂單關聯系管理，有沒有簡單辦法直接掌握交易系統的精髓，當然有，其實都是業內的一些共識，在這里我把一些常識性的規則介紹給大家。

圖2：四句口訣搞懂交易

1.3.1 支付三流合一

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

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

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

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

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

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

圖3：收款交易范式

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

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

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

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

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

圖4：付款交易范式

四方或企業沒有線上賬務系統怎么處理？

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

1.3.2 跨系統三態

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

1）終態：

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

2）運行態：

跨系統支付時需要將狀態置為處理中，有明確結果才能置為“終態”。

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

1.3.3 異常查退合一

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

1）訂單查證：

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

2）賬務沖退：

收款場景下，這種方式以本方賬務結果為準，讓渠道一側與本方保持一致。一般我們都是發起撤銷和退款。

1.3.4 差錯三賬調平

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

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

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

二、交易系統介紹

基于以上的交易規則我們再來看下交易系統是如何設計的。我們先來看下他在我們之前的業務架構流程中屬于什么位置，上下游協作系統又有哪些。

圖5：交易在架構中的位置

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

1）交易即支付

交易系統負責訂單信息和支付指令的轉換，并且他也負責支付引擎的調用，因此交易與支付是相伴而生的。

2）交易場景化

交易接收來網關轉發的業務系統的請求，因此業務系統是什么樣的場景，交易系統就要配套的交付服務流程來負責處理。由此可見交易是一個場景化的模塊。

3）交易可擴展

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

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

1. 業務架構

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

圖5：交易中心業務架構

1）交易接口

這一層是對外提供的交易服務接口，收單網關、會員網關、收銀臺、客戶系統都可以通過這些接口來調用交易完成支付處理。

2）交易服務

按業務場景分模塊提供對應基礎交易服務，這些交易服務根據交易類型按不同的交易鏈路和流程進行處理。

3）交易接出

根據交易處理流程的調度，對支付服務、客戶系統等內部系統進行調用，完成從“支付、訂單、算費、驗證、回調”等一系列的操作，最終實現用戶的收付款和結算處理。

2. 交易功能

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

圖7：交易中心功能視圖

2.2.1 收款功能

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

2.2.2 分賬交易

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

1）即時到賬模式：

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

2）擔保交易模式：

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

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

3）結算方式

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

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

具體采用什么處理方式還需要結合場景實質來提供對應的處理方案。

2.2.3 余額交易

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

2.2.4 付款交易

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

三、分賬交易流程

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

1. 即時到賬模式

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

圖8：即時收款交易訂單

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

圖9：即時分賬場景

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

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

2. 擔保交易模式

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

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

3.2.1 擔保支付

圖10：擔保交易訂單

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

圖11：擔保交易分賬流程

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

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

3.2.2 合單支付

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

圖12：合單交易訂單

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

圖13：合單交易分賬流程

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

3.2.3 組合交易

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

圖14：組合交易訂單

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

圖15：組合交易流程

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

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

四、交易退款流程

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

1. 退款通用特性

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

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

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

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

2. 退款的結算

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

1）軋差退款：

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

2）退款賬戶退款：

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

3）混合退款：

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

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

3. 其他退款情況

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

1）退款不退手續費：

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

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

2）退款金額超訂單：

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

3）退款金額超時效：

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

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

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

圖16：退款流程需要關注的部分信息

4.兜底辦法打款轉賬

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

五、交易設計方案

整個交易系統的流程介紹完了，是不是還差點什么？怎么實現呢？

下面我們把交易系統的設計方案來做個簡要的介紹。

1. 交易用例圖

圖17：收單交易服務

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

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

2. 訂單模型

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

這塊看著比較偏技術，我結合收單場景來介紹下。

1）下單支付：

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

2）交易分賬：

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

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

3）優惠核銷：

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

4）退款交易：

退款是支付的逆向交易，并且有多次退款的場景，因此發起退款前先要關聯“原交易訂單”，然后生成對應的退款單進行退款并完成記賬結算。

5）計費信息：

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

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

3. 交易狀態

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

圖19：支付交易狀態

5.3.1 收款狀態

1）支付狀態

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

2）撤銷狀態

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

5.3.2 分賬狀態

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

1）即時分賬

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

2）擔保分賬

擔保分賬是先收款，等業務側履約完成后再分賬，因此在支付成功狀態下發起。如果分賬失敗與即時分賬一樣要支持重新分賬。

5.3.3 退款狀態

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

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

5.3.4 付款狀態

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

1）預扣款處理

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

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

2）付款結算

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

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

3）退匯處理

退匯是匯款業務比較常見的一種異常情況，是因為對手銀行校驗你的收款人信息無法入賬的處理方式。他的特點是會先告訴你收款成功，然后再把錢打回付款人賬戶。（人行大小額普通貸記強制清算的原因，這個可以看我以前的文章）。

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

六、總結

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

6.1 交易四個口訣

1）支付三流合一

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

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

2）跨系統三狀態

任何跨系統的交易都要設置三種狀態“成功、失敗、處理中”，其中成功、失敗稱為“終態”，“處理中”稱為運行態，支付系統的賬務處理只能根據終態來進行最終的資金結算處理，處理中的狀態都不能進行結算。

3）異常查退合一

由于經常會有處理中的狀態出現，為了保障客戶資金到賬的時效性，因此需要做異常的查退處理來實現支付結果盡快一致。

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

4）差錯三賬調平

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

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

6.2 交易分賬模式

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

1）即時到賬模式

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

2）擔保交易模式

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

6.3 分賬交易流程

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

6.4 退款交易流程

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

6.5 交易設計方案

主要是幾張圖由場景到最終實現的關聯關系要能夠理解。