重庆云创科技有限公司
  咨询电话:400-1060-365

业界新闻

关于B2B支付 这里有一篇最全总结文章

作者:admin  点击次数:220  发布时间:2020-02-23

说起“支付”,大家一定会联想起一些场景:去便利店使用微信支付;去血拼shopping的时候刷卡;去超级市场买菜时候给现金……这些都是我们常见的支付场景,我们熟悉是因为我们以“个人”的身份参与其中,而这些都是To C支付。

不过事实上与To C支付相对,还有To B支付。参与的主体不是个人,而是“法人”,即“组织”。比如:某某公司购买腾讯云一年;某某公司集体购买企业QQ邮箱。

那么,To B支付究竟有什么特点?和To C相比,它有什么不同?带着这些问题,我们启动了系列专题研究。

定义概述

虚拟To B支付,顾名思义就是:“B端用户购买组织所需的虚拟商品时进行的支付”。从定义看,“虚拟To B支付”分成三部分内容:

定义详解

1、商品内容:虚拟vs实物

虚拟To B支付研究的是虚拟商品

商品包括实物商品和虚拟商品,虚拟商品是指电子商务市场中的数字产品和服务。举例:Q币、游戏道具;电子书;服务器……都属于虚拟商品。

2、消费者:法人vs个人

虚拟To B支付研究的是法人

商品的消费者可以分为法人或个人(按照法律概念)。法人即具有民事权利能力和民事行为能力,依法独立享有民事权利和承担民事义务的组织;个人即自然人。

PS:中国对法人的划分是怎样的?中国的“法人”分为企业法人、国家机关法人、事业单位法人、社会团体法人。其中“企业法人”占大多数,它是典型且重要的现代社会经济组织。这也是我们通常用“To B(to business)”来统称B端的原因。

3、支付主体:对公账号vs个人账号

虚拟To B支付研究的支付主体是对公账号

对公账号就是主体是企业事业单位的法人账号,比如腾讯公司就有一个对公账号。

区分To B和To C支付最直接的依据在于,To B的支付用的是对公账号(B账号),To C的支付用的是个人账号(C账号)。

敲重点了!“我们所研究的“To B支付”就是其中的B → B;B→C(即,只要付款方是B用户,都算To B支付)

PS:对公账户小科普

对公账户包括基本账户、一般账户,而一般账户还会有专用存款账户、临时存款账户两种。

基本账户:一个法人只能开一个,是公司资金的基础账户。

一般账户:一个法人可以开具多个,用于特殊的资金流转。

PS:为何需要有“对公账户”?税务局为了方便财产监管,规定公司企业成立时必须提供对公账号。

PS:个体工商户用个人账号还是对公账号?

①个体工商户其实属于自然人,用个人账号即可。因为纳税是定额税,即预先根据商定规定每个月纳多少税。

②但是很特殊的一点:因为有营业执照,所以个体工商户是可以开对公账号的。

③因此,如果是个人账号,那就走To C支付的流程;如果是对公账号,则是To B的流程。我们可以把个体工商户看成是特殊的“小企业”

PS:NGO等社会组织也需要开具对公账号吗?需要,但主要目的不是为了税收,而是为了政府及公众对募捐资金的监管。

虚拟To B支付用户画像与场景-谁在用?

1、To B支付用户画像

我们前面说到,To B支付最重要的特征是支付主体为对公账号,和个人账户很不一样的是,使用这个对公账户的可不是一个人,可能是多个人。

“对公账户”对应的是一个组织,但是具体在使用的时候,是一个“个人”来进行操作支付的,所以我们曾对To B虚拟支付的用户进行了一次研究,简单绘制出To B虚拟支付的用户画像:

2、虚拟To B支付使用场景

严格来说,是用户动机和场景。前面提到了,使用虚拟To B支付,根据资金流转情况,会有B→B和B→C两种情况,而这两种情况,反映的用户动机和使用场景会有所不一样。

B→B:任何企业事业单位之间涉及商品交易的情况。

B→C:涉及种类较多,大致可以划分三大类:

①劳务人员的收入;②投资者资金产生的收益;③个人产品费用,共10小类。

虚拟To B支付的支付方式

1、支付方式

一个法人组织的对公账户资金转出(转款到另一个组织的对公账户、或者某人的个人账号)有两种方式:网银转账、柜台转账。 当然随着微信和支付宝出现,出现了新兴的支付方式。

  • 网上银行转账

①是通过银行将款项从企业的银行账户直接划转到收款对象银行账户的资金结算方式。

②兴起于90年代中期的美国(2000年国内大型银行陆续推出面向企业网上转账服务)。

③需要两个U盾电子密匙,分别由企业的两名独立的工作人员持有,转款时一人负责操作,一人负责审批授权,形成两道关卡。

  • 柜台转账

