微信支付對接銀行服務商
前言
大家好，我是許RR。最近爲公司的聚合支付平臺對接廣發銀行（廣東發展銀行）服務商的支付通道，遇到很多問題，特此記錄一下
概念
估計很多17年前做微信支付的朋友會對現在的微信支付模式感覺到奇怪，比如出現了各種概念，商戶平臺，渠道商，之前的代理商概念也被換成了服務商，配置支付授權目錄也從公衆號後臺遷移到了商戶平臺上，支付白名單也悄然消失，沒有了配置的地方，微信文檔也出現了三種對接模式，包括普通商戶、服務商和銀行服務商。經過我這幾天的重新學習，總結了一點概念分享給大家。首先先介紹各種對接模式的區別。
普通商戶接入
所謂普通商戶的對接就是最樸實無華的開發模式，公衆號主體開通普通商戶類型的商戶後關聯到公衆號，開發拿到公衆號appId、mch_id這些參數到微信的接口去請求，這種模式的優勢在於簡單快速，開發起來也沒有那麼多的阻礙。但是缺點是不容易集成管理，沒有可重複性。
服務商商戶接入
服務商商戶是種比較特殊的商戶，17年前是沒有的，但是可能是因爲政策或者某些原因出現了，服務商是有能力開發支付軟件的第三方公司。我舉一個例子，比如說XX醫院現在需要做線上就診業務，需要開發一套公衆號網站，但是隻有自己的公衆號，甚至連普通商戶也沒有，怎麼辦呢？醫院就將開發線上就診公衆號軟件的責任交給我司，我司通過在我司的公衆號服務商商戶中新建一個子商戶（或者叫特約商戶）並綁定該醫院的公衆號，讓該醫院根據微信指引開通各種東西，包括設置一個對公賬戶，通過這些設置，該醫院成爲我司服務商商戶號下的一個子商戶，服務商開發拿到一些和子商戶有關的參數去微信的接口請求，最終金錢也是流向子商戶的設置的銀行賬戶。這種模式的優勢在於開發的可重用性高，一套代碼多次複用，並且可管理性高，並且服務商應該還有一些我這種開發不知道的好處。
銀行服務商接入
其實銀行服務商和普通服務商應該區別不大（微信文檔中提到），但是具體差別在哪我也不清楚，這個只有銀行的開發才知道了。
對接流程
準備參數
普通商戶模式
普通商戶需要的參數：
| 參數 | 參數名 | 參數說明 |
|---|---|---|
| appId | 公衆號賬號id | 微信支付分配的公衆賬號ID（企業號corpid即爲此appId） |
| mch_id | 商戶號 | 微信支付分配的商戶號（需要在微信的商戶平臺申請到普通商戶賬號，並關聯到公衆號） |
| key | 商戶平臺api安全key | 微信退款時要用到，在商戶平臺的api安全設置中設置 |
準備測試環境
我司的業務是這樣的，有一個醫院想要做線上就診業務，並且將開發公衆號網站的任務交給了我們，我們代替醫院開發公衆號網站並且對接廣發銀行的服務商。第一步要做的就是準備測試環境（這裏我建議要對接銀行服務商的朋友開發時使用正式的公衆號參數進行測試，微信提供的測試公衆號還是與正式公衆號差別較大，部署起來問題很多）。首先銀行有一套自己測試環境，並且銀行的測試環境對接微信的沙箱測試環境，銀行服務商提供的測試環境其實相當完備。接下來我們聊聊整個測試環境的流程與準備。
進件
將要開發的公衆號的主體名和appId提供給銀行服務商在測試環境進價，銀行服務商在銀聯進件後會搭好和微信相關的沙箱環境。一般測試環境進件後銀行方會提供一些銀行方的參數（比如廣發銀行這裏是提供了廣發銀行的商戶id，廣發銀行的商戶號和廣發商戶應用編號），他們接口的後端會自己去和微信的參數做關聯，一般不會直接提供給對接方有關微信的參數（比如說微信的商戶號）。
提供異步通知地址
微信支付完成後微信會將支付成功的結果異步通知到開發方。對接服務商的話，微信會先通知到服務商的後臺，再由服務商後臺異步通知到對接服務商的後臺，所以需要對接服務商的後臺開發提供異步通知地址給銀行方，讓銀行方去配置，保證支付成功的結果能夠通知到開發商戶後臺。
正式開發（實踐）
加密驗籤通訊
我對接的銀行服務商有一套加密解密，加簽驗籤的模式，我覺得可以完全避免安全問題。
-
請求方生成隨機字符串
encryptKey -
請求方使用自己的私鑰對請求體進行簽名，生成
sign -
請求方使用
encryptKey作爲密鑰，用對稱加密方法去加密請求體，生成加密體 -
請求方使用響應方的公鑰對
encryptKey進行非對稱加密，生成encryptKey1 -
請求方用加密體作爲請求體，把
encryptKey1和sign附在http請求頭上發送給響應方 -
響應方接收請求
-
響應方從請求頭上獲取
encryptKey1並且用自己的私鑰解密，獲取encryptKey -
響應方用解密得到的
encryptKey去解密加密體，得到請求體 -
響應方從請求頭上獲取
sign，再用請求方額公鑰對請求體進行驗籤，驗籤成功即代表成功這種加密加簽方式可以防止類型的任何攻擊，應該說是兩方對接接口的最佳實踐了。
接入預支付/下單接口
微信文檔提到的預支付，其實意思就是在微信下單。調用大多數微信接口，需要保障的是微信和本身業務系統數據一致，舉個例子，我現在做的是一個門診的預約掛號業務，患者要先掛號成功了，生成了成功的掛號單後，再去調用微信下單接口進行下單，如果業務系統沒有處理下單失敗的結果，那麼我們業務系統的數據就會亂了，因爲按理說我掛號成功了，是包括下單成功的，假如我下單失敗了，那麼掛號業務也應該失敗。我們系統內的實踐是，一但下單服務失敗，那麼掛號也會失敗，直接返回給患者，讓患者手動重試，同時釋放號源。
接入退款接口
退款是業務中的重中之重，假如業務單是成功狀態，但是退款接口卻給退款了，那麼無疑是生產事故。最好的方法是先到微信查單，獲取支付訂單的最新狀態，先判斷支付單是否已經支付過，可否退款，再到業務系統中確認業務單是否可退款，如果業務系統是不可退款，那麼自然不能允許這次請求。我們系統內的實踐是，先進行微信接口查單對系統內的支付訂單進行狀態更新，先查詢支付訂單是否處於已支付狀態，如果支付訂單不是已支付狀態那麼不允許，如果支付訂單是已支付狀態，再去業務系統查詢業務訂單是否是可退款狀態，如果不是可退款狀態，那麼自然不可以給他退款。
接入查單接口
查單接口需要進行系統內的支付訂單和微信訂單進行覈對校驗，保證系統內的支付訂單是最新的狀態，我們系統內的實踐是，每次查單接口被調用，就發起一次微信查單請求，對比系統內的支付訂單與微信訂單的狀態，如果不相同則更新數據庫的支付訂單狀態。
接入支付
支付回調是用戶成功對微信訂單支付後，微信主動異步請求業務系統服務端接口的一種消息通知，有使用過消息隊列的小夥伴可以把當成微信發的一條消息隊列的消息，業務系統主動去消費。這個異步通知，因爲是異步的，而且微信會多次通知，所以需要業務系統提供的接口實現冪等性，並且因爲多次異步的通知，需要假如分佈式鎖。我們系統內的實踐是，在接口被調用第一行上加上基於redis setnx的分佈式鎖，並設置過期時間爲3秒，搶不到鎖的請求一律返回失敗，搶到鎖後，先去數據庫查詢訂單，覈對訂單狀態，如果訂單狀態不是未支付的，也返回失敗，如果訂單狀態是已支付，那麼說明已經被通知過了，直接返回成功，保證冪等性。如果訂單狀態是未支付狀態，那麼覈對金額，金額對不上也返回失敗，直到經過了所以的校驗，纔對數據庫的訂單狀態進行一個更新。
未完待續。。。