05 交易处理、功能场景与争议

05.1 通用交易生命周期

平台应将“请求已接收”“业务已校验”“已授权/签名”“已提交账本”“已最终确认”“失败/拒绝/待恢复”区分为明确状态。调用成功、消息已发送或交易已排序均不等同于账本最终成功。

每笔交易必须有稳定的业务请求标识、幂等键、关联钱包/机构、发起身份、时间、状态、账本交易标识、审计标识和（如适用）RTGS/会计参考号。

05.2 核心场景目录

场景	必要控制点
机构接入与节点启用	机构批准、证书、网络、配置、冒烟和审计
钱包开立、激活、冻结、关闭	身份、权限、状态机、余额处置和留痕
发行与分发	发行授权、签名、账本最终性、会计关联和对账
P2P / P2B / B2B / G2C 转账	付款方授权、收款方可用性、规则/限额、幂等、最终性和通知
批量支付	批次完整性、逐笔状态、部分失败、重试和对账
赎回与销毁	赎回授权、外部结算、账本终结和会计对账
查询、审计与报表	最小权限、数据范围、可追溯和导出审计

本期强制场景由批准 RTM 决定；未纳入的场景不得被默认为已支持。

05.3 业务校验与签名

资金操作在提交前应完成身份、角色、机构归属、钱包状态、余额、规则/限额、风险结果、请求完整性和必要签名校验。当前技术基线包含 Wallet Node、Endorser、Auditor 等职责分离的处理链路；实际所需签名集合和策略必须随业务模型、证书体系和账本参数定版。

05.4 幂等、超时与恢复

发行、转账、赎回、审批和外部回调必须使用幂等标识。重复请求必须返回原结果或明确处理中状态；同一幂等键但不同请求内容必须拒绝。超时后不得盲目重放资金操作，应先依据业务、账本和外部系统状态查询确定恢复路径。

05.5 异常与争议

事件	处理原则
余额不足、规则不满足、无权限	返回稳定业务拒绝码并保留审计
签名/证书问题	拒绝操作；按证书和安全事件流程处置
账本或外部系统超时	标记待确认，查询最终状态后恢复，不直接冲正
账本与业务/会计差异	立即进入对账和事件流程，禁止掩盖差异
客户争议	记录争议编号、证据、权限、时限、裁决和后续业务动作

争议管理不应承诺对已最终确认账本记录“删除”或“改写”。若需纠正业务结果，应通过经授权的补偿、调整或后续交易实现，并保留原始证据链。

05.6 场景规格模板

每个正式业务场景应至少写明：目的、参与方、前置条件、主流程、异常流程、输入/输出、权限和签名、账本与数据变化、外部接口、通知、审计、对账、性能假设、测试用例和验收证据。

05.7 功能验收要求

UAT 不应只验证前端展示。每个核心场景须同时验证业务结果、资金/账本结果、审计记录、异常提示、重复处理、必要的外部系统关联及最终对账。