我终于开始鼓起勇气写支付下单接口，一直不敢触碰，因为这个接口算的上是整个系统里面，最复杂最需要严谨的那个，毕竟和金钱相关，没有足够的知识准备，没有能力去写，写出来也是经不起高并发、异常的考验的，可能平时状态下没什么问题罢了，我是对自己这样要求的。

所以我不断的去找资源学习，发现每个老师都有自己的处理方案，其实我一直想寻求一套统一的公式。废话不多说，进入正文。

Native支付举例：比如下单接口第一步校验幂等性，防止重复下单（这一步可以用lua脚本或者其他token机制，我只知道lua脚本搭配redis），第二步校验通过，创建订单数据（根据前端传过来的商品id去数据库查询对应的金额、商品描述、利用雪花算法生成订单号、订单状态设置为‘待支付’、设置回调通知地址等等），第三步请求官方下单接口，如果请求成功则返回二维码，至此下单这一步完成。接下来是notify_url回调的处理，这一步给的感觉就是很严谨，比下单还严谨，我说一下。首先获取返回的响应体，解析，验签，校验金额。验签失败则抛出异常，否则继续，接下来响应码不是Success则抛出异常，否则继续。好，都无误，先加锁，然后查询订单状态是否被处理，没有改为‘已支付’则修改订单状态（先查一下，再做处理其实是考虑到了微信可能会发多次通知），然后响应给微信SUCCESS字符串或者XML。

至此！一套支付完成。

接下来，我提几点疑问，其实上面所说的，也只不过是我照着老师的代码翻译的意思罢了。

这又不是并发级别的，第一次15s,第二次15s...真的搞不懂，难道还有其他情况会重复通知，而且还是并发级别的？

5.先本地生成订单、调用下单接口还是先调用下单接口，再生成本地订单，听有些博客说，如果是后者，那么如果数据库写入慢一点的话，但是notify已经回来了，然后查看订单是否支付的时候，会查询不到，你可以想象一下这个过程，是否存在这种可能？

好了，差不多就这么多了，对了还有个JsApi的支付，听说即使下单之后回调的结果是‘requestPayment:ok’也可能会失败，严谨的是再查单一次，是吗？

提了很多问题， 这些问题都是日思夜想的问题，无奈身边没有大神，希望有懂的兄弟可以回答一下，感激不尽，谢谢！