电商交易背景知识合集第一季
本文档适用人员:交易领域的产品研发人员
- 银联
- 一些错综复杂的关系
- 银联是什么
- 银联商务是什么
- 快捷支付绕过银联了吗
- 能通过卡号判断是对公账户或对私账户吗
- 快捷支付
- 为什么要推快捷支付
- POS
- POS签单上的各种号码
- 信用卡刷卡后都发生了什么
- 第三方支付公司
- 为什么需要有备付金
- 直联网关和间联网关
- 何谓银企直连
- 支付宝是怎么对账的
- 我们作为商户如何接入
- 预付费卡牌照与第三方支付牌照有什么区别
- 大宗交易电商网站如何接入
做电商开发总会遇到各种不知所谓的产品和不知所云的术语,下面串一下。
中国银联是中国银行卡联合组织,通过银联跨行交易清算系统,实现商业银行系统间的互联互通和资源共享,保证银行卡跨行、跨地区和跨境的使用。中国银联大力推进各类基于银行卡的综合支付服务。
(出处2)
延伸阅读:
- 对公、对私业务入口不同,分流到不同接口,
- 让用户在业务处理过程中提供银行账户对应的属性信息(例如代收付批量文件中),
- 维护各家银行的对公账户规则。这个比较费劲,关键是维护成本较高,
- 一般对公账户的账户名称至少在6位以上,对私账户的名称一般最多3、4位,因此可以先根据账户名称长度做一下判断,再查找是否包含股份公司、有限公司、协会之类的关键词。(注:仅靠长度判断的话遇上维吾尔族人账户名称也是醉了)
这个流程里,支付宝是主动的一方,是支付宝主动扣了小明的款项。
这个流程里,支付宝是被动的一方,是小明主动支付给了支付宝。
注意到上面两个流程的诸多不同了吧?正是这种种不同促使支付宝异常坚定地推行快捷支付,也正是这种种不同促使银行对支付宝又爱又恨,时远时近。
一,快捷支付有助于大幅度提高用户支付的成功率
越高的成功率,就意味着支付宝越多的资金沉淀,在早期,这个资金沉淀就是支付宝和银行合作的基础所在。在通过银行网银支付流程中,影响支付成功率有三个主要因素:
二,快捷支付有助于更好的构筑阿里渴望的大数据。
我们有没有发现在两个流程中,支付宝和银行交互的数据是有巨大差别的?在快捷支付的过程中,支付宝掌握了用户的所有信息,包括身份、账号、验证方式、手机号,如果是信用卡,还有到期日、CVV码等,用时髦的话来说,这就天然的和用户购物流程形成了完整的闭环。这些信息都可以用于构建用户信用基础信息。
而在网银支付的流程中,支付宝只掌握了一个订单号,只知道这个用户下了一个订单,然后订单就被付款成功了。至于谁付的?账号多少?姓甚名谁?手机验证是否准确?等等一系列,都是黑盒子。
如果换做是你,你会希望用户用那种方式呢?
- 对发卡行来说——卡号+参考号+授权号,就能够确定一笔交易;
- 对于收单方来说——凭证号+域7(对应签购单上的日期/时间)+域32(对应签购单上的收单机构)+33域(对应签购单上的发卡机构)能够唯一确定一笔交易。
(出处6)
- 刷卡信息(包括磁道和密码)由 POS 机具受理后通过收单机构送往银联的收单系统。
- 银联收单系统将报文通过银联核心交换平台送到信用卡的发卡银行,根据交易指令,在发卡银行的对应的卡片账户进行扣款。
- 银联核心交换系统收到扣款成功的返回后,将交易结果原路返回到 POS 终端上。
- 当天晚上11点,清算信息开始批量处理。
- T+1日,各行在人行的头寸账户根据银联的清算文件(指令)将资金进行划拨,即交易资金从信用卡的发卡银行转移到商户的收单银行。
- 收单银行将资金转入商户的具体清算账户(也可以由银联直接转入)。
(出处7)
直联网关是相对间联网关而言的,这俩货都是第三方支付里的概念。
真正意义上的银行接口,最常见的是信用卡无磁无密支付接口。这类接口的特点是用户只需输入信用卡面上卡号、有效期、CVV2,便能完成支付。不少支付公司会将这类接口直接提供给商户使用,由商户代为收集用户上述信息并提交到支付公司完成支付。由于此类支付接口风险性很大,故银行要求只能在实名制行业使用。
一个可能得不能再可能的场景,请大家深刻理解里面每个角色做了什么,获取了哪些信息:
某日阳光灿烂,支付宝用户小明在淘宝上看中了暖脚器一只,价格100元。犹豫再三后小明使用支付宝网银完成了支付,支付宝显示支付成功,淘宝卖家通知他已发货,最近几日注意查收。
我们来看看这个过程中有几个相关方,分别做了什么。我语文不好,写得饶口,如果看不懂请多看几次:
小明:持卡人,消费者,淘宝和支付宝的注册会员,完成了支付动作,自己的银行账户资金减少,交易成功。
银行:收单银行,接受来自支付宝的名为“支付宝BBB”的100元订单,并引导持卡人小明支付成功,扣除小明银行卡账户余额后返回给支付宝成功通知,并告诉支付宝这笔交易在银行流水号为“银行CCC”。
支付宝:支付公司,接收到淘宝发来的订单号为“淘宝AAA”的商户订单号,并形成支付系统唯一流水号:“支付宝BBB”发往银行系统。然后获得银行回复的支付成功信息,顺带银行流水号“银行CCC”。
淘宝:我们支付公司称淘宝这类电商为商户,是支付系统的客户。淘宝向支付系统发送了一笔交易收单请求,金额为100,订单号为:“淘宝AAA”,支付系统最后反馈给淘宝这笔支付流水号为“支付BBB”。
以上流程貌似大家都达到了预期效果,但实际上仍然还有一个问题:
对支付公司(支付宝)而言,虽然银行通知了它支付成功,但资金实际还要 T+1 后结算到它银行账户,所以目前只是一个信息流,资金流还没过来。
Tips:插一句话,对支付系统内部账务来说,由于资金没有能够实时到账,所以 此时小明的这笔100元交易资金并没有直接记入到系统资产类科目下的“银行存款”科目中,而是挂在“应收账款”或者“待清算科目”中。大白话就是,这100元虽然答应给我了,我也记下来了,但还没收到,我挂在那里。
对商户(淘宝)而言,虽然支付公司通知了它支付成功,他也发货了,但资金按照合同也是 T+1 到账。如果不对账确认一下,恐怕也会不安。
倒是对消费者(小明)而言:反正钱付了,你们也显示成功了,等暖脚器呀等暖脚器~
基于支付公司和商户的困惑,我们的支付结算系统需要进行两件事情:一是资金渠道对账,通称对银行帐;二是商户对账,俗称对客户帐。对客户帐又分为对公客户和对私客户,通常对公客户会对对账文件格式、对账周期、系统对接方案有特殊需求,而对私客户也就是我们一般的消费者只需要可以后台查询交易记录和支付历史流水就可以了。
我们先聊银行资金渠道对账,由于支付公司的资金真正落地在商业银行,所以资金渠道的对账显得尤为重要。
在一个银行会计日结束后,银行系统会先进行自己内部扎帐,完成无误后进行数据的清分和资金的结算,将支付公司当日应入账的资金结算到支付公司账户中。于此同时,目前多数银行已经支持直接系统对接的方式发送对账文件。
于是,在某日临晨4点,支付宝系统收到来自银行发来的前一会计日对账文件。根据数据格式解析正确后和前日支付宝的所有交易数据进行匹配,理想情况是一一匹配成功无误,然后将这些交易的对账状态勾对为“已对账”。
Tips : 此时,对账完成的交易,会将该笔资金从“应收账款”或者“待清算账款”科目中移动到“银行存款”科目中,以示该交易真正资金到账。
以上太理想了,都那么理想就不要对账了。所以通常都会出一些差错,那么我总结了一下常见的差错情况:
1)支付时提交到银行后没有反馈,但对账时该交易状态为支付成功
这种情况很正常,因为我们在信息传输过程中,难免会出现掉包和信息不通畅。消费者在银行端完成了支付行为,银行的通知信息却被堵塞了,如此支付公司也不知道结果,商户也不知道结果。如果信息一直没法通知到支付公司这边,那么这条支付结果就只能在日终对账文件中体现了。这时支付公司系统需要对这笔交易进行补单操作,将交易置为成功并完成记账规则,有必要还要通知到商户。
此时的小明:估计急的跳起来了……付了钱怎么不给说支付成功呢!坑爹!
Tips:通常银行系统会开放一个支付结果查询接口。支付公司会对提交到银行但没有回复结果的交易进行间隔查询,以确保支付结果信息的实时传达。所以以上情况出现的概率已经很少了。
2)我方支付系统记录银行反馈支付成功,金额为100,银行对账金额不为100
这种情况已经不太常见了,差错不管是长款和短款都不是我们想要的结果。通常双方系统通讯都是可作为纠纷凭证的,如果银行在支付结果返回时确认是100元,对账时金额不一致,可以要求银行进行协调处理。而这笔账在支付系统中通常也会做对应的挂账处理,直到纠纷解决。
3)我方支付系统记录银行反馈支付成功,但对账文件中压根不存在
这种情况也经常见到,因为跨交易会计日的系统时间不同,所以会出现我们认为交易是23点59分完成的,银行认为是第二天凌晨0点1分完成。 对于这种情况我们通常会继续挂账,直到再下一日的对账文件送达后进行对账匹配。
如果这笔交易一直没有找到,那么就和第二种情况一样,是一种短款,需要和银行追究。
以上情况针对的是一家银行资金渠道所作的流程。实际情况中,支付公司会在不同银行开立不同银行账户,用以收单结算(成本会降低),所以真实情况极有可能是:
临晨1点,工行对账文件丢过来(支行A)。
临晨1点01分,工行又丢一个文件过来(支行B)。
临晨1点15分,农行对账文件丢过来。
……
临晨5点,兴业银行文件丢过来。
……
不管什么时候,中国银行都必须通过我方业务员下载对账文件再上传的方式进行对账,所以系统接收到中行文件一般都是早上9点05分……
对系统来说,每天都要处理大量并发的对账数据,如果在交易高峰时段进行,会引起客户交互的延迟和交易的失败,这是万万行不得的。
所以通常支付公司不会用那么傻的方式处理数据,而是 在一个会计日结束后,通常也是凌晨时段,将前一日交易增量备份到专用对账服务器中,在物理隔绝环境下进行统一的对账行为,杜绝硬件资源的抢占。
以上是银行资金渠道入款的对账,出款基本原理一致,不过出款渠道在实际业务过程中还有一些特别之处,由于又不是让大家亲自要建设系统,就不再赘述了。
谈完了资金渠道的对账,我们再来看看对客户帐。
前面提到了,由于资金落在银行,所以对支付公司来说,对银行帐非常重要。那么同理,由于资金落在支付公司,所以对商户来说,对支付公司账也一样重要。能否提供高品质甚至定制化的服务,是目前支付公司走差异化路线的一个主要竞争点。
Tips:之前说过,银行与支付公司之间的通讯都是可以作为纠纷凭证的。原理是对支付报文的关键信息进行密钥加签+ md5 处理,以确保往来报文“ 不可篡改,不可抵赖”。
同理,支付公司和商户之间也会有类似机制保证报文的可追溯性,由此我们可以知道,一旦我方支付系统通知商户支付结果,那么我们就要为此承担责任。由此我们再推断一个结论:
即便某支付订单银行方面出错导致资金未能到账,一旦我们支付系统通知商户该笔交易成功,那么根据协议该结算的资金还是要结算给这个商户。自然,我们会去追究银行的问题,把账款追回。
1)对支付系统而言,最基本的对账功能是供商户在其后台查询下载某一时间段内的支付数据文件,以供商户自己进行对账。
这个功能应该是个支付公司就有,如果没有就别混了。
2)对大多数支付系统而言,目前已经可以做到对账文件的主动投送功能。
这个功能方便了商户系统和支付系统的对接,商户的结算人员无须登录支付平台后台下载文件进行对账,省去了人工操作的麻烦和风险。
对大型支付系统而言,商户如果跨时间区域很大,反复查询该区域内的数据并下载,会对服务器造成比较大的压力。各位看官别笑,觉得查个数据怎么就有压力了。
现在比较主流的做法是把商户短期内查询过、或者经常要查询的数据做缓存,实在不行就干脆实时备份,两分钟同步一次数据到专用数据库供商户查询,以避免硬件资源占用。甚至……大多数支付公司都会对查询范围跨度和历史事件进行限制,比如最多只能查一个月跨度内,不超过24个月前的数据……以避免服务挂掉。
(出处10)
1 移动支付厂商的选型
1.1 支付渠道
由于是 App,采用的支付方式主要大致有如下几种方式:
a App SDK
支持银行卡支付(借记卡、信用卡)、账户支付、快捷支付等。
支付宝、微信支付、银联在线等主流的第三方支付都提供了对应的解决方案。
b WAP/HTML5
与 App SDK 类似,但微信支付目前不开放给第三方的手机网页版。
像信用卡无磁无密支付(ePOS/MOTOPay)、代扣等由于只对实名行业开放,且商家需要资质较好,一般行业应该不适用。
1.2 增值服务的考察
对普通商户而言,在选择第三方支付厂商时候,除了考虑支付渠道、交易手续费外,还需要重点考虑第三方支付提供的其他服务,主要包括如下一些方面:
a 结算周期、结算手续费,
b 提现/退款接口,
c 分账/代付(委托结算)等结算服务:或者叫分润。例如对代理商按照自定义规则对交易进行分账并批量代付到指定的银行账号(对公、对私)。
一般而言,支付宝、财付通(微信支付)、银联在线支付对分账/代付支持较弱,而像快钱/汇付/易宝之类独立第三方支付,在结算服务商策略相对灵活、产品解决方案也相对完善。
综上所述,建议结合自己业务模式,从支付渠道+增值服务两方面对主流第三方支付厂商进行对比,选择最适合自身的厂商。
2 与第三方支付平台对接问题
此问题主要涉及如下两方面:
2.1 平台虚拟账户资金流转问题
简单说来,你自己平台有一套虚拟账户体系,第三方平台也有一套虚拟账户体系,实际资金存放在银行的账户体系中(第三方支付在银行设立的备付金账户中)。你自己平台的账户体系和第三方支付的账户体系、第三方支付虚拟账户体系与银行账户体系间都只涉及信息流转(电子货币),实际的资金流转只发生在银行的账户体系内。
你作为商户接入第三方支付时候,第三方支付会在其平台为你方设立单独的商户虚拟账户(会有多个账户,包括结算账户、现金账户、信用账户等账户类型),你方平台的收单备付金(待结算资金)存放在结算账户中。商户自身也可以通过在线支付等方式对现金账户进行充值,充值金额存放在现金账户中,这样可以解决你所提到的提现资金预存问题。
当然如果你方交易量大(每日待结算资金量大),也可以和第三方支付探讨通过轧差方式。
2.2 提现
对第三方支付而言,影响提现服务因素包括时效性、费率等。
在时效性上一般分为实时、准实时、T+n。大部分情况下,除支付宝、财付通基于提升自己用户体验的考虑支持实时、准实时提现外,一般第三方支付对接入商户及接入商户用户的提现请求都采用 T+1 到账方式:在 T+1 与商户完成结算后,通过批量代付功能完成对应商家用户的提现请求。
(出处11)
预付费卡的发行和受理是分开的, 原则上不允许支付机构同时拥有预付费卡发行+银行卡收单牌照,但可以为预付费卡受理+银行卡收单。
支付机构发行预付卡的,应当提供预付卡的受理服务。
具体请参看:
非金融机构支付服务管理办法(人民银行令〔2010〕第2号)
央行公布非金融机构支付服务管理办法实施细则
(出处13)
一般第三方支付提供的支付方式大致有几种:
1)账户支付
账户支付有几种形态:
a)电商网站自己的账户体系,用户通过第三方支付对网站自有账户充值后再进行支付。
b)直接使用第三方支付的账户体系(与电商账户不绑定),用户充值是充值到第三方支付账户中并支付(注意与快捷支付的区别)。
c)与第三方支付的账户体系同步,此种情况较少采用,除非合作关系较为紧密。
像 C2C、B2B 平台常用的担保支付之类也可以归为账户支付范畴。
一般应用在适合比较重视账户体系建设的网站,支付金额没有限制(取决于充值的金额)。
2)快捷支付
用户在第三方支付账户体系中:
第一步认证授权:经过实名认证后,绑定银行卡
第二步消费:在第三方支付收银台以第三方支付账户登录,下行短信后,输入验证码及交易密码,完成支付。
也有在商户侧绑定授权及完成支付的(例如银联的绑定支付/快捷支付,但只针对有信用的品牌大商户)。
一般应用在电商网站及移动端,且需要第三方支付的账户体系认同度高,用户愿意绑定。支付金额有限制。
3)网关支付
就是典型的在线支付。一般的在线支付对额度会有限制,但基本上能够满足大部分场景的需要。
普通在线支付 B2C、B2B 网关是有交易限额限制。对需要大额支付的商家,大部分的第三方支付网关支付还提供 B2B 大额支付的接口,配合企业网银/个人网银,基本上能够做到无限额支付。一般 B2B 大额支付只提供了 PC 端功能(主要受限于企业网银)。
4)代收、代付
与商户签署代收、代付协议后,直接从用户银行卡扣钱。
一般支付额度较大,应用在信任关系比较紧密的上下游商家间。
5)信用支付
在 B2B 经常会针对信用好的商户进行授信,根据其信用度授予一定额度,因此会有所谓的信用支付概念。
针对以上几种支付形态,还会有一些组合,例如账户余额+网关支付,信用支付+账户余额,一般叫组合支付。
具体使用一种或多种支付方式,需要根据公司业务形态来确定。
另外如果公司交易量大的话,从降低成本等角度考虑,一般会在交易平台前端自建一个类支付的平台,主要用于接入多家支付公司,各家支付公司支付通道路由、统一对账等,另外还会适度接入一些直连银行(注:通过银企直连接口)。
转载于:https://my.oschina.net/zhengyun/blog/502890
电商交易背景知识合集第一季相关推荐
- 各大电商平台API接口合集-苏宁易购获得suning商品详情 API 返回值说明
接下来以苏宁易购为例,演示获取API数据的方式 onebound.suning.item_get 公共参数 请求地址: https://api-gw.onebound.cn/suning/item_g ...
- 近70套电商详情设计模板合集,店铺装修能省不少
素材在这里,70套 附带PSD源文件和JPG预览图,文件大小4G多点 希望大家能够喜欢 下载地址:https://mdl.ink/K9tWlI
- 汇付国际为跨境电商赋能:做合规的跨境支付平台!
跨境支付行业是跨境电商的关键"连接器",一方面由于疫情线上消费习惯的市场培育以及国民群众的消费升级,一方面依托于数字技术的快速迭代,以及支付渠道的不断完善,跨境支付业务呈现出惊人的 ...
- 写给Android App开发人员看的Android底层知识合集(1-8)
写给Android App开发人员看的Android底层知识合集(1-8) 转自包老师:http://www.cnblogs.com/Jax/p/6864103.html 写给Android App开 ...
- 架构设计 | 基于电商交易流程,图解TCC事务分段提交
本文源码:GitHub·点这里 || GitEE·点这里 一.场景案例简介 1.场景描述 分布式事务在业务系统中是十分常见的,最经典的场景就是电商架构中的交易业务,如图: 客户端通过请求订单服务,执行 ...
- 跨境电商平台运营知识:亚马逊日常运营技巧
亚马逊运营是一个综合性很强的职业,有非常多的亚马逊运营技巧需要去学习,下面海熹跨境人才网整理亚马逊日常八大运营技巧,一起来学习一下吧. 1.首页 进行CPC时,关键词的转换率越高,排名就会提高得越快. ...
- 京东如何打造K8s全球最大集群支撑万亿电商交易
在过去一年里,Kubernetes以其架构简洁性和灵活性,流行度持续快速上升,我们有理由相信在不远的未来,Kubernetes将成为通用的基础设施标准.而京东早在2016年年底上线了京东新一代容器引擎 ...
- 直播助力杭州电商独角兽冲击上市,分账系统重构电商交易新格局
从2016年传统电商开始探索"直播+电商"新模式,到短视频平台的弯道超车,五年内直播电商实现了从零到2万亿GMV的突破.从占比上看,2021年,全国网上零售额达13.1万亿元,直播 ...
- 基于一个电商交易数据分析项目的浅析
一. 背景及数据来源 背景: 电子商务交易相对于传统零售业交易来说,最大的特点就是一切都可以通过数据化来监控和改进.通过数据可以看到用户从哪里来.如何组织产品可以实现很好的转化率.你投放广告的效率如何 ...
最新文章
- python输出一个月日历表_关于python一个月总结
- HDU 4411 Arrest(费用流)
- 加拿大大学计算机排名2015,加拿大大学计算机排名
- 浅谈Handler机制
- Actor-ES框架:Ray-Handler-消息订阅器编写
- django小结191107
- 企业级 Docker Registry--harbor安装和简单使用
- 13-微信小程序商城 产品简介布局(微信小程序商城开发、小程序毕业设计、小程序源代码)(黄菊华-微信小程序开发教程)
- 我的世界java边境之地_《我的世界》:手机版的边境之地你绝对没见过!那里方块只有空壳?...
- scrapy项目-爬取阳光问政
- html5+canvas+九宫格,javascript+canvas制作九宫格小程序
- Blackbox_exporter概述
- BIG DATA 神奇的大数据 - Hadoop(Linux)环境搭建与部署
- linux RAID管理与恢复误删除文件
- Netty 实现一对一客户端聊天(由服务器转发)
- 计算机网络安全杨寅春,若干部分盲签名方案的密码学分析和改进
- Kotlin系列——构造函数精讲
- Linux X 视窗编程基础
- HTML5期末大作业:淘宝网站设计——仿2021淘宝首页(1页) 大学生网页制作教程 表格布局网页模板 学生HTML静态水网页设计作业成品 简单网页制作代码 学生商城网页作品免费设计
- 已解决ValueError: Shape of passed values is (1509, 1), indices imply (1509, 2)
热门文章
- 20210507新版友价框架制作江雀网店交易天猫淘宝京东拼多多唯品会网店转让送手机版系统
- Symbian OS C++程序员编码诀窍
- 从头撸到脚,SpringBoot 就一篇全搞定!
- 【剑指 Offe】11. 旋转数组的最小数字
- matlab 变量上小尖尖,发动机最中间的那个小尖尖,你猜是什么?
- 沈理工大学计算机设计专业,沈理工学子在全国大学生计算机设计竞赛中喜获佳绩...
- 深大uooc学术道德与学术规范教育第一章
- Latex去除正文中的章节编号但同时在目标中保留索引
- 基于MatlabSimulink的汽车等速百公里燃料消耗量仿真
- 复制的eclipse常用快捷键 和 设计模式理解方式