支付寶WAP支付介面開發
因專案需要,要增加支付寶手機網站支付功能,找了支付寶的樣例程式碼和介面說明,折騰兩天搞定,謹以此文作為這兩天摸索的總結。由於公司有自己的支付介面,並不直接使用這個介面,所以晚些時候打算把測試程式碼整理好放到Github上。
1. 開發前準備
- 到官網瞭解此介面的資訊,下載樣例程式碼(只有ASP.NET和PHP)以便隨時參考。
- 一個通過實名認證的企業支付寶賬號,並申請開通手機WAP支付功能,我的測試賬號是拿公司的,申請流程不清楚,官網有說怎麼申請,各位各顯神通吧。
- 公網域名和node.js環境。下面的程式碼大多用coffee來表達,不過本文不會貼太多程式碼,即使對coffee不熟悉也沒什麼關係。關於coffee可以
參考這裡。
github上有兩個開源小專案(搜尋 alipay
),但都沒有WAP支付功能,可以拿來當參考,可以認為是示例程式碼的js移植版,結構很相像。我原打算在其中一個專案基礎上繼續開發,看了程式碼和介面文件後,還是決定從頭開發一個。因為原有程式碼層次不夠清晰,有點過度設計的感覺,而且支付寶的介面很簡單,重寫工作量不大。
吐槽下: 官網的示例程式碼真只是示例級(test)而已,跟產品級(production)還隔比較遠,感覺還談不上SDK。介面文件相當的坑爹,正因如此我才覺得有必要好好寫篇文章總結。
2. 流程
介面開發最重要的應該是理解資料互動流程了,流程弄清了,並理解為何這麼設計,開發起來也是事半功倍
首先,要準備下面幾個引數:
- 企業支付寶賬號的PID(也叫ParnerID)和KEY,如果使用RSA簽名而不是MD5的話,還要把RSA私鑰準備好
- 支付時使用者看到的東西:商品名稱(subject)、支付總額(total_fee)、購買數量(通常都是1吧)
- 交易後的跳轉地址,交易成功後用戶可以手工點選,或頁面延遲自動跳轉到這個地址(return_url)
- 交易狀態非同步通知地址,交易成功或交易關閉會把訊息POST到這個地址(notify_url)
然後,看這幅流程圖(不錯吧,推薦下這個網站:)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
Alipay WAP pay flow Browzer->+Site: 1. HTTP GET note over Site: 2. create a new trade Site->+Alipay: 3. create redirect Alipay->-Site: 4. Token note over Site: 5. build auth url Site->-Browzer: 6. redirect to auth url Browzer->Alipay: 7. redirect Alipay->Browzer: 8. trade info Browzer->Alipay: 9. auth and pay Alipay->+Site: 10. HTTP POST notify note over Site: 11. process trade Site->-Alipay: 12. reply "success" Alipay->Browzer: 13. pay success Browzer->Site: 14. goto return url |
這個流程圖基本囊括了整個互動過程,下面是說明:
- 使用者點選購買按鈕(或其他形式),向網站發起購買請求
- 網站建立訂單,指派一個唯一訂單號
- 網站把訂單號、企業支付寶賬號、交易金額、數量等資訊,用私鑰簽名傳送給支付寶
- 支付寶建立一個交易訂單,返回一個交易令牌(token)
- 網站按照指定要求,用token和自己的私鑰,構造一個重定向得到支付地址
- 網站把重定向地址返回給瀏覽器
- 瀏覽器自動重定向到該地址,即包含了token、網站簽名的支付寶交易頁面
- 支付寶顯示當前交易金額、數量、賣家等資訊
- 使用者用自己的支付寶賬號支付這筆金額
- 支付寶把使用者支付成功(或失敗)這個訊息和訂單號加上支付寶的簽名,使用HTTP POST的方式通知網站(失敗的話,會隔段時間重新發送)
- 網站處理交易後續邏輯(發貨、訂單狀態儲存之類的)
- 網站返回"success"字串給支付寶,表示該通知已經處理,不用再重發
- 支付寶顯示支付成功頁面給使用者(這一步和第10步是不分先後發生的)
- 支付成功頁面延遲自動跳轉,或使用者點選“返回商戶頁面”,跳轉到網站的支付結束頁面(此時不一定成功處理支付寶發來的通知),但會在URL帶上當前的訂單號和狀態。
可以發現,整個流程有點像OAuth(哎呀,之前那篇文章還沒寫完呢!),主要分三步:
一是申請支付寶交易號(獲取token),這一步可以理解為,讓支付寶驗證網站的有效性、讓網站指定該交易要支付多少錢 二是使用者到支付寶頁面付款,這一步可以理解為,讓支付寶驗證使用者有效性,讓使用者在一個不受網站監視的環境下進行支付 三是使用者付款後,處理結果頁面告訴使用者支付成功(同步通知),另外非同步通知網站伺服器該訂單已支付。
支付寶的介面文件說只有兩個步驟,感覺不是很好理解,三步還是比較準確的(收錢肯定要辦事的嘛)。
好睏,細節問題下期繼續。。。
2013-07-24
3. 細節
3.1 網站向支付寶申請新訂單
網站的訂單系統先產生一個新訂單,然後請求支付寶建立一個支付寶訂單.
申請新訂單的service是 alipay.wap.trade.create.direct 需要提交的關鍵引數包括:
3.1.1 使用者在支付寶看到的訂單資訊:
subject: 商品名稱
total_fee: 總金額
seller_account_name: 賣家支付寶賬號(估計跟私鑰繫結的)
merchant_url: 商品展示URL(似乎這個並非必要)
3.1.2 支付寶通知網站時將附帶的資訊:
out_trade_no: 該次交易對應網站的訂單號(要求唯一)
call_back_url: 交易成功後,支付寶頁面上“返回到商家頁面”的地址(同步回撥)
notify_url: 交易狀態變更後,支付寶通知網站的回撥地址(非同步通知)
支付寶驗證通過後,將返回新建立的支付寶訂單號,網站可將該訂單號與自己訂單系統的的訂單號繫結在一起。支付寶同時返回的還有該次交易的token,用於(3.2)使用者支付。
3.2 使用者在支付寶網站,檢視訂單訊息,通過驗證並支付
網站返回跳轉到支付寶的地址,service是alipay.wap.auth.authAndExecute,包含(3.1)返回的token和網站對跳轉地址的簽名
這是個HTTPS頁面,基本認為是安全的。當然前提是瀏覽器沒被動手腳,安卓不少應用被捆綁廣告那是常有的事,手機瀏覽器對HTTPS也不像PC那樣有明顯提示,這些也是我不怎麼信任手機支付的原因。
使用者跳轉到支付寶頁面後,可以在該頁面裡看到當前支付的訂單的名稱和金額,這些是3.1申請時由網站指定的,讓使用者在支付寶的頁面確認一次再付款是合理的。
3.3 支付寶通知網站支付成功,網站收錢做事
這個過程是支付寶通知網站,網站處理後通知使用者已到賬,共包括兩個並行部分:
3.3.1 非同步通知
使用者支付後,支付寶通過HTTP協議通知網站該訂單交易結果。說白了就是支付寶悄悄地告訴網站“這個訂單已經已經付款啦”
值得注意的是,非同步通知有重發機制,支付寶需要得到響應為"success"才認為該通知成功被接收,否則會間隔一段時間重發,依次間隔2m,10m,10m,1h,2h,6h,15h,最多8次通知,由notify_id說明是同一個通知。8次通知都接收失敗怎麼辦?額orz...文件沒說,用那個支付寶訂單號登入支付寶去查賬吧。
3.3.2 同步通知
使用者支付後,支付寶頁面提示“支付成功”,可點選返回商家頁面,也可等待一段時間自動跳回
個人認為,網站跳到這個頁面後,如果仍未收到(3.3.1)非同步通知,並且使用的是MD5簽名,應該把狀態從“待付款”調整為“等待對賬”,而不應該貿然相信該通知的結果。原因是這個回撥地址使用者是可以知道的,MD5簽名還是有被偽造的可能(4.3)。當然額外再做個token之類的理論上也行(需要放在urlpath而不是querystring)。
假如介面調用出錯,通知是不會簽名的。不簽名的原因我懷疑是防止有人惡意收集請求-簽名樣本,見(4.3)。
4. 簽名與加密
簡單的說,簽名防篡改,加密防竊聽。上面的兩種請求(3.1和3.2)和兩個通知(3.3.1和3.3.2)都被要加簽名,支付寶支援下面兩類簽名:
4.1 MD5: 業務資料不加密,防篡改
-
優點: 相對較簡單(當然是相對DSA/RSA來說),計算速度快,明文更直觀
-
缺點: 可抵賴,可能被竊聽、安全性不如非對稱加密
4.2 DSA/RSA: 業務資料加密,也防篡改
-
優點:不可抵賴,安全性較高
-
缺點:相對較複雜,解密速度慢
一開始我想不懂,支付寶既然支援RSA為何還要支援MD5,後來有人說RSA太慢,想想支付寶的業務量就釋然了。由於每個商家的私鑰都不同,並且跟商家的支付寶賬號繫結,即使商家的私鑰被破解了,使用者支付時HTTPS協議基本可以保證使用者支付的目標還是商家的賬號。
4.3 使用MD5簽名可能存在的風險
以下情景僅是我的推斷,沒有嘗試過,所謂道高一尺魔高一丈,希望讀者也別以身犯險。
在使用者支付的步驟(3.2)和支付成功響應頁面(3.3),使用者可以得到一個明文請求內容和對應簽名。由於網站和支付寶直接通訊共用同一個金鑰,一般長期不變,雙方都可以對同一段資料產生簽名,這就有可能抵賴的風險:
網站:“這個資料是你發過來的,上面有你的簽名。”
支付寶:“不是我發的。這個資料是你偽造的,簽名是你籤的。”
另外,當攻擊者收集到足夠多的樣本,是有可能破解出金鑰的,繼而可偽造網站或支付寶任意一方。
4.3.1 惡意消耗商家的訂單號
攻擊者偽造大量未使用的訂單號(不少網站的訂單號都是遞增的純數字,並公開給使用者,且很容易推測到後面的數字),向支付寶請求訂單,直到超時。由於商家對此並不知情(回撥地址和通知地址均篡改掉),其他使用者下單時假如商家用了被偽造過的訂單號,就可能被支付寶認為提交了重複訂單,結果支付失敗。
4.3.2 欺騙商家已支付訂單
由同步通知(3.3.2)返回的引數可以看到,網站訂單標識和交易token和都是可以得到的。這樣的話,關於步驟(3.1),使用者不知道的引數包括notify_url和out_user_no,假如網站的使用者id本身就是公開的,通知回撥地址(3.3.1)被得知或同步通知(3.3.2)實現的不好,就可以通過偽造支付通知,欺騙商家訂單已支付。
待續,下期補充實現程式碼
2013-07-28
5. 程式碼
5.1 簽名
我只做了MD5簽名,專案裡沒用到RSA簽名,就沒做那方面。按照文件說明和demo原始碼,很容易就可以寫出下面的簽名程式碼:
1 2 3 4 5 6 7 |
getSign = (obj,key) -> return null unless obj arr = ([k,v] for k,v of obj when k isnt 'sign' and v? and v isnt '') arr.sort() src = ("#{i[0]}=#{i[1]}" for i in arr).join '&' src = "#{src}#{key}" crypto.createHash('md5').update(src,'utf8').digest 'hex' |
支付寶發到網站的通知(3.3)的簽名演算法跟上面有點不一樣,文件有這麼段說明:
這裡說要按通知的引數的原本順序計算簽名。所以我就把上面的arr.sort()
去掉然後計算簽名,結果發通知發來的簽名和我自己計算的不一致,糾結半天后仔細看文件的樣例說明,看到下面段:
仔細跟實際接收的資料比較之後發現,文件和樣例都說發來的引數順序是(service,v,sec_id,notify_data),但我實際收到的並不是按這個順序,只要按照文件的引數順序重新排列再計算簽名就正確了,最終通知的簽名演算法如下( 真是個蛋疼的大坑orz):
1 2 3 4 5 |
getNotitySign = (obj,key) -> return null unless obj src = ("#{k}=#{obj[k]}" for k in ["service","v","sec_id","notify_data"]).join '&' src = "#{src}#{key}" crypto.createHash('md5').update(src,'utf8').digest 'hex' |
-
文件裡有說到字元編碼引數
_input_charset
,我用的是utf8編碼,發現不用傳這個引數也可以,看來支付寶預設的字元編碼就是utf8了 -
如果使用RSA簽名,需要先解密再計算簽名
5.2 輔助方法
為了程式碼層次更清晰,我把簽名、url拼接等方法抽出到一個單獨模組(alipay_api.coffee):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 |
api_url = "http://wappaygw.alipay.com/service/rest.htm" regexTokenXml = /<request_token>(.*)<\/request_token>/ module.exports = api = services: create: "alipay.wap.trade.create.direct" auth: "alipay.wap.auth.authAndExecute" toReqData: (name,obj) -> arr = ["<#{name}>"] arr.push "<#{k}>#{v}</#{k}>" for k,v of obj arr.push "</#{name}>" arr.join '' createReq: (service,partner,req_data) -> service : service format : 'xml' v : '2.0' partner : partner sec_id : 'MD5' sign : null req_data: req_data parseTokenFromXml: (xml) -> return null unless xml m = regexTokenXml.exec xml m?[1]?.trim() getSign: (obj,key='') -> return null unless obj arr = ([k,v] for k,v of obj when k isnt 'sign' and v? and v isnt '') arr.sort() src = ("#{i[0]}=#{i[1]}" for i in arr).join '&' src = "#{src}#{key}" crypto.createHash('md5').update(src,'utf8').digest 'hex' getNotitySign: (obj,key='') -> return null unless obj src = ("#{k}=#{obj[k]}" for k in ["service","v","sec_id","notify_data"]).join '&' src = "#{src}#{key}" crypto.createHash('md5').update(src,'utf8').digest 'hex' sendCreate: (req,done) -> opt = url: createCreateUrl req request.get opt, (err,res,body) -> return done err if err body = "" unless body ret = querystring.parse body body = null done null,ret createAuthUrl: (token='',key='') -> req = api.createReq api.services.auth req.req_data = "<auth_and_execute_req><request_token>#{token}</request_token></auth_and_execute_req>" req.sign = api.getSign req, yes createAuthUrl req createCreateUrl = (req) -> url = "#{api_url}?" url += "req_data=#{encodeURIComponent req.req_data}" url += "&service=#{encodeURIComponent req.service}" url += "&sec_id=#{encodeURIComponent req.sec_id}" url += "&partner=#{encodeURIComponent req.partner}" url += "&req_id=#{encodeURIComponent req.req_id}" url += "&sign=#{encodeURIComponent req.sign}" url += "&format=#{encodeURIComponent req.format}" url += "&v=#{encodeURIComponent req.v}" url createAuthUrl = (req) -> url = "#{api_url}?" url += "req_data=#{encodeURIComponent req.req_data}" url += "&service=#{encodeURIComponent req.service}" url += "&sec_id=#{encodeURIComponent req.sec_id}" url += "&partner=#{encodeURIComponent req.partner}" url += "&sign=#{encodeURIComponent req.sign}" url += "&format=#{encodeURIComponent req.format}" url += "&v=#{encodeURIComponent req.v}" url |
5.3 業務部分
5.3.1 購買(buy)
購買的邏輯對應於(2)流程圖的(2,3,4,5),建立唯一請求ID,填充本次交易資訊,傳送到支付寶並獲取token,然後拼接支付url並簽名,然後重定向。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 |
demo.buy = (info,done) -> return done 'bad user' unless info?.user_id?.length>10 req = api.createReq api.services.create, info.partner ret = redirect: '' token: null async.series [ (cb) -> getRequestId req.service,(err,req_id) -> req.req_id = req_id cb err (cb) -> createTrade info,req.req_id,(err, tradeId) -> return cb err if err req.req_data = subject : info.subject # 商品名稱 out_trade_no : tradeId.toString() # 網站訂單號 total_fee : info.total_fee # 價錢(number),單位元,例如 0.01 代表1分錢 seller_account_name: info.seller_account_name # 支付寶賬號 call_back_url : info.call_back_url # 支付成功後瀏覽器跳轉地址 notify_url : info.notify_url # 支付成功支付寶的通知將非同步傳送到此地址 out_user : info.user_id # 網站的使用者標識 merchant_url : info.merchant_url # 商品展示頁面, 只是實際測試時(ios)發現支付時沒地方可以跳到這個頁面 req.pay_expire = info.pay_expire if info.pay_expire? # 支付過期時間 req.req_data = api.toReqData 'direct_trade_create_req',req.req_data req.sign = api.getSign req, info.key cb null (cb) -> api.sendCreate req, (err,res) -> return cb err if err return cb 'bad sign from alipay server' unless req.sign is api.getSign req ret.token = api.parseTokenFromXml res.res_data ret.redirect = api.createAuthUrl ret.token storeTradeInfo req.out_trade_no, req.total_fee, ret.token, (err,success) -> return cb err if err cb if success then null else 'store trade info fail' ],(err) -> done err, ret.redirect |
其中用到的幾個方法跟儲存相關,我用的是MySQL:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
getRequestId = (service, done) -> sql = "insert into alipay_requests(service,create_time,state) values(?,now(),'CREATE')" db.queryAll sql,[service],(err,result) -> done err, result?.insertId createTrade = (info,req_id,callback) -> sql = "insert into alipay_trades(user,req_id,create_time) values(?,?,now())" db.queryAll sql,[info.user_id,req_id],(err,result) -> callback err, result?.insertId storeTradeInfo = (tradeId,rmb,token,callback) -> sql = "update alipay_trades set rmb=?,token=?,state='WAIT_PAY' where id = ?" args = [rmb,token,tradeId] db.queryAll sql,args,(err,updateResult) -> callback err,updateResult?.affectedRows is 1 |
5.3.2 通知(notify)
使用者支付後就等著通知了,按道理應該在TRADE_SUCCESS時處理使用者支付成功的邏輯,但我實際測試發現至傳送了TRADE_FINISHED事件來,所以乾脆兩個一併處理了,反正只會有一次成功。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
xmlreader = require 'xmlreader'rr,updateResult?.affectedRows is 1 demo.onNotify = (req,callback) -> xmlreader.read req.notify_data,(err,xdoc) -> return done err if err notify = xdoc.notify notify_id = notify?.notify_id?.text() return done 'bad notify_data' unless notify_id done = (response) -> unless 'string' is typeof response console.error "response notify error: " + (response?.stack ? response ? '') response = 'server error' console.error "response notify: #{response}" unless response is 'success' storeNotifyResponse notify_id,response, (err) -> callback if response is 'success' then err else response storeNotifyDetails notify_id, notify, req, (err,success) -> return done err if err unless success return done "store detail error" trade_status = notify.trade_status.text() if trade_status is 'TRADE_FINISHED' or trade_status is 'TRADE_SUCCESS' unless req.sign is api.getNotitySign req return done 'bad sign' out_trade_no = notify.out_trade_no.text() getTradeUser out_trade_no,(err,user) -> return done err if err user_id = user?.user return done 'unknown user' unless user_id onPayed user_id,(err,success) -> return done err if err return done "onPayed error" unless success storeTradeFinalState out_trade_no, no, console.error done 'success' else # TRADE_PENDING, TRADE_CLOSED, WAIT_BUYER_PAY, etc return done 'unknown trade status' |
跟儲存相關的幾個方法如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
storeTradeFinalState = (tradeId,isError,callback) -> state = if isError then 'FAILURE' else 'SUCCESS' sql = "update alipay_trades set state=?,close_time=now() where id = ?" args = [state,tradeId] db.queryAll sql,args,(err,updateResult) -> callback err,updateResult?.affectedRows is 1 getTradeUser = (out_trade_no,callback) -> sql = "select id,user from alipay_trades where id=?" db.queryOne sql,[out_trade_no],callback onPayed = (user_id,callback) -> sql = "update users set vip=1 where id=? and vip=0 limit 1" db.queryAll sql,[user_id],(err,updateResult) -> callback err, updateResult?.affectedRows is 1 storeNotifyDetails = (notify_id,notify,raw,callback) -> sql = "insert ignore into alipay_notifies(id,recv_time,subject,trade_no,gmt_create, quantity,out_trade_no,notify_time,total_fee,buyer_email,trade_status, gmt_payment,gmt_close,raw) values(?,now(),?,?,?,?,?,?,?,?,?,?,?,? )" args = [ notify_id, notify.subject?.text() notify.trade_no?.text() notify.gmt_create?.text() notify.quantity?.text() notify.out_trade_no?.text() notify.notify_time?.text() notify.total_fee?.text() notify.buyer_email?.text() notify.trade_status?.text() notify.gmt_payment?.text() notify.gmt_close?.text() JSON.stringify raw ] db.queryAll sql,args,(err,updateResult) -> callback err,updateResult?.affectedRows is 1 storeNotifyResponse = (notify_id,response,done) -> sql = "update alipay_notifies set response=? where id=?" db.queryAll sql,[response,notify_id],done |
6. 後記
有些公司有自己的支付平臺,封裝了一層,結果呼叫流程變成下面這樣:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
Alipay WAP using platform pay flow Browzer->+Site: 1. HTTP GET note over Site: 2. create a new trade Site->-Browzer: 3. trade info Browzer->+Platform: 4. redirect note over Platform: 5. create a new trade Platform->+Alipay: 6. create redirect Alipay->-Platform: 7. Token note over Platform: 8. build auth url Platform->-Browzer: 9. redirect to auth url Browzer->Alipay: 10. redirect Alipay->Browzer: 11. trade info Browzer->Alipay: 12. auth and pay Alipay->+Platform: 13. HTTP POST notify Platform->Site: 14. proxy note over Site: 15. process trade Site->Platform: 16. reply "success" Platform->-Alipay: 17. reply "success" Alipay->Browzer: 18. pay success Browzer->Site: 19. goto return url |
咋一看,挺方便的,Site只需要做個跳轉即可,細節都被Platform隱藏起來了,切換不同的支付方式也變得很方便。
可是,這個平臺的介面並不完善,這些資料都是明文並且沒有要求Site做簽名,於是就有一個風險。跟(2)的流程圖對比,可以發現這個流程多了(3,4,14,16)四個步驟。後面兩步只是個代理包裝,沒什麼問題,問題在於步驟3和4。
可以看到,交易細節被放到了重定向url中了,即使用者可以得知交易內容並篡改裡面的資料。舉個例子,假設重定向地址類似這樣
由於該地址沒有驗籤機制,所以攻擊者很容易就可以發現這裡面可以隨意篡改資料。
-
方法1: 將rmb=100.00改成0.01,即將100元的支付變成1分錢,然後支付。結果Site得到通知的時候,就需要額外處理這種支付款項和要求款項不一致的情況。當然最簡單就是金額不足就不退款並且支付失敗了。假如沒做這種判斷,那就相當把100元的商品以1分錢賣出去了。
-
方法2: 偽造大量tradeno,然後請求,並且不支付款項。由於tradeno要求唯一,並只能使用一次,這樣就相當於消耗掉了site的交易ID,並且site對此毫不知情。結果正常使用者要購買時,建立的訂單號對於site來說是未使用的,但對platform來說已經是使用過了,會返回支付失敗。
要避免這個問題,需要在重定向的地址增加簽名,簽名異常的請求都拋棄掉。
(全文完)
轉自:http://neutra.github.io/2013/%E6%94%AF%E4%BB%98%E5%AE%9DWAP%E6%94%AF%E4%BB%98%E6%8E%A5%E5%8F%A3%E5%BC%80%E5%8F%91/