一个通知通过签名校验，不代表金额、订单和状态都可以直接写入本地。
本文使用Java 7 与支持事务、唯一约束的关系数据库，代码为设计伪代码。支付系统同时面对用户请求、外部通道和本地账务，三者不共享一个事务。网络异常下必须保留“不确定”状态，并用查询、流水和对账逐步消除差异。
1. 从现象推到机制
签名证明报文来自持有密钥的一方，并保护约定字段的完整性。还要核对商户身份、订单归属、币种、金额与通道流水。签名字段排序、空值和字符编码必须遵循协议，不能自行用字符串拼接猜规则。
图中的四个节点分别表示原始报文、签名验证、业务核对、幂等更新。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
保留原始请求字节供协议解析，先验证再做状态迁移。这里只表达处理顺序，不提供任何真实通道密钥。
1
2
3
4
5
raw = read_request_bytes()
notice = parse_by_channel_protocol(raw)
verify_signature(notice)
check_order_amount_currency(notice)
apply_idempotent_state_transition(notice)
示例使用虚构订单和金额，不能连接真实支付通道。实现时需要替换数据库访问与验签适配，并明确事务提交点；外部接口的签名字段和响应约定以通道协议为准。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 签名正确但金额不符 | 拒绝更新并记录差异 |
| 重复发送同一通知 | 保持同一笔到账结果 |
| 修改签名覆盖字段 | 验签必须失败 |
对照 1：签名正确但金额不符
拒绝更新并记录差异。观察时记录订单原始应付值与通知金额。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：重复发送同一通知
保持同一笔到账结果。观察时记录通道流水唯一性。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：修改签名覆盖字段
验签必须失败。观察时记录规范化前后的真实待签名内容。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
签名不会自动阻止重放。通知消费还要依赖业务流水去重、状态机与协议允许的时间约束，处理日志也不能泄露密钥和完整支付凭据。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“修改签名覆盖字段”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
