背景：以前遇到了这个问题，在论坛里面发了贴询问无果（https://developers.weixin.qq.com/community/develop/doc/000080c0f081602d03799575556000?jumpto=reply&parent_commentid=0000a894b90d606d04794aaf7528&commentid=0006a04b984ff81b0baa46b45564）

后面发现问题原因，稳定重现了，然后觉得有点奇怪发了这个贴（https://developers.weixin.qq.com/community/develop/doc/00026c4896090813ba3a02c6151c00?_at=1598930191922），依然无果。

（懒得排版，将就看吧）

问题的表现，上面的链接已经详细说了。我们正常的下单支付过程是这样的：下单-唤起支付-支付成功；唤起支付时调微信api，会传一些参数，比如expire（过期时间），这个时间是针对单号来说的，那么这个过期时间是什么时候开始算的呢？做个测试：

 1、猜想是不是唤起支付时，调微信支付api就开始计时了？
 测试：下单-唤起支付-取消支付-隔expire时间（我设置了5min）-再次唤起支付-支付成功

 结论：说明并不是唤起支付时开始计时

2、才想是不是唤起支付后，输入密码才开始计时？（确实是这样）
测试：下单-唤起支付-输入错误密码-取消支付-隔expire时间（我设置了5min）-再次唤起支付-重现支付失败问题

 结论：就是这货

稳定重现后简单来说下解决思路吧，虽然我觉得输入错误密码开始计时这种实现也许可能稍微有点问题，但既然这条路没得走，那就业务方自己处理吧：

总的来说问题原因在于输入错误密码后，微信方就记录了此单单号，然后expire时间过后，再次调支付api支付，微信方发现超时了，所以返回支付失败。

那么解决的思路也简单：

1、延长expire，根据你的情况来设置（治标不治本）

2、更改系统生成单号的策略

这里只说第二种思路，给个策略大家参考下

旧实现（有问题）：系统的订单单号固定（比如1234，订单id），组装发送给微信的单号也是由系统单号或者通过一定策略生成的（比如haha-1234），这种实现的问题在于只要是同一个系统订单，那么它的微信单号就不会变，那遇到上面的问题时自然也没啥好办法了。

新实现：

条件：假设设置了expire时间为2小时

1、系统单号依然固定

2、系统新增支付单实体，自增id

3、第一次唤起支付前（调微信支付api前），添加支付单。

4、唤起支付时把支付单的id（或者你要加其它策略也行，反正基于支付单id）作为发给微信的单号

5、如果是第二次唤起支付，那就从库里面找到对应订单的支付单，如果发现支付单是2小时之前的，则废弃该支付单。重新生成新的单。如果是2小时内的就复用这个支付单，无需再添加。（2小时跟expire的时间对应）

last，新实现以唤起支付时为基准点去处理过期的问题，虽然最完美的应该是以输入支付密码后点确认的那个时刻，但没办法，那一步是微信baba的，不是我们业务方能监听到的。