微信支付 服务商的支持

[krissss]

问题描述

非问题，是建议

代码

无

报错详情

无

说明

当前好像没有对微信服务商的支持，服务商文档，服务商大部分接口都一致，只是对应的多了一层 sub_appid 和 sub_mch_id

[yansongda]

您好，由于业务限制。想知道在实际支付情况下，子商户号、子商户公众账号ID是否是一个变量？

因为我的理解，子商户全部是服务商的一个代理，然后子商户支付的时候向服务商请求调用 API 。

请问我的理解是否正确？

如果是这样的话，无论是以前的 1.x 版本还是现有的 v2.x 版都不需要进行更改了，已经原生支持了，只需要在 $order 中传入sub_mch_id、sub_appid 即可？

[krissss]

@yansongda 没太明白你的意思。

子商户全部是服务商的一个代理，然后子商户支付的时候向服务商请求调用 API

请问这句怎么解释，具体的业务是怎么实现处理呢？

因为我这边做服务商支付的时候基本全部是由子商户应用自己实现完全的支付的，所以调用的时候貌似没走子商户向服务商请求调用API

[yansongda]

其实主要是我对服务商版的应用场景不熟悉。

请问服务商版，目前您那边的流程是什么？

[krissss]

@yansongda 首先A公司会通过一个服务号，申请成为微信服务商，然后A可以帮B公司开通子商户（包括提交材料，审核等等操作），以后B的所有微信支付都可以通过该子商户处理，拿B的公众号举例，原来B需要在公众号后台申请微信支付，现在不需要了，子商户处可以开通

商户后台配置如下：

[krissss]

@yansongda 然后是文档上的区别 服务商版，普通商户

主要区别如下：

统一下单处的配置区别：

1. 服务商模式下的 appid 和 mch_id 均为 A 的公众号 appid 和 mch_id
2. 增加子商户的 sub_appid 和 sub_mch_id，其中 sub_appid 根据你最终是使用 sub_openid 还是 openid 会存在选填和必填的区别，像 APP 支付 和 小程序支付 该 sub_appid 就是必填的
3. 额外的 sub_openid 指用户在B公众号下的 openid， openid 指用户在 A 公众号下的 openid
4. 其他几个支付方式大多也都是这三个参数的区别
5. 服务商模式下的 key 为 A 的key，这点也特别需要注意

[krissss]

@yansongda 我想了下，按你前面说的，在 $order 中传的话，应该是可以的（我等下去试下），但是就是会比较奇怪，原因如下：

不论调用哪种支付方式，配置的 appid app_id miniapp_id 都是 A 公司的，然后再在 $order 里传递 B 公司的 sub_appid，这样子岂不是失去了配置的意义。。。

[yansongda]

了解了，这样一说就明白很多了。谢谢您！

其实也不复杂，就是参数的问题。有大致思路了。

目前我想到的思路有2中：

1、通过 mode 参数去做相关客观参数的增加，比如sub_appid,sub_mch_id。（仅适用 v2.x ）

2、判断 config 中是否有sub_appid,sub_mch_id 等客观参数，如果有，则自动增加。

不知您的思路是什么。如果您时间上充裕的话，还麻烦您 PR 下，我估计晚些时候才能开发这个功能了。:)

[yansongda]

@krissss 是的，开始我并不清楚整个服务商的运作流程，在 order 中传参一定是可以实现功能的，但是向您说的那样失去了配置的意义，并不优雅。

[krissss]

@yansongda 这个 PR 再看吧，因为之前一段时间没看这个，您这已经开发到2.0了，可能代码我得重新看，需要点时间

[krissss]

v2 support #82

[wly1456839489]

你好，有微信服务商支付的例子吗，可以贴一个出来吗