1、主题分享：某二手车业务及支付

1.1 背景说明

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

今天我从三个方向来谈谈XX的商业模式——XX的基本交易流程和衍生服务

XX的支付场景——特定的商业模式下催生了哪些独特的支付场景？

支付产品架构——为了满足业务需求，我们如何构建支付产品架构？

1.2 XX的商业模式

XX是一个C2C交易平台。 车主将自己的汽车放到平台上，买家在平台上浏览并购买自己想要的车型。 XX 代理交易并赚取 X% 的服务费。

当然，这只是最基本的业务，只占XX收入的一部分。 由基础业务衍生出来的其他服务，如金融保险、转账、维修等，将是XX未来的重点收入。

我把基本业务大致分为三个阶段，每个阶段大致做什么。 我只是简单解释一下，为接下来的支付业务做铺垫，就不详细说了（还涉及到一些敏感信息）。 有兴趣的话可以私聊。

我们重点关注车源匹配。 这是XX花了很大力气，聚集了好几位科学家的事情。

该领域也是最近网络上的热门话题。 头条、淘宝等都是在做几千人、几千个页面的事情。

经过数据算法分析，将您最感兴趣的汽车、产品、新闻放到您的页面上，提高转化率。

1.3 XX支付场景

XX的商业模式决定支付场景

比如XX的交易金额比较大，从几万到几十万不等，X%的服务费从2000到几万元不等。

车辆交易​​场景多以线下、面对面的方式进行。

因此，有必要将一套满足大额、面对面支付、安全稳定要求的支付系统集成到销售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 金融体系

接下来，还有一些关于金融体系的事情，我就不细说了（因为又是一座冰山，我对它的了解也只是粗浅的，所以就不细说了）。

金融体系主要分为金融业务和金融结算两大部分。

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

这不是我一个人完成的。 它由另一位专门从事金融的同事领导。 我做一些辅助工作。