微信支付寶,我的支付收款接口現狀剖析

前言

在國內環境,廣大的我的站點及應用,由於業務發展需求,每每須要以我的資質申請對接微信和支付寶的支付渠道。然而如今不管是微信仍是支付寶,僅支持具備企業資質的主體申請接口對接,對我的開發者而言,路已經徹底卡死了。然而道高一尺,魔高一丈,聰明勤勞的國人想出了不少方法繞過這些限制。本文主要剖析當前具備可操做性的兩種方法,供有緣人蔘考決策。web

1.經過金額

原理

安卓端的支付寶,在收到收款消息時,會彈出收到 XX 元的應用欄通知消息。這個通知欄消息,是能夠經過編程手段獲取到的。只須要監聽用戶的通知欄消息,判斷是不是支付寶的通知,而後解析裏面的金額,就具備了自定義回調接口的基礎。編程

想像這樣一種場景:用戶A在網站發起100元的支付,而後網站後臺呈現100元的收款二維碼(這個二維碼能夠事先生成放在後臺)出來,用戶付款成功後,在商家的移動端,經過程序監控到支付寶收到了100元的訂單,而後給網站回調。ok,後續的流程和回調邏輯,能夠繼續作了。api

場景再複雜一點,那假如同一時間,有另一個用戶B也發起了100元的支付,可能尚未付款。同時商家移動端檢測到了一個100元的訂單,進行回調。因爲只有金額信息,網站後臺沒法區分這個100元的訂單,到底屬於用戶A,仍是屬於用戶B,一會兒就亂套了。涉及到錢的事都是大事,估計用戶得炸了。安全

這種併發場景,能夠經過一個很簡單的技巧解決,即當多個用戶發起同一金額的支付時,給不一樣的用戶,呈現不一樣的金額二維碼。好比上面的場景,用戶A,呈現100元的二維碼,同一時間用戶B發起100元的訂單支付請求,那就呈現99.99元的支付二維碼,用戶C再來,就呈現99.98元的支付二維碼,依次類推。這樣,移動端監測到的是不一樣的金額,所以也就具有了經過金額,區分訂單和用戶的能力。服務器

優勢

  1. 原理簡單,實現簡單。
  2. 帳號比較安全,沒有被支付寶風控的風險。

缺點

上面這種經過不一樣的金額實現回調的方式,缺點是很是明顯的,隨便列幾點:微信

  1. 僅支持支付寶。微信的移動端通知消息裏面,並不包含金額信息,所以這種方法就熄火了。
  2. 因爲是經過金額進行訂單和用戶區分,所以須要提早上傳收款二維碼,包括用於應付併發場景的大量上下浮動的二維碼。對於有大量訂價的站點和應用,這個工做量是很是可觀的。
  3. 不利於訂價調整。每次訂價調整,都須要上傳大量收款二維碼。
  4. 不支持任意金額。仍是由於要事先上傳收款二維碼。

表明

經過金額區分訂單和用戶的方式實現支付接口回調,因爲原理簡單,實現成本並不高,所以如今市面上有大量基於該原理實現的支付接口平臺。列舉以下:併發

1.paysapi框架

點評:paysapi 官網提到支持微信。實際上是經過上傳一張任意金額的微信二維碼實現的。也就是用戶發起支付後,須要人肉的輸入支付金額,這在體驗上是比較差的。

2.goddpay高併發

點評:和 paysapi 的網站仍是一毛同樣。

3.支付吧性能

點評:無

2.移動端 hook

原理

移動端安卓平臺,是一個比較開放的平臺。咱們運行的幾乎全部軟件,都是能夠經過必定的手段,進行底層編程 hook,自定義其行爲的。好比微信消息防撤回,搖骰子划拳做弊,自動搶紅包,還有支付寶的餘額 & 等級自定義裝逼等功能,都是經過諸如 xposed, virtualxposed 等 hook 框架技術編程實現的。

一樣,微信和支付寶的收款二維碼自動生成,包括支付成功的消息檢測,也是能夠經過 hook 的手段,進行編程做業的。大體流程以下:

用戶發起訂單支付請求,而後移動端 hook 軟件,監測到這個支付請求,獲取到金額和平臺(微信仍是支付寶)信息。調用相關的軟件,注入相關的二維碼生成行爲,ok,相關金額的二維碼生成成功,再顯示給用戶。

用戶支付成功後,一樣的,不管是微信,仍是支付寶,都會檢測到相關的支付成功信息。移動端 hook 軟件,一樣也能夠檢測到。而後進行回調。再後續,就是業務系統處理流程邏輯了。

缺點

  1. 須要安裝移動端 hook 框架,好比 xposed, virtualxposed 等。其中,xposed 軟件,還要求系統必須 root。
  2. 存在必定的安全風險。由於 hook 軟件,能夠監測到微信和支付寶的軟件行爲,包括你的密碼信息,所以存在必定的安全風險。
  3. 帳號存在被風控的可能。不管是微信仍是支付寶,對自家軟件被自定義的行爲,都是零容忍的。

優勢

  1. 與上述經過金額實現回調的方式比起來,這種方式有明顯的優勢,就是不須要提早上傳大量二維碼,支持任意金額的支付處理。
  2. 同時支持微信和支付寶。
  3. 併發能力,能夠相對作到比較高。

表明

基於 hook 方式實現支付接口回調,對軟件開發者的要求較高。所以相關的解決方案並很少見,現簡單列舉以下:

  1. 微米富
點評:基於 virtualxposed。雖然網站幾乎和 paysapi 一毛同樣,但接口回調實現的原理,卻截然不同。另外,微米富還有一個特殊的地方,就是其在移動端 hook 軟件裏面,內置了一個微型的 web 服務器,直接接收並處理用戶的支付請求。這也致使了幾個問題,一是限於移動端 web 服務器的性能,併發的處理,有必定的限制。二是支付頁面的調整和定義,須要修改移動端代碼。三是軟件配置流程複雜(web 服務器代理相關的配置)。
  1. greenyep
點評:基於 virtualxposed。greenyep 和 微米富有一些細微的區別。它並未在移動端 hook 軟件裏面內置 web 服務器,而是採用定時檢測的方式,去後臺服務檢測訂單信息。這樣作的好處是能夠有一箇中心化的平臺作訂單的調度和統計,同時性能也較內置 web 服務器的方式,有必定的提升。缺點也是明顯的,並不方便軟件的分發,作一些私有化的部署。

建議

  1. 若是站點和應用的支付場景比較簡單,同時對微信支付沒有強需求,能夠考慮諸如 paysapi 等經過金額進行區分實現接口回調的平臺。
  2. 若是對安全及風險敏感度較高,一樣建議考慮 paysapi 等平臺。
  3. 若是支付場景比較複雜,須要支持任意金額,同時對微信和支付寶渠道均有需求,能夠考慮諸如微米富,greenyep 等平臺。
  4. 接上,若是對系統穩定性,併發能力要求較高,能夠考慮 greenyep 平臺。
  5. 接上,若是指望私有部署的便捷性,能夠考慮微米富平臺。

正規渠道類

那到底有沒有一款產品能同時知足我的支付收款需求呢?
又能夠支持相對的高併發,低延遲,資金安全無風險,同時還不須要企業資質,用極低的成本獲得高效的回報。

答案是有的:https://h5zhifu.com

開戶只須要:1身份證  2對應的銀行卡(結算用)  3對應的實名認證的微信
十分鐘便可開戶,擁有正規的我的可用的商戶號和密鑰。

以上拙見,歡迎拍磚

相關文章
相關標籤/搜索