http://doc.cocolian.cn/essay/payment/2016/10/24/account-5-iap/
作者：凤凰牌老熊

昨晚刚回到家，就收到商务团队电话:我们是否有上线新功能，某付宝技术人员在联络群里说，我们支付系统发送过去的请求大量地出错了，赶紧看看! 又是某付宝，虽然在渠道流量占比中不算大，可是挖的坑确是最多的。今天聊聊这些不靠谱的渠道，以及如何规避。

HTTPS的坑

还是这个宝，年初的时候，有一天，系统毫无征兆的大量出错，日志中全是这个错误：

  1. javax.net.ssl.SSLHandshakeException: server certificate change is restrictedduring renegotiation

不用说，这又是那边那个运维同学又手痒了，把HTTPS证书给升级了。找到原因后，就静静的看友商打闹：

  • 你们是不是升级了系统？
  • 你们在系统里改了什么东西？
  • 你们的网络有没有问题？
  • ……
  • 额，不好意思啊，我们不小心升级了下HTTPS证书，现在好了，你们要不看看？

半小时后，看到该宝发通知了：由于网络问题，导致支付失败……这也拿来哄人。
碰到这样友商也是醉了，开发人员还头疼这些出问题的数据怎么处理呢。该宝的HTTPS证书问题，半年就得发作一次。接入方基本无解，就是先关闭这个通道，静静地看他们撕，等待他们回滚。恢复够再打开。虽然各种不靠谱，可是还得接入。支付宝微信支付用的人是多，问题是，交易过于集中到某通道，商务上就失去议价能力。而且如果该大户某天不高兴把通道给掐了老板还不哭晕在厕所。

关于同步和异步接口

那大厂家的东西就靠谱吗？确实是，支付宝接入很少出问题，微信却不太争气，今年出了个问题，是异步回调接口出问题了，有两个小时无法工作。用户的所有支付无法确认。老板和业务方每几分钟就过来问候下，开发人员承受巨大的压力，心里面百万只神兽在奔腾。这里需要先解释下同步和异步接口的事。

  • 当一个支付请求被发送到渠道方，渠道会很快返回一个结果。但是这个结果，只是告诉你调用成功了，不是扣款成功，这叫同步调用。很多新手会拿这个结果当作支付成功了，那就会被坑死，结果就是支付成功率特别高，伴随着一堆无法解释的坏账率。
  • 同步请求参数里面会有一个回调地址，这个地址是渠道在扣款成功后调用的，这叫异步调用。一般同步接口仅检查参数是否正确，签名是否无误等。异步接口才告诉你扣款结果。一般异步接口有5秒以内的延迟。调用不成功会重试。有时候是这边成功了，但渠道侧没收到返回，于是会继续调。当天的支付到第二天还在被异步调用也都是正常的。这也是开发人员需要特别注意的地方，不要当做重复支付。这还不是最坑的，一般渠道侧，只有支付成功了才通知你。要是支付失败了，压根儿都不告诉你。
  • 另一方面，如何老收不到异步结果呢？那就得查查了。同步结果不可靠，异步调用不可靠，那怎么确定支付结果？最终的杀招就是查单了。发出请求几秒（比如5秒，根据自己网络情况而定）后，总订单号调用查单接口获取处理情况。回到微信挖的这个坑，当时我们的问题就在于没有主动查单，导致2小时订单出故障。

所以，对接支付接口的可靠方案是：
1.直连接口调用成功后，将该订单标记为需要跟踪。 2.接收到异步调用后，将该订单标记为成功完成。 3.直连成功后几秒（５秒）后，定时任务调用查单接口，根据查单结果，更新订单状态。

关于安全和加密

