全文共10743个字，建议先收藏，分多次慢慢阅读

掌握了通用的支付设计方法后，还需要能够将其应用到各个领域、不同场景中的具体设计中。下图是我抽象出的支付产品经理能力地图，而本文则是对通用支付设计能力在新零售领域应用的详细拆解。

万字详解零售支付：支付全景、渠道聚合、支付中台、进件与配置

零售业就是商家将商品或服务在场所中卖给消费者。其中的关键词就是人，货，场。本文将详细全面的拆解新零售支付体系，包括零售场景分析、外卖平台渠道的聚合、支付中台建设、商家的渠道进件与支付配置

1.新零售全景拆解

1.1.新零售概述

1.1.1.传统零售货找人

传统零售业,只能在固定场所销售商品或服务，以商家店为中心只能够辐射周边小范围的人群，对于财务、商品库存等管理效率很低。

比如我们去小卖部买东西，一手交钱一手交货。商家基本不会记账，好一点的可能会拿个账本记录这笔交易。

有时候只有当你买这个商品的时候，商家才会发现这个商品缺货了，商家无法进行有效的库存管理。

又因为商家店铺服务范围小，只能货找人，客户的需求，商家也不能全部满足。

1.1.2.新零售人找货

随着互联网和经济的发展，零售行业有了数字化的能力的加持，商家将店面管理实现数字化运营。

销售场所不在局限于线下场所，客户可以在商家的线上商城找到商品，进行下单购买，也可以不需要在面对面进行交易。

新零售就是借助互联网技术，实现了人找货，客户再也不需要局限于固定的商家，可以通过线上平台满足自己的需求。

比如，现在的淘宝，京东，可以购买到生活周边无法提供的商品。

而线下固定场所，也可以借助线上店铺平台进行引流。这就是新零售。

1.1.3.新零售的支付

在新零售中，平台管理商家、商家管理货物、用户通过平台下单。

一切的交易都需要有钱的参与，而在这其中将三方串联起来，正是支付。

用户下单，此时只是一个临时单据，不付钱平台不会通知商家发货，用户支付完成后，平台通知商家发货并减少库存，商家发货，然后用户收货后，平台将对应的金额结算给商家，而这其中平台也会分走一部分利润

由此可见，钱的流转涉及到每一个环节，支付也不单纯的只是用户付款，而是整个流程。

1.1.4.新零售的业态

在零售业有一个概念：业态。业态通常就是指商家向顾客提供商品和服务的具体形式。

比如我们常见的业态有：便利店，连锁店，大型超市，电商等等。在不同业态下，商家都有各自的细分行业特点和痛点。

纵观零售业其实最终就是要实现一笔客户到商家的交易，商家提供商品服务。软件服务商会根据此业态提供不同的解决方案。

随着支付方式的演化，要让商家支持市面上通用的支付方式，新零售也要实现线上支付交易。

下面关于新零售支付流程从业务流和全局产品体系做一个简单分析。

1.2.新零售业务流程

梳理支付上下游业务关系有哪些，就拿客户到店点餐下单交易为例：

客户进店来到收银台，告诉商家我要吃什么菜品，收银员提交订单后，就跳转到支付收银台，选择支付方式，顾客进行付款操作。或者使用商家提供扫码点餐，用上商家小程序进行自助下单支付。

完成订单后商家进行履约。

在提交订单后续的动作就属于支付中台的业务范畴。

万字详解零售支付：支付全景、渠道聚合、支付中台、进件与配置

上面只是一个简单的支付场景的模型，我们需要把这个抽象出来的支付模型放到全局的业务流中，去认识新零售行业业务模型。其中包括客户流，商家流，交易流。

商家注册成为saas软件商户，商家获客，最终客户下单商户进行履约。交易流连接商家和客户。

万字详解零售支付：支付全景、渠道聚合、支付中台、进件与配置

1.2.1 客户侧流程

商家通过线下营销线索，或者线上引流平台吸引客户流量前来消费。

线下营销：发店面广告单页，活动单页。

