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

有個項目須要基於建行的聚合支付，實現微信、支付寶及龍支付的掃碼支付功能。

建行的業務人員扔過來一個包，打開一看，裏面的材料貌似還挺全，但隨着進入真正到開發調試階段，才發現本身把事情想的太簡單了。

通過反覆的「黑盒」調試，終於將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是那麼的美。