一、专题分享：某二手车的业务和支付
1.1 背景说明
今天分享的主题是《某二手车支付业务分享》，我之前在XX负责支付相关产品，这次给大家分享一下之前做过的一些项目，希望能给大家有一些启发～
今天我会分三个方向讲，XX的业务模式－XX的的基本交易流程和衍生服务
XX的支付场景－在特定的业务模式下，催生了哪些独特的支付场景
支付产品架构－为了满足业务的要求，我们怎么搭建的支付产品架构
1.2 XX的业务模式
XX是一个C2C的交易平台，车主将车放到平台上，买家在平台浏览，对意向车型进行购买，XX在中间撮合成交，挣X%的服务费。
当然这只、是最基本的业务，只占XX营收的一部分，由基本业务衍生的其他服务，比如金融保险、过户、保养等才是XX未来重点的营收。
我将基本业务粗略的分为三个阶段，及每个阶段大概做的事情，我只是简单说明一下，为接下来支付业务做铺垫，就不拆开细讲了（也涉及一些敏感信息），如果大家由兴趣可以私下单聊。
重点说一下车源匹配，这块也是XX花了大力气去做的一件事情，堆了好几个科学家。
这块也是最近互联网的风口，今日头条、淘宝、等都在做类似千人千页的事情。
经过数据算法分析，把你最感兴趣的车、商品、新闻投放到你的页面中去，提升转化率
1.3 XX的支付场景
XX的业务模式决定了支付场景
比如，XX的成交金额较大，在几万到几十万不等，X%的服务费在两千到几万元不等
车辆交易场景大多在线下当面进行
所以需要在销售的CRM系统上集成满足大额、当面支付、安全稳定的支付系统
开始没有线上支付时，XX的服务费、车款、金融费用等全部是由线下收取的，管理成本与风险极高（如道德风险、假币、分城市保管、定期向总部汇款等）
目的：
- 让买卖双方交易更便捷，更放心
- 便捷的支付方式，提高销售效率
- 减少资金周转，降低资金风险
- 增强对交易环节的把控，降低交易失败风险
- 便于财务汇总统计，为之后的清结算打下基础
这是我们当初做支付系统的目的与想要解决的问题，从而形成产品定位，为之后的方案设计、开发优化指明方向
接下来挑两个符合XX支付场景，大家不多见的支付方式简单分享一下，对于to C的产品使用可能不太多，这里只是给大家扩展下思路
截几个页面给大家看，这是很久前的版本，也是测试数据，但大家还是尽量不要外传。这个是XX的订单页面，在撮合成交、签完合同后，就会生成业务订单，依据业务订单进行支付
由于XX的交易金额比较大，所以我们需要支持多次分笔支付，这样无形中会使后台的处理逻辑更加复杂，如部分支付、全部支付、部分退款、全部退款、内部退款、内部退款转外部退款等，业务订单又有时效性等业务限制，所以我们当时改动一个很小的逻辑，可能都得考虑很多方面的因素
这块我就不详细讲了，说多了都是泪
选择订单和支付方式后，就进入到支付页
这个是扫码支付的页面，类似于我们去饭店和小卖店，他在墙上贴的那个二维码，只不过我们这个二维码是即时生成在销售使用的CRM上的，与我们的订单系统相关联，支付完成后，在后台可以看到每个订单的支付信息，这也为后续的查账、对账、清结算、业绩等打下基础
这里有个小故事分享给大家，我们当初有两种支付方式供我们选择，一种是客户主扫，一种是客户被扫，两种模式我们经过客户走访和调研，发现客户拿出手机被扫会有一种被侵略的不安全感，客户主扫这种不安全感会大大降低，但是现在很多超市和连锁餐厅都使用客户被扫的模式，我觉得可能是这样能提高收银员的效率；但是我们的支付场景和餐厅不一样，我们大多是是在户外进行，客户的不安全感要比门店高很多，所以我们最终选择了客户主扫模式
这个是移动蓝牙pos支付，这个区别于超商收银台的传统pos（功能比较单一、仅有拨号收单功能，具体大家可以自行百度pos机的各种类型）
我们选的这款pos是M36，使用蓝牙与手机链接，通过销售的CRM与订单系统相关联，在手机上选择订单，输入支付金额后，刷卡支付即可，可以打印小票（包含电子小票和纸质小票）
当然后来也有更先进的pos设备，比如连连推出的智能pos等，但成本就更高了，我们经过多方考量后，决定使用这款pos
由于市场上的同类产品较少，没有借鉴的地方，全靠摸着石头过河，在开发和对接pos的过程中也遇到不少的坑（比如掉单等，即使是万一也很致命，用户体验很差），这里就不详细展开了（都是血泪史），如果大家有兴趣可以单聊
这是手机上的签名页面与交易结果展示页
这是我当初做的同一机型，两家支付公司做的比较，应该是一年前的参数了，仅供大家参考，切勿外传
当然还有很多其他支付场景（车商使用的APP、PC、H5等）
使用的支付方式就是大家常用的，微信、支付宝、直连、网银、代收（金融）、代付（财务出款）等，大家都是老炮儿，我就不在这卖弄
接下来说一下我们这个项目后来取得的成果
服务费的线上支付率由0，上升到99.9%以上（不能排除有些矫情的客户就是给现金）
线上支付率的上升，随之带来的就是各种成本与风险的下降，扣除给渠道的手续费后，我们每月仍能为公司减少不少成本
1.4 支付产品架构
接下来说一下，我们为了满足以上的支付场景，后台产品架构的搭建
这个是之前在XX做的支付产品的架构，这其中是包含商品库系统、合同系统、订单系统、支付系统，还有一些数据流向
简单介绍几个名词
商品：我把所有业务的收费项，无论是实物的、还是非实物的，都抽象成一个个商品
接下来根据业务需要，决定是否需要走合同系统，并生成业务订单
各业务的业务订单流向又不太一样，所以需要做后台的配置表，争取做成公共组件
这是其中一个业务的业务流转图，内部结构很复杂，我就不细讲了
最终都会落到支付订单，由支付订单为财务系统、BI等系统输送数据源，供财务、商业分析等部门进行核算与分析
1.5 财务系统
接下来还有一些财务系统的事，我就不给大家细讲了（因为又是一座冰山，我只略微了解皮毛，就不班门弄斧了
财务系统主要分为两大块：财务操作和财务清结算
项目的主要衡量指标有：业务覆盖率、数据错误率、人员效率
这块不是我一个人做的，是另外一个专门做财务的同事主导，我做些辅助性工作
以上就是我今天的分享内容
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泄露的概率。
Q：那需要生成一张虚拟卡吗？因为需要根据55域判断
A：嗯，是的，绑卡就是申请token的动作
Q：不是说apple不存储真实银行卡信息吗？
A：所以apple pay不是所有银行支持，只有银行改造了才支持
Q：虚拟卡的55域和真实卡的55域不同，是谁生成的？只有发卡行能生成55域吧
A：发卡行，银联还是承担的交易转接的角色
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年以上）的产品经理、软件工程师、架构师等，提供交流平台。如想加入本群，请在本文评论中留言（不公开），说明所在的公司、负责的工作、入群分享的主题和时间。
- 长按或者扫描二维码来打赏，感谢支持群管理工作！
- 请扫码关注“凤凰牌老熊”的微信公众号。