线上引流平台营销：抖音，小红书，大众点评，商家小程序发布店面活动信息。可以在外卖平台:美团，饿了么，饿百平台创建线上门店，也可以使用商家小程序。商家可针对客户进行会员管理，制作营销活动，通过会员营销短信进行通知。

客户到店或线上平台进行下单购买，最终客户获得商家提供的服务分为三类：外卖，堂食，自提。

万字详解零售支付：支付全景、渠道聚合、支付中台、进件与配置

1.2.2 商家侧流程

对于公司saas平台来说，要想找到商户使用我们的软件。主要通过公司渠道或者是代理商注册成为商户。

其中公司渠道分为两大类：

1）公司线上线下营销线索

比如：全国性质的线下新零售大会展厅，官方网站，公众号，抖音等线上平台进行宣传。

2）公司区域销售经理

其中代理商是：通过公司的代理商注册为商户，成本更低。

意向商家提供以上方式最终成为saas软件中的商户，商家一键开店，购买符合商家业态类型的产品包和收银设备，开通线上聚合支付，即可进行收银和管理门店运营。

万字详解零售支付：支付全景、渠道聚合、支付中台、进件与配置

1.2.3 交易流程

交易流是搭起客户和商家的重要桥梁。客户选购服务/商品下单支付。下单支付时创建账单，涉及到支付路由和鉴权通道。支付中台根据规则找到最优支付渠道，进行下单支付。

完成支付后，业务后台进行扣件商品库存,积分计算等操作。其中这个交易流的核心就是支付。

商家如果是由代理商邀请注册，支付路由通道走的是公司的渠道商户号，那么关于商家的交易流水就涉及到分润。代理商可在中台进行查看名下商户的交易数据，分润明细。

代理商进行分润提现，支付中台审核通过后，获得分润收益。或者代理商可以配置走自己的支付通道账号，此时代理商就不涉及到在我们平台进行分润的业务。

万字详解零售支付：支付全景、渠道聚合、支付中台、进件与配置

1.3新零售的产品体系

1.3.1 全局产品架构图

整个新零售支付行业的相关业务，公司根据商户用户体量和业务需求，对此行业分为两个服务形式为用户群体提供收银服务。

saas云产品服务：以快餐，果蔬，便利为主的泛行业和农贸市场(生鲜肉食行业) 。

私有化部署程序：主要针对中大型连锁/单店商超。

公司提供saas运营中台进行管理两大产品主线服务，监控管理代理商，商户，产品增值服务，聚合外卖，聚合支付等平台。

我们通过公司产品架构图能够一览新零售行业产品特点：线下POS和线上小程序来触达顾客。由后台系统提供主要业务支持。

万字详解零售支付：支付全景、渠道聚合、支付中台、进件与配置

通过公司产品架构图，我们来简单分析下公司系统架构图。公司要让2大产品线运行起来就需要一个完善的体系支撑起来。

以下主要从：终端，应用接入层，引用服务层，基础设施层，和监控层几大模块进行分析。

通过这张架构图我们能看到支付中台在系统中架构的位置，整个产品业务线核心其实就是围绕支付。监控层在为监管商户支付配置保驾护航。

万字详解零售支付：支付全景、渠道聚合、支付中台、进件与配置

1.3.2 后台产品架构

商家后台主要是帮助商家能够进行商品管控，商品进销存，查看交易流水报表，营销活动，库存预警等功能。我们可以通过POS收银端和线上商城端业务来分析。

上架商品服务，活动营销，会员储值，优惠券配置等功能商家都可以在商家店铺后台进行个性化配置。

万字详解零售支付：支付全景、渠道聚合、支付中台、进件与配置

1.3.3 支付中台服务层产品架构

中台中抽象出公司两大产品线：saas产品和私有化产品支付的底层共同能力，形成了支付中台。

支付中台处理来自商户后台系统的订单信息，在公司内部产品线，经过支付中台完整最终交易的最后一环。

支付中台主要包含：针对商户的支付账号配置，支付中心，对账功能，以及分润清算中心。

支付中台最终将符合支付账单的指令传递给外部系统，中台等待外部系统响应最终交易状态。最终同步商户后台订单状态信息。

