20170714-某二手车的业务和支付

Posted by PaymentGroup on July 14, 2017

一、专题分享:某二手车的业务和支付

20170714_190154.png

1.1 背景说明

今天分享的主题是《某二手车支付业务分享》,我之前在XX负责支付相关产品,这次给大家分享一下之前做过的一些项目,希望能给大家有一些启发~

20170714_190308.png

今天我会分三个方向讲,XX的业务模式-XX的的基本交易流程和衍生服务
XX的支付场景-在特定的业务模式下,催生了哪些独特的支付场景
支付产品架构-为了满足业务的要求,我们怎么搭建的支付产品架构

1.2 XX的业务模式

XX是一个C2C的交易平台,车主将车放到平台上,买家在平台浏览,对意向车型进行购买,XX在中间撮合成交,挣X%的服务费。

当然这只、是最基本的业务,只占XX营收的一部分,由基本业务衍生的其他服务,比如金融保险、过户、保养等才是XX未来重点的营收。

20170714_190510.png

我将基本业务粗略的分为三个阶段,及每个阶段大概做的事情,我只是简单说明一下,为接下来支付业务做铺垫,就不拆开细讲了(也涉及一些敏感信息),如果大家由兴趣可以私下单聊。

重点说一下车源匹配,这块也是XX花了大力气去做的一件事情,堆了好几个科学家。

这块也是最近互联网的风口,今日头条、淘宝、等都在做类似千人千页的事情。

经过数据算法分析,把你最感兴趣的车、商品、新闻投放到你的页面中去,提升转化率

1.3 XX的支付场景

20170714_190830.png

XX的业务模式决定了支付场景
比如,XX的成交金额较大,在几万到几十万不等,X%的服务费在两千到几万元不等
车辆交易场景大多在线下当面进行
所以需要在销售的CRM系统上集成满足大额、当面支付、安全稳定的支付系统

开始没有线上支付时,XX的服务费、车款、金融费用等全部是由线下收取的,管理成本与风险极高(如道德风险、假币、分城市保管、定期向总部汇款等)

目的:

  • 让买卖双方交易更便捷,更放心
  • 便捷的支付方式,提高销售效率
  • 减少资金周转,降低资金风险
  • 增强对交易环节的把控,降低交易失败风险
  • 便于财务汇总统计,为之后的清结算打下基础

这是我们当初做支付系统的目的与想要解决的问题,从而形成产品定位,为之后的方案设计、开发优化指明方向

接下来挑两个符合XX支付场景,大家不多见的支付方式简单分享一下,对于to C的产品使用可能不太多,这里只是给大家扩展下思路

20170714_191051.png

截几个页面给大家看,这是很久前的版本,也是测试数据,但大家还是尽量不要外传。这个是XX的订单页面,在撮合成交、签完合同后,就会生成业务订单,依据业务订单进行支付

由于XX的交易金额比较大,所以我们需要支持多次分笔支付,这样无形中会使后台的处理逻辑更加复杂,如部分支付、全部支付、部分退款、全部退款、内部退款、内部退款转外部退款等,业务订单又有时效性等业务限制,所以我们当时改动一个很小的逻辑,可能都得考虑很多方面的因素
这块我就不详细讲了,说多了都是泪

选择订单和支付方式后,就进入到支付页

20170714_191242.png

这个是扫码支付的页面,类似于我们去饭店和小卖店,他在墙上贴的那个二维码,只不过我们这个二维码是即时生成在销售使用的CRM上的,与我们的订单系统相关联,支付完成后,在后台可以看到每个订单的支付信息,这也为后续的查账、对账、清结算、业绩等打下基础

这里有个小故事分享给大家,我们当初有两种支付方式供我们选择,一种是客户主扫,一种是客户被扫,两种模式我们经过客户走访和调研,发现客户拿出手机被扫会有一种被侵略的不安全感,客户主扫这种不安全感会大大降低,但是现在很多超市和连锁餐厅都使用客户被扫的模式,我觉得可能是这样能提高收银员的效率;但是我们的支付场景和餐厅不一样,我们大多是是在户外进行,客户的不安全感要比门店高很多,所以我们最终选择了客户主扫模式

20170714_191339.png

这个是移动蓝牙pos支付,这个区别于超商收银台的传统pos(功能比较单一、仅有拨号收单功能,具体大家可以自行百度pos机的各种类型)

我们选的这款pos是M36,使用蓝牙与手机链接,通过销售的CRM与订单系统相关联,在手机上选择订单,输入支付金额后,刷卡支付即可,可以打印小票(包含电子小票和纸质小票)
当然后来也有更先进的pos设备,比如连连推出的智能pos等,但成本就更高了,我们经过多方考量后,决定使用这款pos

由于市场上的同类产品较少,没有借鉴的地方,全靠摸着石头过河,在开发和对接pos的过程中也遇到不少的坑(比如掉单等,即使是万一也很致命,用户体验很差),这里就不详细展开了(都是血泪史),如果大家有兴趣可以单聊

20170714_191500.png

这是手机上的签名页面与交易结果展示页

20170714_191544.png

这是我当初做的同一机型,两家支付公司做的比较,应该是一年前的参数了,仅供大家参考,切勿外传

当然还有很多其他支付场景(车商使用的APP、PC、H5等)
使用的支付方式就是大家常用的,微信、支付宝、直连、网银、代收(金融)、代付(财务出款)等,大家都是老炮儿,我就不在这卖弄

20170714_191641.png

接下来说一下我们这个项目后来取得的成果
服务费的线上支付率由0,上升到99.9%以上(不能排除有些矫情的客户就是给现金)

