有個項目需要基於建行的聚合支付，實現微信、支付寶及龍支付的掃碼支付功能。
建行的業務人員扔過來一個包，打開一看，里面的材料貌似還挺全，但隨着進入真正到開發調試階段，才發現自己把事情想的太簡單了。
經過反復的“黑盒”調試，終於將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是那么的美。