系统、数据与权限：支付状态、账务和资金三条链一致

10.1 参考架构

01支付基础设施以API

02支付交换

03风险

04账本

05清算

正在绘制业务流程…

10.2 支付状态与账务状态分开

支付状态表达业务过程，账务状态表达金额是否预记、记账、冻结、释放、冲正或结算。上游返回成功但账本失败是重大异常；账本已预记但上游未知需要保留并查询。不能用一个status=success同时控制前端、商户结算和总账。

支付状态	账务状态	允许动作	禁止动作
Created	None	风控、取消未发送请求	商户结算
Processing	Reserved/Pending	查询、等待异步回执	盲重试新扣款
Unknown	Pending	查询、对账、客户显示处理中	标失败并再次扣款
Succeeded	Posted	进入清算/退款	删除原记录
Settled	Settled	对账、争议	无原交易退款
Refunded	Reversed/Refunded	客户确认与关单	再次全额退款

10.3 双式账本和守恒

每个金融事件至少产生平衡分录，账户余额来自已批准分录聚合而非直接覆盖。账户类型包括用户余额、待结算、商户应付、退款应付、在途、差错、服务费应收/收入和外部清算。分录包含事件ID、借贷账户、金额币种、业务时间、账务时间、来源、状态和反向关联。

正在绘制业务流程…

10.4 幂等设计

幂等键的作用域要包含商户、业务类型和业务意图，不能全局只用订单号，也不能每次重试生成新键。API入口、支付编排、上游请求、账本、通知、退款和清算文件各有幂等，但必须共享原始业务关联。缓存过期不能让旧重试产生新扣款；跨机房切换后幂等记录仍可用。

10.5 四方对账引擎

四方是内部支付事件、内部账本、银行/清算外部记录和商户结算/总账。文件层校验来源、日期、记录数、金额和哈希；记录层用稳定ID匹配；业务层判断状态、金额、主体、币种、费用和价值日。对账差异有风险优先级和到期日，不能永远挂“在途”。

规则ID	校验	失败动作
DQ-J06-01	每个有效支付意图最多一个有效扣款事件	冻结相同幂等范围
DQ-J06-02	所有账务事件借贷相等	阻断账本提交
DQ-J06-03	客户资金期初+流入-流出=期末	阻断日结/结算
DQ-J06-04	商户应付=成功清算-费用-退款/调整	暂停商户批次
DQ-J06-05	外部成功=内部成功+已解释差异	建差错并查询
DQ-J06-06	银行价值日金额=资金账±合法在途	资金升级
DQ-J06-07	服务费收入=唯一可计费事件×有效费率	阻断收入关账
DQ-J06-08	同文件哈希只处理一次	拒绝重复批次
DQ-J06-09	商户结算账户变更均有原渠道回拨	暂停支付
DQ-J06-10	监管汇总可下钻到源事件	阻断报送

10.6 密钥、证书和敏感凭证

支付密钥不出安全域，生成、导入、轮换、备份、启用、吊销和销毁均双控。应用只取得用途受限的密钥句柄，运维不能查看明文。银行卡、银行账户、身份证、生物特征和认证因子按最小化处理；下游尽量使用令牌。日志不得记录完整敏感凭证，排障也不例外。

10.7 权限矩阵

操作	产品	运营	账务	资金	风控/AML	技术/运维
发布费率	提议	C	验证	-	C	受控执行
改路由	C	发起	C	C	C	执行
调商户限额	C	C	-	-	批准/建议	不得业务批准
发起商户结算	-	C	生成依据	发起	监控	不得发起
批准资金支付	-	-	-	独立双签	-	不得批准
修改账务	-	-	受控冲正	C	-	不得直接SQL改余额
提交可疑报告	-	-	提供数据	-	授权AML	仅技术传输
删除审计日志	禁止	禁止	禁止	禁止	禁止	禁止，只能按政策归档

10.8 数据、隐私与跨境

【可核验事实｜中国大陆】个人信息保护、数据安全和网络数据处理分别受相关法律法规约束；支付机构还应结合支付监管、反洗钱和网络安全规则。[SRC-NPC-PIPL-2021][SRC-NPC-DATA-SECURITY-LAW-2021][SRC-SC-NETWORK-DATA-REGULATION-2024] 项目建立字段级清单：目的、法律基础、敏感性、来源、使用者、存储地、共享方、期限、删除和出境路径。

跨境风控不能默认把全部支付明细、身份材料、设备图谱和生物信息复制到海外。可比较本地闭环、去标识聚合、受控远程访问和正式出境四种架构，并从合法性、模型效果、延迟、成本、监管访问和退出能力权衡。

10.9 灾备与业务复演

灾备测试必须重放成功、失败、未知、重复、乱序、退款、清算文件重传和跨日结算；恢复后比较支付状态、账本、客户资金、商户应付、银行、总账和客户查询。RTO达成但多扣一笔钱，演练仍失败。

01主支付机房故障后团队切换到备用小镇

02并逐笔重放

03对账和核验客户资金后才恢复商户结算

10.10 稳定标识与最小数据模型

