支付回调中的疑问？

先说结论：不需要

再说细节：

1. 程序设计时交易流程应和支付流程彼此独立，一般交易流程依赖支付流程，但没有反向依赖关系；
2. 交易流程可调用支付流程，生成支付单据；
3. 支付过程应有主动触发查询支付状态的方案，比如定时或其他逻辑触发；
4. 支付平台回调只是主动触发的时效优化方案，但主动触发方案不可缺失；
5. 交易流程应关注与其关联的支付数据状态来控制交易流程。

同步和异步通知地址不需要检测用户的支付结果，只负责处理用户支付后的业务逻辑，订单插入等。通知地址的参数都是要签名验证的，不必要担心

你只要校验签名就可以了 签名的校验可以保证消息的准确的

第一个疑问：1. 对回调的来源不信任，密钥签名就是做这个的 2. 支付状态，回调中都会携带状态信息，如微信return_code result_code均为 SUCCESS代表支付成功。3. 前1、2点，基本上没必要去 “订单查询 api 看下订单有没有支付成功”，但不是没特殊情况（百度收银台的开发中遇到了，一两句说不明白）

第二个疑问：回调业务逻辑中，返回给支付平台的 处理结果，要与业务执行结果一致，也就是说，1.业务逻辑处理成功了则返回成功，不可以不返回或不按规定格式返回，否则会一直回调；2. 发生重复回调的情况，避免重复执行业务逻辑，如查询数据库订单状态为已支付，可以直接忽略这次回调即可，或返回处理成功告知已收到回调并且完成了业务逻辑，则不会再回调了。3. 避免业务逻辑未完成，如数据错误但没有使用mysql事务，但程序最终返回了处理成功。

第一个问题：回调可做可不做，常见支付平台本身就会使用轮询的方式对服务器进行回调，自己可以按照时效性或者平台需求做队列

第二个问题：回调的数据是一致性的，支付状态本身就已经是幂等性的一种设计，只有在订单状态为 发生变化 状态才会触发 回调事务,已支付 以及 取消订单 都不会进行任何操作

支付回调需要放入队列吗？

1. 一般情况下不需要主动查单 回调时会有是否成功
2. 幂等性肯定是要做的 因为你的回调不一定只有修改订单状态， 比如我们的支付回调会有修改订单状态，发优惠券，发放积分，修改余额（线上充值）之内的操作 肯定是需要判断订单是否已经修改过支付成功的