一般来说，第三方支付接口直接通过互联网来访问就行，加个HTTPS，基本能保证通道的安全。但是银行的对接就麻烦多了。大部分要求走专线，从银行的机房拉到商户到机房，这样就不用走HTTPS了，这样就不用走HTTPS了， 这样就不用走HTTPS了 ！拉专线快的1个月慢的2个月，一般拉两条线，一主一备。租用电信或者联通的线路。对接银行的好处是用户可以直接绑卡支付，银行提供网银和快捷两种方式。网银是支付时跳转到银行页面去输入账户信息，快捷是用户提供卡号，身份证，手机号，真实姓名给商户，商户在支付时把这些信息发给银行完成支付。后者不会打断用户体验，省掉每次输入卡号的麻烦，所以大家都愿意对接快捷。可是和银行的对接，却不是那么美好。各种问题，只有想不到的，没有碰不到的。
先说参数签名。为了防篡改，参数先加密，后Hash成可显示字符。 Hash都好办，一般就是MD5了。问题就出在加密上。每个银行加密方式不尽相同。最奇葩的是和宇宙第X大行的对接。提供的文档中写着：用专用的加密客户端来加密；该客户端只能在windows环境跑。好吧，那我们就准备公司唯一一个在windows上跑的服务器。等客户端软件打过来了，开发同学半天都装不上。电话过去问为啥装不上，排除了人品，天气等各种因素后，开始奇葩对话：

  • 银行：你们用的什么系统？
  • 我们：windows7啊！
  • 银行：不行不行，我们仅在windows2003上验证过。
  • 我们：您再说一遍，是2003吗？
  • 银行：是的，是windows 2003 server。

可是，今天是2016年啊，这都多少年前的系统了。找运维同学给准备机器。果不其然，同样的问答重复一遍后，运维说，你们自己上大街去找抱小孩卖盗版的阿姨碰运气去， 我只能弄个2008看看，这是能找到的最古老的系统了。不得已，只好在windows 2008尝试，居然安装成功了。后面肯定还有坑，开发小哥嘟喃了半天，很快就得到验证了。加密方法老调用失败，再电话过去，结果又来了一句：你们插U盾了吗？ 这下运维伙伴们都炸了，哪有服务器上插u盾的搞法。好说歹说，银行同学则屈服了，好吧，有个不需要U盾的版本。我去，不早说。
总之，和银行对接，务必详细阅读文档，同时沟通的时候一定要问清楚这几个事情：

  • 是否需要专线？专线申请怎么审批，行内需要多久时间才能批下来？
  • 接口加密，用的什么软件，运行的环境是什么？是否需要Ｕ盾？

  • 上线的时候，需不需要ＡＤＳＳ认证。这是央行的新规定，不少银行开始实行了。

    关于专线

    首先是专线问题。 大部分银行对接是需要专线的。 与银行沟通的时候，注意收集如下信息：

  • 专线类型： MSTP类型或者SDH类型。

  • 专线接入点：目前国内主要是联通、电信。
  • 封装类型： HDLC或者PPP
  • 专线代宽：默认是2M
  • 前置机IP，这个需要在银行侧和电商侧进行配置。 专线其实是在银行和电商之间建立一个局域网，需要双方分配通讯IP。 其实这两组IP都是NAT后的IP，银行分配给我们的是电商真实的前置机IP经过最外端的网络防火墙转换后的IP段，后者也是对方的真实前置机IP经过转换后的IP段。 出于安全考虑，双方都不会将真实IP暴露出去，所以要NAT。
  • 接入地址：即电商这边机房的地址。

这些专业名词，可以自己检索，太专业了，其实我也不懂。从可靠性角度考虑，一般建议从联通、电信各拉一条线路出来。一旦有一个线路出问题了，也不会导致所有交易被终止了。不需要专线的银行接口有：浦发、工行、交行信用卡等。 需要专线的有中行、农行、建行等。一般专线需要1个月左右的时间，包括银行侧的申请、施工时间。

加密问题

其次是加密问题。部分银行，如中行，前置要求使用加密机。此处加密机的常用功能有三方面：

  • MAC加密（完整性）；
  • 支付会话\密码加密（安全性）；
  • 密钥交换加密（防截取）。

对开发来说，加密机的主要作用，是让黑客都无法从内存中看到密码。 不是做广告，国内对接银行一般就用江南天安的加密机了

对接银联

对接银联比对接银行简单， 不需要专线，不需要加密机。 不过需要获取ADSS认证。 银联最近在推Token接口，有两套接口，一套是银联侧开通，一套是商户侧开通。前者类似网银支付，后者类似快捷支付。 务必要求接入后者接口啊。基本上读完接口文档就知道怎么写代码了。
最后，回到开始这个事情。在我码完这些文字后，接到友商的电话了：“ 额，不好意思啊，我们不小心升级了下HTTPS证书，现在好了，你们要不看看？

感谢您对本文的关注，如需要及时收到凤凰牌老熊的最新作品，或者有相关问题探讨，请扫码关注“凤凰牌老熊”的微信公众号，在公众号里留言或者回复，可以尽快处理，谢谢。
本文欢迎转载，转载时请注明本文来自 微信公众号“凤凰牌老熊”。