在新零售SaaS收銀系統(tǒng)中，支付核心起到了至關(guān)重要的作用，這篇文章里，作者針對(duì)支付核心做了解讀和梳理，想了解的同學(xué)，不妨來(lái)看一下。

一、概念

支付核心，是處理不同業(yè)務(wù)線支付的核心模塊。

具體做的內(nèi)容就是：一筆訂單由交易系統(tǒng)請(qǐng)求下單，支付系統(tǒng)將此賬單的支付指令，傳遞給上游支付渠道，最終完成支付并處理業(yè)務(wù)支付結(jié)果。

這其中，在新零售SaaS收銀系統(tǒng)中，支付核心起到了至關(guān)重要的作用。

它承載著內(nèi)部業(yè)務(wù)和外部渠道支付，最終促成交易閉環(huán)。

二、收銀臺(tái)API的本質(zhì)

用戶在收銀臺(tái)完成下單支付，在整個(gè)收銀系統(tǒng)中不光要靠線上/線下的可視化收銀臺(tái)，還需要一套接口收銀臺(tái)。

在準(zhǔn)備封裝前 ，我們先來(lái)深挖一下收銀臺(tái)的本質(zhì)是什么?

在傳統(tǒng)收銀臺(tái)前，收銀臺(tái)是要促成買家和賣家交易并完成支付。也就是我們常說(shuō)的，一手交錢一手交貨。錢從買家的錢包轉(zhuǎn)移到了賣家的錢包中。

在現(xiàn)代收銀臺(tái)前，收銀臺(tái)可能是線下終端收銀臺(tái)，也可能是線上收銀臺(tái)。賣家將商品或服務(wù)提供給買家，錢從買家賬戶轉(zhuǎn)移到賣家賬戶中。

不管在傳統(tǒng)收銀臺(tái)，還是現(xiàn)代收銀臺(tái)，要完成交易，支付是其中必備的一環(huán)。

支付：就需要將錢從買方轉(zhuǎn)移到賣方。其中交易媒介就是我們的賬戶。

當(dāng)我們站在最上層結(jié)算銀行的角度來(lái)看這個(gè)支付過(guò)程時(shí)，它就是對(duì)賬戶進(jìn)行借記貸記操作。

對(duì)賬戶的操作有：存錢，轉(zhuǎn)賬，消費(fèi)，退款等操作。銀行方會(huì)對(duì)此封裝出各類操作的接口，提供給下游平臺(tái)使用。

針對(duì)這些操作，第三方支付渠道，銀行等會(huì)結(jié)合下層應(yīng)用的場(chǎng)景，封裝出不同的支付產(chǎn)品，來(lái)供它的下游平臺(tái)或商戶使用。

新零售SaaS軟件服務(wù)商，也需要根據(jù)自己的客戶業(yè)務(wù)場(chǎng)景，封裝出一套收銀臺(tái)接口。同時(shí)也需要選擇適合自己業(yè)務(wù)場(chǎng)景的渠道支付產(chǎn)品進(jìn)行對(duì)接。最終來(lái)為客戶的收銀場(chǎng)景提供支付服務(wù)。

收銀臺(tái)的API封裝本質(zhì)：就是根據(jù)不同的支付業(yè)務(wù)場(chǎng)景，傳遞不同的支付指令，來(lái)對(duì)買方和賣方的賬戶進(jìn)行借記貸記操作。

只不過(guò)這其中經(jīng)由多個(gè)下層，根據(jù)服務(wù)業(yè)務(wù)場(chǎng)景，層層封裝成該渠道的支付產(chǎn)品而已。

那么支付核心到底要如何封裝收銀臺(tái)API?

又該如何確定支付渠道產(chǎn)品是否能支對(duì)接呢？

三、如何封裝收銀臺(tái)API

1. 分析行業(yè)不同業(yè)務(wù)線的支付場(chǎng)景

有線上支付、線下支付、智能機(jī)具，禮品卡券等支付場(chǎng)景。

• 線上支付：主要是 小程序支付，公眾號(hào)支付，H5支付，PC網(wǎng)關(guān)支付、APP支付等
• 線下支付：銀行卡支付，云閃付，微信、支付寶等錢包類支付，數(shù)字人民幣等
• 智能收銀終端： 智能POS,MIS-POS,聚合人臉支付等
• 卡券：會(huì)員卡、優(yōu)惠券支付、次卡、電子禮品卡、電子現(xiàn)金券等

2. 選擇合適的支付方式

根據(jù)公司不同業(yè)務(wù)線的支付場(chǎng)景,我們需要找到合適的支付渠道產(chǎn)品。

結(jié)合銀行、第三方提供的支付渠道產(chǎn)品，新零售SaaS收銀行業(yè)的業(yè)務(wù)，需要B掃C，C掃B，JSAPI,APP，刷臉等支付方式。

當(dāng)我們確定好所選支付渠道產(chǎn)品時(shí)，首要考慮的內(nèi)容就是支付渠道產(chǎn)品的應(yīng)用場(chǎng)景，

