把通用的業(yè)務(wù)抽象整理為一套工具，為多個(gè)業(yè)務(wù)線使用，支付中臺(tái)也是如此。本文詳細(xì)解析新零售中的“支付中臺(tái)”，該怎么做以及相關(guān)模塊和場(chǎng)景，希望對(duì)你有所幫助。

中臺(tái)，就是把通用業(yè)務(wù)，抽象整理成一套工具。供多個(gè)業(yè)務(wù)線使用。

同理，支付中臺(tái)，就是將支付能力抽象整理出的一套支付工具，能同時(shí)支撐多個(gè)業(yè)務(wù)線使用。

用統(tǒng)一的平臺(tái)來完成支付相關(guān)的共通流程，進(jìn)行模塊化封裝。

一、為什么，怎么做

在最初，SaaS軟件服務(wù)商，只有一條業(yè)務(wù)線時(shí)，只需要做一套支付。當(dāng)業(yè)務(wù)高速發(fā)展時(shí)，SaaS軟件服務(wù)商存在多條業(yè)務(wù)線，對(duì)支付的管理和功能上就會(huì)有很多重合環(huán)節(jié)。

1.1 為什么

SaaS服務(wù)商對(duì)這些環(huán)節(jié)做單獨(dú)開發(fā)和運(yùn)營配置，就會(huì)很耗費(fèi)人力成本，降低了SaaS服務(wù)商效率。比如：運(yùn)營人員需要同時(shí)管理多個(gè)支付渠道和交易流水，還需要為商戶配置支付賬號(hào)。

SaaS軟件服務(wù)商需要一套解決方案，來解決支付服務(wù)效率低的問題。

如果實(shí)現(xiàn)了支付中臺(tái)，運(yùn)營人員可以通過一個(gè)平臺(tái)進(jìn)行管理多個(gè)商戶進(jìn)件、商戶支付配置、交易流水對(duì)賬、分潤、分賬等信息。

開發(fā)人員，能夠在支付中臺(tái)的架構(gòu)下，快速進(jìn)行支付渠道對(duì)接或者引入新的業(yè)務(wù)模式。從而滿足市場(chǎng)的需求。

為了能夠同時(shí)支持多種業(yè)態(tài)的支付業(yè)務(wù)，提升SaaS服務(wù)商的核心競(jìng)爭(zhēng)力，搭建支付中臺(tái)迫在眉睫。

1.2 如何做

我們來分析一下SaaS軟件服務(wù)商的收銀業(yè)務(wù)線，其中主要包含SaaS收銀業(yè)務(wù)線和大型商超收銀業(yè)務(wù)線。終端設(shè)備主要有POS，小程序，WEB,刷臉設(shè)備，碼牌和APP。

用戶使用終端進(jìn)行交易時(shí)，涉及到的核心支付業(yè)務(wù)流程主要是發(fā)起支付，查詢訂單，退款和撤銷。

SaaS軟件服務(wù)商要使得商家店面支付業(yè)務(wù)流程跑通，不能僅僅只有支付功能。還需要對(duì)商戶信息進(jìn)件報(bào)備，開通商戶支付賬號(hào)并進(jìn)行配置，對(duì)支付賬號(hào)配置支付路由渠道，提供多維度對(duì)賬報(bào)表，為代理商提供分潤服務(wù)，以及給商戶提供分賬服務(wù)。

二、支付中臺(tái)的5大模塊

下面以商戶賬號(hào)配置、支付、對(duì)賬、分潤、分賬 五個(gè)模塊來搭建支付中臺(tái)。

2.1 商戶賬號(hào)配置模塊

賬號(hào)配置，就是為商家提供收款賬號(hào)配置服務(wù)。對(duì)SaaS軟件服務(wù)商來說，支付最終服務(wù)的對(duì)象就是商家。商家開店要收款，最終錢要收到商戶指定的賬號(hào)內(nèi)。那么商戶的支付賬號(hào)從哪里來？運(yùn)營人員如何進(jìn)行配置呢？

商戶要擁有支付收款能力，必須得向第三/四方支付渠道平臺(tái)申請(qǐng)（將營業(yè)資質(zhì)等信息報(bào)備），獲得支付入網(wǎng)許可，這就是商戶進(jìn)件。

運(yùn)營人員或代理商可在支付中臺(tái)替商戶進(jìn)件，幫商家免去進(jìn)件繁瑣過程。

商戶進(jìn)件通常分為兩類：一類是直連模式，一類是服務(wù)商模式。

直連模式就是商戶直接在第三/四方支付渠道下申請(qǐng)一個(gè)支付商戶號(hào)。

服務(wù)商模式就是SaaS軟件服務(wù)商或者代理商在第三/四方支付渠道下，幫商戶申請(qǐng)支付賬號(hào)，將該支付商戶掛到自己服務(wù)商名下。關(guān)于商戶進(jìn)件，可以由商戶自主選擇。兩者最大的不同就是，支付費(fèi)率不同。