①企业在银行开户时留下印鉴(一般是财务章或法人代表章),盖在预留的印鉴卡上,留在银行。

②当企业需要对外支付时,先填写对外支付申请(付款方的银行账号、户名,收款方的银行账号、户名),申请上加盖印鉴,银行核对后,即代企业进行支付。

PS:支票转账也属于柜台转账的一种。

线上打款的新兴衍生形式

微信支付&支付宝企业付款

微信支付企业版、企业支付宝现在支持既可以转账到个人账户,也可以转账到对公账户。

2、各支付方式优缺点总结

  • 网银

优点:较传统柜台转账方式大大降低经营成本;对用户来说无时空限制

缺点:有一定安全风险;操作起来不是太方便。

  • 公章

优点:安全性最高。因为章盖的页面叫印文,肉眼看很像,但每枚公用章印在公安机关有电子版备案,有伪造印章罪。

缺点:需要人工介入较多,时间较长。

  • 微信及支付宝的企业支付

优点:容易用,耗时短。

缺点:对公支付有一定限制,限时、限额。单笔不能超过一定数量。

小结

前面说了那么多,再来总结一下几个要点:

1、区分to B还是to C支付在于“谁”支付,只要是B端账号支付,都是to B支付

2、“B”因为是组织,使用B账户的,可能是多个人

3、目前to B支付(B资金转出去)的方式有:网银、柜台公章、新兴在线支付。各有利弊。

虚拟To B支付设计研究(二):设计思考篇

这是虚拟to B支付专题研究的第二篇:虚拟to B支付设计思考。本篇是在第一篇《基础知识科普篇》基础上,对虚拟to B支付相关设计知识进行更深入研究,更侧重于设计思考。

本篇研究方法:对比法

社会科学中运用较广的方法。对比法旨在将有一定关联的现象和概念,进行比较对照,判断异同、分析缘由。

对于认知陌生领域,好处在于通过与已知熟悉事物的对比,从熟悉事物迁移到陌生事物,更形象地认识陌生新事物。

因此,本篇会通过与To C对比,更好地理解To B支付设计特别之处。

一、什么是虚拟To B支付

虚拟To B支付是“B端用户购买组织所需的虚拟商品时进行的支付”。上一篇文章对此有过详细定义《虚拟To B支付设计研究-基本知识科普篇》

对此再回顾几个要点,唤起大家的回忆:

  1. 虚拟To C支付,可以联想平时游戏充值、开通包月的场景,比如QQ音乐充值会员;虚拟To B支付,可以联想其他公司买腾讯服务的场景,比如企业邮箱购买。
  2. 区分To B还是To C支付在于“谁”支付,只要是B端账号支付,都是To B支付。
  3. “B”因为是组织,使用B账户的,可能是多个人。
  4. 目前To B支付(B资金转出去)的方式有:网银、柜台公章、新兴在线支付。它们各有利弊。

二、虚拟to B支付设计差异点 1、提供用户更稳健的操作

虚拟To B支付牵扯的通常是大宗商品,这类商品最大的特点是:交易金额高,交易频率低。可能一年才买一次,但是一次就花个成百上千万。比如某某企业购买腾讯云业务。

因此,对于虚拟To B支付来说,操作过程会更加求稳。因此在设计时需要注意几个要点:

1.1 操作流程更“稳”

一般虚拟To C支付的场景多为冲动型消费,冲动型消费的特点是,用户的购买意愿很容易消减,为了抓住这一点的稍纵即逝的消费意愿,越快让它支付完越好。

因此“快”会是非常重要的考虑因素。参考米大师web,举一个例子,我们在包月付费时,我们会想办法来缩短用户的支付路径,想办法让用户越快给完钱越好。比如我们一般是把后台下单逻辑隐藏,因此前端是不出现的,前端可以直接一步完成:选商品→支付流程。

BUT,在虚拟to B支付场景中,操作步骤不一定最快,但是一定是最稳健:该有的操作一步也不能少,有时候为了稳健,还需要用户多次安全确认。

我们通常会用指示器把操作步骤显示出来。让用户每一步都能确认,避免犯错。

1.2 资金流向时刻反馈

在虚拟To C场景中,由于是小额资金交易,银行对资金的处理速度很快,能及时反馈结果。从用户侧下单支付(下单支付页),到后台反馈银行结果(结果页),用时都很快。

BUT,虚拟To B支付则不同,由于是大额资金交易,银行需要进行核实,这个过程有时候需要进行很传统的操作,比如:人工打电话核实、登录网银U盾操作核实。因此从用户侧下单支付,到后台反馈银行结果,有时候需要一定时间。

动辄成百上千万的资金,用户需要对自己给出去的钱有极致的操控感,需要实时获知自己的资金流向。因此需要在用户每个操作时都给出实时的资金反馈。我们在设计时会着重注意实时反馈。

