這篇文章里，作者分享了最近做的一個關(guān)于支付及對賬的項(xiàng)目，雖然在不同的業(yè)務(wù)場景下，每個收單機(jī)構(gòu)、支付渠道的相關(guān)參數(shù)字段或許會不一樣，不過作者的項(xiàng)目復(fù)盤，或許會對你有所幫助或啟發(fā)，一起來看看吧。

最近我做了一個對零售行業(yè)公司關(guān)于支付及對賬的項(xiàng)目，準(zhǔn)備做一個復(fù)盤（不泄露公司信息），看看我們是如何在原有基礎(chǔ)上對其進(jìn)行支付和對賬方面的改造。由于每家公司的業(yè)務(wù)場景不一樣所需要用到的功能不一樣，每個收單機(jī)構(gòu)和每個支付渠道的相關(guān)參數(shù)字段不一樣，所以該篇文章僅供參考。

一、改造方案簡述

我們先看看公司在改造前是怎樣的。公司有很多門店，每個門店每天會發(fā)生大量訂單交易；這些訂單有兩種收款來源：

1. 線下：顧客在門店選購商品，門店人員通過收銀ERP手動產(chǎn)生業(yè)務(wù)訂單；
2. 線上：顧客在小程序/APP商城產(chǎn)生業(yè)務(wù)訂單。

先來看看線下場景。雖然公司有自己的收銀ERP系統(tǒng)，各個門店也有POS機(jī)。

但如果收銀ERP系統(tǒng)和POS機(jī)沒有打通，線下實(shí)際場景中門店人員會怎么操作？

1. 顧客到店選購商品，門店人員將商品在ERP中錄入訂單，訂單狀態(tài)為“待付款”。
2. 顧客通過掃碼支付寶微信掃碼牌、現(xiàn)金、刷POS機(jī)等方式完成付款。
3. 門店人員確認(rèn)顧客已付款，將ERP訂單狀態(tài)從“待付款”手動改為“已完成”；系統(tǒng)扣除庫存。

如果顧客要退款，這時線下場景又是怎么操作的？

1. 門店人員進(jìn)入支付寶微信后臺操作退款，或POS機(jī)后臺操作退款。
2. 手動將ERP訂單生成一個退款單（全部或部分退款），然后手動改狀態(tài)；系統(tǒng)還原庫存。

財(cái)務(wù)人員是怎么對賬的？

1. 先到支付寶、微信、POS機(jī)等后臺下載三方流水訂單，并將當(dāng)日流水金額匯總。
2. 在公司的ERP系統(tǒng)下載業(yè)務(wù)訂單，并將當(dāng)日業(yè)務(wù)訂單金額匯總。
3. 將當(dāng)日業(yè)務(wù)訂單總額和三方流水總額進(jìn)行手動比對，如無異常則繼續(xù)比對下一日；如果發(fā)現(xiàn)總額對不上，則需將當(dāng)日每一筆訂單都一一核對，相當(dāng)費(fèi)時費(fèi)力。

為什么財(cái)務(wù)人員對賬會如此困難？先看看下圖：

（該圖是對ERP業(yè)務(wù)訂單和三方流水文件中關(guān)鍵字段提取后，做的一個簡略表單展示）

假設(shè)這是某店在1號發(fā)生了兩筆交易，顧客都是用的微信支付?？梢钥吹紼RP會記錄兩筆業(yè)務(wù)訂單，如果在第二天去下載微信的對賬文件也會有這兩筆微信訂單（為了和業(yè)務(wù)訂單區(qū)隔開，就叫三方流水）。

但問題是業(yè)務(wù)訂單號是ERP自己生成的，微信訂單號是微信自己生成的，這兩筆都是100元，但系統(tǒng)怎么知道Y1是對應(yīng)的W1，Y2對應(yīng)的W2？總不可能通過交易時間去判斷吧？所以只能通過人工去判斷，費(fèi)時費(fèi)力。

從以上操作可見，門店人員或財(cái)務(wù)人員會有以下這些痛點(diǎn)：

1. 門店人員雖然在收銀ERP錄入了訂單，但顧客付完款后，需要手動改訂單狀態(tài)。
2. 門店自行配送上門時（非外賣平臺訂單），需要靠腦子記商品和金額，顧客付款也不方便。
3. 三方支付的訂單需要在其后臺操作退款。
4. 退款與訂單一樣，退款成功后需要在ERP手動改狀態(tài)。
5. 財(cái)務(wù)人員只能手動對賬，系統(tǒng)無法對賬，因?yàn)橛唵沃g沒有關(guān)聯(lián)，這是最重要的問題。

為了解決這些痛點(diǎn)，特別是最重要的對賬問題，我們就需要從收款開始改造，我們需要讓交易數(shù)據(jù)達(dá)到下圖中所示的條件后，才能通過系統(tǒng)自動對賬：

