感觉很多程序都是只要一有关钱这一方面，我磨磨唧唧，文档也写的简直了！
前排提示：微信文档坑很多，在没有前辈或者有经验的情况下，千万不要死怼代码，一个人思考，最好遇到问题直接去找微信客服，发邮箱就发邮箱嘛~~~
微信openId那一块，磨磨唧唧的弄完后，明明APP还没有支持会员系统，就已经叫我去弄微信支付充值会员了~~~（什么鬼~~~）
看了两天微信文档，结果翻来翻去就那两种方法，简直无奈啊~~~
其一：JS-SDK，文档接口https://mp.weixin.qq.com/wiki?t=resource/res_main&id=mp1421141115
这种方式跟微信分享那一块差不多，先插入JS文件http://res.wx.qq.com/open/js/jweixin-1.2.0.js，这个是动态网站，直接添加就是了！
然后自己先弄一个签名，签名怎么弄呢，其实问下文档附录1写的很清楚的！如图
签名需要jsapi_ticket，而jsapi_ticket需要通过access_token获取，access_token的获取方式就是一个坑了，微信授权那有一个access_token，而基本配置那也有一个access_token，两个token，我们获取的当然不会是授权的那个了（什么！你说为什么不是授权的那个？TM我测试的十几次，我当然知道了~~~~~~）
基本配置那的access_token获取方式非常简单，知道APPID，和APP密码（开发者ID和开发者密码），调用微信提供的API接口就可以返回你需要的access_token了！
文档接口：https://mp.weixin.qq.com/wiki?t=resource/res_main&id=mp1421140183
咋一看是不是很简单，然后呢，这又是一个坑！access_token获取是不能在前台上获取的，因为在前台获取的话，APPID和appsecret都能被人看到的，为了安全起见，也就是保险，这个只能在后台获取，接口参数这些也很简单，跟后台吱呼一声，让他写个接口，然后我们这边调用获取到access_token后就更简单了，直接调微信接口按照参数把access_token写进去就能获取到我们需要的jsapi_ticket了！
接口格式： https://api.weixin.qq.com/cgi-bin/ticket/getticket?access_token=ACCESS_TOKEN&type=jsapi
然后值得注意的就是access_token和jsapi_ticket的存在时间都是7200秒也就是2小时。最好是叫后台获取到access_token后在服务器端缓存一下，不然会造成数据流失异常（但是这个异常我到现在都没有遇到过~~~~）！
有了jsapi_ticket后，我们就要进入另一个微信坑了，简直就是天坑啊，简直了~~~~
话不多说，直接上图，签名~~~，前端签名这个东东是真的恼火，但是这块倒也不是很难，现在网上找几个封装好了的时间轴方法，随机数方法，然后按照ASCII从小到大排序，基本上也可以获取的到。
接下来就是另一个坑人游戏了，统一下单！
文档入口：https://pay.weixin.qq.com/wiki/doc/api/jsapi.php?chapter=9_1
统一下单最开始我还以为也是前端调用接口，然后获取的，直到无论如何都获取不到后，各种度娘文档论坛发现都是后台获取的，然后我一脸懵逼的交给了后台，才发现，原来事情并不是那么简单！
看到没有！看到我话红线的地方没有？上面写的什么？开户成功后，要想进行微信支付，必须要接入沙箱测试，验收完沙箱的所有用例后，才能进行审核，审核完毕后才可以进行正式的上/下交易~~~~
这说明了什么，说明必须要用沙箱测试，用沙箱测试制造假的key用假的key调用统一下单，调用完下单后，收到微信返回的数据sign，然后用sign再进行一次签名，然后再将签名给前台，然后...........然后就一脸懵逼了.......
用沙箱是的的确确调用统一下单能够成功返回的，但是呢，但是统一下单返回数据中最重要的prepay_id参数用于是错的，永远只有22位，少了后面的total_fee以及一些其他参数的拼装集合！
然后我和后台java就一脸懵逼了，各种测试，各种鼓膜，各种度娘，永远是错，一直到我这边实在熬不住了去找微信客服，然后微信客服又叫我发邮件去他们那边的技术相关~~~然后收到了一条回信！！
这是什么意思？？？什么鬼，微信文档写着必须走沙箱，测试全部通过才能走正式，微信技术支持说，管毛的沙箱，直接走正式环境~~~~~~辣子的时间啊，辣子的脑细胞啊~~~~~
一场闹剧闹了整整一周的时间，我能说什么~~~
然后统一下单需要注意的一点
是微信公众号支付的话openId是必须传入的，否则微信无法确认是公众号对应的是哪一个用户！
还有就是我们前端这边，第一步完成后，第二部传入的prepay_id的格式必须是package："=***********"；
只要格式不对，就一定会报错！
然后这里的paySign也是一个坑，这里的paySign很容易让人误解是统一下单中的sign返回参数，其实不然，统一下单返回的参数中，我们只用得到prepay_id这个，其他的对于我们前台来说，一个也没用，这里的paySign是支付签名，由后台用统一下单的签名方式生成！千万不要搞错
然后我们这边的微信签名接口对应的参数，全部都是最后一次后台签名paySign中对应的参数！
这些全部获取好了，直接按照微信文档格式写就OK~~~~
这是第一种方式，而第二种方式确实没什么区别，只是不需要那么繁琐，直接调用然后完成就OK！但是最后需要的参数，跟第一种方式也是一样的，后台代码不会有改变!
第二种只是接口名不一样，然后要传入的参数多一个APPID其他的全部都跟第一种需要的参数和获取方法一模一样！
这边是我写的：
画红线的地方是绝对需要再三检查的，只要格式有一丁点不对劲，都一定会错。
然后我这里有一个非常好检查错误的方法，微信公众号支付一定要用IOS来测试。
IOS会根据如图从上到下的顺序报错~~~~~~~
最后再说一次，千万不要用沙箱测试，那玩意有毒，用了永远报错，直接走正式环境~~~~~