微信公眾號之微信支付
阿新 • • 發佈：2017-08-23
apple 論壇 最好 pps 插入 制造 返回 *** 異常 
這種方式跟微信分享那一塊差不多，先插入JS文件http://res.wx.qq.com/open/js/jweixin-1.2.0.js，這個是動態網站，直接添加就是了！
然後自己先弄一個簽名，簽名怎麽弄呢，其實問下文檔附錄1寫的很清楚的！如圖
簽名需要jsapi_ticket，而jsapi_ticket需要通過access_token獲取，access_token的獲取方式就是一個坑了，微信授權那有一個access_token，而基本配置那也有一個access_token，兩個token，我們獲取的當然不會是授權的那個了（什麽！你說為什麽不是授權的那個？TM我測試的十幾次，我當然知道了~~~~~~ 
咋一看是不是很簡單，然後呢，這又是一個坑！access_token獲取是不能在前臺上獲取的，因為在前臺獲取的話，APPID和appsecret都能被人看到的，為了安全起見，也就是保險，這個只能在後臺獲取，接口參數這些也很簡單，跟後臺吱呼一聲，讓他寫個接口，然後我們這邊調用獲取到 
然後值得註意的就是access_token和jsapi_ticket的存在時間都是7200秒也就是2小時。最好是叫後臺獲取到access_token後在服務器端緩存一下，不然會造成數據流失異常（但是這個異常我到現在都沒有遇到過~~~~）！
有了jsapi_ticket後，我們就要進入另一個微信坑了，簡直就是天坑啊，簡直了~~~~
話不多說，直接上圖，簽名~~~，前端簽名這個東東是真的惱火，但是這塊倒也不是很難，現在網上找幾個封裝好了的時間軸方法，隨機數方法，然後按照ASCII從小到大排序，基本上也可以獲取的到。
接下來就是另一個坑人遊戲了，統一下單！
文檔入口：https://pay.weixin.qq.com/wiki/doc/api/jsapi.php?chapter=9_1
統一下單最開始我還以為也是前端調用接口，然後獲取的，直到無論如何都獲取不到後，各種度娘文檔論壇發現都是後臺獲取的，然後我一臉懵逼的交給了後臺，才發現，原來事情並不是那麽簡單！
看到沒有！看到我話紅線的地方沒有？上面寫的什麽？開戶成功後，要想進行微信支付，必須要接入沙箱測試，驗收完沙箱的所有用例後，才能進行審核，審核完畢後才可以進行正式的上/下交易~~~~
這說明了什麽，說明必須要用沙箱測試，用沙箱測試制造假的key用假的key調用統一下單，調用完下單後，收到微信返回的數據sign，然後用sign再進行一次簽名，然後再將簽名給前臺，然後...........然後就一臉懵逼了.......
用沙箱是的的確確調用統一下單能夠成功返回的，但是呢，但是統一下單返回數據中最重要的prepay_id參數用於是錯的，永遠只有22位，少了後面的total_fee以及一些其他參數的拼裝集合！
然後我和後臺java就一臉懵逼了，各種測試，各種鼓膜，各種度娘，永遠是錯，一直到我這邊實在熬不住了去找微信客服，然後微信客服又叫我發郵件去他們那邊的技術相關~~~然後收到了一條回信！！
這是什麽意思？？？什麽鬼，微信文檔寫著必須走沙箱，測試全部通過才能走正式，微信技術支持說，管毛的沙箱，直接走正式環境~~~~~~辣子的時間啊，辣子的腦細胞啊~~~~~
一場鬧劇鬧了整整一周的時間，我能說什麽~~~
然後統一下單需要註意的一點
是微信公眾號支付的話openId是必須傳入的，否則微信無法確認是公眾號對應的是哪一個用戶！
還有就是我們前端這邊，第一步完成後，第二部傳入的prepay_id的格式必須是package："=***********"；
只要格式不對，就一定會報錯！
然後這裏的paySign也是一個坑，這裏的paySign很容易讓人誤解是統一下單中的sign返回參數，其實不然，統一下單返回的參數中，我們只用得到prepay_id這個，其他的對於我們前臺來說，一個也沒用，這裏的paySign是支付簽名，由後臺用統一下單的簽名方式生成！千萬不要搞錯
然後我們這邊的微信簽名接口對應的參數，全部都是最後一次後臺簽名paySign中對應的參數！
這些全部獲取好了，直接按照微信文檔格式寫就OK~~~~
這是第一種方式，而第二種方式確實沒什麽區別，只是不需要那麽繁瑣，直接調用然後完成就OK！但是最後需要的參數，跟第一種方式也是一樣的，後臺代碼不會有改變!
第二種只是接口名不一樣，然後要傳入的參數多一個APPID其他的全部都跟第一種需要的參數和獲取方法一模一樣！
這邊是我寫的：
畫紅線的地方是絕對需要再三檢查的，只要格式有一丁點不對勁，都一定會錯。
然後我這裏有一個非常好檢查錯誤的方法，微信公眾號支付一定要用IOS來測試。
IOS會根據如圖從上到下的順序報錯~~~~~~~
最後再說一次，千萬不要用沙箱測試，那玩意有毒，用了永遠報錯，直接走正式環境~~~~~
感覺很多程序都是只要一有關錢這一方面，我磨磨唧唧，文檔也寫的簡直了！
前排提示：微信文檔坑很多，在沒有前輩或者有經驗的情況下，千萬不要死懟代碼，一個人思考，最好遇到問題直接去找微信客服，發郵箱就發郵箱嘛~~~ 微信openId那一塊，磨磨唧唧的弄完後，明明APP還沒有支持會員系統，就已經叫我去弄微信支付充值會員了~~~（什麽鬼~~~） 看了兩天微信文檔，結果翻來翻去就那兩種方法，簡直無奈啊~~~ 其一：JS-SDK，文檔接口https://mp.weixin.qq.com/wiki?t=resource/res_main&id=mp1421141115
這種方式跟微信分享那一塊差不多，先插入JS文件http://res.wx.qq.com/open/js/jweixin-1.2.0.js，這個是動態網站，直接添加就是了！
然後自己先弄一個簽名，簽名怎麽弄呢，其實問下文檔附錄1寫的很清楚的！如圖
簽名需要jsapi_ticket，而jsapi_ticket需要通過access_token獲取，access_token的獲取方式就是一個坑了，微信授權那有一個access_token，而基本配置那也有一個access_token，兩個token，我們獲取的當然不會是授權的那個了（什麽！你說為什麽不是授權的那個？TM我測試的十幾次，我當然知道了~~~~~~
咋一看是不是很簡單，然後呢，這又是一個坑！access_token獲取是不能在前臺上獲取的，因為在前臺獲取的話，APPID和appsecret都能被人看到的，為了安全起見，也就是保險，這個只能在後臺獲取，接口參數這些也很簡單，跟後臺吱呼一聲，讓他寫個接口，然後我們這邊調用獲取到
然後值得註意的就是access_token和jsapi_ticket的存在時間都是7200秒也就是2小時。最好是叫後臺獲取到access_token後在服務器端緩存一下，不然會造成數據流失異常（但是這個異常我到現在都沒有遇到過~~~~）！
有了jsapi_ticket後，我們就要進入另一個微信坑了，簡直就是天坑啊，簡直了~~~~
話不多說，直接上圖，簽名~~~，前端簽名這個東東是真的惱火，但是這塊倒也不是很難，現在網上找幾個封裝好了的時間軸方法，隨機數方法，然後按照ASCII從小到大排序，基本上也可以獲取的到。
接下來就是另一個坑人遊戲了，統一下單！
文檔入口：https://pay.weixin.qq.com/wiki/doc/api/jsapi.php?chapter=9_1
統一下單最開始我還以為也是前端調用接口，然後獲取的，直到無論如何都獲取不到後，各種度娘文檔論壇發現都是後臺獲取的，然後我一臉懵逼的交給了後臺，才發現，原來事情並不是那麽簡單！
看到沒有！看到我話紅線的地方沒有？上面寫的什麽？開戶成功後，要想進行微信支付，必須要接入沙箱測試，驗收完沙箱的所有用例後，才能進行審核，審核完畢後才可以進行正式的上/下交易~~~~
這說明了什麽，說明必須要用沙箱測試，用沙箱測試制造假的key用假的key調用統一下單，調用完下單後，收到微信返回的數據sign，然後用sign再進行一次簽名，然後再將簽名給前臺，然後...........然後就一臉懵逼了.......
用沙箱是的的確確調用統一下單能夠成功返回的，但是呢，但是統一下單返回數據中最重要的prepay_id參數用於是錯的，永遠只有22位，少了後面的total_fee以及一些其他參數的拼裝集合！
然後我和後臺java就一臉懵逼了，各種測試，各種鼓膜，各種度娘，永遠是錯，一直到我這邊實在熬不住了去找微信客服，然後微信客服又叫我發郵件去他們那邊的技術相關~~~然後收到了一條回信！！
這是什麽意思？？？什麽鬼，微信文檔寫著必須走沙箱，測試全部通過才能走正式，微信技術支持說，管毛的沙箱，直接走正式環境~~~~~~辣子的時間啊，辣子的腦細胞啊~~~~~
一場鬧劇鬧了整整一周的時間，我能說什麽~~~
然後統一下單需要註意的一點
是微信公眾號支付的話openId是必須傳入的，否則微信無法確認是公眾號對應的是哪一個用戶！
還有就是我們前端這邊，第一步完成後，第二部傳入的prepay_id的格式必須是package："=***********"；
只要格式不對，就一定會報錯！
然後這裏的paySign也是一個坑，這裏的paySign很容易讓人誤解是統一下單中的sign返回參數，其實不然，統一下單返回的參數中，我們只用得到prepay_id這個，其他的對於我們前臺來說，一個也沒用，這裏的paySign是支付簽名，由後臺用統一下單的簽名方式生成！千萬不要搞錯
然後我們這邊的微信簽名接口對應的參數，全部都是最後一次後臺簽名paySign中對應的參數！
這些全部獲取好了，直接按照微信文檔格式寫就OK~~~~
這是第一種方式，而第二種方式確實沒什麽區別，只是不需要那麽繁瑣，直接調用然後完成就OK！但是最後需要的參數，跟第一種方式也是一樣的，後臺代碼不會有改變!
第二種只是接口名不一樣，然後要傳入的參數多一個APPID其他的全部都跟第一種需要的參數和獲取方法一模一樣！
這邊是我寫的：
畫紅線的地方是絕對需要再三檢查的，只要格式有一丁點不對勁，都一定會錯。
然後我這裏有一個非常好檢查錯誤的方法，微信公眾號支付一定要用IOS來測試。
IOS會根據如圖從上到下的順序報錯~~~~~~~
最後再說一次，千萬不要用沙箱測試，那玩意有毒，用了永遠報錯，直接走正式環境~~~~~微信公眾號之微信支付