csds/zd_product_document

Fork 0

Files

LiuLiang 4c16cd8c6c 聚合支付系统

2026-06-22 11:56:31 +08:00

68 KiB

Raw Blame History

PRD：适用于连锁企业的聚合支付平台

文档状态：初稿
目标版本：1.0
产品形态：企业级聚合支付平台
首期行业：连锁餐饮，可扩展至连锁零售、鞋服和药店
依赖产品：基础平台、连锁业务对账系统

变更记录

版本	变更内容
0.1	形成聚合支付平台 1.0 初稿
0.2	将门店支付进件、双收单渠道接入和渠道切换纳入 1.0
0.3	明确平台统一管理收单渠道、按客户授权渠道，并增加客户应用手续费配置

1. 摘要

本产品面向已有 POS、扫码点餐、小程序等业务系统的连锁企业，提供统一支付接口、支付通道配置、交易状态管理、退款管理和异常处置能力。

平台不直接保管客户资金，不替代持牌支付机构，也不替代 POS、对账系统和分账系统。平台负责可靠地完成支付受理，并输出完整、统一、可追溯的支付流水。

一句话定位：

面向连锁企业，连接业务系统与多个支付通道的支付接入和交易运营中台。

2. 联系人

实际姓名由项目启动会补充。角色和责任如下。

角色	姓名	主要责任	评审内容
产品负责人	待定	产品目标、范围、优先级和验收	PRD、版本范围、验收结果
业务负责人	待定	客户业务规则和试点协调	门店场景、商户关系、退款规则
技术负责人	待定	技术方案、系统稳定性和安全	架构、接口、一致性、性能
研发负责人	待定	研发计划和交付质量	工作量、依赖、交付风险
测试负责人	待定	测试方案和质量验收	核心链路、异常链路、回归测试
运维负责人	待定	上线、监控、故障处理和回退	监控、告警、应急预案
安全与合规负责人	待定	支付安全、数据安全和合规边界	密钥、日志、敏感信息、合作资质
实施负责人	待定	客户初始化、联调和门店上线	配置模板、上线清单、培训
试点客户负责人	待定	客户决策、资源协调和验收确认	试点范围、业务验收、问题闭环
支付机构联系人	待定	通道申请、接口支持和异常协同	商户号、接口、账单、结算状态

3. 背景

3.1 当前情况

连锁企业通常同时存在多个支付入口：

门店 POS
扫码点餐
微信或支付宝小程序
品牌 App
私域商城
自助点餐机
第三方业务系统

企业还可能同时使用多个支付通道：

微信支付直连
支付宝直连
银联或银行聚合支付
持牌支付机构
行业支付服务商

如果每个业务系统分别接入每个支付通道，会出现以下问题：

同一个渠道被重复开发和维护。
不同系统使用不同的支付状态和错误码。
集团无法统一管理门店、终端、商户号和支付参数。
顾客已扣款但 POS 未收到成功结果时，门店难以判断实际状态。
回调丢失、网络超时和重复请求可能造成状态不一致。
客服和运营需要登录多个渠道后台查询交易。
支付流水格式不统一，对账系统需要重复清洗和适配。
新增支付渠道时，需要同时改造多个业务系统。
新门店需要分别向支付机构提交资料，进件过程缺少统一跟踪。
收单渠道发生故障、费率变化或合作调整时，门店切换渠道依赖人工改配置，风险较高。
平台已经开发支持的收单渠道缺少统一目录，容易在客户项目中重复配置或重复判断支持范围。
不同客户和应用的收单手续费约定不同，缺少统一、生效时间明确且可追溯的手续费规则。

3.2 为什么现在建设

公司正在形成“支付—对账—分账”的产品组合：

聚合支付平台负责支付受理和支付流水。
连锁业务对账系统负责订单与渠道结算核销。
分账系统负责多主体资金分配和结算。

基础平台已规划客户、组织、用户、角色、权限、门户、配置和操作日志能力。聚合支付平台可以复用这些能力，把建设重点放在支付业务本身。

市场竞品已能提供多渠道支付，但仍有以下机会：

中大型连锁企业不希望替换已有 POS 和业务系统。
企业希望保留已有银行和收单机构关系。
企业需要跨支付机构的统一交易运营视图。
连锁企业的品牌、加盟商、门店、终端和商户号关系较复杂。
支付异常的解释、定位和处置仍然依赖人工经验。
支付流水需要直接支持后续对账和分账，而不只是生成收款记录。

3.3 产品原则

