一個微信支付的項目

一、前言

微信支付和支付寶支付，幾乎壟斷了移動支付業務的市場。項目上最近也上線了有關微信支付的模塊，雖然開發很簡單，可是由於和錢相關，作方案時要謹慎再謹慎。
項目背景是，咱們給客戶食堂作了一款微信小程序，員工能夠基於我的的一卡通登陸使用和消費。此次他們要增長給一卡通充值的功能。一卡通就相似於咱們大學時候的學生證，可用來吃飯消費，你們天天都要用，因此微信充值的頻率還算比較高。
這個項目實際開發了兩天，但前先後後的配合工做持續了快半年，我以爲挺典型的，在此作一下記錄。

二、項目準備

客戶是典型國企的氛圍，財務部通常都是手動作帳，要想讓各級領導接受微信支付，前期要作不少工做。

2.一、開通商戶號

微信支付須要先開通綁定銀行的商戶號，可是開通商戶號通常須要企業的法人拿相關的營業執照去辦理，因此這部分工做想一想都難。協調集團董事長，財務和業務部門，幾個月就過去了。

2.二、0.6%的手續費

通過微信支付的全部費用，騰訊公司會從中抽取 0.6%的手續費。這個其實也不算很高，可是客戶領導仍是很慎重，又考慮了一個月。咱們甚至於作了兩個版本：一個版本是三菱公司承擔這筆手續費，員工充值100元，實際到帳100元；另外一個版本是在界面上提示讓員工本身承擔手續費，員工充值100元，實際到帳99.4元。他們採用了後者。

2.三、安全

各級領導最關心，絕對就是微信支付的安全性了吧，因此前期保障安全的技術方案要作好，要是再弄個方便給領導彙報的ppt就更好了。

三、實際開發

3.一、微信官方api

微信支付官方開發文檔十分詳細，我這裏就列幾個我經常使用的吧。

1. 1.(後端)下訂單：https://api.mch.weixin.qq.com...。商戶在小程序中先調用該接口在微信支付服務後臺生成預支付交易單，返回正確的預支付交易後調起支付。
2. 2.(後端)查訂單：https://api.mch.weixin.qq.com...。該接口提供全部微信支付訂單的查詢，商戶能夠經過查詢訂單接口主動查詢訂單狀態，完成下一步的業務邏輯。
3. 3.小程序調起支付API：微信小程序代碼，能夠調起微信支付模塊的組件，引導用戶完成支付。

固然還有一些退款、發送帳單等api，只不過咱們此次沒有這些需求，就沒用上。

3.二、流程步驟

1. 1.（前端）點擊「充值」按鈕，輸入須要充值的金額，點擊「下一步」，調用後端下訂單的接口。
2. 2.（後端）根據當前用戶的金額，調用上文中「1. (後端)下訂單」接口，生成微信訂單，並將訂單號返回給前端。
3. 3.（前端）根據微信訂單號，經過「3. 小程序調起支付API」，調起微信的支付模塊，引導用戶去支付訂單。支付成功後，會觸發支付成功的回調函數，調用後端業務系統入帳的接口。
4. 4.（後端）所謂業務系統入帳的接口，在這裏就是給一卡通充值的接口。不過要先拿前端提供的微信訂單號，調用「2. (後端)查訂單」接口，再次確認該訂單是否真的支付完成，並不是僞造。而後再寫代碼實現給一卡通的充值操做。

四、安全保障（重要！！！）

通常來講，你沒有考慮到的地方，每每最容易出問題。我記下我遇到的和我能想到的，可能會出現問題的點，後續若是還有再補充。

4.一、本地微信訂單中間表

在 3.2 中的流程操做，咱們要考慮若是執行了一半，咱們的服務器或者數據庫故障，致使操做步驟中斷了怎麼辦。例如執行到了步驟3，用戶已經付過錢了，由於服務器宕機，步驟4中的充值操做就沒了。
強烈建議在本地也建一箇中間表，記錄每一筆微信訂單，並在每一步操做實時更新訂單狀態。而後再寫一個輪詢的腳本，當發現問題訂單時，能夠作出補救措施。還能夠經過該中間表作一些前端報表頁面，相關用戶能夠追溯到每筆訂單的履歷。

4.二、官方api的bug

微信官方提供的api也多是會有問題的，我就遇到過。例如「3. 小程序調起支付API」中，在支付成功的回調函數裏面，會去調用後端入帳的接口。但是我就遇到過一個訂單，用戶在支付成功後，沒有觸發回調函數，致使扣了錢，卻沒有完成一卡通的實際入帳。有多是用戶手機的問題，當時沒辦法調起微信客戶端的支付API，有多是網絡波動致使的問題，甚至於，也有多是微信官方API的bug。

咱們一切要作最壞的打算，在基於已經有了訂單中間表後，輪詢的腳本就能捕捉全部未支付的訂單。經過「2. (後端)查訂單」接口查詢訂單狀態，若是訂單支付成功的，就作一卡通的入帳，若是訂單支付失敗或者並未支付的，則關閉訂單。

4.三、事務鎖

以咱們如今的方案，針對某次微信訂單的入帳操做就有兩個了。一個是成功支付後的回調函數，觸發入帳操做；另外一個是輪詢腳本用於補救的入帳。若是你的方案存在併發的風險，就要考慮事務鎖，不然可能微信付款100元，一卡通到帳的倒是200元。
若是接口部署的服務器是集羣，那還要考慮分佈式的事務。千萬別覺得成功回調觸發的支付接口，就比輪詢的接口執行的早，這兩個接口被分配到集羣的隨機節點上，不一樣服務器節點上的線程等待時間也不一致。我就遇到過一個成功回調觸發的支付接口，在weblogic一個節點上卡了10分鐘才執行，而輪詢的接口被分配在另外一個節點上，早就執行完了。

五、財務對帳

也許有些人對這個「財務對帳」這個過程感到奇怪，但你絕對會印象深入，bug嚴重的話，程序員真的會被「祭天」。財務會對微信充值的每一筆錢作比對，不要小看平時測試的幾塊錢的髒數據，對帳那一天，每塊錢的差別都要講清前因後果。
因此，在項目方案設計的時候，必定要作好支付流水的記錄。詳細再詳細，例如手續費要單獨作字段記錄，不然由於政策上的變動，有的手續費扣了，有的沒扣，在財務面前沒辦法說的清。