更多分享请关注我的公众号
三、回调的安全问题
1）为了防止回调接口的安全，第三方通常会有密钥
2）但可能由于密钥的泄露或有人伪造我们的回调参数调用我们商户的回调接口，我们可以在接收到第三方回调请求后，再次请求第三方查询接口，也就是不要依赖第三方的回调参数，我们只是依赖第三方回调的实时性，因为第三方通常在真正完成支付业务后会立即回调告诉我们结果，所以我们需要接受第三方的回调请求，但我们不要依赖它的参数，我们需要再次根据第三方的查询接口来查询它到底是否支付成功
四、如何防止重复支付
由于用户的习惯或者支付的网络问题等，可能会导致用户对同一个订单发起支付，所以这里就需要注意，在支付时给第三方传入参数时，需要保证对同一个订单每次只能有一个待支付的支付记录，且保证每次支付记录的交易流水号唯一
五、如何防止重复生成订单
同上面的原因，可能会导致用户生成重复订单，我们可以在用户初始化订单信息的最后一个页面时，服务端生成一个全局的唯一值传给前端，当用户重复点击生成订单时，我们就可以根据这个全局唯一值来判断是否是同一个订单，当然这里用户如果是重新填写订单信息的话，这种情况我们就不作为用户是重复生成订单，而是用户本身就想下两次订单。
六、如何防止并发产生的数据问题
上面说的一些方案都是从架构或策略上面入手处理重复提交问题，现在我们还要考虑并发的情况下，其实也不一定是并发，比如第三方通常会有重复回调，或者我们自己做了补偿重发，这里就要考虑幂等性问题，通常是用业务唯一值的校验、分布式锁的锁定即比如每个用户每次只能进行一次该操作、乐观锁、悲观锁等
七、我们还要非常熟悉业务
需要对业务做一些校验，还要对支付数据做校验，比如支付金额，虽然是该笔订单号，但金额是不是相同的等
八、敏感信息尽量不要返回给前端
我们在开发接口的时候，单独开发支付功能一般会主动注意安全问题，但有的没有直接涉及到支付，而是普通的查询支付信息返回给前端，这时可能反而没有意识到安全，其实也要提高警惕，不要把敏感信息返回给前端了，不然让外人用户知道同样对系统安全威胁非常大。
总结，其实以上问题的处理方案总的来说就是如下：
1）主动查询第三方支付记录
2）幂等性
3）全局唯一值
4）业务，另外，再比如微信支付涉及到公众号支付，为了与公众号其他功能开发安全级别分开，可以开通多个公众号来独立区分支付公众号账号。
其实还可以
5）添加对账功能
6）风控
当然安全管理，如密钥的管理是基本，这个没什么好说的。
更多分享请关注我的公众号