用户页面显示成功，与服务端确认到账，必须来自不同可信度的证据。
本文使用Java 7 与支持事务、唯一约束的关系数据库，代码为设计伪代码。支付系统同时面对用户请求、外部通道和本地账务，三者不共享一个事务。网络异常下必须保留“不确定”状态，并用查询、流水和对账逐步消除差异。
1. 从现象推到机制
内部订单、支付尝试和通道流水分别建模。一笔订单可能重试多次，但每次通道请求应有独立身份。状态机只允许明确迁移，成功态不能被迟到的失败通知覆盖，超时进入待查询而不是直接认定失败。
图中的四个节点分别表示业务订单、支付尝试、通道证据、状态迁移。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
先列迁移表，再写条件更新，更新条数为零时重新读取当前状态。
1
2
3
UPDATE payment_attempt
SET state = :next_state
WHERE attempt_id = :id AND state = :expected_state;
示例使用虚构订单和金额，不能连接真实支付通道。实现时需要替换数据库访问与验签适配，并明确事务提交点；外部接口的签名字段和响应约定以通道协议为准。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 同步返回超时 | 保留待查询状态 |
| 成功后收到失败通知 | 不得回退已确认的成功态 |
| 同订单发起第二次尝试 | 尝试身份不同但仍关联同订单 |
对照 1：同步返回超时
保留待查询状态。观察时记录本地记录与通道实际结果。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：成功后收到失败通知
不得回退已确认的成功态。观察时记录状态迁移条件与版本。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：同订单发起第二次尝试
尝试身份不同但仍关联同订单。观察时记录订单与支付尝试的数量关系。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
页面跳转只能作为用户体验入口。是否到账需要经过服务端协议验证和账务核对，不能由前端传来的金额或状态决定。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“同订单发起第二次尝试”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