是否適配新零售SaaS收銀系統(tǒng)的業(yè)務(wù)線。其次考慮通道的安全性，穩(wěn)定性，手續(xù)費(fèi)率等問(wèn)題。

我們這里主要從接口角度，來(lái)分析業(yè)務(wù)場(chǎng)景是否適配。

那么我們?cè)撊绾螌徍饲澜涌谖臋n是否適配新零售SaaS收銀系統(tǒng)業(yè)務(wù)場(chǎng)景呢？

四、審核渠道接口文檔

此小節(jié)，著重從開(kāi)發(fā)角度來(lái)審核渠道支付接口是否符合業(yè)務(wù)所需。

接口文檔中也是，只以核心參數(shù)拿出來(lái)作為判斷依據(jù)。

根據(jù)上面分析的新零售SaaS收銀系統(tǒng)業(yè)務(wù)線， 我們確定了要對(duì)接B掃C，JSAPI（小程序，掃碼點(diǎn)餐）支付，C掃B接口 還有刷臉支付。

為了促使交易支付流程的完整性，不只是需要支付操作的接口，還需要訂單查詢、退款、退款查詢、撤銷、異步回調(diào)推送訂單狀態(tài)。

接下來(lái)就需要明確支付通道方提供的接口中必填業(yè)務(wù)參數(shù)， 新零售SaaS收銀系統(tǒng)是否支持對(duì)接。

同時(shí)，新零售SaaS收銀系統(tǒng)的支付參數(shù)必傳項(xiàng)，通道方是否支持。

1. B掃C

此接口需要注意的點(diǎn)：上游平臺(tái)商戶號(hào)，商戶訂單號(hào)，付款碼， 付款金額，單品優(yōu)惠詳情、落單號(hào)。

上游平臺(tái)商戶號(hào)（必填）：這個(gè)參數(shù)是每個(gè)接口必須得，它是上游渠道判斷指令來(lái)源于哪個(gè)商戶的重要依據(jù)。

商戶平臺(tái)唯一訂單號(hào)（必填）：需要注意訂單號(hào)長(zhǎng)度超長(zhǎng)的情況或定制化規(guī)則。不同通道要求不同，開(kāi)發(fā)需要單獨(dú)來(lái)處理。

付款金額（必填）：?jiǎn)挝灰辞迨欠诌€是元，在實(shí)際編碼的過(guò)程中，開(kāi)發(fā)需要使用BigDecaimal類型轉(zhuǎn)換，警惕使用Double方式進(jìn)行轉(zhuǎn)換，從而來(lái)避免精度丟失問(wèn)題。

單品優(yōu)惠詳情（非必填）：渠道方或者商戶想要針對(duì)商品優(yōu)惠，開(kāi)發(fā)需要上傳此信息給上游渠道。

此字段需要格外注意商戶傳入的商品名稱是否有特殊字符，開(kāi)發(fā)需要進(jìn)行單獨(dú)過(guò)濾或者編碼，防止支付驗(yàn)簽報(bào)錯(cuò)。

回調(diào)推送地址（非必填）：接口中存在此字段建議上傳，能夠異步接收訂單狀態(tài)。不過(guò)度依賴程序定時(shí)任務(wù)查詢，減輕服務(wù)器壓力。

響應(yīng)參數(shù)中的落單號(hào)（非必填）：此字段如果接口能返回最好也要記錄下來(lái)，方便商家給客戶退款時(shí)，直接掃描落單號(hào)直接發(fā)起退款。從而減少商家輸入商戶訂單號(hào)，這種繁瑣的退款步驟。

2. C掃B

此接口響應(yīng)字段中的 支付鏈接（必填），是預(yù)下單之后返回的付款二維碼。掃描付款二維碼 進(jìn)入到線上收銀臺(tái) 進(jìn)行支付。

其他字段解讀同【B掃C】。

3. JSAPI

使用場(chǎng)景主要在微信小程序或者支付寶小程序。

如果是微信場(chǎng)景：接口中小程序APPID和 用戶標(biāo)識(shí) 是必須傳入的。響應(yīng)結(jié)果中會(huì)返回拉起微信支付控件的必備參數(shù)。

如果是支付寶場(chǎng)景：接口用戶標(biāo)識(shí)必傳。響應(yīng)結(jié)果中返回支付寶訂單號(hào)，是用來(lái)拉起支付寶控件。

其他字段解讀同【B掃C】。

說(shuō)明：微信小程序支付 和 支付寶小程序支付；對(duì)接此方法，還需要對(duì)接回調(diào)方法。

關(guān)鍵點(diǎn)：回調(diào)地址，微信subAppId，微信或支付寶用戶ID。

4. 刷臉支付

刷臉支付，分為支付寶刷臉和微信刷臉。

此場(chǎng)景下依賴前端POS或IOT小程序較多。更多的是需要前端去初始化調(diào)用官方提供的文檔接口。

支付寶，是前端直接調(diào)用平臺(tái)接口獲取刷臉付款碼，然后調(diào)用B掃C接口便可以拉起支付。

微信，是需要后臺(tái)提供一個(gè)接口拉獲取微信刷臉調(diào)用憑證。