举一个例子,如果资金延迟到账,我们会展示一个时间轴,时刻反馈资金的处理情况。(类似于电商中的物流时间流同步)

1.3 退款作为一个重要的功能设计

在虚拟To C支付中,因为到账及时率高,加上用户冲动消费(买了也不贵的心理),退款是一个非常低频的操作,在产品设计上通常“有即可”,或者有问题找到求助方法即可。

举一个例子,腾讯服务的付费,在业务中我们不提供一个专门的退款功能,但是会在客服中提供发生问题求助的法子。

BUT,虚拟To B支付则不同,由于是大额资金交易,加上前面提到了,从下单到订单完成,中间会有时间差。因此,资金是允许在成交之前,随时退订。

因此,退款功能需要做到一个突出重要,用户能够发现的位置:

PS:对于虚拟To B支付,有一个特别点,允许部分退款。

2. 兼顾更加多样复杂角色的前端

都说To B产品是很复杂的,对于虚拟To B支付来说,这个复杂点在于:兼具的角色很多,因为一个B端账号的背后,可能是多个用户在使用。

有可能就是,老板、财务总监、职员都共用一个B端账号,他们之间的使用差异是很大的,因此设计时需要兼顾这些角色的差异性。

1.1 历史操作信息作为一个重要的功能设计

虚拟To C支付中,操作者通常是唯一的。一个账号背后可能就是一个自然人(排除共用账号的特殊情况)。因此自己进行了什么支付操作,还是有一定印象。

但是虚拟To B支付则不一定,操作者不一定是唯一的。老板、财务总监、职员都可能进行过一定操作,如果不记录,就会导致资金操作乱套。因此,我们会提供一个历史操作信息的记录,来方便不同角色登入时,可以清楚上一次操作者的操作。

1.2 简明易懂的内容设计

虚拟To B支付通常涉及到一定的专业背景知识(比如财务等专有名词)。但是每个角色的知识背景是不一样的(比如老板、财务总监、职员),财务背景的用户可以在较低学习成本的情况下使用,但是没有财务背景的(比如老板),则需要设计时兼顾这部分人的需要,在涉及一定专业背景知识的场景中,我们可以通过一定的内容设计,把背景知识的内容转换为一般通俗易懂的内容。

3. 做好为产品限制擦屁股的准备

整个行业内,虚拟To C支付已经做得相对完善了,但是虚拟To B支付则处于刚刚起步的阶段。不少技术、政策限制导致的问题,需要通过合理的设计来“润滑”用户的心理:

  • 银行系统对于大单处理的效率会是一个很大的技术限制,轻则可以几小时到账,重则几天,有时候甚至1周才能处理完成。这个时候需要通过一定设计来安抚用户。
  • 有时候受政策影响也会导致用户一定的不顺畅,需要苦口婆心地向用户解释。比如支付方式中的线下支付,就是针对一些大单,必须线下使用公章才能用户能线上操作。

小结

目前虚拟To C支付已经做得相对完善了,虚拟To B支付则处于刚刚起步的阶段。正正如此,这一部分还有不少的机会点挖掘。

虚拟To B支付设计研究(三):海外研究篇

随着公司业务拓展到海外市场,我们在工作中也接触到针对海外用户的支付设计实践。这篇文章结合虚拟To B支付专题研究的背景,是关于海外To B类产品支付体验的研究小结。

一、什么是海外虚拟To B支付

“虚拟To B支付”是指“B端用户购买组织所需的虚拟商品时进行的支付”。而“海外虚拟To B支付”,顾名思义,则特指“海外的”B端用户在购买虚拟商品时进行的支付。

二、考察范围设定

“海外”很大,很难针对每个国家都进行深入细致的研究,因此我们以“互联网发展程度”和“相关设计需求指向的地区”作为标准,选定北美作为第一阶段产品、设计调研的考察范围。

而产品案例方面,则选取了云服务、日常办公、商业应用、企业培训等七个典型且与公司业务有一定相关性的类型,进行深入研究。

三、研究发现 1. 海外主流To B类产品支付流程和国内基本一致

在考察的三十多个案例中,我们发现,大部分产品的支付流程遵循典型的“三部曲”模式,与国内的To B及部分To C案例的流程设计非常相似。

然而,也有不少案例采用比较“灵活开放”的流程,让用户在输入信用卡信息后再对数量、套餐类型等订单信息进行选择或修改操作,如以下例子:

关于主要任务的流程设置,通常是支付体验设计中重点考虑的方面,不会轻易地对经典三部曲进行改动,对观察到的几个特例分析,这样处理的原因或在于:

  • 可改动的部分都为简单的操作(如:改数量、选类型),行为成本低,一旦发起,可导致b;
  • 用户的操作许多时候仅可能调高最终支付的价格(就像在安静地促销)。

