关于扫码点餐多人实时共享订单的思考

问题前提

 多个消费者扫码后实时共享同一订单，此订单支持多人同时下单，共享中消费者都可对订单结算，且可随时加餐并支付

问题描述

 当多人分阶段对同一订单支付后，因某些原因触发退单申请时，因订单资金来源于不同消费者，商家对此退单应做何操作？退款应如何退回？

思考解决方式

• 如何触发退单

首先想到消费者只能对自己支付的订单部分提出退单申请，交由商家确认，但分析后发现会出现以下问题。

问题：若当前需要退订的餐品由不同的消费者支付，则需要多个消费者提出退单申请，如此设计，需要消费者在退订时记得自己下单的餐品，增加了消费者操作成本。

考虑另一种方式：消费者可对订单任意部分提出退单申请，交由商家确认。

• 退款金额计算

1. 考虑到订单本身可能会存在满减、优惠券、买一送n等优惠形式，而每种优惠可能会有一定的生效限制，比如支付金额达到某一额度时生效，若选择退单的餐品已经享有了相应优惠，那么若退单后现阶段支付金额已不足以支持使用可能已经使用的优惠了，那么应该如何计算退款金额？
2. 退单的餐品属于不同的支付批次，是否应该单独计算各自批次优惠额度以及退款金额？

• 退回路径

退款计算完成后应该如何将钱款退回？这个第一反应是将钱退还给退单申请人，但是明显不符合情理，应该退还给各自餐品的支付人。

那么当订单中两个消费者对一餐品分别点了一份，完成支付后，在退单申请时退了一份，那么应该退款到哪个消费者呐？

在记录订单中餐品时，对于同一餐品，不同消费者分别为若干份数支付，应该如何记录？是将订单中同一餐品作为一条记录主体，然后在该条记录中记录支付人、份数、金额，还是根据支付人员不同，分别记录在多条记录中。

到此，结论是需要分别记录每一支付批次的支付人、当前批次下的餐品列表、总金额、优惠以及优惠金额。

但是对于此业务设计的时候还是会感到非常混乱，总觉得哪里不合理，所以在这里记录下，希望各位大佬和道友能够提些建议。

在此谢过！

 

=================迟到的说明2020.05.29=================

有朋友私信问我最后怎么解决的，在此做下说明。

前述的同一个订单多人多次支付的业务逻辑过于复杂，超出了我能力处理界限，故放弃此场景，采取曲线救国方式变相实现。

规定同一个订单可以多人多次提交，但是只允许支付一次，支付完成后由商家确认结束订单。

若消费者想要添加新的餐品，则重新在当前桌号上创建新的订单。

另：关于多人实时共享订单，可以通过websocket的方式来实现。