CN112950184A - 多终端协同批量下单的处理方法和服务平台 - Google Patents

Abstract

本发明提供一种多终端协同批量下单的处理方法和服务平台，所述方法包括：开启一个协同批订单，并配置所述协同批订单的锁定时长；在所述锁定时长的时间范围内，接收参与所述协同批订单的各用户所提交的子订单，并基于各所述子订单修改更新所述协同批订单；在所述锁定时长达到对应的时间时长时，锁定并确认所述协同批订单；基于确认的所述协同批订单和各用户对应的各子订单为各用户生成对应的支付链接，并将各所述支付链接分别发送至各用户；检测是否接收到与各所述支付链接对应的各支付完成信息，若是，则确认所述协同批订单支付完成，若否，则确认所述协同批订单支付失败。本发明可以实现多个用户同时参与同一个订单的购买和支付。

Description

多终端协同批量下单的处理方法和服务平台

技术领域

本发明涉及金融技术领域，特别是涉及金融支付技术领域，具体为一种多终端协同批量下单的处理方法和服务平台。

背景技术

当前，群组团购消费模式逐步兴起，比如社区团购、家庭团购、同事团购物等，这类需求现在实现技术往往是采用代购模式，即由某人代劳帮助大家统一收费下单购买和分发，容易出现不信任、质量纠纷、维权困难等问题。

针对这类群组场景化消费模式，核心基本需求就是多用户同时下单，批量消费购物。对用户终端来说，批量购物享受更多优惠，货物渠道来源有保障，信任用户推荐产品，方便维权；对商家或电商平台来说，批量订单销售，渠道推广成本低，客户群体稳定可靠，回头率高，规模化订单管理总体成本比较低等。

支持多终端的协同批量下单，从前端来说有多种批量触发模式。包括第一种场景：群组某用户主动发起订单，系统智能推荐参与用户，或者用户基于群组信息共享主动参与；第二种场景：电商平台主动向固定的群组用户群推送产品的下单链接，有兴趣的用户可以主动参与下单等。

不论哪种模式，电商后端系统都需要支持多终端协同批量下单。现有电商平台的一个用户一个订单模式，无法支持多用户的批量下单业务需求。

发明内容

鉴于以上所述现有技术的缺点，本发明的目的在于提供一种多终端协同批量下单的处理方法和服务平台，用于解决现有技术中无法实现多个用户同时参与同一个订单的购买和支付的技术问题。

为实现上述目的及其他相关目的，本发明提供一种多终端协同批量下单的处理方法，包括：开启一个协同批订单，并配置所述协同批订单的锁定时长；在所述锁定时长的时间范围内，接收参与所述协同批订单的各用户所提交的子订单，并基于各所述子订单修改更新所述协同批订单；在所述锁定时长达到对应的时间时长时，锁定并确认所述协同批订单；基于确认的所述协同批订单和各用户对应的各子订单为各用户生成对应的支付链接，并将各所述支付链接分别发送至各用户；检测是否接收到与各所述支付链接对应的各支付完成信息，若是，则确认所述协同批订单支付完成，若否，则确认所述协同批订单支付失败。

于本发明的一实施例中，开启一个协同批订单的方式包括：于用户终端内基于用户请求开启所述协同批订单；或者于商户终端内基于预设条件和/或商户请求开启所述协同批订单。

于本发明的一实施例中，所述接收参与所述协同批订单的各用户所提交的子订单包括：各用户基于接收到的所述协同批订单的分享信息或展示信息进入所述协同批订单；接收用户基于所述协同批订单输入的订购信息；接收用户基于所述输入的订购信息提交的各用户的子订单。

于本发明的一实施例中，所述多终端协同批量下单的处理方法还包括：在所述锁定时长的时间范围内，接收锁定时长更改请求，并在接收到参与所述协同批订单的所有用户反馈的同意更改指令时，基于所述锁定时长更改请求更改对应的锁定时长。

于本发明的一实施例中，所述确认所述协同批订单包括：将锁定的所述协同批订单分别发送至参与所述协同批订单的各用户；

在预设确认时长内接收到各用户反馈的确认指令或在所述预设确认时长达到对应的时间时长时未收到各用户反馈的确认指令时，确认所述协同批订单；在预设确认时长内接收到一个或多个用户反馈的子订单修改指令时，基于所述子订单修改指令修改更新所述协同批订单，并重复上述过程，直至参与所述协同批订单的各用户确认所述协同批订单。

