从0到1构建电商平台之订单系统(2):支付订单
上一篇笔者为大家介绍了订单系统中关于提交订单操作相关的问题:《从0到1构建电商平台之订单系统(1):提交订单》,提交订单之后,接下来要做的是“支付订单”。
电商平台主要会涉及商家系统、商品系统、订单系统、售后系统、会员系统、营销系统、财务系统、数据系统等。我会把订单系统的文章拆分成三篇,本篇是第二篇。
虽然每个公司的具体需求与业务场景不一样,我们平台的功能需求可能其他平台不尽相同,但整个订单的产生到结束的,主要有以下3个流程:
上一篇文章我们是写的是提交订单这一步操作,当用户把订单提交后此时后台会有两步操作:
1)拆单
由购物车进入提交订单页面时可能有多商家多商品的情况,一旦提交了订单就会涉及到拆单(不管是否成功支付),一般来说最简单的是按商家拆,拆完后分别流转至相应的商家后台,用户在客户端的订单列表也会看到多个子订单;如果业务场景要求的话可以再按仓库等维度拆,这里不做展开;
2)生成账单
生成账单的目的是为了记录该笔母订单的金额,如商品金额、抵扣总金额、各商品分别抵扣金额、用户需支付金额等,用户将要支付的是母订单的账单,当该笔账单已完成,则各子订单状态跳转为待发货;
注意,如果用户在支付页面退出,此时账单也会随着商家拆分成各子账单,因为用户可以在订单列表里分别对拆分后的子订单进行支付
下面是支付页面的字段和各项判断流程:
一、支付方式
1. 支付宝/微信等三方支付
由开发同学对接好三方支付平台的接口即可,这里不做展开。
2. 余额支付
用户在平台会通过一定的方式获取余额(非充值,也非用来抵扣的金币,是一种支付方式),此时有2种情况:
1)金币完全抵扣
当金币能完全抵扣时,在支付页面可以只显示余额支付;因为此时支付金额虽然为0,但需要选择余额支付并输入支付密码,目的是为了防止被他人盗用(当用户选择支付宝/微信支付时需输入支付密码,相当于已经起到了防止作用)
2)金币非完全抵扣/未抵扣
此时用户只能选择一种支付方式,但如果余额小于支付金额只能选择支付宝/微信。
二、 判断流程与思考
1. 锁定库存:两种方案
1)提交订单即锁库存
这样做的优点是用户的体验较好,我提交了订单这个商品就是我的了,我可以慢慢付款;
缺点是可能会导致真正有购买需求的用户无法购买,比如甲用户先提交订单锁定了库存他还在考虑中,不一定会买,但是乙用户想立即购买确发现没货了(也不排除有人恶意下单锁定库存)
所以待付款订单一般都会有剩余支付时间,比如30分钟,到了时间自动取消订单并释放库存,或者在添加商品的sku时设置单人限购数量,这样一个账号只能在某一段时间内购买n次,同时技术上也可以做限制,同一ip只能购买n次
2)支付成功才锁库存
这样做的优点是可以筛掉恶意下单的情况;缺点是用户的体验会差一些,可能付款慢一点就会失去购买的机会。
我们平台采用的是a方案,可以根据不同的业务场景选择不同的方案。
2. 是否能下架商品?
进入支付页面说明该订单已生成,且处于待付款状态,此时需要注意的是此时商家是否能下架商品。
1)能
可能会导致用户在已经支付订单时提示商品已下架,因为此时订单已经生成,处于待付款状态;只有让系统自动取消该订单,但对用户是比较不友好的
2)不能
对商家是不友好的,因为判断条件为订单处于待付款,此时用户可能不付款退出,订单也会处于待付款;
衍生的情况就比较麻烦了,哪怕待付款订单自动取消的时间为30分钟,也会存在不断有用户下单,商家就可能一直不能下架商品,后续的问题可能会更大,但如果此时限制其他用户不能下单,那么就在技术与商家的操作上都会比较复杂(具体的操作这里不做展开)。
我暂时没有想更好的解决方案,采用的第一种方案。
3. 验证sku信息是否更改
当订单处于待付款时商家修改了sku(下架商品 – 编辑商品 – 工作人员审核上架),该订单同样不能付款,因为和此时的商品信息甚至金额可能和之前发生了改变,与之衍生的可能就是商家与用户的纠纷。
注意:如果采用的是商家不能下架商品的方案,则这一点就不用验证(所以2、3两点没在流程图上体现出来)。
4. 是否支付成功
支付成功即生成待发货订单,立即锁定库存。
支付失败则还是为待付款订单,然后开始倒计时;一般平台商品库存充足倒计时可长一点,对用户会友好一点,库存不怎么充足或者平台上入驻的小商家居多,平台无法控制商家的库存或者下架之类的操作;
如果也考虑到时间给用户带来的紧迫感的话,时间可以短一些;时间一到订单状态就应变成已关闭状态,用户无法支付,同时释放库存。
订单成功支付后就需要商家处理订单了,同时用户也可以进行一些操作,下一篇“处理订单”。
本文由 @张璨 原创发布于人人都是产品经理,未经作者许可,禁止转载。
题图来自Unsplash,基于CC0协议。
期待老师写关于结构化能力、商业洞察、需求洞察、抽象能力、架构能力、逆向思维等方面的文章!!!
为什么会有锁定库存和扣除库存两种状态,他们起到的效果其实是一样的,都是让前端显示的可售库存-1,其他用户无法购买到这件商品,那么是不是可以在提交订单的时候就扣除库存,而不是锁定库存,如果订单取消,那么再归还库存,这样还能少一个状态,简化流程,也可避免一些该状态下的衍生问题。
锁定可以恢复,但是扣除就不能恢复
扣除也可以恢复呀,反正记录了扣除的数量,到时候相应的增加对应数量不就等于恢复吗
1、支付后,多个子订单的变成“待发货”状态,那要是其中部分商家发货了,部分商家还没有发货。请问母订单的订单状态时什么?
已发货?待发货?部分发货?
2、那如果部分发货中有的商品已经收货了是待评价,部分商品待收货,那子订单状态是什么?
待评价?待收货?部分收货?
2-1、母订单的状态又是什么?
3、如果收货的商品中有部分(数量)售后,那又会不会影响到商品的在状态显示?如果会,那又会不会继续传承到子订单和母订单的状态呢?
支付后拆单是对不同商家一并支付的情况(购物车下单),所以拆了之后就没有你说的这个母订单了
所以你下面的这些问题不成立了
http://www.woshipm.com/pd/2976600.html
http://www.woshipm.com/pd/3298531.html
你可以看一下我的这两篇文章
待付款就拆单了,不然后面任意选择性支付,和未支付已支付的商品处理贼烦.一个总单对应子单,支付后未支付的形成新的一个总单
对头,从后端的角度来说处理起来确实很烦
是否能下架商品第三种方案:
可以下架,后续用户下单时提示商品已下架无法下单,向商家端提供已生成订单且处于待支付状态的订单数量,让商家决定这部分订单是否可付款继续流转下去。
考虑场景:下架商品时,因为待支付订单自动取消时长为30分钟,这30分钟内已经生成大量待支付订单,针对于这部分订单商家允许客户继续支付及后续流转。
对,相当于就是加了一个判断,支付时间大于下架时间的订单会标注出来,商家可以看见,如果要取消可以主动与用户联系
比如,用户3点59提交了订单,此时创建了订单,4点01支付成功,但4点00的时候商家下架了该商品,此笔订单就标注出来告知用户
作者写锁定库存这块,我觉得支付后锁定库存适合“抢购或者大型活动”时使用,让用户有紧迫感,不赶紧支付商品就有被抢光的风险;正常场景还是提交就锁定更友好;
是的,所以得看具体的业务场景;如果一个平台有两种锁库存的方式,不同的业务场景一定要提醒清楚用户,不然会引起纠纷的,毕竟涉及到钱的事
当年淘宝就因为这个事情好像争执了很久…
写的很棒!
谢谢,哈哈
用户侧拆单的原因是什么?
不是用户拆单,是用户下单的时候可能选择了多个商家的商品一起下单,平台会进行拆单。平台最终是要把订单推送给商家,由商家联系发货。结算的时候也是和商家单独进行结算的
是这样的,用户侧也拆单的主要原因我认为是,因为每个商家是单独发货,用户更关心订单的物流情况,拆单之后查看物流、联系卖家操作上会更方便一些,页面更清楚一些,其他的原因我暂时就没想到了
这样对用户来说体验好吗?
你的出发点是物流查询,物流查询可以以其他的方式展示啊,比如多个物流单号,点击以后进入物流详情页中(可能有更优的方案)
用户侧待付款订单拆成多笔支付,这个就很扯了….购物车里面不就是多笔订单合并付款,你现在还要整成多笔待支付,会不会有点反人类….
用户侧拆单是根据商家来拆的,不同商家是不同的订单,用户侧没有子订单的概念,也没有说待付款的需要拆成子订单去付款
第一,商家发物流的情况有很多,比如一个商品拆分成多个包裹,多个商品合并成一个包裹进行发货,碰到这种情况查看物流的时候就需要告知用户哪些商品在哪个包裹里,再加上多个商家,页面就会更乱;功能是可以做,只是看有没有必要
第二,既然商家端都拆了,用户端拆了之后,取消订单,确认收货等操作会更清晰一些,现在主流的设计都是确认收货/取消订单都是对订单而不是单个商品,如果多商家都放在一个订单里,比如有些商家一直没货需要很久才发货,另外一个商家的货早就收到了,确认收货就确认不了,商家也就结算不了,如果设计成能对单个商家收货,那这不更乱了吗,既然如此,商家看到的是子订单,用户看到的也是子订单
第三,在后端代码那里,一般都是提交订单之后,就创建订单,这个时候就需要拆分成子订单,写入数据库,而不是支付之后才拆,如果是支付之后再拆,那么待付款的订单就进入不了商家后台,也就不能进行订单改价等操作,说到这里,订单改价也是影响用户端拆分订单的因素之一,支付只能对订单支付,如果订单处于待付款的时候不拆,商家改价在后端逻辑来说就会很麻烦,功能是可以做,只是看有没有必要,简单的事就是直接一拆就好了,如果不拆反而会衍生很多问题,就需要做更多的事去解决
文章里面说的是:用户在客户端上看到的是多个子订单,如果没付款,是需要对子订单单独付款的
如果是没付款,单从用户端来说,的确不该拆单!
在后端代码那里,一般都是提交订单之后,就创建订单,这个时候就需要拆分成子订单,写入数据库,而不是支付之后才拆,如果是支付之后再拆,那么待付款的订单就进入不了商家后台,也就不能进行订单改价等操作,订单改价也是影响用户端拆分订单的因素之一,支付只能对订单支付,如果订单处于待付款的时候不拆,商家改价在后端逻辑来说就会很麻烦,功能是可以做,只是看有没有必要,简单的事就是直接一拆就好了,如果不拆反而会衍生很多问题,就需要做更多的事去解决
每个电商平台都不一样,有的会记录待支付的订单状态(PC),有的只会记录支付取消的状态,但是不管是记录待支付的状态还是支付取消的状态,对于后端来说,必然会拆单。但是对于APP用户来说,他还没完成支付,没必要拆单,而且你拆单就意味着, 之前的一笔订单,他再次支付,需要支付N次(N个店铺),这个体验相都不用想,肯定不好。
像淘宝京东都是待付款时就会拆单,可以自己试一下,他们为什么这么设计我不清楚,但是可以确定的是他们一定是踩过各种坑才这样做的,对于我们来说只能借鉴他们的做法,这样对公司肯定是最负责的,然后自己只能尽量去分析他们为什么这么做,为什么不这么做,分清楚哪些是必须这样做,哪些是这样做更好,像用户端拆单这块,我认为是这样做更好,暂时没找到必须这样做的理由
京东淘宝在没支付完成之前,用户看到的永远只有一个订单,不会分开显示的。
这么说吧,拆单是必然的,但是在没支付完成前,用户是感知不到的。我觉得我们想法差不多,但是没沟通清楚!
我刚刚试了一下,待付款的订单,淘宝会拆,京东不会拆,但是淘宝支持订单改价,京东我查了一下好像不支持;淘宝订单的自动取消是24小时,京东是30分钟,我猜想可能京东是支付后才后台进行拆单,这时子订单才会进入商家后台,可能业务场景不一样吧,京东希望用户尽快付款,而淘宝会留时间给用户与商家协商
说到支付N次这个问题,哪种方案更好还是要看具体业务场景,就像我刚刚说的,比如要改价之类的操作,肯定下单就拆的方案会好很多,当然在支付页面就退出的发生频次肯定比改价的场景多得多,但是我认为用户并不会因为这一小点就放弃这个平台,因为这是用户自己的选择
当然,我的想法肯定有一定的局限性,这些都是我们的推测,我也只能尽量去推测他们为什么这么做的意图 😉
我认为这个和改价的关系不是很大,更重要的是淘宝和京东的经营模式不太一样,
不用去推测他们的意图,你要考虑你准备给用户什么样的体验
用户一次能干完的事情,你非要用户干好多遍,而且是重复的,是不是make trouble了?
设计不能完美解决用户的诉求,但是也别制作麻烦啊
第一,推测大厂的产品意图再来设计,对公司来说是最负责的,因为大厂肯定踩过无数的坑才会最终成型,比如我们平台的经营模式更接近于淘宝,而在逻辑设计上更偏向于京东,如果不去推测他们意图,只知其然而不知其所以然,如果在流程上出问题了,这个责任就大了,虽然自己的推测不一定是对的,但是至少自己思考过了,权衡过了,而不是盲目的去借鉴
第二,像待付款订单拆单,看起来只关乎用户体验,背后说大点和平台的定位有关,不然为什么淘宝就拆了,难道淘宝的产品经理不会考虑用户体验吗?至少在我看来,我会同时关注数据的完整性,后端的开发逻辑,数据库的结构设计,而不是仅仅考虑用户的操作体验;比如提交订单后订单其实是拆了,这个时候如果用户端不拆实际上就是套了一层壳子,看起来是一层壳子,涉及到金钱的功能,背后的逻辑都很复杂,而且容易出错,像我们之前开发时间相当紧,做个权衡,现阶段没必要,用户也不会因为没有这层壳子而放弃我们平台
😳