diff --git a/10-产品线/聚合支付/01-产品发现与MVP方向.md b/10-产品线/聚合支付/01-产品发现与MVP方向.md
new file mode 100644
index 0000000..cc62490
--- /dev/null
+++ b/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. 用沙箱或模拟通道验证支付、重复请求、回调丢失、退款等关键链路。
diff --git a/10-产品线/聚合支付/02-竞品分析.md b/10-产品线/聚合支付/02-竞品分析.md
new file mode 100644
index 0000000..6f737d6
--- /dev/null
+++ b/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)
+
diff --git a/10-产品线/聚合支付/PRD-适用于连锁企业的聚合支付平台.md b/10-产品线/聚合支付/PRD-适用于连锁企业的聚合支付平台.md
new file mode 100644
index 0000000..cbae757
--- /dev/null
+++ b/10-产品线/聚合支付/PRD-适用于连锁企业的聚合支付平台.md
@@ -0,0 +1,1525 @@
+# PRD：适用于连锁企业的聚合支付平台
+
+> 文档状态：初稿  
+> 目标版本：1.0  
+> 产品形态：企业级聚合支付平台  
+> 首期行业：连锁餐饮，可扩展至连锁零售、鞋服和药店  
+> 依赖产品：基础平台、连锁业务对账系统  
+
+## 变更记录
+
+| 版本 | 变更内容 |
+| --- | --- |
+| 0.1 | 形成聚合支付平台 1.0 初稿 |
+| 0.2 | 将门店支付进件、双收单渠道接入和渠道切换纳入 1.0 |
+| 0.3 | 明确平台统一管理收单渠道、按客户授权渠道，并增加客户应用手续费配置 |
+
+## 1. 摘要
+
+本产品面向已有 POS、扫码点餐、小程序等业务系统的连锁企业，提供统一支付接口、支付通道配置、交易状态管理、退款管理和异常处置能力。
+
+平台不直接保管客户资金，不替代持牌支付机构，也不替代 POS、对账系统和分账系统。平台负责可靠地完成支付受理，并输出完整、统一、可追溯的支付流水。
+
+一句话定位：
+
+> 面向连锁企业，连接业务系统与多个支付通道的支付接入和交易运营中台。
+
+## 2. 联系人
+
+实际姓名由项目启动会补充。角色和责任如下。
+
+| 角色 | 姓名 | 主要责任 | 评审内容 |
+| --- | --- | --- | --- |
+| 产品负责人 | 待定 | 产品目标、范围、优先级和验收 | PRD、版本范围、验收结果 |
+| 业务负责人 | 待定 | 客户业务规则和试点协调 | 门店场景、商户关系、退款规则 |
+| 技术负责人 | 待定 | 技术方案、系统稳定性和安全 | 架构、接口、一致性、性能 |
+| 研发负责人 | 待定 | 研发计划和交付质量 | 工作量、依赖、交付风险 |
+| 测试负责人 | 待定 | 测试方案和质量验收 | 核心链路、异常链路、回归测试 |
+| 运维负责人 | 待定 | 上线、监控、故障处理和回退 | 监控、告警、应急预案 |
+| 安全与合规负责人 | 待定 | 支付安全、数据安全和合规边界 | 密钥、日志、敏感信息、合作资质 |
+| 实施负责人 | 待定 | 客户初始化、联调和门店上线 | 配置模板、上线清单、培训 |
+| 试点客户负责人 | 待定 | 客户决策、资源协调和验收确认 | 试点范围、业务验收、问题闭环 |
+| 支付机构联系人 | 待定 | 通道申请、接口支持和异常协同 | 商户号、接口、账单、结算状态 |
+
+## 3. 背景
+
+### 3.1 当前情况
+
+连锁企业通常同时存在多个支付入口：
+
+- 门店 POS
+- 扫码点餐
+- 微信或支付宝小程序
+- 品牌 App
+- 私域商城
+- 自助点餐机
+- 第三方业务系统
+
+企业还可能同时使用多个支付通道：
+
+- 微信支付直连
+- 支付宝直连
+- 银联或银行聚合支付
+- 持牌支付机构
+- 行业支付服务商
+
+如果每个业务系统分别接入每个支付通道，会出现以下问题：
+
+1. 同一个渠道被重复开发和维护。
+2. 不同系统使用不同的支付状态和错误码。
+3. 集团无法统一管理门店、终端、商户号和支付参数。
+4. 顾客已扣款但 POS 未收到成功结果时，门店难以判断实际状态。
+5. 回调丢失、网络超时和重复请求可能造成状态不一致。
+6. 客服和运营需要登录多个渠道后台查询交易。
+7. 支付流水格式不统一，对账系统需要重复清洗和适配。
+8. 新增支付渠道时，需要同时改造多个业务系统。
+9. 新门店需要分别向支付机构提交资料，进件过程缺少统一跟踪。
+10. 收单渠道发生故障、费率变化或合作调整时，门店切换渠道依赖人工改配置，风险较高。
+11. 平台已经开发支持的收单渠道缺少统一目录，容易在客户项目中重复配置或重复判断支持范围。
+12. 不同客户和应用的收单手续费约定不同，缺少统一、生效时间明确且可追溯的手续费规则。
+
+### 3.2 为什么现在建设
+
+公司正在形成“支付—对账—分账”的产品组合：
+
+- 聚合支付平台负责支付受理和支付流水。
+- 连锁业务对账系统负责订单与渠道结算核销。
+- 分账系统负责多主体资金分配和结算。
+
+基础平台已规划客户、组织、用户、角色、权限、门户、配置和操作日志能力。聚合支付平台可以复用这些能力，把建设重点放在支付业务本身。
+
+市场竞品已能提供多渠道支付，但仍有以下机会：
+
+- 中大型连锁企业不希望替换已有 POS 和业务系统。
+- 企业希望保留已有银行和收单机构关系。
+- 企业需要跨支付机构的统一交易运营视图。
+- 连锁企业的品牌、加盟商、门店、终端和商户号关系较复杂。
+- 支付异常的解释、定位和处置仍然依赖人工经验。
+- 支付流水需要直接支持后续对账和分账，而不只是生成收款记录。
+
+### 3.3 产品原则
+
+1. **资金合规**：平台只提供技术服务，不沉淀、不挪用、不代为清算客户资金。
+2. **支付正确**：资金状态正确高于页面体验和功能数量。
+3. **通道中立**：允许客户使用多家银行、微信支付宝直连或持牌支付机构。
+4. **不替换业务系统**：通过标准接口接入已有 POS、小程序和业务中台。
+5. **连锁模型优先**：所有交易必须可以明确归属客户、品牌、门店和终端。
+6. **异常可解释**：支付过程要可查询、可追踪、可处理。
+7. **边界清晰**：支付、对账和分账分别承担独立职责。
+8. **先试点再扩展**：首版接入两个可切换的收单渠道和有限支付场景，用小范围门店验证。
+9. **进件不代替审核**：平台统一收集和提交资料，但最终审核、签约和商户号开通由持牌支付机构完成。
+10. **切换不重试未知交易**：渠道切换只影响新交易；已有交易仍由原渠道完成查询、退款和对账。
+11. **平台统一维护渠道**：渠道适配器和公共能力由平台统一开发、测试、发布和停用，客户不能自行创建平台级收单渠道。
+12. **先授权再使用**：平台支持某个收单渠道，不代表所有客户自动可用；客户只有获得授权后才能进件、配置商户号和参与路由。
+13. **费率版本化**：应用手续费按生效时间形成版本，交易发生时固化命中的规则和预估手续费，不使用新规则覆盖历史结果。
+
+### 3.4 产品边界
+
+#### 3.4.1 本产品负责
+
+- 支付应用接入和接口凭证管理
+- 平台级收单渠道目录、渠道适配器和能力版本管理
+- 按客户授权或取消授权收单渠道
+- 门店支付进件申请、资料管理和进度跟踪
+- 支付商户号及参数管理
+- 品牌、门店、终端与商户号的支付关系
+- 统一支付、查询、关闭和退款接口
+- 支付路由
+- 收单渠道切换、灰度生效和回退
+- 支付订单和支付流水
+- 退款单和退款流水
+- 回调接收、通知下游和通知重试
+- 主动查单和自动补偿
+- 支付状态统一
+- 交易查询和异常处置
+- 支付监控和告警
+- 客户应用收单手续费规则和预估手续费计算
+- 向对账系统输出标准支付流水
+
+#### 3.4.2 本产品不负责
+
+- 商品、购物车、销售订单和履约管理
+- 会员、储值、积分、优惠券和营销
+- 支付机构的资金清算和商户结算
+- 代替支付机构完成商户资质审核、协议签署和最终开户审批
+- 无牌资金归集或“二清”
+- 渠道结算账单与业务订单的财务核销
+- 对账差异处理
+- 多主体清分、分润、结算和出款
+- 门店利润和加盟商利润核算
+- 完整 POS 或门店经营 SaaS
+
+### 3.5 系统关系
+
+```mermaid
+flowchart LR
+    A["POS / 小程序 / 业务系统"] -->|"统一支付请求"| B["聚合支付平台"]
+    B -->|"通道路由与请求转换"| C["银行 / 微信支付宝 / 持牌支付机构"]
+    C -->|"支付结果与异步通知"| B
+    B -->|"统一支付结果"| A
+    B -->|"标准支付流水"| D["连锁业务对账系统"]
+    D -->|"已确认可分账数据"| E["分账系统"]
+    F["基础平台"] -->|"客户、组织、用户、权限、门户、日志"| B
+```
+
+## 4. 目标
+
+### 4.1 产品目标
+
+建设一个适用于连锁企业的统一支付平台，使业务系统只接入一次，就能使用一个或多个支付通道；使总部可以统一管理支付配置、交易状态和异常；使支付数据可以直接进入对账系统。
+
+### 4.2 客户收益
+
+- 减少各业务系统重复接入支付渠道的开发工作。
+- 缩短新增门店、终端和支付通道的上线时间。
+- 统一提交门店进件资料并跟踪各渠道审核结果。
+- 在不改造 POS 的情况下按门店切换收单渠道。
+- 降低重复支付、状态未知和回调丢失造成的风险。
+- 缩短门店、客服和运营查询支付问题的时间。
+- 统一支付流水，降低财务对账的数据处理成本。
+- 保留客户已有 POS、商户号和收单机构关系。
+
+### 4.3 公司收益
+
+- 补齐公司“支付—对账—分账”产品闭环。
+- 形成可复用的支付接入和交易数据标准。
+- 提高连锁客户整体方案的竞争力和客户粘性。
+- 为后续平台型业务、担保交易和行业支付模板建立基础。
+- 降低不同客户项目重复开发支付接口的成本。
+
+### 4.4 战略一致性
+
+本产品符合公司的以下规划原则：
+
+- 面向连锁企业沉淀行业通用能力。
+- 对账、分账、支付、账户和权限能力边界清晰。
+- 基于基础平台实现多客户、多组织和多产品复用。
+- 从客户项目中沉淀标准产品能力。
+- 先支持连锁餐饮，再扩展到零售、鞋服和药店。
+
+### 4.5 目标和关键结果
+
+目标周期从首个试点版本上线开始计算。
+
+#### O1：证明统一支付链路可以稳定承载试点门店交易
+
+| 关键结果 | 目标值 | 统计口径 |
+| --- | ---: | --- |
+| 支付平台自身可用性 | 不低于 99.95% | 不含外部通道故障和计划维护 |
+| 平台技术处理成功率 | 不低于 99.99% | 合法请求被平台正确受理的比例 |
+| 支付最终状态可确认率 | 100% | 成功、失败或关闭均有最终结果 |
+| 幂等正确率 | 100% | 相同幂等请求不产生重复支付单 |
+| 支付金额差错 | 0 笔 | 平台原因导致金额或币种错误 |
+| 严重资金事故 | 0 起 | 重复扣款、错误退款等严重事故 |
+
+#### O2：证明平台能降低接入和运营成本
+
+| 关键结果 | 目标值 | 统计口径 |
+| --- | ---: | --- |
+| 新业务系统接入周期 | 比现有方式缩短至少 50% | 从获取资料到联调通过 |
+| 新门店支付配置时间 | 单店不超过 30 分钟 | 基础资料完整的标准场景 |
+| 标准门店进件资料复用率 | 不低于 80% | 多渠道共同字段无需重复录入 |
+| 进件状态可追踪率 | 100% | 每个申请可查看当前状态、退回原因和处理记录 |
+| 已完成进件门店渠道切换时间 | 不超过 10 分钟 | 不含支付机构侧开户时间 |
+| 渠道切换后新交易路由正确率 | 100% | 按生效范围和时间进入目标渠道 |
+| 常见支付异常定位时间 | 比现状缩短至少 50% | 从收到问题到明确状态或责任环节 |
+| 试点期间跨渠道后台查询比例 | 下降至少 70% | 可在平台内完成查询的问题 |
+
+#### O3：证明支付数据可以直接支持对账
+
+| 关键结果 | 目标值 | 统计口径 |
+| --- | ---: | --- |
+| 标准支付流水关键字段完整率 | 100% | 订单、金额、门店、商户、渠道、状态等 |
+| 支付与退款关联成功率 | 100% | 有效退款均可关联原支付 |
+| 对账系统接收成功率 | 不低于 99.99% | 自动重试后仍失败视为失败 |
+| 试点交易可追溯率 | 100% | 能追溯业务单、支付单和渠道单 |
+
+### 4.6 非目标
+
+首版不以以下结果作为成功标准：
+
+- 成为支付机构或直接获得支付牌照。
+- 通过支付费率竞争获取大量小微商户。
+- 替换客户现有 POS、会员或供应链系统。
+- 一次性支持所有支付机构和全部支付方式。
+- 在首版实现智能成本路由和无人值守自动通道容灾。
+- 在聚合支付平台内完成财务对账和资金分账。
+
+## 5. 市场细分
+
+市场按客户需要完成的工作划分，不只按企业规模划分。
+
+### 5.1 首要市场：已有业务系统的中大型连锁企业
+
+#### 需要完成的工作
+
+> 当企业有多个品牌、门店、终端和支付通道时，希望业务系统只接入一次，并由总部统一管理支付配置和交易状态。
+
+#### 典型特征
+
+- 已有 50 家以上门店，或门店数量增长较快。
+- 已有 POS、小程序、扫码点餐或业务中台。
+- 同时存在直营网点和加盟门店。
+- 使用两个及以上支付渠道、商户号体系或收单机构。
+- 需要集团、品牌、区域和门店分级管理。
+- 对系统稳定、数据安全和审计有明确要求。
+
+#### 首期优先行业
+
+- 连锁餐饮
+
+#### 后续可扩展行业
+
+- 连锁零售
+- 连锁鞋服
+- 连锁药店
+- 其他多门店服务业
+
+### 5.2 次要市场：为连锁企业提供软件的服务商
+
+#### 需要完成的工作
+
+> 当 POS、ERP 或行业 SaaS 服务商需要为多个客户提供支付能力时，希望使用统一接口，避免逐个接入支付机构。
+
+#### 约束
+
+- 需要清晰的客户隔离和应用隔离。
+- 需要更完善的开放接口、沙箱、文档和版本兼容策略。
+- 可能要求白标、专属实例或私有化部署。
+- 商务模式和支付机构合作关系更复杂。
+
+此市场不作为 1.0 首要目标，但技术设计不能阻断后续扩展。
+
+### 5.3 后续市场：平台型交易企业
+
+#### 需要完成的工作
+
+> 当平台连接多个交易参与方时，希望统一完成支付，并在履约确认后进入对账和分账。
+
+#### 约束
+
+- 涉及子商户、担保交易、退款责任和分账。
+- 合规和资金边界更复杂。
+- 需要与分账系统深度协同。
+
+此市场进入后续版本，1.0 不建设担保交易。
+
+### 5.4 核心用户角色
+
+| 用户角色 | 主要工作 | 数据范围 |
+| --- | --- | --- |
+| 客户管理员 | 开通应用、分配角色和数据权限 | 本客户全部组织 |
+| 平台渠道管理员 | 管理平台支持的收单渠道、适配器版本和客户授权 | 全平台收单渠道 |
+| 支付管理员 | 管理支付应用、已授权渠道、商户号、手续费和路由 | 本客户全部支付配置 |
+| 总部支付运营 | 查看交易和通道状态，处理异常 | 授权品牌或全部门店 |
+| 集团财务 | 查询支付、退款和汇总数据 | 授权品牌、主体和门店 |
+| 客服人员 | 按订单、手机号后四位等条件协助查询 | 授权门店和脱敏数据 |
+| 门店店长 | 查询本店交易，提交退款或查看退款结果 | 本门店 |
+| 门店收银员 | 通过 POS 发起支付、查询和退款 | 本终端或本门店 |
+| IT 人员 | 创建应用、获取凭证、联调和排查接口 | 授权应用 |
+| 实施人员 | 初始化门店、商户号和通道配置 | 被授权客户 |
+| 平台运维 | 监控平台和通道，不查看非必要敏感信息 | 平台运维范围 |
+
+### 5.5 首版约束
+
+- 首版至少有一个明确试点客户。
+- 首版至少接入两个可用于试点门店的收单渠道。
+- 首版优先支持人民币境内支付。
+- 首版优先支持被扫支付和小程序支付中的一种或两种，最终以试点为准。
+- 客户可以录入已有商户号，也可以通过平台向合作支付机构提交门店进件申请。
+- 客户只能使用平台已开发且已明确授权给本客户的收单渠道。
+- 业务系统必须提供稳定的业务订单号和退款单号。
+- 网络、终端和外部支付通道不完全由本平台控制。
+- 退款权限和审批规则必须由试点客户确认。
+
+## 6. 价值主张
+
+### 6.1 总部支付运营
+
+#### 需要完成的工作
+
+统一管理多品牌、多门店、多终端和多个支付通道，并快速处理支付异常。
+
+#### 获得的价值
+
+- 在一个平台查看全部授权交易。
+- 统一维护商户号和通道参数。
+- 清楚看到支付请求、渠道响应、异步通知和下游通知过程。
+- 通过异常任务处理状态未知、通知失败和退款异常。
+- 比较不同通道的成功率和响应时间。
+
+#### 避免的痛点
+
+- 频繁登录多个渠道后台。
+- 依赖研发查日志。
+- 不清楚顾客是否实际扣款。
+- 门店和总部口径不一致。
+
+### 6.2 门店店员和店长
+
+#### 需要完成的工作
+
+快速收款，并在支付结果不明确时给顾客一个可靠答复。
+
+#### 获得的价值
+
+- POS 使用统一支付接口，不感知后端通道差异。
+- 可以查询本店交易的最终状态。
+- 可以看到简单、明确的失败原因和处理建议。
+- 可以按权限发起退款或退款申请。
+
+#### 避免的痛点
+
+- 顾客已扣款却要求再次支付。
+- 退款结果长时间不明确。
+- 支付问题只能电话联系总部或技术人员。
+
+### 6.3 IT 和业务系统开发人员
+
+#### 需要完成的工作
+
+用一套接口接入支付，并保证接口升级和多通道变化不会反复改造业务系统。
+
+#### 获得的价值
+
+- 统一的支付、查询、关闭和退款接口。
+- 统一的状态、错误码和签名规则。
+- 沙箱、示例、接口日志和联调工具。
+- 新增通道时尽量不修改业务系统。
+- 请求和回调可追踪。
+
+#### 避免的痛点
+
+- 每个渠道重复开发。
+- 渠道接口升级导致多个系统同时改造。
+- 回调问题难复现。
+- 不同系统使用不同支付状态。
+
+### 6.4 财务和对账人员
+
+#### 需要完成的工作
+
+获得完整、可信、可关联的支付与退款流水，用于后续对账。
+
+#### 获得的价值
+
+- 统一支付字段和状态。
+- 支付、退款、关闭和撤销关系清晰。
+- 每笔交易可关联业务订单、门店、商户号和渠道流水。
+- 数据自动输出到对账系统。
+
+#### 避免的痛点
+
+- 多系统流水格式不一致。
+- 缺少渠道流水号或门店归属。
+- 退款与原支付无法关联。
+- 支付状态变化后数据未同步。
+
+### 6.5 相对竞品的差异
+
+| 比较维度 | 常见收款工具 | 持牌支付 PaaS | 门店 SaaS 套件 | 本产品 |
+| --- | --- | --- | --- | --- |
+| 主要客户 | 单店、小微商户 | 平台企业、商户服务商 | 需要完整门店系统的商户 | 已有业务系统的连锁企业 |
+| 是否替换 POS | 可能需要设备 | 通常不强制 | 常与自有 POS 绑定 | 不替换 |
+| 通道中立 | 较弱 | 较弱 | 较弱 | 强 |
+| 连锁组织模型 | 基础 | 需项目配置 | 较强 | 核心能力 |
+| 异常可解释 | 基础查询 | 技术能力较强 | 偏门店操作 | 总部运营核心能力 |
+| 对账衔接 | 导出或基础对账 | 平台内组合 | 套件内组合 | 直接连接独立对账系统 |
+| 分账衔接 | 通常无 | 自有资金产品 | 部分支持 | 连接独立分账系统 |
+| 私有化和深度集成 | 较弱 | 视项目而定 | 较弱 | 目标能力 |
+
+## 7. 解决方案
+
+### 7.1 用户体验与流程
+
+#### 7.1.1 信息架构
+
+聚合支付平台 1.0 建议包含以下一级菜单：
+
+1. 支付概览
+2. 交易中心
+3. 退款中心
+4. 异常中心
+5. 支付配置
+6. 接入管理
+7. 监控中心
+8. 数据输出
+
+基础平台继续提供：
+
+- 客户管理
+- 组织管理
+- 用户与账号
+- 角色和权限
+- 统一门户
+- 通用操作日志
+- 消息与待办
+
+#### 7.1.2 新客户开通流程
+
+```mermaid
+flowchart TD
+    A["基础平台创建客户并开通聚合支付应用"] --> B["初始化品牌、区域和门店"]
+    B --> C["平台向客户授权两个已支持的收单渠道"]
+    C --> D["创建支付应用并设置手续费"]
+    D --> E["提交门店支付进件"]
+    E --> F["支付机构审核并返回商户号"]
+    F --> G["绑定品牌、门店、终端和商户号"]
+    G --> H["配置主渠道、备用渠道和切换规则"]
+    H --> I["执行配置检查"]
+    I --> J{"检查是否通过"}
+    J -->|"否"| K["修正进件资料或支付配置"]
+    K --> I
+    J -->|"是"| L["双渠道小额实付和切换测试"]
+    L --> M["试点门店启用"]
+```
+
+#### 7.1.3 支付主流程
+
+```mermaid
+sequenceDiagram
+    participant POS as POS/业务系统
+    participant PAY as 聚合支付平台
+    participant CH as 支付通道
+
+    POS->>PAY: 发起支付（业务订单号、金额、门店、终端）
+    PAY->>PAY: 验证身份、参数、幂等和路由
+    PAY->>CH: 转换并发送渠道支付请求
+    CH-->>PAY: 返回受理结果
+    PAY-->>POS: 返回统一受理结果
+    CH-->>PAY: 异步通知最终结果
+    PAY->>PAY: 验签、去重、更新状态
+    PAY-->>POS: 通知统一支付结果
+    PAY->>PAY: 通知失败时自动重试
+    PAY->>PAY: 状态长期未明确时主动查单
+```
+
+#### 7.1.4 支付状态未知处理流程
+
+1. 平台请求支付通道后发生网络超时。
+2. 平台不得直接把订单标记为支付失败。
+3. 支付单进入“支付处理中”。
+4. 平台按规则主动查询通道。
+5. 查询为成功时，更新为支付成功并通知业务系统。
+6. 查询为失败或已关闭时，更新为对应最终状态。
+7. 多次查询仍无结果时，生成异常任务并告警。
+8. 运营人员可以查看完整事件时间线并再次查单。
+9. 未获得可靠最终结果前，不允许同一业务单重新生成新的有效支付单，除非业务规则明确允许。
+
+#### 7.1.5 退款流程
+
+```mermaid
+flowchart TD
+    A["业务系统或授权用户发起退款"] --> B["校验退款单号幂等"]
+    B --> C["校验原支付、可退金额和权限"]
+    C --> D{"是否需要审批"}
+    D -->|"是"| E["生成退款申请"]
+    E --> F["授权人员审批"]
+    F -->|"拒绝"| G["退款申请关闭"]
+    F -->|"通过"| H["发送渠道退款请求"]
+    D -->|"否"| H
+    H --> I["生成退款流水"]
+    I --> J{"渠道结果"}
+    J -->|"成功"| K["更新退款成功并通知"]
+    J -->|"处理中"| L["主动查询退款结果"]
+    J -->|"失败"| M["记录原因并生成异常"]
+    L --> K
+    L --> M
+```
+
+#### 7.1.6 异常处理流程
+
+1. 系统识别异常并生成异常任务。
+2. 异常任务自动带入交易、通道和事件记录。
+3. 系统给出异常类型、影响范围和建议动作。
+4. 运营人员领取或被分配任务。
+5. 运营人员执行查单、重发通知、确认配置或联系渠道等动作。
+6. 系统记录每次操作和结果。
+7. 问题消除后，任务自动或人工关闭。
+8. 关闭时必须填写处理结果；人工改状态必须有高权限和完整审计。
+
+#### 7.1.7 交易详情页面草图
+
+```text
++--------------------------------------------------------------+
+| 支付单号          业务订单号          当前状态：支付成功       |
++--------------------------------------------------------------+
+| 金额 | 品牌 | 门店 | 终端 | 支付方式 | 通道 | 商户号（脱敏）   |
++--------------------------------------------------------------+
+| 事件时间线                                                   |
+| 10:00:01 收到业务请求                                        |
+| 10:00:01 选择通道和商户号                                    |
+| 10:00:02 通道受理                                            |
+| 10:00:05 收到通道成功通知                                    |
+| 10:00:05 通知 POS 成功                                       |
++--------------------------------------------------------------+
+| 业务请求 | 渠道请求 | 通道响应 | 回调记录 | 通知记录 | 退款记录 |
++--------------------------------------------------------------+
+| 可用操作：主动查单 / 重发通知 / 查看原始报文（按权限脱敏）      |
++--------------------------------------------------------------+
+```
+
+#### 7.1.8 门店进件流程
+
+```mermaid
+flowchart TD
+    A["选择客户、品牌和门店"] --> B["选择目标收单渠道"]
+    B --> C["复用企业、主体、法人和结算账户资料"]
+    C --> D["补充渠道专属资料"]
+    D --> E["系统校验完整性和有效期"]
+    E --> F{"校验通过"}
+    F -->|"否"| G["提示缺失或错误资料"]
+    G --> C
+    F -->|"是"| H["提交支付机构"]
+    H --> I["支付机构审核"]
+    I -->|"退回补充"| J["记录退回原因并补件"]
+    J --> H
+    I -->|"审核拒绝"| K["关闭申请并保留记录"]
+    I -->|"审核通过"| L["回写商户号和支付权限"]
+    L --> M["执行支付配置和小额验证"]
+```
+
+#### 7.1.9 收单渠道切换流程
+
+```mermaid
+flowchart TD
+    A["选择切换范围：品牌、门店或终端"] --> B["选择目标收单渠道"]
+    B --> C["检查目标渠道进件、商户号和支付能力"]
+    C --> D["执行路由试算和小额支付验证"]
+    D --> E{"检查是否通过"}
+    E -->|"否"| F["阻止切换并说明原因"]
+    E -->|"是"| G["设置立即或定时生效"]
+    G --> H["审批并发布新路由版本"]
+    H --> I["新交易进入目标渠道"]
+    I --> J["观察成功率、耗时和异常"]
+    J --> K{"指标是否正常"}
+    K -->|"是"| L["确认切换完成"]
+    K -->|"否"| M["回退上一有效路由版本"]
+```
+
+切换规则：
+
+- 渠道切换只影响生效时间之后创建的新支付单。
+- 切换前已经创建的支付、退款、关闭和查询继续使用原渠道。
+- 支付结果未知的交易不得通过换渠道重新发起。
+- 目标渠道未完成门店进件、商户号未启用或支付能力不匹配时，不允许切换。
+- 每次切换必须保存范围、生效时间、操作人、审批人、切换前后配置和原因。
+
+### 7.2 核心功能
+
+#### 7.2.1 功能优先级定义
+
+| 优先级 | 定义 |
+| --- | --- |
+| P0 | 1.0 上线必须具备，缺失时不能试点 |
+| P1 | 1.0 应具备，可根据试点范围分批交付 |
+| P2 | 后续版本建设 |
+
+#### 7.2.2 支付应用管理
+
+支付应用代表一个调用聚合支付平台的业务系统，例如 POS、小程序或扫码点餐系统。
+
+| 编号 | 需求 | 优先级 | 验收标准 |
+| --- | --- | --- | --- |
+| APP-01 | 支持在客户下创建多个支付应用 | P0 | 应用名称和应用编码在客户内唯一 |
+| APP-02 | 为应用生成调用身份和密钥 | P0 | 密钥只在创建或重置时完整展示 |
+| APP-03 | 支持启用、停用和删除未使用应用 | P0 | 停用后新请求被拒绝，历史数据保留 |
+| APP-04 | 支持配置回调地址 | P0 | 仅允许符合安全规则的地址 |
+| APP-05 | 支持配置允许的支付产品和门店范围 | P1 | 超出范围的请求被拒绝 |
+| APP-06 | 支持密钥轮换 | P1 | 轮换期间可配置短时间双密钥有效 |
+| APP-07 | 支持沙箱与生产环境隔离 | P1 | 两个环境的凭证和数据不能混用 |
+| APP-08 | 支持查看本应用可用的已授权收单渠道 | P0 | 不展示或使用未授权渠道 |
+| APP-09 | 支持为应用配置收单手续费规则 | P0 | 规则校验通过并发布后生效 |
+| APP-10 | 支持查看应用当前和历史手续费版本 | P0 | 历史版本不可被覆盖或删除 |
+| APP-11 | 支持从客户已授权渠道中选择本应用可用渠道 | P0 | 应用不能选择客户未授权渠道 |
+
+##### 7.2.2.1 客户应用收单手续费
+
+收单手续费配置在客户支付应用下。它表示该应用在指定条件下约定或预估的收单手续费，用于交易成本展示、对账和经营分析。
+
+手续费规则至少支持以下维度：
+
+- 客户支付应用
+- 收单渠道
+- 支付方式
+- 商户号（可选）
+- 品牌或门店范围（可选）
+- 费率
+- 单笔固定费用（可选）
+- 单笔最低和最高手续费（可选）
+- 生效时间和失效时间
+- 退款手续费处理方式
+
+首版计算公式：
+
+```text
+预估手续费
+= 交易金额 × 费率
++ 单笔固定费用
+```
+
+计算完成后，再应用单笔最低和最高手续费限制。金额按人民币分保存，并按明确的舍入规则处理。
+
+| 编号 | 需求 | 优先级 | 验收标准 |
+| --- | --- | --- | --- |
+| FEE-01 | 支持按应用配置默认手续费规则 | P0 | 无更具体规则时命中应用默认规则 |
+| FEE-02 | 支持按收单渠道和支付方式配置差异费率 | P0 | 同一交易只能命中一条有效规则 |
+| FEE-03 | 支持费率、固定费用、最低和最高手续费 | P0 | 计算结果符合已发布公式 |
+| FEE-04 | 支持立即生效和定时生效 | P0 | 同一条件的有效期不得重叠 |
+| FEE-05 | 支持规则试算 | P0 | 输入金额、渠道和支付方式可看到命中规则及结果 |
+| FEE-06 | 交易成功时固化手续费规则版本和预估金额 | P0 | 后续改费率不改变历史交易 |
+| FEE-07 | 支持退款手续费处理配置 | P1 | 可配置不退、按退款金额比例冲减或按渠道结果处理 |
+| FEE-08 | 支持手续费规则发布、停用和版本记录 | P0 | 保留操作人、时间、原因和前后值 |
+| FEE-09 | 实际渠道手续费进入对账后可与预估手续费比较 | P1 | 平台输出规则和预估值，对账系统接收实际值 |
+| FEE-10 | 未配置手续费时按“待配置”处理 | P0 | 不默认按 0 元参与正式成本统计 |
+
+手续费规则：
+
+- 手续费不是支付交易的附加扣款，不改变顾客支付金额。
+- 平台计算的是约定或预估手续费，不代替支付机构最终结算结果。
+- 同一应用、渠道、支付方式和适用范围在同一时点只能有一条有效规则。
+- 路由切换到新渠道前，必须检查目标渠道对应手续费规则；缺少规则时给出阻断或明确警告，由客户策略决定。
+- 手续费规则必须随支付流水输出给对账系统，包括规则编号、版本、费率和预估手续费。
+
+#### 7.2.3 平台收单渠道与客户授权
+
+平台收单渠道代表平台已经完成适配开发并经过测试的银行、微信支付宝直连或持牌支付机构。
+
+平台渠道统一管理规则：
+
+- 只有平台渠道管理员可以新增、发布、升级、停用收单渠道。
+- 渠道开发完成且通过统一接口、状态、回调、退款和安全测试后，状态才可变为“平台已支持”。
+- 平台已支持的渠道默认不向客户开放。
+- 平台需要为具体客户创建渠道授权，客户才能使用该渠道进件、配置商户号和参与路由。
+- 客户授权可以限制支付产品、支付方式、有效期、品牌或门店范围。
+- 取消授权只阻止新进件和新交易，不影响历史交易查询、退款和对账。
+
+收单渠道状态：
+
+| 状态 | 定义 |
+| --- | --- |
+| 开发中 | 适配器尚未达到可用标准 |
+| 测试中 | 正在进行统一接口和渠道联调测试 |
+| 平台已支持 | 已通过测试，可以向客户授权 |
+| 维护中 | 暂停新交易，但保留历史交易处理能力 |
+| 已停用 | 不再向客户提供新业务 |
+
+客户渠道授权状态：
+
+| 状态 | 定义 |
+| --- | --- |
+| 待生效 | 已完成授权，尚未到生效时间 |
+| 已授权 | 客户可在授权范围内使用 |
+| 已暂停 | 暂时禁止新进件和新交易 |
+| 已到期 | 超过授权有效期 |
+| 已取消 | 平台主动终止授权 |
+
+| 编号 | 需求 | 优先级 | 验收标准 |
+| --- | --- | --- | --- |
+| CHN-01 | 平台统一创建收单渠道档案 | P0 | 渠道编码全平台唯一 |
+| CHN-02 | 管理渠道适配器、接口地址、机构参数和证书 | P0 | 敏感参数加密保存并脱敏展示 |
+| CHN-03 | 支持测试连接和完整能力测试 | P0 | 支付、查询、回调和退款均有测试结果 |
+| CHN-04 | 支持渠道开发、测试、已支持、维护和停用状态 | P0 | 非“平台已支持”渠道不得新增客户授权 |
+| CHN-05 | 支持声明渠道支付产品和能力 | P0 | 明确支持的支付方式、退款、关闭和查询能力 |
+| CHN-06 | 支持适配器版本和变更记录 | P0 | 可查看版本、发布时间、兼容范围和变更内容 |
+| CHN-07 | 支持插件式新增渠道适配器 | P1 | 新渠道不改变统一支付接口 |
+| CHN-08 | 支持平台向具体客户授权收单渠道 | P0 | 未授权客户不能使用该渠道 |
+| CHN-09 | 支持授权支付产品、范围和有效期 | P0 | 超出授权范围的进件和交易被拒绝 |
+| CHN-10 | 支持暂停、恢复和取消客户授权 | P0 | 只影响新业务，历史交易仍可处理 |
+| CHN-11 | 支持查看渠道已授权客户清单 | P1 | 平台管理员可按状态和有效期筛选 |
+| CHN-12 | 支持客户查看自身已授权渠道及能力 | P0 | 客户不能查看其他客户授权 |
+
+#### 7.2.4 支付商户号管理
+
+支付商户号是支付机构分配的收款主体标识。平台只管理配置，不改变商户号的资金归属。
+
+| 编号 | 需求 | 优先级 | 验收标准 |
+| --- | --- | --- | --- |
+| MCH-01 | 支持录入商户号、商户名称、所属主体和通道 | P0 | 同一通道内商户号不重复 |
+| MCH-02 | 支持商户号与品牌、门店和终端绑定 | P0 | 能覆盖门店独享和多门店共享场景 |
+| MCH-03 | 支持配置商户号有效期和状态 | P0 | 无效商户号不得用于新支付 |
+| MCH-04 | 支持按支付方式配置子商户号或应用标识 | P1 | 路由后可得到唯一有效配置 |
+| MCH-05 | 支持批量导入和批量校验 | P1 | 错误行可下载并说明原因 |
+| MCH-06 | 支持配置完整性检查 | P0 | 缺少必填参数时不能启用 |
+| MCH-07 | 商户号和资金主体关系可追溯 | P0 | 交易发生时固化当时关系快照 |
+
+#### 7.2.5 门店支付进件
+
+门店支付进件是指平台协助客户向已授权的收单渠道提交商户开户和支付产品开通资料。平台管理申请和进度，但不代替支付机构完成审核。
+
+进件对象至少包括：
+
+- 进件申请
+- 申请渠道
+- 客户、品牌、门店和经营主体
+- 商户类型
+- 企业及法人资料
+- 门店经营资料
+- 结算账户资料
+- 支付产品
+- 渠道补充字段
+- 审核状态和审核记录
+- 审核通过后返回的商户号、子商户号和应用标识
+
+进件状态如下：
+
+| 状态 | 定义 |
+| --- | --- |
+| 草稿 | 尚未提交，可以编辑 |
+| 待提交 | 资料校验通过，等待提交 |
+| 提交中 | 正在向支付机构提交 |
+| 审核中 | 支付机构已受理 |
+| 待补件 | 支付机构要求补充或修正资料 |
+| 审核通过 | 支付机构已批准 |
+| 审核拒绝 | 支付机构明确拒绝 |
+| 已撤销 | 提交前或允许撤销时被撤销 |
+| 已失效 | 商户资格、资料或合作关系失效 |
+
+| 编号 | 需求 | 优先级 | 验收标准 |
+| --- | --- | --- | --- |
+| ONB-01 | 支持按门店和目标渠道创建进件申请 | P0 | 同一门店、渠道和申请类型不产生重复有效申请 |
+| ONB-02 | 支持复用企业、法人、门店和结算账户资料 | P0 | 多渠道共同字段无需重复录入 |
+| ONB-03 | 支持渠道专属字段和资料清单 | P0 | 不同渠道可以配置不同必填项 |
+| ONB-04 | 支持资料格式、完整性和有效期校验 | P0 | 不完整或过期资料不得提交 |
+| ONB-05 | 支持图片、证照和协议附件上传 | P0 | 文件类型、大小和访问权限受控 |
+| ONB-06 | 支持单店提交和批量创建申请 | P1 | 批量任务逐店返回结果 |
+| ONB-07 | 支持向支付机构提交和查询进度 | P0 | 每次提交、查询和响应可追溯 |
+| ONB-08 | 支持待补件、补件和重新提交 | P0 | 退回原因清晰，历史版本保留 |
+| ONB-09 | 审核通过后自动回写商户号和支付权限 | P0 | 回写前校验门店、主体和渠道关系 |
+| ONB-10 | 支持人工录入外部已完成进件的商户号 | P0 | 需上传依据并经过校验 |
+| ONB-11 | 支持进件状态看板和超时提醒 | P1 | 可按渠道、品牌和状态筛选 |
+| ONB-12 | 证照和结算账户变更触发重新审核提示 | P1 | 受影响的渠道和门店可识别 |
+| ONB-13 | 进件资料按最小权限查看和下载 | P0 | 敏感资料不向无关角色开放 |
+| ONB-14 | 支持渠道无法提供进件 API 时的人工流程 | P0 | 可记录线下提交时间、渠道单号和审核结果 |
+
+进件规则：
+
+- 一个门店可以向多个收单渠道分别进件。
+- 只有客户已获得授权且授权范围覆盖该门店和支付产品时，才能向渠道进件。
+- 进件通过不等于可以立即交易；还需完成商户号绑定、支付产品开通和小额验证。
+- 审核通过后的关键主体资料不得直接覆盖。变更时创建新版本，并判断是否需要重新进件。
+- 结算账户必须属于支付机构允许的合法账户，平台不代收结算资金。
+- 不同渠道返回的商户号独立管理，不得混用密钥、证书或应用标识。
+
+#### 7.2.6 门店与终端支付配置
+
+组织和门店主档来自基础平台。聚合支付平台补充支付专用配置。
+
+| 编号 | 需求 | 优先级 | 验收标准 |
+| --- | --- | --- | --- |
+| CFG-01 | 同步客户、品牌、区域和门店信息 | P0 | 停用门店不能发起新支付 |
+| CFG-02 | 管理门店支付启用状态 | P0 | 可按门店启用或停用支付 |
+| CFG-03 | 管理终端编号和终端状态 | P0 | 终端编号在门店内唯一 |
+| CFG-04 | 支持终端绑定支付应用 | P0 | 未绑定应用的终端请求被拒绝 |
+| CFG-05 | 支持批量复制标准门店配置 | P1 | 可复制后再修改差异项 |
+| CFG-06 | 支持配置上线检查清单 | P1 | 全部必检项通过后才能启用 |
+| CFG-07 | 支持配置生效时间 | P2 | 可按未来时间自动生效 |
+
+#### 7.2.7 支付路由与收单渠道切换
+
+路由负责根据交易信息，从客户已授权且有效的收单渠道中选择渠道和商户号。
+
+| 编号 | 需求 | 优先级 | 验收标准 |
+| --- | --- | --- | --- |
+| RTE-01 | 支持按客户、品牌、门店、终端和支付方式匹配路由 | P0 | 每笔支付得到唯一有效路由 |
+| RTE-02 | 支持默认路由 | P0 | 无更具体规则时使用默认路由 |
+| RTE-03 | 支持规则优先级 | P0 | 优先级冲突时拒绝启用规则 |
+| RTE-04 | 路由结果包含通道和商户号 | P0 | 结果可以完整追溯 |
+| RTE-05 | 支持路由试算 | P0 | 不发起真实交易即可查看结果 |
+| RTE-06 | 支持按品牌、门店或终端人工切换收单渠道 | P0 | 切换需要权限、审批和审计 |
+| RTE-07 | 支持按成功率、成本自动路由 | P2 | 不纳入 1.0 |
+| RTE-08 | 支持故障自动切换 | P2 | 必须先解决重复支付风险 |
+| RTE-09 | 支持主渠道和备用渠道配置 | P0 | 两个渠道均完成目标门店进件和支付验证 |
+| RTE-10 | 支持立即生效和定时生效 | P0 | 生效时间之前的新交易仍使用原路由 |
+| RTE-11 | 支持按门店灰度切换 | P0 | 可先选择少量门店验证，再扩大范围 |
+| RTE-12 | 切换前校验目标渠道可用性 | P0 | 进件、商户号、支付方式和连接检查全部通过 |
+| RTE-13 | 支持配置版本和一键回退 | P0 | 可回退到上一有效路由版本 |
+| RTE-14 | 切换后监控成功率、耗时和异常 | P0 | 指标异常时告警并提示回退 |
+| RTE-15 | 历史交易继续绑定原渠道 | P0 | 查单、关闭和退款不会错误发送到新渠道 |
+| RTE-16 | 校验目标渠道客户授权 | P0 | 未授权、暂停或到期渠道不能成为新交易路由 |
+| RTE-17 | 校验目标渠道应用手续费 | P0 | 缺失规则时按客户策略阻断或警告 |
+
+首版不得在支付结果未知时自动换通道重试，以免同一业务订单产生重复扣款。
+
+#### 7.2.8 统一支付接口
+
+首版提供以下业务接口：
+
+- 创建支付
+- 查询支付
+- 关闭支付
+- 创建退款
+- 查询退款
+
+支付方式以试点客户确认结果为准，候选范围包括：
+
+- 被扫支付：店员扫描顾客付款码
+- 主扫支付：顾客扫描动态二维码
+- 小程序支付
+
+| 编号 | 需求 | 优先级 | 验收标准 |
+| --- | --- | --- | --- |
+| API-01 | 统一接口使用平台标准字段 | P0 | 业务系统不直接传渠道私有字段即可完成标准场景 |
+| API-02 | 每个请求必须通过身份和签名校验 | P0 | 非法请求不创建业务数据 |
+| API-03 | 创建支付必须有客户、应用、业务订单号和金额 | P0 | 缺少必填字段时返回明确错误 |
+| API-04 | 金额使用最小货币单位整数 | P0 | 不接受浮点金额 |
+| API-05 | 同一应用和业务订单号具备幂等保护 | P0 | 重复请求不产生重复有效支付单 |
+| API-06 | 返回统一支付单号和统一状态 | P0 | 所有通道使用同一状态定义 |
+| API-07 | 支持查询获得最终状态 | P0 | 查询结果与平台当前有效状态一致 |
+| API-08 | 关闭仅适用于允许关闭的未成功支付 | P0 | 已支付成功的交易不得关闭 |
+| API-09 | 支持扩展字段但不影响标准字段 | P1 | 渠道差异可扩展且不破坏兼容 |
+| API-10 | 接口版本向后兼容 | P1 | 小版本升级不要求业务系统立即改造 |
+
+#### 7.2.9 支付订单与支付流水
+
+平台区分业务订单、支付单和渠道交易：
+
+- 业务订单由 POS 或业务系统创建。
+- 支付单代表一次支付意图。
+- 渠道交易代表平台向支付通道发起的一次交易。
+
+| 编号 | 需求 | 优先级 | 验收标准 |
+| --- | --- | --- | --- |
+| PAY-01 | 保存业务订单号、支付单号和渠道流水号 | P0 | 三类编号可互相查询 |
+| PAY-02 | 保存客户、品牌、门店、终端和商户号快照 | P0 | 后续配置变化不改变历史归属 |
+| PAY-03 | 保存原始金额、币种和支付方式 | P0 | 金额不可被普通用户修改 |
+| PAY-04 | 保存创建、受理、成功、失败和关闭时间 | P0 | 时间来源和时区明确 |
+| PAY-05 | 保存渠道请求和响应摘要 | P0 | 敏感字段脱敏或不落库 |
+| PAY-06 | 支持一笔业务订单按规则产生多次支付尝试 | P1 | 同时只能有符合规则的有效支付 |
+| PAY-07 | 支持支付单详情和事件时间线 | P0 | 能展示完整处理过程 |
+| PAY-08 | 支持按条件导出授权范围内的交易 | P1 | 大批量导出使用异步任务 |
+
+#### 7.2.10 支付状态机
+
+支付单使用以下标准状态：
+
+| 状态 | 定义 | 是否最终状态 |
+| --- | --- | --- |
+| 待支付 | 支付单已创建，尚未发往通道 | 否 |
+| 支付处理中 | 通道已受理或结果暂时未知 | 否 |
+| 支付成功 | 通道确认支付成功 | 是 |
+| 支付失败 | 通道明确确认支付失败 | 是 |
+| 已关闭 | 未成功支付已被关闭 | 是 |
+
+退款不是支付单状态。退款使用独立退款单和退款状态，支付详情显示累计退款金额。
+
+```mermaid
+stateDiagram-v2
+    [*] --> 待支付
+    待支付 --> 支付处理中: 请求发送到通道
+    待支付 --> 支付失败: 参数或通道明确拒绝
+    支付处理中 --> 支付成功: 通知或查单确认成功
+    支付处理中 --> 支付失败: 查单确认失败
+    待支付 --> 已关闭: 关闭成功
+    支付处理中 --> 已关闭: 通道确认未支付并关闭
+```
+
+状态规则：
+
+- 只有可靠的通道结果才能将支付标记为成功。
+- 网络超时不等于支付失败。
+- 支付成功后不得变为支付失败或已关闭。
+- 收到重复通知时不得重复变更业务结果。
+- 冲正、撤销或退款必须使用独立业务记录，不能覆盖原支付历史。
+- 人工不得直接把支付处理中改为支付成功。
+
+#### 7.2.11 异步通知与主动查单
+
+| 编号 | 需求 | 优先级 | 验收标准 |
+| --- | --- | --- | --- |
+| NTF-01 | 接收并验证支付通道异步通知 | P0 | 验签失败的通知不更新交易 |
+| NTF-02 | 通知按通道流水和事件标识去重 | P0 | 重复通知只处理一次业务结果 |
+| NTF-03 | 支付结果变化后通知业务系统 | P0 | 通知内容使用统一格式 |
+| NTF-04 | 下游通知失败自动重试 | P0 | 重试次数和间隔可配置 |
+| NTF-05 | 业务系统返回明确成功后停止重试 | P0 | 成功记录可查询 |
+| NTF-06 | 支付处理中按规则主动查单 | P0 | 最终状态自动更新 |
+| NTF-07 | 查单超过时限仍不明确时生成异常 | P0 | 异常可被运营查询和处理 |
+| NTF-08 | 支持人工重发下游通知 | P1 | 操作需要权限并记录日志 |
+
+#### 7.2.12 退款管理
+
+退款状态如下：
+
+| 状态 | 定义 | 是否最终状态 |
+| --- | --- | --- |
+| 待审批 | 退款需要审批，尚未通过 | 否 |
+| 待退款 | 已通过校验，尚未发送到通道 | 否 |
+| 退款处理中 | 通道已受理或结果未知 | 否 |
+| 退款成功 | 通道确认退款成功 | 是 |
+| 退款失败 | 通道明确确认退款失败 | 是 |
+| 已拒绝 | 退款申请被拒绝 | 是 |
+| 已关闭 | 退款尚未执行且被关闭 | 是 |
+
+| 编号 | 需求 | 优先级 | 验收标准 |
+| --- | --- | --- | --- |
+| REF-01 | 退款必须关联原支付单 | P0 | 无有效原支付时不得退款 |
+| REF-02 | 退款单号具备幂等保护 | P0 | 重复请求不重复退款 |
+| REF-03 | 累计退款金额不得超过支付成功金额 | P0 | 并发退款也不能超额 |
+| REF-04 | 支持全额退款和部分退款 | P0 | 多次部分退款累计正确 |
+| REF-05 | 支持退款查询和主动补偿 | P0 | 结果未知时不得直接标记失败 |
+| REF-06 | 支持按客户配置退款权限 | P0 | 未授权用户不能发起退款 |
+| REF-07 | 支持可选退款审批 | P1 | 可按金额、角色或门店配置 |
+| REF-08 | 退款成功后通知业务系统 | P0 | 通知失败自动重试 |
+| REF-09 | 保存退款原因和操作来源 | P0 | API 和人工操作均可追溯 |
+
+#### 7.2.13 交易中心
+
+| 编号 | 需求 | 优先级 | 验收标准 |
+| --- | --- | --- | --- |
+| TXN-01 | 按支付单号、业务订单号和渠道流水号查询 | P0 | 精确查询可定位唯一或明确结果 |
+| TXN-02 | 按品牌、门店、终端、通道、状态和时间筛选 | P0 | 数据范围服从基础平台权限 |
+| TXN-03 | 展示支付详情和事件时间线 | P0 | 请求、响应、通知、查单和操作均可见 |
+| TXN-04 | 展示原支付下全部退款 | P0 | 累计已退和可退金额正确 |
+| TXN-05 | 展示统一错误原因和处理建议 | P1 | 常见渠道错误完成标准映射 |
+| TXN-06 | 支持主动查单和重发通知 | P1 | 只对允许状态提供操作 |
+| TXN-07 | 支持授权数据导出 | P1 | 敏感信息按角色脱敏 |
+
+#### 7.2.14 异常中心
+
+首版至少识别以下异常：
+
+- 支付处理中超过时限
+- 通道回调验签失败
+- 下游通知多次失败
+- 支付状态冲突
+- 退款处理中超过时限
+- 退款失败
+- 路由或商户号配置缺失
+- 通道连接异常
+- 对账数据输出失败
+
+| 编号 | 需求 | 优先级 | 验收标准 |
+| --- | --- | --- | --- |
+| EXC-01 | 自动生成异常任务 | P0 | 相同交易和异常类型不重复生成有效任务 |
+| EXC-02 | 异常有类型、等级、状态和责任角色 | P0 | 可筛选和统计 |
+| EXC-03 | 异常关联完整交易上下文 | P0 | 不需要再次手工拼接基础信息 |
+| EXC-04 | 支持领取、分配、处理和关闭 | P1 | 所有操作保留记录 |
+| EXC-05 | 支持建议处理动作 | P1 | 常见异常有清晰建议 |
+| EXC-06 | 严重异常触发消息和告警 | P0 | 告警对象和方式可配置 |
+| EXC-07 | 状态恢复后可自动关闭适用异常 | P1 | 自动关闭原因可见 |
+
+#### 7.2.15 支付概览和监控
+
+支付概览面向客户管理人员，监控中心面向运营和技术人员。
+
+| 编号 | 需求 | 优先级 | 验收标准 |
+| --- | --- | --- | --- |
+| MON-01 | 展示交易笔数、金额和成功率 | P1 | 支持按客户授权范围筛选 |
+| MON-02 | 展示通道成功率和响应时间 | P1 | 可按时间和支付方式查看 |
+| MON-03 | 展示处理中、失败和异常数量 | P0 | 可跳转到对应交易或异常 |
+| MON-04 | 监控回调积压和通知重试积压 | P0 | 超过阈值触发告警 |
+| MON-05 | 监控通道连接和接口错误 | P0 | 能区分平台和外部通道问题 |
+| MON-06 | 支持告警阈值配置 | P1 | 客户告警与平台告警分开 |
+| MON-07 | 支持业务高峰看板 | P2 | 后续版本建设 |
+
+#### 7.2.16 标准支付流水输出
+
+聚合支付平台向对账系统输出支付和退款数据，不负责完成核销。
+
+支付流水至少包含：
+
+- 客户、品牌、区域、门店和终端
+- 支付应用
+- 业务订单号
+- 平台支付单号
+- 渠道交易流水号
+- 支付方式
+- 通道
+- 客户渠道授权编号
+- 商户号及收款主体标识
+- 交易金额和币种
+- 手续费规则编号和版本
+- 预估收单手续费
+- 支付状态
+- 创建、受理、成功、失败或关闭时间
+- 原始业务发生时间和营业日期（由业务系统提供）
+- 当前记录版本和更新时间
+
+退款流水至少包含：
+
+- 平台退款单号
+- 业务退款单号
+- 原支付单号
+- 渠道退款流水号
+- 退款金额
+- 退款状态
+- 退款原因
+- 创建和成功时间
+
+| 编号 | 需求 | 优先级 | 验收标准 |
+| --- | --- | --- | --- |
+| OUT-01 | 支付和退款状态变化可增量输出 | P0 | 下游能识别新增和更新 |
+| OUT-02 | 输出记录具备唯一标识和版本 | P0 | 重复消费不产生重复业务数据 |
+| OUT-03 | 输出失败自动重试 | P0 | 最终失败生成异常任务 |
+| OUT-04 | 支持按时间范围补发 | P1 | 补发不改变原交易状态 |
+| OUT-05 | 支持查询输出状态 | P0 | 每笔交易可查看是否成功送达 |
+| OUT-06 | 对账系统确认接收后记录回执 | P1 | 可追踪双方数据交付状态 |
+| OUT-07 | 输出手续费规则和预估手续费 | P0 | 对账系统可以与渠道实际手续费核对 |
+
+#### 7.2.17 权限与审计
+
+基础平台负责用户、角色、菜单和数据范围。聚合支付平台负责业务操作权限校验和业务审计。
+
+敏感操作包括：
+
+- 创建或重置应用密钥
+- 查看或修改支付通道密钥和证书
+- 启用或停用通道
+- 向客户授权、暂停或取消收单渠道
+- 修改应用手续费规则
+- 修改路由
+- 提交、补充、撤销进件申请
+- 查看或下载进件证照和结算账户资料
+- 发布或回退收单渠道切换
+- 修改商户号绑定
+- 发起或审批退款
+- 主动查单
+- 重发通知
+- 导出交易
+- 人工关闭异常
+
+| 编号 | 需求 | 优先级 | 验收标准 |
+| --- | --- | --- | --- |
+| SEC-01 | 所有页面和接口校验客户与数据范围 | P0 | 不能跨客户或越权访问 |
+| SEC-02 | 敏感字段按角色脱敏 | P0 | 页面、导出和日志规则一致 |
+| SEC-03 | 敏感操作记录操作人、时间、前后值和原因 | P0 | 审计记录不可被普通用户删除 |
+| SEC-04 | 退款和密钥操作支持二次确认 | P0 | 误操作风险得到控制 |
+| SEC-05 | 支持高风险操作双人审批 | P2 | 后续按客户需求建设 |
+
+#### 7.2.18 配置发布和回退
+
+| 编号 | 需求 | 优先级 | 验收标准 |
+| --- | --- | --- | --- |
+| PUB-01 | 路由、商户号绑定和通道参数修改前进行校验 | P0 | 校验失败不能发布 |
+| PUB-02 | 配置发布保留版本 | P1 | 可查看历史版本 |
+| PUB-03 | 支持回退到上一个有效版本 | P1 | 回退不改变历史交易快照 |
+| PUB-04 | 高风险配置变更需要审批 | P2 | 后续按客户需求建设 |
+| PUB-05 | 收单渠道切换必须形成独立发布单 | P0 | 发布单包含范围、时间、原因和验证结果 |
+| PUB-06 | 支持灰度发布和扩大范围 | P0 | 每次扩大范围均保留版本和操作记录 |
+| PUB-07 | 支持紧急回退上一有效收单渠道 | P0 | 回退只影响新交易，不改变历史渠道归属 |
+
+### 7.3 技术和质量要求
+
+本节定义产品必须达到的技术结果，不规定具体代码架构。
+
+#### 7.3.1 核心业务对象
+
+| 对象 | 定义 |
+| --- | --- |
+| 支付应用 | 调用聚合支付接口的业务系统 |
+| 平台收单渠道 | 平台统一开发、测试并支持的银行或支付机构渠道 |
+| 渠道适配器版本 | 某收单渠道的接口实现和能力版本 |
+| 客户渠道授权 | 平台允许某客户使用指定收单渠道及能力范围的授权 |
+| 支付商户号 | 支付机构分配的商户标识 |
+| 应用手续费规则 | 客户支付应用在指定渠道和支付方式下的手续费规则 |
+| 进件申请 | 门店向指定支付机构申请商户号和支付产品的申请记录 |
+| 进件资料 | 企业、法人、门店、结算账户及渠道要求的证明资料 |
+| 终端 | 门店内发起支付的设备或逻辑终端 |
+| 路由规则 | 选择通道和商户号的规则 |
+| 渠道切换单 | 记录切换范围、目标渠道、生效时间、审批和回退信息的发布单 |
+| 业务订单 | 外部业务系统中的销售或交易订单 |
+| 支付单 | 平台内的一次支付意图 |
+| 渠道交易 | 向支付通道发起的一次交易请求 |
+| 退款单 | 对原支付发起的一次退款意图 |
+| 通知记录 | 渠道回调或平台通知下游的记录 |
+| 异常任务 | 需要系统或人工处理的支付问题 |
+| 支付事件 | 支付处理过程中发生的不可变事实记录 |
+
+#### 7.3.2 唯一性和幂等
+
+- 客户之间的数据必须隔离。
+- 同一支付应用下，业务订单号必须唯一。
+- 同一支付应用下，业务退款单号必须唯一。
+- 同一手续费适用条件的有效时间不得重叠。
+- 每次外部请求必须有请求标识。
+- 同一幂等请求重复到达时，返回已有结果，不重复执行资金操作。
+- 支付、退款、回调和下游通知都必须独立实现幂等。
+- 并发退款必须使用可靠的金额锁定机制，防止超额退款。
+
+#### 7.3.3 一致性
+
+- 平台与支付通道使用最终一致方式确认支付结果。
+- 网络超时只表示当前结果未知，不表示交易失败。
+- 异步通知和主动查单结果冲突时，按通道规则和事件时间进行处理，并生成审计记录。
+- 已确认成功的支付不得被较早或重复的失败通知覆盖。
+- 所有状态变化必须产生支付事件。
+- 对账输出失败不能影响支付结果，但必须重试和告警。
+
+#### 7.3.4 性能
+
+首版性能目标由试点交易峰值校准，初始基线如下：
+
+| 指标 | 目标 |
+| --- | ---: |
+| 平台内部处理增加的 P95 耗时 | 不超过 100 毫秒 |
+| 查询接口 P95 响应时间 | 不超过 500 毫秒 |
+| 交易列表常用查询 P95 | 不超过 2 秒 |
+| 支持的首期持续交易量 | 不低于 100 TPS |
+| 支持的首期短时峰值 | 不低于 300 TPS |
+| 下游通知开始时间 | 状态变化后 1 秒内 |
+
+以上指标不含外部支付通道响应时间。
+
+#### 7.3.5 可用性和恢复
+
+- 核心支付接口月度可用性目标不低于 99.95%。
+- 单个非核心后台页面故障不得影响支付受理。
+- 通道管理、报表和导出任务与核心支付链路隔离。
+- 支付请求和关键状态变化不能只存在于内存。
+- 系统重启后，未完成支付和退款任务可以继续处理。
+- 必须有数据备份、恢复演练和版本回退方案。
+- 上线前必须明确恢复时间目标和恢复点目标，并由技术与业务负责人确认。
+
+#### 7.3.6 安全
+
+- 全部外部接口使用加密传输。
+- 请求和回调必须验签，并防止重放。
+- 应用密钥、通道密钥、私钥和证书加密保存。
+- 密钥不得明文写入普通日志。
+- 银行卡号、证件号、手机号等敏感信息按最小必要原则采集和展示。
+- 不保存支付密码、付款码等禁止留存的信息。
+- 管理端使用基础平台统一登录和鉴权。
+- 支付接口凭证与管理端用户凭证分离。
+- 安全日志和支付审计日志按合规要求保存。
+- 上线前完成漏洞扫描、权限测试和关键接口安全测试。
+
+#### 7.3.7 合规
+
+- 平台必须明确自身是技术服务方，不是资金清算主体。
+- 资金由持牌机构按合规协议直接结算到合法商户账户。
+- 产品方案不得形成无牌资金归集和二次清算。
+- 接入前核实合作支付机构资质和业务范围。
+- 如果业务属于收单外包服务，应按要求完成备案和管理。
+- 客户协议必须明确平台、客户和支付机构的责任边界。
+- 新增储值、担保、分账或跨境业务前必须单独进行合规评审。
+- 进件资料必须经客户授权后提交给指定支付机构，并记录授权、提交和访问过程。
+- 平台展示“审核通过”只表示支付机构已返回通过结果，不代表平台自行完成资质审核。
+- 平台不得擅自修改客户提交的主体、法人或结算账户证明材料。
+
+#### 7.3.8 可观测性
+
+每笔交易至少可以通过以下标识追踪：
+
+- 业务订单号
+- 平台支付单号
+- 请求标识
+- 渠道流水号
+- 门店和终端
+
+系统必须记录：
+
+- 接口请求结果
+- 路由结果
+- 通道请求和响应结果
+- 异步通知
+- 主动查单
+- 下游通知和重试
+- 状态变化
+- 人工操作
+
+监控必须区分：
+
+- 平台错误
+- 配置错误
+- 客户请求错误
+- 网络错误
+- 外部通道错误
+- 下游业务系统错误
+
+#### 7.3.9 数据保存
+
+- 支付和退款核心记录不得物理删除。
+- 配置停用不影响历史交易查询。
+- 交易发生时保存组织、商户号和路由快照。
+- 日志保存期限由合规和客户合同共同确定。
+- 原始报文只保存排查所需内容，并对敏感字段脱敏或加密。
+- 导出文件设置有效期，并限制下载权限。
+
+### 7.4 假设与待验证事项
+
+| 编号 | 假设 | 风险 | 验证方法 | 最晚验证阶段 |
+| --- | --- | --- | --- | --- |
+| A-01 | 试点客户愿意保留现有 POS，只接入支付中台 | 客户可能更想购买完整收银套件 | 客户访谈和方案确认 | 需求确认 |
+| A-02 | 客户至少使用两个支付渠道或计划新增通道 | 单通道客户价值不足 | 盘点商户号和通道 | 需求确认 |
+| A-03 | 业务系统能提供全局唯一订单号 | 幂等和对账难以保证 | 接口和数据样本检查 | 接口设计 |
+| A-04 | 一个统一状态机可覆盖首期通道 | 渠道状态无法准确映射 | 使用真实接口文档做映射评审 | 技术预研 |
+| A-05 | 主动查单可以在可接受时间内确认未知状态 | 顾客和门店等待过久 | 沙箱与真实小额测试 | 联调测试 |
+| A-06 | 连锁组织和商户号关系能用标准模型覆盖 | 客户大量特殊关系导致定制 | 选取三类客户数据试建模 | 方案评审 |
+| A-07 | 客户愿意为软件能力付费，而不只比较费率 | 商业模式不成立 | 报价访谈或付费试点 | 试点签约 |
+| A-08 | 支付流水可以直接满足对账系统输入 | 字段或状态仍需大量转换 | 端到端数据走查 | 集成测试 |
+| A-09 | 两个收单渠道可以覆盖同一组试点门店和支付方式 | 无法完成真实渠道切换 | 开发前完成门店准入预审和双渠道小额测试 | 技术预研 |
+| A-10 | 基础平台能按计划提供组织、权限和门户 | 业务系统重复建设底座 | 完成依赖接口和交付检查 | 开发启动 |
+| A-11 | 支付机构允许目标部署和技术服务模式 | 商务或合规阻断 | 与支付机构完成书面确认 | 开发启动 |
+| A-12 | 门店退款规则可以标准化 | 不同客户审批差异过大 | 梳理真实退款制度 | 需求确认 |
+| A-13 | 两个试点收单渠道均支持目标门店类型进件 | 无法完成渠道切换验证 | 获取渠道准入规则并预审样本门店 | 技术预研 |
+| A-14 | 主要进件资料可跨渠道复用 | 每个渠道仍需大量重复录入 | 对比两个渠道资料清单 | 需求确认 |
+| A-15 | 渠道切换可只通过平台路由完成 | POS 或渠道侧还需改配置 | 完成双渠道端到端切换演练 | 联调测试 |
+| A-16 | 平台级渠道适配器可以供多个客户复用 | 客户差异导致每次仍需定制开发 | 用两个客户配置同一渠道验证 | 技术预研 |
+| A-17 | 客户应用手续费可以使用统一规则模型 | 渠道费率规则过于复杂 | 收集两个渠道和试点客户合同样本 | 需求确认 |
+
+### 7.5 依赖
+
+| 依赖项 | 依赖内容 | 未满足影响 |
+| --- | --- | --- |
+| 基础平台 | 客户、组织、用户、权限、门户、日志 | 管理端无法上线 |
+| 试点客户 | 门店、终端、订单、商户号和真实场景 | 无法验证产品价值 |
+| 支付机构 | 两个渠道的接口、进件规则、测试环境和技术支持 | 无法完成进件及渠道切换 |
+| 对账系统 | 标准支付流水接收协议 | 无法验证产品组合闭环 |
+| 运维平台 | 日志、指标、告警和部署能力 | 无法达到生产要求 |
+| 安全与合规 | 方案评审、合同和数据要求 | 不得生产上线 |
+
+### 7.6 1.0 验收主场景
+
+1. 平台创建两个收单渠道，完成适配器测试并标记为“平台已支持”。
+2. 平台只向试点客户授权这两个渠道，其他客户不可见、不可用。
+3. 创建客户支付应用并完成凭证配置。
+4. 为应用配置两个渠道的手续费规则，试算结果正确。
+5. 手续费新版本生效后，历史交易仍保留原规则版本和预估金额。
+6. 为试点门店向两个已授权收单渠道创建进件申请。
+7. 复用企业和门店资料，补充渠道专属资料并提交。
+8. 进件被退回后可查看原因、补件并重新提交。
+9. 审核通过后自动或人工校验回写两个渠道的商户号。
+10. POS 使用统一接口通过主渠道发起支付并成功。
+11. 支付成功时固化应用手续费规则版本和预估手续费。
+12. 相同请求重复提交，不产生重复支付。
+13. 通道同步响应超时，通过主动查单确认成功。
+14. 通道重复回调，平台只处理一次。
+15. 业务系统回调失败，平台自动重试并最终成功。
+16. 对指定试点门店执行路由试算和备用渠道小额验证。
+17. 将指定门店从主渠道灰度切换到备用渠道，新交易正确进入备用渠道并使用备用渠道手续费。
+18. 暂停客户的备用渠道授权后，新交易不能进入该渠道。
+19. 切换前已创建交易仍通过原渠道完成查询和退款。
+20. 支付结果未知时，系统禁止通过备用渠道重新支付。
+21. 切换后指标异常时，可回退到上一有效渠道。
+22. 总部按业务订单号查询完整交易时间线。
+23. 门店只能查询本店交易。
+24. 发起全额退款并成功。
+25. 发起多次部分退款，累计不超过原支付金额。
+26. 并发发起超额退款时，系统可靠拦截。
+27. 支付处理中超过时限，系统生成异常并告警。
+28. 停用平台渠道后，不允许新增授权或新交易。
+29. 修改商户号关系后，历史交易归属不变化。
+30. 标准支付、退款和预估手续费成功输出到对账系统。
+31. 对账输出失败后自动重试，并可人工补发。
+32. 越权用户无法查看其他客户、门店或进件资料。
+33. 密钥、证书、进件证照和敏感数据不在页面及日志中明文暴露。
+34. 发生版本故障时，可以按预案回退且不丢失交易。
+
+## 8. 发布
+
+### 8.1 发布策略
+
+采用“双渠道预接入—小范围试点—灰度切换—稳定运行—扩展门店”的方式发布。
+
+首版不能直接全量覆盖客户全部门店。每个阶段都需要有明确的进入条件、退出条件和回退方案。
+
+### 8.2 阶段 0：需求确认和技术预研
+
+建议周期：2—4 周。
+
+范围：
+
+- 确认试点客户、品牌和 3—5 家试点门店。
+- 盘点业务系统、支付方式、已有商户号和候选收单渠道。
+- 确认两个试点收单渠道的接口、进件资料和门店准入规则。
+- 确认支付、退款和异常场景。
+- 完成统一状态和通道状态映射。
+- 完成统一进件资料模型和两个渠道专属字段映射。
+- 完成渠道切换、灰度和回退规则。
+- 完成合规、安全和资金链路评审。
+- 完成聚合支付与基础平台、对账系统的接口边界。
+
+退出条件：
+
+- 试点范围书面确认。
+- 两个支付机构测试环境和进件联调方式可用。
+- 关键假设 A-01 至 A-06 有明确结论。
+- 资金链路不存在无牌清算风险。
+- 技术预研通过进件、支付、查询、回调、退款和渠道切换最小链路。
+
+### 8.3 阶段 1：内部可用版本
+
+建议周期：6—8 周。
+
+包含：
+
+- 支付应用管理
+- 两个支付通道适配器
+- 平台收单渠道目录和客户渠道授权
+- 门店进件申请、资料校验和状态跟踪
+- 客户支付应用手续费规则和试算
+- 商户号和门店终端配置
+- 主备渠道配置、路由试算和手工切换
+- 创建支付和支付查询
+- 支付状态机
+- 回调验签、去重和主动查单
+- 交易查询和事件时间线
+- 基础日志、监控和告警
+
+不包含：
+
+- 生产门店上线
+- 复杂退款审批
+- 自动通道切换
+- 对外开放平台门户
+
+退出条件：
+
+- 沙箱和模拟通道核心测试通过。
+- 幂等、重复回调和超时查单测试通过。
+- 安全测试无阻断问题。
+- 核心监控和告警可用。
+
+### 8.4 阶段 2：1.0 试点版本
+
+建议周期：4—6 周。
+
+在阶段 1 基础上增加：
+
+- 真实支付通道生产接入
+- 试点门店双渠道进件和商户号回写
+- 按门店灰度切换及路由版本回退
+- 手续费规则版本、交易手续费快照和对账输出
+- 退款和退款查询
+- 下游通知和通知重试
+- 异常中心
+- 标准支付流水输出到对账系统
+- 试点客户角色和数据权限
+- 门店配置检查和上线清单
+- 生产应急和回退方案
+
+试点范围：
+
+- 一个客户
+- 一个品牌
+- 3—5 家代表性门店
+- 两个已完成试点门店进件的收单渠道
+- 一到两种支付方式
+- 一个主要业务入口
+
+退出条件：
+
+- 连续稳定运行至少两个完整营业周期。
+- 无严重资金事故。
+- 支付最终状态可确认率达到 100%。
+- 支付和退款流水可以完整进入对账系统。
+- 试点门店完成至少一次主渠道到备用渠道的切换和回退演练。
+- 试点门店和总部确认核心流程可用。
+- 所有 P0 问题关闭。
+
+### 8.5 阶段 3：1.0 扩展发布
+
+建议周期：试点通过后 4—8 周。
+
+包含：
+
+- 扩展到更多门店或完整品牌。
+- 增加批量配置和门店复制。
+- 增加批量进件、批量补件和进件进度看板。
+- 将渠道切换范围从试点门店扩大到品牌或区域。
+- 优化支付概览和运营报表。
+- 完善错误码映射和处理建议。
+- 根据试点结果优化退款权限。
+- 完善实施、培训和运维手册。
+
+进入条件：
+
+- 试点复盘通过。
+- 容量测试达到扩展门店峰值要求。
+- 客户上线计划和门店回退方式明确。
+
+### 8.6 后续版本
+
+#### 1.1 候选范围
+
+- 第三个及更多支付通道
+- 主扫、小程序等更多支付方式
+- 更完整的切换审批和定时发布
+- 更完整的退款审批
+- 通道成本和成功率分析
+- 开发者沙箱、文档和联调工具
+- 专属实例或私有化部署增强
+
+#### 1.2 候选范围
+
+- 多通道健康度路由
+- 安全的自动故障切换
+- 更多渠道的进件模板和自动回写
+- 数字人民币和外卡支付
+- 连锁零售、鞋服和药店行业模板
+- 平台型子商户场景
+- 与分账系统的担保交易衔接
+
+### 8.7 1.0 明确不发布
+
+- 智能成本路由
+- 未确认支付结果时自动换通道重付
+- 代替支付机构完成资质审批或商户开户
+- 会员储值和营销
+- POS 商品和订单管理
+- 财务对账和差异处理
+- 多主体分账和出款
+- 担保交易
+- 跨境支付
+- 面向小微商户的硬件铺设和地推体系
+
+### 8.8 上线检查
+
+上线前必须确认：
+
+- 试点客户和门店范围
+- 商户号及资金收款主体
+- 两个渠道的进件状态、商户号和支付产品权限
+- 客户渠道授权状态和授权范围
+- 支付和退款权限
+- 支付通道生产参数
+- 业务系统生产回调地址
+- 门店和终端配置
+- 路由规则
+- 渠道切换范围、生效时间和回退版本
+- 客户应用手续费规则、生效时间和历史版本
+- 幂等规则
+- 主动查单规则
+- 通知重试规则
+- 监控和告警联系人
+- 支付机构应急联系人
+- 数据备份和恢复方案
+- 版本回退方案
+- 客服和门店操作说明
+- 对账系统数据接收
+- 安全与合规审批
+
+### 8.9 发布后的观察指标
+
+发布后按小时、营业日和自然日观察：
+
+- 支付请求量和金额
+- 支付成功率
+- 支付处理中数量和持续时间
+- 平台错误率
+- 通道错误率
+- 平台处理耗时
+- 通道响应耗时
+- 回调验签失败数量
+- 下游通知失败和积压
+- 主动查单数量和确认结果
+- 重复请求拦截数量
+- 退款成功率和处理中数量
+- 异常任务数量和处理时长
+- 支付流水输出失败数量
+- 门店和客户投诉
+
+### 8.10 停止或回退条件
+
+出现以下任一情况，应停止扩店并根据预案回退：
+
+- 发生平台原因导致的重复扣款或错误退款。
+- 支付金额、币种或商户号路由错误。
+- 大量交易状态无法确认。
+- 核心接口持续不可用并超过约定时间。
+- 数据跨客户泄露或严重越权。
+- 密钥、证书或敏感支付数据泄露。
+- 资金链路存在合规问题。
+- 支付流水大面积缺失且无法补回。
+
+回退后必须保留全部已发生交易和事件记录，不得通过删除数据掩盖问题。
diff --git a/10-产品线/聚合支付/README.md b/10-产品线/聚合支付/README.md
index 2a192cb..749a5bc 100644
--- a/10-产品线/聚合支付/README.md
+++ b/10-产品线/聚合支付/README.md
@@ -3,3 +3,9 @@
 本目录用于沉淀聚合支付系统规划。
 
 2026 年重点目标是基于基础平台和技术架构调整，完成聚合支付系统 1.0 版本建设。
+
+## 规划文档
+
+- [产品发现与 MVP 方向](./01-产品发现与MVP方向.md)
+- [竞品分析](./02-竞品分析.md)
+- [PRD：适用于连锁企业的聚合支付平台](./PRD-适用于连锁企业的聚合支付平台.md)