编辑导语:在当今的互联网时代,电商平台不断发展壮大。据规定,未经中国人民银行批准,任何非金融机构和个人不得从事或变相从事支付业务。那么对于没有支付牌照的电商平台,应该如何做支付呢?本篇文章作者介绍了支付业务许可证的范围以及接入渠道的形式,讲述了没有支付业务许可证时应对的措施,一起来学习一下。我们常说的支付牌照,全名叫做支付业务许可证。政策规定电商平台做哪些业务需要支付业务许可证呢?一、支付业务许可
编辑导语:在当今的互联网时代,电商平台不断发展壮大。据规定,未经中国人民银行批准,任何非金融机构和个人不得从事或变相从事支付业务。那么对于没有支付牌照的电商平台,应该如何做支付呢?本篇文章作者介绍了支付业务许可证的范围以及接入渠道的形式,讲述了没有支付业务许可证时应对的措施,一起来学习一下。
我们常说的支付牌照,全名叫做支付业务许可证。
政策规定电商平台做哪些业务需要支付业务许可证呢?
一、支付业务许可证的范围
由中国人民银行于2010年6月14日发布,自2010年9月1日起施行的《非金融机构支付服务管理办法》规定:非金融机构提供支付服务,应当依据本办法规定取得《支付业务许可证》,成为支付机构。
未经中国人民银行批准,任何非金融机构和个人不得从事或变相从事支付业务。
本办法所称非金融机构支付服务,是指非金融机构在收付款人之间作为中介机构提供下列部分或全部货币资金转移服务:
- 网络支付;
- 预付卡的发行与受理;
- 银行卡收单;
- 中国人民银行确定的其他支付服务。
2021年央行重新定义了支付业务。
2021年1月20日,中国人民银行发布《非银行支付机构条例(征求意见稿)》,本次征求意见稿按照业务实质确定了支付业务新的分类方式。
即从资金和信息两个维度,根据是否开立账户(提供预付价值)、是否具备存款类机构特征,将支付业务重新划分为储值账户运营业务和支付交易处理业务两类:
- 储值账户运营是指通过开立支付账户或者提供预付价值,根据收款人或者付款人提交的电子支付指令,转移货币资金的行为。法人机构发行且仅在其内部使用的预付价值除外。
- 支付交易处理是指在不开立支付账户或者不提供预付价值的情况下,根据收款人或者付款人提交的电子支付指令,转移货币资金的行为。
支付账户是指根据自然人(含个体工商户)真实意愿为其开立的,凭以发起支付指令、用于记录预付交易资金余额、反映交易明细的电子簿记。
二、没有支付业务许可证怎么办
从2015年起,央行已暂停发放支付业务许可证。
那对于没有许可证的公司来说,如果想要做上述提及的支付业务,只能去接入有资质的机构,常见的接入选择有:
- 银行。银行是依法经营货币信贷业务的支付机构,为了适应市场发展,现在很多银行都推出了面向不同行业的支付产品,大部分都不需要专线,接入简单并且资质上有保障。
- 非银行支付机构。是指在中华人民共和国境内依法设立并取得支付业务许可证,从事上述提到的支付业务的公司。例如微信、支付宝。相比较银行提供的产品,这类产品能力更丰富,例如微信支付分,可以用于智能柜、先用后付等场景,能够支持电商平台更好的发展业务。
- 聚合支付产品。例如收钱吧、掌贝、ping++。聚合支付是借助银行、非银机构的支付通道与清结算能力,利用自身的技术与服务集成能力,将一个以上的银行、非银机构或清算组织的支付服务,整合到一起。例如电商平台想要同时支持微信、支付宝、云闪付,就不需要一一对接微信支付、支付宝和银联商务,直接对接一个聚合支付产品即可。
三、如何接入渠道
如何选择渠道,一般会考虑渠道的稳定性、渠道提供的支付方式、支付成功率、手续费、接入难度等,这个根据公司的实际需要评估即可,此处不赘述。
主要讲解一下作为电商平台,在哪些环节需要用到渠道的能力。
渠道负责实际的资金流转,一般电商平台会用到的渠道的能力有支付、分账、退款,这里以接入银行/非银行支付机构来进行介绍。
1. 渠道开户
平台需要在渠道进行开户,以微信支付为例,需要先成为微信支付的商户。
这里需要根据平台商品的性质来决定商户的类型。
如果是自营的电商平台,即平台上售卖的都是本公司自营的商品,货权在自己,那么支付流程会比较简单,消费者下单后直接支付到平台,平台在渠道方成为普通的商户即可。
如果平台有供应商入驻的模式,即平台上售卖的有供应商货权的商品,这类商品下单时,是不能直接支付到平台账户的,需要消费者支付给供应商,此时平台需要在渠道方申请成为服务商。
2. 商户进件
如果平台在渠道方是普通商户,是不需要二级商户进件和管理的流程的。
如果平台在渠道方是服务商,就需要将平台的所有供应商在渠道方开户,供应商作为这个服务商下的二级商户,这个二级商户号的资金流入流出仅能由平台发起。
平台的供应商在渠道方开户的动作就属于商户进件,一般通过接口的方式完成。二级商户进件完成后,电商平台可帮二级商户发起交易、退款等行为。
3. 下单&支付
以服务商的模式为例,消费者在平台提交订单后,会拉起支付。
一个交易订单中可能会包含n个供应商的商品,那一笔交易订单会对应多个支付单,此时需要采用合单支付,消费者只用输入一次密码,可以完成多个支付单的付款。
一般情况下,渠道方对一次支付的合单数量会有限制,这就需要按照支付的限制来设计购物车和订单确认的流程。
支付时也需要明确这笔支付单是否需要分账、是否担保交易,实现订单佣金收取和对供应商的账期控制。
4. 分账
如果电商平台在每一笔交易订单中需要收取平台服务费或其他费用,就需要用到分账的能力,把支付过程中,消费者支付给供应商的资金,分一部分出来到平台账户,以达到抽佣的效果。
具体流程如下图:
5. 账期控制
账期是为了对供应商的资金结算进行控制。
例如我们在淘宝买东西,支付的资金虽然进入了供应商的二级账户,但是是冻结状态,供应商是无法提现的。
等到消费者确认收货后,该笔资金才会解冻,转入可提现余额。
一般渠道都提供了账期控制的能力,例如微信支付是通过分账进行控制的,支付时将订单标记为要分账,等到达可结算的条件后,将订单的资金解冻。
再比如,银联商务是通过担保支付的能力实现的。
6. 退款
当涉及消费者取消订单或售后退款时,就需要用到渠道的退款能力。
逆向流程要比正向支付流程复杂很多。
退款时,如果支付时有分账,需要先分账的金额从服务商账户退给供应商账户,再从供应商账户退给消费者。
如果进行了账期控制,还未结算给供应商的订单,一般不会出现余额不足导致无法退款的情况。
如果是已结算的订单,供应商很可能已经提现提走了,就会出现退款时余额不足,导致退款失败。
但是又不能让消费者等着,因为不确定供应商账户什么时候会有入账。
此时可通过以下方式解决:
- 提前预留一部分不可提金额,在电商平台的余额系统进行控制,来应对日常的售后退款。
- 如果渠道提供了垫资退款的能力,可由平台先帮供应商垫资退款,后续从供应商账户回补。
- 这笔退款由客服线下联系消费者,走线下退款,余额系统进行调账处理。
7. 提现
当资金结算到供应商账户后,供应商在平台发起提现。
直接调用渠道的提现能力即可,一般供应商都是企业或者个体工商户,可以提现到对公/私人的银行卡。
四、内部账务处理
电商平台由于要管理平台和供应商的账户,不仅需要接入支付渠道,还需要做内部的账务处理。
比如平台接入了微信、支付宝、银联商务,每个供应商都在这三个渠道进行了进件且发生过交易。
但对于供应商来说,不论哪个渠道,都是在平台发生的交易,平台应该进行统一管理。
例如供应商看到账户余额有100.00,余额的分布是微信20.00、支付宝40.00、银联商务40.00,供应商发起一笔提现90.00,平台应按照规则分配好不同渠道的提现金额,再去请求提现。
从这个意义上来说,平台也类似一个聚合支付产品。
平台内部需要提供的能力,除了真实的资金处理外,整体设计和流程,与支付机构并无太大区别,收银台、支付路由、对接渠道支付、清结算、账务核心、出金、会计、资金相关的业务系统、对账,这些在正常的业务流程中都会涉及到。
下图是我司目前的整体设计:
五、内部和渠道对账
由于内部有一套账户和账务处理,渠道有真实的账户和资金处理,因此内部系统和渠道的对账是必须要做的,以免流水和余额出现差异,影响业务流程。
1. 余额核对
渠道一般会提供服务商账户和二级商户的实时余额查询和日终余额查询。
实时余额查询。一般是由于特定需求产生的,可能这个供应商后续不再在平台进行交易了,想看一下他的当前余额。
实时余额查询一般做成一个调接口查询的功能即可,是不需要用来做系统间的核对的。
日终余额查询。内部系统在进行日切后,会产生上一日账户余额。
渠道方一般也会在次日生成上一日的日终余额。
每日需要将渠道的上日余额和内部系统产生的上日余额进行核对,如果二者一致,说明内部记录的余额没有问题(但不能说明账务处理没有问题,错误的账务处理,一增一减也会导致余额能对上)。
如果出现差异,说明账务处理有问题,需要技术及时排查。
2. 每日账单核对
渠道一般在次日会生成上一日的账单,获取到账单后,将内部账务流水和账单进行核对。
需要注意渠道账单的时间,以2022-03-08为例,渠道方统计入这一天的流水,与内部账务处理未必会完全一致。
例如微信支付虽然是0点日切,但是在2022-03-08 23:59之后的支付单,都不会再实时分账,因为要处理前一日的清算批次。
如果内部系统将这一分钟的单据计入了分账流水,就会导致对账差异。
因此一般建议内部系统的账务处理时间,以渠道反馈的时间为准,以确保账务处理和真实资金变动的时间一致。
对账结果如果出现差异,首先确认是否时间问题引起的,如果是,财务只需要标记差异后续平账即可。
如果是遗漏了单据,无论出现长短款,一般情况下都需要调内部账,以渠道的结果为准。
本文由 @安妮 原创发布于人人都是产品经理,未经许可,禁止转载。
题图来自 Unsplash,基于 CC0 协议。