如圖中，對賬系統(tǒng)就可以通過123來將Y1和W1進(jìn)行連接，并進(jìn)行隨后的對賬操作。

所以我們就需要用一套完整的解決方案：

• 支付網(wǎng)關(guān)：作為企業(yè)對接所有三方支付渠道的統(tǒng)一入口；以后關(guān)于三方支付渠道（包括線下和線上）產(chǎn)生的所有交易都先通過網(wǎng)關(guān)來分發(fā)到對應(yīng)渠道上，實(shí)現(xiàn)統(tǒng)一規(guī)范支付數(shù)據(jù)。
• 智能POS機(jī)：從線下門店的前端收款處解決對賬無法關(guān)聯(lián)的問題，所有三方支付（除現(xiàn)金等）都由智能POS機(jī)來統(tǒng)一收款；并可解決線下場景中各種操作上的問題。
• 應(yīng)收對賬系統(tǒng)：解決財(cái)務(wù)人員大量重復(fù)的對賬操作，主動找出差異賬，并提供手動處理。

簡單來說就需要進(jìn)行如下操作：

1. 公司需要先找一家銀行（也就是收單機(jī)構(gòu)）合作，采購一批他們的pos機(jī)，談好費(fèi)率、接口等合作事項(xiàng)。
2. 然后自行開發(fā)支付網(wǎng)關(guān)后臺、基于安卓的pos機(jī)上的應(yīng)用和應(yīng)收對賬系統(tǒng)，并且將安卓應(yīng)用與公司的ERP系統(tǒng)通過接口對接，以傳輸相關(guān)數(shù)據(jù)。
3. 最后將應(yīng)用安裝到每個POS機(jī)上，拿給各個門店使用，并且可在支付管理后臺配置相關(guān)數(shù)據(jù)。
4. 產(chǎn)生訂單后，財(cái)務(wù)人員或門店人員便可通過應(yīng)收對賬系統(tǒng)自行對賬，并處理異常。

有了這么一套解決方案之后，門店人員的操作會變成怎樣？

1. 顧客到店選購商品，門店人員在ERP上錄入訂單，并將訂單推送到智能POS機(jī)上。
2. 顧客展示支付寶/微信等三方支付的二維碼，門店人員掃描其二維碼，完成收銀。
3. POS機(jī)將收銀成功信息推送至ERP，ERP改變訂單狀態(tài)為“已完成”。退款亦如此。
4. 由于三方支付通過POS機(jī)收銀，所以三方對賬文件和業(yè)務(wù)訂單中都存有一個唯一標(biāo)識，并通過該唯一標(biāo)識能將兩者進(jìn)行關(guān)聯(lián)；所以在應(yīng)收對賬系統(tǒng)可實(shí)現(xiàn)自動對賬、自動找差異。

基于上面的前提，我們先來看看智能POS機(jī)該有哪些功能，再看要讓POS機(jī)正常使用需要配置哪些支付網(wǎng)關(guān)的數(shù)據(jù)，最后再看對賬系統(tǒng)是如何進(jìn)行自動對賬的。

二、智能POS機(jī)和支付網(wǎng)關(guān)后臺

1. 智能POS機(jī)——正向交易

假設(shè)我們已經(jīng)找了一家銀行合作，采購了一批智能POS機(jī)，這時我們就要來思考POS機(jī)上的APP應(yīng)用怎么設(shè)計(jì)了。

因?yàn)槊颗_POS機(jī)都有自己的唯一標(biāo)識碼，可能是MAC地址，這個需要視POS機(jī)的實(shí)際情況而定。然后需要將POS機(jī)與組織架構(gòu)進(jìn)行綁定，但綁定方式有如下兩種：

1）門店綁定POS機(jī)，且綁定員工

這種綁定方式雖然比較簡單，但是該P(yáng)OS機(jī)只能用于某一個門店收銀，如需更換門店，則需要在后臺進(jìn)行更換綁定，不靈活。

2）公司綁定POS機(jī)，但門店綁定了員工

如圖所示，員工甲綁定了多個門店，但該公司下的所有POS機(jī)都可登錄，但是在登錄時只能選擇其綁定的門店A和門店B，不能選擇門店C。

這種綁定方式有一種好處是更靈活，比如某門店的POS機(jī)壞了，要從其他門店拿一個過去應(yīng)急，就不用在后臺重新綁定，用完之后也不用再改回來；又比如員工甲今天在門店A上班，明天在門店B上班，等等情況。

我們選擇的是第二種綁定方式。

有一個問題，以上兩種方式都把POS機(jī)和門店建立了關(guān)聯(lián)關(guān)系，方式1是直接綁定，方式2是通過登錄員工所屬的門店所判斷；那如果不建立這樣一個關(guān)聯(lián)關(guān)系會怎樣？

