在新零售SaaS收銀系統中，支付核心起到了至關重要的作用，這篇文章里，作者針對支付核心做了解讀和梳理，想了解的同學，不妨來看一下。

一、概念

支付核心，是處理不同業務線支付的核心模塊。

具體做的內容就是：一筆訂單由交易系統請求下單，支付系統將此賬單的支付指令，傳遞給上游支付渠道，最終完成支付并處理業務支付結果。

這其中，在新零售SaaS收銀系統中，支付核心起到了至關重要的作用。

它承載著內部業務和外部渠道支付，最終促成交易閉環。

二、收銀臺API的本質

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

在準備封裝前 ，我們先來深挖一下收銀臺的本質是什么?

在傳統收銀臺前，收銀臺是要促成買家和賣家交易并完成支付。也就是我們常說的，一手交錢一手交貨。錢從買家的錢包轉移到了賣家的錢包中。

在現代收銀臺前，收銀臺可能是線下終端收銀臺，也可能是線上收銀臺。賣家將商品或服務提供給買家，錢從買家賬戶轉移到賣家賬戶中。

不管在傳統收銀臺，還是現代收銀臺，要完成交易，支付是其中必備的一環。

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

當我們站在最上層結算銀行的角度來看這個支付過程時，它就是對賬戶進行借記貸記操作。

對賬戶的操作有：存錢，轉賬，消費，退款等操作。銀行方會對此封裝出各類操作的接口，提供給下游平臺使用。

針對這些操作，第三方支付渠道，銀行等會結合下層應用的場景，封裝出不同的支付產品，來供它的下游平臺或商戶使用。

新零售SaaS軟件服務商，也需要根據自己的客戶業務場景，封裝出一套收銀臺接口。同時也需要選擇適合自己業務場景的渠道支付產品進行對接。最終來為客戶的收銀場景提供支付服務。

收銀臺的API封裝本質：就是根據不同的支付業務場景，傳遞不同的支付指令，來對買方和賣方的賬戶進行借記貸記操作。

只不過這其中經由多個下層，根據服務業務場景，層層封裝成該渠道的支付產品而已。

那么支付核心到底要如何封裝收銀臺API?

又該如何確定支付渠道產品是否能支對接呢？

三、如何封裝收銀臺API

1. 分析行業不同業務線的支付場景

有線上支付、線下支付、智能機具，禮品卡券等支付場景。

• 線上支付：主要是 小程序支付，公眾號支付，H5支付，PC網關支付、APP支付等
• 線下支付：銀行卡支付，云閃付，微信、支付寶等錢包類支付，數字人民幣等
• 智能收銀終端： 智能POS,MIS-POS,聚合人臉支付等
• 卡券：會員卡、優惠券支付、次卡、電子禮品卡、電子現金券等

2. 選擇合適的支付方式

根據公司不同業務線的支付場景,我們需要找到合適的支付渠道產品。

結合銀行、第三方提供的支付渠道產品，新零售SaaS收銀行業的業務，需要B掃C，C掃B，JSAPI,APP，刷臉等支付方式。

當我們確定好所選支付渠道產品時，首要考慮的內容就是支付渠道產品的應用場景，

是否適配新零售SaaS收銀系統的業務線。其次考慮通道的安全性，穩定性，手續費率等問題。

我們這里主要從接口角度，來分析業務場景是否適配。

那么我們該如何審核渠道接口文檔是否適配新零售SaaS收銀系統業務場景呢？

四、審核渠道接口文檔

此小節，著重從開發角度來審核渠道支付接口是否符合業務所需。

接口文檔中也是，只以核心參數拿出來作為判斷依據。

根據上面分析的新零售SaaS收銀系統業務線， 我們確定了要對接B掃C，JSAPI（小程序，掃碼點餐）支付，C掃B接口 還有刷臉支付。

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

接下來就需要明確支付通道方提供的接口中必填業務參數， 新零售SaaS收銀系統是否支持對接。

同時，新零售SaaS收銀系統的支付參數必傳項，通道方是否支持。

1. B掃C

此接口需要注意的點：上游平臺商戶號，商戶訂單號，付款碼， 付款金額，單品優惠詳情、落單號。

上游平臺商戶號（必填）：這個參數是每個接口必須得，它是上游渠道判斷指令來源于哪個商戶的重要依據。

商戶平臺唯一訂單號（必填）：需要注意訂單號長度超長的情況或定制化規則。不同通道要求不同，開發需要單獨來處理。

付款金額（必填）：單位要看清是分還是元，在實際編碼的過程中，開發需要使用BigDecaimal類型轉換，警惕使用Double方式進行轉換，從而來避免精度丟失問題。

