如何儘可能簡單的對接微信支付
如何儘可能簡單的對接微信支付
作為一名長時間跟微信支付對接過的程式猿，可以說對微信支付是極為熟悉的了。
微信支付提供如下多種對接方式：
以上截圖來自於微信支付對接文件，侵刪。
如何選擇對接方式和降低對接微信支付的成本，或許是許多程式猿或公司在思考的問題。
而我的建議則是：只選擇H5支付與Native支付
1、H5支付
H5支付的使用場景要比諸如APP支付等的要多，首先H5支付是可以在APP中使用的，雖然微信官網推薦APP中使用APP支付，但是在APP中使用H5支付是不會有任何適配性等問題的，而且H5支付還可以在手機端的任何網頁中使用（如果該網頁在PC開啟，那麼就沒辦法使用了），通過下單後獲得的連結跳轉過去，都會喚醒使用者安裝的微信APP完成支付。
溫馨提醒：H5的跳轉連結是有域名限制的，在微信支付的後臺管理中，有一個地方可設定可用的域名，最多5個，如下圖所示。
跳轉的時候，如果使用該支付的頁面本身就是配置中的域名之一，那麼可以直接跳轉；如果是在APP上使用，則需要在referer中設定為配置中的域名之一。
Referer小課堂：
Referer 是 HTTP 請求 header 的一部分，當瀏覽器（或者模擬瀏覽器行為）向 web 伺服器傳送請求的時候，頭資訊裡有包含 Referer 。比如我在 www.toknow.top 裡有一個 https://api.mch.weixin.qq.com 連結，那麼點選這個 https://api.mch.weixin.qq.com ，它的 header 資訊裡就有： Referer=http://www.toknow.top
由此可以看出，Referer 就是一個來源標記。
所以，如果對接了H5支付，那麼其實可以應對任何在手機端的支付，例如：APP端、網頁端（手機端開啟）、公眾號等跳轉的頁面。這麼一來，就可以避免對接多個支付方式導致後期難以維護等問題，也實現了“一次對接，多處使用”，可謂是一舉多得。
2、Native支付
H5支付搞定了手機端，還有PC端怎麼辦呢？使用Native支付就行了。
Native支付就是把下單後獲得的類似url的資訊生成一個二維碼顯示即可，使用者使用微信的掃一掃來掃描這個二維碼就可以付錢了。
Native支付的對接非常簡單，當然這個簡單是建立在對接完H5的基礎上的，因為Native支付跟H5支付只有一個引數的區別。
即 trade_type 引數：
值為 MWEB：表示 H5支付，跳轉連結在 mweb_url 引數中返回；
值為 NATIVE：表示 Native支付，可生成二維碼的資訊在 code_url 引數中返回；
這樣一來，就基本解決了微信支付在任何終端上的使用了，極為省事。
3、回撥
訂單被支付後，微信會分多次回撥通知我們的服務端，我們在下單時就會把該回調介面的全稱傳送給微信支付，下次就會回撥到該介面中了。
這裡最少存在兩個問題：
一是：如果某企業或單位會在多個產品中使用到微信支付，那麼我們豈不是需要在各個產品中都複製一套相同的程式碼？這種情況建議是單獨建立一個支付服務，所有的產品都通過該服務來使用微信支付，微信支付每次回撥也都是回撥到該服務的某個介面上去，我們再在該介面上回調到各個產品中去即可。
上述方式看起來好像只是多了一層封裝，實際的回撥處理好像還是需要在各個產品中做處理的——這說法完全沒有毛病，但是上述方式可以封裝成一個通用的回撥格式，任何使用了支付通道的產品，回撥時都會以相同的格式回撥。以後需要拓展其他支付時，例如支付寶支付或網銀支付等其他支付，他們的回撥都是千奇百怪的，但是他們也都按照該格式來回調，那麼使用支付通道的產品就能更加優雅的對接所有的支付渠道了。
二是：微信支付回撥會有多次，所以使用支付的產品需要能夠應對多次回撥不會重複操作的問題。
4、查詢回撥
雖然微信支付的回撥是多次非同步的回撥，但是微信支付是沒辦法保證100%通知到我們的，諸如網路異常或其他程式碼異常等未知的問題，總會在偶爾的情況下使得某個已支付的訂單沒有通知到位，這時候需要呼叫微信的訂單查詢方法去查詢訂單，如果已經成功支付，那麼就再回調一次。
上述做法雖然是需要手動去操作，但是已經能夠應該這種偶發性的問題；如果依然嫌棄這種手動操作，或許可以考慮做個訊息佇列或其他快取機制來解決。
5、一站式解決方案
上述解決方案已經能完美解決微信支付的使用問題，完全可以根據這個思路做出一個專注微信支付的微服務來；
但是，如果你希望獲得完全由筆者設計完成的微信支付中介軟體，可以與筆者聯絡，筆者將提供可直接使用的安裝包（基於Spring Boot的jar包）並提供技術支援；
該微信支付中介軟體將包括SSL加密（需要客戶提供）、介面防篡改簽名等安全技術防護；
使用該中介軟體不僅安全無憂，而且大大節省開發時間。
有意者聯絡QQ：984135372，非誠勿