于本发明的一实施例中，所述多终端协同批量下单的处理方法还包括：在开启一个协同批订单时，为参与所述协同批订单的各用户建立协同批订单群组；在检测到参与所述协同批订单的用户提交子订单时，将对应用户加入所述协同批订单群组；在检测到参与所述协同批订单的用户退出子订单时，将对应用户移出所述协同批订单群组。

于本发明的一实施例中，所述多终端协同批量下单的处理方法还包括：实时获取参与所述协同批订单的用户数量和/或订购数量；基于参与所述协同批订单的用户数量和/或订购数量修改更新所述协同批订单中对应的订购价格。

于本发明的一实施例中，在所述确认所述协同批订单支付失败时，还包括：撤回所述协同批订单，并将已支付完成的各用户的对应支付款返还至对应的支付账户。

于本发明的一实施例中，所述多终端协同批量下单的处理方法还包括：显示所述协同批订单的当前支付状态；

在确认所述协同批订单支付完成后，记录所述协同批订单的消费信息和参与所述协同批订单的各用户的消费信息。

为实现上述目的，本发明还提供一种服务平台，包括存储器，用于存储计算机程序；处理器，用于运行所述计算机程序以实现如上所述的多终端协同批量下单的处理方法。

如上所述，本发明的一种多终端协同批量下单的处理方法和服务平台，具有以下有益效果：

1、本发明可以实现多个用户同时参与同一个订单的购买和支付，在现有电商体系的基础上，对消费者和电商平台都带来新的应用价值，消费者批量购物可能获得更大的优惠幅度，心理信任度高买的放心，方便维权，商家推广渠道成本低，客户群稳定，规模化订单管理总体成本低等。

2、本发明可以为类似群组、家庭、社团、工会等组织化场景，提供基于优化资源配置的购买消费支持，更好的满足社会化消费监管、消费者权益保护、消费结构分析和治理。

3、本发明能基于现有电商平台系统拓展，能较好的与现有电商平台的订单系统、支付接口功能对接，用户体验能实现平滑转移，因此，在带来新型技术和适用功能的同时，建设、运营、推广成本较低。

附图说明

图1显示为本发明的多终端协同批量下单的处理方法的流程示意图；

图2显示为本发明的服务平台实现多终端协同批量下单的处理方法的框架原理示意图。

图3显示为本发明的服务平台于一实施例中的原理结构示意图。

具体实施方式

以下通过特定的具体实例说明本发明的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。

需要说明的是，以下实施例中所提供的图示仅以示意方式说明本发明的基本构想，故图式中仅显示与本发明中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。

本实施例提供的多终端协同批量下单的处理方法和服务平台，用于解决现有技术中无法实现多个用户同时参与同一个订单的购买和支付的技术问题。

以下将详细阐述本实施例的多终端协同批量下单的处理方法和服务平台的原理及实施方式，使本领域技术人员不需要创造性劳动即可理解本实施例的多终端协同批量下单的处理方法和服务平台。

本实施例提供一种多终端协同批量下单的处理方法，应用于服务平台，所述服务平台可以是电商平台、支付平台，也可以是与电商平台和支付平台对接的第三方平台。

本实施例的多终端协同批量下单的处理方法通过所述服务平台提供的APP、微信、支付宝等综合平台软件中的网页或小程序向用户终端展示多个图形用户界面(GUI)，通过所述图形用户界面展示多终端协同批量下单的处理方法所形成的功能，该图形用户界面可称为用户服务图形界面。

于一实施例中，所述用户终端可以例如固定终端，例如服务器、台式机等；也可以是移动终端，例如笔记型电脑、智能手机或平板电脑等。

于一实施例中，该用户终端可以是在离线或在线状态下实现多终端协同批量下单的处理方法的展示。

可选的，所述用户终端和该服务平台之间可以是C/S架构实现数据通信，即用户终端安装用户端软件，服务平台安装服务端软件，用户终端的用户端软件可以生成图形用户界面(GUI)，服务端软件向用户端软件提供实现多终端协同批量下单的处理方法的数据，以供用户终端处理并展示于该图形用户界面。

