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

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

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

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

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

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

一、全局支付流程剖析

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

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

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

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

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

1）去結(jié)算

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

2）交易計(jì)價

這時候需要計(jì)算出本單相關(guān)的費(fèi)用，例如優(yōu)惠券的使用、總優(yōu)惠券金額、本單應(yīng)付金額等信息。

3）提交訂單

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

2. 收銀臺從無到有

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

1）跳轉(zhuǎn)到收銀臺

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

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

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

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

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

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

1）終端支付流程

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

2）支付核心流程

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

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

3）與渠道的交互流程

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

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

第一次預(yù)下單交互，調(diào)用預(yù)下單接口，渠道返回了預(yù)付單標(biāo)識。

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

4. 支付各方應(yīng)答

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

支付核心根據(jù)渠道的結(jié)果通知，對各方進(jìn)行應(yīng)答。

1）客戶端向用戶應(yīng)答

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

只不過，用戶調(diào)回商家應(yīng)用以后會到達(dá)商戶應(yīng)用的支付成功通知頁面。

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

2）通知交易支付結(jié)果

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

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

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

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

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

因?yàn)橛行┣佬枰?jì)算累加交易，以進(jìn)行交易的分流，就是每個渠道都提供的交易，不能0交易。

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

4）通知賬務(wù)記賬

當(dāng)然，支付成功以后記賬是少不了的，這一點(diǎn)就不過多描述了。

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

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

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

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

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

主線流程不會因?yàn)橹Ц斗绞降牟煌?，選擇的渠道不同而不同。

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

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

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

1. 客戶端支付請求處理

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

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

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

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

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

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

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

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

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

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

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

4. 支付應(yīng)答

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

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

至此，一筆支付的處理就結(jié)束了。

以上的主流程，可以在每一個支付方式上進(jìn)行差異化調(diào)整，細(xì)化。

三、支付單據(jù)結(jié)構(gòu)、2單號模型

因?yàn)橹Ц恫灰欢ㄕ埱笠淮尉统晒α耍?/p>

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

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

1. 渠道的多次請求要求

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

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

2. 支付核心的單據(jù)結(jié)構(gòu)設(shè)計(jì)

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

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

該結(jié)構(gòu)如下圖所示，這是我們要關(guān)注的第3張圖。

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

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