2. 并非都严格遵循“任务唯一”原则

用户在进行To B支付操作时,往往比较谨慎。国内的许多产品(如阿里云、腾讯企业邮箱)的支付设计,都遵循“任务唯一”的原则,对控件选用、页面布局、跳转关系等环节作相应处理,使用进度指示器、手风琴、分页等方式,收纳信息,渐进地呈现内容,让用户专心地、一步步地完成任务。

而在我们考察的国外案例中,常常见到在整幅页面上平铺展示性及操作性的内容,许多时候用户需要滚动屏幕才能完成操作。常用于处理复杂输入任务的“固定下一步按钮”也不常见。在以下例子中,我们观察到用户需要滚动两到三屏才能完成任务。

在考察到的长表单设计里,许多出自如Slack、Pinterest Ads、Rackspace等成熟公司。可推测,在重视可用性验证的To B类产品中,这样的处理并非完全没有考究,一定程度上反映了海外用户的一些特点:对信用卡相关的长表单填写有较高的容忍度,即使任务“显得”很长,也能依靠经验较轻松地完成。

3. 以信用卡和PayPal作为主要支付方式(渠道)、少量支持转账

和国内To B支付相对丰富的渠道(线下转账、网银、银行卡、第三方支付等)相比,海外To B类产品在支付渠道选择上比较有限,大部分案例仅提供信用卡作为唯一的支付渠道,部分提供PayPal,少量支持银行转账(要注意的是,这里并非国内常见的通过网银进行网上转账操作,而是传统的通过财务人员填写纸质单据的线下转账) 。

4. 折扣方式以优惠码为主

和国内的情况类似,海外To B类产品在支付阶段的营销设计比较简单。在调研的案例中,我们发现优惠码是最主要的折扣手段。

优惠码的使用在国内并不常见,但在北美,无论线上还是线下,却是很流行的一种营销推广方式,当地用户在日常生活中经常接触到这种折扣方式。网上也有许多专门用于淘优惠码的站点,如下图的retailmenot.com。

对比地考察国内外To C及To B类产品,我们发现,支付阶段的营销方式常起源于To C类产品对用户习惯的培养,并慢慢迁移、过渡到To B类产品的对应环节中。未来To B类产品支付营销的创新,或许就来自现有To C类产品的成熟经验。

5. 有一定文化差异,但不多不显著

随着技术的发展,信息互通的提高,像很多传统品类(如:汽车、微波炉),互联网产品中许多基本操作日趋统一,不同国家的产品在使用上差别并不大。在调研中,我们并没有发现显著、可严重影响任务完成的设计差异(和预期有些不同);在考察的案例中,主要的差别集中在渠道本身(见上述篇章)和部分信息输入的细节上:

(1)信用卡的姓名合并填写

“名在前,姓在后,分开填写”大概是许多同学在旅行或者其他涉外经历中形成的印象,而在我们的调研中则发现一些小差别,合并填写姓名在输入信用卡信息时,是更常见的方式。

(2)地址信息大体按从小到大的区域维度填写

和国内从大到小的习惯相反,北美地区填写地址时基本遵循从街道、房号到城市,再到州的从小到大的顺序输入。

四、总结及体会

关于海外虚拟To B支付,我们主要的研究发现包括:

  1. 基本流程和国内类似
  2. 常见不遵循“任务唯一”原则的设计
  3. 支付渠道选择不多,以信用卡为主
  4. 营销方式简单,受当地日常生活习惯影响(以优惠码为主)
  5. 有一定文化差异,如:姓名、地址的填写

总的来说,在虚拟To B支付设计这个类别中,海外(北美)和国内的主要差异集中在渠道和营销这两个环节上。由于支付渠道建设(a.网上银行;b.第三方移动支付,如:微信支付、支付宝)更健全,国内To B类产品在整个支付体验的精细化处理上更有优势。

最后,在文化层面上,虽然观察到的表面化的差异不多,但在海外产品上常见的“有度”、“不过分”的感觉还是能让人慢慢地feel到,这也是在相关的设计实践中应该注意的。

To B支付如何合规?这里提供5种模式

(文章中提到的案例基本上都是从公开渠道了解到的,如果凑巧有这些公司的朋友读到,又凑巧有冒犯之处,还请见谅和指正)

14年以前,互联网处在野蛮生长期,类金融业务的合规性未引起监管机构足够的关注。自从14、15年大量的P2P平台倒闭、跑路,与此同时支付宝、微信的资金体量越来越大,传统金融机构和社会舆论开始重视互联网业务的资金安全问题。

