1.前提條件 相比較於支付寶和微信的支付功能接入這一塊,銀行相對來說更加嚴格,比如說支付寶,在你簽約之前可以進行一些測試。但是銀行來說就不是這樣了,如果您現在要進行招行的支付功能開發的話,請務必先讓相關人員去進行簽約 2. 測試開發必須條件 進行測試開發之前有幾個比較重要的東西是不可避免的,我們來看 ...
1.前提條件
相比較於支付寶和微信的支付功能接入這一塊,銀行相對來說更加嚴格,比如說支付寶,在你簽約之前可以進行一些測試。但是銀行來說就不是這樣了,如果您現在要進行招行的支付功能開發的話,請務必先讓相關人員去進行簽約
2. 測試開發必須條件
進行測試開發之前有幾個比較重要的東西是不可避免的,我們來看一下都是有什麼:
-
商戶號、商戶分行號以及商戶秘鑰(具體明細請參考:http://link.cmbchina.com/open2/DOC/ToTest6.aspx)
-
驗證碼查詢地址(測試環境招行所發的驗證碼都可以在此網站查詢到http://121.15.180.69/GetMsgVerifyCode/Default.aspx)
-
API文檔(進行簽約時招行一般會給我們一份文檔,但是此文檔也是很有參考價值的http://link.cmbchina.com/open2/API/APIdefault.aspx)
3.測試開發
咱們這次一個完整的支付流程為例
進入正式的開發之前咱們先來看一下一個圖,這個圖呢,簡單介紹了一下這個支付的流程,並沒有考慮失敗的因素。僅供大家參考!
接下來呢,我們就按照上圖所示的流程進行開發。
-
第一個相信不用費心,APP請求時攜帶一個訂單號就行。
-
我們根據訂單號查詢出此訂單關聯的訂單金額及用戶等信息,然後呢參考此鏈接(http://link.cmbchina.com/open2/API/PWDPayAPI4.aspx)的請求報文要求的必填欄位一一組合起來。
這裡組合的時候有幾個小小的問題,因為招行對我們發送的請求報文是有要求的:測試環境回調地址不支持功能變數名稱,只能是純IP地址,且埠只能為80、443、8081其中的一個。另外請求報文中的reqData欄位里的內容要進行排序。最後,排序完的報文要進行簽名。詳細要求請看此鏈接:http://link.cmbchina.com/open2/API/SigAndCheck2.aspx
這裡進行排序的話我可以提供一種全新的思路,我們可以把待排序的欄位使用一個dto封裝起來類似於下麵這種:
1
|
|
這樣的dto轉換成json串的時候是已經有序了的。
對參數進行簽名的話怎可以參考招行為我們提供的代碼示例。http://link.cmbchina.com/open2/API/Appendix16.aspx#jvch2
需要註意的就是上方我們dto轉成的是一個json串,但是簽名要求的待簽名的字元串格式是這樣的。agrNo=xxx&amount=88.88&bankSerialNo=1234567&branchNo=xxx
排序以及簽名完畢以後就可以把這個發送給APP了,我們發送給APP的就是下方這個形式的json:
1
|
{
|
- APP收到伺服器返回的請求報文,就可以組成如下表單向招行發送請求:
1
|
<form action="http://121.15.180.66:801/NetPayment/BaseHttp.dll?MB_EUserPay" method="post" >
|
這一塊呢,也有一個需要註意的地方,因為有的時候我們服務端開發的時候可能APP還沒有時間,如果我們每次都讓人家幫忙也挺浪費時間的。這裡也有一個快速測試的好辦法。我們可以把上方的代碼拿著自己建一個HTML文件,發送到自己手機上,然後使用手機瀏覽器打開其實也是可以的。
-
此時招行就會返回一個統一的支付頁面
-
在這我們填入簽約時招行給我們的測試賬號等信息,賬號支付使用的驗證碼請參考文章剛開始我們所說的網址
-
假設支付成功,那麼招行就會回調我們請求參數所填的回調地址,這裡其實是有兩個回調地址的,一個是簽約成功的回調,一個是支付成功的回調。
關於這些回調的問題一般我們會有兩種方式解決,1呢是內網穿透,2呢就是遠程Debug,因為招行的測試回調地址只能是ip所以這裡我們就是要第二種方式,不熟悉遠程Debug的同學可以參考我的另一篇博文IDEA遠程Debug
我們就拿支付成功的回調來說。
招行會把參數放到一個jsonRequestData的屬性里。我們可以通過以下方式來取得:JSONObject jsonRequestData=JSONObject.parseObject(request.getParameter("jsonRequestData"));
這個json裡面的東西我們可以參考一下這個鏈接http://link.cmbchina.com/open2/API/PayRltAPI6.aspx
有了這些東西我們就可以準確的知道此次支付的一些相關信息。
不過呢,這樣有個問題呀,這東西要是別人偽造的怎麼辦呀。所以呢,這裡還一個驗簽的過程,驗證此次回調到底是不是招行發來的。
這個驗簽還牽扯到一個問題,那就是驗簽需要招行的公鑰,而招行的公鑰是會定期更新的,所以我們可以做一個定時任務定期去請求招行的公鑰(關於定時任務的相關可以參考我的這篇博客:Java定時任務解決方案)
至於怎麼去查詢請參考此鏈接http://link.cmbchina.com/open2/API/QueryAPI3.aspx,使用我們上方所說的如何排序請求參數,如何進行簽名。不過這個只需要在服務端請求就可以了,至於在服務端如何發送請求大家可以使用一下方式:
1
|
public static String doPost(String jsonParam, String url, String charset) {
|
既然公鑰有了,我們就可以進行驗簽了。
具體驗簽細節可參看此鏈接:http://link.cmbchina.com/open2/API/Appendix16.aspx。
如果驗簽通過的情況下我們就可以happy進行各種操作了。
不過呢,還有一點。記得給招行返回一個收到的信息
`
response.setStatus(HttpStatus.SC_OK);
`
你要是不告訴人家你收到了,他是會在間隔一段時間後再次發送通知,直到10個以後。
- 這個大流程終於走到這了,這個時候你是使用APP輪訓,或者向APP推送告知支付完成的信息就是看你需求了。
結語
關於招行的支付功能是我上周剛剛親手擼出來的代碼,我想能踩的坑我基本上已經踩過了,如果大家在開發過程中遇到什麼問題的話都可以來我的網站,我們一起交流討論:石玉軍的個人博客
本文出自http://zhixiang.org.cn,轉載請保留。