将

常见业务抽象为一组工具，可供多个业务线使用，包括支付中台。本文详细分析了新零售中的“支付中台”，具体操作方法，以及相关的模块和场景，希望对您有所帮助。

中台是将一般业务抽象和组织成一套工具。由多个业务线使用。

同理，支付中台是一套抽象和组织支付能力的支付工具，可以支持多条业务线同时使用。

使用统一的平台完成与支付相关的常见流程，并进行模块化打包。

1. 为什么，如何

一开始，SaaS 软件服务提供商在只有一条业务线的情况下只需要进行一组付款。当业务快速发展时，SaaS 软件服务提供商拥有多条业务线，在支付的管理和功能上会有很多重叠的环节。

1.1 为什么

SaaS 服务提供商单独开发和运营这些链路，这将消耗人力成本并降低 SaaS 服务提供商的效率。例如，运营商需要同时管理多个支付渠道和交易流，还需要为商户配置支付账户。

SaaS 软件服务提供商需要一种解决方案来解决支付服务效率低下的问题。

如果实施了支付中台，运营商可以通过一个平台管理多个商户入账、商户支付配置、交易流转对账、利润分享、账户共享等信息。

开发者可以在支付中台的架构下快速连接支付渠道或引入新的商业模式。从而满足市场的需求。

为了同时支持多种格式的支付业务，提升SaaS服务提供商的核心竞争力，构建支付中台迫在眉睫。

1.2 怎么做

我们来分析一下SaaS软件服务提供商的收银业务线，主要包括SaaS收银业务线和大型超市收银业务线。终端设备主要包括POS、小程序、WEB、刷脸设备、码卡和APP。

当用户使用终端进行交易时，涉及的核心支付业务流程主要是发起支付、查询订单、退款和取消。

SaaS 软件服务提供商不仅要具备支付功能，才能使商户店铺支付的业务流程顺利进行。还需要上报商户信息，开通和配置商户支付账户，为支付账户配置支付路由通道，提供多维度对账报表，为代理商提供利润分享服务，为商户提供账户分享服务。

二、支付平台的五大模块

以下基于五个模块：商户账户配置、支付、对账、利润分享和账户共享。

2.1 商户账户配置模块

账户配置是为商家提供集合账户配置服务。对于 SaaS 软件服务提供商来说，最终支付服务的对象是商家。商家在开店时需要收款，最后一笔钱必须到商家指定的账户。那么商家的支付账户从何而来呢？您如何为操作员配置它？商家

要想具备支付和收款的能力，必须向第三方/第四方支付渠道平台申请（报送经营资质等信息），并获得支付网络准入许可，即商户的准入。

运营商或代理商可以在支付中心为商家输入商品，帮助商家避免繁琐的进货流程。

商户进货通常分为两类：一类是直连模式，另一类是服务提供商模式。

直连模式是指商户在第三方/第四方支付渠道下直接申请支付商户编号。

服务提供商模式是 SaaS 软件服务提供商或代理帮助商家申请第三方/第四方支付渠道下的支付账户，支付商家与自己的服务提供商名称相关联。至于商家入金，可以由商家选择。两者最大的区别是支付率不同。

通常，商家选择使用服务商模式是因为付款率较低。其中，服务提供商模式不仅支持默认服务提供商（SaaS 软件服务提供商），还可以为代理添加自己的支付通道服务提供商信息。

商家选择采用服务商模式，只要门店有支付交易流转，就会给服务商带来睡后收入。这也是高频交易场景的软件服务提供商愿意做支付中台的主要原因之一。

如何配置支付账户？

那里

支付中台中只有两个角色有权配置支付账户：操作员和代理。支付中台有多个支付渠道，运营人员需要将支付通道配置权限分配给代理。

为商户下的多个店铺配置不同的支付渠道。配置渠道后，您可以为不同的支付环境设置路由配置。

2.2 支付核心系统模块

支付是指用户在商户终端的收银台购买商品和服务并完成支付操作。支付收银台的终端环境包括 POS、小程序、人脸扫描设备、WEB 页面、码卡等。围绕付款的业务流程的主要环节是：付款、查询、退款和冲销。

对于终端收银的业务流程抽象，我们可以封装一套支付收银 API，然后不同的业务终端可以快速嵌入到支付业务流程中。

对于支付，我们可以将其分为不同的支付场景：B 扫描 C、C 扫描 B、APP 支付等。

在正向交易中订单完成后，还需要主动查询支付状态或等待支付结果的异步通知。

如果在支付过程中出现支付超时，则客户已完成支付，系统尚未收到支付成功信息，可以撤销，按原方式退还金额;如果付款失败，订单将在取消后关闭。

正常支付成功后，您可以使用退款申请退款。同时，您可以使用退款查询来确定最终的退款状态。

（1） 收银 API 封装

统一订单入口：B扫C、C扫B、APP支付等。

