微信银行服务商对接避坑指南-技术圈

Hello ，大家好，我是楼下小黑哥~

这篇文章主要梳理一下微信银行服务商下几个主要参数的概念、作用。总结一下对接过程中碰到相关设置的问题。

那这些参数，看起来挺简单的，但是有些场景下，需要在后台增加相关配置。如果不配置的话，就会报各种错误，无法唤起支付。

但是配置的话，对于第一次接触的小伙伴，极度不友好。这些配置有些是可以在微信支付官网找到的，但是这个查找过程挺费劲的。

所以这里总结一下，希望帮助到后续对接微信银行服务商的小伙伴们。

ps:这篇文章主要是以银联微信的文档为主，原则上网联微信应该是差不多的。

微信支付参数解释

微信支付的交易请求将会涉及一些微信特有的参数，像微信普通商户交易请求，只涉及 appid 与 mch_id,这个参数概念比较简单，比较容易。

但是在微信银行服务商版本，微信交易参数就很多,主要为以下七个参数：

appid
mch_id
sub_appid
sub_mch_id
channel_id
openid
sub_openid

这五个参数，概念其实比较简单，但是混杂一起就是比较绕，下面我们详细解释一下。

appid

这里的 appid 银联文档解释为微信分配的公众账号ID，也就是微信公众号 appid。但是实际上我们使用的过程中发现，这个 appid 也可以是相同主体的微信小程序的 appid。

但是这里有个前提，我们必须在服务商后台绑定这个 appid。

绑定页面如下：

其他限制如下：

服务商/渠道商/从业机构可以关联主体一致的 appid 帐号，不支持关联主体不一致的AppID帐号；
服务商/渠道商/从业机构最多可关联 3 个 appid 帐号；
当商户号或 appid 帐号存在风险时，包括但不限于帐号资料不全，有处罚单据未处理等，平台可能会增加审核流程或限制新增关联。

相关详情可以查看服务商商户号与AppID账号关联管理，地址如下：

https://kf.qq.com/faq/200520fueQrI200520aQf6Rr.html

mch_id 与 sub_mch_id

这两个参数的概念比较简单，也没有其他用法。

mch_id 就是微信分配给服务商的商户号，而 sub_mch_id 就是微信分配给服务商下特约商户的商户号，两者关系如下所示：

服务商每笔交易这两个参数都是必送。

sub_appid

特约商户 appid 配置

sub_appid 银联文档上是微信分配给服务商下的子商户号的 appid。那这个 appid 可以是公众号 appid,也可以小程序 appid。

绑定页面如下：

子商户可以绑定的相同主体的 appid ，也可以绑定不同主体的 appid。那绑定主体不一致的 appid，比较麻烦，详情参考下面这个链接：

https://kf.qq.com/faq/190715yaYnYv1907153mmIbA.html

另外需要说明一点，sub_appid 不是必传的参数，交易过程中可以不用传入这个参数。

如果不传这个 sub_appid，JSAPI 等微信交易唤起微信支付交易参数只会包含服务商的 appid，如果特约商户需要在自己的公众号或小程序内进行微信支付，使用微信 JSSDK 唤起微信支付将会报错。

这种情况微信交易必须上传 sub_appid 。

此外，如果我们在后台绑定了子商户的 appid,那交易过程中就必须上传 sub_appid,否则微信交易就会出错。

支付目录设置

微信 JSAPI 支付在微信环境内唤起微信支付，我们需要提前设置『支付目录』。

这个支付目录其实就是商户最后请求拉起微信支付收银台的页面地址，如果商户拉起微信支付收银台地址与后台设置的不一样，拉起的时候就弹出报错，提示“当前页面的URL未注册。”

服务商模式支付目录设置可分为2种方式：

服务商为全体子商户设置支付目录需要登录【微信服务商平台—>产品中心—>开发配置】，设置后一般5分钟内生效。

这种模式适合不传入 sub_appid 进行交易的场景。

那服务商为某一子商户单独设置支付目录需要登录【微信服务商平台—>服务商功能—>特约商户管理】，设置后一般5分钟内生效。

微信相关参考文档：

https://pay.weixin.qq.com/wiki/doc/apiv3_partner/open/pay/chapter2_1.shtml
https://pay.weixin.qq.com/wiki/doc/api/jsapi_sl.php?chapter=7_9&index=7

channel_id

channel_id 是银行服务商独有的参数，银联文档解释为微信支付分配给收单服务商 id，这个解释其实比较抽象，比较难以理解这个参数的目的。

channel_id 还有一个另外一个名称，渠道商 id。那微信特约商户进件的时候，就需要传入 channel_id，表明这个特约商户属于哪个渠道商。

渠道商指的是帮助银行拓展和运营特约商户的公司，可以分为三种类型:

普通类渠道商,指无第三方支付牌照、拓展微信支付商户的企业
支付机构类渠道商,指持有第三方支付牌照、拓展微信支付商户的支付机构。
银行类渠道商

银行类渠道商比较特殊，他指是拓展微信支付商户的银行主体，若子商户是该银行服务商自拓的商户，则渠道商为银行自身，银行需要在商户平台将自身进件为直拓渠道。

若商户为银行下属分行或者支行或者其他银行拓展的，则需要将其下属分行或者支行或者其他银行进件成为渠道商。

如某银行总行 A（银行服务商)有自拓子商户 B，有其分行 C 拓展的子商户 D，也有某信用社 E 拓展的子商户 F，则子商户 B 的渠道是 A，子商户 D 的渠道是 C，子商户 F 的渠道是 E。

银行 A 需要将自身、分行 C 以及信用社 E 进件成为渠道商。

服务商每笔交易都必须上送 channel_id。

openid 与 sub_openid

openid 是微信体系内的用户标识，它与 appid 有一定的绑定关系，相同的用户在不同 appid 下 openid 将会是不一样的。

那这里的 openid 需要通过服务商主体 appid 登录授权才能获取，而 sub_openid 需要通过子商户的 appid，即 sub_appid 登录授权才能获取。

微信文档上描述，如果传入 sub_openid ，那就必须传入 sub_appid。

但是实际测试过程中发现，发现以下几个问题，

一、传入 sub_openid ，不传入 sub_appid，并不会报错，交易可以继续进行。并且这里传入的 sub_openid 可以是任意 appid 下获取的 openid，微信端并不校验这个 sub_openid 有效性。

二、这套逻辑并不适用 openid 这个字段。openid 这个字段，一定要传入 appid 下获取的 openid 字段，否则交易将会返回『openid和appid不匹配』。