• ERP產(chǎn)生的訂單將不知道推送給哪臺POS機(jī)（推送邏輯下文中描寫）；比如門店A上產(chǎn)生了一筆訂單需要推送給門店A的POS機(jī)，但門店B也有POS機(jī)，沒有綁定關(guān)系就不知道該具體推給哪臺。
• 應(yīng)收對賬系統(tǒng)將無法進(jìn)行門店下的訂單級對賬，因?yàn)槿綄~文件和ERP業(yè)務(wù)訂單都只記錄了公司信息，沒有記錄門店信息；出現(xiàn)差異的時候?qū)o法知曉是哪個門店的差異。

有了配置好的組織架構(gòu)數(shù)據(jù)、POS機(jī)數(shù)據(jù)，這時POS機(jī)就可以用了，那我們再來看該怎么交易？

POS機(jī)上的交易會分為兩種方式：A.有訂單交易和B.無訂單交易，分別對應(yīng)不同的場景。

A. 有訂單交易：

有訂單交易主要是為了應(yīng)對顧客到店選購商品，或者門店自行配送上門（非外賣平臺訂單）等場景，門店人員可在POS機(jī)上查看到從ERP推送過來的訂單并進(jìn)行收款。

我們來模擬一個較為復(fù)雜的場景：顧客選了3個商品總共200元，但是他帶了50元現(xiàn)金，然后想在支付寶上支付20元，微信上支付30元，刷卡支付50元；門店人員的操作應(yīng)該是：

1. 先在ERP上生成一個訂單，錄入這3個商品，得到200元的訂單總額。
2. 然后在ERP上選擇支付方式：“現(xiàn)金”收入50元（現(xiàn)金無需通過POS機(jī)），POS收銀“150元”。
3. POS機(jī)上便可收到這筆150元的訂單，再進(jìn)行組合支付，分別掃碼微信和支付寶。

上面我們看到的是線下場景實(shí)際發(fā)生的操作，那各個系統(tǒng)的后端數(shù)據(jù)又是如何交互的呢？

1. 首先在ERP生成業(yè)務(wù)訂單，然后將該訂單推送到POS機(jī)上的應(yīng)用。
2. POS機(jī)應(yīng)用后臺會先生成一個POS訂單，然后根據(jù)實(shí)際交易生成多條POS支付記錄，再將POS支付記錄推送到支付網(wǎng)關(guān)，請求支付。
3. 支付網(wǎng)關(guān)接收到請求后，會生成聚合支付單，再根據(jù)其記錄的支付方式去調(diào)對應(yīng)的三方支付接口。
4. 三方支付接口收到請求后，會先生成自己的流水單，再完成支付。

B. 無訂單交易

無訂單交易就是指還未在ERP上錄入訂單，可先行在POS機(jī)收款，此功能是為了彌補(bǔ)有訂單交易無法覆蓋到的一些特殊場景，具體操作如下：

1. 門店人員先在POS機(jī)選擇無訂單收款，收款成功后該筆POS訂單會回傳至ERP。
2. 門店人員需在ERP上創(chuàng)建業(yè)務(wù)訂單，再將交易流水與此筆業(yè)務(wù)訂單進(jìn)行關(guān)聯(lián)。

所以對于POS訂單或ERP業(yè)務(wù)訂單來說，會存在“未關(guān)聯(lián)”和“已關(guān)聯(lián)”兩種狀態(tài)，會影響應(yīng)收對賬，在下一章會講。

了解了正向交易的流程是怎樣進(jìn)行的，接下來我們就來看看具體的操作頁面：

以上為部分原型界面，分別是“首頁”、“訂單收銀頁”、“收銀臺頁”、“輸入支付金額頁”。

操作順序?yàn)椋寒?dāng)ERP系統(tǒng)中錄入業(yè)務(wù)訂單并推送到POS機(jī)進(jìn)行收款后，在POS機(jī)的首頁點(diǎn)擊訂單收款按鈕，便可進(jìn)入待收款的訂單列表頁，選擇某一個訂單可進(jìn)入訂單詳情頁，也可直接進(jìn)行收款。而無訂單交易的操作界面和收銀臺界面差不多，先選擇掃碼還是刷卡，再輸入金額進(jìn)行后續(xù)操作。

有幾個需要注意的點(diǎn)：

① 在訂單收銀頁展示的訂單信息是POS后臺生成的POS訂單，而非ERP的業(yè)務(wù)訂單

所以需要和業(yè)務(wù)方、開發(fā)同學(xué)溝通好，需要展示哪些字段，傳哪些參數(shù)過來。

② ERP系統(tǒng)是否需要做數(shù)據(jù)隔離？

