一文搞懂，新零售 “支付中臺”

作者：瑾蘭  |  主編：陳天宇宙

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

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

用統一的平臺來完成支付相關的共通流程，進行模塊化封裝。

在最初，saas 軟件服務商，只有一條業務線時，只需要做一套支付。當業務高速發展時，saas 軟件服務商存在多條業務線，對支付的管理和功能上就會有很多重合環節

爲什麼

saas 服務商對這些環節做單獨開發和運營配置，就會很耗費人力成本，降低了 saas 服務商效率

比如：運營人員需要同時管理多個支付渠道和交易流水，還需要爲商戶配置支付賬號。

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

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

開發人員，能夠在支付中臺的架構下，快速進行支付渠道對接或者引入新的業務模式。從而滿足市場的需求。

爲了能夠同時支持多種業態的支付業務，提升 saas 服務商的核心競爭力，搭建支付中臺迫在眉睫。

如何做

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

用戶使用終端進行交易時，涉及到的核心支付業務流程主要是發起支付，查詢訂單，退款和撤銷。

saas 軟件服務商要使得商家店面支付業務流程跑通，不能僅僅只有支付功能。還需要對商戶信息進件報備，開通商戶支付賬號並進行配置，對支付賬號配置支付路由渠道，提供多維度對賬報表，爲代理商提供分潤服務，以及給商戶提供分賬服務。

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

商戶賬號配置模塊

賬號配置，就是爲商家提供收款賬號配置服務。對 saas 軟件服務商來說，支付最終服務的對象就是商家。商家開店要收款，最終錢要收到商戶指定的賬號內。那麼商戶的支付賬號從哪裏來? 運營人員如何進行配置呢？

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

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

商戶進件通常分爲兩類：一類是直連模式，一類是服務商模式。

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

服務商模式就是 saas 軟件服務商或者代理商在第三 / 四方支付渠道下，幫商戶申請支付賬號，將該支付商戶掛到自己服務商名下。關於商戶進件，可以由商戶自主選擇。兩者最大的不同就是，支付費率不同。    

通常，商戶會選擇使用服務商模式, 因爲支付費率更低。其中服務商模式不只是支持默認服務商 (saas 軟件服務商)，還可以爲代理商添加自己的支付渠道服務商信息。

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

如何配置支付賬號？

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

對商戶下的多個門店，進行配置不同的支付渠道。配置完渠道之後，可以對不同的支付環境設置路由配置。

支付核心系統模塊

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

對於終端收銀臺的業務流程抽象，我們可以封裝出一套支付收銀臺 API, 後續不同業務終端可以快速嵌入到支付業務流程中。    

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

訂單完成正向交易後，還需要主動查詢支付狀態或等待異步通知支付結果。

在支付過程中出現支付超時，顧客已經支付完成，系統還未接收到支付成功信息，可以撤銷，金額會原路退回；如果是支付失敗，撤銷後便關閉訂單。

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

（1）收銀臺 API 封裝

統一下單入口：B 掃 C,C 掃 B,JSAPI ，APP 支付等等

訂單查詢：訂單狀態不是最終終態時，支付等待中 / 退款中時，提供接口進行輪詢查詢。

訂單撤銷：支付失敗，或支付成功但訂單超時時，發起撤銷。將關閉支付訂單，防止出現重複支付的情況。

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

回調：支付或退款回調，上游渠道推送過來的支付或退款狀態通知。支付中臺更新訂單狀態，並對下游業務進行同步推送狀態信息。

（2）支付核心

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

（3）支付渠道

支付渠道, 根據客戶不同支付場景，系統兼容對接新的支付渠道。支付渠道來完成支付中臺內部的支付指令向外部支付渠道的傳遞。

對賬模塊

對賬，就是對門店交易數據進行覈對對比的操作，防止出現錯賬問題。它對於關心店面利益的人不可或缺。

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

分潤模塊

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

當然如果商戶支付賬號進件是代理商自己的服務商，那麼 saas 軟件服務商不提供分潤服務。分潤服務需要代理商向上遊支付渠道申請。

分賬模塊

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

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

B 掃 C 支付場景

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

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

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

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

刷臉支付，依託於終端設備，通過面容獲取付款碼。常見的有微信刷臉和支付寶刷臉。刷臉設備其實和 B 掃 C 原理類似，只不過之前是設備掃描顧客手機，獲取的是手機付款碼支付。現在是設備掃描人臉獲取一個對應的面部付款碼。之後還是調用 B 掃 C 接口進行支付。 

C 掃 B 支付場景

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

由商家根據用戶選擇的商品生成支付訂單，商家點擊支付，終端 POS 副屏會顯示一個動態的收款碼。

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

JSAPI 支付場景

JSAPI , 就是預下單支付。顧客先下單後輸入賬單金額密碼進行支付操作。常見的應用場景有兩類：

其中碼牌，主要是小商戶，小攤販使用居多。

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

APP 支付場景

APP 支付，就是發生在商家 APP 內的支付。

在商家 APP 內發起支付時，支付中臺會請求上游支付通道，獲取預支付信息。

商家 APP 拿到支付預支付信息後，拉起本地第三方支付方式 SDK（支付寶，微信等），最終在第三方應用內完成支付。    

最終我們將業務抽象出一套圍繞支付業務爲核心的支付中臺。saas 軟件服務商可以藉助支付中臺打造自己的護城河。作爲護城河主要是以下三個原因：

陳天宇宙

chentianyuzhou.com

你  的  最  強  支  付  軍  師

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/gQe79qo5_xVejnDY3hg_bg

猜你喜歡