在15年,监管政策开始要求P2P平台将资金托管在银行、第三方支付、基金等机构;16年,明确将支付宝、微信等第三方支付定位为小额支付通道;同样在16年,大批无支付牌照的互联网公司因涉嫌“二清”被约谈(蘑菇街、二维火、有赞等平台都被央行约过)。为此,上规模又存在不合规操作的电商平台可谓人人自危,直接导致支付牌照水涨船高,均价从几千万涨至几亿、十几亿。

所谓的“二清”指的是非银行及第三方支付的机构从事支付业务。这种业务之所以不被央行允许,是因为机构可以随时套现甚至是卷款走人,从而给大量用户带来损失。

举例来说,像蘑菇街这样的平台以前可以引导用户将金额充值平台上的账户中(也就是蘑菇街的账户)。用户发生消费后,金额并不是实时进入商家的账户,而是记录在平台上。在商家申请提现时,由平台按照与商家的约定,扣减分润后才将商家应得的部分打款给商家。在这种模式下,资金停留在平台期间,平台只要愿意,可以任意对资金进行处理。比如,房地产火了,就把钱提出来放进房市里炒房;股市火了,也可以把钱丢到股市里炒股。一旦赚了,皆大欢喜;即使亏了,还可以继续吸引更多用户存钱进来,拆东墙补西墙也能支撑一阵子。

正因为如此,“二清”广泛存在于众多公司中,成了大家都心知肚明却不轻易放到台面上说的秘密。也因为有较大的风险,且风险面在扩大,央行才频频出手。一众互联网公司也调转船头,开始走合规的路线。以下本汪就以工作经历中见到的解决方案为例,来谈谈互联网ToB业务中对资金流的处理方法。

一、 线下大客户合同模式

这种模式由平台方直接面向客户提供服务,供应商仅作为平台方的合作伙伴存在,不直接与客户接触。或者是平台向客户出售货物,货物由供应商提供。

由平台方的大客户销售在线下与客户协商好并签订合同,在合同中约定什么时间付款、用什么方式付款、付多少钱、开什么发票、什么时候开票、发票怎么给乙方、谁交税点等相关事项。实际发生交易后“一手交钱一手交货”,只要合同流、资金流、发票流三项吻合(也就是金额、交易双方等信息对得上),在财务上就是合规的。

平台方完成以上的交易后,货物的归属就转移到平台,之后平台要怎么出售都可以,所以这种方式是最简单和常见的。

二、 居间服务和三方合同模式

这种方式涉及到平台和第三方供应商共同为客户提供服务的,常见于居间的情况。

互联网公司经常凭借自身的流量优势做一些空手套白狼的生意。举例来说,某公司是平台方,名气大流量大,想要吸引客户到网站或者app上购买某种服务,这些服务不必由这家公司提供,而是由其它供应商提供。交易结束后,平台方先抽取提成,然后将供应商应得的款项给对方。

这是链家租房采用的方式。租客、房东、链家签订三方协议,约定好租金、平台服务费、押金等,一纸合同将各方的权益都说清楚,也把资金流向说清楚。对于平台来说,服务费在交易现场就由顾客打入链家的账户中,金额与合同中一致,一般情况下顾客也不需要发票,所以合同、资金、发票是一致的,在财务处理上也没有问题。

这种模式因涉及的关系方有3个,较难以协调,所以适用于偏线下的互联网业务,如果是线上业务得使用第三种方式。

三、 互联网代收代付业务

前两年兴起的很多O2O公司都是使用这种方式。以滴滴为例,平台方在线下与B端用户(也就是快车司机、专车司机)签好合同或者协议,司机以合作商家的身份入驻平台。顾客在平台上下单坐车,完成交易后通过微信、支付宝等方式将车费打入滴滴平台,滴滴在司机app上开放提现入口,当B端司机发起提现时再把钱打入司机的银行卡中。乘客需要发票时,向滴滴申请,由滴滴为乘客开具发票。读者或许有疑问,在流程中钱不是也停留在第三方平台了吗?难道不存在二清的问题吗?为什么司机为顾客服务,开发票的却是滴滴呢?

以滴滴的规模,如果存在二清的问题,早就被约谈了。滴滴的模式之所以是合法的,是因为平台是采用了互联网代收代付的模式。也就是说滴滴完全可以解释,车费都给司机了,司机可以随时提现(顺便说一下最近易道闹得沸沸扬扬就是因为司机提不到钱);而且在实际进行交易的时候,乘客的钱也可能是直接进入了滴滴为司机个人开的(银行)账户,只不过是走了滴滴的通道而已,而司机提现的时候才从此个人账户转账到了彼个人账户(司机自己开立的银行账户)中;更何况滴滴现在也有支付牌照,就更加有恃无恐了。

