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