通联支付对接小技巧——汇入金接入介绍及流程设计

简介#

本篇文章我们来聊一聊通联的一款支付产品 —— 汇入金。

为了满足客户大额支付需求,丰富客户的支付渠道,同时解决通道限额等问题,通联推出大额支付产品:汇入金

汇入金 的原理就是用户通过网银支付,线下汇款给通联的备付金子账号(需要提前开通该子账号,该子账号和通联的用户关联),云商通收到款项以后,作上账处理,同时通知商户端作补登处理(处理账户余额、修改订单状态等)。

其实备付金子账号的应用场景还是很广泛的,比如我们在购买二手房时,需要先把首付款打到中介平台的资金监管账户,这个账户其实就是一个备付金子账号,我们可以通过汇款的方式对其发起转账。

对接工作#

接下来,我们就来了解下产品的开通流程和其他的一些注意事项。

商务对接流程#

汇入金商务对接流程

在商务对接流程中,商户端需要填写以下两个申请单:

  1. 《云商通平台账户上线申请单》
  2. 《网络支付商户变更单》

按要求填写完毕后,交给通联业务经理即可,需要等待总部审批完毕,以及完成必要的信息配置,才可以正常使用。

注意:汇入金转账是有额度限制的,在开通时需要和通联业务经理确认额度大小。因为如果客户转账金额超过额度大小的话,会触发额度风控,无法正常到账。如果额度无法满足正常支付场景的话,可以提交申请进行提升额度。

业务对接流程#

业务对接流程如下图所示:

业务对接流程图

流程设计#

了解完对接流程以后,接下来我们就来看看具体的对接流程。

创建子账号#

首先我们需要为汇入金收款账户创建一个子账号。我们通过调用云商通 【4.1.29 会员子账号开通】接口为会员开通子账号(支持平台大 B、小 B 和小 C 账户)。

前提条件:个人会员需要完成「创建会员」、「实名认证」和「绑定手机号」操作,企业会员需要完成「创建会员」、「设置企业信息并审核通 过」和「绑定手机号」操作。

创建业务订单#

根据业务场景创建业务订单,这里最好提前生成商户订单编号 bizOrderNo

展示汇款信息#

用户选择汇入金支付方式时,需要向用户展示出汇款信息。参考模版如下:

付款信息

备注附言这里可以填写溯源码,这里可以约定一个溯源码生成规则,比如可以使用 两位业务类型 + 四位订单尾号 + 四位随机数 方式生成。例如:

  1. 两位十六进制数用来表示业务订单类型,00 - FF,共有 256 种可能,支持 256 种业务订单类型,如果不够可根据需要扩展,比如用 00 表示用户充值订单。
  2. 如果业务订单号是 22032117110619087588 ,取尾号后四位就是 7588。
  3. 生成四位随机数,例如:0973。

组装在一起就是:0075880973

注意:使用自定义溯源单号来填充摘要信息的前提是,通联侧配置的是收款人校验规则而不是摘要校验规则,否则无法通过校验。

溯源码在创建订单的时候生成,并和业务订单进行绑定。

线下汇款#

按照如下步骤进行网银汇款操作。这里一定要看清楚,千万不要选错,一旦打款成功,再追回款项十分麻烦(之前遇到过通联选成联通的案例,务必仔细检查后再汇款)。

如果在银行列表中搜索不到「支付机构备付金集中存管账户」的选项,可致电银行确认是否支持此项汇款功能。

回调处理#

根据云商通【4.3.5 会员子账号汇款入金上账通知】 通知格式进行对接。

通知格式如下:

回调格式

回调格式和普通的回调一样,按照上述的参数格式进行接收处理即可。

这里有个关键的步骤是根据 summary 字段传递的溯源码进行溯源,即通过和订单的关联关系找到商户订单编号 bizOrderNo,处理对应的订单状态,并进行正常响应。给通联响应信息格式如下:

{
  "code": 10000,
  "msg": "接口调用成功",
  "data": {
    "bizOrderNo": "商户订单编号",
    "merchantRet": "0000",
    "extendInfo": ""
  }
}

通联如果没有在响应中拿到 bizOrderNo 的话,会默认生成一个 bizOrderNo 并通知给客户。

