閒暇之餘，總結一下之前做過的微信支付（h5、公眾號、pc掃碼）遇到的一些問題。

1、h5支付與公眾號支付的異同
兩者都屬於手機端支付方式，h5支付為非微信瀏覽器支付方式，而公眾號為微信瀏覽器支付方式（可以簡單理解為在微信開啟連線產生的支付）；公眾號支付在調起支付前需要獲取openId，並放入cookie中（微信識別使用者標誌，可通過view重定向獲取），h5支付不需要；簽名引數方面不同之處在於，微信支付的tradeType為”JSAPI”且需要openid，而h5支付tradeType為”MWEB”。

2、訂單和交易流水
問題描述：不同支付方式之間轉換問題，如h5產生訂單後，選擇公眾號或者pc掃碼支付產生支付異常（原因是微信唯一識別一筆交易的標誌為tradeNo，而不是tradeNo+tradeType）
解決方式：考慮到訂單這一屬性不能記錄每一筆交易的流程，因此引入交易流水概念，每調起一次支付產生一筆交易流水，且將交易流水號作為tradeNo傳給微信。這樣做可確保同一筆訂單在不同支付方式中對應多筆交易流水（一種方式調起未支付），而微信根據交易流水不同可識別為不同的交易，弊端在於要保持訂單表和交易流水錶的資訊一致性。需要注意的是，這種方式中退款流程也要根據交易流水號進行退款。

3、pc掃碼支付codeUrl
採用頁面img src請求動態獲取二維碼資料流，而img src獲取後臺傳過來的二維碼圖片地址。好處在於在分散式系統中，採用後者會導致二維碼圖片地址不一致導致重複支付問題，而前者每次都是通過src動態請求獲取。

4、h5支付回撥頁面（官方的文件也提到過這個問題）
個人理解就是支付調起完成後（不管是已支付還是未支付）頁面重定向，h5支付返回view格式為：”redirect:”+ mwebUrl+”&redirect_url=”+redirectUrl。其中redirectUrl即上述提到重定向的頁面，需要進行encode。

5、交易流水重複支付
在每次調起支付之前，根據訂單號查詢最近此訂單最近一筆交易的流水號，並根據此流水號呼叫微信官方介面orderquery查詢此交易狀態，如狀態為已支付則直接拋訂單已支付異常。

6、wxNotify回撥
wxNotify回撥並不完全可靠，wxNotify未回撥導致交易流水狀態不對。可用定時任務對未支付的交易流水進行輪詢，根據流水號呼叫官方介面orderquery查詢此交易狀態，如果狀態為已支付則對資料做相應修改操作。（同理退款操作也可採用此種方式）