本文主要分享如何对接第三方支付，以及在生产上实际遇到的一些问题，避免大家重复踩坑。

一、五个接口

先简单阐述一下，对接第三方支付时，需要对接如下5个核心接口

1.发起支付

该接口主要用于从第三方获取token，当用户跳转到第三方网站进行支付时，第三方支付公司用来校验是否是合法的支付请求

2.支付结果查询

商户用该接口来判断支付结果成功与否

3.退款

商户用该接口进行退款

4.退款查询

商户用该接口来判断退款结果成功与否

5.获取支付成功订单列表接口

商户用该接口获取第三方某日所有成功支付订单列表，用于对账时使用

二、四个流程

只需要对接完如下四个流程，便可完成第三方支付的对接。

• 发起支付请求
• 同步回调和异步回调
• 退款和退款查询
• 对账

1.发起支付请求

下面的时序图中有几个名词，此处先给大家介绍一下

• 电商系统：海外商城的服务系统，负责提供整个购物流程
• 支付网关：我们将支付抽离为一个单独的系统，该系统用来对接所有支付

时序图

伪代码

#商城系统

说明点

• 签名校验：请求支付接口域名为内网域名，使用签名校验，让系统更加安全
• 记录请求日志：请求除了记录到log文件中，建议落库，方便日后查找
• 非首次支付判断支付状态：防止重复支付，该判断可在流量高峰期降配掉
• 生成新的支付号：部分第三方支付公司，规定同一个支付号，无论支付成功与否只能使用一次。目前，在小米网，当订单创建成功后，订单号不会改变，所以每次用户发起支付后，支付网关会生成新的支付号，使用该支付号请求第三方。该方案会引入重复支付问题，在后面章节阐述解决方案。

实例

• surl：支付后，第三方会调用该url，告知支付网关支付结果，这个流程叫同步回调
• pay_url：需要跳转到第三方的url
• hash：第三方用hash来检验该请求是否合法

2.同步回调和异步回调

支付后，第三方支付会通知支付网关，支付结果。通知的实现一般会有两种方案

• 同步回调：支付后，立即回调支付网关提供的回调接口。该接口url一般在发起支付时，作为参数传递给第三方
• 异步回调：支付后，第三方支付会调用对接方提供的API，该API一般是对接的时候提供给第三方，第三方配置在自己系统中的。异步回调有重试机制，如果对接方没有返回指定结果，如httpcode不为200，则会在一段时间后重试，直到达到指定重试上线后，会停止重试。

同步回调和异步回调是支付系统稳定性和准确性的重要保证。这两个流程核心逻辑一致，所以此处放在一起讲述。

时序图

伪代码

#2.同步回调 异步回调

说明点

• 日志：传入和返回数据都做记录
• 签名校验：校验第三方签名十分重要，这是防止他人攻击的方案之一
• 判断支付成功：情况允许条件下，建议请求第三方查询接口来判断是否支付成功，这是防止他人攻击的方案之二
• 跳转支付成功/失败页面：当发起支付时，支付成功或者失败页面的url会传给支付网关。之所以请求支付时传递该url，原因在于不同终端，url不同。
• 该流程需要两个定时脚本进行支撑
  • 通知订单中心支付完成。因为更改支付系统的订单状态和通知订单中心未必会同时成功。
  • 重复支付订单自动退款

实例

3.退款

退款整体流程一般为，财务系统向支付网关发起退款请求，支付网关将退款记录到表。支付系统定时进行退款，财务系统定时查询退款状态。

时序图

伪代码

#3.退款

说明点

• 退款类型：退款一般分为两种类型
  • 部分退款：有的第三方公司不支持，需要提前咨询
  • 全额退款

• 待退款列表：建议同一个订单的多个退款单，确认处理完一个之后，再处理另一个
• 退款相关状态：调用第三方接口状态callStatus，退款结果状态refundStatus。callStatus成功，refundStatus未成功，可定时查退款状态
• 查询退款结果：可选，根据第三方API情况做判断
• 日志：请求日志和返回日志都进行记录

4.对账

对账的完成，需要第三方提供前一天的支付成功数据，然后和支付网关系统中当天的支付成功数据进行对比。

对不上账的类型有：

• 支付网关有数据，第三方没有数据
  • 可能被黑客攻击了，用户没有真正支付，但是我们发货了
  • 代码有问题，用户没有完成支付，但是系统认为支付成功了
  • 第三方提供数据不全

• 支付网关没有数据，第三方有数据
  • 用户支付成功，但是同步或者异步通知都失败了

• 金额不一致
  • 代码有问题，电商发起支付金额和真正调用第三方金额不一致
  • 第三方提供数据有问题

对账是验证支付系统准确的重要一环，可以帮助开发人员今早发现很多问题，建议每一种支付方式都要支持，并且及时对账。

实例

三、支付进阶

完成上述四个流程后，就实现了支付渠道的对接。然后需要考虑支付网关的实现。支付网关包含多个支付渠道，对外部提供统一的接口。支付网关一般需要考虑如下问题：

• 支付网关中接入多个第三方支付，如何设计使变动最小？
• 相同的银行，多个第三方支付支持，如何设计分配流量的系统？
• 如何监控每个第三方支付的成功率，并动态切换第三方支付？
• 如何做好风控？

这些问题的讲解涉及到很大的篇幅，今后会进行讲解。大家可以先自己思考一些解决方案。

最后

大家如果喜欢我的文章，可以关注我的公众号（程序员麻辣烫）

http://weixin.qq.com/r/jCkOFgjEHFVjrUx193ye (二维码自动识别)

往期文章回顾：

算法

1. 算法学习计划
2. 蛮力法
3. 分治法

技术

1. 浅谈微服务
2. TCP性能优化
3. 限流实现1
4. Redis实现分布式锁
5. Golang源码BUG追查
6. 事务原子性、一致性、持久性的实现原理
7. CDN请求过程详解
8. 记博客服务被压垮的历程
9. 常用缓存技巧
10. 如何高效对接第三方支付
11. Gin框架简洁版
12. InnoDB锁与事务简析

读书笔记

1. 敏捷革命
2. 如何锻炼自己的记忆力
3. 简单的逻辑学-读后感
4. 热风-读后感
5. 论语-读后感

思考

1. 对项目管理的一些看法
2. 对产品经理的一些思考
3. 关于程序员职业发展的思考
4. 关于代码review的思考
5. Markdown编辑器推荐-typora