微信支付開發中幾個值得注意的地方

現在，支付的引入是不少互聯網產品都須要的。爲了讓用戶用着更「舒心」，集成像支付寶、微信支付這樣的第三方支付也就成了常有的事。今天就來看看微信支付，涉及代碼之處均用 Python 編寫。

要想開發順利進行，首先要對業務流程有個清晰的認識。這裏以微信公衆號支付爲例，所以也借用微信支付官方文檔中的業務流程圖：

接下來來關注幾個開發過程當中的關鍵點，包括：

• 生成商戶訂單與調用統一下單 API 

• 微信服務器交互的數據格式

• 公衆號支付下網頁內經過 JS-API 調起支付

• 異步通知商戶支付結果（回調）

 

生成商戶訂單與調用統一下單 API 

這對應業務流程中的第 4 和 第 5 步，商戶後臺首先爲用戶生成訂單，而後調用微信的【統一下單】接口向微信支付系統提交訂單。這裏有一個關鍵點就是簽名的生成。簡單來說分爲如下幾個步驟：

• 將全部有效參數以「k=v」的形式進行拼接，有效參數是指非空參數，也就是說若是參數爲空，則不參與簽名；

• 將全部的「k=v」對用「&」鏈接，獲得「k1=v1&k2=v2&k3=v3」這樣的字符串；

• 將微信支付 API 密鑰 拼接在最後，如「k1=v1&k2=v2&k3=v3&key=secret」；

• 對總體進行 MD5 運算，即獲得簽名。

這種簽名方法有一個高大上的名字叫作 HMAC（Hash-based Message Authentication Code，基於哈希的消息碼）。基於此思路，能夠實現以下簽名方法：

def gen_sign(params, key):
    """
    簽名生成函數
 
    :param params: 參數，dict 對象
    :param key: API 密鑰
    :return: sign string
    """
 
    param_list = []
    for k in sorted(params.keys()):
        v = params.get(k)
        if not v:
            # 參數的值爲空不參與簽名
            continue
        param_list.append('{0}={1}'.format(k, v))
    # 在最後拼接 key
    param_list.append('key={}'.format(key))
    # 用 & 鏈接各 k-v 對，而後對字符串進行 MD5 運算
    return md5('&'.join(param_list).encode('utf8')).hexdigest()

參與簽名的參數中有一個隨機字符串，在 Python 中有不少方法，固然也能夠利用 uuid 庫來生成：

def gen_nonce_str():
    """
    生成隨機字符串，有效字符a-zA-Z0-9
 
    :return: 隨機字符串
    """
 
    return ''.join(str(uuid.uuid4()).split('-'))

微信服務器交互的數據格式

微信服務器與商戶服務器之間採用 XML 格式進行交互，這就涉及到與語言原生數據類型進行轉換以方便處理。交互的數據參數都是 key-value 的形式，所以在 Python 中使用字典會更加方便。而要解析 XML，也有一大把第三方庫供使用，好比 BeautifulSoup。如下是具體實現：

def trans_xml_to_dict(xml):
    """
    將微信支付交互返回的 XML 格式數據轉化爲 Python Dict 對象
 
    :param xml: 原始 XML 格式數據
    :return: dict 對象
    """
 
    soup = BeautifulSoup(xml, features='xml')
    xml = soup.find('xml')
    if not xml:
        return {}
 
    # 將 XML 數據轉化爲 Dict
    data = dict([(item.name, item.text) for item in xml.find_all()])
    return data
 
 
def trans_dict_to_xml(data):
    """
    將 dict 對象轉換成微信支付交互所需的 XML 格式數據
 
    :param data: dict 對象
    :return: xml 格式數據
    """
 
    xml = []
    for k in sorted(data.keys()):
        v = data.get(k)
        if k == 'detail' and not v.startswith('<![CDATA['):
            v = '<![CDATA[{}]]>'.format(v)
        xml.append('<{key}>{value}</{key}>'.format(key=k, value=v))
    return '<xml>{}</xml>'.format(''.join(xml))

注意 detail 參數，即商品詳情，其值爲 JSON 格式，在轉換爲 XML 數據時應前注意使用 CDATA 標籤將其保護起來。如：

<detail>
<![CDATA[{"goods_detail": [{"wxpay_goods_id": "10010001", "price": 1, "goods_num": 1, "goods_name": "\\u82f9\\u679c", "goods_id": "10010001"},
 {"wxpay_goods_id": "10010002", "price": 1, "goods_num": 1, "goods_name": "\\u9999\\u8549", "goods_id": "10010002"}]}]]></detail>

公衆號支付下網頁內經過 JS-API 調起支付

這一點對應業務流程中的第 7 步。之因此說起它是由於微信官方文檔在此給開發者挖了一個坑（至少截至我在寫這篇文章時是的），就是在「網頁端調起支付API」中關於 JS 的示例代碼是採用的 WeixinJSBridge，這在很早之前就是 Deprecated 的「玩意兒」，現在更是已經不可用了。正確的作法是使用 JS-SDK，能夠參考微信公衆號的 wiki。

使用 JS-SDK 前須要先調用 config，這裏也包含一個簽名，但注意這個簽名與以前微信支付的簽名並不相干。其首先須要用微信公衆號的 APPID 和 APPKEY 來換取 access_token，而後用該 access_token 調用 JS-SDK 換取 ticket 的接口獲得 ticket，最後再使用該 ticket 和用戶當前頁面的 URI 經過 sha1 運算生成簽名。

在此以後，便可調用 wx.chooseWXPay 來調起支付，這裏也有一個坑：timestamp。wx.chooseWXPay 中的參數要求 timestamp 是全小寫。而微信支付中籤名時要求 timestamp 中的「s」是大寫。真的是要傻傻分不清了。

 

異步通知商戶支付結果（回調）

最後是關於異步回調，對應業務流程中的第 10 步。在用戶支付操做完成後，微信服務器會經過回調的形式告知商戶服務器支付結果。回調的地址與【統一下單】中定義的 notify_url 一致。當接收到回調時，首先應驗證簽名的有效性以保證「來源可靠」，而後能夠經過回調中所帶的 openid、out_trade_no 等來定位惟一訂單。

 

微信支付還有不少種形式，在業務流程上也不盡相同。不過只要能玩轉其中一種，其餘的也基原本說能很快實現。另外，支付功能的實現涉及業務流程中的安全性，所以必定要注意理清業務流程，並卡好各個關鍵結點。

 

推薦閱讀：

微信支付開發中幾個值得注意的地方

解析：微服務的原則

老王講架構：負載均衡

支付寶系統架構內部剖析

SaaS技術棧的走勢

大數據Spark與Storm技術選型