较优的，所述用户终端和该服务平台之间可以是B/S架构实现数据通信，即用户终端具备浏览器(Browser)以用于显示该用户服务图形界面；服务平台安装服务端软件，服务平台既向用户终端提供展示该用户服务图形界面的数据，又向用户端软件提供展示于该图形用户界面的实现多终端协同批量下单的处理方法的数据。

基于B/S架构，可以大大降低对用户的用户终端的硬软件要求，用户的用户终端不需要安装用户端软件，仅需具备网页浏览器即可，从而能大大提升用户的用户体验。

需说明的是，对应不同类型的用户终端，其所展示的图形用户界面亦可不同。

具体来讲，在一些实施例中，对于该用户终端为PC终端而言，其可通过装载的浏览器(包括但不限于IE、谷歌、360、QQ、搜狗、百度、傲游、UC、火狐、猎豹、2345、欧朋等等浏览器)通过浏览网页，并以网页为接口，通过访问预定的URL来访问服务平台提供的特定网页，在该特定网页中显示所述用户服务图形界面，通过该图形用户界面向用户提供实现多终端协同批量下单的处理方法的数据。

而在又一些实施例中，对于该用户终端为移动终端(例如智能手机、平板电脑)而言，其可通过例如微信、支付宝等综合平台软件中的网页或小程序来访问用于实现多终端协同批量下单的处理方法的图形用户界面。

例如，展示在微信公众号中提供进入用于实现多终端协同批量下单的处理方法的图形用户界面的接口，已注册的用户可以通过扫描二维码或搜索微信公众号的方式添加微信公众号，进而操作(例如点击)微信公众号中的预设菜单从而进入用于实现多终端协同批量下单的处理方法的图形用户界面，相比于PC端的界面，移动终端的界面会更加简洁。

如图1所示，于本实施例中，所述多终端协同批量下单的处理方法包括以下步骤：

步骤S100，开启一个协同批订单，并配置所述协同批订单的锁定时长。

其中，于本实施例中，所述协同批订单是指多个用户同时参与购买的同一个订单，一个订单支持多用户批量协同购买，是具有协同的一个订单，而不是有协同或没有协同的多个订单。即所述协同批订单为一个订单，多个用户通过该订单分别进行购买。

多个用户同时参与购买的同一个协同批订单，相对单个用户独立下单来说，消费者和商家都具有相应的优势，比如消费者批量购物具有更大的优惠幅度，心理信任度高买的放心，方便维权；商家推广渠道成本低，客户群稳定，规模化订单管理总体成本低等。

于本实施例中，开启一个协同批订单的方式包括：于用户终端内基于用户请求开启所述协同批订单；或者于商户终端内基于预设条件和/或商户请求开启所述协同批订单。

例如，可以由某个用户预先下单时主动开启一个协同批订单，并设定锁定时长。或者电商平台自动开启一个协同批订单，并设定锁定时长。

例如，电商平台根据商品售卖策略和数据分析状态，适时间隔的自动创建开启新的协同批订单，或者电商平台以人工方式主动开启一个协同批订单，并设定锁定时长。

其中，所述锁定时长可以自定义设置，也可以采用预先配置的默认锁定时长。

也就是说，订单发起人(包括用户或者电商平台)可以主动设置该协同批订单的锁定时长，也可以采用默认的锁定时长。

其中，所述锁定时长并不限定，例如所述锁定时长为10分钟或24小时。

于本实施例中，所述多终端协同批量下单的处理方法还包括：

在所述锁定时长的时间范围内，接收锁定时长更改请求，并在接收到参与所述协同批订单的所有用户反馈的同意更改指令时，基于所述锁定时长更改请求更改对应的锁定时长。

例如，商家愿意加大优惠力度，吸引更多的用户参与，延长锁定时间。此时，协同批量订单发起人(包括用户或者电商平台)可以改变该订单的锁定时间，但需要预先获取所有已经参与该订单用户的同意。

步骤S200，在所述锁定时长的时间范围内，接收参与所述协同批订单的各用户所提交的子订单，并基于各所述子订单修改更新所述协同批订单。

于本实施例中，所述接收参与所述协同批订单的各用户所提交的子订单包括：

1)各用户基于接收到的所述协同批订单的分享信息或展示信息进入所述协同批订单；

2)接收用户基于所述协同批订单输入的订购信息；