应用场景#

这里来看一下汇入金应用的一些具体场景。

考虑到用户需要手动输入打款信息,而且汇入金回调需要与业务订单进行关联,这里主要考虑以下几个重点:

  1. 回调信息中需要能够和订单信息关联;
  2. 用户手动操作容易失误,输入内容不能太复杂;
  3. 如果用户备注填写错误,支持手动溯源处理。

我们可以利用 summary 这个字段进行巧妙地处理,上文中已经讲到了 溯源单号 的生成方式,下面我们通过两个具体的场景看看如何使用。

充值#

场景描述#

用户先通过汇入金的方式进行充值,充值到购买人通联余额,然后通过余额支付的方式进行「标准代收」或者「消费」的操作。

实现步骤#

  1. 用户创建充值订单;
  2. 用户选择汇入金方式进行付款;
  3. 付款信息展示付款人的通联子账号信息及其他必要打款信息;
  4. 备注信息填写溯源码(业务订单类型 + 订单尾号 + 定长随机数);
  5. 用户进行打款操作;
  6. 云商通收到款项以后进行上账操作,同时通知商户端进行补登操作;
  7. 商户端响应正确信息;
  8. 商户端根据备注溯源码定位到充值订单,修改订单状态及付款人的通联余额;
  9. 用户业务端余额增加,可在商城内使用余额支付进行购买操作。

消费#

温馨提示:因为目前通联规定了收款人校验和摘要校验二选一配置(即确保打款人和通联账号认证主体必须一致),所以消费这种场景只是存在于理论上的方案。实际能否使用取决于将来通联政策的调整。

场景描述#

常用于消费类型的业务场景,如:平台直接收取服务费用(自营产品收款、会员服务收款等)、商户直接收款(平台入驻的商家直接收款)。换言之,就是付款人付款后,款项直接进入第三方收款人的场景。

实现步骤#

  1. 用户创建消费订单;
  2. 用户选择汇入金方式进行付款;
  3. 付款信息展示收款人的通联子账号信息及其他必要打款信息;
  4. 备注信息填写溯源码(业务订单类型 + 订单尾号 + 定长随机数);
  5. 用户进行打款操作;
  6. 云商通收到款项以后进行上账操作,同时通知商户端进行补登操作;
  7. 商户端响应正确信息;
  8. 商户端根据备注溯源码定位到消费订单,修改订单状态。

总结#

「汇入金」作为一种「特殊」的入账方式,因为其「补登通知」发生在付款人「线下汇款」操作之后,并未提前生成通联订单,所以,如何跟业务订单进行关联是关键问题所在。

这里,我们巧妙地使用 summary 字段将通知信息与业务订单进行关联,这样就可以对汇入金的应用场景进行扩展,增加了业务的灵活性。在现实场景中,一些类似的汇款场景也可以参考这种设计。

但是笔者认为,比较理想的操作应该是将此类场景分解成「两段式操作」:即「下单」和「支付」两步来走,这样就是一个完整的闭环了。下单成功后返回一个唯一标识,用户打款时上送此唯一标识(比如通过 summary),回调时也可以很方便地通过唯一标识来溯源。(可能通联有自己的考虑才没使用这种方案吧,小猜测一波)

不过,随着近年来通联风控政策的收紧,「汇入金」的申请门槛已经越来越高,但是之前已经申请过的用户仍然可以正常使用。所以,且用且珍惜吧~

感谢大家的持续关注~

本作品采用《CC 协议》,转载必须注明作者和本文链接
你应该了解真相,真相会让你自由。
本帖由系统于 1年前 自动加精
《L01 基础入门》
我们将带你从零开发一个项目并部署到线上,本课程教授 Web 开发中专业、实用的技能,如 Git 工作流、Laravel Mix 前端工作流等。
《G01 Go 实战入门》
从零开始带你一步步开发一个 Go 博客项目,让你在最短的时间内学会使用 Go 进行编码。项目结构很大程度上参考了 Laravel。
文章
41
粉丝
123
喜欢
718
收藏
770
排名:248
访问:3.8 万
私信
所有博文
社区赞助商