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

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

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

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

一、為什么，怎么做

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

1.1 為什么

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

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

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

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

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

1.2 如何做

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

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

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

二、支付中臺的5大模塊

下面以商戶賬號配置、支付、對賬、分潤、分賬 五個模塊來搭建支付中臺。

2.1 商戶賬號配置模塊

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

B端究竟需要什么样的产品经理？

B端产品经理都是以提升供应侧的工作效率为目的，所以B端需求主要是以业务问题为导向。 这个是B端产品比较重要的一点，B端产品是服务于一个主体 ...

查看详情 >

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

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

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

直連模式就是商戶直接在第三/四方支付渠道下申請一個支付商戶號。

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

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

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

如何配置支付賬號？

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

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

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

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

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

對于支付，我們又可以按照不同的支付場景分為：B掃C，C掃B，JSAPI，APP支付等。

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

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

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

（1）收銀臺API封裝

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

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

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

退款申請：訂單逆向流程。

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

（2）支付核心

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

（3）支付渠道

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

2.3 對賬模塊

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

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

2.4 分潤模塊

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

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

2.5 分賬模塊

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

三、4大支付場景

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

3.1 B掃C支付場景

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

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

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

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

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

3.2 C掃B支付場景

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

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

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

3.3 JSAPI支付場景

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

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

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

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

3.4 APP支付場景

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

在商家APP內(nèi)發(fā)起支付時，支付中臺會請求上游支付通道，獲取預(yù)支付信息。

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

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

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

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