支付的業(yè)務架構和流程是相對復雜的，那么，你知道支付的核心處理流程是什么樣的嗎？關于這個問題，我們不妨從這篇文章里尋找答案。本篇文章里，作者就結合多張圖做出拆解，一起來看看吧。

前幾天我們解析了支付核心的產(chǎn)品架構，整個產(chǎn)品架構可以抽象出以下的業(yè)務架構。

各業(yè)務終端通過收銀臺或者開放API接入支付核心，發(fā)起支付業(yè)務請求，通過支付核心完成自己的支付業(yè)務.

支付核心主要由支付處理核心、支付風控、支付路由、支付網(wǎng)關等4個核心部分組成。

當然整個支付業(yè)務的實現(xiàn)也離不開其他層的支持，如交易核心、清結算、賬務核心、以及用戶中心、商品中心、合同中心等。

在這樣的框架下，支付的核心處理流程是什么樣的呢？我們通過3張圖可以展開這部分的分析。

一、全局支付流程剖析

站在全局的視角看支付流程，了解清楚從用戶挑選商品開始，到最后支付完成，不同系統(tǒng)層之間是如何協(xié)調完成的，看下面第1張圖。

橫向看，代表支付的進程，包含了交易處理環(huán)節(jié)、收銀臺處理環(huán)節(jié)、支付處理環(huán)節(jié)、支付應答環(huán)節(jié)；該4大環(huán)節(jié)分別解決了交易單的生成、收銀臺的封裝和展示、請求支付渠道完成支付、支付后的各方應答反饋。

縱向看，是支付在多層之間的協(xié)同交互，主要是客戶端、交易核心、支付核心以及外部支付渠道側的業(yè)務處理，這里我們弱化了與其他如賬務核心的交互。

1. 交易處理完成業(yè)務單據(jù)生成

用戶支付的前提是要買東西，因此需要先選擇自己需要的商品，并且生成對應的訂單以后，才能進入到支付環(huán)節(jié)。

1）去結算

用戶在購物車選擇了自己要結算的商品，去結算。

2）交易計價

這時候需要計算出本單相關的費用，例如優(yōu)惠券的使用、總優(yōu)惠券金額、本單應付金額等信息。

3）提交訂單

用戶提交訂單以后在交易核心生成交易單據(jù)，并完成卡券的凍結、訂單的創(chuàng)建、賬單的創(chuàng)建，如此完成了整個業(yè)務層交易類單據(jù)的生成。

2. 收銀臺從無到有

交易層業(yè)務處理完成以后，接下來就開始進入支付階段的，支付的起點是收銀臺。

1）跳轉到收銀臺

有了完整的業(yè)務單據(jù)信息以后就可以請求支付核心獲得本筆交易的收銀臺的模版，然后反饋客戶端，跳轉到收銀臺頁面，進入到支付流程中。

我們在收銀臺模版一文詳細介紹了在客戶端是如何獲得可用收銀臺的，這里就不再詳述了。

到了收銀臺頁面，展示了本單支持的支付方式，用戶選擇對應的支付方式，例如微信支付，就正式進入了支付處理階段。

3. 支付處理，條條大路通羅馬

不同的終端類型、如網(wǎng)站、H5、APP等，就有不同的支付流程，比如在網(wǎng)站進行支付，就無法跳轉到支付應用中，但可以跳轉到銀行網(wǎng)銀或者掃碼支付。

但整體來看整個支付流程應該分成三大部分的流程，客戶端的流程、支付核心的流程、與渠道的交互流程。

1）終端支付流程

不同的終端形成了不同的終端支付流程，是展示收款碼還是跳轉到網(wǎng)上銀行，支付成功后落地頁是什么。

2）支付核心流程

是針對“終端+支付方式”所形成的支付業(yè)務處理，如APP里的微信支付、網(wǎng)站的快捷支付、H5內的快捷支付等，都有相似的“主流程”和“差異化的分支流程”。

但是支付核心的主流程如上圖所示，不管什么支付方式都包含了參數(shù)的交易、交易信息補全、風控與路由處理、支付單的生成及渠道請求報文的封裝、提交渠道等相同的環(huán)節(jié)。

3）與渠道的交互流程

不同的支付方式就決定了如何與渠道進行交互，有的渠道可能需要預下單、有的渠道可能就不需要、在預下單以后渠道就會返回不同的“支付標識”，如token、url等，這是支付下一步的關鍵參數(shù)。

如微信的JSAPI支付的交互流程。

第一次預下單交互，調用預下單接口，渠道返回了預付單標識。

通過JSAPI下單接口獲取到發(fā)起支付的必要參數(shù)prepay_id，如上圖，然后使用微信支付提供的前端JS方法調用公眾號支付，在請求參數(shù)中使用prepay_id，封裝到package參數(shù)中。

4. 支付各方應答

支付發(fā)起以后，等待支付渠道的結果通知，在發(fā)起支付請求時我們預留了“通知地址”，渠道會將支付結果告知該地址。

支付核心根據(jù)渠道的結果通知，對各方進行應答。

1）客戶端向用戶應答

支付成功了要告訴用戶，如果支付是跳轉到了渠道的收銀臺，那么用戶在渠道的支付應用內已經(jīng)知道了支付成功的結果。

只不過，用戶調回商家應用以后會到達商戶應用的支付成功通知頁面。

至此，客戶端的支付流程就全部結束了，但是整個支付還沒有結束，支付系統(tǒng)還要進行各方通知。

