在國內環境,廣大的我的站點及應用,由於業務發展需求,每每須要以我的資質申請對接微信和支付寶的支付渠道。然而如今不管是微信仍是支付寶,僅支持具備企業資質的主體申請接口對接,對我的開發者而言,路已經徹底卡死了。然而道高一尺,魔高一丈,聰明勤勞的國人想出了不少方法繞過這些限制。本文主要剖析當前具備可操做性的兩種方法,供有緣人蔘考決策。web
安卓端的支付寶,在收到收款消息時,會彈出收到 XX 元的應用欄通知消息。這個通知欄消息,是能夠經過編程手段獲取到的。只須要監聽用戶的通知欄消息,判斷是不是支付寶的通知,而後解析裏面的金額,就具備了自定義回調接口的基礎。編程
想像這樣一種場景:用戶A在網站發起100元的支付,而後網站後臺呈現100元的收款二維碼(這個二維碼能夠事先生成放在後臺)出來,用戶付款成功後,在商家的移動端,經過程序監控到支付寶收到了100元的訂單,而後給網站回調。ok,後續的流程和回調邏輯,能夠繼續作了。api
場景再複雜一點,那假如同一時間,有另一個用戶B也發起了100元的支付,可能尚未付款。同時商家移動端檢測到了一個100元的訂單,進行回調。因爲只有金額信息,網站後臺沒法區分這個100元的訂單,到底屬於用戶A,仍是屬於用戶B,一會兒就亂套了。涉及到錢的事都是大事,估計用戶得炸了。安全
這種併發場景,能夠經過一個很簡單的技巧解決,即當多個用戶發起同一金額的支付時,給不一樣的用戶,呈現不一樣的金額二維碼。好比上面的場景,用戶A,呈現100元的二維碼,同一時間用戶B發起100元的訂單支付請求,那就呈現99.99元的支付二維碼,用戶C再來,就呈現99.98元的支付二維碼,依次類推。這樣,移動端監測到的是不一樣的金額,所以也就具有了經過金額,區分訂單和用戶的能力。服務器
上面這種經過不一樣的金額實現回調的方式,缺點是很是明顯的,隨便列幾點:微信
經過金額區分訂單和用戶的方式實現支付接口回調,因爲原理簡單,實現成本並不高,所以如今市面上有大量基於該原理實現的支付接口平臺。列舉以下:併發
1.paysapi框架
點評:paysapi 官網提到支持微信。實際上是經過上傳一張任意金額的微信二維碼實現的。也就是用戶發起支付後,須要人肉的輸入支付金額,這在體驗上是比較差的。
2.goddpay高併發
點評:和 paysapi 的網站仍是一毛同樣。
3.支付吧性能
點評:無
移動端安卓平臺,是一個比較開放的平臺。咱們運行的幾乎全部軟件,都是能夠經過必定的手段,進行底層編程 hook,自定義其行爲的。好比微信消息防撤回,搖骰子划拳做弊,自動搶紅包,還有支付寶的餘額 & 等級自定義裝逼等功能,都是經過諸如 xposed, virtualxposed 等 hook 框架技術編程實現的。
一樣,微信和支付寶的收款二維碼自動生成,包括支付成功的消息檢測,也是能夠經過 hook 的手段,進行編程做業的。大體流程以下:
用戶發起訂單支付請求,而後移動端 hook 軟件,監測到這個支付請求,獲取到金額和平臺(微信仍是支付寶)信息。調用相關的軟件,注入相關的二維碼生成行爲,ok,相關金額的二維碼生成成功,再顯示給用戶。
用戶支付成功後,一樣的,不管是微信,仍是支付寶,都會檢測到相關的支付成功信息。移動端 hook 軟件,一樣也能夠檢測到。而後進行回調。再後續,就是業務系統處理流程邏輯了。
基於 hook 方式實現支付接口回調,對軟件開發者的要求較高。所以相關的解決方案並很少見,現簡單列舉以下:
點評:基於 virtualxposed。雖然網站幾乎和 paysapi 一毛同樣,但接口回調實現的原理,卻截然不同。另外,微米富還有一個特殊的地方,就是其在移動端 hook 軟件裏面,內置了一個微型的 web 服務器,直接接收並處理用戶的支付請求。這也致使了幾個問題,一是限於移動端 web 服務器的性能,併發的處理,有必定的限制。二是支付頁面的調整和定義,須要修改移動端代碼。三是軟件配置流程複雜(web 服務器代理相關的配置)。
點評:基於 virtualxposed。greenyep 和 微米富有一些細微的區別。它並未在移動端 hook 軟件裏面內置 web 服務器,而是採用定時檢測的方式,去後臺服務檢測訂單信息。這樣作的好處是能夠有一箇中心化的平臺作訂單的調度和統計,同時性能也較內置 web 服務器的方式,有必定的提升。缺點也是明顯的,並不方便軟件的分發,作一些私有化的部署。
正規渠道類
那到底有沒有一款產品能同時知足我的支付收款需求呢?
又能夠支持相對的高併發,低延遲,資金安全無風險,同時還不須要企業資質,用極低的成本獲得高效的回報。
答案是有的:https://h5zhifu.com
開戶只須要:1身份證 2對應的銀行卡(結算用) 3對應的實名認證的微信
十分鐘便可開戶,擁有正規的我的可用的商戶號和密鑰。
以上拙見,歡迎拍磚