收款神器!解讀聚合收款碼背後的原理

樓下小黑哥 發表於 2020-09-28

Hello,我是樓下小黑哥!

今天跟大家分享一下聚合收款碼的支付原理,這也是我這大半年來一直在做的專案。

微信/支付寶收款碼大家應該不會陌生,線下小微商戶收款大多使用這個,就比如下圖。

收款神器!解讀聚合收款碼背後的原理

這種收款方式很方便,微信、支付寶後臺申請開通,然後還可以免費申請相關物料。

收款神器!解讀聚合收款碼背後的原理不過這種方式使用者體驗其實不是很好,之前有好幾次拿出支付寶,卻掃了微信支付碼。

另外,這種個人的收款碼通常還有單日收款的上限,比如支付寶單日上限 500元。

有了需求,自然會有聰明人人想到解決方案,於是有了聚合收款碼產品解決方案,如下圖。

收款神器!解讀聚合收款碼背後的原理

一個收款碼,支援多種客戶端,主流是微信、支付寶,現在常見還會支援銀聯,QQ 等。

使用者選擇任一支援的客戶端掃碼,都能完成支付,再也不用糾結掃錯碼的尷尬。

有沒有很神奇?其實底層原理很簡單,看完你就明白了,下面就讓小黑哥帶你解密聚合收款碼的底層原理。

歡迎關注我的公眾號:程式通事,獲得日常乾貨推送。
如果您對我的專題內容感興趣,也可以關注我的部落格:studyidea.cn

微信相關支付方式

聚合收款碼底層支付其實還是離不開微信、支付寶支援的支付方式,所以我們先從微信支付寶渠道出發,簡單介紹這個過程將會使用的支付方式。

上篇文章,我們以支付寶為例來介紹,這次我們就以微信支付為例。

開啟微信支付官網,可以看到很多支付方式。

收款神器!解讀聚合收款碼背後的原理

其中付款碼支付在前兩篇文章完整介紹過,這裡不再介紹,感興趣的小夥伴可以看下下面這兩篇文章。

手機沒網了,卻還能支付,這是什麼原理?|原創

輕輕一掃,立刻扣款,付款碼背後的原理你不想知道嗎?|原創

首先我們介紹一下微信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 支付。

聚合收款碼-JSAPI支付

另外,如果支付寶採用面付掃碼支付這種支付方式的話,那麼其實不需要第一步登入授權了,可以直接跳到收銀臺發起支付。

聚合收款碼-支付寶 native 支付

動態聚合收款碼流程

動態聚合收款碼其實與靜態收款碼總體比較類似,只不過建立動態碼內部已經建立了相應的訂單,後續流程與靜態聚合收款碼差不多。

聚合收款碼-動態碼內部創單

銀聯靜態二維碼流程

如果你使用微信、支付寶掃碼開啟銀聯二維碼,將會開啟我們自己收銀臺頁面,後續流程其實跟靜態聚合收款碼一模一樣的。

但是如果你使用支付銀聯支付的 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,最後使用者輸入金額之後,呼叫微信/支付寶完成支付。

好了,今天文章介紹到這裡,最後,點個贊再走吧~

收款神器!解讀聚合收款碼背後的原理

嘻嘻,國慶就要到了,大家再熬幾天!!!

相關資料

  1. https://pay.weixin.qq.com/wiki/doc/api/index.html
  2. https://opendocs.alipay.com/open/194
  3. https://developers.weixin.qq.com/doc/offiaccount/OA_Web_Apps/Wechat_webpage_authorization.html

歡迎關注我的公眾號:程式通事,獲得日常乾貨推送。如果您對我的專題內容感興趣,也可以關注我的部落格:studyidea.cn