3)接收用户基于所述输入的订购信息提交的各用户的子订单。

其中，电商平台开启的协同批订单于电商平台内直接展示未锁定的协同批订单。用户在电商平台浏览商品时即可看到所述未锁定的协同批订单，然后主动进入所述协同批订单。

或者用户通过协同消费群，社交好友转发，短消息，网络广告等网络推广方式所分享的分享信息获取所述协同批订单的进入链接，然后进入所述协同批订单。

所以参与一个所述协同批订单的各用户可能来自同一个群组，也可能来自不同的群组，或者属于网络散客。

其中，本实施例中，所述群组是指即提供专业的协同消费购物的群组，该群组直接对接电商平台端和支付端，可以是由电商平台、支付平台开发和提供的APP或者小程序，也可以由第三方独立开发，并与电商平台和支付平台接口对接，由用户下载到智能手机或者电脑使用，并与个人电子钱包有效集成和对接。

用户通过网络平台或社交媒体用户的(信息链接)推荐等，直接链接电商平台。用户在电商平台浏览商品时，针对某个商品，可以直接开启新的所述协同批订单或者参与该商品已有的未锁定的所述协同批订单。

进入所述协同批订单的用户输入购买的件数、物流信息等订购信息，然后生成子订单提交至电商平台，电商平台接收用户基于所述输入的订购信息提交的各用户的子订单，然后基于各所述子订单修改更新所述协同批订单。

例如，用户A可以主动开启一个协同批订单，设定锁定时长，该用户A输入其子订单的购买信息：购物数量，账户，物流信息等，自动生成该用户A的子订单。用户A可以将该协同批订单的链接信息，共享到协同消费群，或者转发给社交好友等进行分享。用户B和用户C通过协同消费群，社交好友转发，短消息，网络广告等各种渠道，链接电商平台，参与协同批订单，同样输入各自的子订单的购买信息提交，电商平台然后基于各所述子订单修改更新所述协同批订单，自动更新协同批订单的下单用户列表。

此外，于本实施例中，所述多终端协同批量下单的处理方法还包括：

1)实时获取参与所述协同批订单的用户数量和/或订购数量；

2)基于参与所述协同批订单的用户数量和/或订购数量修改更新所述协同批订单中对应的订购价格。

其中，可以预先配置多人购买的优惠策略，配置用户数量和/或订购数量与购买价格的对应关系。

例如，可以根据所述协同批订单的订购数量，自动调整订购商品的单价。

步骤S300，在所述锁定时长达到对应的时间时长时，锁定并确认所述协同批订单。

于本实施例中，在所述锁定时长达到对应的时间时长时，锁定所述协同批订单。所述协同批订单锁定后，在支付之前不可以再修改变更该所述协同批订单的有关购买的关键信息，直接确认所述协同批订单。

此外，于本实施例中，在所述锁定时长未达到对应的时间时长时，也可以基于预设锁定条件锁定所述协同批订单。所述预设锁定条件包括但不限于订购数量达到订购数量阈值，参与协同批订单的用户数量达到参与用户数量阈值，接收到外部输入锁定指令(人工手动控制所述协同批订单锁定)等。

此外，于另一实施例中，所述协同批订单锁定后，在支付之前可以与用户进行确认，提供给用户修改子订单的机会。即所述协同批订单锁定后，向各参与用户确认所述协同批订单。

具体地，所述确认所述协同批订单包括：

1)将锁定的所述协同批订单分别发送至参与所述协同批订单的各用户。

具体地，到所述锁定时长后，锁定所述协同批订单，并将当前锁定的所述协同批订单的订单信息(购买用户列表(去除隐私信息)、总数量、总价格、各用户购买数量、单价)等发送给每个参与该所述协同批订单的用户。例如，发给(与电商平台对接的)协同购物群组，或者对应用户手机短信；或者用户(再次)登录电商平台时主动推送信息。

2)在预设确认时长内接收到各用户反馈的确认指令或在所述预设确认时长达到对应的时间时长时未收到各用户反馈的确认指令时，确认所述协同批订单。

也就是说，在预设确认时长内接收到各用户反馈的确认指令，即所有用户均对所述协同批订单进行了确认，则确认所述协同批订单。或者在预设确认时长内，所有用户或一个或多个用户没有及时反馈指令时，则默认不反馈指令的用户确认所述协同批订单，以使得商家在电商平台及时确认该协同批订单的有效性。

