這段時間由於要進行微信公眾號相關的開發，故而接觸到了微信支付。老版本的V2公眾號微信支付比較難搞，有些東西不夠規範。新版本的微信支付統一了介面，文件也比較齊全，全部接入商戶平臺（pay.weixin.qq.com）。下面簡述一下微信公眾號現金支付的開發過程。

申請微信支付

首先，你要有個公眾號，而且是已經經過認證的，這樣才能開通微信支付功能。開通微信支付功能後，你需要有個財付通商戶號，將商戶號繫結到公眾號上。我開發的時候，同事已經幫我申請好了公眾號及微信支付商戶號，一切僅需要根據API進行開發即可。這裡碰到過一個坑，我們怎麼都不不知道微信商戶號為什麼沒有許可權，還叫微信的同事檢查了一下，說要將公眾號和商戶號繫結，並且要稽核通過批准開通的支付方式（JSAPI，NATIVE等）才能進行開發。

NATIVE支付

微信的原生支付，是通過掃碼，從微信的應用原生入口，如對話方塊，或者是二維碼中進入。與之相對的是JSAPI支付，是從內嵌的瀏覽器中發起支付，然後在瀏覽器中有條件的進行支付。NATIVE的支付開發模式分兩種，一種是商戶通過微信制定的規則，生成一個商品售賣的資訊，返回二維碼給使用者掃碼，使用者掃碼之後，微信回撥商戶後臺，後臺正式下單，微信得到下單後讓使用者支付該單。第二種是商戶平臺預先下單，相關支付資訊已經提交了微信，使用者掃碼之後進行支付該單，支付完後微信回撥商戶結果。二者之間主要的差別在於，使用者掃描時臨時下單還是商戶預先幫使用者下單，然後再支付。由於我們設計了一箇中間的支付平臺，我們自身並不知道商品的資訊，這樣的業務適合由商戶平臺下單，然後等待回撥的方式，這樣比較直觀，如果是直接賣東西的商戶，可以直接提供商品的二維碼，那麼直接展示商品二維碼的方式會直觀點，但兩者的效果都是等價的，兩種支付方式皆可。

採用模式二，向微信下單，將會得到一個prepay_id，還有支付的二維碼連結，得到連結後，商戶要將它生成為二維碼，生成的方式多種多樣，一種是通過將資料提交給第三方的網頁介面（一個連結），讓他們幫忙生成二維碼，然後通過  標籤嵌入到頁面中。另外一種是使用別人已經封裝好的庫，直接將二維碼繪製出來，渲染在頁面中。二者各有利弊，前一種能夠節省資源，但要求網路條件良好，服務穩定，後一種則在本地生成，比較迅速。使用者掃描二維碼，進行輸密碼鑑權後，則扣款，等待回撥通知商戶平臺，一般這個時間不會太久，因為使用者的頁面也在重新整理支付結果，以及時地給使用者一個反饋。

JSAPI支付

如果在移動端，應用又部署在移動網頁上，那麼二維碼的方式不太適合，雖然也可以長按識別二維碼跳轉支付，但是這樣的體驗很怪。一開始，我很不理解，為什麼微信不能像NATIVE支付一樣，返回一個連結到微信內嵌的瀏覽器中，然後直接跳轉到該支付地址，進入支付頁面。後來轉念一想，如果任何網頁都能直接彈到支付頁面，有可能會造成濫用下單，並導致有人中招支付了。微信需要一個授信的入口，讓使用者進入支付介面。經過測試，微信在瀏覽器跳轉該支付連結的時候，進入不了輸密碼的介面，原因就是我這個是瀏覽器裡面沒有認證微信身份的操作，而對話和二維碼掃描則不同，是微信客戶端的原生入口，已經自帶了微信使用者的身份資訊等。JSAPI的支付方式就是一個鑑權並跳轉的過程，首先前半部分和NATIVE掃碼支付一樣，先給微信下單，返回一些下單的基本資訊（核心的有prepay_id），後臺將這些資訊告訴前端，讓前端跳轉到一個微信鑑權的地址，並帶上這些資訊和一個跳轉地址，鑑權通過後會進入支付介面，支付完成後，微信回撥商戶後臺，同時頁面回到商戶的頁面，重新整理本地訂單狀態，呈現支付結果。這裡總共是一個三方的關係，微信客戶端（商戶前端），商戶後臺，微信後臺，這三者之間的互動，最終會使得支付狀態一致，至於微信後臺背後的銀聯等東西，對我們商戶開發者是透明的。

JSAPI的方式需要通過js指令碼呼叫微信的介面，這個介面就是原生的入口，這樣的設計雖然看起來不一樣，但是其實和NATIVE統一了。而且下單和支付的邏輯是一樣的，只是具體的鑑權和調起的方式不一樣。微信 商戶後臺 有詳細的文件。 此外，JSAPI需要在微信公眾號填寫授權支付目錄，只有制定的目錄下面才能調起支付請求，一個大平臺肯定會考慮比較多可能的情況，從而做得穩妥一點，他們也可能碰到過一些場景，出過問題，才弄成現在這樣的設計。

小結

這其中我們踩過很多坑，很多資訊也沒有辦法從介面上獲得搞得浪費了一些時間，最好的狀態就是一次申請通過，各種該開的支付許可權都開了，並且發現了微信公眾號後臺的一些bug，這條路並不順利。而且基於微信，我們設計了一個微信支付和積分支付的混合支付平臺，用於騰訊內部的支付場景。這裡API的設計和安全方面的保障參考了微信和支付寶的設計，後面將會詳細說說。

by bibodeng 2015-11-22