智能POS、支付網(wǎng)關(guān)后臺與應(yīng)收對賬系統(tǒng)(一)
這篇文章里,作者分享了最近做的一個關(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ā)生大量訂單交易;這些訂單有兩種收款來源:
- 線下:顧客在門店選購商品,門店人員通過收銀ERP手動產(chǎn)生業(yè)務(wù)訂單;
- 線上:顧客在小程序/APP商城產(chǎn)生業(yè)務(wù)訂單。
先來看看線下場景。雖然公司有自己的收銀ERP系統(tǒng),各個門店也有POS機(jī)。
但如果收銀ERP系統(tǒng)和POS機(jī)沒有打通,線下實(shí)際場景中門店人員會怎么操作?
- 顧客到店選購商品,門店人員將商品在ERP中錄入訂單,訂單狀態(tài)為“待付款”。
- 顧客通過掃碼支付寶微信掃碼牌、現(xiàn)金、刷POS機(jī)等方式完成付款。
- 門店人員確認(rèn)顧客已付款,將ERP訂單狀態(tài)從“待付款”手動改為“已完成”;系統(tǒng)扣除庫存。
如果顧客要退款,這時線下場景又是怎么操作的?
- 門店人員進(jìn)入支付寶微信后臺操作退款,或POS機(jī)后臺操作退款。
- 手動將ERP訂單生成一個退款單(全部或部分退款),然后手動改狀態(tài);系統(tǒng)還原庫存。
財(cái)務(wù)人員是怎么對賬的?
- 先到支付寶、微信、POS機(jī)等后臺下載三方流水訂單,并將當(dāng)日流水金額匯總。
- 在公司的ERP系統(tǒng)下載業(yè)務(wù)訂單,并將當(dāng)日業(yè)務(wù)訂單金額匯總。
- 將當(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):
- 門店人員雖然在收銀ERP錄入了訂單,但顧客付完款后,需要手動改訂單狀態(tài)。
- 門店自行配送上門時(非外賣平臺訂單),需要靠腦子記商品和金額,顧客付款也不方便。
- 三方支付的訂單需要在其后臺操作退款。
- 退款與訂單一樣,退款成功后需要在ERP手動改狀態(tài)。
- 財(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)行如下操作:
- 公司需要先找一家銀行(也就是收單機(jī)構(gòu))合作,采購一批他們的pos機(jī),談好費(fèi)率、接口等合作事項(xiàng)。
- 然后自行開發(fā)支付網(wǎng)關(guān)后臺、基于安卓的pos機(jī)上的應(yīng)用和應(yīng)收對賬系統(tǒng),并且將安卓應(yīng)用與公司的ERP系統(tǒng)通過接口對接,以傳輸相關(guān)數(shù)據(jù)。
- 最后將應(yīng)用安裝到每個POS機(jī)上,拿給各個門店使用,并且可在支付管理后臺配置相關(guān)數(shù)據(jù)。
- 產(chǎn)生訂單后,財(cái)務(wù)人員或門店人員便可通過應(yīng)收對賬系統(tǒng)自行對賬,并處理異常。
有了這么一套解決方案之后,門店人員的操作會變成怎樣?
- 顧客到店選購商品,門店人員在ERP上錄入訂單,并將訂單推送到智能POS機(jī)上。
- 顧客展示支付寶/微信等三方支付的二維碼,門店人員掃描其二維碼,完成收銀。
- POS機(jī)將收銀成功信息推送至ERP,ERP改變訂單狀態(tài)為“已完成”。退款亦如此。
- 由于三方支付通過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)該是:
- 先在ERP上生成一個訂單,錄入這3個商品,得到200元的訂單總額。
- 然后在ERP上選擇支付方式:“現(xiàn)金”收入50元(現(xiàn)金無需通過POS機(jī)),POS收銀“150元”。
- POS機(jī)上便可收到這筆150元的訂單,再進(jìn)行組合支付,分別掃碼微信和支付寶。
上面我們看到的是線下場景實(shí)際發(fā)生的操作,那各個系統(tǒng)的后端數(shù)據(jù)又是如何交互的呢?
- 首先在ERP生成業(yè)務(wù)訂單,然后將該訂單推送到POS機(jī)上的應(yīng)用。
- POS機(jī)應(yīng)用后臺會先生成一個POS訂單,然后根據(jù)實(shí)際交易生成多條POS支付記錄,再將POS支付記錄推送到支付網(wǎng)關(guān),請求支付。
- 支付網(wǎng)關(guān)接收到請求后,會生成聚合支付單,再根據(jù)其記錄的支付方式去調(diào)對應(yīng)的三方支付接口。
- 三方支付接口收到請求后,會先生成自己的流水單,再完成支付。
B. 無訂單交易
無訂單交易就是指還未在ERP上錄入訂單,可先行在POS機(jī)收款,此功能是為了彌補(bǔ)有訂單交易無法覆蓋到的一些特殊場景,具體操作如下:
- 門店人員先在POS機(jī)選擇無訂單收款,收款成功后該筆POS訂單會回傳至ERP。
- 門店人員需在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)后臺需要配置兩塊信息:
- 關(guān)于商戶入網(wǎng)的:支付渠道信息、各渠道的參數(shù)等。目的是通過接口的方式將該商戶的信息傳到支付渠道的后端直接驗(yàn)證,以保證交易能順利進(jìn)行。
- 關(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)
專欄作家
橘鉆,人人都是產(chǎn)品經(jīng)理專欄作家。擅長B端/后臺類復(fù)雜業(yè)務(wù)邏輯設(shè)計(jì)。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自 Unsplash,基于 CC0 協(xié)議
該文觀點(diǎn)僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。
很細(xì)致,太感謝了,正為這個苦惱,期待第二篇~
寫的很詳細(xì)
很細(xì)致 期待第二篇~
哈哈哈,非常清晰呀,謝謝博主分享呀
看的很過癮,可以盡快寫第二部分么,正好當(dāng)前項(xiàng)目要做財(cái)務(wù)對賬
好的,謝謝支持
請教一個問題,如果公司系統(tǒng)對接了四方聚合支付系統(tǒng),那么文中關(guān)于支付網(wǎng)關(guān)配置部分是不是就不用關(guān)心了
是的,但是用四方的話無法對賬,因?yàn)椤拔ㄒ粯?biāo)識”在四方那里,所以我們之前也改造了收錢吧這個四方平臺的收款通道
666
問問老師,業(yè)務(wù)訂單指的是電商的訂單嗎?
這個就要看你們的業(yè)務(wù)場景而定了
比如你們是電商商城產(chǎn)生了前端的商城訂單,隨即數(shù)據(jù)傳到訂單ERP系統(tǒng)產(chǎn)生了ERP訂單。這個商城訂單和ERP訂單都可以是文中所謂的業(yè)務(wù)訂單,但具體用哪個訂單來進(jìn)行對賬就要看你們自己的需要了。
寫得非常細(xì)致
專業(yè)
謝謝