支付业务，测试遇到请求超时怎么处理？查看是否是网络原因；fiddler抓包查看原因；
支付业务流程测试，参考：https://www.jianshu.com/p/9e3f4e66a273
同步用于即时通知支付完成（立即通知）；
异步用于防止信息漏发漏收（稍后通知）；
幂等性，其实就是数据一致性和事务完整性；
数学上的定义：f(f(x))=f(x)。x被函数f作用一次或作用无限次的结果是一样的；
某个函数或者某个接口使用相同参数调用一次或者无限次，其造成的后果是一致的；
在实际应用中一般针对接口进行幂等性设计。例如：
1.前端重复提交选中的数据，后台应该只产生对应本次提交的一个响应结果；
2.用户发起一笔付款请求，应该只扣除用户账号一次钱，即使遇到网络重发或系统bug重发时，也只扣除一次钱；
3.创建业务订单时，一次业务请求只能创建一个订单；
如果相关接口不做幂等性。可能会造成很严重的后果，例如：
1.前端重复提交选中的数据，后台可能产生多个响应结果，数据不能保持一致性；
2.用户发起一笔付款请求，如果遇到网络超时，同一个请求重复发送多次，可能造成用户账号多次扣款；
3.创建业务订单时，一次业务请求可能会产生多个订单；
如何保证幂等性？
幂等性需要通过唯一的业务单号来保证。也就是说相同的业务单号，认为是同一笔业务。使用这个唯一的业务单号来确保，后面多次的相同的业务单号的处理逻辑和执行效果是一致的。
下面以支付为力，在不考虑并发的情况下，实现幂等很简单：1）先查询一下订单是否已经支付过；2）如果已经支付过，则返回支付成功；如果没有支付，进行支付流程，修改订单状态为'已支付'.
防重复提交策略
高并发下会出现下面的情况：第二次请求在第一次请求第2）步订单状态还没有修改为‘已支付状态’的情况下到来。既然得出了这个结论，余下的问题也就变得简单；把查询和变更状态操作加锁，将并行操作改为串行操作；
乐观锁：
如果只是更新已有的数据，没有必要对业务进行加锁，设计表结构时使用乐观锁，一般通过version来做乐观锁，这样既能保证执行效率，又能保证幂等。例如：update tab1 set col1=1，version=version+1 where version=#version#
分布式锁
如redis。订单发起支付请求，支付系统会去redis缓存中查询是否存在该订单号，若存在则给出提示；若不存在，则在redis中增加该订单号，执行结束后（成功/失败），删除该订单号；
参考：https://www.sohu.com/a/239759335_741445