在Web應用中接入微信支付，我以爲只是調用幾個API稍作調試即可。
沒想到微信的API和官方文檔裏隱坑無數，致我抱着懷疑人生的心情悲憤踩遍了丫們佈下的所有坑。
簡要介紹幾個主要大坑：
坑一：關於WeixinJSBridge這個對象
查閱網頁端調起支付API的開發文檔，此對象即旁若無人的映入眼簾。
然後我們就理所應當的在代碼裏調用了丫的。
可是，too young too naive……
儘管此對象只在微信瀏覽器裏有效，藉此可判斷用戶是否在微信瀏覽器裏訪問應用。
但其實調用了丫之後，你是沒有未來的……
此坑所耗時間：1.5天。
坑二：幾個簽名的混淆
關於簽名的調試，網上各種哭嚎，不少人在簽名處調試多日無果。
那是因爲整個工作流程中，涉及到了至少三個簽名，稍不小心就會用錯。
在統一下單的接口裏，向微信服務器發送請求中的參數有一枚簽名；
其返回的參數中，亦有一枚簽名，後經觀察，發現二者爲同一簽名。
但在使用JSSDK後所調用的wx.config裏所需的參數signature卻是另一枚簽名。
而在wx.chooseWXPay裏所需的支付簽名paySign，卻又是另另另外的一枚。
此坑所耗時間：2天。
坑三：兩個Access_token
查看開發文檔可以看到，微信搞了兩個Access_token！
即使他們用再多的加粗文字來提醒我們兩個token的不同之處，
也難以撫平我們在開發過程中陷入混亂的受傷之身心！
一個是網頁授權的access_token，需要用戶授權之後才能拿到。
而另一個是普通的access_token，支持公衆號的各種基礎服務，並非支付獨用。
看文檔所述的流程，以爲用網頁授權的token就對了？
恭喜，又進坑了……
最後真正用到的是第二個token。
此坑所耗時間：1.5天。
…………
坑坑相套，防不勝防。最終跑通功能後，心力交瘁矣！
爲防以後再次進坑，在此總結一番，供各位參考。
背景畢。
———————— 我是悲憤不已的分割線 ————————
準備工作第一彈：
公衆號一枚，並開通微信支付功能。
在微信公衆平臺（mp.weixin.qq.com）的［微信支付-開發配置］裏對支付授權目錄做配置。
測試期間，需要配置測試授權目錄，以及將參與測試的微信號添加到白名單中。
由於測試必須在線上（測試）環境，debug不太方便，才耗費了辣麼多美好的時光。
授權目錄，即爲調用微信支付控件的頁面所在目錄。
準備工作第二彈：
還是在公衆平臺上，進入開發者中心，找到接口權限表。
在其中的網頁服務中，找到“網頁授權用戶基本信息”並填寫之。
這裏所填的URL必須是用戶進入應用的URL，且必須是oauth驗證所用的URL裏的redirect_uri裏的值……
一處不對，都會在坑裏苦熬良久。
準備工作第三彈：
還是在公衆平臺上，進入公衆號設置，找到功能設置。
需要對JS接口安全域名做設置。
這裏的安全域名就是你的應用相關的域名，改動次數受限制，要注意。
準備工作第四彈：
還是在公衆平臺上，在開發者中心裏找到配置項。
這裏需要有APPID和APPSecret的訪問權限。
另外，還需要準備的是商戶id：mch_id 和 key。
注：secret 和 key 在通信接口裏有用到，不允許在前端頁面使用！
———————— 我是躍躍欲試的分割線 ————————
第一步驟：一個帶驗證的入口URI
首先引導用戶進入應用，這裏以H5頁面爲例。
由於微信支付必須在微信瀏覽器裏進行，因此入口URL鏈接應當從公衆號發佈給用戶，
這樣用戶纔會在微信客戶端中點擊鏈接，進入應用。
（不要問京東爲什麼可以在純網頁端使用微信支付，那是微信給他的小夥伴京東開的後門好嗎）
這個入口URL不是簡單的URL，這裏需要做oauth的驗證，因此我們暫設此URL爲entranceURL。
entranceURL的格式爲：
https://open.weixin.qq.com/connect/oauth2/authorize?appid=APPID&redirect_uri=REDIRECT_URI&response_type=code&scope=SCOPE&state=STATE#wechat_redirect
標紅的幾個變量需要說明：
1. APPID就是公衆號的appid
2. REDIRECT_URI很眼熟？就是剛在網頁授權裏寫的URI，要轉義哦親。
3. response_type須填code，理由是這是一個GET請求，微信會返回code然後用code再……blah blah blah
4. SCOPE，填snsapi_userinfo（需用戶手動授權）或snsapi_base（直接進入頁面）
5. STATE 會跟隨code一起返回，看業務需要自己填。一般格式是有大小寫和數字的組合。
第二步驟：用code獲取openId
用戶點擊了這個entranceURL之後會發生什麼奇妙的事情咩？
這時候微信會返回給你一個code，並重定向到你在REDIRECT_URI裏指定的頁面。
你需要在這個頁面的URL裏拿到code的值，如果拿不到，要提示用戶授權失敗或未授權。
由於這個entranceURL可能是應用的首頁，而需要調用支付控件的是其他頁面，
所以可以先將其緩存到例如sessionStorage裏，到了需要調用支付控件時再用。
拿到這個code需要做什麼咩？
這時候要做的事情就不能在前端頁面裏繼續進行了，這裏必須寫一個前後端通信的接口，
將這個code傳送給後端服務器，然後在服務器裏發起對微信的GET請求：
https://api.weixin.qq.com/sns/oauth2/access_token?appid=我的appid&secret=我的secret&code=這個code&grant_type=authorization_code;
標紅的是需要被替換的變量，其中appid和secret都應該保存在服務端文件中。
這個請求返回的Json裏的openid就是我們要的。
第三步驟：統一下單接口
接口地址：https://api.mch.weixin.qq.com/pay/unifiedorder
參考文檔：https://pay.weixin.qq.com/wiki/doc/api/jsapi.php?chapter=9_1
這個接口在文檔裏講得很清楚，在此不贅述。
注意這裏有簽名sign，它與後面要用的signature和paySign雖然都是簽名，但完全不同。
如果你的trade_type是NATIVE就不需要openid，如果是JSAPI就必須要openid。
在統一下單的接口中，你會告訴微信當前這筆交易的一些基本信息，
包括但不限於商戶id、交易號、交易金額等等。
微信會將其打包到一個package裏，從接口返回的prepay_id裏其實就對應了你的交易詳情。
注意這個接口返回的狀態碼有兩種，一個標識的是通信是否成功：return_code
另一個標識的是業務是否成功：result_code。詳情見文檔。
第四步驟：前端配置wx.config
在上一步接口的業務返回成功之後，可以在前端引用JSSDK了。
開發文檔在：https://mp.weixin.qq.com/wiki/7/aaa137b55fb2e0456bf8dd9148dd613f.html
首先注入權限驗證配置時，需要用到wx.config。
它有幾個參數要格外注意，不然又進坑了：
1. 隨機字符串nonceStr，必須使用上一步的統一下單接口返回的nonceStr。
2. 簽名signature，不是上步接口裏的sign，需在服務端生成，返給前端。（見下一步驟）
3. jsApiList 裏要指定微信支付接口“chooseWXPay”。
4. debug參數設爲true時，會在移動端打出alert幫助調試。
第五步驟：服務端生成wx.config所需的signature
首先用appid和secret從微信基礎支持接口中獲取access_token。
前面提到了兩個token：網頁授權型token和普通型token。
這裏獲取的是普通型token。
由於這個token是公衆號所有服務都可能用到的，因此要格外注意。
有效期7200s，建議過期之前應當緩存之。
然後用這個token去獲取jsapi_ticket，接口地址：
https://api.weixin.qq.com/cgi-bin/ticket/getticket?access_token=" access_token "&type=jsapi
這個ticket同樣也要做緩存。
現在可以準備生成signature了，所需的參數有：
1. jsapi_ticket
2. nonceStr 即統一下單接口返回的隨機字符串
3. 時間戳：秒爲單位（後續還會用到時間戳，要保持一致）
4. 當前頁面URL，不需轉義
注意這個簽名是用sha1算法加密，其他的簽名是用MD5算法加密的。
第六步驟：終於開始配置chooseWXPay了
wx.config的驗證通過之後，就可以在wx.ready的回調裏執行wx.chooseWXPay了。
chooseWXPay的幾個屬性配置說明如下：
1. timeStamp：剛纔用到的那個時間戳，秒爲單位。
2. nonceStr：統一下單接口裏的隨機字符串
3. package：值的格式爲“prepay_id=” 統一下單接口返回的prepay_id
4. signType：由於這裏的簽名是MD5加密，因此這個值就是“MD5”
5. paySign：呵呵，此處是坑，這個簽名也是在服務端生成，返給前端，見下一步驟。
6. success：支付成功後的回調。
7. fail： 支付失敗後的回調。
8. cancel：用戶取消支付後的回調。
這裏注意，由於進入應用時是帶着oauth驗證的，因此在用戶取消支付後，
code可能已過期，因此建議在取消支付的回調裏，調用wx.closeWindow()退出Web頁返回微信客戶端。
因爲即使你不退出，再執行支付，code之後的驗證也不會通過。
這時只能重新訪問一次第一步驟中的entranceURL纔行。
第七步驟：生成chooseWXPay所需的簽名paySign
這個簽名不同於剛纔在wx.config裏的簽名signature，這是用MD5加密的。
生成簽名所需參數有appid，nonceStr，package，signType和timeStamp。（字典序排列）
其中nonceStr和package都是前面調用的統一下單的接口返回的。
這裏的signType是“MD5”.
另外，這個簽名拼合的時候，最後要加一個key，就是app的key。
key的排序在最後，排序不參與字典序。具體規則見官方文檔。
第八步驟：線上測試
至此，萬事具備，包括東風。可以測試了。
建議使用iPhone手機測試，如果有問題IOS會報出錯信息，Android不會。
最常見的問題就是“Invalid signature”，這個錯誤信息太籠統了。
需要更細緻的調試和辛勤的打Log。我在這個坑裏淌了兩天……
注：本地測試環境不能測試，必鬚髮布到線上測試環境（非生產環境），
並且線上測試環境的域名和URI等信息都要在公衆號設置裏有授權。
———————— 我是蠢蠢欲動的分割線 ————————
如此看來，流程清晰多了，也無甚難處。
可當初做開發和調試時，因爲對後端語言不熟，耗費了很多時間，
用JS三秒寫出的方法，用後端語言寫就頻繁報錯，
什麼也不說了，只恨自己讀書少。
最後感謝在此過程中提供語法指點的盆友。