对接第三方支付方案

一、五个接口

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

1.发起支付

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

2.支付结果查询

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

3.退款

商户用该接口进行退款。

4.退款查询

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

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

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

二、四个流程

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

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

• 对账

  1.发起支付请求

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

• 电商系统：海外商城的服务系统，负责提供整个购物流程

• 支付网关：我们将支付抽离为一个单独的系统，该系统用来对接所有支付

说明点

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

2.同步回调和异步回调

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

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

同步回调和异步回调是支付系统稳定性和准确性的重要保证。

说明点

• 日志：传入和返回数据都做记录
• 签名校验：校验第三方签名十分重要，这是防止他人攻击的方案之一
• 判断支付成功：情况允许条件下，建议请求第三方查询接口来判断是否支付成功，这是防止他人攻击的方案之二
• 跳转支付成功/失败页面：当发起支付时，支付成功或者失败页面的 url 会传给支付网关。之所以请求支付时传递该 url，原因在于不同终端，url 不同。

• 该流程需要两个定时脚本进行支撑

  • 通知订单中心支付完成。因为更改支付系统的订单状态和通知订单中心未必会同时成功。
  • 重复支付订单自动退款

    3.退款

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

    说明点

• 退款类型：退款一般分为两种类型

  • 部分退款：有的第三方公司不支持，需要提前咨询
  • 全额退款
• 待退款列表：建议同一个订单的多个退款单，确认处理完一个之后，再处理另一个
• 退款相关状态：调用第三方接口状态 callStatus，退款结果状态 refundStatus。callStatus 成功，refundStatus 未成功，可定时查退款状态
• 查询退款结果：可选，根据第三方 API 情况做判断

• 日志：请求日志和返回日志都进行记录

  4.对账

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

• 支付网关有数据，第三方没有数据

  • 可能被黑客攻击了，用户没有真正支付，但是我们发货了
  • 代码有问题，用户没有完成支付，但是系统认为支付成功了
  • 第三方提供数据不全
• 支付网关没有数据，第三方有数据
  • 用户支付成功，但是同步或者异步通知都失败了
• 金额不一致
  • 代码有问题，电商发起支付金额和真正调用第三方金额不一致
  • 第三方提供数据有问题

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