單品優惠詳情（非必填）：渠道方或者商戶想要針對商品優惠，開發需要上傳此信息給上游渠道。

此字段需要格外注意商戶傳入的商品名稱是否有特殊字符，開發需要進行單獨過濾或者編碼，防止支付驗簽報錯。

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

響應參數中的落單號（非必填）：此字段如果接口能返回最好也要記錄下來，方便商家給客戶退款時，直接掃描落單號直接發起退款。從而減少商家輸入商戶訂單號，這種繁瑣的退款步驟。

2. C掃B

此接口響應字段中的 支付鏈接（必填），是預下單之后返回的付款二維碼。掃描付款二維碼 進入到線上收銀臺 進行支付。

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

3. JSAPI

使用場景主要在微信小程序或者支付寶小程序。

如果是微信場景：接口中小程序APPID和 用戶標識 是必須傳入的。響應結果中會返回拉起微信支付控件的必備參數。

如果是支付寶場景：接口用戶標識必傳。響應結果中返回支付寶訂單號，是用來拉起支付寶控件。

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

說明：微信小程序支付 和 支付寶小程序支付；對接此方法，還需要對接回調方法。

關鍵點：回調地址，微信subAppId，微信或支付寶用戶ID。

4. 刷臉支付

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

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

支付寶，是前端直接調用平臺接口獲取刷臉付款碼，然后調用B掃C接口便可以拉起支付。

微信，是需要后臺提供一個接口拉獲取微信刷臉調用憑證。

最終，前端調用刷臉識別SDK，獲取刷臉付款碼后，調用B掃C進行支付。

這里是微信獲取刷臉調用憑證的接口，核心參數展示。

5. 訂單支付查詢

訂單支付狀態不明確時、需要查詢訂單支付狀態等詳細信息時，需要調用此接口。

核心請求參數，通常是只需要傳入兩個參數即可。平臺商戶號和訂單號（商戶平臺支付訂單號或者是上游平臺的支付訂單號）。

很多渠道方支付文檔，都會優先使用渠道方的訂單號。但站在開發對接者的角度是有漏洞的。

比如：新零售SaaS收銀系統一筆支付單，請求上游渠道方支付完成，會存在無法拿到支付響應結果的情況。

因為在支付過程中，網絡波動后請求超時，導致商戶收銀系統無法拿到上游返回的支付訂單號。

所以此時，就需要訂單支付查詢接口，有一個商戶平臺支付訂單號（下文中的orderCode）的 參數。

當存在這種情況時，商戶收銀系統依舊可以查詢到支付結果。而不是，只能依賴渠道方訂單號。

我們在審核渠道接口時，如果只能根據渠道方訂單號查詢訂單詳情，一定要向渠道方要求添加上商戶平臺支付訂單號（orderCode）此參數。

6. 退款

核心請求參數：

退款必備關鍵性請求參數:refundNo（商戶退款訂單號，有時候此參數也不一定） 或 orderCode（商戶支付訂單號）；

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

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

7. 退款查詢

此接口中，優先以商戶平臺單號查詢，原因同【訂單支付查詢】。

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

8. 撤銷

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

9. 回調推送

對接線上JSAPI 、C掃B.接口必接。退款和支付都會存在回調信息推送。

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

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

通道方通常會按照此地址直接進行推送，但也會有少數通道按照支付接口中傳入的回調地址進行推送。

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

回調接口響應必備參數：

響應內容按照接口文檔要求即可，通常是返回 success,fail。

五、支付核心流程

一筆支付請求來到支付核心要經歷那些流程呢？

1. 從不同應用場景中發來了一筆支付請求，進入到收銀臺API中
2. 檢查業務參數,是否滿足當前支付操作的業務要求
3. 冪等性驗證
4. 組裝交易數據：如新零售SaaS收銀系統中的商戶基本信息，初始化狀態
5. 獲取到支付賬號路由
6. 組裝交易數據：支付渠道配置的商戶號等信息
7. 根據交易信息創建支付單
8. 支付發送前，封裝符合通道要求的業務參數。如:基本支付信息，加簽，加密等
9. 支付發送中，使用符合通道要求的請求方式，數據格式等。如post方式請求，使用json格式傳遞數據等
10. 支付發送后，渠道方返回響應結果并驗證結果。如：驗簽，解密。支付信息檢查是否預期返回。
11. 更新支付單，將支付狀態等業務信息進行同步。如：更新狀態支付狀態，支付訂單號，落單號，渠道號等信息