3)在预设确认时长内接收到一个或多个用户反馈的子订单修改指令时，基于所述子订单修改指令修改更新所述协同批订单，并重复上述过程，直至参与所述协同批订单的各用户确认所述协同批订单。

即若有用户及时反馈有异议，商家可根据用户提供的订单修改指令(更新信息)，适当变更其对应的子订单信息，如变更物品的颜色种类，物流信息等。并基于该所述子订单对应修改更新所述协同批订单。

将修改更新后的所述协同批订单再次分别发送至参与所述协同批订单的各用户。由于子订单更改后，可能存在订购数量的变化，而订购数量的变化有可能导致订购价格的变化，因而，在有子订单修改后，检测订购价格的变化，可以基于订购价格的变化确定是否需要用于对修改更新后的所述协同批订单再次确认：

若订购价格无变化，则将修改更新后的所述协同批订单再次分别发送至参与所述协同批订单的各用户，显示给各用户即可，无需各用户进行确认。

若订购价格有变化，则将修改更新后的所述协同批订单再次分别发送至参与所述协同批订单的各用户并重复上述1)和2)中确认所述协同批订单的过程。再次不再赘述。

步骤S400，基于确认的所述协同批订单和各用户对应的各子订单为各用户生成对应的支付链接，并将各所述支付链接分别发送至各用户。

例如，商家确认所述协同批订单时，依据各用户提供的子订单的信息，自动针对每个用户生成对应的子订单的支付链接，然后发给/反馈给对应的用户，由各用户采用异步模式支付属于各自部分的子订单。

其中，将各所述支付链接分别发送至各用户的发送方式包括但不限于：发送给(与电商平台对接的)协同购物群组的对应用户支付链接，或者短信发送支付链接到用户手机，或者用户(再次)登录到连接电商平台时，主动推送该支付链接。

对于一个所述协同批订单，每个用户的支付数额或者比例，可以用其自身购买的件数、总订单设置的支付比例数等来表示，基于其对应的子订单进行支付。

于本实施例中，各用户可以采用但不限于代付、转移支付等支付方式进行对应支付链接的子订单的支付。

步骤S500，检测是否接收到与各所述支付链接对应的各支付完成信息，若是，则执行步骤S600：确认所述协同批订单支付完成，若否，则执行步骤S700：确认所述协同批订单支付失败。

由于所述协同批订单和各子订单是属于一个关联整体，单个用户的子订单的支付成功并不意味该用户已购买成功，因为涉及到所述协同批订单的折扣等优惠折算问题。

在接收到与各所述支付链接对应的各支付完成信息时，也即在所有子订单支付成功时，所述协同批订单才被确认支付成功。预设时间内，在存在未支付的子订单时，所述协同批订单才被确认支付失败。

于本实施例中，在确认所述协同批订单支付失败时，还包括：撤回所述协同批订单，并将已支付完成的各用户的对应支付款返还至对应的支付账户。

也就是说，若有用户支付不成功，或者退出购买，导致所述协同批订单支付失败时，也可以全部撤单，需要撤回所述协同批订单，即原路退款给已支付的用户。

例如，如在一定时间周期内，所有用户成功支付，则该协同批订单成功；否则，在一定周期内，其他参与用户可以为未成功支付的子订单代付。超过一定时间周期存在未支付子订单，且整个协同批订单撤回，并原路退还已经支付成功的各用户。

此外，若所述协同批订单支付失败但所述协同批订单仍未达到所述锁定时长对应的时间时长时(预设锁定条件提前锁定了)，如果有用户支付不成功，或者退出购买，可以令所述协同批订单返回至未锁定状态，继续等待其他用户参与，即重复执行上述步骤S200至步骤S700，其他参与所述协同批订单的用户只是接收或实时查看协同订单状态，避免重复下单。

所以本实施例的多终端协同批量下单的处理方法中，多个用户可以同时实时的、异步的协同支付同一个订单。当某个或某些用户最终未成功支付时，订单需要整体撤销退款，或者重新编辑修改订单。

于本实施例中，所述多终端协同批量下单的处理方法还包括：

1)显示所述协同批订单的当前支付状态；

