支付寶WAP支付介面開發

阿新 • • 發佈：2019-02-10

因專案需要，要增加支付寶手機網站支付功能，找了支付寶的樣例程式碼和介面說明，折騰兩天搞定，謹以此文作為這兩天摸索的總結。由於公司有自己的支付介面，並不直接使用這個介面，所以晚些時候打算把測試程式碼整理好放到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)

然後，看這幅流程圖（不錯吧，推薦下這個網站:）

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原始碼，很容易就可以寫出下面的簽名程式碼：

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)：

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):

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並簽名，然後重定向。

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：

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事件來，所以乾脆兩個一併處理了，反正只會有一次成功。

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'

跟儲存相關的幾個方法如下：

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. 後記

有些公司有自己的支付平臺，封裝了一層，結果呼叫流程變成下面這樣：

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/