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

前言

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

1.經過金額

原理

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

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

場景再複雜一點，那假如同一時間，有另一個用戶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對應的實名認證的微信
十分鐘便可開戶，擁有正規的我的可用的商戶號和密鑰。

以上拙見，歡迎拍磚