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

 

本文作者为我的朋友 Terry Gao，某互联网架构师，首发于其个人公众号【PHP架构】 

经授权允许本账号转载。

看了之后，感觉写的非常到位，对于测试人员也很有帮助，故原文直接发布。

如果有朋友想了解支付相关测试，请点击-->互联网产品支付功能如何测试？

 

点击尾部 阅读原文，进入对方公众号。

 

原文如下 

---

 

作为一个具备用户交易能力的网站，丰富它的支付渠道对于获客和提高日活都

有不可估量的积极作用。算起来，我接触过的支付系统也有几十个了，在这里总结一下我所接触过的支付系统对外接口的设计方案。

 

1. 支付宝

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

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

 

2. 微信支付

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

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

 

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

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

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

 

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

 

4.1 接口部分

• 下单接口

• 同步回调通知：通知的信息需要包含双方订单号，订单金额，用户身份信息，订单状态等

• 异步回调通知：同“同步回调通知”

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

   

4.2 安全部分

• 信息加密：https、AES、RSA非对称加密（公钥私钥）等；

• 签名规则：对传输的信息整体应用签名规则（sha256等），生成签名字符串，用于防止传输信息被篡改；

• IP白名单：对于服务器间调用的接口，可以将对方服务器IP加入白名单，防止非法IP调用；

• 订单信息反查：A站点主动向支付渠道查询订单信息，保证订单信息的有效性和准确性。

 

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

 

 

---

 

                                                               了解更多请关注微信公众号：测试架构师

                                                         

---