资讯专栏INFORMATION COLUMN

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

warnerwu / 2889人阅读

摘要:相比起来,支付宝的下单动作由于是在前端调用的,因此,站点需要将自己的订单信息返回到客户端,然后又客户端发起调用支付宝的下单接口,这样一来,如果安全加密等做的不到位,很容易被恶意用户篡改信息。

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

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架构],参与互动交流。

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/11773.html

相关文章

  • 人人都是 API 设计师:我对 RESTful API、GraphQL、RPC API 思考

    摘要:通常情况下,伪都是基于第一层次与第二层次设计的。为了解决这个版本不兼容问题,在设计的一种实用的做法是使用版本号。例如,建议第三位版本号通常表示兼容升级,只有不兼容时才需要变更服务版本。 原文地址:梁桂钊的博客 博客地址:blog.720ui.com 欢迎关注公众号:「服务端思维」。一群同频者,一起成长,一起精进,打破认知的局限性。 有一段时间没怎么写文章了,今天提笔写一篇自己对 API 设...

    ormsf 评论0 收藏0
  • 人人都是 API 设计师:我对 RESTful API、GraphQL、RPC API 思考

    摘要:通常情况下,伪都是基于第一层次与第二层次设计的。为了解决这个版本不兼容问题,在设计的一种实用的做法是使用版本号。例如,建议第三位版本号通常表示兼容升级,只有不兼容时才需要变更服务版本。 原文地址:梁桂钊的博客博客地址:http://blog.720ui.com 欢迎关注公众号:「服务端思维」。一群同频者,一起成长,一起精进,打破认知的局限性。 有一段时间没怎么写文章了,今天提笔写一篇...

    FWHeart 评论0 收藏0
  • RageFrame 一个 Yii2 + AdminLET 免费开源多商户通用后台管理系统

    摘要:极致的插件机制,系统内的系统,安装和卸载不会对原来的系统产生影响强大的功能完全满足各阶段的需求,支持用户多端访问后台微信前台等,系统中的系统。多入口模式,多入口分为后台前端,微信,对内接口,对外接口,不同的业务,不同的设备,进入不同的入口。 RageFrame 2.0 为二次开发而生,让开发变得更简单 项目地址:https://github.com/jianyan74/... 前言 这...

    sunny5541 评论0 收藏0
  • RageFrame 一个 Yii2 + AdminLET 免费开源多商户通用后台管理系统

    摘要:极致的插件机制,系统内的系统,安装和卸载不会对原来的系统产生影响强大的功能完全满足各阶段的需求,支持用户多端访问后台微信前台等,系统中的系统。多入口模式,多入口分为后台前端,微信,对内接口,对外接口,不同的业务,不同的设备,进入不同的入口。 RageFrame 2.0 为二次开发而生,让开发变得更简单 项目地址:https://github.com/jianyan74/... 前言 这...

    Ali_ 评论0 收藏0

发表评论

0条评论

warnerwu

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<