267 lines
12 KiB
Markdown
267 lines
12 KiB
Markdown
# 聚合支付系统产品发现与 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. 用沙箱或模拟通道验证支付、重复请求、回调丢失、退款等关键链路。
|