万字详解零售支付：支付全景、渠道聚合、支付中台、进件与配置

2.聚合外卖渠道

在过去，商家普遍使用传统POS收银软件进行线下店面收银，可以在一定程度上提升收银效率。

之后随着O2O外卖渠道的发展，越来越多的商家选择在线上平台运营门店，提升商家曝光效应，进而来扩大门店客流量。甚至商家会在多个线上平台运营门店。

O2O外卖，就是消费者在线平台下单，购买服务、商品，在线下商家完成服务履约。比如：美团，饿了么等。这里的平台/渠道就是指的订单来源。

2.1.新的挑战

商家在不同平台一遍一遍重复建立商品的繁琐操作。

当多平台线上订单量急增时，门店订单履约效率会大幅降低，商家就特别容易出差错，备错货，从而造成线上门店评分低。

本来是借助线上平台来提升门店的曝光率的，现在却适得其反。这时候，商家就需要考虑，多雇个帮手来管理不同线上平台的门店。雇人，对商家来说又增加了人力成本。

2.2.运营管理模式

商家需要把线下门店商品,手动同步到线上不同渠道上的门店中。
商家在兼顾线下门店收银的情况下，还需要兼顾不同线上门店的新订单履约
商家定期需要切换不同渠道平台进行对账，商品库存盘点清算。
商家可能还会定期对一些会员，搞一些促销活动宣传

通过上述商家操作，我们可以看出来商家运营门店主要通过五个模块：商品管理、订单履约、数据对账、会员运营、促销活动。

虽然，不同业态侧重点不同，但商品管理、订单履约、数据对账是运营的核心。

面对繁多的线上平台，作为商家最头疼的就是：多门店无法统一管理。商品需要在多个平台同步，订单无法统一管理，导致对账困难。

那么作为saas收银软件服务商，如何解决商家遇到的上述痛点呢？

因为商家在线下收银使用的是我们的服务，那么我们只需要将其他平台聚合到我们的服务中，让商家只需要在我们的服务中操作一次即可，这就是多渠道聚合。

2.3.业务流程

商家订单来源，主要来自线下门店和线上多渠道门店。门店的相关数据都保存到对应平台中,导致数据不同步。

我们可以将线下和线上订单数据进行同步，借助商家线下POS终端和saas商户后台来实现订单履约管理。最终,实现多端数据统一管理。

2.4.聚合四件套：门店、商品、履约、对账

2.4.1.门店映射

首先要做的就是进行门店统一。商户后台需要提供线下门店账号和外卖平台账号进行绑定映射。

加载商户门店列表
选中要进行映射的门店进行绑定
跳转到外卖平台登录界面并进行登录
外卖平台会加载出该账号下的门店，勾选保存成功
外卖平台会推送绑定成功消息到商户后台，然后商户后台成功保存线下和线上门店的映射关系。

2.4.2.商品映射

线上多平台门店要和线下门店进行商品同步，主要包括：商品基本档案,商品的价格、库存、上下架。

在门店映射的基础之上，商家可以将本地商品批量上传到外卖平台。上传商品时只需要将核心的SKUID，分类，商品名称等基本信息和线上平台一一对应即可。

商家还需要进行商品映射，商品映射这一步是计算库存的核心。

只有进行商品映射之后，商家在saas商户后台才能够查看到来自不同平台消耗的库存量。

对于商品单品的常用基本操作主要是价格、库存、上下架，我们可以将此操作集成到商家后台,以提升效率。

2.4.3.订单履约

为了提升商家多店订单履约效率，我们将订单业务操作分为：接单，出餐，配送，订单完成，退款审核和发起退款功能，统一放到POS终端设备上。

用户在外卖APP中选品并下单支付，最终由商家提供给用户商品。至于这笔订单的支付流程如何支付收款？商家线下提供的商品要如何进行配送？

它们都是由外卖开放平台来提供支持的，saas软件服务商都无需关心。saas软件服务商需要关心的一点就是要将订单基本信息和状态同步正确。

订单正向履约流程：用户下单支付后，外卖平台将新订单推送给商户后台，商户后台写入数据库。