资金合规：平台只提供技术服务，不沉淀、不挪用、不代为清算客户资金。
支付正确：资金状态正确高于页面体验和功能数量。
通道中立：允许客户使用多家银行、微信支付宝直连或持牌支付机构。
不替换业务系统：通过标准接口接入已有 POS、小程序和业务中台。
连锁模型优先：所有交易必须可以明确归属客户、品牌、门店和终端。
异常可解释：支付过程要可查询、可追踪、可处理。
边界清晰：支付、对账和分账分别承担独立职责。
先试点再扩展：首版接入两个可切换的收单渠道和有限支付场景，用小范围门店验证。
进件不代替审核：平台统一收集和提交资料，但最终审核、签约和商户号开通由持牌支付机构完成。
切换不重试未知交易：渠道切换只影响新交易；已有交易仍由原渠道完成查询、退款和对账。
平台统一维护渠道：渠道适配器和公共能力由平台统一开发、测试、发布和停用，客户不能自行创建平台级收单渠道。
先授权再使用：平台支持某个收单渠道，不代表所有客户自动可用；客户只有获得授权后才能进件、配置商户号和参与路由。
费率版本化：应用手续费按生效时间形成版本，交易发生时固化命中的规则和预估手续费，不使用新规则覆盖历史结果。

3.4 产品边界

3.4.1 本产品负责

支付应用接入和接口凭证管理
平台级收单渠道目录、渠道适配器和能力版本管理
按客户授权或取消授权收单渠道
门店支付进件申请、资料管理和进度跟踪
支付商户号及参数管理
品牌、门店、终端与商户号的支付关系
统一支付、查询、关闭和退款接口
支付路由
收单渠道切换、灰度生效和回退
支付订单和支付流水
退款单和退款流水
回调接收、通知下游和通知重试
主动查单和自动补偿
支付状态统一
交易查询和异常处置
支付监控和告警
客户应用收单手续费规则和预估手续费计算
向对账系统输出标准支付流水

3.4.2 本产品不负责

商品、购物车、销售订单和履约管理
会员、储值、积分、优惠券和营销
支付机构的资金清算和商户结算
代替支付机构完成商户资质审核、协议签署和最终开户审批
无牌资金归集或“二清”
渠道结算账单与业务订单的财务核销
对账差异处理
多主体清分、分润、结算和出款
门店利润和加盟商利润核算
完整 POS 或门店经营 SaaS

3.5 系统关系

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 建议包含以下一级菜单：

支付概览
交易中心
退款中心
异常中心
支付配置
接入管理
监控中心
数据输出

基础平台继续提供：

客户管理
组织管理
用户与账号
角色和权限
统一门户
通用操作日志
消息与待办

7.1.2 新客户开通流程

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 支付主流程

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 支付状态未知处理流程

平台请求支付通道后发生网络超时。
平台不得直接把订单标记为支付失败。
支付单进入“支付处理中”。
平台按规则主动查询通道。
查询为成功时，更新为支付成功并通知业务系统。
查询为失败或已关闭时，更新为对应最终状态。
多次查询仍无结果时，生成异常任务并告警。
运营人员可以查看完整事件时间线并再次查单。
未获得可靠最终结果前，不允许同一业务单重新生成新的有效支付单，除非业务规则明确允许。

7.1.5 退款流程

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 异常处理流程

系统识别异常并生成异常任务。
异常任务自动带入交易、通道和事件记录。
系统给出异常类型、影响范围和建议动作。
运营人员领取或被分配任务。
运营人员执行查单、重发通知、确认配置或联系渠道等动作。
系统记录每次操作和结果。
问题消除后，任务自动或人工关闭。
关闭时必须填写处理结果；人工改状态必须有高权限和完整审计。

7.1.7 交易详情页面草图

+--------------------------------------------------------------+
| 支付单号          业务订单号          当前状态：支付成功       |
+--------------------------------------------------------------+
| 金额 | 品牌 | 门店 | 终端 | 支付方式 | 通道 | 商户号（脱敏）   |
+--------------------------------------------------------------+
| 事件时间线                                                   |
| 10:00:01 收到业务请求                                        |
| 10:00:01 选择通道和商户号                                    |
| 10:00:02 通道受理                                            |
| 10:00:05 收到通道成功通知                                    |
| 10:00:05 通知 POS 成功                                       |
+--------------------------------------------------------------+
| 业务请求 | 渠道请求 | 通道响应 | 回调记录 | 通知记录 | 退款记录 |
+--------------------------------------------------------------+
| 可用操作：主动查单 / 重发通知 / 查看原始报文（按权限脱敏）      |
+--------------------------------------------------------------+

7.1.8 门店进件流程

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 收单渠道切换流程

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 客户应用收单手续费

收单手续费配置在客户支付应用下。它表示该应用在指定条件下约定或预估的收单手续费，用于交易成本展示、对账和经营分析。

手续费规则至少支持以下维度：

客户支付应用
收单渠道
支付方式
商户号（可选）
品牌或门店范围（可选）
费率
单笔固定费用（可选）
单笔最低和最高手续费（可选）
生效时间和失效时间
退款手续费处理方式

首版计算公式：

预估手续费
= 交易金额 × 费率
+ 单笔固定费用

计算完成后，再应用单笔最低和最高手续费限制。金额按人民币分保存，并按明确的舍入规则处理。

编号	需求	优先级	验收标准
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 支付状态机

支付单使用以下标准状态：

状态	定义	是否最终状态
待支付	支付单已创建，尚未发往通道	否
支付处理中	通道已受理或结果暂时未知	否
支付成功	通道确认支付成功	是
支付失败	通道明确确认支付失败	是
已关闭	未成功支付已被关闭	是

