前言
在国内环境，广大的个人站点及应用，因为业务发展需求，往往需要以个人资质申请对接微信和支付宝的支付渠道。然而现在无论是微信还是支付宝，仅支持具有企业资质的主体申请接口对接，对个人开发者而言，路已经完全卡死了。然而道高一尺，魔高一丈，聪明勤劳的国人想出了很多方法绕过这些限制。本文主要剖析当前具有可操作性的两种方法，供有缘人参考决策。
1. 通过金额
原理
安卓端的支付宝，在收到收款消息时，会弹出收到 XX 元的应用栏通知消息。这个通知栏消息，是可以通过编程手段获取到的。只需要监听用户的通知栏消息，判断是否是支付宝的通知，然后解析里面的金额，就具有了自定义回调接口的基础。
想像这样一种场景：用户A在网站发起100元的支付，然后网站后台呈现100元的收款二维码（这个二维码可以事先生成放在后台）出来，用户付款成功后，在商家的移动端，通过程序监控到支付宝收到了100元的订单，然后给网站回调。ok，后续的流程和回调逻辑，可以继续做了。
场景再复杂一点，那假如同一时间，有另外一个用户B也发起了100元的支付，可能还没有付款。同时商家移动端检测到了一个100元的订单，进行回调。由于只有金额信息，网站后台无法区分这个100元的订单，到底属于用户A，还是属于用户B，一下子就乱套了。涉及到钱的事都是大事，估计用户得炸了。
这种并发场景，可以通过一个很简单的技巧解决，即当多个用户发起同一金额的支付时，给不同的用户，呈现不同的金额二维码。比如上面的场景，用户A，呈现100元的二维码，同一时间用户B发起100元的订单支付请求，那就呈现99.99元的支付二维码，用户C再来，就呈现99.98元的支付二维码，依次类推。这样，移动端监测到的是不同的金额，因此也就具备了通过金额，区分订单和用户的能力。
优点
- 原理简单，实现简单。
- 账号比较安全，没有被支付宝风控的风险。
缺点
上面这种通过不同的金额实现回调的方式，缺点是非常明显的，随便列几点：
- 仅支持支付宝。微信的移动端通知消息里面，并不包含金额信息，因此这种方法就熄火了。
- 由于是通过金额进行订单和用户区分，因此需要提前上传收款二维码，包括用于应付并发场景的大量上下浮动的二维码。对于有大量定价的站点和应用，这个工作量是非常可观的。
- 不利于定价调整。每次定价调整，都需要上传大量收款二维码。
- 不支持任意金额。还是因为要事先上传收款二维码。
代表
通过金额区分订单和用户的方式实现支付接口回调，由于原理简单，实现成本并不高，因此现在市面上有大量基于该原理实现的支付接口平台。列举如下：
- paysapi
点评：paysapi 官网提到支持微信。其实是通过上传一张任意金额的微信二维码实现的。也就是用户发起支付后，需要人肉的输入支付金额，这在体验上是比较差的。
- 虎皮椒
点评：和 paysapi 的网站一毛一样。
- goddpay
点评：和 paysapi 的网站还是一毛一样。
- 支付吧
点评：无
2. 移动端 hook
原理
移动端安卓平台，是一个比较开放的平台。我们运行的几乎所有软件，都是可以通过一定的手段，进行底层编程 hook，自定义其行为的。比如微信消息防撤回，摇骰子划拳作弊，自动抢红包，还有支付宝的余额 & 等级自定义装逼等功能，都是通过诸如 xposed, virtualxposed 等 hook 框架技术编程实现的。
同样，微信和支付宝的收款二维码自动生成，包括支付成功的消息检测，也是可以通过 hook 的手段，进行编程作业的。大致流程如下：
用户发起订单支付请求，然后移动端 hook 软件，监测到这个支付请求，获取到金额和平台（微信还是支付宝）信息。调用相关的软件，注入相关的二维码生成行为，ok，相关金额的二维码生成成功，再显示给用户。
用户支付成功后，同样的，不论是微信，还是支付宝，都会检测到相关的支付成功信息。移动端 hook 软件，同样也可以检测到。然后进行回调。再后续，就是业务系统处理流程逻辑了。
缺点
- 需要安装移动端 hook 框架，比如 xposed, virtualxposed 等。其中，xposed 软件，还要求系统必须 root。
- 存在一定的安全风险。因为 hook 软件，可以监测到微信和支付宝的软件行为，包括你的密码信息，因此存在一定的安全风险。
- 账号存在被风控的可能。不论是微信还是支付宝，对自家软件被自定义的行为，都是零容忍的。
优点
- 与上述通过金额实现回调的方式比起来，这种方式有明显的优点，就是不需要提前上传大量二维码，支持任意金额的支付处理。
- 同时支持微信和支付宝。
- 并发能力，可以相对做到比较高。
代表
基于 hook 方式实现支付接口回调，对软件开发者的要求较高。因此相关的解决方案并不多见，现简单列举如下：
- 微米富
点评：基于 virtualxposed。虽然网站几乎和 paysapi 一毛一样，但接口回调实现的原理，却大相径庭。另外，微米富还有一个特殊的地方，就是其在移动端 hook 软件里面，内置了一个微型的 web 服务器，直接接收并处理用户的支付请求。这也导致了几个问题，一是限于移动端 web 服务器的性能，并发的处理，有一定的限制。二是支付页面的调整和定义，需要修改移动端代码。三是软件配置流程复杂（web 服务器代理相关的配置）。
- greenyep
点评：基于 virtualxposed。greenyep 和 微米富有一些细微的区别。它并未在移动端 hook 软件里面内置 web 服务器，而是采用定时检测的方式，去后台服务检测订单信息。这样做的好处是可以有一个中心化的平台做订单的调度和统计，同时性能也较内置 web 服务器的方式，有一定的提高。缺点也是明显的，并不方便软件的分发，做一些私有化的部署。
建议
- 如果站点和应用的支付场景比较简单，同时对微信支付没有强需求，可以考虑诸如 paysapi 等通过金额进行区分实现接口回调的平台。
- 如果对安全及风险敏感度较高，同样建议考虑 paysapi 等平台。
- 如果支付场景比较复杂，需要支持任意金额，同时对微信和支付宝渠道均有需求，可以考虑诸如微米富，greenyep 等平台。
- 接上，如果对系统稳定性，并发能力要求较高，可以考虑 greenyep 平台。
- 接上，如果期望私有部署的便捷性，可以考虑微米富平台。
以上拙见，欢迎拍砖。也可以直接与作者取得联系探讨：353066897@qq.com
来源：oschina
链接：https://my.oschina.net/u/4020046/blog/2874441