支付系统经验谈

支付系统各接口总结

接口:同步调用, 重试调用(框架自动重试),自己定时任务自动重试、主动查询、主动查询后自动重试,异步回调,对账,网关层处理对后续逻辑。定时关闭

正常支付:

  1. 正常获取支付签名.

  2. 重试调用(框架自动重试): 支付宝普通支付不交互,支付宝app支付交互可重试,微信支付交互,可重试,返回新的可用的预支付id.

  3. 定时任务自动重试,无.

  4. 主动查询:回调延迟, 需要客户端协作,把支付成功的回调通知回来.定时任务主动查询这些.

  5. 主动查询后重试,无必要.

  6. 异步回调. 只有成功回调.

  7. 对账: 对方失败,我方成功的. 1. 以一方的时间计算总额.需要计算一方的时间.2. 用该时间过滤,得到我方成功的.

  8. 网关层处理对后续逻辑: 网关不能自动退款(这样会导致有退款流水在收单系统上找不到), 如果是网关发起的退款,要标记该笔支付是失败的.不能标记是成功的.

  9. 定时关闭. 要查询下渠道是否正在执行.如果是可以关. 会出现关闭掉,回调回来,走自动退款.

支付系统返回值,错误码,code

code 分成三类:

  1. 明确成功的 code

  2. 明确失败的 code

  3. 未知状态的 code(未知的code)

原则: 未知 code 保持进行中

  1. 提现一定要查询修复方式。同步的:只相信 success,其他保持不变,通过状态来决定状态。异步的:同步,维持状态不变。
  2. 充值(预充值),成功保持进行中,其他不关闭,只是记录已出错过,下次重新获取流水号。如果未知 code 关闭,这样就不会出现因为微信某种原因拒绝,重试还是拒绝,导致用户再也无法支付的现象。一直用同个流水号。导致问题,支付后又来请求,会导致关闭掉。改进: 不关闭,只是记录已出错过。 不影响状态流转。解决了支付的一个大问题,线上遇到的场景:未知 code到底是保持进行中,还是保持关闭的问题。 对支付而言:这种 case 下,如果保持进行中,又支付,还是失败的。如果关闭,可能已经支付成功了,但是又调用了一次。
  3. 代扣。 未知 code。 关闭对我方有好处,用户损失,不会导致用户无法重复代扣的问题。进行中好处,可以通过后续状态检查校验。

未知状态的 code

这些 code 有些是错误可重试的,有些是不可重试的,不管可不可重试,最好都阻断掉。所以请求方可以重新请求,以获取结果。也可以采用查询状态的方案来实现。

好的提供者,内部要保证完整性。采用状态查询修复和再次查询的方案。如果某个提供者,不提供内部完整性。 查询到状态为:

  • 进行中,重试,触发流转。
  • 失败,关闭。不重试。
  • 成功,不重试
  • 无,重试。可能触发流转,也可能继续被拒绝返回未知 code,陷入无限死循环。

所以建议如果对方明确接口是可重试的,内部不保证完整性,建议用后者。

©️2020 CSDN 皮肤主题: 岁月 设计师:pinMode 返回首页