这个模式能走得通有几个前提,首先是滴滴与司机都签订了合同(至于司机和滴滴是什么关系,本汪不知道,很可能是对等的合作商关系)明确了双方的权利;其次是司机都是个体户,且每月的收入不超过3万,所以司机才可以不用为乘客开发票,而是由做代收代付的平台方来出具。读者大概都知道,快车和专车的发票是向滴滴申请的,而出租车发票得在下车时找出租车司机要。那是因为出租车公司不属于滴滴啊,出租车司机和滴滴之间也没有合同关系。

滴滴模式的优点是可以少交很多增值税(那是非常多啊!!!),当然营业税还是逃不了,不管有没有毛利都得交。滴滴需要从收入中扣掉司机工资、扣掉补贴等等的款额作为利润算增值税,特别是当年狂补贴的时候,你敢相信它有利润吗?!这种模式一端是个人用户,另一端虽然是B端,但是是个体户,所以能走通。如果两端都是公司或企业,这种模式也行不通,就得用第四种处理方式了。

四、 银行子账户管理模式

上文说过蘑菇街被约谈,在那之后平台也走上了合规的路线(不得已而为之啊,要是没人管,谁特么自找麻烦)。合规后的蘑菇街是通过第四方支付来搭建交易和支付流程的。何为第四方支付呢?第三方支付大家都知道,不就是支付宝、微信之类的么。第四方支付是个什么鬼?

就说中华民族是一个了不起的民族,但凡有利可图就有不怕死的往前冲,但凡有勇士挑战大众的神经,国家就会出面把他灭了。之所以会出现第四方支付大体也是这个逻辑(哈哈哈,也可能不是)。

设想一下,大家都是第三方支付对吧,要不合作一下?(奸笑)反正用户的钱存着也是存着,你缺钱的时候我借你点,我缺钱的时候你再借我一点,这样不是你好我好大家好么?(再奸笑)借来的钱再用来做点其它的金融业务,简直一个爽。这样,就绕过了央妈,那还得了?!所以央行是禁止第三方支付之间的合作的。What?!原来微信支付宝不能互转不是因为在干战啊?当然不是,你见过其它第三方支付之间能相互转账吗?那么第三方支付之间的钱要流转起来该咋整?还是得通过银行。

现在央行对第三方支付的定位已经明确了,就是日常生活中使用的小额资金进出通道,而不能行使银行职能。所以所有的第三方支付只能通过用户绑定的银行卡实现间接的资金流转。而三方支付的所有的资金流动也在央行、税务局等等机构的监管之下,一旦有个风吹草动,出现不正常情况,监管机构分分钟找上门。

再回来说第四方支付。所谓第四方支付为面向于有支付需求的用户提供解决多种方案的供应商,他们可以整合多种第三方支付或者银行渠道,打包给客户,从而使客户在接入支付时更便捷。也就是说第四方支付既能对接银行,也能对接第三方支付,将这些渠道包装好后卖给客户,收取服务费和手续费。

还是说蘑菇街。通过第四方支付的解决方案,蘑菇街在银行开立两类(或者只需要一类)账户:第一类是平台的子账户,第二类(可选)是供应商子账户。一旦发生交易,流程这么进行:

首先说顾客是通过与平台无关的方式(微信、支付宝、银行卡)支付的并且是实时划账的情况(一般只适用于C2B2B),那么付款后钱先进入蘑菇街在银行的账户中,在该账户中平台已经设置好分润的规则,所以钱进来后一部分(比如10%)留在平台账户,剩下的(90%)划入供应商在银行的公户中(只要合同约定好,私户也可以)。如果不采用实时划款给供应商的方式,也可以使用提现的方案,即把顾客支付的钱留在平台在银行开立的账户中,供应商申请提现时再把货款转账给供应商。

然后在说一下用户使用平台“钱包”或者“余额”账户支付的情况(适用于C2B2B和B2B2B)。需要在平台中开立三类账户,除了上述的两种之外,还需要为客户也开账户。如果客户是企业,则和普通的开对公户类似,需要提供三证、法人身份证等;如果客户是个人,则只需要提供一张个人的银行卡即可。交易分为两个步骤,首先是充值,用户通过其它支付方式将钱转入上述开立的银行账户中,同时平台方将金额记录下来并在“钱包”或者“余额中”展示给用户;然后在支付时,需要用户主动付款,将银行账户中的钱先打入平台在银行中的账户,平台账户按照设置好的分润规则截留服务费,然后把供应商应得款项打如供应商的银行账户中。

这种方式的优点是:1.所有的充值、支付都在银行账户中,资金受银行和国家部门的监管,因此完成了合规;2.因为是采用银行内部转账的方式,所以支付时的费率低;3、供应商可以开户也可以不开户,对于个体户来说比较方便。缺点也是有的:B类客户开户依旧比较麻烦,如果个人用户要使用“钱包”功能,那么和微信支付宝一样,需要先绑定一张卡。