一笔业务至少有商户订单号、支付机构支付ID、幂等键、上游请求号、清算参考号、账务事件ID、结算批次号和退款ID。它们不是可互换的“流水号”：订单号表达商业意图，支付ID表达一次支付生命周期，幂等键防止相同意图重复生效，上游号用于通道查询，清算号证明价值交换，账务事件记录不可变金融影响，结算批次汇总商户应付。数据模型应保存映射关系，而不是把最后收到的号覆盖到同一字段。

主数据同样需要版本。商户主体、受益所有人、结算账户、合同、产品、费率、渠道和风险策略发生变化时，旧交易仍应指向当时生效版本。用当前费率回算历史交易会造成收入与商户账单漂移；用当前商户风险等级解释历史处置会破坏审计。版本记录至少包含生效与失效时间、批准人、变更原因和证据摘要。

实体	必要主键	关键版本/状态	禁止做法
商户	merchant_id	主体、场景、KYB、账户	用店铺昵称作唯一键
支付	payment_id	意图、授权、执行、终态	以订单号代替支付ID
账务事件	ledger_event_id	分录版本、冲正关联	更新删除原分录
清算	clearing_ref	价值日、对手方、结果	只留Excel行号
结算	settlement_batch_id	应付、扣费、放款、退回	手工改总额不留明细
定价	price_version_id	费项、阶梯、有效期	覆盖历史费率

10.11 消息投递：至少一次传输与业务恰好一次生效

分布式系统很难承诺每条网络消息只到一次，因此工程目标是允许消息重复到达，却只让业务影响生效一次。请求侧用幂等键和唯一约束；数据库事务中同时写业务状态和待发送事件；发送器重复投递直到收到确认；消费侧用事件ID去重并保证处理与收件记录同事务；失败进入可观测重试或死信队列。任何自动重试都设置次数、退避和总时限，超过阈值转人工处置。

通知商户失败不等于支付失败。商户查询接口、异步通知和对账文件应返回同一权威状态语义；若通知多次，商户也应按支付ID幂等处理。系统切换、消息积压或数据库回滚后，要用业务不变量验证：客户只扣一次、商户只形成一笔应收、账本只有一组有效分录、退款累计不超过可退额。仅看HTTP成功率无法证明这些不变量。

10.12 可观测性与审计轨迹

日志回答程序做了什么，业务事件回答钱发生了什么，审计轨迹回答谁基于什么权限做了什么决定。三者应通过支付ID、商户ID、案件ID和变更ID关联，但权限和留存策略不同。日志不得明文打印完整身份证件、银行卡敏感信息、密钥或认证要素；分析平台使用脱敏或令牌化数据；高敏查询记录目的、工单和查看人。

监控分四层：基础设施看容量和依赖；应用看延迟、错误和队列；业务看成功、未知、退款和结算；资金账务看不平、重复、负余额和超期未匹配。告警要关联行动手册、当班负责人、升级阈值和业务影响，不以海量无人处理的消息制造安全感。重大事故时间线统一使用可信时钟，保留原始证据，复盘区分触发因素、放大因素和根因。

10.13 规则模型与人工决策治理

反欺诈模型给出概率或分值，不直接等于事实结论。上线前定义目标、样本窗口、标签来源、误杀成本、群体影响、降级方案和批准人；上线后监控数据漂移、命中稳定性、绕过方式、人工推翻率和投诉。训练数据与生产特征要有合法来源和用途边界，敏感个人信息采取更严格控制。模型版本、特征版本、阈值和处置动作必须可追溯。

人工审核不是无规则自由裁量。审核台展示必要证据、允许的结论、理由码和复核路径；高风险限制或大额处置实行双人或分级批准。模型不可用时按事先批准的安全策略降级，例如缩小额度、加强认证或转人工，而不是默认全部放行或全部拒绝。模型供应商只提供能力，支付机构仍要对使用场景、客户影响和持续监督负责。

10.14 外包、云和退出计划

接入云、短信、身份核验、反欺诈、渠道或运维供应商前，业务负责人说明必要性，架构和安全评估数据、权限、可用性及集中度，合规判断监管与跨境要求，采购和法务固化服务水平、审计权、事件通知、分包限制、数据返还删除和退出条款。合同签完不是风险结束，运行期继续监控性能、事件、财务健康和重大变更。

退出计划要能执行：资产与数据清单完整，可导出格式经过验证；替代供应商或自建能力有容量；密钥和网络切换步骤明确；历史证据、账务和客户申诉仍可查询；退出后撤销账户、证书和访问权。每年至少桌面演练关键供应商退出，重大依赖做技术演练。若单一供应商故障即可导致客户重复扣款、无法结算或账本不可用，应提升到董事会风险，而不是停留在采购折扣议题。

10.15 灾备切换的业务复演

灾备成功不以“服务器启动”为终点。演练前冻结范围和恢复点目标，备份订单、支付、账务、清算和配置版本；切换时确保双活或主备不会同时对外产生金融效果；切换后抽取成功、失败、处理中、退款、结算和跨日交易，逐笔复演状态、分录、客户资金和通知。切回原中心前再次核对增量事件，防止两个中心各自接受同一幂等键。

演练报告列出丢失或延迟事件、未知状态峰值、对账差额、人工补录、客户影响和恢复时间。人工补录也必须走受控事件和批准流程，禁止直接改数据库。若演练发现目标无法达成，立即更新容量、架构、值班和商户沟通方案，并在整改前限制超出恢复能力的新业务量。