2)在确认所述协同批订单支付完成后，记录所述协同批订单的消费信息和参与所述协同批订单的各用户的消费信息。

每个参与协同批订单的用户可以实时查看参与所述协同批订单的所有用户的当前支付状态。在确认所述协同批订单支付完成后，记录所述协同批订单的消费行为和每个参与用户的消费行为，包括但不限于：时间、商品、数量、金额等。

本实施例中，还包括协同批订单管理，所述协同批订单管理按照协同批订单(总订单)和各子订单的分层模式进行管理，包括子订单的订单信息、支付信息、物流信息、售后服务信息等。表1是电商平台的一个所述协同批订单示例。

表1

订单号-子订单	最后交易时间	成员	数量	单价	总价	地址	电话	其他
									0001	8-28 15:30:00	A(发起)	4	100	400			已完成
0001-1	8-28 15:29:00	A	1	100	100	A座1门	139	已付
									0001-2	8-28 15:28:30	B	2	100	200	B座2门	138	已付
0001-3	8-28 15:28:00	C	1	100	100	C座3门	137	已付

特别地，于本实施例中，所述多终端协同批量下单的处理方法还包括：

1)在开启一个协同批订单时，为参与所述协同批订单的各用户建立协同批订单群组；

2)在检测到参与所述协同批订单的用户提交子订单时，将对应用户加入所述协同批订单群组；在检测到参与所述协同批订单的用户退出子订单时，将对应用户移出所述协同批订单群组。

也就是说，于本实施例中，以所述协同批订单为中心建立对应的临时即时消息订单群组(即所述协同批订单群组)，参与该协同批订单的用户，就自动参与到该临时即时消息订单群组；退出该协同批订单，即退出该临时即时消息订单群组。所述协同批订单完成后，该临时即时消息订单群组(即所述协同批订单群组)不关闭，通过该临时即时消息订单群组(即所述协同批订单群组)，实现用户之间、用户与电商平台之间的信息交互，方便后续针对所述协同批订单的售后服务和维权。

此外，在批量协同订单支付完成后，还可以通过即时消息订单群组(即所述协同批订单群组)与电商平台商家联系，完成售后服务需求，包括联系子订单的退/换等。用户也可以直接分别针对批量协同订单和各子订单评价购物体验。

所以，相比于现有以个人下单购物的电商平台订单周期仅包含选物下单(购物车)、订单支付、订单售后，本实施例的协同批订单的基本周期环节包括：订单发起、参与订单、订单锁定、协同支付、订单售后，可以基于现有的电商平台系统，通过拓展功能，为用户提供批订单消费的特殊功能支持。

通过本实施例的多终端协同批量下单的处理方法，如图2所示，电商平台可以实现如下功能：

1)商品管理：商品管理在线展示当前商品的已经开启的但未锁定的协同批订单，供用户选择参与。

2)协同批订单管理：由某个用户开启或者电商平台系统自动开启协同批订单，由多个用户的子订单构成。每个用户决定参加该协同批订单时，订单系统自动为其生成子订单，由其输入指定子订单的购物数量，支付账户，物流信息等。在协同批订单锁定前，用户可以变更其子订单信息，或者不想再参与该协同批订单时删除其子订单，并自动退出协同批订单群组。协同批订单随着用户数的加入，根据电商平台制定的价格策略等，自动统计计算和调整单件价格和总订单价格。

3)批订单群管理：依附于协同批订单生命周期、由电商平台自动创立协同批订单群组，方便参与协同批订单的各用户之间，以及用户与电商平台之间交互。

4)支付管理：可以对子订单支付进行管理：每个用户可以选择自己的子订单的支付通道和账户。

5)订单管理：采用协同批订单-子订单两层总分记账模式和售后服务模式。

所以本实施例的多终端协同批量下单的处理方法可以基于现有的电商平台系统，通过拓展功能，为用户提供批订单消费的特殊功能支持，如图2所示，本实施例的多终端协同批量下单的处理方法在电商平台的应用流程如下：

1)用户在电商平台浏览某件商品。电商平台直接展示该商品当前未锁定的协同批订单。电商平台根据商品售卖策略和数据分析状态，适时间隔的自动创建开启新的协同批订单。用户也可以主动开启一个新的协同批订单。

