按照嘉宾的要求,本文不对外公开。如果你是意外看到这篇文章,请勿将链接发送给其他人。


大家好,很荣幸能在这里和大家分享关于微信支付的一点小知识。 目前公司的项目也处于调研和整体规划阶段,现在把自己之前实际产品使用中遇到的问题和目前调研的发现分享给大家。

一、二清问题

B2B2C及SaaS类平台型公司,在帮商户做变现收款时,常使用以平台自己名义申请的第三方支付商户号,通过大商户模式帮助其下商家进行收款。平台再自己清算结算给其下商家。

存在风险

平台私自设置资金池,私自挪用商家沉淀资金开展其他业务。甚至可能侵吞商家未结算货款,私自跑路。商户交易真实性难以追溯,存在灰色业务甚至洗钱的风险。

痛点

B2B2C及SaaS类为代表的这些电商企业的资金流运营方式多是通过与微信、支付宝等支付机构合作,但支付机构仅承担通道职能,并未对平台本身账户进行托管,从而形成“大商户+二清”模式,可能存在金融风险。同时此类电商公司不具备支付牌照,不具备给商户做清算结算的资质,不受到央行许可监管。期间还可能存在电商平台包装、隐匿虚假商户、变造交易信息、用户信息泄露等问题。

具体如下图所示:

20180716_210703

二清解释
支付公司或银行先将商户货款结算给平台(某个人或某家公司),再由平台结算给商户。

不合规的点

平台无请结算资质,不能触碰资金,不能给商户做结算。

突破思路考虑
是否可以引入,一位具备清算资质的机构来触碰资金做清结算。中国具备合法清算资质的只有银联和网联,银行因为做资金结算本身也具备清结算的资质。

二、解决方案

基于以上考虑,可以找银行来接管资金并对各个商家做清算结算的操作,避免平台二清。

如下图所示:

20180716_210741

而银行要做转清的业务的话,因为银行本身的技术架构和业务能力是有限的,无法跟上电商平台高并发类交易及快需求迭代的节奏。银行不愿意投入资源去建设满足电商类平台的技术架构。因此,需要一个技术服务商帮银行做技术转接,服务电商类平台。至此,W公司就是这样一个技术服务商。

首先,先了解微信商户账号体系的结构,如下:

20180716_210823

W公司的商户账号体系,如下:

20180716_210824

因为,W公司包装了微信支付的整个进件、支付及处理了渠道商和子商户之间的关系,转化为W公司自己体系内的W公司商户账号体系。因此,需要结合两套账号体系一起来理解。

20180716_210902

1. 电商平台生成W公司渠道号
a. 向银行提交相关资料,银行的同事进行银行账号的开户;
b. 银行完成开户后,建立开户主体的渠道号;
c. 渠道模式交易接口:渠道编号+商户号+渠道密钥签名发起交易。

此处备付金非第三方支付机构备付金。意为电商平台自有资金账户、手续费分润账户等。

2. 生成W公司普通商户号/门店商户号(微信子商户号)
a. 生成商户号的所需的资料除了企业相关证件之外,还包括商户号结算所对应的银行账号信息;
b. 生成微信商户识别码:提供要在微信端开子账户号的信息(包括需要绑定公众号的appid,支付域名,商户简称等);
c. 渠道授权:由银行的工作人员发起,电商平台来完成授权。

20180716_211114

3. 生成门店商户号结算账户
a. 接口自主进件帮商户开设结算虚拟户,是指电商平台通过银行的B2B接口向银行进行的进件,生成每个商户自己的结算附属账户(下挂在电商平台主账户下);
b.门店商户号直接通过调用W公司接口,上传商户信息并开通。

20180716_211139

基于以上的两套账户模式的融合。W公司作为银行技术服务商,为银行下的渠道商户完成支付。 银行完成清结算。

三、信息流和资金流

20180716_211312

20180716_211324

四、退款处理

因商户号交易资金不足导致的退款失败,这类情况应该怎么处理?

方式1:退款限制改为父商户号交易资金足够便可发起退款,但这里会有一个问题是银行在进行清分的时候,交易资金不足的商户号的结算金额为负数,那银行就没法清分了。
方式2:将商户号的结算时间开放为T+N。
方式3:使用机构模式进行退款,只要总的资金池中金额足够,就可以发起扣款。
银行与电商平台确定资金短款处理方式。

20180716_211341

20180716_211417

最后,再来对比一下三种模式:

20180716_211439

五、合规疑点

1. 关于商户号

W公司是其实是父子关系商户号,强制将只是平台作为纽带关系的商户捆绑在一起,存在不同平台同一商户的问题。 这个关系设计存在不合理性,从产品设计上叫做弱关联,仅仅在资金处理上存在 所以应该转为以商户法人或企业编号作为主体,辅助以渠道编号

2. 关于退款

关于退款,是采用冻结余额的做法进行退款,而并没有联动返回电商平台分润的扣除部分
这块对于入驻商户是极大的不公平,久而久之,必然这套模式会被诟病

3. 银行资金流

银行资金流的问题,目前都知道未来支付宝微信的备付金100%上收,备付金直接清算给收单银行,就会存在合规问题,2019年这个模式就会行不通,支付宝微信资金不能进入银行虚拟户(内部户)