POS终端通过轮询监听的方式，提醒商户有新订单。商户可以在POS终端接单或拒单。

如果拒单，订单直接取消并退款结束。

如果进行接单，订单状态会同步给外卖平台。商家备货后在POS终端点击出餐，状态同步给外卖平台。外卖平台会根据门店签约的配送服务,来决定是否支持自动发配送。

如果是，则由平台进行配送履约，平台配送完成后，由平台推送订单完结状态。反之，商家可自动发起平台其他配送服务进行配送履约服务，履约完成状态同步回商户后台。商家也可以线下自配送履约。

如果商家自配送，则需要商家自动确认订单完结，saas软件服务商会将此状态同步到外卖平台。

订单完结之后，saas软件服务商就需要写入流水并计算商品库存。

订单逆向退单流程：涉及到的就是钱和商品。当订单已经完结用户申请退单时，商家审核通过后,进行退款，并写入退款流水和库存。如果申请退单，是未完结的订单，则直接退款取消订单。

商户后台系统需要记录:订单的来源，系统订单号，订单金额，订单状态等信息;订单详情要记录订单的品名称，本地映射商品ID,价格，配送费等基本。

2.4.4.对账报表

商户后台会基于以上多平台订单履约数据和商品映射关系，进行流水报表不同维度的展示，比如：根据交易流水，商品流水，支付流水进行确认。针对于收款对账：分为收款员对账，交班对账，收款日对账几个维度展示。

2.4.5.新零售渠道聚合之道

saas软件服务商针对商户运营多门店：提供外卖渠道聚合，解决线上和线下门店数据不同步问题，提供数字化解决方案，助力商家高效运营门店。将此打包外卖渠道解决方案打包成增值服务，提供给商户。

其实市面上不光是O2O外卖平台，还有O2O零售平台(比如：京东到家，饿百，闪购)，核心业务流程和我们以上分析的这个外卖聚合平台类似。

我们可以把外卖平台中的配送看作是快递业务，只不过这个“快递”配送是短时间内的，零售类因为配送范围远，配送时长也更长。

最终都是由商家提供商品、服务，借助O2O平台提供的配送/物流实现订单履约。完全也可以将这一类O2O零售/外卖平台，做成聚合通道，为商家提供多平台门店运营服务,提升运营效率。

3.新零售“支付中台”

中台，就是把通用业务，抽象整理成一套工具。供多个业务线使用。

同理，支付中台，就是将支付能力抽象整理出的一套支付工具，能同时支撑多个业务线使用

用统一的平台来完成支付相关的共通流程，进行模块化封装。

3.1.为什么，怎么做

在最初，saas软件服务商，只有一条业务线时，只需要做一套支付。当业务高速发展时，saas软件服务商存在多条业务线，对支付的管理和功能上就会有很多重合环节

3.1.1.为什么

saas服务商对这些环节做单独开发和运营配置，就会很耗费人力成本，降低了saas服务商效率

比如：运营人员需要同时管理多个支付渠道和交易流水，还需要为商户配置支付账号。

saas软件服务商需要一套解决方案，来解决支付服务效率低的问题。

如果实现了支付中台，运营人员可以通过一个平台进行管理多个商户进件、商户支付配置、交易流水对账、分润、分账等信息

开发人员，能够在支付中台的架构下，快速进行支付渠道对接或者引入新的业务模式。从而满足市场的需求。

为了能够同时支持多种业态的支付业务，提升saas服务商的核心竞争力，搭建支付中台迫在眉睫。

3.1.2.如何做

我们来分析一下saas软件服务商的收银业务线，其中主要包含saas收银业务线和大型商超收银业务线。终端设备主要有POS，小程序，WEB,刷脸设备，码牌和APP。

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

saas软件服务商要使得商家店面支付业务流程跑通，不能仅仅只有支付功能。还需要对商户信息进件报备，开通商户支付账号并进行配置，对支付账号配置支付路由渠道，提供多维度对账报表，为代理商提供分润服务，以及给商户提供分账服务。

3.2.支付中台的5大模块

