1.微信服务商模式
1.1需要获取微信的单品优惠
微信官方文档说明想要获取单品优惠详情的接口，那么在付款码支付，扫码支付，以及查询订单是传入version参数，这样在响应参数中会多promation_detail字段，但是这个时候如果你想要获取商户实收的话，只能自己通过计算去获取，公式官方也有说明：商户实收=订单金额-免充值优惠；
1.2微信扫码支付问题
仅为jsapi支付模式
微信扫码支付是需要预下单，先请求服务商系统的接口获取单号，然后返回链接请求预下单接口，预下单接口获取到微信预下单的单号，然后进行参数组装以及签名返回，并且前端在发起支付请求，仅在微信中打开有效；
1.3微信回调问题
微信回调过来的是xml格式的数据，所以不能设置参数格式，其实就是一串字符串，可以采用(@RequestBody String xx)接收，并且post请求也可以；但是这里需要注意返回的单品优惠详情参数的解析，他的格式为
"promotion_detail": "{\"promotion_detail\":[{\"promotion_id\":\"9158610305\",\"name\":\"折扣免充值\",\"scope\":\"GLOBAL\",\"type\":\"DISCOUNT\",\"amount\":99,\"activity_id\":\"9808376\",\"wxpay_contribute\":0,\"merchant_contribute\":99,\"other_contribute\":0}]}"
所以做数据解析的时候需要注意
1.4微信退款的实退取值
跟支付时候一样，首先获取的为微信侧返回的结算金额，如果该字段没有返回，那么也是需要计算，公式同支付时一样，但是退款的优惠详情跟支付时候返回的优惠详情不一样，退款优惠数据格式如下：
"refundCouponDataList": [
{
"couponFee": "99",
"couponId": "9158559725",
"couponType": "NO_CASH"
}
],
1.5微信刷脸支付相关问题
微信刷脸的流程有2种模式：
第一种使用传统的刷脸码支付，face_code_type为0时，先获取服务商系统内的订单号，然后移动端获取rawdata参数，传递给后端，由后端发起请求获取authinfo，然后回传给移动端，移动端通过authinfo以及之前获取的订单号，换取face_code,然后请求服务商后端接口，注意：这里因为face_code_type=0，所以后端接口请求微信的接口为旧版刷脸支付接口，接口路径为：https://api.mch.weixin.qq.com/pay/facepay；
第二种使用付款码支付接口，face_code_type为1时，移动端直接获取rawdata，然后请求服务商后台换取authinfo，移动端获取到authinfo后请求微信接口换取face_code,注意：换取face_code的请求参数里的face_code_type必须等于1，然后调用服务商后台付款码支付接口；
个人觉得使用第二种方式进行刷脸支付，对原有系统改动最少，且能够达到一样的目标，且旧版刷脸支付接口的文档相对来说不是很齐全，并且可能其中存在别的坑，故推荐第二种模式；
1.6微信相关配置参数问题
appId：应用id
mchId：微信商户号
key：微信的签名秘钥，在微信商户后台里面设置
apiClientCertKey：证书的密码，默认为商户号
apiClientCertPath：你的证书路径，后缀名为.p12的文件
这里还需要注意2点：
1.6.1 扫码支付的回调url需要在微信商户后台里面设置好，且为有效域名，否则发起支付时，会报redirect_url不一致；
1.6.2 还有一点就是扫码支付时，预下单接口需要传入用户的openid参数，那么在下单之前，通过用户授权的code换取openid，需要去后台配置权限，否则无法获取到openid，也就无法进行支付；获取openid的请求路径为：https://api.weixin.qq.com/sns/oauth2/access_token?appid={appid}&secret={secret}&code={code}&grant_type=authorization_code
2.支付宝服务商
2.1支付宝商户授权问题
支付宝的商户授权很简单，直接拼接服务商的参数，然后转换成一个二维码，支付宝直接扫码授权，然后支付宝回调我们接口，通过支付宝回调的app_auth_code去请求支付宝接口换取app_auth_token，**注意该token有效为一年，最好将相关其余参数一起保存，防止后期token过去需要使用；链接：https://openauth.alipay.com/oauth2/appToAppAuth.htm?app_id=2015101400446982&redirect_uri=http%3A%2F%2Fexample.com；具体相关详情看官方文档https://docs.alipay.com/isv/10467/xldcyq
注意：这里后面有一个state的商户自定义参数，且对应的值必须为base64后的值，我这里拿来做对应商户的回传，不然支付宝回调的时候无法确定具体对应商户，当然看自己业务，可以不一样；
2.2支付宝回调接口问题
这个问题是在自己测试优惠相关问题时突然发现的，正常扫码支付的时候是可以回调的，这个没问题，但是当我将对订单进行部分退款的时候发现，支付宝又回调了我的接口，但是官方退款接口也没有说明会回调，多次测试后发现只有扫码支付的订单，退款时候才会回调，然后再去看扫码支付的文档也没有说明退款时候会回调我们接口，因为当时候回调接口里面只做了下单相关的业务逻辑，没有写退款的，所以这一点是支付宝没有说明的，很可能会导致数据不一致。
2.3支付宝文档中的参数问题
这也是在做优惠的时候发现的问题，支付宝官方文档（https://docs.open.alipay.com/api_1/alipay.trade.refund/
）上给的退款接口响应参数，没有说明会返回商户实退金额即send_back_fee，但是请求接口的时候发现实际上是返回了，但是在退款查询接口的文档里https://docs.open.alipay.com/api_1/alipay.trade.fastpay.refund.query/有说明这个字段的返回，虽然是否必填为否，但是实际上没有返回，由于支付宝的实退金额是无法计算得出，所以只能获取官方给的实退，原因在于支付宝的优惠无法区分免充值和预充值；这一点应该是支付宝可能将两个接口的参数返回弄反了；
2.4支付宝用户实付金额
这也是做优惠问题时遇到，支付宝给的用户实付金额是有问题的，它与我们理解的用户实际上支付的钱是不一样的，它这个金额里面会包含集分宝的金额，支付宝方面的解释是：因为集分宝的积分是属于用户的，那么这个就算是用户的实付，所以这样解释也没问题，但是这个对于我们的处理就不一样了，我们需要给出的是用户实际上支付的金额，所以说这里如果继续取支付宝返回的实付的话就会有问题，需要对优惠进行相关处理；
2.5支付宝退款单号问题
这个问题也是偶然发现的，在进行退款的时候，由于我们有对三方单号以及渠道号做了唯一索引，所以在退款单号入库的时候发现，支付宝的退款单号报了一个duplicate key的错误，然后查看数据发现，这个交易单号跟支付宝下单时候支付宝返回的交易单号是同一个，也就是支付宝退款的时候不会返回支付宝方面的退款单号，这里处理的时候就需要注意一下；支付宝退款优惠详情
"fundDetailItemList": [
{
"amount": "0.01",
"fundChannel": "ALIPAYACCOUNT"
},
{
"amount": "1.00",
"fundChannel": "MDISCOUNT"
}
]
