从市场验证到稳定复制

3.1 从客户问题而非“支付功能”开始

客户通常不缺一个“付款按钮”，而是缺少更高转化、更少拒付、更快结算、全渠道对账、跨境本地化、资金可视、合规商户接入或稳定灾备。需求访谈要还原客户当前订单、支付方式、失败原因、资金周期、人工对账、退款争议和监管责任。若客户真正需要的是违规套现、二清、隐藏交易背景或绕过外汇，则无论收入多高都不能进入产品路线图。

客户痛点	可验证基线	产品假设	成功证据
支付成功率低	分通道、错误码、客群和时段	智能路由可改善非风险型失败	成功率升且欺诈/成本不恶化
商户结算慢	清算日历、差错和银行价值日	自动对账缩短合法在途	到账时长下降、未明款不升
人工对账多	文件数、匹配率、工时、错账	稳定ID和规则引擎自动匹配	自动匹配率、重开率和关闭时长
退款投诉高	原因、产品、商户、时长	退款状态机和客户通知改善	重复退款为零、投诉下降
跨境复杂	国家、币种、订单和服务商	本地许可伙伴与统一编排	每条路由许可、资金、数据均可证

3.2 十一道从零到一闸门

01支付创业团队依次通过需求

02许可

03客户资金

04商户

05路由

闸门	必备产出	唯一A	硬阻断
需求与合法性	场景、客户、交易背景、禁止用途	业务负责人	需求实质违法或规避监管
主体与许可	主体—业务类型—地域矩阵	法务合规负责人	无相应许可或不可外包核心职责
产品合同	服务、费用、责任、退款、退出	产品负责人	资金与责任写不清
客户资金	账户、备付金、待结算与自有资金设计	资金负责人	客户资金可被自有账户调用
用户商户	KYC/KYB、受益所有人、行业和网站/门店	合规负责人	无法核实或高风险不可控制
路由清算	参与者、许可、消息、日历和最终性	支付运营负责人	非法直连、二清或单点无替代
账本对账	事件模型、双式账、幂等与四方对账	账务负责人	任一场景不能守恒
风控AML	认证、交易监测、案件、报告与申诉	风险负责人	模型直接替代法定判断
系统安全	容量、密钥、权限、灾备、数据	技术负责人	峰值或恢复测试失败
财务税务	收入成本、发票、结算和现金桥	财务负责人	客户资金被计收入
首单与放量	端到端演练、限量、监控、回滚	总经理/经营负责人	P0未清或责任人缺席

3.3 首单不是支付成功页

首单从商户合同和费率版本开始，经过商户状态、终端/接口、用户授权、支付指令、风控、路由、扣款/授权、业务账、客户资金账、清算、商户结算、服务费、发票凭证、银行对账和客户查询。至少演练成功、余额不足、超时未知、重复请求、风控拒绝、上游成功下游超时、退款、冲正、跨日、清算文件重复和商户账户变更。

3.4 容量不是TPS单指标

容量	测什么	通过标准
接口容量	峰值、突发和长尾延迟	无丢单，超时状态可查询
账本容量	同账户并发、热点和批量入账	守恒、顺序和幂等正确
风控容量	规则、模型、名单和人工队列	不因降级放开高风险
清算容量	大文件、重传、跨日和节假日	控制总额、哈希和状态正确
客服容量	查询、退款、争议和事故	用户获得一致状态和时限
资金容量	峰值头寸、结算、退款和差错	客户资金完整，自有流动性够用

3.5 放量采用“双钥匙”

业务钥匙确认需求、商户质量、服务能力和单位经济；风险钥匙确认许可、客户资金、欺诈AML、系统、数据和连续性。两把钥匙都通过才扩大金额、商户、渠道或地区。增长目标不能覆盖风险阻断，风险部门也不能只说“不行”而不给具体缺口、证据和可行替代。

3.6 经验回路

正在绘制业务流程…

