0%

Tom 商店-间连多渠道支付

在介绍项目中使用的间连多渠道支付业务前,我们先了解下支付场景上不同服务商类型的区别,即直连模式和间连模式。

1. 直连与间连差异

这里仅比较微信支付和支付宝的直连和间连,不做其他方面比较

  • “直连”是指商户自己注册或通过官方认证的普通服务商开通对接的微信支付和支付宝支付。
  • “间连”是指商户借助其他持牌支付机构/银行,通过银联、网联与微信支付/支付宝实现连接。

  • 账户侧机构:支付宝、微信支付等(有支付牌照+有面向C端用户的App+App有钱包功能+对其他支付机构开放)
  • 收单侧机构:能给商户开特约商户号用于收单的机构,泛指所有第三方支付机构(有时候为了区别于账户侧机构可特指非账户侧的支付机构)。
  • 清算机构:银联、网联

银行与银行之间构成清算关系,银行内部以及银行与商户、消费者之间构成结算关系,清算完成银行间债权债务关系清偿,结算完成银行、商户与消费者之间债权债务关系清偿。

微信支付和支付宝有部分能力是没有对其他支付机构和银行开放的(即不支持间连),但有替代方案可弥补:

以微信APP支付为例,微信 APP 本身不具备支持间连支付的能力,替代的方案即是商户需要自行开发支付商户小程序以此唤起微信小程序进行支付。

间连和直连在费率、收单和分账方面也有很多不同,详见下表:

比较项目直连模式间连模式
费率标准优惠
收单不同支付方式,收款账户不同,分别进入微信支付商户平台和企业支付宝统一汇总在一个商户号,方便管理和对账
分账单一支付方式分账,且分账比例受限聚合支付统一分账,分账比例不限

2. 项目间连支付

2.1 业务实现流程

在项目上,目前以平安银行作为收单侧机构同时支持微信、支付宝和云闪付等多个渠道的间连支付能力。商户系统使用聚鑫支付系统作为提供统一调用接口请求到下游第三个方支付机构。

下面以微信/支付宝间连支付的实际项目应用场景为例介绍其业务流程,具体业务流程图如下所示:

微信/支付宝间连支付流程

名词释义:

  • 商户支付小程序:由于微信支付宝本身不具备间连支付能力,因此需要商户自行开发支付小程序
  • 渠道支付系统:泛指微信、支付宝渠道支付系统

重点步骤说明:

步骤4 :商户支付后台会根据订单类型、间连子商户配置开关和用户灰度等开关机制判断是否支持间连模式支付,然后初始化生成支付单信息,此时商户支付后台由于缺少支付小程序的支付用户信息(如微信的 wxOpenId),因此暂时无法调用下游第三方支付机构获取预支付单。

步骤8 :终端跳转至商户支付小程序后才真正调用第三方支付机构的下单接口获取预支付单信息,并由商户小程序调用 SDK 拉起收银台进行支付。

步骤20-22 :不同于 APP 支付,由于是跳转到小程序进行支付操作,一般情况下终端是无法接收到小程序端 SDK 的支付结果回调的,因此终端 APP 无法感知小程序端的支付情况。因此当用户以后台应用切换的方式从商户支付小程序切至商户APP时,APP需以弹窗的交互形式让用户自行点击查询支付结果。不过对于微信小程序支付则存在特例,由于微信支付小程序支付页面存在“返回商户APP”的按钮,如果用户点击该按钮跳回APP则可以告知终端小程序端的支付结果。

2.2 支付降级策略

目前项目中同时也支持直连多渠道合并支付(详见:Tom 商店-直连多渠道支付流程),为了提高商户支付系统的健壮性,当间连支付出现支付失败、第三方机构风控等场景时需要支持自动降级切换成直连支付渠道。

观察上图 微信/支付宝间连支付流程, 我们在部分支付关键节点标识了红色序号,在这些关键节点会进行支付事件上报,例如步骤③则是终端 APP 跳转至支付小程序的上报节点,如果此时上报跳转失败事件,那么当用户进行二次支付时,后台会根据上报结果自动从间连支付模式切换至直连支付模式。

------ 本文结束------