对接第四方支付是相对比较高效的,一旦对接之后,各种常见的第三方支付方式(比如支付宝、微信、百度钱包、京东、分期乐等)都可以借助第四方一次搞定,省去分头对接的麻烦。当然,如果读者不怕麻烦也可以和第三方支付谈,谁用谁知道,哈哈哈。

五、 第三方支付账户管理模式

本汪对接的是一家不太出名的支付公司。简单地说,支付公司提供的方案和第四种比较像,也就是说三方支付在账户管理方面行使了一部分类似于银行的职能。

在三方支付中,同样开立三类子账户:平台方账户、客户的账户、供应商的账户,需要说的是客户既可以是C端客户,也可以是B端客户,从业务角度看的话,其区别在于开户的麻烦程度不同(其实都很麻烦…)。客户充值后,钱进入客户的账户,交易时,平台方发出指令,钱从客户账户划入供应商的账户中,同时会按照分润规则将利润转入平台账户内。在整个流程中,平台方是不能动客户账户和供应商账户的,所以就解决的二清的问题。同时,为了保证用户充值的金额能全部到账、供应商提现能实现T+0、做充返营销活动等需求,可以在三方支付内为平台开立多个特殊用途账户。

在第三方支付中开户和在银行中开户需要的资料是差不多的,所以对于平台方,要让客户和上游供应商都提供开户资料是一件相当痛苦的事情。如果想要省事,也只能是在与供应商的合同中约定好权责,然后允许供应商提供私人卡来收取平台方的打款。但是这也只适用于不太正规的供应商。如果供应商内部比较规范,本身就会规避这样的事情发生。毕竟,把公司的钱转给个人,就存在个人卷钱走人的可能。

以上就是本汪接触的5种情况,以后更加了解之后再慢慢补充和完善。

一般来说,采用什么方式需要考虑这些方面:

  1. 是否能使业务合规;
  2. B类用户、C类用户的充值、提现、转账每一类业务的手续费是多少,到账的时间分别需要多久;
  3. B类用户和C类用户是否开户便捷。

另外再补充一下:

  • 关于充值,用户充值是需要向支付渠道支付手续费的,如果想实现充多少钱在平台账户上就显示多少,平台需要垫钱;
  • 关于提现,提现一般是工作日T+1到账,而且也是有手续费的,如果要实现T+0,需要和支付渠道谈实现方式;
  • 关于转账,也有费用

哈哈哈,收费无处不在啊。

B2B价格平台技术分享

来源:京东成都研究院

B2B价格平台目前不仅仅支持上图中出现的价格类型(级别价、阶梯价、京东价、协议价、VIP价、一口价、市场价、零售价、批发价),此外还支持:区域价、区域级别价、区域阶梯价等价格类型;平台支撑了四大业务线:分销、大客户、掌柜宝、医药城,在平台现有650W+的数据中各业务线分别占比为:6.66%、89.75%、0.24%、3.35%;

平台分别由CBI(价格服务中心)、SYNC(异步组件)、SVR(平台服务)、DAL(数据访问层)、RPC(外部服务依赖层)、数据持久(储存层)六大模块组成。

  • 数据持久层:数据库采用Mysql,由于数据量大,借助公司Gum(弹性数据库)实现分库存储和查询。由于价格接口访问量大,接口效应时间和可用率和并发性要求高,数据查询将不直接查询数据库,通过缓存实现。缓存分为两种:本地缓存Ehcache和分布式缓存Redis,其中Redis使用公司统一缓存服务Jimdb,减少维护成本,查询服务首先查询本地缓存,未命中则查询redis缓存。为了解决分库后,批量价格查询跨库问题,引入Es集群。数据库与缓存(Ehcache、Redis)、ES集群、Hbase间数据同步使用BinLake管道减少数据延迟。Hbase集群用于记录价格变化历史归档信息。
  • DAL(数据访问层):价格服务中心与数据层间的通讯管道,提供统一的数据访问服务。为了满足未来价格数据的增量,价格底层数据采用分库,根据业务路由字段访问具体的数据库。
  • RPC(外部服务依赖层):负责与外部依赖接口交互,如:主站仓报价、京东价、POP价格、B2B任务引擎、返利系统等。
  • SVR(平台服务):负责完成平台服务组装。
  • CBI(价格服务中心):由publish服务、pick服务、异步组件组成。其中:
  • Publish服务:支持价格发布服务(写服务),包括:价格设置、价格清零、价格限量(数量增、减)等。
  • Pick查询服务:统一价格查询服务,经过流程编排计算、数据格式转换返回指定价格类型数据。流程编排,针对于不同大客户的合同类型(折扣价、实时价、京东价、稳定协议价、较低协议价、较低实时价)计算、组合出不同的价格。
  • Publish服务、pick服务独立部署,避免读、写服务间互相影响。

