zd_product_document/10-产品线/聚合支付/01-产品发现与MVP方向.md

聚合支付系统产品发现与 MVP 方向

1. 发现结论

聚合支付系统 1.0 不应定位为一个覆盖支付、对账、清分、分账、结算全部环节的“大而全资金系统”，而应定位为：

面向连锁经营企业，统一连接门店收银场景与多个支付渠道，提供统一受理、统一交易管理、统一通道配置和统一支付结果输出的支付接入中台。

首期优先服务已有连锁客户，解决多门店、多商户号、多支付通道下接入分散、配置复杂、交易状态不一致和故障处置困难的问题。

聚合支付系统负责“把交易可靠地支付成功并形成标准支付流水”；连锁业务对账系统负责“确认订单与渠道结算是否一致”；分账系统负责“把确认后的资金按规则分配和结算”。

2. 产品机会

2.1 目标客户

首期目标客户：

• 拥有多个直营网点或加盟门店的连锁餐饮企业
• 已有 POS、扫码点餐、小程序等交易入口，需要统一支付能力的连锁品牌
• 同时使用微信、支付宝、银联或银行聚合通道的企业
• 需要总部统一管控支付参数、门店交易和通道运行情况的企业

后续可扩展客户：

• 连锁零售、鞋服、药店等多门店企业
• 为多个商户提供交易服务的互联网平台
• 需要支付能力输出的软件服务商和行业解决方案商

2.2 核心用户

用户	需要完成的工作	当前主要问题
集团财务	掌握各门店、渠道的支付交易	多渠道后台分散，支付口径不一致
支付运营	配置商户、门店和支付通道	参数多、配置易错、变更难追踪
门店店员	快速完成收款、退款和订单查询	支付失败原因不清，异常处理依赖总部
IT 人员	将 POS、小程序等系统接入支付	每个渠道重复开发，接口和签名规则不同
客服人员	查询交易状态并处理支付投诉	缺少统一交易视图和完整处理轨迹
管理人员	评估通道稳定性和交易规模	缺少统一指标和异常监控

2.3 核心问题

系统首期应回答以下问题：

• 一个品牌、门店和收银终端应使用哪个支付商户号和支付通道？
• POS、扫码点餐、小程序如何通过一套接口完成多渠道支付？
• 支付请求是否成功，最终状态是什么？
• 回调丢失、状态未知、重复请求时如何保证交易正确？
• 支付失败后，门店和运营人员如何判断原因并恢复业务？
• 退款是否成功，原支付与退款记录如何关联？
• 如何向对账系统输出完整、标准、可追溯的支付流水？

3. 产品边界

3.1 聚合支付系统负责

• 支付渠道和通道接入
• 平台统一维护收单渠道目录、适配器和能力版本
• 按客户授权可使用的收单渠道
• 门店支付进件申请、资料提交和进度跟踪
• 商户、门店、终端与通道参数配置
• 统一支付、查询、关闭和退款接口
• 支付路由与通道选择
• 收单渠道灰度切换和配置回退
• 支付订单和支付流水管理
• 客户支付应用收单手续费配置和预估计算
• 异步通知、主动查单、幂等和状态一致性
• 交易异常监控与运营处置
• 向业务系统返回支付结果
• 向对账系统输出标准支付流水

3.2 聚合支付系统不负责

• POS 商品、购物车、营销和销售订单管理
• 渠道结算账单与业务订单的财务核销
• 银行入账核对和差异处理闭环
• 多主体清分、分润、结算和出款
• 门店或加盟商利润核算
• 会员储值账户的完整账户体系

3.3 与相邻系统的关系

系统	核心职责	输入	输出
POS/业务系统	生成销售订单并发起收款	商品、订单、应收金额	业务订单、支付请求
聚合支付系统	完成支付受理并统一交易状态	支付请求、通道配置	支付结果、标准支付流水
连锁业务对账系统	核销订单应收与渠道实收	业务订单、支付流水、渠道账单	对账结果、可分账数据
分账系统	按主体和规则完成资金分配	可分账数据、分账规则	分账、结算和出款结果

4. 三视角功能创意

4.1 产品经理视角

1. 统一支付 API：以一套接口承接 POS、小程序、扫码点餐等系统的支付、查询、关闭和退款请求。
2. 多层级商户模型：支持集团、品牌、区域、门店、终端与支付商户号之间的关系管理。
3. 可配置支付路由：按品牌、门店、支付方式、时间或通道状态选择支付通道。
4. 标准支付流水中心：统一不同渠道的交易字段、状态和错误码，并向对账系统输出。
5. 支付运营驾驶舱：展示交易规模、成功率、响应时间、异常类型和通道表现。

4.2 产品设计视角

1. 接入配置向导：按“创建客户—添加门店—绑定商户号—验证通道”的步骤完成开通。
2. 统一交易工作台：通过业务订单号、支付流水号、渠道流水号、门店等条件快速定位交易。
3. 异常处置工作台：将支付中、回调失败、退款异常等交易转化为可操作任务。
4. 门店轻量查询页：允许门店只查询本店交易、重新查单或发起权限范围内的退款申请。
5. 可解释失败提示：将渠道错误码转换为店员、运营和技术人员分别可理解的处理建议。

4.3 软件工程视角

1. 渠道适配器框架：通过统一协议和插件式适配器接入微信、支付宝、银联及银行通道。
2. 支付状态机：明确待支付、支付中、成功、失败、已关闭、退款中、部分退款、已退款等状态及转换约束。
3. 一致性保障机制：通过业务幂等键、回调去重、主动查单和补偿任务解决重复与状态未知问题。
4. 事件输出机制：以标准事件向 POS、对账、监控等下游系统发布支付状态变化。
5. 通道可观测性：监控成功率、延迟、错误码分布、回调积压和查单补偿情况。

