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

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

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

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

一、生成二维码部分

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

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

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

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

5）若是RETURNTYPE==2，那么只须要与建行服务器进行一次POST请求便可；不然还须要进行一次GET请求。

二、接收支付完成回调

1）回调方式：POST，在实际支付完成后就会当即收到回调请求，若是在短期内没有响应，会重复请求。

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

3）另一个大坑：在验签时还须要商户柜台公钥，若是还像上面那样只截取后面的30位，就会顺利入坑。由于此次是所有，惊不惊喜意不意外

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

三、其余方面

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

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

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

 

无论如何，总算仍是实现了，末了再多说几句：

从实际需求角度，聚合支付的定位很是好，尤为对于咱们软件服务商来讲，没必要再挨个实现各类支付渠道了，一个聚合支付全搞定

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

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

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