2)假设用户A主动开启一个协同批订单，设定锁定时长；并自动生成该用户的子订单，该用户输入其子订单的购买信息：购物数量，账户，物流信息等。

3)用户A可以将该协同批订单的链接信息，共享到协同消费群，或者转发给社交好友。用户B，C通过各种渠道，链接电商平台，参与该协同批订单，同样输入其自身的子订单的购买信息，自动更新协同批订单的下单用户列表。

4)到预定锁定时长后，自动锁定该协同批订单，并将当前锁定的协同批订单的最终信息(购买用户列表(去除隐私信息)、总数量、总价格、各用户购买数量、单价)等发送给每个参与的用户。例如发给(与电商平台对接的)协同购物群组，或者对应用户手机短信；或者用户(再次)登录电商平台时主动推送信息。

5)所有用户在协同批订单群组里没有及时反馈异议时，商家在电商平台及时确认该协同批订单的有效性。如用户及时反馈有异议，且商家可根据用户提供的更新信息，适当变更其对应的子订单信息。如变更物品的颜色种类，物流信息等。

6)商家确认协同批订单时，依据提供的子订单信息，电商平台的系统自动针对每个用户生成对应的子订单的支付链接，发给/反馈给对应的用户。例如，发送给(与电商平台对接的)协同购物群组的对应用户支付链接，或者短信发送支付链接到用户手机，或者用户(再次)登录到连接电商平台时，主动推送该支付链接。

7)用户支付。各用户采用异步模式支付属于各自部分的子订单。每个用户可以实时查看协同批订单的所有用户的当前支付状态。

8)如在一定时间周期内，所有用户成功支付，则该协同批订单成功；否则，在一定周期内，其他参与用户可以为未成功支付的子订单代付。超过一定时间周期存在未支付子订单，且整个协同批订单撤回，并原路退还已经支付成功的用户。

9)记录协同批订单的消费行为和每个参与用户的消费行为(包括：时间、商品、数量、金额)。

此外，如图3所示，本实施例还提供一种服务平台100，包括存储器102，用于存储计算机程序；处理器101，用于运行所述计算机程序以实现如上所述的多终端协同批量下单的处理方法。其中，所述服务平台100可以是电商平台、支付平台，也可以是与电商平台和支付平台对接的第三方平台；本实施例的多终端协同批量下单的处理方法通过所述服务平台100提供的APP、微信、支付宝等综合平台软件中的网页或小程序进行展示。

存储器102通过装置总线与处理器101连接并完成相互间的通信，存储器102用于存储计算机程序，处理器101用于运行计算机程序，以使所述服务平台100执行所述的多终端协同批量下单的处理方法。上述已经对所述多终端协同批量下单的处理方法进行了说明，在此不再赘述。

