后台用的fastadmin，它自己带了一套easywechat 4.x的扩展，基于这个基础上做的分账。
主要是记录思路和踩坑。
用的不是v3的文档哈，链接在这里
其实我踩的坑大部分是配置问题，什么是主商户，什么是子商户，各种appid,mch_id又是啥啥啥。搞清楚了配置就比较顺当了
用我们项目需求来举例，我们的需求做多商户商城平台，邀请子商户入驻，收取订单服务费；
所以主商户=我们平台=服务商
需要理解的是，主商户是不收钱的，它只是作为一个发起分账的平台
在easywechat里面，主商户的配置如下：
平台子商户==特约商户：
在文档里面的标记是：sub_mch_id（子商户的商户号），sub_appid（子商户绑定的微信公众账号id）
我们按照以下流程来做分账的功能：
1.添加分账方
因为文档没有给查询分账方list的接口，我选择在添加成功后直接写到数据库里面
添加分账方的参数如下：
这里的坑点是文档中对sub_appid参数的必填属性设置为否，其实是误导理解的，当分账方的类型为子商户的appid得到的openid的时候，是需要传这个参数的。
所以如果你的请求返回异常的话，先检查那四个参数（主商户和子商户分别的appid和商户号）是否正确传入
其他的文档就写得比较清楚了。
但是有一点坑的是：只要你参数传正确了，重复添加分账方它也会返回success，删除一个不存在的分账方，它也会返回success
2.请求单次分账
踩过了第一步的坑之后，这里已经进入正常状态了，坑点是如果分账方数据有不合规范的话，请求结果会告诉你：分账接收方类型不合法，但是其实我是amount的参数没有传分，传了带小数点的元。
3.关于子商户和服务商的关系的理解
服务商相当于一个中间人，普通商户要委托服务商做事，就要成为服务商的特约商户，授权给服务商，服务商可以为特约商户添加平台appid作为支付媒介，服务商本体不收钱，就作为一个中间平台，在多商户商城的场景中，商户绑定自己的商户号，统一下单接口传参数表示允许分账，在订单完全结束后发起分账，发起分账的时候，sub_mch_id==商家自己的商户号；
在easywechat4.x中使用，实例化参数（服务商的各项信息）不变，sub_mch_id跟随商家变化而变化，个人粗俗理解为：服务商要为哪个商户做事，sub_mch_openid就填写哪个商户号
4.关于退款
众所周知退款是需要证书的，我的多商户支付，退款讲道理也是各自的证书去退款，但是居然报错了 ，给我说证书验证失败（在这之前是签名错误，经过排查后将签名的key改为主商户的支付密钥），然后将证书改为主商户证书，验证成功，成功退款
（所以我根本不需要子商户自己上传证书啊卧槽...）
5.关于商户后台配置
有一个服务商JSAPI支付要开通，并让子商户授权
这个没开通的话会报错：服务商商户号未开通该产品权限，子商户没授权的话会报错：特约商户未授权该产品
如果想要开通这个，必须要先开通服务商本身的jsapi支付，然后随意填写一个回调地址，然后这个服务商JSAPI支付的设置才会显示出来！！！！