探讨一下常见支付系统的对外接口

作为一个具备用户交易能力的网站,丰富它的支付渠道对于获客和提高日活都有不可估量的积极作用。算起来,我接触过的支付系统也有几十个了,在这里总结一下我所接触过的支付系统对外接口的设计方案。

1. 支付宝

作为国内最大的支付平台,绝大多数网站都会与其对接,当之无愧是最常见的支付渠道,而很多其它小的支付渠道也是参考支付宝来设计其对外接口的,很具有代表性,其支付流程如下图:

上图的流程中其实还隐藏了很多安全校验的细节,例如与支付宝接口之间的数据加密规则和验签规则,异步回调接口的调用者IP白名单,支付宝订单信息反查及与A站点订单信息比对校验(金额、用户、状态等)。另外,还有一些流程是可选的,例如,同步回调这一步,如果将订单确认的流程加在里面,则有可能影响用户体验,所以在这里订单的确认流程可以自己触发另开线程去跑,或者去除同步回调的确认订单功能,完全依赖异步回调来完成订单。而异步回调里的订单反查也不是必须的,如果你认为白名单和验签规则足够可信的话,不反查也可以。

2. 微信支付

成交量也非常可观的支付渠道,其支付流程也具有一定的代表性,流程如下图:

相比支付宝,其在初始的下单阶段有一些差异,主要表现在,下单动作是由A站点的服务端调用的,而支付宝则是由前端发起调用的。相比起来,支付宝的下单动作由于是在前端调用的,因此,A站点需要将自己的订单信息返回到客户端,然后又客户端发起调用支付宝的下单接口,这样一来,如果安全、加密等做的不到位,很容易被恶意用户篡改信息。而微信的下单接口是服务端调用的,A站服务器只将获得的微信预付订单号返回给客户端,用来发起调用微信客户端支付接口,这样一来,订单信息详情没有暴露在外,相对更安全一些。

3. 深度合作的积分抵扣模式

有时,一些站点或游戏会与某些第三方深度合作,将第三方的积分接入其中,以一定的比例来抵扣和兑换其中的商品或道具。所谓深度合作,则是第三方会直接给出授权互信接口,允许A站点直接调用扣减某用户的积分,用户只需将其第三方站点的账号与A站点的账号绑定即可。这种模式,大多数情况下只有接口级的调用,没有前端收银台界面,流程图如下:

从上图可以看出,这种方式在流程上相对比较简单,只要A站点与第三方做好接口加密、签名等安全措施,商定好结算规则,对接起来相对比较容易。另外,这种对接形式需要第三方支持按照A站点的订单号来反查订单信息,方便对账结算和订单异常的自动化处理。

4. 总结:支付系统对外接口的必备要素

4.1 接口部分

  • 下单接口
  • 同步回调通知:通知的信息需要包含双方订单号,订单金额,用户身份信息,订单状态等
  • 异步回调通知:同“同步回调通知”
  • 交易订单查询接口:支持使用双方任一方的订单号来查询订单信息,因为有时A站点不一定能拿到支付渠道产生的订单号,此时则只能拿A站点自己的订单号来查询支付渠道的支付信息。之所以需要查询,一个是在回调时确保订单信息的有效性和准确性,另一个目的则是防止异常情况下,A站点没有收到支付渠道的回调信息,而用户的确在支付渠道成功支付,为确保A站点用户支付都能及时到账发货,需要增加异步的订单查询跑批。

4.2 安全部分

  • 信息加密:https、AES、非对称加密(公钥私钥)等;
  • 签名规则:对传输的信息整体应用签名规则(sha256等),生成签名字符串,用于防止传输信息被篡改;
  • IP白名单:对于服务器间调用的接口,可以将对方服务器IP加入白名单,防止非法IP调用;
  • 订单信息反查:A站点主动向支付渠道查询订单信息,保证订单信息的有效性和准确性。

以上只是我对之前接触过的支付系统对外接口的总结,可能有一些说的不对或有待完善的地方,如果你有任何问题或建议,可以扫描下方二维码或者为微信搜索[phpjiagoushier],关注我的微信公众号[PHP架构师],与我交流互动。

发表评论

电子邮件地址不会被公开。 必填项已用*标注