支付渠道那些事

支付系统设计-10

Posted by shamphone on August 9, 2016

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

HTTPS的坑

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

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

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

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

半小时后,看到该宝发通知了:由于网络问题,导致支付失败……这也拿来哄人。

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

关于同步和异步接口

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

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

所以,对接支付接口的可靠方案是:

1.直连接口调用成功后,将该订单标记为需要跟踪。 2.接收到异步调用后,将该订单标记为成功完成。 3.直连成功后几秒(5秒)后,定时任务调用查单接口,根据查单结果,更新订单状态。

关于安全和加密

一般来说,第三方支付接口直接通过互联网来访问就行,加个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盾的版本。我去,不早说。

总之,和银行对接,务必详细阅读文档,同时沟通的时候一定要问清楚这几个事情:

  • 是否需要专线?专线申请怎么审批,行内需要多久时间才能批下来?
  • 接口加密,用的什么软件,运行的环境是什么?是否需要U盾?
  • 上线的时候,需不需要ADSS认证。这是央行的新规定,不少银行开始实行了。

关于专线

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

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

  • 专线接入点:目前国内主要是联通、电信。

  • 封装类型: HDLC或者PPP

  • 专线代宽:默认是2M

  • 前置机IP,这个需要在银行侧和电商侧进行配置。 专线其实是在银行和电商之间建立一个局域网,需要双方分配通讯IP。 其实这两组IP都是NAT后的IP,银行分配给我们的是电商真实的前置机IP经过最外端的网络防火墙转换后的IP段,后者也是对方的真实前置机IP经过转换后的IP段。 出于安全考虑,双方都不会将真实IP暴露出去,所以要NAT。

  • 接入地址:即电商这边机房的地址。

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

加密问题

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

  • MAC加密(完整性);

  • 支付会话\密码加密(安全性);

  • 密钥交换加密(防截取)。

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

对接银联

对接银联比对接银行简单, 不需要专线,不需要加密机。 不过需要获取ADSS认证。 银联最近在推Token接口,有两套接口,一套是银联侧开通,一套是商户侧开通。前者类似网银支付,后者类似快捷支付。 务必要求接入后者接口啊。基本上读完接口文档就知道怎么写代码了。

最后,回到开始这个事情。在我码完这些文字后,接到友商的电话了:“ 额,不好意思啊,我们不小心升级了下HTTPS证书,现在好了,你们要不看看?


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

本文欢迎转载,转载时请注明本文来自 微信公众号“凤凰牌老熊”。