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

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

樓下小黑哥 小黑十一點半 html

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

上次的文章手機沒網了,卻還能支付,這是什麼原理?發佈以後,沒想到你們都比較感興趣,因此反響還不錯。程序員

另外這篇文章還被「碼農翻身」公號改編成漫畫漫畫:如何盜刷別人的支付寶?,嘿嘿不得不說,仍是劉欣老師講解的更加清晰明瞭。web

如今這篇文章閱讀數據已經破千,雖然對於其餘號主來講仍是不多的數據,可是對於我來講,真是第一個里程碑,期待後面愈來愈好~api

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

好了,不 BB 了,今天跟你們分享一下聚合收款碼的支付原理,這也是我這大半年來一直在作的項目。瀏覽器

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

收款神器!解讀聚合收款碼背後的原理|原創
這種收款方式很方便,微信、支付寶後臺申請開通,而後還能夠免費申請相關物料。ide

不過這種方式用戶體驗其實不是很好,以前有好幾回拿出支付寶,卻掃了微信支付碼。微信支付

另外,這種我的的收款碼一般還有單日收款的上限,好比支付寶單日上限 500元。網站

有了需求,天然會有聰明人人想到解決方案,因而有了聚合收款碼產品解決方案,以下圖。
收款神器!解讀聚合收款碼背後的原理|原創url

一個收款碼,支持多種客戶端,主流是微信、支付寶,如今常見還會支持銀聯,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 支付。
收款神器!解讀聚合收款碼背後的原理|原創

聚合收款碼-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,最後用戶輸入金額以後,調用微信/支付寶完成支付。

好了,今天文章介紹到這裏,最後,點個贊再走吧~
收款神器!解讀聚合收款碼背後的原理|原創

相關資料
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

相關文章
相關標籤/搜索