下面以商户账号配置、支付、对账、分润、分账五个模块来搭建支付中台。

3.2.1.商户账号配置模块

账号配置，就是为商家提供收款账号配置服务。对saas软件服务商来说，支付最终服务的对象就是商家。商家开店要收款，最终钱要收到商户指定的账号内。那么商户的支付账号从哪里来?运营人员如何进行配置呢？

商户要拥有支付收款能力，必须得向第三/四方支付渠道平台申请（将营业资质等信息报备），获得支付入网许可，这就是商户进件。

运营人员或代理商可在支付中台替商户进件，帮商家免去进件繁琐过程。

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

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

服务商模式就是saas软件服务商或者代理商在第三/四方支付渠道下，帮商户申请支付账号，将该支付商户挂到自己服务商名下。关于商户进件，可以由商户自主选择。两者最大的不同就是，支付费率不同。

通常，商户会选择使用服务商模式,因为支付费率更低。其中服务商模式不只是支持默认服务商(saas软件服务商)，还可以为代理商添加自己的支付渠道服务商信息。

商户选择走服务商模式，只要店面有支付交易流水，便会为服务商带来睡后收益。这也是为什么拥有高频交易场景的软件服务商愿意去做支付中台的一个主要原因。

如何配置支付账号？

支付中台拥有支付账号配置权限的就只有两种角色：运营人员和代理商。支付中台有多个支付渠道，需要由运营人员给代理商赋值支付渠道配置权限。

对商户下的多个门店，进行配置不同的支付渠道。配置完渠道之后，可以对不同的支付环境设置路由配置。

3.2.2.支付核心系统模块

支付，就是用户购买商品服务，并在商户终端收银台完成付款操作。支付收银台终端环境有POS、小程序、刷脸设备、WEB页面、码牌等等。业务流程围绕支付的主要环节就是：支付，查询，退款，撤销。

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

对于支付，我们又可以按照不同的支付场景分为：B扫C，C扫B，JSAPI,APP支付等。

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

在支付过程中出现支付超时，顾客已经支付完成，系统还未接收到支付成功信息，可以撤销，金额会原路退回；如果是支付失败，撤销后便关闭订单。

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

1）收银台API封装

统一下单入口：B扫C,C扫B,JSAPI ，APP支付等等

订单查询：订单状态不是最终终态时，支付等待中/退款中时，提供接口进行轮询查询。

订单撤销：支付失败，或支付成功但订单超时时，发起撤销。将关闭支付订单，防止出现重复支付的情况。

退款申请：订单逆向流程。

回调：支付或退款回调，上游渠道推送过来的支付或退款状态通知。支付中台更新订单状态，并对下游业务进行同步推送状态信息。

2）支付核心

支付核心，处理来自上游收银台支付请求，并且根据支付账号配置路由，确定最终执行的支付渠道。它是一笔订单最终完成支付，传递支付指令的前置条件。

3）支付渠道

支付渠道,根据客户不同支付场景，系统兼容对接新的支付渠道。支付渠道来完成支付中台内部的支付指令向外部支付渠道的传递。

3.2.3.对账模块

对账，就是对门店交易数据进行核对对比的操作，防止出现错账问题。它对于关心店面利益的人不可或缺。

对账从支付记录入手。从门店、日、收银员、POS维度进行账务分析。对于一些通道，财务，运营人员还需要下载对账文件进行查账。

3.2.4.分润模块

分润，就是按照事先约定好的比例，将钱分给使用公司默认支付渠道的代理商（支付商户号都是挂到公司服务商名下）。以此来奖励代理商，扩展更多商户使用公司支付渠道进行支付。

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

3.2.5.分账模块

分账，就是钱开始是统一由一个收款账号进行收款，在分账日时，按照事先约定好的比例对参与方进行划分交易收入。通常是多个分门店进行交易，商家总部收款在分账日时会按比例分账。

3.3.四大支付场景

这里我们以商户零售常见支付场景分类，来分析它的支付交易流程。

3.3.1.B扫C支付场景

B扫C支付，也称为条码支付，被扫支付。就是商家拿扫码设备扫描顾客支付二维码。