2）通知交易支付結果

支付核心需要將支付結果告知交易系統(tǒng)，畢竟人家是業(yè)務方，支付成功后還要進行訂單履約等一系列后續(xù)動作。

交易接收到支付成功的通知以后，會更新交易單、訂單、賬單等的單據(jù)狀態(tài)為成功。

然后對卡券發(fā)起核銷處理，訂單進入到履約階段。

卡券的處理一般是下單成功以后進行凍結，支付成功以后進行核銷，也就是如上圖中券狀態(tài)變成已使用或者已核銷。

3）通知路由，進行數(shù)據(jù)累加

因為有些渠道需要計算累加交易，以進行交易的分流，就是每個渠道都提供的交易，不能0交易。

此時路由就需要記錄每個通道的累計交易情況，以便后續(xù)進行通道篩選時使用。

4）通知賬務記賬

當然，支付成功以后記賬是少不了的，這一點就不過多描述了。

二、支付核心主流程、11個環(huán)節(jié)

上面我們介紹了全局視角的支付流程，當然還能進行細化，比如每一個支付方式的具體支付流程在第1張圖中進行展開細化。

了解了全局流程以后，應該支付支付請求到了支付核心以后的處理流程是什么樣的。

這里要清楚，每一個支付方式，路由篩選出了不同的通道，都會形成一個獨特的支付處理流程，快捷支付、網(wǎng)銀支付；A支付機構的快捷支付、B支付機構的快捷支付等所形成的支付核心的處理流程是存在差異的。

當然，要想把控好每一個支付方式在每一個通道的處理流程，首先要先把握“主線流程”。

主線流程不會因為支付方式的不同，選擇的渠道不同而不同。

真正不同的是渠道的差異化造成的，所以我們把支付核心主流程抽象出11個環(huán)節(jié)，這就是第2張圖。

可以根據(jù)實際的業(yè)務需要，對該圖的環(huán)節(jié)進行增加或者刪減，但大同小異。

上圖的11個環(huán)節(jié)可以再次劃分成客戶端支付請求處理、支付核心請求報文處理、請求渠道發(fā)起支付、支付應答處理等4個階段。

1. 客戶端支付請求處理

客戶端或者內部業(yè)務系統(tǒng)按照支付接入接口要求傳入支付請求，需要進行一系列的校驗和信息補全處理。

如上圖所示，應該判斷該請求是否有當前支付業(yè)務的請求權限，并校驗請求參數(shù)是否合法，比如必填參數(shù)是否正確、參數(shù)格式是否正確、枚舉類參數(shù)的枚舉是否正確等。

然后對交易信息進行補全，比如增加交易狀態(tài)、其他一些交易信息補充，為后續(xù)的請求路由系統(tǒng)以及生成支付單做準備。

2. 支付核心支付報文處理

交易信息完整以后，接下來就是請求路由獲取可用支付通道。

通過路由系統(tǒng)返回的通道編號，補全渠道信息，例如該渠道的商戶號信息、通訊協(xié)議信息、以及一些其他差異化數(shù)據(jù)。

3. 請求渠道發(fā)起支付

支付單生成以后，并且補全了渠道需要的參數(shù)以后，就開始準備向渠道發(fā)起支付申請了。

按照渠道的協(xié)議要求，封裝協(xié)議參數(shù)，進行加密、簽名，封裝成渠道要求的報文格式。

然后，請求相應接口發(fā)起支付。

并且，通知支付單模塊、路由系統(tǒng)、記賬系統(tǒng)等內部系統(tǒng)更新狀態(tài)以及下一步業(yè)務的預處理。

4. 支付應答

將支付報文提交給渠道以后，就等著渠道返回支付結果了。

接收到支付結果以后，更新支付單相關狀態(tài)，并通知交易系統(tǒng)、業(yè)務請求系統(tǒng)、賬務系統(tǒng)等內部系統(tǒng)進行支付成功后的業(yè)務處理。

至此，一筆支付的處理就結束了。

以上的主流程，可以在每一個支付方式上進行差異化調整，細化。

三、支付單據(jù)結構、2單號模型

因為支付不一定請求一次就成功了；

可能第一次用戶取消了，要重新發(fā)起支付，或者第一次失敗了，系統(tǒng)要再次發(fā)起支付；

從而，一筆支付可能需要與渠道交互多次。

1. 渠道的多次請求要求

而不同渠道對于重復請求，對單號有不同的要求，有的可能需要取消原單，以新單發(fā)起支付，以避免重復支付或者付款，有的可能沒有這個要求，需要使用原單號發(fā)起支付。

這一點要跟退款重新發(fā)起區(qū)別開，渠道對重新發(fā)起退款的要求是使用原單號進行退款，不需要更換退款單號，這一點與重新發(fā)起支付請求有區(qū)別。

2. 支付核心的單據(jù)結構設計

考慮到支付的重新發(fā)起情況，我們可以將支付單的結構設置成兩層結構，由支付單和支付流水組成，一筆支付單對應對比支付流水。

支付單與業(yè)務請求一一對應，支付單與支付流水一對多，支付流水與渠道請求一一對應。

該結構如下圖所示，這是我們要關注的第3張圖。

這樣的機構下會產(chǎn)生至少3個單號，業(yè)務訂單號、支付單號、支付請求號（支付流水號），形成的表結構和對應關系如下圖所示。

以上就是支付核心的全部支付流程分析，具體的支付方式的差異化流程，大家可以自主研究。