4. 关于父商户号

持卡人在微信看到的支付信息为W公司的父商户号,而非真实商户号,在人行检查时,存在支付信息不匹配,变造伪造交易信息。

5. 关于提现资金流

关于提现资金流的问题,有收单银行完成商户提现交易,而实际这个商户并不是银行的收单商户。不符合收单银行的KYC原则。 这个其实是微信支付自己的设计,为银行这种机构设置商户号。 这个设计会与目前反洗钱报送冲突,势必面临整改风险。

6. 关于税的问题

大的趋势都要往 银联、网联走。 现在银行接完,银联、网联之后也可以提供相关聚合支付收单相关能力。 其实很重要的一点大家都忽略了税的问题。分账核心需求是避税。但是税务也在收紧, 说一下几个关键点吧,大家很容易想到:

  1. 如果不分账,属于平台的服务费是不是是事后支付,而入驻商户应该按照原始收入记账,交税。
  2. 如果不分账。电商平台需要开立增值税发票(原来是营业税),税点6%
  3. 如果不分账,W公司,微信的手续费还要各自交税
    简单一个分账环节中间少了多少税,大家可以算一下。 为什么分账就不用缴税了?因为没有开票了。 就像小饭店说不开票来瓶可乐,老板都不愿意。

W公司的这个方案, 微信和央行是报备过的,这里是一些比较细节的问题了。大的原则上,仍然是商户一户一进。在微信支付那边必须有报备,支付时展示的收款商户名称也是最细颗粒度的平台下的子商户。信息二清也不存在。资金方面,也仍然是同商户进,同商户出。
这能解决一部分问题。微信支付本身也可以支持分账,不过需要特别开权限,但需要注册特约商户,处理起来比较麻烦。

关于微信支付的Q&A

Q: 问一下,在微信内,使用微信支付必须要关注对应商户公众号么?
A: 不需要,但是查询会判断有没有关注。
Q: 如果商户通过第三方支付来走微信扫码,进件的话最终是第三方支付审核还是微信官方审核?
A: 微信商户需要审核通过才可以加入子商户,服务商可以协助提交资料,帮助审核。
Q: 请问何为“进件”?
A: 商户资料审核&商户入驻&商户报备等;
Q: 通过第三方支付的话 最终审核方是谁?
A: 微信,通过服务商也是由微信去审核。服务商只是配合提交。
Q: 现在一个普通的科技公司还可以申请成为服务商吗?
A: 可以的,证明有开发能力。
Q: 如果是通过服务商这种方式,资金是只可能由微信官方直接到商户吧? 中间有没有可能在某个账户落下?
A: 不会,中间不落地,全程在微信支付里面,如果落下了,就会涉嫌二清。

关于二清的Q&A

Q: 123是入网了银行了,不知道银行的资料要求是咋样的
A: W公司成了微信的外包拓展商,但W公司又没有外包资质。这里注意电商平台拿到的是W公司商户号
A: 嗯是的。 拿到的都是W公司的商户号
A: 理论上W公司存在中间篡改商户信息可能
A: 所以,央行后面说了 核心收单和商户入网,必须银行自己作。不能找外包。
A: 嗯,看来人行也注意到这个问题了, 如果W公司透传相对合规一些
Q: 保持技术服务商的角色
A: 电商平台二清的问题我也研究过一阵子, 我也推演过几个方案
Q: 中信的电商管家研究过么,合规?
A: 研究过,也不合规哦。

Q:哪家银行支持这个TN结算子商户
A: 很多银行都支持T+N。

Q:微信支持分账,是不是就可以一个app可以收到不同的商户号了?
A: 是的, 也只能这样, 否则分账就没有依据了。这里其实是参考收单管理办法的,总对总入网管理:

第十六条 收单机构应当对实体特约商户收单业务进行本地化经营和管理,通过在特约商户及其分支机构所在省(区、市)域内的收单机构或其分支机构提供收单服务,不得跨省(区、市)域开展收单业务。 对于连锁式经营或集团化管理的特约商户,收单机构或经其授权的特约商户所在地的分支机构可与特约商户签订总对总银行卡受理协议,并按照前款规定落实本地化服务和管理责任。

Q. 其他补充

  1. 另外前面说到的银行给开的特殊银行账户,目前我们也和华夏建行平安有合作,银行给我们的定义也是说“专户”。
  2. 不用必须,微信后台有配置。大于多少金额(具体数字忘记了,好像是几百)可以设置成默认关注。
  3. 商户有通过官方申请优惠费率的需求,但是这样又绕开了商场, 这个问题一直很难解决。
  4. 服务商有优惠政策,费率一般比官方的便宜一点。

本文档来自支付产品技术交流群的聊天记录整理,由志愿者整理并发布到本网站。如需要及时收到来自支付产品技术交流群的最新消息,请扫码关注“凤凰牌老熊”的微信公众号。 本群面向支付行业的有经验(2年以上)的产品经理、软件工程师、架构师等,提供交流平台。如想加入本群,请在本文评论中留言(不公开),说明所在的公司、负责的工作、入群分享的主题和时间。