智能POS、支付网关后台与应收对账系统（一）

这篇文章里，作者分享了最近做的一个关于支付及对账的项目，虽然在不同的业务场景下，每个收单机构、支付渠道的相关参数字段或许会不一样，不过作者的项目复盘，或许会对你有所帮助或启发，一起来看看吧网关。

这篇文章里，作者分享了最近做的一个关于支付及对账的项目，虽然在不同的业务场景下，每个收单机构、支付渠道的相关参数字段或许会不一样，不过作者的项目复盘，或许会对你有所帮助或启发，一起来看看吧网关。

最近我做了一个对零售行业公司关于支付及对账的项目，准备做一个复盘（不泄露公司信息），看看我们是如何在原有基础上对其进行支付和对账方面的改造网关。由于每家公司的业务场景不一样所需要用到的功能不一样，每个收单机构和每个支付渠道的相关参数字段不一样，所以该篇文章仅供参考。

一、改造方案简述

我们先看看公司在改造前是怎样的网关。公司有很多门店，每个门店每天会发生大量订单交易；这些订单有两种收款来源：

先来看看线下场景网关。虽然公司有自己的收银ERP系统，各个门店也有POS机。

但如果收银ERP系统和POS机没有打通网关，线下实际场景中门店人员会怎么操作？

如果顾客要退款网关，这时线下场景又是怎么操作的？

财务人员是怎么对账的网关？

为什么财务人员对账会如此困难网关？先看看下图：

（该图是对ERP业务订单和三方流水文件中关键字段提取后网关，做的一个简略表单展示）

假设这是某店在1号发生了两笔交易，顾客都是用的微信支付网关。可以看到ERP会记录两笔业务订单，如果在第二天去下载微信的对账文件也会有这两笔微信订单（为了和业务订单区隔开，就叫三方流水）。

但问题是业务订单号是ERP自己生成的，微信订单号是微信自己生成的，这两笔都是100元，但系统怎么知道Y1是对应的W1，Y2对应的W2？总不可能通过交易时间去判断吧？所以只能通过人工去判断，费时费力网关。

从以上操作可见网关，门店人员或财务人员会有以下这些痛点：

为了解决这些痛点网关，特别是最重要的对账问题，我们就需要从收款开始改造，我们需要让交易数据达到下图中所示的条件后，才能通过系统自动对账：

如图中，对账系统就可以通过123来将Y1和W1进行连接，并进行随后的对账操作网关。

所以网关我们就需要用一套完整的解决方案：

支付网关：作为企业对接所有三方支付渠道的统一入口；以后关于三方支付渠道（包括线下和线上）产生的所有交易都先通过网关来分发到对应渠道上，实现统一规范支付数据网关。

智能POS机：从线下门店的前端收款处解决对账无法关联的问题，所有三方支付（除现金等）都由智能POS机来统一收款；并可解决线下场景中各种操作上的问题网关。

应收对账系统：解决财务人员大量重复的对账操作，主动找出差异账，并提供手动处理网关。

简单来说就需要进行如下操作：

有了这么一套解决方案之后网关，门店人员的操作会变成怎样？

展开全文

基于上面的前提，我们先来看看智能POS机该有哪些功能，再看要让POS机正常使用需要配置哪些支付网关的数据，最后再看对账系统是如何进行自动对账的网关。

二、智能POS机和支付网关后台 1. 智能POS机——正向交易

假设我们已经找了一家银行合作，采购了一批智能POS机，这时我们就要来思考POS机上的APP应用怎么设计了网关。

因为每台POS机都有自己的唯一标识码，可能是MAC地址，这个需要视POS机的实际情况而定网关。然后需要将POS机与组织架构进行绑定，但绑定方式有如下两种：

1）门店绑定POS机网关，且绑定员工

这种绑定方式虽然比较简单，但是该POS机只能用于某一个门店收银，如需更换门店，则需要在后台进行更换绑定，不灵活网关。

2）公司绑定POS机网关，但门店绑定了员工

如图所示，员工甲绑定了多个门店，但该公司下的所有POS机都可登录，但是在登录时只能选择其绑定的门店A和门店B，不能选择门店C网关。

这种绑定方式有一种好处是更灵活，比如某门店的POS机坏了，要从其他门店拿一个过去应急，就不用在后台重新绑定，用完之后也不用再改回来；又比如员工甲今天在门店A上班，明天在门店B上班，等等情况网关。

我们选择的是第二种绑定方式网关。

有一个问题网关，以上两种方式都把POS机和门店建立了关联关系，方式1是直接绑定，方式2是通过登录员工所属的门店所判断；那如果不建立这样一个关联关系会怎样？

ERP产生的订单将不知道推送给哪台POS机（推送逻辑下文中描写）；比如门店A上产生了一笔订单需要推送给门店A的POS机，但门店B也有POS机，没有绑定关系就不知道该具体推给哪台网关。

应收对账系统将无法进行门店下的订单级对账，因为三方对账文件和ERP业务订单都只记录了公司信息，没有记录门店信息；出现差异的时候将无法知晓是哪个门店的差异网关。

有了配置好的组织架构数据、POS机数据网关，这时POS机就可以用了，那我们再来看该怎么交易？

POS机上的交易会分为两种方式：A.有订单交易和B.无订单交易，分别对应不同的场景网关。

