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

智能POS支付网关后台与应收对账系统最近我做了一个对零售行业公司关于支付及对账的项目，准备做一个复盘（不泄露公司信息），看看我们是如何在原有基础上对其进行支付和对账方面的改造。由于每家公司的业务场景不一样所需要用到的功能不一样，每个收单机构和每个支付渠道的相关参数字段不一样，所以该篇文章仅供参考。一、改造方案简述我们先看看公司在改造前是怎样的。公司有很多门店，每个门店每天会发生大量订单交易；这些订单有两种收款来源：线下：顾客在门店选购商品，门店人员通过收银ERP手动产生业务订单；线上：顾客在小程序/APP商城产生业务订单。先来看看线下场景。虽然公司有自己的收银ERP系统，各个门店也有POS机。但如果收银ERP系统和POS机没有打通，线下实际场景中门店人员会怎么操作？顾客到店选购商品，门店人员将商品在ERP中录入订单，订单状态为“待付款”。顾客通过扫码支付宝微信扫码牌、现金、刷POS机等方式完成付款。门店人员确认顾客已付款，将ERP订单状态从“待付款”手动改为“已完成”；系统扣除库存。如果顾客要退款，这时线下场景又是怎么操作的？门店人员进入支付宝微信后台操作退款，或POS机后台操作退款。手动将ERP订单生成一个退款单（全部或部分退款），然后手动改状态；系统还原库存。财务人员是怎么对账的？先到支付宝、微信、POS机等后台下载三方流水订单，并将当日流水金额汇总。在公司的ERP系统下载业务订单，并将当日业务订单金额汇总。将当日业务订单总额和三方流水总额进行手动比对，如无异常则继续比对下一日；如果发现总额对不上，则需将当日每一笔订单都一一核对，相当费时费力。为什么财务人员对账会如此困难？先看看下图：（该图是对ERP业务订单和三方流水文件中关键字段提取后，做的一个简略表单展示）假设这是某店在1号发生了两笔交易，顾客都是用的微信支付。可以看到ERP会记录两笔业务订单，如果在第二天去下载微信的对账文件也会有这两笔微信订单（为了和业务订单区隔开，就叫三方流水）。但问题是业务订单号是ERP自己生成的，微信订单号是微信自己生成的，这两笔都是100元，但系统怎么知道Y1是对应的W1，Y2对应的W2？总不可能通过交易时间去判断吧？所以只能通过人工去判断，费时费力。从以上操作可见，门店人员或财务人员会有以下这些痛点：门店人员虽然在收银ERP录入了订单，但顾客付完款后，需要手动改订单状态。门店自行配送上门时（非外卖平台订单），需要靠脑子记商品和金额，顾客付款也不方便。三方支付的订单需要在其后台操作退款。退款与订单一样，退款成功后需要在ERP手动改状态。财务人员只能手动对账，系统无法对账，因为订单之间没有关联，这是最重要的问题。为了解决这些痛点，特别是最重要的对账问题，我们就需要从收款开始改造，我们需要让交易数据达到下图中所示的条件后，才能通过系统自动对账：如图中，对账系统就可以通过123来将Y1和W1进行连接，并进行随后的对账操作。所以我们就需要用一套完整的解决方案：支付网关：作为企业对接所有三方支付渠道的统一入口；以后关于三方支付渠道（包括线下和线上）产生的所有交易都先通过网关来分发到对应渠道上，实现统一规范支付数据。智能POS机：从线下门店的前端收款处解决对账无法关联的问题，所有三方支付（除现金等）都由智能POS机来统一收款；并可解决线下场景中各种操作上的问题。应收对账系统：解决财务人员大量重复的对账操作，主动找出差异账，并提供手动处理。简单来说就需要进行如下操作：公司需要先找一家银行（也就是收单机构）合作，采购一批他们的pos机，谈好费率、接口等合作事项。然后自行开发支付网关后台、基于安卓的pos机上的应用和应收对账系统，并且将安卓应用与公司的ERP系统通过接口对接，以传输相关数据。最后将应用安装到每个POS机上，拿给各个门店使用，并且可在支付管理后台配置相关数据。产生订单后，财务人员或门店人员便可通过应收对账系统自行对账，并处理异常。有了这么一套解决方案之后，门店人员的操作会变成怎样？顾客到店选购商品，门店人员在ERP上录入订单，并将订单推送到智能POS机上。顾客展示支付宝/微信等三方支付的二维码，门店人员扫描其二维码，完成收银。POS机将收银成功信息推送至ERP，ERP改变订单状态为“已完成”。退款亦如此。由于三方支付通过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元；门店人员的操作应该是：先在ERP上生成一个订单，录入这3个商品，得到200元的订单总额。然后在ERP上选择支付方式：“现金”收入50元（现金无需通过POS机），POS收银“150元”。POS机上便可收到这笔150元的订单，再进行组合支付，分别扫码微信和支付宝。上面我们看到的是线下场景实际发生的操作，那各个系统的后端数据又是如何交互的呢？首先在ERP生成业务订单，然后将该订单推送到POS机上的应用。POS机应用后台会先生成一个POS订单，然后根据实际交易生成多条POS支付记录，再将POS支付记录推送到支付网关，请求支付。支付网关接收到请求后，会生成聚合支付单，再根据其记录的支付方式去调对应的三方支付接口。三方支付接口收到请求后，会先生成自己的流水单，再完成支付。B.无订单交易无订单交易就是指还未在ERP上录入订单，可先行在POS机收款，此功能是为了弥补有订单交易无法覆盖到的一些特殊场景，具体操作如下：门店人员先在POS机选择无订单收款，收款成功后该笔POS订单会回传至ERP。门店人员需在ERP上创建业务订单，再将交易流水与此笔业务订单进行关联。所以对于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.支付网关数据配置支付网关后台需要配置两块信息：关于商户入网的：支付渠道信息、各渠道的参数等。目的是通过接口的方式将该商户的信息传到支付渠道的后端直接验证，以保证交易能顺利进行。关于POS机相关信息的：录入公司信息、门店信息、员工信息等组织架构相关信息，然后录入智能POS机的信息（这一块就不用展开）。（注意：关于商户入网的数据配置，这个配置页面有没有必要开发前端页面要看公司的需求，而每个公司的业务场景不一样，每个支付渠道的参数也不一样，大多无法抽象都是定制化开发。所以此部分仅做参考，后台配置功能是否需要做得和业务、开发同学沟通好，怎样做可以去看该渠道的接口文档。）首先得配置有哪些支付渠道，该渠道下有哪些支付产品：比如微信这个渠道有个支付产品叫小程序支付（直连模式），其支付方式为微信小程序支付。XX银行这个渠道也有个微信下的支付产品叫小程序支付（间联模式），其支付方式也为微信小程序支付。在为商户配置支