集成建行聚合支付踩过的坑，有些槽不吐不快

有个项目需要基于建行的聚合支付，实现微信、支付宝及龙支付的扫码支付功能。

建行的业务人员扔过来一个包，打开一看，里面的材料貌似还挺全，但随着进入真正到开发调试阶段，才发现自己把事情想的太简单了。

经过反复的“黑盒”调试，终于将N个坑填平，趁热乎赶紧把一些关键信息写下来备忘。

1、生成二维码部分

1）RETURNTYPE：返回类型（聚合支付可选值：2-建行通用的扫码页面，3-返回二维码串，可自定义扫码页面）

2）生成MAC签名摘要时，需要商户的柜台公钥后30位

3）REMARK1和REMARK2可以传递两个备注，但长度不能超过30位，并且要求对中文使用js的escape函数进行编码，what？一个后端接口你告诉我用js进行编码？

4）最害人的坑：在根据参数拼接MAC签名串时，要注意别把Null拼进去，就是说，要提前将Null => 空值

5）如果RETURNTYPE==2，那么只需要与建行服务器进行一次POST请求即可；否则还需要进行一次GET请求。

2、接收支付完成回调

1）回调方式：POST，在实际支付完成后就会立即收到回调请求，如果在短时间内没有响应，会重复请求。

2）验签的大坑：根据天书一般的文档，无数次黑盒调试，得出来的硬道理：文档中对于参数有返回值的意思是：包括空值，但不包括Null。再翻译一下：就算返回值是个空值，也算有返回值，但如果是Null就不算有返回值，就不参与验签。

3）另外一个大坑：在验签时还需要商户柜台公钥，如果还像上面那样只截取后面的30位，就会顺利入坑。因为这次是全部，惊不惊喜意不意外

4）建行很贴心的为验签提供了一个jar包，但使用maven的我表示很无耐

3、其他方面

1）其实在整个开发过程中，业务是很简单的，之所以会有这么多问题，主要就是文档太含糊，很多关键点都没有明确，比如上面提到的空值判断规则、验签规则等等

2）再有就是接口的友好性，调试发生问题时，得不到任何技术上的明确反馈，只有一个错误代码，但很可惜我实在猜不出这个代码的含义。尤其是验签失败时，一脸懵逼

3）建行聚合支付的API应该是16年上线的，时间并不长，但JAVA版本的验签包竟然是基于远古时代的1.4，无法理解，更无法理解的是签名摘要非要用&拼接的方式，效率奇低不说，代码也丑的没眼看。

 

不管如何，总算还是实现了，末了再多说几句：

从实际需求角度，聚合支付的定位非常好，尤其对于我们软件服务商来说，不必再挨个实现各种支付渠道了，一个聚合支付全搞定

但很显然建行的技术同行们并没有非常认真的对待这件事，也可能是我没有得到正确的文档，但满网找了很久也没找到更标准的官方文档，这方面工行做的要好很多。

最后在技术路线方面更是难以相信这些API是出自堂堂的国有银行，吐槽点无数

邂逅了建行的API之后，才发现，原来腾讯的API是那么的美。