A. 有订单交易：

有订单交易主要是为了应对顾客到店选购商品，或者门店自行配送上门（非外卖平台订单）等场景，门店人员可在POS机上查看到从ERP推送过来的订单并进行收款网关。

我们来模拟一个较为复杂的场景：顾客选了3个商品总共200元网关，但是他带了50元现金，然后想在支付宝上支付20元，微信上支付30元，刷卡支付50元；门店人员的操作应该是：

上面我们看到的是线下场景实际发生的操作网关，那各个系统的后端数据又是如何交互的呢？

B. 无订单交易

无订单交易就是指还未在ERP上录入订单网关，可先行在POS机收款，此功能是为了弥补有订单交易无法覆盖到的一些特殊场景，具体操作如下：

所以对于POS订单或ERP业务订单来说，会存在“未关联”和“已关联”两种状态，会影响应收对账，在下一章会讲网关。

了解了正向交易的流程是怎样进行的网关，接下来我们就来看看具体的操作页面：

以上为部分原型界面，分别是“首页”、“订单收银页”、“收银台页”、“输入支付金额页”网关。

操作顺序为：当ERP系统中录入业务订单并推送到POS机进行收款后，在POS机的首页点击订单收款按钮，便可进入待收款的订单列表页，选择某一个订单可进入订单详情页，也可直接进行收款网关。而无订单交易的操作界面和收银台界面差不多，先选择扫码还是刷卡，再输入金额进行后续操作。

有几个需要注意的点：

① 在订单收银页展示的订单信息是POS后台生成的POS订单网关，而非ERP的业务订单

所以需要和业务方、开发同学沟通好，需要展示哪些字段，传哪些参数过来网关。

② ERP系统是否需要做数据隔离网关？

POS机支付完成后，需将结果信息回传至ERP网关。如果ERP要做数据隔离，也就是甲的收款记录，乙在ERP上是否能查看，所以在回传信息中需要相关字段来表示。

③ 未收款/部分收款的订单是否需要时效限制网关？

这个需要跟业务场景沟通，比如超过24小时POS订单将失效，需要回传告诉ERP关闭订单；未收款的订单需要自动退款，等等逻辑网关。

2. 智能POS机——退货退款

相较于交易来说网关，退款的分支流程会更多一些，我们先看一下退款有哪些场景：

1）订单交易

1.1 订单已完全收款，在已完成状态下进行退款网关。

1.2 订单未完全收款，在部分收款状态下进行退款网关。

2）无订单交易

2.1 该笔订单暂未关联业务订单时进行退款网关。

2.2 该笔订单已关联业务订单时进行退款网关。

先看1.1这种情况网关，我们设计的发起入口只能是在ERP，为什么不能在POS机处发起？

是因为既已完全收款了，很可能货已经发出了，而一个订单可能会有多个商品而只退其中一部分，所以这时需要针对退货的商品生成一个退货退款单；而退货退款单如果由POS机发起，一个是并没有电脑操作方便，一个是增加了开发量网关。

流程图如下所示：

再看1.2这种情况，订单部分收款代表着货还未发出，这时顾客要退款会有2种操作，要么重新付款（比如微信付的款退了，用支付宝付），要么全都不要了网关。所以我们设计的是只能在POS机上退，如果又可在ERP上退，基于顾客可能的操作考虑，会增加门店人员的操作复杂度，也增加了ERP与POS机数据交互的复杂度。

流程图如下所示：

从实际业务场景来考虑，情况2.2与1.1退款方式一致，情况2.1与1.2退款方式一致网关。

了解了退款的场景与流程网关，我们再来看看退款具体是怎么操作的：

3. 支付网关数据配置

支付网关后台需要配置两块信息：

（注意：关于商户入网的数据配置，这个配置页面有没有必要开发前端页面要看公司的需求，而每个公司的业务场景不一样，每个支付渠道的参数也不一样，大多无法抽象都是定制化开发网关。

所以此部分仅做参考，后台配置功能是否需要做得和业务、开发同学沟通好，怎样做可以去看该渠道的接口文档网关。）

首先得配置有哪些支付渠道网关，该渠道下有哪些支付产品：

比如微信这个渠道有个支付产品叫小程序支付（直连模式），其支付方式为微信小程序支付网关。

XX银行这个渠道也有个微信下的支付产品叫小程序支付（间联模式），其支付方式也为微信小程序支付网关。

在为商户配置支付产品时，只能在不同渠道下的同一支付方式的支付产品中，启用一个；比如启用了微信的就不能启用民生银行的；否则支付网关就不能判断走哪个渠道网关。

然后要配置商户信息网关。注意，该商户信息并非正式组织架构商户，而是在支付网关中作为收款单位的商户；一个公司可能有多个子公司，每个公司都有自己的营运资质，所以每个子公司都可以作为一个商户：

有了商户信息之后网关，就要为商户添加支付渠道，并选择支付产品：

商户有了支付渠道网关，这时就要为其配置该渠道的相关参数：

如图微信分为服务商模式，参数的添加逻辑如图所示，但具体得看微信的接口文档网关。

下一章：应收对账系统

本文由 @橘钻 原创发布于人人都是产品经理网关，未经许可，禁止转载

题图来自 Unsplash网关，基于 CC0 协议