• Home

如何在不同主体的小程序和商户上发起微信支付

小龙同学

最近在负责一个市级的政府医疗门户小程序,涉及到线上的支付。过程中遇到了不少的坑,这里记录下来希望对你有用:)

问题

先说下背景,小程序的主体是卫健委,连接了市级的N家医院,每家医院都在微信平台申请了支付的商户号。小程序的很多业务(挂号,门诊,住院等)都涉及到线上的支付。

不同于公众号的H5支付,H5支付在后台调用统一下单的时候需要获得用户的openid,前端可以调用微信的jsapi得到code发给后端,再由后端调用微信接口获得该用户的openid从而发起支付。这里要注意的是,即使用户没有关注该支付商户的公众号,后端也能获得用户的openid,原因在于这里实际上做了一次静默授权(scope=snsapi_base,用户无需点击授权并自动跳转至回调页)

小程序和H5的统一下单接口本质上是一样的,也需要openid,不幸的是,小程序没法像前端那样通过调用jsapi获得code,因为所有以api.weixin.qq.com为域名的HTTP都无法请求,因此套用H5的方式是行不通的。

那么如何在小程序调起微信支付呢?

关键在于openid的获得,不同的支付模式下openid的获取都不一样。

普通模式

这是最简单的模式,小程序和收款商户拥有同一个主体,那么就可以直连收款了。openid也就是当前在小程序支付用户的openid

由于小程序的主体(卫健委)和各医院不是一个主体,所以普通模式下单是不行的。

联合运营模式

普通模式真的不行吗?其实也可以。

微信提供了一种叫做联合运营的模式,相当于把主体不同的公众号和商户绑定在一起,看起来就成了一个主体,就可以通过普通模式进行统一下单了。这里的openid也即当前在小程序支付用户的。

需要注意的是联合运营的申请需要准备不少微信,卫健委和不同医院的材料,耗时较长(我们在内部花了一周的时间)。

申请下来就按照普通模式开发就好了。

服务商模式

服务商模式相当于一个第三方代理(有自己的商户号),医院把自己的商户号挂在服务商那(作为子商户号),小程序只需要和服务商进行支付(前提是在服务商关联小程序)。统一下单的时候涉及到的几个关键字段:

  • appid: 服务商APPID
  • mch_id: 服务商商户号
  • sub_appid: 当前调起支付的小程序APPID
  • sub_mch_id: 子商户号(也即收款的医院)
  • sub_openid: 当前调起支付的用户的小程序的openid

这里的sub_openid怎么获取困扰了我们很久,我们不得已才走了联合运营那条路。后来经过和微信团队的沟通,发现这个sub_openid原来就是用户在小程序的!

联合运营 vs. 服务商

我到底应该选择那种模式?

首先,两种模式都需要申请,来来回回流程都挺长。具体流程是商务的同事去做的,大伙可以网上查或者咨询微信。我们只谈谈在开发和运营上孰优孰劣。

开发上,可能会觉得联合模式会简单些,因为就和普通模式一样嘛。

其实不然。

普通模式下,调用微信支付提供的接口,你需要收集各家医院的证书密钥,且不说别人愿意给你,维护成本也挺高的。

然后对账也是个问题。正因为和普通模式一样,通过商户号去调用微信接口拉去对账单时,你拉到的是这个商户号全部的订单。有什么问题?如果医院在其他地方也委托其他的服务商或者自己(通过普通模式)收款,三者拉到的对账单都是一样的。举个栗子,同一个房间,好几个人都有钥匙,看到不该看的东西,很不安全,对账也是个麻烦事。

服务商模式就能很好的规避这些问题。

所以最终我们还是会从联合运营模式转到服务商模式。

致谢

感谢几位同事的审阅,尤其是陆同学提供的题图:)

🏷 小程序  🏷 微信支付  
© cc-40-by