标签：type 很多 文档 就是 strong 官方 角度 官方文档 聚合支付
有个项目需要基于建行的聚合支付，实现微信、支付宝及龙支付的扫码支付功能。
建行的业务人员扔过来一个包，打开一看，里面的材料貌似还挺全，但随着进入真正到开发调试阶段，才发现自己把事情想的太简单了。
经过反复的“黑盒”调试，终于将N个坑填平，趁热乎赶紧把一些关键信息写下来，进行备忘。
1、生成二维码部分
1）RETURNTYPE：返回类型（聚合支付可选值：2-建行通用的扫码页面，3-返回二维码串，可自定义扫码页面）
2）生成MAC签名摘要时，需要商户的柜台公钥后30位
3）REMARK1和REMARK2可以传递两个备注，但长度不能超过30位，坑点：如果包含中文，需要先进行escape转码，所以转码前不超过30位不代表转码后也可以。
4）最害人的坑：在根据参数拼接MAC签名串时，要注意别把Null拼进去，就是说，要提前将Null => 空值
5）如果RETURNTYPE==2，那么只需要与建行服务器进行一次POST请求即可；否则还需要进行一次GET请求。
2、接收支付完成回调
1）回调方式：POST
2）验签的大坑：根据天书一般的文档，无数次黑盒调试，得出来的硬道理：某参数有返回值的意思是，包括空值，但不包括Null
3）另外一个大坑：在验签时还需要商户柜台公钥，但不好意思，这次是全部，惊喜不？意外不？
不管如何，总算还是实现了，末了再多说几句：
从实际需求角度，聚合支付的定位非常好，尤其对于我们软件服务商来说，不必再挨个实现各种支付渠道了，一个聚合支付全搞定
但很显然建行的技术同行们并没有非常认真的对待这件事，也可能是我没有得到正确的文档，但满网找了很久也没找到更标准的官方文档，这方面工行做的要好很多。
最后在技术路线方面更是难以相信这些API是出自堂堂的国有银行，吐槽点无数，竟然无从下嘴
邂逅了建行的API之后，才发现，原来腾讯的API那么的优美动人。
标签：type 很多 文档 就是 strong 官方 角度 官方文档 聚合支付
原文地址：https://www.cnblogs.com/netWild/p/10865479.html
