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

简介

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

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

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

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

对接工作

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

商务对接流程

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

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 协议》，转载必须注明作者和本文链接