H7.13.1payment timeout not failure设计研究
网络超时不等于支付失败，需要先查询结果再决定下一步
别名: 支付超时 · 超时查询 · timeout is not decline
概念解释
前端等渠道应答的时钟先响了，只说明本页没等到回包，不说明渠道拒绝或没扣款。超时 ≠ 失败：下一步是带着意图号去查询，查到成功就出凭证，查到拒绝再按失败处理，查不到就保持未知。它把「未知时不要猜」落到超时这一种具体触发，不管失败文案怎么写，也不管库存怎么释放。
机制
超时是本地或网关的等待上限，与渠道记账不是同一事件。慢网、回调迟到、用户切到后台，都会让页先放弃，而授权可能已经成功。把超时画成红字失败，人会立刻再付，双扣就从这里开始。查询是对渠道的只读问询，用的是刚才那一笔的意图号，不应新开意图。人需要看见「超时了，正在问结果」，而不是「失败请重试」这种把超时翻译成拒绝的句子。
怎么研究
在渠道已接受但回调晚于前端超时的条件下，比较：超时即失败并可再付、超时后强制查询、超时后保持转圈直到回调。
自变量：超时阈值、超时后是否禁止新意图、查询重试次数。 因变量：双授权、空失败（其实已成功）、人能否说出「还不知道」。
实验室用 mock 延迟最干净。真实网络抖动要打日志区分「前端超时」与「渠道拒绝码」。不要把最终对账当唯一指标——过程中已经出现过失败文案，就是把超时当成了失败。
边界
查询本身也有时限，多次无应答要升级人工，不能把超时页变成永久查询。渠道明确返回超时类码且声明未记账，才可以按失败给换方式。离线时无法查询，应保存意图号，恢复网络后再查，而不是离线时允许再付。
怎么落地
- 前端超时进入「结果未确认 + 查询」，支付按钮不可用，直到查询返回拒绝或人工接管。
- 查询使用原意图号；页面展示订单号供人去银行对照。
- 查询成功则直接切到确认凭证，不要经过失败页。
- 验证：让渠道成功但延迟回调超过页面超时，看界面是否查询而非失败；在查询返回前连点支付，渠道侧仍应只有一笔授权。