以前写过一篇如何对接第三方支付的文章如何高效对接第三方支付，因为对接的大多数是海外支付公司，这些公司有很多神奇的问题，往往会埋坑，所以开发之前，整理出问题列表，以便尽早发现和解除问题，保证按时上线。
问题如下
1. 支付
a. 同一个订单号，支付成功之前，是否可以使用该订单号重复发起支付请求
b. 同一个订单号是否能够保障只能被成功支付一次
c. 支付过程是否有其他限制，导致支付失败？比如：地区、ip等
d. 是否支持请求时设置同步/异步通知的url地址
e. 第三方需要支持请求时设置订单过期时间
f. 请求支付的数据是否需要签名，签名规则是什么，如果没有如何防止数据不被篡改？
g.能否提供用户测试的信用卡或者储蓄卡等
2. 同步/异步通知
a. 同步通知的结果是否可信？是否需要同步通知到达时查询一次支付结果以查询结果为准
b. 查询的交易状态与交易的实际状态是否有时间延迟（如：用户支付后，我方立即查询是否会得到一致的结果）
c. 异步通知策略，通知的时间间隔，通知的次数，触发异步通知的条件
d. 通知数据中是否包含交易号，即第三方系统内的一笔交易的唯一标示，以及通知的种类标示字段（交易成功通知/退款成功通知/其它通知）
e. 针对异步/同步通知如何判断支付成功，是否有pending状态（可发货出库的状态）
f. 同步/异步请求的方式是GET/POST哪种方式，传输数据的方式是json/xml/formdata
g. 异步/同步返回的数据是否有签名，如何进行验证？如果没有如何保证数据是安全未篡改的？
h. 是否有风控流程？时间间隔多久？超过间隔时间为收到成功或失败的通知导致发货后的损失怎么解决？
i. 哪个状态可以认为真正支付成功了？
j. 处理失败是否会阻塞
3. 查询
a. 是否支持订单状态查询，通过我们的订单号或第三方的交易流水号
b. 是否支持退款单状态的查询，如果不支持，如何检查之前退款是否成功，主要用来检测是否会重复退款
c. 支付订单的查询与退款订单的查询是否是孤立的？比如：支付单如果支付成功，无论该订单是否退款，查询的状态都是支付成功，而退款状态需要通过其他接口获取
d. 接口是否有签名相关安全措施，如果没有如何保障安全
e. 查询的金额不会因为交易状态的变更而发生变化
4. 退款
a. 是否支持部分退款，退款接口是否包含唯一退款单号标示，对于同一退款单号第三方要保证不超退不重复退。退款是否为幂等操作。
b. 退款接口，直接调用退款接口即可，还是调用退款接口后还有异步通知
c. 需原路退款，确认退款时效和退款期限
d. 退款是否有任何限制？比如某种支付渠道需要支付后多少时间后才可退款，某种渠道不支持部分退等，部分退款有无次数、频率限制。
e. 退款必须只能由小米商城通过接口或者在其后台手工操作，不能由用户申请而直接进行退款
f. 如果在第三方的退款金额不足，第三方如何处理？理论上应该资金充足时自动重试
g. 如果是卡支付，用户是否能够直接向银行申请退款，如果可以，这部分流程如何处理？
5. 对账/结算
a. T+1日获取第三方前一日的完整交易记录，提供api还是ftp
b. 是否提供结算单明细：每一笔结算给mi.com的资金，由哪些交易构成的明细，以及第三方每一笔收的手续费、产生的费率等。
c. 对账单的数据在交易产生后，每个字段值不应该发生变化，比如：某笔交易部分退款后，它的支付交易金额应该保持不变。
6. 线上配置
- 配置线上账号需要多长时间
- 配置线上账号需要什么信息，对于这些信息有无特殊需求
7. 支付系统支持的qps为多大
a. 常规系统支付的qps
b. 大型活动是否需要提前沟通，预估交易相关数值
c. 对方服务的部署位置
8. 开发&测试
a. 开发阶段需要提供完备的测试环境、测试账号
b. 测试如何模拟各种场景的case
最后
大家如果喜欢我的文章，可以关注我的公众号（程序员麻辣烫）
我的个人博客为：https://shidawuhen.github.io/
往期文章回顾：