价格服务中心的接口需提供JSF、HTTPS两种不同的调用方式,以此便于适应不同的外部调用场景。

  • SYNC(异步组件):由MQ、Worker组成,其中:
  • MQ组件。负责MQ的接收、发送。接收的MQ,如:POP价格变化MQ(新通路POP商品)、京东促销价格变化MQ(大客户),平台价格变化MQ发送;
  • Worker组件。完成历史数据归档、缓存同步、数据清写和纠正;由B2B任务引擎执行统一调度;

上图流程展示了整个平台的数据流向,平台B2B-PRICE-SYNC接收到Binlake变更消息后,调用B2B-PRICE-SVR、B2B-PRICE-DAL服务。B2B-PRICE-DAL层将开启多线程分别完成对异步数据源Jimdb、Hbase、Es集群的异步写,如果Jimdb集群写成功则,发送MQ消息通知Ehcache集群进行数据更新,仅当Jimdb、Hbase、Es集群全部写成功后,再由B2B-PRICE-SYNC对外统一发送价格平台变更MQ消息通知外部系统。如果B2B-PRICE-SYNC调用底层重试3次(保持幂等性)失败,则把数据写入任务引擎,由引擎调度延迟重试。

平台建设中接入了公司的Binlake系统,下面简单介绍下组成Binlake系统的三大服务组件:

  • Wave服务 Wave服务完成实际的数据库Binary Log的持续采集、管理和分发写入到下游的消息发布和订阅系统中。在BinLake集群中会存在N个Wave服务,这些Wave服务共同组成一个无状态集群。
  • Tower服务 Tower服务是整个BinLake的管理中心,提供BinLake接入服务的申请、完成Wave服务、数据源、接入应用的管理。
  • Judge服务

Judge服务主要完成两个功能:Wave节点监控信息采集和loadBalance决策。

ZooKeeper

BinLake使用zookeeper服务进行Wave无状态集群的管理、状态同步和消息通知等。

上图左侧是通过binlake团队提供的工具包解析后的Binlake消息体内容,其中EntryMessage代表一条消息,rowDatas代表Mysql表中变更的行记录(一条消息中可以包含多条记录)。消息体中的EntryType取值:TRANSACTIONBEGIN、TRANSACTIONEND、ROWDATA、HEARTBEAT(binlake内部使用),EventType取值:INSERT、UPDATE 、DELETE、CREATE、ALTER、 ERASE、QUERY、TRUNCATE、RENAME、CINDEX、DINDEX。

当平台接收到Binlake消息后,将对比消息数据与缓存数据的版本号,如果消息数据版本号大于、等于缓存中数据版本号,则使用消息数据更新Jimdb、Es、Hbase集群数据;否则视消息数据为过期数据丢弃(详见上方左图)。一个系统或平台,都不应该完全依赖外部系统,应该有自己的降级方案。当Binlake宕机后,平台分别可以执行MQ降级方案、接口降级方案,以此确保系统不受Binlake宕机影响(详见上方右图)。

价格平台除了发送MQ消息外,还接收外部的MQ消息,详见上图。平台在处理接收到的消息时,为了防止因网络堵塞、系统多实例并发处理速度等因数造成数据错误,在接收到SKU价格变更消息时,首先使用分布式锁对SKU进行加锁,然后调用相应价格接口查询价格,最后与库中数据对比版本号并更新数据,并释放锁。

平台建设中尝试了公司新的技术、服务、与工具,如JED(GUM)、Binlake、JDOS等,节省公司资源、提升了研发效率。

平台建设中难免会踩到一些坑,分享给大家、希望各位在以后的工作中切勿重蹈覆辙。

1、去掉非必要的参数验证,以此提升性能;

2、尽量减少调用链路长度,节约网络开销;

3、服务接口出、入参数数量尽可能少,减少数据网络传输量,增加系统吞吐量;

5、尽可能储存压缩后的数据,节约储存空间;

4、利用mdc记录日志,系统各层间线程唯一编号(业务请求唯一编号)可采取自顶向下、或自底向上逐级传递,可根据业务场景灵活选择;业务请求唯一编号,便于排查线上问题,提升排查问题效率;

5、系统中,应该尽量配置各种开关,用于接口的升降级、配置参数的动态修改、日志打印级别的动态调整;

6、引入自动化测试工具提升测试效率,节约人力成本。如B2B部门自动化测试工具:http://btest.jd.com;

7、兜底方案。系统上线前,应考虑各种兜底方案,确保系统上线后,即使有问题也做到业务零感知;

栏目导航

联系我们

电话:400-1060-365

邮箱:info@untra.cn

地址: 重庆市两江新区互联网产业园13栋6楼

关闭
用手机扫描二维码关闭