退款不是支付单状态。退款使用独立退款单和退款状态，支付详情显示累计退款金额。

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 验收主场景

平台创建两个收单渠道，完成适配器测试并标记为“平台已支持”。
平台只向试点客户授权这两个渠道，其他客户不可见、不可用。
创建客户支付应用并完成凭证配置。
为应用配置两个渠道的手续费规则，试算结果正确。
手续费新版本生效后，历史交易仍保留原规则版本和预估金额。
为试点门店向两个已授权收单渠道创建进件申请。
复用企业和门店资料，补充渠道专属资料并提交。
进件被退回后可查看原因、补件并重新提交。
审核通过后自动或人工校验回写两个渠道的商户号。
POS 使用统一接口通过主渠道发起支付并成功。
支付成功时固化应用手续费规则版本和预估手续费。
相同请求重复提交，不产生重复支付。
通道同步响应超时，通过主动查单确认成功。
通道重复回调，平台只处理一次。
业务系统回调失败，平台自动重试并最终成功。
对指定试点门店执行路由试算和备用渠道小额验证。
将指定门店从主渠道灰度切换到备用渠道，新交易正确进入备用渠道并使用备用渠道手续费。
暂停客户的备用渠道授权后，新交易不能进入该渠道。
切换前已创建交易仍通过原渠道完成查询和退款。
支付结果未知时，系统禁止通过备用渠道重新支付。
切换后指标异常时，可回退到上一有效渠道。
总部按业务订单号查询完整交易时间线。
门店只能查询本店交易。
发起全额退款并成功。
发起多次部分退款，累计不超过原支付金额。
并发发起超额退款时，系统可靠拦截。
支付处理中超过时限，系统生成异常并告警。
停用平台渠道后，不允许新增授权或新交易。
修改商户号关系后，历史交易归属不变化。
标准支付、退款和预估手续费成功输出到对账系统。
对账输出失败后自动重试，并可人工补发。
越权用户无法查看其他客户、门店或进件资料。
密钥、证书、进件证照和敏感数据不在页面及日志中明文暴露。
发生版本故障时，可以按预案回退且不丢失交易。

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 停止或回退条件

出现以下任一情况，应停止扩店并根据预案回退：

发生平台原因导致的重复扣款或错误退款。
支付金额、币种或商户号路由错误。
大量交易状态无法确认。
核心接口持续不可用并超过约定时间。
数据跨客户泄露或严重越权。
密钥、证书或敏感支付数据泄露。
资金链路存在合规问题。
支付流水大面积缺失且无法补回。

回退后必须保留全部已发生交易和事件记录，不得通过删除数据掩盖问题。

68 KiB Raw Blame History Unescape Escape

PRD：适用于连锁企业的聚合支付平台

变更记录

1. 摘要

2. 联系人

3. 背景

3.1 当前情况

3.2 为什么现在建设

3.3 产品原则

3.4 产品边界

3.4.1 本产品负责

3.4.2 本产品不负责

3.5 系统关系

4. 目标

4.1 产品目标

4.2 客户收益

4.3 公司收益

4.4 战略一致性

4.5 目标和关键结果

O1：证明统一支付链路可以稳定承载试点门店交易

O2：证明平台能降低接入和运营成本

O3：证明支付数据可以直接支持对账

4.6 非目标

5. 市场细分

5.1 首要市场：已有业务系统的中大型连锁企业

需要完成的工作

典型特征

首期优先行业

后续可扩展行业

5.2 次要市场：为连锁企业提供软件的服务商

需要完成的工作

约束

5.3 后续市场：平台型交易企业

需要完成的工作

约束

5.4 核心用户角色

5.5 首版约束

6. 价值主张

6.1 总部支付运营

需要完成的工作

获得的价值

避免的痛点

6.2 门店店员和店长

需要完成的工作

获得的价值

避免的痛点

6.3 IT 和业务系统开发人员

需要完成的工作

获得的价值

避免的痛点

6.4 财务和对账人员

需要完成的工作

获得的价值

避免的痛点

6.5 相对竞品的差异

7. 解决方案

7.1 用户体验与流程

7.1.1 信息架构

7.1.2 新客户开通流程

7.1.3 支付主流程

7.1.4 支付状态未知处理流程

7.1.5 退款流程

7.1.6 异常处理流程

7.1.7 交易详情页面草图

7.1.8 门店进件流程

7.1.9 收单渠道切换流程

7.2 核心功能

7.2.1 功能优先级定义

7.2.2 支付应用管理

7.2.2.1 客户应用收单手续费

7.2.3 平台收单渠道与客户授权

7.2.4 支付商户号管理

7.2.5 门店支付进件

7.2.6 门店与终端支付配置

7.2.7 支付路由与收单渠道切换

7.2.8 统一支付接口

7.2.9 支付订单与支付流水

7.2.10 支付状态机

7.2.11 异步通知与主动查单

7.2.12 退款管理

68 KiB

Raw Blame History