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

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

一、改造方案簡(jiǎn)述

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

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

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

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

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

如果顧客要退款，這時(shí)線下場(chǎng)景又是怎么操作的？

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

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

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

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

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

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

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

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

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

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

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

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

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

簡(jiǎn)單來(lái)說(shuō)就需要進(jìn)行如下操作：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A. 有訂單交易：

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

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

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

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

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

B. 無(wú)訂單交易

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

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

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

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

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

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

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

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

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

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

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

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

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

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

相較于交易來(lái)說(shuō)，退款的分支流程會(huì)更多一些，我們先看一下退款有哪些場(chǎng)景：

1）訂單交易

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

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

2）無(wú)訂單交易

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

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

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

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

流程圖如下所示：

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

流程圖如下所示：

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

了解了退款的場(chǎng)景與流程，我們?cè)賮?lái)看看退款具體是怎么操作的：

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

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

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

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

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

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

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

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

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

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

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

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

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

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