POS機(jī)支付完成后，需將結(jié)果信息回傳至ERP。如果ERP要做數(shù)據(jù)隔離，也就是甲的收款記錄，乙在ERP上是否能查看，所以在回傳信息中需要相關(guān)字段來表示。

③ 未收款/部分收款的訂單是否需要時效限制？

這個需要跟業(yè)務(wù)場景溝通，比如超過24小時POS訂單將失效，需要回傳告訴ERP關(guān)閉訂單；未收款的訂單需要自動退款，等等邏輯。

2. 智能POS機(jī)——退貨退款

相較于交易來說，退款的分支流程會更多一些，我們先看一下退款有哪些場景：

1）訂單交易

1.1 訂單已完全收款，在已完成狀態(tài)下進(jìn)行退款。

1.2 訂單未完全收款，在部分收款狀態(tài)下進(jìn)行退款。

2）無訂單交易

2.1 該筆訂單暫未關(guān)聯(lián)業(yè)務(wù)訂單時進(jìn)行退款。

2.2 該筆訂單已關(guān)聯(lián)業(yè)務(wù)訂單時進(jìn)行退款。

先看1.1這種情況，我們設(shè)計(jì)的發(fā)起入口只能是在ERP，為什么不能在POS機(jī)處發(fā)起？

是因?yàn)榧纫淹耆湛盍?，很可能貨已?jīng)發(fā)出了，而一個訂單可能會有多個商品而只退其中一部分，所以這時需要針對退貨的商品生成一個退貨退款單；而退貨退款單如果由POS機(jī)發(fā)起，一個是并沒有電腦操作方便，一個是增加了開發(fā)量。

流程圖如下所示：

再看1.2這種情況，訂單部分收款代表著貨還未發(fā)出，這時顧客要退款會有2種操作，要么重新付款（比如微信付的款退了，用支付寶付），要么全都不要了。所以我們設(shè)計(jì)的是只能在POS機(jī)上退，如果又可在ERP上退，基于顧客可能的操作考慮，會增加門店人員的操作復(fù)雜度，也增加了ERP與POS機(jī)數(shù)據(jù)交互的復(fù)雜度。

流程圖如下所示：

從實(shí)際業(yè)務(wù)場景來考慮，情況2.2與1.1退款方式一致，情況2.1與1.2退款方式一致。

了解了退款的場景與流程，我們再來看看退款具體是怎么操作的：

3. 支付網(wǎng)關(guān)數(shù)據(jù)配置

支付網(wǎng)關(guān)后臺需要配置兩塊信息：

1. 關(guān)于商戶入網(wǎng)的：支付渠道信息、各渠道的參數(shù)等。目的是通過接口的方式將該商戶的信息傳到支付渠道的后端直接驗(yàn)證，以保證交易能順利進(jìn)行。
2. 關(guān)于POS機(jī)相關(guān)信息的：錄入公司信息、門店信息、員工信息等組織架構(gòu)相關(guān)信息，然后錄入智能POS機(jī)的信息（這一塊就不用展開）。

（注意：關(guān)于商戶入網(wǎng)的數(shù)據(jù)配置，這個配置頁面有沒有必要開發(fā)前端頁面要看公司的需求，而每個公司的業(yè)務(wù)場景不一樣，每個支付渠道的參數(shù)也不一樣，大多無法抽象都是定制化開發(fā)。

所以此部分僅做參考，后臺配置功能是否需要做得和業(yè)務(wù)、開發(fā)同學(xué)溝通好，怎樣做可以去看該渠道的接口文檔。）

首先得配置有哪些支付渠道，該渠道下有哪些支付產(chǎn)品：

比如微信這個渠道有個支付產(chǎn)品叫小程序支付（直連模式），其支付方式為微信小程序支付。

XX銀行這個渠道也有個微信下的支付產(chǎn)品叫小程序支付（間聯(lián)模式），其支付方式也為微信小程序支付。

在為商戶配置支付產(chǎn)品時，只能在不同渠道下的同一支付方式的支付產(chǎn)品中，啟用一個；比如啟用了微信的就不能啟用民生銀行的；否則支付網(wǎng)關(guān)就不能判斷走哪個渠道。

然后要配置商戶信息。注意，該商戶信息并非正式組織架構(gòu)商戶，而是在支付網(wǎng)關(guān)中作為收款單位的商戶；一個公司可能有多個子公司，每個公司都有自己的營運(yùn)資質(zhì)，所以每個子公司都可以作為一個商戶：

有了商戶信息之后，就要為商戶添加支付渠道，并選擇支付產(chǎn)品：

商戶有了支付渠道，這時就要為其配置該渠道的相關(guān)參數(shù)：

如圖微信分為服務(wù)商模式，參數(shù)的添加邏輯如圖所示，但具體得看微信的接口文檔。

下一章：應(yīng)收對賬系統(tǒng)