在零售场景B扫C支付方式居多，用户只需要打开付款码，收款操作由商家操作。

顾客在店消费后，收银员在终端POS收银台操作生成支付订单，收银员使用扫码设备扫描顾客APP（微信，支付宝，云闪付）付款码，支付中台在收到支付请求后，会请求上游支付通道。

上游支付通道根据密码验证规则来判断是否输入支付密码，输入密码完成支付，或者不输入密码直接免密支付。

刷脸支付，依托于终端设备，通过面容获取付款码。常见的有微信刷脸和支付宝刷脸。刷脸设备其实和B扫C原理类似，只不过之前是设备扫描顾客手机，获取的是手机付款码支付。现在是设备扫描人脸获取一个对应的面部付款码。之后还是调用B扫C接口进行支付。

3.3.2.C扫B支付场景

C扫B支付，也称为主扫支付，就是顾客扫描商家生成一个带金额的动态码（只支持扫码一次）。

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

顾客扫描收款码，手机APP会跳转到一个带有金额的页面中（金额无法修改），顾客点击支付，输入密码便完成交易。

3.3.3.JSAPI支付场景

JSAPI ,就是预下单支付。顾客先下单后输入账单金额密码进行支付操作。常见的应用场景有两类：

码牌，顾客扫描静态码牌，手动输入订单金额进行付款。
公众号，小程序：顾客用公众号/小程序下单，输入密码进行付款。

其中码牌，主要是小商户，小摊贩使用居多。

对于做小本生意购入一个终端POS设备成本较高，使用静态码牌收款方便省成本。当然它的缺点也显而易见，无法查询顾客购买商品详情。

3.3.4.APP支付场景

APP 支付，就是发生在商家APP内的支付。

在商家APP内发起支付时，支付中台会请求上游支付通道，获取预支付信息。

商家APP拿到支付预支付信息后，拉起本地第三方支付方式SDK（支付宝，微信等），最终在第三方应用内完成支付。

最终我们将业务抽象出一套围绕支付业务为核心的支付中台。saas软件服务商可以借助支付中台打造自己的护城河。作为护城河主要是以下三个原因：

支付能力多业务线共享，节省人力资本，提升产研和运营管理效率。
将原有业务系统支付解耦，统一封装收银API到支付中台系统中，开发能快速兼容新的支付渠道，对接效率极大提升。
支持多渠道切换，手续费，佣金存在优势，吸引商户使用。为公司和代理商获得额外睡后收入，帮商户减少支付成本。

4.“商户进件”与“支付账号”配置

在现在国内支付环境下，商户开店，就需要为用户提供支付服务，来完成收款业务。商家如果要使用支付服务，必须要商户进件入网成功后拿到支付账号并且配置到商户收银支付系统才可以算是为用户提供支付服务。

4.1.环境和目的

我们先来简单分析下商户的支付环境和商户进件的目的。

4.1.1.支付环境

根据商家开店场景：分为线下实体店和线上店铺。

进而我们可以将支付场景划分为：线下支付和线上支付。

线下支付是指在实体场所中发生的支付交易，比如：现金，码牌（主扫支付-静态码），条码支付（被扫支付），动态码支付(主扫支付)等其中一种支付类型。

线上支付是指在网上完成的支付交易。比如：电商商城，小程序，公众号等支付方式。

4.1.2.商户进件目的

就是将商家真实信息资料上传到指定渠道下。其中进件所选的渠道决定了用户在收银台所使用的支付方式。比如要支持支付宝、微信，就需要两个都进行进件。

商户为什么要进件呢？

一方面是为了完成商户真实性、合规经营等信息获取支付服务。另一方面，为了税收监管，防止洗钱，防止有虚假商户存在交易，无法追踪收取税务的问题。银监会的交易数据和税务总局税收要成正比。其中如果因为商户真实性未落实，产生的交易数据应该向谁去收取税呢？这时候收单机构就会被惩罚，如此一来就会由上级一层一层往下卡，来完成对商户真实性进行认证监管。

下面我们来详细分析下商户进件和支付账号配置的业务流程。