好了,解讀聚合不 BB 了,碼背今天跟大家分享一下聚合收款碼的原創原理支付原理,這也是收款神器收款我這大半年來一直在做的項目。
微信/支付寶收款碼大家應該不會陌生,解讀聚合線下小微商戶收款大多使用這個,碼背就比如下圖。原創原理
這種收款方式很方便,收款神器收款微信、解讀聚合支付寶后臺申請開通,碼背然后還可以免費申請相關物料。原創原理
不過這種方式用戶體驗其實不是收款神器收款很好,之前有好幾次拿出支付寶,解讀聚合卻掃了微信支付碼。
另外,這種個人的收款碼通常還有單日收款的上限,比如支付寶單日上限 500元。
有了需求,自然會有聰明人人想到解決方案,于是有了聚合收款碼產品解決方案,如下圖。
一個收款碼,支持多種客戶端,主流是微信、支付寶,現在常見還會支持銀聯,QQ 等。
用戶選擇任一支持的客戶端掃碼,都能完成支付,再也不用糾結掃錯碼的尷尬。
有沒有很神奇?其實底層原理很簡單,看完你就明白了,下面就讓小黑哥帶你解密聚合收款碼的底層原理。
微信相關支付方式
聚合收款碼底層支付其實還是離不開微信、支付寶支持的支付方式,所以我們先從微信支付寶渠道出發,簡單介紹這個過程將會使用的支付方式。
上篇文章,我們以支付寶為例來介紹,這次我們就以微信支付為例。
打開微信支付官網,可以看到很多支付方式。
其中付款碼支付在前兩篇文章完整介紹過,這里不再介紹,感興趣的小伙伴可以看下下面這兩篇文章。
首先我們介紹一下「微信Native支付」,引用微信官網的解釋:
Native支付是商戶系統按微信支付協議生成支付二維碼,用戶再用微信“掃一掃”完成支付的模式。該模式適用于PC網站支付、實體店單品或訂單支付、媒體廣告支付等場景。
簡單來講就是商戶后臺調用微信支付接口,微信返回預支付交易的鏈接,格式如下:
weixin://wxpay/bizpayurl?sr=123456
然后商戶將其轉為二維碼,提供給客戶使用微信掃碼支付。
這種支付方式可以應用在 PC 網站購物場景,比如說英雄聯盟官網購買相關游戲道具:
既然「微信Native支付」最后可以變成二維碼完成支付,那么聚合收款碼是不是可以采用「微信Native支付」這種支付方式呢?
答案是可以,但是不適合,產品體驗不太好。
最好使用微信支付另外一種支付產品「JSAPI 支付」。
至于原因,不要急,接下去看就會明白。
「JSAPI 支付」,又被稱為公眾號支付,名詞解釋引用一下官網介紹:
JSAPI 支付是用戶在微信中打開商戶的 H5 頁面,商戶在 H5 頁面通過調用微信支付提供的 JSAPI 接口調起微信支付模塊完成支付。
具體業務流程如下:
日常生活中,很多應用場景使用這種支付方式,比如說:極客時間公眾號上購買課程
這種支付方式相對于「微信Native支付」,比較麻煩,還需要使用微信公眾號登錄授權功能,以此獲取用戶的 openid。
另外當我們調用「微信 JSAPI」后臺接口,拿到微信返回的相關參數之后,我們還需要使用「微信的 JSSDK」,這樣才能喚起微信支付。
聚合收款碼核心原理
了解完聚合支付的所需要的底層支付方式,下面我們來了解一下聚合收款碼的核心原理。
聚合收款碼業務流程如下:
第一步用戶使用微信/支付寶 APP 掃碼之后,將會打開一個收銀臺頁面。
這個收銀臺頁面可以自適應,不同 APP 顯示不同的樣式,比如支付寶打開收銀臺顯示支付寶的 logo,微信打開就會顯示微信的 logo。
第二步用戶在收銀臺輸入金額,點擊支付之后將會喚起 APP 的支付彈窗。
好了,觀察這個流程,我們可以發現掃碼之后,后臺應用需要識別出當前 APP 到底是微信還是支付寶。
那如何判斷當前使用的 APP 呢?
其實這個原理很簡單,在支付寶/微信打開一個鏈接,實際將會使用內置的瀏覽器發起了 HTTP 請求,而 HTTP ?的請求頭將會攜帶 「User-Agent(UA)」,用來標識用戶代理軟件的應用類型、操作系統、軟件開發商以及版本號。
微信/支付寶中瀏覽器發起 HTTP 請求,攜帶的 「User-Agent」分別為:
支付寶
UCBrowser/11.5.0.939?UCBS/2.10.1.6?Mobile?Safari/537.36?AliApp(AP/10.0.15.051805)?AlipayClient/10.0.15.051805?Language/zh-Hans
微信
MQQBrowser/6.2?TBS?043220?Safari/537.36?MicroMessenger/6.5.8.1060?NetType/4G?Language/zh_CN
這里需要注意了,不同型號的手機,不同的版本 APP,「User-Agent」不一定會一樣,其實我們只需要判斷是否包含某些關鍵字即可,比如說只要 「User-Agent」?包含 「MicroMessenger」?就是微信,包含 「AlipayClient」就是支付寶。
下面使用 Java 代碼為例:
String?userAgent?=?request.getHeader("user-agent");
if?(Objects.equals(userAgent,?"AlipayClient"))?{
????//?支付寶
}?else?if?(Objects.equals(userAgent,?"MicroMessenger"))?{
????//?微信
}
這個問題解決之后,后面的流程就很簡單了,只要調用微信/支付寶的 「JSAPI 支付」接口,拿到相關參數之后,喚起支付。
準確來講,支付寶那邊 JSAPI 支付官方名稱為支付寶生活號支付。
這里解釋一下上面的問題,為什么聚合收款碼不能使用「微信Native支付」呢?
主要是因為「微信Native支付」接口返回是一個微信自定義 schema 協議,只能通過微信掃碼打開,喚起支付。
如何聚合收款碼使用「微信Native支付」,收銀臺提交金額之后,需要將微信返回交易鏈接轉成二維顯示在頁面,然后用戶使用微信內置識別二維碼功能喚起支付。
這樣一來比較影響產品體驗,降低支付的成功率。
支付寶也有類似「微信Native支付」支付接口-「當面付掃碼支付」,成功調用之后也會返回支付鏈接。
那這里可以提大家提個小問題,聚合收款碼是否可以使用「支付寶當面付掃碼支付」接口那?
答案是可以的,而且體驗比「微信Native支付」好。
這是因為支付寶返回鏈接是一個標準 HTTP 連接,如下:
https://qr.alipay.com/xxxx
這個鏈接只要在支付寶內中打開,就可以喚起支付。
所以如果聚合收款碼使用「支付寶當面付掃碼支付」接口,收銀臺金額提交之后,當拿到支付寶返回的支付鏈接,應用程序內只要使用 ?HTTP 302 跳轉到支付鏈接,就可以喚起支付寶支付。
畫外音:之前我也一直以為支付寶跟微信一樣,不能使用。
那這樣實際上聚合收款碼底層使用支付方式就有了兩種方案:
微信 JSAPI 支付/支付寶生活支付 微信 JSAPI 支付/支付寶面付掃碼支付
那如何選擇那?個人建議使用第一種方案,微信、支付寶都采用 JSAPI 支付。
主要是因為只要 302 跳轉喚起支付寶支付,就會關閉我們收銀臺頁面,這樣一來整個微信支付與支付寶支付流程就不太一樣了
其次,當用戶支付成功之后,JSAPI 支付還可以跳轉到一個成功頁面,這個頁面我們可以支付結果展示,或者騷一點,還可以掛些廣告,或者引流其他公號上。
但是如果使用付寶面付掃碼支付,支付完成之后,頁面就被關閉了,就沒辦法完成支付頁面跳轉。
聚合收款碼核心流程
介紹完原理,下面主要介紹一下市面上主流聚合收款碼業務流程,其實聚合收款碼可以分為三類:
靜態聚合收款碼 動態聚合收款碼 銀聯靜態二維碼
靜態聚合收款碼就類似如下這種,需要用戶主動輸入金額,可以無限次使用。
而動態聚合收款碼是只能使用一次,并且由商家指定金額,用戶只要掃碼就可以支付指定金額。
這種應用場景比如 B 站購買大會員:
銀聯靜態二維碼其實功能上與靜態聚合收款碼差不多,但是它多了支持銀聯支付的功能。
除了這個以外,最主要的區別是銀聯靜態二維碼是銀聯發碼,背后對應的地址是銀聯的地址,類似如下:
https://qr.95516.com/00010000/xxx
靜態聚合收款碼流程
靜態聚合收款碼主要支付流程主要可以分為二步,第一步為登錄授權。
這里的登陸授權一般使用微信、支付寶匿名登錄授權功能,這樣這個過程普通用戶其實是無感知的。
畫外音:如果是程序員的話,可能會感受到這個過程經過了多次跳轉。
第二步,用戶在收銀臺輸入金額之后,應用內部將會創建相應的訂單,然后再調用微信/支付寶的 JSAPI 支付。
另外,如果支付寶采用面付掃碼支付這種支付方式的話,那么其實不需要第一步登錄授權了,可以直接跳到收銀臺發起支付。
動態聚合收款碼流程
動態聚合收款碼其實與靜態收款碼總體比較類似,只不過創建動態碼內部已經創建了相應的訂單,后續流程與靜態聚合收款碼差不多。
銀聯靜態二維碼流程
如果你使用微信、支付寶掃碼打開銀聯二維碼,將會打開我們自己收銀臺頁面,后續流程其實跟靜態聚合收款碼一模一樣的。
但是如果你使用支付銀聯支付的 APP 掃碼,比如說各大銀行的手機 APP,美團,京東等,就會在這些 APP 內各自支付頁面,然后完成支付。
我們銀聯二維碼的功能,將會在銀聯后臺報備一個跳轉地址,比如說
https://www.heihei.com
當用戶使用微信/支付寶訪問銀聯二維碼,銀聯后臺自己識別訪問請求 「User-Agent」,然后后臺根據規則拼接重定向地址。
拼接規則如下:
https://www.heihei.com?qrCode=URLENCODE(https://qr.95516.com/00010000/xxx)
總結
聚合收款碼統一了用戶支付流程,提高商家的收款效率。
另外聚合收款碼其實還可以跟商家后臺一些 ERP 等軟件打通,這樣還提高的商家生產效率。
不得不說,第一個設計出聚合收款碼的的產品,真實個鬼才~
聚合收款碼,背后原理一點也不難,根據用訪問請求的 「User-Agent」,以此判斷用戶當前掃碼使用的客戶端類型。
然后調用微信/支付寶匿名登錄獲取用戶 id,最后用戶輸入金額之后,調用微信/支付寶完成支付。
好了,今天文章介紹到這里,最后,點個贊再走吧~
嘻嘻嗎,國慶就要到了,大家再熬幾天!!!
相關資料
https://pay.weixin.qq.com/wiki/doc/api/index.html https://opendocs.alipay.com/open/194 https://developers.weixin.qq.com/doc/offiaccount/OA_Web_Apps/Wechat_webpage_authorization.html
特別推薦一個分享架構+算法的優質內容,還沒關注的小伙伴,可以長按關注一下:
長按訂閱更多精彩▼
如有收獲,點個在看,誠摯感謝
免責聲明:本文內容由21ic獲得授權后發布,版權歸原作者所有,本平臺僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯系我們,謝謝!