H7.06.3payment unknown state query设计研究
状态未知时需提供查询而非猜测
别名: 支付结果未知 · 查询支付 · payment pending lookup
概念解释
渠道还没回答、本站也不敢标成功或失败时，界面进入未知。正确做法是提供「查询这一笔」：订单号、正在问渠道、结果出来后怎么通知——而不是猜成失败让人再付，或猜成成功去发货。这条是未知态的交互原则。超时在协议上不等于失败、渠道与订单短暂不一致要说「处理中」，是把未知再拆开的后一层。
机制
人不能忍受无标签的等待，会把沉默编码成失败，尤其在钱可能已经划走的时候。若界面顺着这套编码写「失败，请重试」，就在未知上叠了一次新的意图。若写「成功」则可能空单发货。查询把判断权留在系统：对渠道做一次只读询问，界面保持「尚未确定」。人需要的是进度感与出口：刷新结果、去订单详情、拿到号去银行核对，而不是被迫选择相信哪一句文案。
怎么研究
切断异步通知，让前端超时。比较：直接标失败、直接标成功、保持处理中并给查询。
自变量：超时后的标签、是否自动再查、是否仍提供支付按钮。 因变量：重复支付、空单发货、人能否说出「还不确定」。
实验室被试按说明书等，不会像真实用户那样去银行 App。要允许他们离开页面再回来。不要用最终对账正确率单独当指标——过程中已经双扣再退，查询仍然失败了。
边界
查询也有时限，超时后要升级为人工单，而不是永远转圈。人已经从银行侧看到扣款时，界面仍说未知会打架，应提示「以银行记录为准，我们正在对账」。完全离线无法查询时，给出稍后凭号查询的路径，而不是假装有实时结果。已知拒绝不应伪装成未知来拖延。
怎么落地
- 超时或无应答时展示「结果未确认」，提供查询按钮与订单号，隐藏「再付一次」直到查询返回失败。
- 查询是只读；自动轮询要有次数上限和「将通知你」的出口。
- 结果落地后从未知切到成功凭证或可行动失败，不要停在处理中。
- 验证：人为丢掉渠道回调，看页面是否出现查询而不是失败；在查询返回前尝试再付，应被挡住。若文案写成「支付失败」而渠道稍后成功，交互在猜。