今天来讲讲支付。
工作到现在，接入过好几个项目的支付，其中涉及到了微信支付、支付宝支付、银联支付。
三种支付的对接感受其实整体上大同小异。都遵循同一个流程：
1)、商户APP向商户服务器请求生成订单
2)、商户服务器通过生成的订单编号向第三方支付平台请求签名信息返回给商户APP
3)、商户APP拿到授权签名信息向第三方支付平台调起支付
4)、用户支付完成
5)、第三方支付平台向商户服务器发起支付结果回调
6)、商户服务器根据回调信息处理业务逻辑
接下来谈谈对比。
1.文档和SDK对比
总体感受是支付宝的文档的SDK最好用。面向对象很舒服。
微信的开放平台/商户平台/公众平台初次接入者很容易混淆，搞不清楚哪个是哪个。
银联的demo很详细，基本不需作多大改动就可以拿来用，只不过在环境配置上多了几个证书，签名和验签时都需要证书，稍显麻烦。
2.前端调起支付所需参数对比
相比之下，支付宝的SDK最方便，把所有参数和方法都封装成了面向对象的方式，清晰易懂。
3.需要注意的地方
补充：
1.如果调起了支付，然后回到商户app取消了订单，此时再跳转到第三方支付页面去支付，并且支付成功了。这种情况，本来应该是请求第三方平台关闭订单，但是支付宝和微信都是在下单后的短时间内不能马上取消订单。解决办法是：在支付回调的方法里面加上判断，如果是错误或者重复支付，则退款给买家。
2.支付宝收到多个支付成功回调的问题：
支付宝的解释是：
只要交易状态发生改变，符合满足支付宝异步触发条件，就会发送异步通知；
其中，像即时到账，移动支付，手机网站支付等接口，默认都是支持3个月可退款的，支付成功之后，支付宝会发送一个trade_success（支付成功）的异步通知，3个月之后，此交易就不允许退款,此时支付宝会再次发送（trade_finished）的异步通知，因此会在3个月之后再次收到一次异步通知；
注意，只trade_success状态下处理自己的业务逻辑；
我遇到的问题是：如果调用了部分退款接口，会触发一个交易状态为TRADE_SUCCESS的支付成功回调回来。导致数据错乱。
解决办法：判断回调是否有返回退款参数，gmt_refund，refund_fee（退款时间和退款金额）这些，以此来区分是退款成功之后的回调还是正常支付完成的回调。
如果有朋友需要相关代码，可以留言。
收到代码的朋友，如果觉得我的文章帮助到了你，请酌情适当打赏楼主烟钱。