通常，商戶會(huì)選擇使用服務(wù)商模式，因?yàn)橹Ц顿M(fèi)率更低。其中服務(wù)商模式不只是支持默認(rèn)服務(wù)商（SaaS軟件服務(wù)商），還可以為代理商添加自己的支付渠道服務(wù)商信息。

商戶選擇走服務(wù)商模式，只要店面有支付交易流水，便會(huì)為服務(wù)商帶來睡后收益。這也是為什么擁有高頻交易場(chǎng)景的軟件服務(wù)商愿意去做支付中臺(tái)的一個(gè)主要原因。

如何配置支付賬號(hào)？

支付中臺(tái)擁有支付賬號(hào)配置權(quán)限的就只有兩種角色：運(yùn)營人員和代理商。支付中臺(tái)有多個(gè)支付渠道，需要由運(yùn)營人員給代理商賦值支付渠道配置權(quán)限。

對(duì)商戶下的多個(gè)門店，進(jìn)行配置不同的支付渠道。配置完渠道之后，可以對(duì)不同的支付環(huán)境設(shè)置路由配置。

2.2 支付核心系統(tǒng)模塊

支付，就是用戶購買商品服務(wù)，并在商戶終端收銀臺(tái)完成付款操作。支付收銀臺(tái)終端環(huán)境有POS、小程序、刷臉設(shè)備、WEB頁面、碼牌等等。業(yè)務(wù)流程圍繞支付的主要環(huán)節(jié)就是：支付，查詢，退款，撤銷。

對(duì)于終端收銀臺(tái)的業(yè)務(wù)流程抽象，我們可以封裝出一套支付收銀臺(tái)API,后續(xù)不同業(yè)務(wù)終端可以快速嵌入到支付業(yè)務(wù)流程中。

對(duì)于支付，我們又可以按照不同的支付場(chǎng)景分為：B掃C，C掃B，JSAPI，APP支付等。

訂單完成正向交易后，還需要主動(dòng)查詢支付狀態(tài)或等待異步通知支付結(jié)果。

在支付過程中出現(xiàn)支付超時(shí)，顧客已經(jīng)支付完成，系統(tǒng)還未接收到支付成功信息，可以撤銷，金額會(huì)原路退回；如果是支付失敗，撤銷后便關(guān)閉訂單。

在正常支付成功后，可以使用退款來申請(qǐng)退款。同時(shí)可以使用退款查詢來確定最終的退款狀態(tài)。

（1）收銀臺(tái)API封裝

統(tǒng)一下單入口：B掃C,C掃B,JSAPI ，APP支付等等。

訂單查詢：訂單狀態(tài)不是最終終態(tài)時(shí)，支付等待中/退款中時(shí)，提供接口進(jìn)行輪詢查詢。

訂單撤銷：支付失敗，或支付成功但訂單超時(shí)時(shí)，發(fā)起撤銷。將關(guān)閉支付訂單，防止出現(xiàn)重復(fù)支付的情況。

退款申請(qǐng)：訂單逆向流程。

回調(diào)：支付或退款回調(diào)，上游渠道推送過來的支付或退款狀態(tài)通知。支付中臺(tái)更新訂單狀態(tài)，并對(duì)下游業(yè)務(wù)進(jìn)行同步推送狀態(tài)信息。

（2）支付核心

支付核心，處理來自上游收銀臺(tái)支付請(qǐng)求，并且根據(jù)支付賬號(hào)配置路由，確定最終執(zhí)行的支付渠道。它是一筆訂單最終完成支付，傳遞支付指令的前置條件。

（3）支付渠道

支付渠道，根據(jù)客戶不同支付場(chǎng)景，系統(tǒng)兼容對(duì)接新的支付渠道。支付渠道來完成支付中臺(tái)內(nèi)部的支付指令向外部支付渠道的傳遞。

2.3 對(duì)賬模塊

對(duì)賬，就是對(duì)門店交易數(shù)據(jù)進(jìn)行核對(duì)對(duì)比的操作，防止出現(xiàn)錯(cuò)賬問題。它對(duì)于關(guān)心店面利益的人不可或缺。

對(duì)賬從支付記錄入手。從門店、日、收銀員、POS維度進(jìn)行賬務(wù)分析。對(duì)于一些通道，財(cái)務(wù)，運(yùn)營人員還需要下載對(duì)賬文件進(jìn)行查賬。

2.4 分潤模塊

分潤，就是按照事先約定好的比例，將錢分給使用公司默認(rèn)支付渠道的代理商（支付商戶號(hào)都是掛到公司服務(wù)商名下）。以此來獎(jiǎng)勵(lì)代理商，擴(kuò)展更多商戶使用公司支付渠道進(jìn)行支付。