线上支付率的上升,随之带来的就是各种成本与风险的下降,扣除给渠道的手续费后,我们每月仍能为公司减少不少成本

1.4 支付产品架构

接下来说一下,我们为了满足以上的支付场景,后台产品架构的搭建

20170714_191905.png

这个是之前在XX做的支付产品的架构,这其中是包含商品库系统、合同系统、订单系统、支付系统,还有一些数据流向

简单介绍几个名词

商品:我把所有业务的收费项,无论是实物的、还是非实物的,都抽象成一个个商品

接下来根据业务需要,决定是否需要走合同系统,并生成业务订单

各业务的业务订单流向又不太一样,所以需要做后台的配置表,争取做成公共组件

20170714_192218.png

这是其中一个业务的业务流转图,内部结构很复杂,我就不细讲了

最终都会落到支付订单,由支付订单为财务系统、BI等系统输送数据源,供财务、商业分析等部门进行核算与分析

1.5 财务系统

接下来还有一些财务系统的事,我就不给大家细讲了(因为又是一座冰山,我只略微了解皮毛,就不班门弄斧了

财务系统主要分为两大块:财务操作和财务清结算

项目的主要衡量指标有:业务覆盖率、数据错误率、人员效率

这块不是我一个人做的,是另外一个专门做财务的同事主导,我做些辅助性工作

20170714_192750.png

以上就是我今天的分享内容

1.6 Q&A

Q: 其实可以考虑再接入支付宝微信等支付二维码,在整合订单和支付里。我的意思就是中间可以再合并掉一个页面,直接进入支付页面

A:嗯嗯,我们之后是简化了一些流程,这个是之前的版本。


Q:那么多状态 是不是都是相对独立的产品服务?

A1: 把一些状态抽象出来,仔细理一下,会发现其实不同的业务的某些状态和流程是相同的,可以做成公共组件

A2:嗯,是的,其实中后台的支付订单这块是公共服务,基本大家设计都是差不多的,嵌套进去erp或者crm形成闭环

A3:嗯,我(分享者)当时看了一些其它电商的订单,比如京东、美团之类,都有共通点

A4:嗯,不过区别在于容错机制


二、Q&A

Q:XX如此大的额度,是做分期的好选择

A1:这个分期财务成本太高,用户选择二手车一般不会选择贷款的,基本都是新车去4s店免费分期了

A2:也不一定吧,10W以上的二手车还是可能会考虑分期的

Q:二手车金融还是有很大市场

A1:房贷,车贷个人感觉都是金融很好的场景,而且单纯做中间商也不是长久之计,最后很多都玩儿起金融,即使自己不做,也会接入外部的

A2:有数据做支撑,金融变现能力很强

三、自由讨论


Q:有没有哪位同仁接了央行的网联平台,我的问题是,现在网联不是一天可进行多个批次的对账嘛,但是网联平台本身不告诉你批次信息,那么在这种情况下如何做到获取明确的批次信息,进行明确的批次对账?
==待回复==

3.1 关于apple pay token生成的问题

Q:请教个问题,applypay的时候,token是谁生成的,银联还是发卡行?

A:银联吧

Q:如果是银联的话,是不是收单机构上送了token,然后银联转换成卡号发给发卡行?因为apply pay小票上打印的是token,不是卡号

A:apple pay自己包了一层,加密服务在apple 服务器自己的,到银联可能是真实的卡号了

Q:我取日志看下,看pos送是什么,感觉pos读出来的就是token了

A:嗯,是的

Q:如果是apple包的,那银联收到交易后需要取apply解析了

A:NFC芯片将Token发送给POS;
POS将Token和其他交易信息发送给收单行;
收单行将Token和其他交易信息发送给银联交易转接服务器;
银联交易转接服务器将Token发给Token SP;
Token SP通过Token对应出PAN,将PAN回送至银联交易转接服务器;
银联交易转接服务器将Token、PAN和其他交易信息发给发卡行;
发卡行进行交易授权,并将PAN和授权信息回送至银联交易转接服务器;银联交易转接服务器将Token和授权信息回送至收单行;
收单行将Token和授权信息回送至POS;POS提示交易成功,打单。Token SP是苹果的服务器。

横向比较传统支付和Apple Pay,实际上后者比前者多了两个参与方,就是令牌申请方Token Requestor和令牌服务提供商Token SP,这两方的存在保障了用户PAN的安全,降低了PAN泄露的概率。

20170714_113906.png

Q:那需要生成一张虚拟卡吗?因为需要根据55域判断

A:嗯,是的,绑卡就是申请token的动作

Q:不是说apple不存储真实银行卡信息吗?

A:所以apple pay不是所有银行支持,只有银行改造了才支持

Q:虚拟卡的55域和真实卡的55域不同,是谁生成的?只有发卡行能生成55域吧

A:发卡行,银联还是承担的交易转接的角色

20170714_114122.png

Q:啊,原来是token服务商去申请的虚拟卡,是这样吧

A1:对!所以需要一家家去接入,不是所有银行支持

A2:token是tsp产生的,映射关系也在tsp

Q:那apple应该只有虚拟卡信息和部分卡号信息吧?

A:手机端存的是TOEKN,苹果TOKEN SP存的是授权信息


3.2 、EMVCo的规范

对标记化感兴趣的可以看看这个 EMVCo的规范,银联也是遵循这个规范基础提出了自己的标计划落地实现。银联在目前的模式下承担了清算网络和tsp的双重职责。

Q:以后visa master进来需要了解的

A1:所以需要进行边际的区分 不能笼统的说银联 虽然目前是银联 但是在交易过程中承担的角色不同。目前TSP的列表

A2:所谓的token化是指帐号的token化 所以掌握帐号的机构才做得了

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