此博客不更新很久了, 更新的文檔在這, 有興趣到這里圍觀:
---------------------------------------------------
支付寶WAP支付接口開發(Node/Coffee語言)
因項目需要，要增加支付寶手機網站支付功能，找了支付寶的樣例代碼和接口說明，折騰兩天搞定，謹以此文作為這兩天摸索的總結。由於公司有自己的支付接口，並不直接使用這個接口，所以晚些時候打算把測試代碼整理好放到Github上。
1. 開發前准備
- 到官網了解此接口的信息，下載樣例代碼（只有ASP.NET和PHP）以便隨時參考。
- 一個通過實名認證的企業支付寶賬號，並申請開通手機WAP支付功能，我的測試賬號是拿公司的，申請流程不清楚，官網有說怎么申請，各位各顯神通吧。
- 公網域名和node.js環境。下面的代碼大多用coffee來表達，不過本文不會貼太多代碼，即使對coffee不熟悉也沒什么關系。關於coffee可以參考這里。
github上有兩個開源小項目（搜索 alipay ），但都沒有WAP支付功能，可以拿來當參考，可以認為是示例代碼的js移植版，結構很相像。我原打算在其中一個項目基礎上繼續開發，看了代碼和接口文檔后，還是決定從頭開發一個。因為原有代碼層次不夠清晰，有點過度設計的感覺，而且支付寶的接口很簡單，重寫工作量不大。
吐槽下： 官網的示例代碼真只是示例級(test)而已，跟產品級(production)還隔比較遠，感覺還談不上SDK。接口文檔相當的坑爹，正因如此我才覺得有必要好好寫篇文章總結。
2. 流程
接口開發最重要的應該是理解數據交互流程了，流程弄清了，並理解為何這么設計，開發起來也是事半功倍
首先，要准備下面幾個參數：
a. 企業支付寶賬號的PID(也叫ParnerID)和KEY，如果使用RSA簽名而不是MD5的話，還要把RSA私鑰准備好
b. 支付時用戶看到的東西：商品名稱(subject)、支付總額（total_fee）、購買數量（通常都是1吧）
c. 交易后的跳轉地址，交易成功后用戶可以手工點擊，或頁面延遲自動跳轉到這個地址(return_url)
d. 交易狀態異步通知地址，交易成功或交易關閉會把消息POST到這個地址(notify_url)
然后，看這幅流程圖（不錯吧，推薦下這個網站:）
這個流程圖基本囊括了整個交互過程，下面是說明:
- 用戶點擊購買按鈕（或其他形式），向網站發起購買請求
- 網站創建訂單，指派一個唯一訂單號
- 網站把訂單號、企業支付寶賬號、交易金額、數量等信息，用私鑰簽名發送給支付寶
- 支付寶創建一個交易訂單，返回一個交易令牌(token)
- 網站按照指定要求，用token和自己的私鑰，構造一個重定向得到支付地址
- 網站把重定向地址返回給瀏覽器
- 瀏覽器自動重定向到該地址，即包含了token、網站簽名的支付寶交易頁面
- 支付寶顯示當前交易金額、數量、賣家等信息
- 用戶用自己的支付寶賬號支付這筆金額
- 支付寶把用戶支付成功（或失敗）這個消息和訂單號加上支付寶的簽名，使用HTTP POST的方式通知網站（失敗的話，會隔段時間重新發送）
- 網站處理交易后續邏輯（發貨、訂單狀態存儲之類的）
- 網站返回"success"字符串給支付寶，表示該通知已經處理，不用再重發
- 支付寶顯示支付成功頁面給用戶（這一步和第10步是不分先后發生的）
- 支付成功頁面延遲自動跳轉，或用戶點擊“返回商戶頁面”，跳轉到網站的支付結束頁面（此時不一定成功處理支付寶發來的通知），但會在URL帶上當前的訂單號和狀態。
可以發現，整個流程有點像OAuth（哎呀，之前那篇文章還沒寫完呢！），主要分三步：
一是申請支付寶交易號（獲取token），這一步可以理解為，讓支付寶驗證網站的有效性、讓網站指定該交易要支付多少錢 二是用戶到支付寶頁面付款，這一步可以理解為，讓支付寶驗證用戶有效性，讓用戶在一個不受網站監視的環境下進行支付 三是用戶付款后，處理結果頁面告訴用戶支付成功（同步通知），另外異步通知網站服務器該訂單已支付。
支付寶的接口文檔說只有兩個步驟，感覺不是很好理解，三步還是比較准確的（收錢肯定要辦事的嘛）。
好困，細節問題下期繼續。。。