如何尽可能简单的对接微信支付
作为一名长时间跟微信支付对接过的程序猿，可以说对微信支付是极为熟悉的了。
微信支付提供如下多种对接方式：
以上截图来自于微信支付对接文档，侵删。
如何选择对接方式和降低对接微信支付的成本，或许是许多程序猿或公司在思考的问题。
而我的建议则是：只选择H5支付与Native支付
1、H5支付
H5支付的使用场景要比诸如APP支付等的要多，首先H5支付是可以在APP中使用的，虽然微信官网推荐APP中使用APP支付，但是在APP中使用H5支付是不会有任何适配性等问题的，而且H5支付还可以在手机端的任何网页中使用（如果该网页在PC打开，那么就没办法使用了），通过下单后获得的链接跳转过去，都会唤醒用户安装的微信APP完成支付。
温馨提醒：H5的跳转链接是有域名限制的，在微信支付的后台管理中，有一个地方可设置可用的域名，最多5个，如下图所示。
跳转的时候，如果使用该支付的页面本身就是配置中的域名之一，那么可以直接跳转；如果是在APP上使用，则需要在referer中设置为配置中的域名之一。
Referer小课堂：
Referer 是 HTTP 请求 header 的一部分，当浏览器（或者模拟浏览器行为）向 web 服务器发送请求的时候，头信息里有包含 Referer 。比如我在 www.toknow.top 里有一个 https://api.mch.weixin.qq.com 链接，那么点击这个 https://api.mch.weixin.qq.com ，它的 header 信息里就有： Referer=http://www.toknow.top
由此可以看出，Referer 就是一个来源标记。
所以，如果对接了H5支付，那么其实可以应对任何在手机端的支付，例如：APP端、网页端（手机端打开）、公众号等跳转的页面。这么一来，就可以避免对接多个支付方式导致后期难以维护等问题，也实现了“一次对接，多处使用”，可谓是一举多得。
2、Native支付
H5支付搞定了手机端，还有PC端怎么办呢？使用Native支付就行了。
Native支付就是把下单后获得的类似url的信息生成一个二维码显示即可，用户使用微信的扫一扫来扫描这个二维码就可以付钱了。
Native支付的对接非常简单，当然这个简单是建立在对接完H5的基础上的，因为Native支付跟H5支付只有一个参数的区别。
即 trade_type 参数：
值为 MWEB：表示 H5支付，跳转链接在 mweb_url 参数中返回；
值为 NATIVE：表示 Native支付，可生成二维码的信息在 code_url 参数中返回；
这样一来，就基本解决了微信支付在任何终端上的使用了，极为省事。
3、回调
订单被支付后，微信会分多次回调通知我们的服务端，我们在下单时就会把该回调接口的全称发送给微信支付，下次就会回调到该接口中了。
这里最少存在两个问题：
一是：如果某企业或单位会在多个产品中使用到微信支付，那么我们岂不是需要在各个产品中都复制一套相同的代码？这种情况建议是单独创建一个支付服务，所有的产品都通过该服务来使用微信支付，微信支付每次回调也都是回调到该服务的某个接口上去，我们再在该接口上回调到各个产品中去即可。
上述方式看起来好像只是多了一层封装，实际的回调处理好像还是需要在各个产品中做处理的——这说法完全没有毛病，但是上述方式可以封装成一个通用的回调格式，任何使用了支付通道的产品，回调时都会以相同的格式回调。以后需要拓展其他支付时，例如支付宝支付或网银支付等其他支付，他们的回调都是千奇百怪的，但是他们也都按照该格式来回调，那么使用支付通道的产品就能更加优雅的对接所有的支付渠道了。
二是：微信支付回调会有多次，所以使用支付的产品需要能够应对多次回调不会重复操作的问题。
4、查询回调
虽然微信支付的回调是多次异步的回调，但是微信支付是没办法保证100%通知到我们的，诸如网络异常或其他代码异常等未知的问题，总会在偶尔的情况下使得某个已支付的订单没有通知到位，这时候需要调用微信的订单查询方法去查询订单，如果已经成功支付，那么就再回调一次。
上述做法虽然是需要手动去操作，但是已经能够应该这种偶发性的问题；如果依然嫌弃这种手动操作，或许可以考虑做个消息队列或其他缓存机制来解决。
5、一站式解决方案
上述解决方案已经能完美解决微信支付的使用问题，完全可以根据这个思路做出一个专注微信支付的微服务来；
但是，如果你希望获得完全由笔者设计完成的微信支付中间件，可以与笔者联系，笔者将提供可直接使用的安装包（基于Spring Boot的jar包）并提供技术支持；
该微信支付中间件将包括SSL加密（需要客户提供）、接口防篡改签名等安全技术防护；
使用该中间件不仅安全无忧，而且大大节省开发时间。
