Java生鲜电商平台-电商支付流程架构实战

Java生鲜电商平台-电商支付流程架构实战

 

说明：我一直秉承的就是接地气的业务架构实战。个人文章都有一个这样的核心。

1. 业务场景

2. 解决问题。

3.代码实现。

4.代码重构。

5.总结与复盘。

6.缺点与防范

 

1、场景描述

想必你们都曾遇到过这个问题，在电商购物的过程当中，已经走到了最后一步：去支付。这个时候忽然意识到商品数量不对，或者收货信息选错。

除此以外，用户还存在之下返回的缘由：

误点击，也就是说用户仍是想买的；

犹豫中点了返回，想买的欲望不是十分坚定；

坚定不买了。

2、可选方案

（1）目前几乎全部主流电商平台，在支付页面点击返回跳转到订单的待支付页面。

 

 

 

 

 

（2）有一部分微商城，依然原路径返回，不过依然生成了待支付订单。

 

 

（3）原路返回，也不生成待支付订单，不过做者目前并无找到此类型的案例。

 

3、为何要有「待付款」状态

1. 库存计算

在电商系统中，前端页面显示的库存与仓库的实体库存是不一样步的，于是在商品出仓前要求前端的库存进行「锁定」即前端的减库存。

关于库存的锁定，电商领域存在有两种方案：

一种是拍下减库存即生成订单（待付款）减库存，故此方案绕不过「待支付」；

一种是支付成功减库存。

拍下减库存存在的问题：

用户可能拍下不买，不乏存在有用户把拍下当收藏夹用，以至占用库存，影响平台的交易量。甚至存在更为极端的「恶拍」漏洞，竞争对手会把商品全部库存全都拍掉，也不付钱，平台的商品就所有被下架了。

支付成功减库存存在的问题：

支付成功减库存会碰到最严重的问题，是「超卖」。由于系统在付款成功以前，都不减库存，因此老是会发生“短期不少人都拍下，甚至都付钱了，可是系统却发现库存不够了”。

买家拍下商品后，从提交付款到付款成功的之间是有时间差的，由于付款的动做是在几个不一样的系统之间传信息。所以最后一件商品可能被多人拍下，这几我的均可能付款成功。

淘宝的作法是把什么时候减库存的决定权交给卖家，而后告知卖家两个方案各自适应的场景。

 

2. 提升转化

电商是经过交易驱动的产品类型，所以订单的每一步都要考虑转化率，提升转化率是电商的基础要求。

用户在电商下单，大多都是会进行一番思考的，毕竟支付宝里的钱也不是河水流过来的。用户在支付前总会有种种缘由搁置付款，通常待支付订单的有效时间为24小时之内，在这段有效时间内平台就像一名促销员同样，告知你有未付款的订单。

 

 

4、肯定解决方案

结果是几乎全部的电商都采用了从支付页面返回跳转至待支付的方案。

从用户角度来考量：退回去修改信息（收货信息、商品信息）必定是用户真实存在的诉求。

在商家的角度：提升订单的成交率，是第一要务。这个时候最好的办法就是利用数据工具，作埋点和统计，根据各类状况出现的几率作出相应的决策。

 

 五：代码方面

       QQ群