當(dāng)然如果商戶支付賬號(hào)進(jìn)件是代理商自己的服務(wù)商，那么SaaS軟件服務(wù)商不提供分潤服務(wù)。分潤服務(wù)需要代理商向上游支付渠道申請(qǐng)。

2.5 分賬模塊

分賬，就是錢開始是統(tǒng)一由一個(gè)收款賬號(hào)進(jìn)行收款，在分賬日時(shí)，按照事先約定好的比例對(duì)參與方進(jìn)行劃分交易收入。通常是多個(gè)分門店進(jìn)行交易，商家總部收款在分賬日時(shí)會(huì)按比例分賬。

三、4大支付場(chǎng)景

這里我們以商戶零售常見支付場(chǎng)景分類，來分析它的支付交易流程。

3.1 B掃C支付場(chǎng)景

B掃C支付，也稱為條碼支付，被掃支付。就是商家拿掃碼設(shè)備掃描顧客支付二維碼。

在零售場(chǎng)景B掃C支付方式居多，用戶只需要打開付款碼，收款操作由商家操作。

顧客在店消費(fèi)后，收銀員在終端POS收銀臺(tái)操作生成支付訂單，收銀員使用掃碼設(shè)備掃描顧客APP（微信，支付寶，云閃付）付款碼，支付中臺(tái)在收到支付請(qǐng)求后，會(huì)請(qǐng)求上游支付通道。

上游支付通道根據(jù)密碼驗(yàn)證規(guī)則來判斷是否輸入支付密碼，輸入密碼完成支付，或者不輸入密碼直接免密支付。

刷臉支付，依托于終端設(shè)備，通過面容獲取付款碼。常見的有微信刷臉和支付寶刷臉。刷臉設(shè)備其實(shí)和B掃C原理類似，只不過之前是設(shè)備掃描顧客手機(jī)，獲取的是手機(jī)付款碼支付。現(xiàn)在是設(shè)備掃描人臉獲取一個(gè)對(duì)應(yīng)的面部付款碼。之后還是調(diào)用B掃C接口進(jìn)行支付。

3.2 C掃B支付場(chǎng)景

C掃B支付，也稱為主掃支付，就是顧客掃描商家生成一個(gè)帶金額的動(dòng)態(tài)碼（只支持掃碼一次）。

由商家根據(jù)用戶選擇的商品生成支付訂單，商家點(diǎn)擊支付，終端POS副屏?xí)@示一個(gè)動(dòng)態(tài)的收款碼。

顧客掃描收款碼，手機(jī)APP會(huì)跳轉(zhuǎn)到一個(gè)帶有金額的頁面中（金額無法修改），顧客點(diǎn)擊支付，輸入密碼便完成交易。

3.3 JSAPI支付場(chǎng)景

JSAPI，就是預(yù)下單支付。顧客先下單后輸入賬單金額密碼進(jìn)行支付操作。常見的應(yīng)用場(chǎng)景有兩類：

1. 碼牌，顧客掃描靜態(tài)碼牌，手動(dòng)輸入訂單金額進(jìn)行付款。
2. 公眾號(hào)，小程序：顧客用公眾號(hào)/小程序下單，輸入密碼進(jìn)行付款。

其中碼牌，主要是小商戶，小攤販?zhǔn)褂镁佣唷?/p>

對(duì)于做小本生意購入一個(gè)終端POS設(shè)備成本較高，使用靜態(tài)碼牌收款方便省成本。當(dāng)然它的缺點(diǎn)也顯而易見，無法查詢顧客購買商品詳情。

3.4 APP支付場(chǎng)景

APP 支付，就是發(fā)生在商家APP內(nèi)的支付。

在商家APP內(nèi)發(fā)起支付時(shí)，支付中臺(tái)會(huì)請(qǐng)求上游支付通道，獲取預(yù)支付信息。

商家APP拿到支付預(yù)支付信息后，拉起本地第三方支付方式SDK（支付寶，微信等），最終在第三方應(yīng)用內(nèi)完成支付。

最終我們將業(yè)務(wù)抽象出一套圍繞支付業(yè)務(wù)為核心的支付中臺(tái)。SaaS軟件服務(wù)商可以借助支付中臺(tái)打造自己的護(hù)城河。

作為護(hù)城河主要是以下三個(gè)原因：

1. 支付能力多業(yè)務(wù)線共享，節(jié)省人力資本，提升產(chǎn)研和運(yùn)營管理效率。
2. 將原有業(yè)務(wù)系統(tǒng)支付解耦，統(tǒng)一封裝收銀API到支付中臺(tái)系統(tǒng)中，開發(fā)能快速兼容新的支付渠道，對(duì)接效率極大提升。
3. 支持多渠道切換，手續(xù)費(fèi)，傭金存在優(yōu)勢(shì)，吸引商戶使用。為公司和代理商獲得額外睡后收入，幫商戶減少支付成本。