指标变化必须区分产品改进、客群变化、上游波动、规则放松和统计口径变更。成功率提高但拒付、欺诈或成本恶化，未必创造价值；风控拦截率提高但误伤真实客户，也未必控制更好。

3.7 商业计划的五张底表

第一张是场景底表，列每种商品服务、付款人、商户、金额、频率、退款与争议。第二张是许可底表，把每个活动映射到具体法人、业务类型、地域和合作资格。第三张是资金底表，从付款工具、客户资金账户、清算到商户结算逐节点写账户所有人和价值日。第四张是系统底表，列请求、状态、账本、清算、对账、密钥、数据和灾备。第五张是经济底表，把成功交易、费率、通道、渠道、损失、客服和固定成本连接。五表使用同一产品、商户、路由和地区ID；任一表缺行都不能由其他表的“原则说明”补齐。

底表	最小粒度	核心恒等式	所有者
场景	产品×商户类型×支付方式	交易状态总数守恒	产品
许可	法人×活动×地域	所有生产活动有有效依据	合规
资金	账户×币种×价值日	期初+流入-流出=期末	资金
系统	事件×版本×环境	一意图一有效金融结果	技术/账务
经济	可计费事件×费率×成本	收入-成本=贡献	财务/产品

3.8 从概念验证到受控生产

概念验证只能使用脱敏或合成数据，不连接真实客户资金。沙箱验证协议、错误码、签名和状态机；集成环境验证银行/网络模拟器、账本和清算；预生产验证与生产等价的容量、权限和灾备；生产首单采用小金额、白名单商户、双人值守和实时对账。任何团队以“真实交易才能测”跳过隔离环境，都应先设计可控试点和回滚，而不是让客户承担测试风险。

3.9 商户迁移

收购、系统替换或牌照分类迁移不是把商户表复制过去。逐商户确认合同主体、许可业务、结算账户、受益所有人、费率、终端/密钥、退款未决、保证或风险安排、投诉和历史数据。旧新系统并行时只有一个权威结算源；双写用于核对，不能双结算。迁移批次先做零金额配置验证，再做限量交易和T+日对账，最后关闭旧密钥并留查询档案。

迁移对象	验收	回滚条件
合同与许可	新主体服务有合法有效依据	主体或地域不一致
商户主数据	法人、账户、受益人和状态一致	任一高风险字段缺失
费率	新旧样本逐笔复算一致	费率或税务差异
交易	状态、幂等和上游ID可追溯	重复/丢失/未知失控
资金	客户资金和商户应付守恒	任何未解释资金差
未决业务	退款、争议、投诉有唯一归属	两边均无人负责

3.10 定价试验不能拿客户资金做实验

费率试验在合同允许和客户充分知情的范围内，对明确商户样本采用版本化价格；试验分配保存原因和期间，计费引擎可复演。不得在前端随机展示不同手续费但结算按另一规则，也不得通过延迟商户结算获得隐性收益。价格评估同时看转化、交易质量、路由成本、客服、退款拒付和长期留存。

3.11 退出比上线更难

产品或地区退出要停止新增、通知用户商户、处理余额和待结算、完成退款争议、清理路由与密钥、迁移档案、关闭外包访问、保存法定记录并处理许可证/报告。应用下架不能终止支付义务；合同终止也不能删除用户查询和申诉入口。退出负责人每日核对客户资金、未决交易、商户应付和投诉，全部为零或有合法承接人后才关闭。

3.12 稳定复制的经营例会

每日运营会看未知状态、客户资金差异、商户结算、通道、攻击和投诉；每周产品风险会看商户结构、成功/成本、欺诈误杀、退款拒付和变更；每月经营会看收入、毛利、自有现金、固定成本、许可和关键供应商；每季董事会看风险偏好、客户资金、AML、系统连续性、审计和恢复能力。会议结论进入行动台账，不以PPT结论替代生产规则变更。