阅读 354

支付接入常规问题

以前写过一篇如何对接第三方支付的文章如何高效对接第三方支付,因为对接的大多数是海外支付公司,这些公司有很多神奇的问题,往往会埋坑,所以开发之前,整理出问题列表,以便尽早发现和解除问题,保证按时上线。

问题如下

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. 线上配置

  1. 配置线上账号需要多长时间
  2. 配置线上账号需要什么信息,对于这些信息有无特殊需求

7. 支付系统支持的qps为多大

a. 常规系统支付的qps

b. 大型活动是否需要提前沟通,预估交易相关数值

c. 对方服务的部署位置

8. 开发&测试

a. 开发阶段需要提供完备的测试环境、测试账号

b. 测试如何模拟各种场景的case

最后

大家如果喜欢我的文章,可以关注我的公众号(程序员麻辣烫)

我的个人博客为:shidawuhen.github.io/

往期文章回顾:

  1. Go语言
  2. MySQL/Redis
  3. 算法
  4. 架构/网络/项目
  5. 思考/读书笔记
文章分类
后端
文章标签