5. 优先级最高的 5 项能力

P1. 统一支付 API 与渠道适配器

价值

• 直接降低业务系统接入多个支付渠道的开发和维护成本。
• 是聚合支付产品成立的基础能力。
• 可先接入一个主渠道验证协议，再逐步扩展适配器。

需要验证的假设

• 现有客户确实存在两个及以上支付渠道或收单机构。
• 不同业务入口可以接受统一的支付协议和状态定义。
• 标准接口可覆盖至少 80% 的共同场景，渠道特性可通过扩展字段承载。

P2. 多层级商户与通道配置

价值

• 解决连锁企业区别于单门店支付产品的核心复杂度。
• 为支付路由、权限隔离、交易归属和后续对账提供基础。
• 可通过后台配置和小范围门店试点快速验证。

需要验证的假设

• 集团、品牌、门店、终端和商户号的关系可被抽象为稳定模型。
• 商户号可能被门店独占、多个门店共享或按渠道分别配置。
• 总部统一配置与门店局部管理之间存在明确权限边界。

P3. 支付状态机与一致性保障

价值

• 支付结果正确性是产品上线的最低门槛。
• 可显著降低重复支付、状态未知和回调丢失导致的客诉与资金风险。
• 是交易查询、对账输出和异常处理的共同基础。

需要验证的假设

• 各目标通道的状态可映射为一套内部标准状态。
• 业务系统能够提供稳定且唯一的幂等标识。
• 主动查单和补偿任务可以满足目标业务的最终一致性时效。

P4. 统一交易工作台与异常处置

价值

• 使运营、客服和 IT 能够在一个入口定位并处理支付问题。
• 可以直接验证系统是否减少支付问题的平均处理时长。
• 是试点客户最容易感知的运营价值。

需要验证的假设

• 客户当前支付问题处理确实依赖多个渠道后台和人工沟通。
• 大部分异常可归为有限的标准类型并给出明确动作。
• 不同角色可通过数据权限共享同一交易视图。

P5. 标准支付流水与对账输出

价值

• 打通“支付—对账—分账”的产品组合闭环。
• 避免对账系统重复适配每一种支付接口和支付状态。
• 形成可复用的公司级交易数据标准。

需要验证的假设

• 对账系统需要的是支付交易明细，而非仅依赖渠道结算账单。
• 支付流水具备稳定的业务订单号、渠道流水号、商户和门店归属。
• 支付、退款和撤销数据能够完整关联并支持增量同步。

6. MVP 建议范围

6.1 必须包含

• 客户、品牌、门店、终端基础关系
• 支付商户号和通道参数管理
• 两个可供试点门店使用的收单渠道接入
• 平台渠道目录和客户渠道授权
• 门店支付进件、补件、审核状态和商户号回写
• 统一支付、查询、关闭、退款接口
• 支付订单、支付流水和退款记录
• 幂等、回调去重、主动查单和补偿
• 统一交易查询
• 基础异常监控
• 按门店切换收单渠道、灰度生效和回退
• 标准支付流水输出
• 应用手续费规则、版本和预估手续费输出
• 操作日志和敏感操作权限控制

6.2 暂不纳入

• 智能成本路由或复杂多通道路由
• 多支付通道无人值守自动容灾切换
• 代替支付机构完成资质审批、协议签署和最终开户
• 营销、会员、储值、优惠券
• 财务对账、差异处理
• 清分、分账、结算和出款
• 复杂经营分析报表
• 面向外部开发者的开放平台门户

6.3 MVP 成功指标

建议以一个客户、一个品牌、若干试点门店验证：

• 支付请求技术成功率不低于现有直连方案
• 支付最终状态可确认率达到 100%
• 重复请求不产生重复支付
• 支付异常平均定位时间显著低于现状
• 新业务系统接入支付的开发周期至少缩短 50%
• 输出流水可被对账系统完整接收，关键字段完整率达到 100%

7. 首轮发现需要验证的问题

客户与场景

• 首个试点客户是谁，使用哪些业务入口和支付渠道？
• 是直营网点、加盟门店，还是两者混合？
• 当前支付链路中最频繁、损失最大的三个问题是什么？
• 总部、门店、服务商分别由谁负责支付运营？

商户与资金关系

• 商户号由品牌、门店、加盟商还是收单服务商持有？
• 一个门店是否存在多个商户号？一个商户号是否覆盖多个门店？
• 资金直接进入谁的账户？
• 支付系统是否需要参与商户进件，还是只管理已开通参数？

技术与接口

• 现有 POS、小程序和扫码点餐系统由谁开发和维护？
• 支付以主扫、被扫、小程序、App 或其他哪类方式为主？
• 业务系统是否具备稳定的全局订单号和退款单号？
• 首期必须接入哪些支付机构，是否有测试环境和接口文档？

运营与风险

• 当前如何处理支付中、顾客已扣款但 POS 未成功、重复支付和退款失败？
• 谁拥有退款权限，是否需要申请审批？
• 交易数据和支付密钥的安全、审计及保存要求是什么？
• 试点上线的可接受停机窗口和回退方案是什么？

8. 建议的下一步

1. 选择一个明确的试点客户和 3—5 家代表性门店。
2. 访谈财务、支付运营、门店和 IT，完成现状支付链路图。
3. 盘点现有商户号、通道、业务入口及异常案例。
4. 确认首期支付场景和首个接入通道。
5. 基于真实接口资料设计统一支付协议和内部状态机。
6. 用沙箱或模拟通道验证支付、重复请求、回调丢失、退款等关键链路。