最終，前端調(diào)用刷臉識(shí)別SDK，獲取刷臉付款碼后，調(diào)用B掃C進(jìn)行支付。

這里是微信獲取刷臉調(diào)用憑證的接口，核心參數(shù)展示。

5. 訂單支付查詢

訂單支付狀態(tài)不明確時(shí)、需要查詢訂單支付狀態(tài)等詳細(xì)信息時(shí)，需要調(diào)用此接口。

核心請(qǐng)求參數(shù)，通常是只需要傳入兩個(gè)參數(shù)即可。平臺(tái)商戶號(hào)和訂單號(hào)（商戶平臺(tái)支付訂單號(hào)或者是上游平臺(tái)的支付訂單號(hào)）。

很多渠道方支付文檔，都會(huì)優(yōu)先使用渠道方的訂單號(hào)。但站在開(kāi)發(fā)對(duì)接者的角度是有漏洞的。

比如：新零售SaaS收銀系統(tǒng)一筆支付單，請(qǐng)求上游渠道方支付完成，會(huì)存在無(wú)法拿到支付響應(yīng)結(jié)果的情況。

因?yàn)樵谥Ц哆^(guò)程中，網(wǎng)絡(luò)波動(dòng)后請(qǐng)求超時(shí)，導(dǎo)致商戶收銀系統(tǒng)無(wú)法拿到上游返回的支付訂單號(hào)。

所以此時(shí)，就需要訂單支付查詢接口，有一個(gè)商戶平臺(tái)支付訂單號(hào)（下文中的orderCode）的 參數(shù)。

當(dāng)存在這種情況時(shí)，商戶收銀系統(tǒng)依舊可以查詢到支付結(jié)果。而不是，只能依賴渠道方訂單號(hào)。

我們?cè)趯徍饲澜涌跁r(shí)，如果只能根據(jù)渠道方訂單號(hào)查詢訂單詳情，一定要向渠道方要求添加上商戶平臺(tái)支付訂單號(hào)（orderCode）此參數(shù)。

6. 退款

核心請(qǐng)求參數(shù)：

退款必備關(guān)鍵性請(qǐng)求參數(shù):refundNo（商戶退款訂單號(hào)，有時(shí)候此參數(shù)也不一定） 或 orderCode（商戶支付訂單號(hào)）；

如果存在多次退款的情況，reundNo（商戶退款訂單號(hào)）最好要有，方便追蹤退款記錄。

其他字段解讀同【B掃C】。

7. 退款查詢

此接口中，優(yōu)先以商戶平臺(tái)單號(hào)查詢，原因同【訂單支付查詢】。

其他字段解讀同【B掃C】。

8. 撤銷

涉及字段解讀同【B掃C】。

9. 回調(diào)推送

對(duì)接線上JSAPI 、C掃B.接口必接。退款和支付都會(huì)存在回調(diào)信息推送。

如果支付或退款回調(diào)地址是以下拼裝的后綴是訂單ID這種方式，需要注意下通道退款推送規(guī)則，規(guī)則可能有不同。

如:https://www.xx.cn/pay/orderPay/xx/1 是支付推送，https://www.xx.cn/pay/orderPay/xx/2 是退款推送地址。

通道方通常會(huì)按照此地址直接進(jìn)行推送，但也會(huì)有少數(shù)通道按照支付接口中傳入的回調(diào)地址進(jìn)行推送。

涉及字段解讀同【B掃C】。

回調(diào)接口響應(yīng)必備參數(shù)：

響應(yīng)內(nèi)容按照接口文檔要求即可，通常是返回 success,fail。

五、支付核心流程

一筆支付請(qǐng)求來(lái)到支付核心要經(jīng)歷那些流程呢？

1. 從不同應(yīng)用場(chǎng)景中發(fā)來(lái)了一筆支付請(qǐng)求，進(jìn)入到收銀臺(tái)API中
2. 檢查業(yè)務(wù)參數(shù),是否滿足當(dāng)前支付操作的業(yè)務(wù)要求
3. 冪等性驗(yàn)證
4. 組裝交易數(shù)據(jù)：如新零售SaaS收銀系統(tǒng)中的商戶基本信息，初始化狀態(tài)
5. 獲取到支付賬號(hào)路由
6. 組裝交易數(shù)據(jù)：支付渠道配置的商戶號(hào)等信息
7. 根據(jù)交易信息創(chuàng)建支付單
8. 支付發(fā)送前，封裝符合通道要求的業(yè)務(wù)參數(shù)。如:基本支付信息，加簽，加密等
9. 支付發(fā)送中，使用符合通道要求的請(qǐng)求方式，數(shù)據(jù)格式等。如post方式請(qǐng)求，使用json格式傳遞數(shù)據(jù)等
10. 支付發(fā)送后，渠道方返回響應(yīng)結(jié)果并驗(yàn)證結(jié)果。如：驗(yàn)簽，解密。支付信息檢查是否預(yù)期返回。
11. 更新支付單，將支付狀態(tài)等業(yè)務(wù)信息進(jìn)行同步。如：更新?tīng)顟B(tài)支付狀態(tài)，支付訂單號(hào)，落單號(hào)，渠道號(hào)等信息