另需说明的是，上述提到的装置总线可以是外设部件互连标准(PeripheralComponent Interconnect，简称PCI)总线或扩展工业标准结构(Extended IndustryStandard Architecture，简称EISA)总线等。该装置总线可以分为地址总线、数据总线、控制总线等。为便于表示，图3中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。通信接口用于实现数据库访问装置与其他设备(例如客户端、读写库和只读库)之间的通信。存储器102可能包含随机存取存储器(Random Access Memory，简称RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

上述的处理器101可以是通用处理器，包括中央处理器(Central ProcessingUnit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(Digital Signal Processing，简称DSP)、专用集成电路(Application SpecificIntegrated Circuit，简称ASIC)、现场可编程门阵列(Field－Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

所以本实施例提供的服务平台100支持多终端用户协同批量下单的电商模式，包括批量下单、协同支付、批量订单管理等新型功能模式，为多个用户提供实时异步、协同、批量、又相对独立服务的订单模式。

综上所述，本发明可以实现多个用户同时参与同一个订单的购买和支付，在现有电商体系的基础上，对消费者和电商平台都带来新的应用价值，消费者批量购物可能获得更大的优惠幅度，心理信任度高买的放心，方便维权；商家推广渠道成本低，客户群稳定，规模化订单管理总体成本低等；本发明可以为类似群组、家庭、社团、工会等组织化场景，提供基于优化资源配置的购买消费支持，更好的满足社会化消费监管、消费者权益保护、消费结构分析和治理；本发明能基于现有电商平台系统拓展，能较好的与现有电商平台的订单系统、支付接口功能对接，用户体验能实现平滑转移，因此，在带来新型技术和适用功能的同时，建设、运营、推广成本较低。所以，本发明有效克服了现有技术中的种种缺点而具高度产业利用价值。

上述实施例仅例示性说明本发明的原理及其功效，而非用于限制本发明。任何熟悉此技术的人士皆可在不违背本发明的精神及范畴下，对上述实施例进行修饰或改变。因此，举凡所属技术领域中具有通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本发明的权利要求所涵盖。

Claims (10)

1.一种多终端协同批量下单的处理方法，其特征在于：包括：

开启一个协同批订单，并配置所述协同批订单的锁定时长；

在所述锁定时长的时间范围内，接收参与所述协同批订单的各用户所提交的子订单，并基于各所述子订单修改更新所述协同批订单；

在所述锁定时长达到对应的时间时长时，锁定并确认所述协同批订单；

基于确认的所述协同批订单和各用户对应的各子订单为各用户生成对应的支付链接，并将各所述支付链接分别发送至各用户；

检测是否接收到与各所述支付链接对应的各支付完成信息，若是，则确认所述协同批订单支付完成，若否，则确认所述协同批订单支付失败。

2.根据权利要求1所述的多终端协同批量下单的处理方法，其特征在于：开启一个协同批订单的方式包括：

于用户终端内基于用户请求开启所述协同批订单；或者于商户终端内基于预设条件和/或商户请求开启所述协同批订单。

3.根据权利要求1所述的多终端协同批量下单的处理方法，其特征在于：所述接收参与所述协同批订单的各用户所提交的子订单包括：

各用户基于接收到的所述协同批订单的分享信息或展示信息进入所述协同批订单；

接收用户基于所述协同批订单输入的订购信息；

接收用户基于所述输入的订购信息提交的各用户的子订单。

4.根据权利要求1所述的多终端协同批量下单的处理方法，其特征在于：所述多终端协同批量下单的处理方法还包括：

在所述锁定时长的时间范围内，接收锁定时长更改请求，并在接收到参与所述协同批订单的所有用户反馈的同意更改指令时，基于所述锁定时长更改请求更改对应的锁定时长。

5.根据权利要求1所述的多终端协同批量下单的处理方法，其特征在于：所述确认所述协同批订单包括：

将锁定的所述协同批订单分别发送至参与所述协同批订单的各用户；

在预设确认时长内接收到各用户反馈的确认指令或在所述预设确认时长达到对应的时间时长时未收到各用户反馈的确认指令时，确认所述协同批订单；

在预设确认时长内接收到一个或多个用户反馈的子订单修改指令时，基于所述子订单修改指令修改更新所述协同批订单，并重复上述过程，直至参与所述协同批订单的各用户确认所述协同批订单。

6.根据权利要求1至5任一权利要求所述的多终端协同批量下单的处理方法，其特征在于：所述多终端协同批量下单的处理方法还包括：

在开启一个协同批订单时，为参与所述协同批订单的各用户建立协同批订单群组；

在检测到参与所述协同批订单的用户提交子订单时，将对应用户加入所述协同批订单群组；

在检测到参与所述协同批订单的用户退出子订单时，将对应用户移出所述协同批订单群组。

7.根据权利要求1至5任一权利要求所述的多终端协同批量下单的处理方法，其特征在于：所述多终端协同批量下单的处理方法还包括：

实时获取参与所述协同批订单的用户数量和/或订购数量；

基于参与所述协同批订单的用户数量和/或订购数量修改更新所述协同批订单中对应的订购价格。

8.根据权利要求1所述的多终端协同批量下单的处理方法，其特征在于：在所述确认所述协同批订单支付失败时，还包括：

撤回所述协同批订单，并将已支付完成的各用户的对应支付款返还至对应的支付账户。

9.根据权利要求1所述的多终端协同批量下单的处理方法，其特征在于：所述多终端协同批量下单的处理方法还包括：

显示所述协同批订单的当前支付状态；

在确认所述协同批订单支付完成后，记录所述协同批订单的消费信息和参与所述协同批订单的各用户的消费信息。

10.一种服务平台，其特征在于：包括存储器，用于存储计算机程序；处理器，用于运行所述计算机程序以实现如权利要求1至9任一项所述的多终端协同批量下单的处理方法。

Images