一文搞懂，新零售“支付中台”
中台，就是把通用业务，抽象整理成一套工具。供多个业务线使用。
同理，支付中台，就是将支付能力抽象整理出的一套支付工具，能同时支撑多个业务线使用。
用统一的平台来完成支付相关的共通流程，进行模块化封装。
一、为什么，怎么做
在最初，SaaS软件服务商，只有一条业务线时，只需要做一套支付。当业务高速发展时，SaaS软件服务商存在多条业务线，对支付的管理和功能上就会有很多重合环节。
1.1 为什么
SaaS服务商对这些环节做单独开发和运营配置，就会很耗费人力成本，降低了SaaS服务商效率。比如：运营人员需要同时管理多个支付渠道和交易流水，还需要为商户配置支付账号。
SaaS软件服务商需要一套解决方案，来解决支付服务效率低的问题。
如果实现了支付中台，运营人员可以通过一个平台进行管理多个商户进件、商户支付配置、交易流水对账、分润、分账等信息。
开发人员，能够在支付中台的架构下，快速进行支付渠道对接或者引入新的业务模式。从而满足市场的需求。
为了能够同时支持多种业态的支付业务，提升SaaS服务商的核心竞争力，搭建支付中台迫在眉睫。
1.2 如何做
我们来分析一下SaaS软件服务商的收银业务线，其中主要包含SaaS收银业务线和大型商超收银业务线。终端设备主要有POS，小程序，WEB,刷脸设备，码牌和APP。
用户使用终端进行交易时，涉及到的核心支付业务流程主要是发起支付，查询订单，退款和撤销。
SaaS软件服务商要使得商家店面支付业务流程跑通，不能仅仅只有支付功能。还需要对商户信息进件报备，开通商户支付账号并进行配置，对支付账号配置支付路由渠道，提供多维度对账报表，为代理商提供分润服务，以及给商户提供分账服务。
二、支付中台的5大模块
下面以商户账号配置、支付、对账、分润、分账 五个模块来搭建支付中台。
2.1 商户账号配置模块
账号配置，就是为商家提供收款账号配置服务。对SaaS软件服务商来说，支付最终服务的对象就是商家。商家开店要收款，最终钱要收到商户指定的账号内。那么商户的支付账号从哪里来？运营人员如何进行配置呢？
商户要拥有支付收款能力，必须得向第三/四方支付渠道平台申请（将营业资质等信息报备），获得支付入网许可，这就是商户进件。
运营人员或代理商可在支付中台替商户进件，帮商家免去进件繁琐过程。
商户进件通常分为两类：一类是直连模式，一类是服务商模式。
直连模式就是商户直接在第三/四方支付渠道下申请一个支付商户号。
服务商模式就是SaaS软件服务商或者代理商在第三/四方支付渠道下，帮商户申请支付账号，将该支付商户挂到自己服务商名下。关于商户进件，可以由商户自主选择。两者最大的不同就是，支付费率不同。
通常，商户会选择使用服务商模式，因为支付费率更低。其中服务商模式不只是支持默认服务商（SaaS软件服务商），还可以为代理商添加自己的支付渠道服务商信息。
商户选择走服务商模式，只要店面有支付交易流水，便会为服务商带来睡后收益。这也是为什么拥有高频交易场景的软件服务商愿意去做支付中台的一个主要原因。
如何配置支付账号？
支付中台拥有支付账号配置权限的就只有两种角色：运营人员和代理商。支付中台有多个支付渠道，需要由运营人员给代理商赋值支付渠道配置权限。
对商户下的多个门店，进行配置不同的支付渠道。配置完渠道之后，可以对不同的支付环境设置路由配置。
2.2 支付核心系统模块
支付，就是用户购买商品服务，并在商户终端收银台完成付款操作。支付收银台终端环境有POS、小程序、刷脸设备、WEB页面、码牌等等。业务流程围绕支付的主要环节就是：支付，查询，退款，撤销。
对于终端收银台的业务流程抽象，我们可以封装出一套支付收银台API,后续不同业务终端可以快速嵌入到支付业务流程中。
对于支付，我们又可以按照不同的支付场景分为：B扫C，C扫B，JSAPI，APP支付等。
订单完成正向交易后，还需要主动查询支付状态或等待异步通知支付结果。
在支付过程中出现支付超时，顾客已经支付完成，系统还未接收到支付成功信息，可以撤销，金额会原路退回；如果是支付失败，撤销后便关闭订单。
在正常支付成功后，可以使用退款来申请退款。同时可以使用退款查询来确定最终的退款状态。
（1）收银台API封装
统一下单入口：B扫C,C扫B,JSAPI ，APP支付等等。
订单查询：订单状态不是最终终态时，支付等待中/退款中时，提供接口进行轮询查询。
订单撤销：支付失败，或支付成功但订单超时时，发起撤销。将关闭支付订单，防止出现重复支付的情况。
退款申请：订单逆向流程。
回调：支付或退款回调，上游渠道推送过来的支付或退款状态通知。支付中台更新订单状态，并对下游业务进行同步推送状态信息。
（2）支付核心
支付核心，处理来自上游收银台支付请求，并且根据支付账号配置路由，确定最终执行的支付渠道。它是一笔订单最终完成支付，传递支付指令的前置条件。
（3）支付渠道
支付渠道，根据客户不同支付场景，系统兼容对接新的支付渠道。支付渠道来完成支付中台内部的支付指令向外部支付渠道的传递。
2.3 对账模块
对账，就是对门店交易数据进行核对对比的操作，防止出现错账问题。它对于关心店面利益的人不可或缺。
对账从支付记录入手。从门店、日、收银员、POS维度进行账务分析。对于一些通道，财务，运营人员还需要下载对账文件进行查账。
2.4 分润模块
分润，就是按照事先约定好的比例，将钱分给使用公司默认支付渠道的代理商（支付商户号都是挂到公司服务商名下）。以此来奖励代理商，扩展更多商户使用公司支付渠道进行支付。
当然如果商户支付账号进件是代理商自己的服务商，那么SaaS软件服务商不提供分润服务。分润服务需要代理商向上游支付渠道申请。
2.5 分账模块
分账，就是钱开始是统一由一个收款账号进行收款，在分账日时，按照事先约定好的比例对参与方进行划分交易收入。通常是多个分门店进行交易，商家总部收款在分账日时会按比例分账。
三、4大支付场景
这里我们以商户零售常见支付场景分类，来分析它的支付交易流程。
3.1 B扫C支付场景
B扫C支付，也称为条码支付，被扫支付。就是商家拿扫码设备扫描顾客支付二维码。
在零售场景B扫C支付方式居多，用户只需要打开付款码，收款操作由商家操作。
顾客在店消费后，收银员在终端POS收银台操作生成支付订单，收银员使用扫码设备扫描顾客APP（微信，支付宝，云闪付）付款码，支付中台在收到支付请求后，会请求上游支付通道。
上游支付通道根据密码验证规则来判断是否输入支付密码，输入密码完成支付，或者不输入密码直接免密支付。
刷脸支付，依托于终端设备，通过面容获取付款码。常见的有微信刷脸和支付宝刷脸。刷脸设备其实和B扫C原理类似，只不过之前是设备扫描顾客手机，获取的是手机付款码支付。现在是设备扫描人脸获取一个对应的面部付款码。之后还是调用B扫C接口进行支付。
3.2 C扫B支付场景
C扫B支付，也称为主扫支付，就是顾客扫描商家生成一个带金额的动态码（只支持扫码一次）。
由商家根据用户选择的商品生成支付订单，商家点击支付，终端POS副屏会显示一个动态的收款码。
顾客扫描收款码，手机APP会跳转到一个带有金额的页面中（金额无法修改），顾客点击支付，输入密码便完成交易。
3.3 JSAPI支付场景
JSAPI，就是预下单支付。顾客先下单后输入账单金额密码进行支付操作。常见的应用场景有两类：
- 码牌，顾客扫描静态码牌，手动输入订单金额进行付款。
- 公众号，小程序：顾客用公众号/小程序下单，输入密码进行付款。
其中码牌，主要是小商户，小摊贩使用居多。
对于做小本生意购入一个终端POS设备成本较高，使用静态码牌收款方便省成本。当然它的缺点也显而易见，无法查询顾客购买商品详情。
3.4 APP支付场景
APP 支付，就是发生在商家APP内的支付。
在商家APP内发起支付时，支付中台会请求上游支付通道，获取预支付信息。
商家APP拿到支付预支付信息后，拉起本地第三方支付方式SDK（支付宝，微信等），最终在第三方应用内完成支付。
最终我们将业务抽象出一套围绕支付业务为核心的支付中台。SaaS软件服务商可以借助支付中台打造自己的护城河。
作为护城河主要是以下三个原因：
- 支付能力多业务线共享，节省人力资本，提升产研和运营管理效率。
- 将原有业务系统支付解耦，统一封装收银API到支付中台系统中，开发能快速兼容新的支付渠道，对接效率极大提升。
- 支持多渠道切换，手续费，佣金存在优势，吸引商户使用。为公司和代理商获得额外睡后收入，帮商户减少支付成本。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
