聚合支付系统

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

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

10-产品线/聚合支付/02-竞品分析.md

@@ -0,0 +1,490 @@
+# 聚合支付系统竞品分析
+
+> 研究范围：中国市场，重点关注服务连锁餐饮、连锁零售及平台企业的聚合支付、统一支付接入、商户管理与交易运营能力。  
+> 研究时间：2026 年 6 月。  
+> 说明：竞品公开资料通常不会披露连锁企业客户数、支付交易份额和合同价格。本文区分“公开事实”与“基于公开产品定位的判断”，不以企业累计商户数直接推导聚合支付市场份额。
+
+## 1. 结论摘要
+
+聚合支付已不是一个依靠“聚合微信和支付宝”即可建立优势的市场。主流厂商已沿三条路线发展：
+
+1. **技术聚合路线**：以统一 API、SDK 和开发者工具降低多渠道接入成本，代表为 Ping++。
+2. **持牌支付 PaaS 路线**：将支付、商户进件、账户、分账、结算和对账组合输出，代表为汇付天下、银联商务和富友支付。
+3. **支付与门店经营一体化路线**：以聚合收款为入口，叠加收银硬件、餐饮或零售 SaaS、会员营销与供应链，代表为收钱吧。
+
+对于本公司的聚合支付系统，不建议正面复制持牌机构的收单网络，也不建议建设覆盖商品、会员、营销和供应链的通用门店 SaaS。更合理的竞争方向是：
+
+> 面向已有 POS 和业务系统的中大型连锁企业，提供可控、可解释、可嵌入的支付接入与交易运营中台，并与自有对账、分账产品形成完整闭环。
+
+应重点建立以下差异：
+
+- 连锁集团、品牌、加盟商、门店、终端、商户号的多层级配置模型
+- 可同时连接客户自有商户号、银行通道和持牌支付机构的通道中立能力
+- 支付状态一致性、异常处置和可观测性
+- 标准支付流水直接进入连锁业务对账系统
+- 经对账确认后直接进入分账系统
+- 面向企业现有 POS、ERP、小程序的低侵入集成，而不是强制替换前台系统
+
+## 2. 市场范围与竞争格局
+
+### 2.1 市场定义
+
+本文所称聚合支付，是指不改变最终资金结算责任主体，通过技术系统统一连接多种支付渠道、收单机构和业务入口，并向企业提供支付受理、交易管理、商户配置、账务数据及相关运营服务。
+
+本产品当前目标市场不是面向夫妻店提供一个收款码，而是面向以下客户提供企业级支付中台：
+
+- 多品牌、多区域、多门店的连锁经营企业
+- 同时管理直营网点与加盟门店的品牌总部
+- 已经存在 POS、扫码点餐、小程序、商城等多个交易入口的企业
+- 需要接入多个银行或持牌支付机构的企业
+- 需要将支付流水继续用于对账、分账和经营核算的企业
+
+### 2.2 市场规模与趋势
+
+“聚合支付技术服务”缺少统一、持续的官方市场规模统计，不能与第三方支付交易规模直接画等号。可以用支付基础市场规模判断其业务承载空间：
+
+- 中国人民银行数据显示，2025 年银行处理移动支付业务 2314.64 亿笔、571.97 万亿元；非银行支付机构处理网络支付业务 13254.45 亿笔、337.81 万亿元。[来源](https://www.cncc.cn/ywfw/tjsj/)
+- 艾瑞咨询对更宽口径的“中国第三方综合支付”估算显示，2024 年交易规模约为 580.7 万亿元，其中企业支付约 205.3 万亿元。该口径包含的业务明显大于聚合支付技术服务，不可视为本产品 TAM。[来源](https://pdf.dfcfw.com/pdf/H3_AP202411071640772479_1.pdf?1731012442000.pdf=)
+
+市场已进入成熟期，主要变化不是消费者支付方式从无到有，而是：
+
+- 支付机构和技术服务商从收款工具转向“支付 + 账户 + 分账 + 对账 + SaaS”
+- 大型企业更关注支付系统稳定性、数据主权、多通道路由和资金合规
+- 线下支付继续与 POS、会员、营销、外卖、供应链等门店系统融合
+- 监管提高支付机构和收单外包服务机构的准入、备案、数据安全及风险管理要求
+- 外卡、数字人民币、跨境支付和条码互联互通扩大支付方式复杂度
+- 单纯聚合二维码高度同质化，竞争价值向行业场景、运营效率和数据闭环迁移
+
+### 2.3 关键成功因素
+
+企业级聚合支付的关键成功因素包括：
+
+1. 支付结果正确，重复请求、回调丢失和状态未知不会产生资金差错。
+2. 接口稳定、文档清晰、联调和上线周期短。
+3. 能管理复杂的组织、门店、终端、商户号和支付通道关系。
+4. 能提供交易查询、异常定位、退款控制、审计和监控。
+5. 具备合规的资金链路，不形成无牌“二清”。
+6. 能与企业已有 POS、ERP、财务、对账和分账系统集成。
+7. 服务商具备持续接入新渠道并处理渠道规则变化的能力。
+
+## 3. 竞品集合
+
+### 3.1 五家主要竞品
+
+| 竞品 | 类型 | 市场位置 | 主要优势 | 对本产品的直接威胁 |
+| --- | --- | --- | --- | --- |
+| Ping++ | 聚合支付 API / 金融科技 SaaS | 技术聚合代表 | API、SDK、开发者体验、渠道聚合 | 最接近“统一支付接入中台”的产品形态 |
+| 汇付天下·斗拱 | 持牌支付 PaaS | 企业支付平台型强手 | 支付、进件、账户、分账、结算一体化 | 可向企业和软件服务商直接输出完整支付基础设施 |
+| 银联商务 | 大型持牌收单与行业解决方案商 | 规模与渠道领导者 | 全国服务网络、支付方式、银行和银联生态 | 大客户资质、线下受理和资金服务能力强 |
+| 收钱吧 | 收单外包服务与门店 SaaS | 线下商户服务领导者 | 硬件、服务网络、门店 SaaS、连锁餐饮方案 | 可用支付入口打包替换连锁客户的经营系统 |
+| 富友支付·富掌柜 | 持牌支付与行业 SaaS | 综合型支付服务商 | 支付牌照、行业 SaaS、分账及担保等增值能力 | 可提供支付、经营和资金能力的一体化方案 |
+
+### 3.2 相邻及间接竞争者
+
+- **微信支付、支付宝开放平台**：企业直接接入时可以绕过聚合服务商，但企业需要自己承担多渠道适配、统一状态和运营平台建设。
+- **商业银行聚合收单**：银行可依靠账户和客户关系提供较低费率及资金服务，但跨行、跨机构的通道中立性通常有限。
+- **拉卡拉、通联支付、连连数字等持牌机构**：具备支付、账户或行业方案能力，可能进入同一客户项目。
+- **客如云、美团收银等餐饮 SaaS**：以订单和收银为核心，将支付作为内置能力，可能直接控制交易入口。
+- **客户自研支付中台**：大型连锁企业可能选择自建，以换取数据控制、定制能力和通道议价权。
+
+## 4. 竞品一：Ping++
+
+### 4.1 基本信息与定位
+
+- 运营主体为上海简米网络科技有限公司，成立于 2014 年。
+- 官方定位已从单一支付 SDK 扩展为开放银行与科技金融服务商。
+- 官方披露合作企业超过 4000 家、累计处理订单交易超过 100 亿笔，支持 300 多个主流互联网平台，系统建设能力支持 TPS 不低于 10000。[来源](https://www.pingxx.com/about.html)
+- 主要客户是需要在 App、网站、小程序或平台业务中快速接入支付的互联网企业和产业平台。
+- 产品形态与本公司的“统一支付 API + 交易管理”最接近。
+
+### 4.2 核心优势
+
+- 一套 API 和 SDK 聚合多个支付渠道，开发者价值明确。
+- 具备交易管理、可视化统计、多维报表、多用户权限、交易监控和渠道对账等能力。
+- 公开开发者文档、SDK、帮助中心和系统状态页，降低技术采购的不确定性。
+- 提供试用版、标准版、专业版和定制版，形成标准 SaaS 到项目定制的产品梯度。
+- 已将聚合支付与合规分账、银行账户等产品组合，能够覆盖平台型企业的后续资金需求。
+- 公开披露具有收单外包服务机构备案、等保三级、PCI DSS 和 ISO 等资质。
+
+### 4.3 弱点与空白
+
+以下为基于公开产品信息的判断，需要通过客户访谈或试用进一步验证：
+
+- 产品历史和公开案例更偏线上互联网业务，对复杂连锁门店组织和终端管理的强调弱于其通用支付 API。
+- 客户仍需自行申请相应支付渠道和权限，Ping++ 主要解决技术聚合，不天然解决所有商户进件和线下实施问题。
+- 标准套餐存在应用数、并发数和接口调用量边界，大型连锁客户最终可能进入定制采购。
+- 对支付后端的财务对账、门店差异闭环和连锁经营主体核算不是其公开差异重点。
+
+### 4.4 商业模式与价格
+
+- 采用软件服务订阅、版本套餐和定制服务模式。
+- 官网当前展示版本差异但采用“咨询购买”，注册和试用门槛较低。[来源](https://www.pingxx.com/pricing.html)
+- 公开页面显示套餐按并发、接口调用次数、应用数、功能和服务等级区分。
+- 支付渠道交易费仍由实际支付渠道或收单机构决定，不能将软件费与支付费率混为一体。
+
+### 4.5 竞争威胁
+
+- 已占据“快速统一接入多渠道支付”的清晰心智。
+- 开发者生态、文档和标准 API 会提高客户切换成本。
+- 支付与分账、账户产品组合后，可直接覆盖本公司的支付和分账产品边界。
+- 如果其加强连锁门店模型、线下终端和行业模板，将成为最直接的产品竞争者。
+
+## 5. 竞品二：汇付天下·斗拱
+
+### 5.1 基本信息与定位
+
+- 汇付天下成立于 2006 年，定位为企业收款和资金管理平台服务商。[来源](https://www.huifu.com/)
+- 曾于 2018 年在港交所上市，2021 年完成私有化退市。
+- 斗拱定位为集全栈支付运营与软件开发于一体的综合 PaaS 平台。
+- 目标客户包括企业商户、平台企业、SaaS 服务商和支付服务商。
+
+### 5.2 核心优势
+
+- 同时具备持牌支付能力和开放 PaaS 能力，不只提供技术转接。
+- 支持线下场所、公众号、小程序、PC 网站、App 等多种经营场景。
+- 产品覆盖支付、商户进件、统一账户、自动结算、多方分账、对账和银行连接等层级。[来源](https://paas.huifu.com/open/doc/api_standard/)
+- 向服务商开放商户进件、收款、账户和资金能力，适合软件公司嵌入自己的行业产品。[来源](https://paas.huifu.com/open/doc/guide/)
+- 组件化能力较强，客户可以基于 PaaS 组合业务，而不是只购买固定收银产品。
+- 具备支付机构的合规、资金处理和风控基础设施。
+
+### 5.3 弱点与空白
+
+以下为基于产品模式的判断：
+
+- 产品覆盖面广，接入涉及商户准入、签约、合规材料和资金方案，企业采购及联调复杂度可能高于纯技术 API。
+- 作为持牌支付机构，其商业目标包含支付交易和资金服务，不是完全通道中立。
+- 对只想保留既有商户号、银行关系和前台系统的客户，完整平台方案可能偏重。
+- 连锁品牌的集团—品牌—加盟商—门店经营关系需要通过行业方案配置，不是公开产品的唯一核心模型。
+
+### 5.4 商业模式与价格
+
+- 主要收入可能由支付手续费、账户和资金服务费、增值产品费、PaaS 或定制项目费组成。
+- 官方未公开统一企业报价，通常按行业、交易规模、支付产品和资金方案销售。
+- 获客方式包括直销、行业解决方案中心、SaaS 合作伙伴和支付服务商生态。
+
+### 5.5 竞争威胁
+
+- 可以同时提供支付接入与资金闭环，减少客户采购多个供应商的必要性。
+- 服务商生态允许 POS、ERP 或 SaaS 厂商直接嵌入斗拱，形成渠道规模。
+- 其支付、分账和结算能力会同时威胁本公司的聚合支付与分账产品。
+- 未来如果强化连锁行业数据和对账能力，可能形成从支付到经营资金管理的完整替代方案。
+
+## 6. 竞品三：银联商务
+
+### 6.1 基本信息与定位
+
+- 银联商务成立于 2002 年 12 月，由中国银联控股，是首批获得人民银行支付业务许可的机构之一。
+- 官方披露截至 2025 年 12 月累计服务商户超过 2800 万家、累计铺设终端超过 4400 万台。[来源](https://www.chinaums.com/gywm/)
+- 业务覆盖线下、互联网和移动支付，并向餐饮、零售、文旅等行业提供综合解决方案。
+- 在五家竞品中，支付受理网络、机构信用和大型项目资源最强。
+
+### 6.2 核心优势
+
+- 覆盖银行卡、二维码、云闪付、外卡、数字人民币等多种支付方式。
+- 具备全国服务和终端部署网络，适合大规模线下门店实施。
+- 天满开放平台提供支付 API 和商户交易能力，可与企业系统集成。[来源](https://open.chinaums.com/)
+- “小 U 云店”等产品将综合支付与门店连锁管理、商品、营销和数据分析结合。[来源](https://erp.chinaums.com/cloudStore.html)
+- 餐饮行业方案已覆盖支付、点餐、外卖、会员、进销存、统一对账、分账及供应链资金划付。[来源](https://www.chinaums.com/xiamenums/xwzx/mtbd/202409/t20240926_46866.shtml)
+- 银联和银行生态、线下终端以及公共事业和大型商户项目经验构成较强壁垒。
+
+### 6.3 弱点与空白
+
+以下为基于大型收单机构模式的判断：
+
+- 产品和组织体系庞大，标准化销售、属地机构与项目定制并存，客户体验可能受地区和方案团队影响。
+- 对寻求多家收单机构灵活切换的企业，其通道中立性不如独立支付编排中台。
+- 全套行业方案较重，可能与客户既有 POS、ERP、会员和供应链系统产生边界冲突。
+- 中型连锁客户若只需要轻量 API、统一交易和异常运营，可能面临方案过重或沟通链路较长的问题。
+
+### 6.4 商业模式与价格
+
+- 主要采用支付收单手续费、终端和硬件、SaaS 服务、行业解决方案及项目服务等组合模式。
+- 企业报价未公开，费率和项目价格通常取决于行业、卡种、支付方式、门店规模、设备和服务范围。
+- 获客依靠银联与银行生态、全国分支服务体系、直销和行业合作伙伴。
+
+### 6.5 竞争威胁
+
+- 对注重机构资质、全国交付、外卡和银行卡受理的大型连锁客户具有明显优势。
+- 可以通过银行或银联合作关系进入客户，采购信任成本较低。
+- 其行业解决方案不仅替代支付中台，还可能替代 POS、门店 SaaS、对账和分账系统。
+- 支付互联互通和外卡受理持续推进，会进一步放大其网络优势。
+
+## 7. 竞品四：收钱吧
+
+### 7.1 基本信息与定位
+
+- 收钱吧成立于 2013 年，定位为数字化门店综合服务商。
+- 官方披露其服务网络覆盖中国境内所有城市（含香港），为超过 1000 万实体商家提供服务，全国 50 多个城市设有分公司，服务团队超过 10000 人。[来源](https://www.shouqianba.com/zh/about-us/company-profile)
+- 产品覆盖扫码支付、刷卡、分期、预授权、外卡、支付终端、餐饮和零售 SaaS、营销、外卖及连锁餐饮方案。
+- 2024 年发布面向连锁品牌的“全来店”产品系列，2025 年披露已合作 300 多家连锁餐饮品牌。[来源](https://www.shouqianba.com/zh/about-us/news/2025-chunji-fabuhui)
+
+### 7.2 核心优势
+
+- 从聚合支付起步，线下商户认知强，收款设备和实施服务成熟。
+- 软硬件产品丰富，覆盖码牌、音箱、扫码设备、智能 POS、收银机和云打印机。
+- 能将支付与点单、会员、营销、外卖、发票、供应链等门店经营场景打包销售。
+- 本地服务网络适合解决门店安装、培训、设备更换和售后问题。
+- 对餐饮和零售商户形成“开箱即用”价值，决策链路通常短于企业自建支付中台。
+- 企账通和全来店使其开始进入连锁账务和总部管控场景。
+
+### 7.3 弱点与空白
+
+以下为基于产品定位的判断：
+
+- 核心优势是门店全套产品和线下服务，不一定适合希望保留自有 POS、支付商户号和技术架构的大型企业。
+- 产品矩阵广，支付中台的开放性、通道编排深度和企业级可观测能力不是其公开传播重点。
+- 面向单店和中小商户的标准产品与大型连锁的复杂组织、权限和系统集成需求存在差异。
+- 使用其完整门店生态可能增加客户对硬件、收银系统和运营服务的供应商绑定。
+
+### 7.4 商业模式与价格
+
+- 聚合支付通常与交易服务、硬件、SaaS 年费和增值运营服务组合。
+- 公开传播存在“0 元开通”和低门槛硬件策略；大型连锁产品按门店数和功能需求询价。
+- 获客依靠直营团队、全国服务团队、合作伙伴、支付入口和门店 SaaS 交叉销售。
+
+### 7.5 竞争威胁
+
+- 可利用庞大线下商户基础和服务网络快速进入连锁品牌。
+- 支付、硬件、收银和运营一体化降低客户一次性部署难度。
+- 全来店向总部管控和供应链扩展后，会与公司餐饮数字化产品线产生更广泛竞争。
+- 如果客户愿意整体替换收银和门店系统，本公司的“只做支付中台”价值可能不够突出。
+
+## 8. 竞品五：富友支付·富掌柜
+
+### 8.1 基本信息与定位
+
+- 富友支付成立于 2011 年，是持牌第三方支付机构。
+- 官方披露其具备互联网支付、银行卡收单、多用途预付卡、跨境支付等相关资质，并通过“富掌柜”提供收单和商户数字化服务。
+- 官网披露有超过 60 万家企业合作。[来源](https://www.fuioupay.com/)
+- 主要覆盖中小微商户、大中型商户、连锁企业和细分行业 SaaS 场景。
+
+### 8.2 核心优势
+
+- 兼容主扫、被扫及多类支付方式，具备持牌支付和资金服务能力。
+- 富掌柜提供支付聚合、语音播报、后台查账、电子发票、分期、卡券核销、结算和电子对账等能力。
+- 行业 SaaS 覆盖餐饮、零售、美业、生鲜、茶饮和加油站等场景。
+- 对连锁商户提供多层级经营数据、门店管理、会员、营销和进销存能力。
+- 官网明确提供积分、营销、分账和担保等增值服务，可以向支付后链路延伸。
+- 跨境和多用途预付卡等资质拓宽了复杂支付场景。
+
+### 8.3 弱点与空白
+
+以下为基于公开材料的判断：
+
+- 产品传播偏支付服务和富掌柜行业方案，独立、通道中立的企业支付编排中台心智较弱。
+- 部分公开产品说明和规模数据更新时间较早，企业选型时需要进一步核实当前功能、服务范围和案例。
+- 采用其支付、结算和行业 SaaS 全套方案可能与客户既有系统及收单关系发生冲突。
+- 对集团级支付异常运营、状态一致性和跨机构监控的公开说明不充分。
+
+### 8.4 商业模式与价格
+
+- 主要由支付手续费、商户服务、硬件、行业 SaaS、增值支付和资金服务构成。
+- 官网未公开标准企业价格，预计按支付产品、交易规模、门店和行业方案定价。
+- 通过金融机构合作、分支机构、渠道和行业协会拓展市场。
+
+### 8.5 竞争威胁
+
+- 持牌能力使其可以直接完成支付和结算，而本产品需要依赖合作机构。
+- 支付、分账、担保、预付卡和跨境能力可以覆盖更复杂的企业资金场景。
+- 富掌柜将支付与门店经营结合，对希望单一供应商交付的连锁客户有吸引力。
+- 若其开放 API 和企业级商户模型增强，会与本产品形成正面竞争。
+
+## 9. 横向能力对比
+
+评分含义：5 为公开能力和市场证据很强，3 为具备基础能力或需项目化实现，1 为公开信息较弱。评分是基于公开资料的相对判断，不代表实际生产性能测试结果。
+
+| 能力 | Ping++ | 汇付斗拱 | 银联商务 | 收钱吧 | 富友支付 | 本产品建议目标 |
+| --- | ---: | ---: | ---: | ---: | ---: | ---: |
+| 统一支付 API / SDK | 5 | 5 | 4 | 3 | 3 | 5 |
+| 持牌收单与资金处理 | 2 | 5 | 5 | 2 | 5 | 1 |
+| 多支付方式覆盖 | 5 | 5 | 5 | 4 | 5 | 4 |
+| 商户进件与结算 | 2 | 5 | 5 | 4 | 5 | 2 |
+| 连锁组织与门店管理 | 3 | 3 | 4 | 5 | 4 | 5 |
+| POS 与线下终端生态 | 2 | 4 | 5 | 5 | 5 | 3 |
+| 开发者体验 | 5 | 5 | 4 | 3 | 3 | 5 |
+| 支付状态一致性 | 4 | 5 | 5 | 4 | 4 | 5 |
+| 异常处置与可观测性 | 4 | 4 | 4 | 3 | 3 | 5 |
+| 财务对账闭环 | 3 | 4 | 5 | 4 | 4 | 5 |
+| 多方分账与结算 | 4 | 5 | 5 | 4 | 5 | 5（通过分账系统） |
+| 门店经营 SaaS | 1 | 3 | 5 | 5 | 5 | 1 |
+| 通道中立性 | 5 | 2 | 2 | 2 | 2 | 5 |
+| 私有化与深度定制 | 4 | 4 | 4 | 3 | 4 | 5 |
+
+## 10. 可利用的市场空白
+
+### 10.1 “已有系统不替换”的中大型连锁
+
+多数综合竞品倾向销售支付、收银硬件和门店 SaaS 全套方案。已有成熟 POS、ERP、会员和小程序的连锁企业并不希望整体替换，只需要统一支付接口、商户号管理、异常运营和标准流水。
+
+机会：
+
+- 提供独立支付中台，不介入商品、点单和会员
+- 支持渐进式接入，按品牌、区域或门店灰度迁移
+- 兼容原有商户号和收单关系
+
+### 10.2 多收单机构的通道中立管理
+
+持牌机构通常优先使用自身支付和资金能力，银行方案也倾向本行渠道。大型连锁企业希望保留多家银行和支付机构，以获得成本议价、风险分散和业务连续性。
+
+机会：
+
+- 通道适配器标准
+- 按门店、支付方式和收单机构配置路由
+- 通道健康度监控和人工切换
+- 独立比较成功率、耗时、错误码和成本
+
+### 10.3 支付异常的可解释运营
+
+市场大量产品可以“发起支付”，但总部运营人员更需要回答：
+
+- 顾客是否实际扣款？
+- POS 为什么没有收到成功结果？
+- 哪个环节丢失了回调？
+- 是否需要重新查单或关闭订单？
+- 退款失败应由门店、总部还是渠道处理？
+
+机会：
+
+- 标准状态机和完整事件时间线
+- 渠道错误码翻译与处理建议
+- 自动查单、补偿和异常任务
+- 门店、客服、运营和技术的分角色视图
+
+### 10.4 支付—对账—分账的一体化但边界清晰
+
+竞品常把支付、对账和分账包装在同一平台，但产品边界和数据可信链路未必清晰。本公司已有独立对账和分账产品规划，可形成：
+
+> 支付生成标准流水 → 对账确认渠道实收 → 分账执行资金分配
+
+机会：
+
+- 支付系统不自行替代财务核销
+- 对账系统形成可分账可信结果
+- 分账系统只消费已确认数据
+- 三个系统使用统一订单、流水、主体和状态标准
+
+### 10.5 行业模板而非行业大套件
+
+企业客户需要行业适配，但不一定需要重新购买完整行业 SaaS。
+
+机会：
+
+- 连锁餐饮的营业日、门店终端、加盟商和退款权限模板
+- 连锁零售的多终端、交接班和大促高并发模板
+- 连锁药店的医保与普通支付区分模板
+- 平台业务的子商户、担保和分账衔接模板
+
+## 11. 推荐竞争定位
+
+### 11.1 定位陈述
+
+> 面向已有业务系统的连锁经营企业，提供通道中立的聚合支付中台，统一管理集团到门店的支付配置、交易状态和异常处置，并无缝连接对账与分账系统。
+
+### 11.2 需要强调的差异点
+
+1. **不是收款码工具**：面向多品牌、多门店、多商户号的企业级支付治理。
+2. **不绑定单一收单机构**：兼容客户现有银行、微信支付宝直连和持牌支付机构。
+3. **不强制替换 POS**：通过标准 API、SDK 和适配器嵌入已有业务系统。
+4. **支付结果可解释**：提供状态机、事件时间线、异常任务和自动补偿。
+5. **天然连接财务闭环**：标准支付流水直接进入对账，对账结果直接进入分账。
+6. **支持客户可控部署**：根据客户等级提供 SaaS、专属实例或私有化部署。
+
+### 11.3 优先目标客户
+
+- 50 家以上门店、已有 POS 或业务中台的连锁餐饮品牌
+- 同时存在直营和加盟门店、商户号归属复杂的品牌
+- 已经使用两家及以上收单机构或银行通道的企业
+- 正在建设统一对账、分账或资金管理平台的客户
+- 对支付数据、系统可控性和故障处置有明确要求的中大型客户
+
+### 11.4 暂时避免的市场
+
+- 只需要低费率收款码的单店和微型商户
+- 强依赖全国硬件铺设、上门安装且软件价值较低的项目
+- 要求本公司直接提供收单和资金结算但不接受合作持牌机构的客户
+- 首期即要求覆盖完整 POS、会员、营销、外卖和供应链的客户
+- 仅凭支付费率决定采购、没有软件服务付费意愿的客户
+
+## 12. 未来 12—18 个月的竞争风险与应对
+
+| 风险 | 可能性 | 影响 | 应对 |
+| --- | --- | --- | --- |
+| 持牌机构继续开放 PaaS，统一 API 成为基础能力 | 高 | 高 | 将优势放在连锁模型、异常运营和三系统闭环 |
+| 收钱吧等门店 SaaS 向大型连锁总部管控扩展 | 高 | 中高 | 坚持兼容既有 POS，联合而非替换行业 SaaS |
+| 银行以低费率打包聚合收单 | 高 | 中 | 提供跨银行管理、路由和数据中立价值 |
+| 客户选择自研支付中台 | 中高 | 高 | 提供私有化、源码级扩展或联合建设模式 |
+| 监管加强收单外包、数据和反洗钱要求 | 高 | 高 | 明确技术服务边界，完成备案与安全体系建设 |
+| 支付互联互通降低“聚合渠道”价值 | 中 | 中 | 从支付方式聚合升级为企业支付运营和财务数据治理 |
+| 竞品通过支付费率补贴软件 | 中高 | 中高 | 避免单独销售支付，绑定对账、分账和行业方案价值 |
+
+## 13. 产品与市场行动建议
+
+### 13.1 产品验证
+
+1. 选取 3 家已有 POS 且门店超过 50 家的连锁客户，验证是否愿意为独立支付中台付费。
+2. 盘点每家客户的商户号、收单机构和门店关系，检验多层级模型能否覆盖 80% 以上场景。
+3. 用真实异常案例验证交易时间线、主动查单和补偿任务的价值。
+4. 将同一批支付流水送入对账系统，验证支付—对账数据标准。
+5. 与一家银行和一家持牌支付机构完成技术及商务合作验证。
+
+### 13.2 竞品实测
+
+建议申请或演示以下产品，不只依赖官网资料：
+
+- Ping++ 试用版：评估 API、状态模型、交易工作台和报表
+- 汇付斗拱：评估服务商进件、统一账户、分账和接口复杂度
+- 银联商务天满：评估线下支付接口、商户号和终端模型
+- 收钱吧全来店：评估连锁总部管控、支付与 POS 绑定程度
+- 富友富掌柜：评估连锁商户、电子对账及增值资金能力
+
+### 13.3 销售话术验证
+
+应测试客户是否认可以下价值主张：
+
+- “保留现有 POS 和收单关系，只统一支付接入与运营”
+- “总部统一管理门店、终端和商户号”
+- “支付异常从跨多个后台排查，变为一条交易时间线”
+- “支付流水不再二次加工，直接用于对账和分账”
+- “新增支付通道时，业务系统无需重复改造”
+
+## 14. 资料来源
+
+### 市场与监管
+
+- [中国人民银行清算总中心：支付体系运行统计数据](https://www.cncc.cn/ywfw/tjsj/)
+- [中国人民银行：2024 年支付体系运行总体情况](https://www.pbc.gov.cn/zhifujiesuansi/128525/128545/128643/5589365/index.html)
+- [2024 年中国第三方支付行业研究报告](https://pdf.dfcfw.com/pdf/H3_AP202411071640772479_1.pdf?1731012442000.pdf=)
+- [非银支付监管条例落地，收单外包市场持续洗牌](https://jrj.wuhan.gov.cn/ztzl_57/xyrd/yxy/202312/t20231227_2330527.shtml)
+
+### Ping++
+
+- [Ping++ 公司介绍](https://www.pingxx.com/about.html)
+- [Ping++ 聚合支付与定价方案](https://www.pingxx.com/pricing.html)
+- [Ping++ 开发者中心](https://www.pingxx.com/docs/overview/)
+
+### 汇付天下
+
+- [汇付天下官网](https://www.huifu.com/)
+- [斗拱平台](https://paas.huifu.com/)
+- [斗拱文档中心](https://paas.huifu.com/open/home/)
+- [斗拱服务商进件指引](https://paas.huifu.com/open/doc/guide/)
+
+### 银联商务
+
+- [银联商务公司简介](https://www.chinaums.com/gywm/)
+- [银联商务天满开放平台](https://open.chinaums.com/)
+- [银联商务小 U 云店](https://erp.chinaums.com/cloudStore.html)
+- [天天富餐饮·臻享行业方案](https://www.chinaums.com/xiamenums/xwzx/mtbd/202409/t20240926_46866.shtml)
+
+### 收钱吧
+
+- [收钱吧公司简介与发展历程](https://www.shouqianba.com/zh/about-us/company-profile)
+- [收钱吧 2025 春季产品发布](https://www.shouqianba.com/zh/about-us/news/2025-chunji-fabuhui)
+- [收钱吧官网](https://www.shouqianba.com/)
+
+### 富友支付
+
+- [富友支付官网](https://www.fuioupay.com/)
+- [富友支付业务与资质介绍](https://www.fuioupay.com/news/2021-09-24.html)
+- [富掌柜连锁商户能力介绍](https://www.fuioupay.com/news/2018-11-27.html)
+

10-产品线/聚合支付/README.md

@@ -3,3 +3,9 @@
 本目录用于沉淀聚合支付系统规划。
 
 2026 年重点目标是基于基础平台和技术架构调整，完成聚合支付系统 1.0 版本建设。
+
+## 规划文档
+
+- [产品发现与 MVP 方向](./01-产品发现与MVP方向.md)
+- [竞品分析](./02-竞品分析.md)
+- [PRD：适用于连锁企业的聚合支付平台](./PRD-适用于连锁企业的聚合支付平台.md)