订单查询：如果订单状态不是 ，则提供 API 在待付款或退款过程中查询订单。

订单撤销：支付失败或支付成功但订单超时时发起取消。付款订单将被关闭，以防止重复付款。

退款请求： 订单反向。

：支付或退款回调，即上游渠道推送的支付或退款状态的通知。支付中心更新订单状态，并将状态信息同步推送给下游业务。

（2） 支付核心

支付核心处理来自上游收银员的支付请求，并根据支付账户的路由配置确定支付通道的最终执行。这是订单最终付款和付款指示交付的前提条件。

（3） 支付渠道

支付渠道，根据客户不同的支付场景，系统兼容新的支付渠道。支付渠道完成从内部支付中心到外部支付渠道的支付指令的投递。

2.3 对账模块

对账是检查和比较商店的交易数据以防止会计错误问题的操作。对于关心店面利益的人来说，它是必不可少的。

对帐从付款记录开始。从商店、日、收银员和 POS 维度分析账户。对于部分渠道，财务、运营人员也需要下载对账文件进行审计。

2.4 利润分享模块

分润是指将款项按照预先约定的比例分配给使用公司默认支付渠道的代理商（支付商户编号列在公司服务提供商的名称下）。通过这种方式，我们将奖励我们的附属公司并扩大更多商家使用公司的支付渠道。

当然，如果商家的支付账户是代理自己的服务提供商，那么 SaaS 软件服务提供商不提供利润分享服务。利润分享服务需要代理商向上游支付渠道申请。

2.5 账本共享模块

账户共享是指在账户共享之初由一个收款账户收取资金，并在账户共享日期按照预先约定的比例在参与者之间分配交易收入。通常，交易由多个分支机构进行，商户总部的收款将在账户共享日按比例拆分。

3. 4 种主要支付场景

在这里，我们将对商户零售的常见支付场景进行分类，以分析其支付交易流程。

3.1 B 扫描 C 支付场景

B 扫码 C 支付，又称条码支付，就是扫码支付。是商家用扫码设备扫描二维码，扫描客户付款的二维码。

在零售场景下，B scan C 支付方式居多，用户只需开通支付码，收款操作由商户操作。

客户在店内消费后，收银员在终端POS收银台操作生成支付订单，收银员使用扫码设备扫描客户APP（微信、支付宝、银联）的支付码，支付中心收到支付请求后会向上游支付渠道请求。

上游支付通道根据密码验证规则决定是输入支付密码、输入密码完成支付，还是不输入密码支付。

人脸支付，依托终端设备，通过人脸获取支付码。常见的有微信刷脸和支付宝刷脸。刷脸设备其实跟B扫描C的原理差不多，只是设备之前扫描了客户的手机，获取了手机支付码支付。现在是时候让设备扫描面部以获取相应的面部支付代码了。之后，还是叫 B 扫 C 接口付费。

3.2 C 扫描 B 支付场景

C-scan B 支付，又称主扫支付，是指客户扫描商户生成一个带有金额的动态码（仅支持一个扫码）。

商户根据用户选择的商品生成支付订单，商户点击支付，终端POS副屏会显示动态支付码。

客户扫描支付码，手机 app 会跳转到有金额的页面（金额无法修改），客户点击支付并输入密码完成交易。

3.3 支付场景

，即预购付款。下单后，客户输入账单金额密码进行支付。有两种常见的应用程序场景：

码卡，客户扫描静态码卡，手动输入订单金额进行支付。公众号、小程序：客户使用公众号/小程序下单，输入密码进行支付。

其中，码牌主要供小商家和小商贩使用。

对于小型企业来说，购买终端POS设备的成本很高，使用静态码卡收钱很方便，可以节省成本。当然，它的缺点是显而易见的，无法查询客户的购买细节。

3.4 APP 支付场景

APP 支付是发生在商家 APP 中的支付。

在商户 App 中发起支付时，支付中台会请求上游支付通道获取预付费信息。

商户 APP 获取到支付预付费信息后，拉起本地第三方支付方式 SDK（支付宝、微信等），最后在第三方应用中完成支付。

最后，我们将业务抽象成一套以支付业务为核心的支付中台。SaaS 软件服务提供商可以借助支付中台构建自己的护城河。

成为护城河的主要原因有三个：

多条业务线共享支付能力，节省人力资本，提高生产、科研和运营管理效率。将原有业务系统的支付解耦，将收银员 API 统一打包到支付中台系统中，开发后可以快速兼容新的支付渠道，大大提高了对接效率。支持多渠道切换，手续费、佣金有优势，吸引商家使用。为公司和代理商创造额外的床后收入，帮助商家降低支付成本。

本文最初由 @ on is a 发布。未经作者许可，禁止复制。

标题图像来自 基于 CC0 许可证。

本文中的视图仅代表作者本人，大家都是产品经理，平台仅提供信息存储空间服务。