文章目录

这两天在集成微信支付的功能,先是客户在插件中集成支付功能,后来发现回调不起来,于是将支付功能集成到了主应用,然后暴露接口给插件使用。费劲几个小时的折腾,于是乎就有下文。

我们先来看下官网对于code为-1的说明(官网说明地址点这里):

1
开放平台配置的报名和应用签名是否一致:(android);确认是否使用正式的keystore打包apk并安装调试;(android);提交订单部分需要在服务器端完成。

先请仔细阅读,你遇到的问题就在这段描述中。其中注意,中间还错别字报名应为包名(鹅厂果然不一样)。

下面开始说说事情的经过和结果:

公司这里给客户做了一个应用,客户那边的业务扩展使用插件的方式开发,然后集成到主应用中来。由于客户业务中需要支付功能,而且在插件中支付功能不能正常运行,于是我这边就将插件中的支付集成到主应用中,然后给接口让插件调用。使用这种方式集成完后,我测试了一遍,支付宝支付OK,微信支付也OK。于是跟他们说集成好了,可以用了。

客户那边测试使用的时候反馈,微信支付只能支付成功一次,第二次就不行了。于是乎,我这边也试了下,果然,第二次支付不成功。一看输出的LOG,回调的code返回-1。

为了解决这个问题与客户进行了沟通,客户说是我集成的问题,说他们写了一个测试的demo,连续支付两次都没有问题。好吧,我自己寻找问题的解决方案。我很确信自己的代码集成没有问题,那部分代码也是来自客户写的支付代码。如果客户写的代码有问题,就不可能连续支付两次都OK。

于是找到了前面的官方回调后返回code为-1的说明,当时也只是读了一遍,没深究,因为我觉得问题原因都不是,毕竟还支付成功过一次。

最后去反编译看微信SDK的代码,支寻找为什么会返回-1,突然看到代码里面的getPackageName()时,想到了包名,回忆起之前集成微信第三方登录时绑定的包名和签名信息,突然大悟,是不是和包名有关?客户测试的demo包名和主应用的包名是不一样的。于是跟客户沟通,看了一下支付微信的后台配置,叫对方把包名改成主应用的包名,结果测试,支付两次OK。好吧,问题找到了。

回想起整个问题解决过程,还是插件开发惹的祸。但中间种种不正常让人生疑,如果包名不对,为什么还能在清除应用缓存之后能支付成功?其实当时我应该就要反应过来,有谁会做成这种支付的时候还要清除缓存就能支付成功的?体验做成这样,还叫BAT?可能这个提示是官方支付demo里面的提示,集成的时候直接拿过来用了吧。

中间客户也有叫我检查一下是不是服务器的问题,用工具抓一下微信请求的包,如果返回的code为0,就是请求成功,返回其他值就是不正常,服务器端就有问题。让我先排除一下,结果是code返回0,服务器端OK,没有问题。也就是问题还是在客户端。

刚开始是怀疑签名有问题,于是用官方的工具检测了下,发现签名最后生成的信息是一样的。这个疑问就排除了。只是当时没想到去排除包名的问题。唉,支付宝怎么就没有这样坑人的问题呢?

文章目录