CN112465490A - 一种服务处理方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请提供了一种服务处理方法、装置、电子设备及存储介质，其中，该服务处理方法包括：接收目标群组中的第一用户发送的服务请求，所述服务请求中包括第一服务信息和群组信息；根据所述服务请求中的第一服务信息以及响应所述服务请求的目标服务提供方的第二服务信息，生成服务中的第一服务订单；在检测到所述第一服务订单完成后，根据所述群组信息确定目标支付账号；根据所述目标支付账号和所述第一服务订单对应的支付金额，生成已完成的第二服务订单。本申请通过组建对应有目标支付账号的目标群体，实现同一目标群体内的各个用户使用公共的目标支付账号支付服务费用，简化群体内服务费用的支付过程，提高服务费用的清算效率。

Description

一种服务处理方法、装置、电子设备及存储介质

技术领域

本申请涉及线上服务技术领域，具体而言，涉及一种服务处理方法、装置、电子设备及存储介质。

背景技术

实际中，为了提高企业各部门员工的工作积极性，各部门会组织团体性外出聚会，比如，团建、聚餐、开会等；其中，在以部门为单位进行外出活动时，由部门的负责人支付部门内所有员工外出的出行费用。

通常，当部门内员工数量较少且能够同时出行时，即一辆出租车可容纳部门内所有员工时，在用车结束后由部门负责人支付打车费用，但是，当部门内员工数量较多，或者，部门内员工不能同时出行时，需要员工垫付车费，后续统一告知部门负责人车费金额，由部门负责人对员工垫付的车费进行费用清算。

采用该种车费的支付方式，在部门内员工数量较多，或者，部门内员工不能同时出行时，车费的费用清算过程较为繁琐，部门负责人难以管理车费的支付情况，导致整个清算过程的效率低。

发明内容

有鉴于此，本申请实施例的目的在于提供一种服务处理方法、装置、电子设备及存储介质，能够通过组建对应有目标支付账号的目标群体，实现同一目标群体内的各个用户使用公共的目标支付账号支付服务费用，简化群体内服务费用的支付过程，提高服务费用的清算效率。

第一方面，本申请实施例提供了一种服务处理方法，所述方法包括：

接收目标群组中的第一用户发送的服务请求，所述服务请求中包括第一服务信息和群组信息；

根据所述服务请求中的第一服务信息以及响应所述服务请求的目标服务提供方的第二服务信息，生成服务中的第一服务订单；

在检测到所述第一服务订单完成后，根据所述群组信息确定目标支付账号；

根据所述目标支付账号和所述第一服务订单对应的支付金额，生成已完成的第二服务订单。

在一种可能的实施方式中，通过如下方式创建所述目标群组：

接收第二用户发送的创建请求；其中，所述创建请求中包括群组信息；所述第二用户为所述第一用户中满足预设条件的用户；

若所述创建请求为合法请求，则根据所述群组信息创建所述目标群组；

接收所述第二用户发送的针对所述目标群组的支付账号配置请求，为所述目标群组配置目标支付账号。

在一种可能的实施方式中，所述方法还包括：

接收所述第二用户发送的针对所述目标支付账号的免密设置请求，将所述目标支付账号设置为免密支付账号。

在一种可能的实施方式中，所述方法还包括：

接收所述第二用户发送的针对所述目标支付账号的验证信息设置请求，将所述目标支付账号的验证信息设置为所述第二用户提供的目标验证信息。

在一种可能的实施方式中，所述方法还包括：

接收所述第二用户发送的针对所述目标支付账号的支付额度设置请求，将所述目标支付账号的支付额度设置为所述第二用户提供的目标支付额度。

在一种可能的实施方式中，所述根据所述目标支付账号和所述第一服务订单对应的支付金额，生成已完成的第二服务订单，包括：

从所述目标支付账号中转出所述第一服务订单对应的支付金额，生成第一支付完成信息；

根据所示第一支付完成信息和所述第一服务订单，生成所述第二服务订单。

在一种可能的实施方式中，所述根据所述目标支付账号和所述第一服务订单对应的支付金额，生成已完成的第二服务订单，还包括：

向所述第一用户对应的第一用户终端发送身份验证提示信息；

接收所述第一用户提供的验证信息，若所述验证信息为所述目标验证信息，则从所述目标支付账号中转出所述第一服务订单对应的支付金额，生成第二支付完成信息；

根据所示第二支付完成信息和所述第一服务订单，生成所述第二服务订单。

在一种可能的实施方式中，所述根据所述目标支付账号和所述第一服务订单对应的支付金额，生成已完成的第二服务订单，还包括：

获取所述目标支付账号的剩余支付额度，若所述剩余支付额度大于等于所述第一服务订单对应的支付金额，则从所述目标支付账号中转出所述支付金额，生成所述第二服务订单；

若所述剩余支付额度小于所述第一服务订单对应的支付金额，则从所述第一用户对应的候选支付账号中转出所述支付金额，生成所述第二服务订单。

在一种可能的实施方式中，所述接收所述第二用户发送的针对所述目标群组的支付账号配置请求，为所述目标群组配置目标支付账号，包括：

接收所述第二用户发送的针对所述目标群组的支付账号配置请求，获取所述第二用户对应的目标支付账号的信用信息；

若所述信用信息满足信用条件，则将所述目标群组的支付账号设置为所述目标支付账号。

在一种可能的实施方式中，所述方法还包括：

向第三用户发送邀请信息；所述邀请信息用于邀请所述第三用户加入所述目标群组；

在接收到所述第三用户返回的第一确认信息后，若所述目标群组符合添加条件，则将所述第三用户确定为所述第一用户。

在一种可能的实施方式中，所述方法还包括：

接收第三用户发送的加入所述目标群组的入群请求，并将所述入群请求发送给第二用户对应的第二用户终端；

在接收到所述第二用户返回的第二确认信息后，若所述目标群组符合添加条件，则将所述第三用户确定为所述第一用户。

在一种可能的实施方式中，所述方法还包括：

接收所述第二用户发送的针对所述目标群组的订单查看请求，查找所述目标群组对应的每个第二服务订单的订单信息，并将所述订单信息发送给第二用户对应的第二用户终端。

在一种可能的实施方式中，所述方法还包括：

接收所述第二用户发送的针对所述目标群组的电子发票生成请求，查找所述目标群组对应的每个第二服务订单的订单信息，并将所述订单信息发送给第二用户对应的第二用户终端；

接收所述第二用户发送的从所述第二服务订单中选取的目标服务订单，生成所述目标服务订单的电子发票，并将所述电子发票发送给所述第二用户对应的第二用户终端。

在一种可能的实施方式中，所述添加条件至少包括以下条件之一：存在包括所述第二用户的目标群组、所述目标群组对应有目标支付账号、所述目标群组内包括的用户的数量小于预设阈值。

第二方面，本申请实施例提供了一种服务处理装置，所述装置包括：

第一接收模块，用于接收目标群组中的第一用户发送的服务请求，所述服务请求中包括第一服务信息和群组信息；

第一生成模块，用于根据所述服务请求中的第一服务信息以及响应所述服务请求的目标服务提供方的第二服务信息，生成服务中的第一服务订单；

第一确定模块，用于在检测到所述第一服务订单完成后，根据所述群组信息确定目标支付账号；

第二生成模块，用于根据所述目标支付账号和所述第一服务订单对应的支付金额，生成已完成的第二服务订单。

第三方面，本申请实施例提供了一种电子设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述处理器执行所述机器可读指令，以执行第一方面任一项所述的服务处理方法的步骤。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行第一方面任一项所述的服务处理方法的步骤。

本申请实施例提供的一种服务处理方法、装置、电子设备及存储介质，其中，服务处理方法包括：接收目标群组中的第一用户发送的服务请求，所述服务请求中包括第一服务信息和群组信息；根据所述服务请求中的第一服务信息以及响应所述服务请求的目标服务提供方的第二服务信息，生成服务中的第一服务订单；在检测到所述第一服务订单完成后，根据所述群组信息确定目标支付账号；根据所述目标支付账号和所述第一服务订单对应的支付金额，生成已完成的第二服务订单。本申请实施例能够通过组建对应有目标支付账号的目标群体，实现同一目标群体内的各个用户使用公共的目标支付账号支付服务费用，简化群体内服务费用的支付过程，提高服务费用的清算效率。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请实施例提供的一种服务处理方法的流程图；

图2示出了本申请实施例提供的另一种服务处理方法的流程图；

图3示出了本申请实施例提供的另一种服务处理方法的流程图；

图4示出了本申请实施例提供的另一种服务处理方法的流程图；

图5示出了本申请实施例提供的另一种服务处理方法的流程图；

图6示出了本申请实施例提供的另一种服务处理方法的流程图；

图7示出了本申请实施例提供的另一种服务处理方法的流程图；

图8示出了本申请实施例提供的另一种服务处理方法的流程图；

图9示出了本申请实施例提供的另一种服务处理方法的流程图；

图10示出了本申请实施例提供的一种服务处理装置的结构示意图；

图11示出了本申请实施例提供的一种电子设备的示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

现有的企业出行方案，员工在外出用车时，需要满足企业设置的用车规则，比如，满足时间段，起点范围、终点范围等规则，才可以在用车完毕后使用员工所在企业的企业余额进行车费支付，无法满足企业内子部门小团体随时出发，统一支付，统一报销的灵活场景。

基于上述问题，本申请实施例提供了一种服务处理方法、装置、电子设备及存储介质，其中，服务处理方法包括：接收目标群组中的第一用户发送的服务请求，所述服务请求中包括第一服务信息和群组信息；根据所述服务请求中的第一服务信息以及响应所述服务请求的目标服务提供方的第二服务信息，生成服务中的第一服务订单；在检测到所述第一服务订单完成后，根据所述群组信息确定目标支付账号；根据所述目标支付账号和所述第一服务订单对应的支付金额，生成已完成的第二服务订单。本申请实施例能够通过组建对应有目标支付账号的目标群体，实现同一目标群体内的各个用户使用公共的目标支付账号支付服务费用，简化群体内服务费用的支付过程，提高服务费用的清算效率。

针对以上方案所存在的缺陷，均是发明人在经过实践并仔细研究后得出的结果，因此，上述问题的发现过程以及下文中本申请针对上述问题所提出的解决方案，都应该是发明人在本申请过程中对本申请做出的贡献。

下面将结合本申请中附图，对本申请中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

为了使得本领域技术人员能够使用本申请内容，结合特定应用场景“团体外出用车”，给出以下实施方式。对于本领域技术人员来说，在不脱离本申请的精神和范围的情况下，可以将这里定义的一般原理应用于其他实施例和应用场景。虽然本申请主要围绕团体外出用车进行描述，但是应该理解，这仅是一个示例性实施例。

需要说明的是，本申请实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。

本申请中的术语“服务请求端”、“乘客”、“请求方”、“服务请求方”和“客户”可互换使用，以指代可以请求或订购服务的个人、实体或工具。本申请中的术语“服务提供端”、“司机”、“提供方”、“服务提供方”和“供应商”可互换使用，以指代可以提供服务的个人、实体或工具。本申请中的术语“用户”可以指代请求服务、订购服务、提供服务的个人、实体或工具。例如，用户可以是乘客、驾驶员、操作员等，或其任意组合。

本申请中的术语“服务请求”和“订单”可互换使用，以指代由乘客、服务请求方、司机、服务提供方、或供应商等、或其任意组合发起的请求。接受该“服务请求”或“订单”的可以是乘客、服务请求方、司机、服务提供方、或供应商等、或其任意组合。服务请求可以是收费的或免费的。

参见图1所示，图1为本申请实施例提供的一种服务处理方法的流程图，该方法包括以下步骤：

S101、接收目标群组中的第一用户发送的服务请求，所述服务请求中包括第一服务信息和群组信息。

该步骤中，目标群组可以是在微信、QQ等通讯软件中组建的群组，可以是在淘宝、拼多多等购物软件中组建的群组，可以是在饿了么、美团等订餐软件中组建的群组，可以是在滴滴打车等交通软件中组建的群组，还可以是在微信的不同类型的小程序中组建的群组，这里，不对目标群组的载体的类别进行限定。

目标群组中包括多个用户，第一用户为目标群组中的任一用户，第一用户对应有第一用户终端，第一用户终端可以是智能手机、平板电脑、台式电脑、笔记本电脑等终端设备。具体的，第一用户终端响应第一用户的服务请求操作，生成与服务请求操作相匹配的服务请求，并将服务请求发送给本申请实施例的执行主体服务器，服务器接收第一用户终端发送的服务请求。

这里，服务请求用于请求不同类别的服务，服务的类别与目标群组的载体的类别相关联，比如，在滴滴打车小程序中组建的目标群组，该目标群组内的第一用户发送的服务请求用于请求打车服务，服务请求中携带有第一服务信息，第一服务信息为第一用户关于本次服务的服务要求，比如，服务请求为打车服务请求，对应的第一服务信息包括起始点、终点、服务类型(出租车、快车、拼车等)、乘车时间、乘客数量等信息。

群组信息为第一用户所在的目标群组的属性信息，群组信息至少包括以下信息之一：群组名称、群组标识、群组序列号、群组头像。本申请实施例中，第一用户包含于目标群组中，为了对目标群组内的第一用户发送的服务请求，以及目标群组外的任一用户发送的服务请求进行区分，在服务请求中还可以携带第一用户所在的目标群组的群组信息。

作为一种可选的实施方式，对应有提供服务的第一小程序，第一小程序布置在微信软件中，在第一小程序中组建目标群组后，目标群组中的第一用户向第一小程序的后台服务器发送服务请求，服务请求中携带有第一服务信息和第一用户所在的目标群组的群组信息。

作为另一种可选的实施方式，对应有提供服务的第一小程序，以及组建服务群组的第二小程序，第一小程序和第二小程序均布置在微信软件中，在第二小程序中组建目标群组后，第二小程序将目标群组相关的信息同步给第一小程序，第一用户通过第二小程序进入第一小程序，并向第一小程序的服务器发送服务请求，其中，服务请求中至少包括第一服务信息，还可以包括群组信息。

S102、根据所述服务请求中的第一服务信息以及响应所述服务请求的目标服务提供方的第二服务信息，生成服务中的第一服务订单。

该步骤中，目标群组中的第一用户为服务请求端，相应的，对应有服务提供端，目标服务提供方即为服务提供端，作为一种可选的实施方式，通过如下方式确定目标服务提供方：根据服务请求携带的第一服务信息，从多个服务提供方中选取候选服务提供方；根据每个候选服务提供方对应的第二服务信息，从多个候选服务提供方中选取目标服务提供方；其中，候选服务提供方为可以满足第一服务信息的服务提供方，候选服务提供方对应的第二服务信息至少包括身份信息、位置信息、历史服务评价信息，基于每个候选服务提供方的第二服务信息，从候选服务提供方中择优选择可以提供优质服务的目标服务提供方，将服务请求发送给目标服务提供方，在目标服务提供方响应服务请求后，根据第一用户的第一服务信息，以及目标服务提供方的第二服务信息，生成服务中的第一服务订单。

作为另一种可选的实施方式，服务器在接收到目标群组中的第一用户发送的服务请求后，根据服务请求携带的第一服务信息，从多个服务提供方中选取候选服务提供方，并将携带有第一服务信息的服务请求广播给每个候选服务提供方，根据每个候选服务提供方响应服务请求的响应时间，从多个候选服务提供方中选取目标服务提供方，比如，将最先响应服务请求的候选服务提供方确定为目标服务提供方，进而根据第一用户的第一服务信息，以及目标服务提供方的第二服务信息，生成服务中的第一服务订单。

其中，第一服务订单的订单信息至少包括：第一用户发送服务请求的时间，目标服务提供方响应服务请求的时间，第一用户的第一服务信息，目标服务提供方的第二服务信息，实时更新的服务金额。

S103、在检测到所述第一服务订单完成后，根据所述群组信息确定目标支付账号。

该步骤中，完成第一服务订单时对应多种方式，方式一，若第一服务信息中包括终点，在检测到已到达终点位置时，完成第一服务订单；方式二，若第一服务信息中包括服务时长，在检测到服务时长已结束时，完成第一服务订单；方式三，在接收到第一用户发送的结束第一服务订单的指示信息时，完成第一服务订单；方式四，在接收到目标服务提供方发送的结束第一服务订单的指示信息时，完成第一服务订单。

目标支付账号为目标群组中每个第一用户均可使用的支付账号，目标群组中的每个第一用户在完成服务后，使用目标群组的目标支付账号支付服务费用。

在检测到第一服务订单完成时，根据服务请求对应的群组信息，获取第一用户所在的目标群组的目标支付账号，其中，目标支付账号可以是微信支付账号、支付宝支付账号、云闪付支付账号、美团支付账号，银行卡的支付账号等多种支付账号，这里，不对支付账号的类型进行限定。

具体的，通过如下方式获取第一用户所在的目标群组的目标支付账号，预存有每个目标群组的群组信息与目标支付账号的对应关系，基于上述对应关系，查找第一用户所在的目标群组的目标支付账号。

作为一种可选的实施方式，每个目标群组对应唯一的目标支付账号，基于目标群组的群组信息与目标支付账号的对应关系，查找第一用户所在的目标群组对应的目标支付账号。

作为另一种可选的实施方式，每个目标群组可以对应多个支付账号，基于目标群组的群组信息与支付账号的对应关系，查找第一用户所在的目标群组对应的多个支付账号，并将多个支付账号提供给第一用户对应的第一用户终端，供第一用户进行选择，第一用户终端响应第一用户针对多个支付账号中的目标支付账号的选择操作，将第一用户选择的目标支付账号发送给服务器，以使服务器确定此次服务的目标支付账号。

实际中，第一用户可以包含于多个服务群组中，第一用户通过组建服务群组的第二小程序进入到提供服务的第一小程序，向第一小程序的服务器发送服务请求，其中，第一小程序本地预存有每个服务群组的支付账号，以及每个服务群组中包括的用户，第一小程序的服务器在检测到服务请求的第一服务订单完成后，查找第一用户所在的多个服务群组，将多个服务群组发送给第一用户对应的第一用户终端，供第一用户选择使用哪个服务群组的支付账号，第一用户终端响应第一用户针对多个服务群组中的目标群组的选择操作，将第一用户选择的目标群组发送给服务器，若目标群组对应唯一的支付账号，则服务器将目标群组的支付账号确定为目标支付账号，若目标群组对应多个支付账号，则服务器将第一用户选择的支付账号确定为目标支付账号。

S104、根据所述目标支付账号和所述第一服务订单对应的支付金额，生成已完成的第二服务订单。

该步骤中，第一服务订单的订单信息中包括实时更新的服务金额，在检测到第一服务订单完成时，将此时的服务金额确定为第一服务订单对应的支付金额，其中，服务金额和支付金额可以是虚拟货币、电子货币、数字货币、信用分值中的任一种。

每个由第一用户发起的服务请求均对应有服务订单，其中，服务订单对应有服务中的第一服务订单，以及已完成的第二服务订单两种订单状态，付款前的服务订单为第一服务订单，付款后的服务订单为第二服务订单，在从目标支付账号中转出第一服务订单对应的支付金额后，确定该次服务付款完成，生成第二服务订单，第二服务订单的订单信息至少包括：第一用户发送服务请求的时间，目标服务提供方响应服务请求的时间，第一用户的第一服务信息，目标服务提供方的第二服务信息，支付时间，支付金额，订单的评价信息。

本申请实施例提供的一种服务处理方法，目标群组内的第一用户的服务请求完成后，从目标群组的目标支付账号中扣除服务请求对应的支付金额，通过组建对应有目标支付账号的目标群体，实现同一目标群体内的各个用户使用公共的目标支付账号支付服务费用，简化群体内服务费用的支付过程，提高服务费用的清算效率。

进一步的，参见图2所示，图2为本申请实施例提供的另一种服务处理方法的流程图，通过如下方式创建所述目标群组：

S201、接收第二用户发送的创建请求；其中，所述创建请求中包括群组信息；所述第二用户为所述第一用户中满足预设条件的用户。

该步骤中，每个目标群组中包括多个第一用户，其中，多个第一用户中包括一个第二用户，第二用户为满足预设条件的第一用户，具体的，第二用户为目标群组的队长，即创建目标群组的用户，第二用户对应的第二用户终端响应第二用户的群组创建操作，生成与群组创建操作相匹配的创建请求，并将生成的创建请求发送给服务器。

作为一种可选的实施方式，对应有提供服务的第一小程序，第一小程序布置在微信软件中，第二用户进入第一小程序的创建群组页面，或者，第二用户在微信、QQ等通讯软件中接收到好友发送的分享卡片，第二用户终端响应第二用户针对分享卡片的点击操作，将第二用户终端的当前页面更新为第一小程序的创建群组页面，第二用户终端响应第二用户的群组创建操作，将与群组创建操作相匹配的创建请求发送给第一小程序的服务器。

作为另一种可选的实施方式，对应有提供服务的第一小程序，以及组建服务群组的第二小程序，第一小程序和第二小程序均布置在微信软件中，第二用户进入第二小程序的创建群组页面，或者，第二用户在微信、QQ等通讯软件中接收到好友发送的分享卡片，第二用户终端响应第二用户针对分享卡片的点击操作，将第二用户终端的当前页面更新为第二小程序的创建群组页面，第二用户终端响应第二用户的群组创建操作，将与群组创建操作相匹配的创建请求发送给第二小程序的服务器。

实际中，第二用户发送的创建请求中携带有待创建的服务群组的群组信息，或者，服务器在接收到第二用户发送的创建请求后，向第二用户对应的第二用户终端发送输入群组信息的提示信息，以使第二用户通过第二用户终端向服务器提供群组信息。

S202、若所述创建请求为合法请求，则根据所述群组信息创建所述目标群组。

该步骤中，服务器在接收到第二用户发送的创建请求后，获取第二用户的用户信息，并接收第二用户提供的待创建的服务群组的群组信息，基于用户信息和群组信息，判断创建请求是否为合法请求，其中，用户信息至少包括以下信息之一：用户头像、用户名称、用户介绍信息，群组信息至少包括以下信息之一：群组名称、群组标识、群组序列号、群组头像。

具体的，通过如下方式判断创建请求是否为合法请求：判断第二用户的用户信息中是否包括非法信息，比如，判断第二用户的用户头像、用户名称、用户介绍信息中是否包括敏感词汇、敏感图案等不允许公开使用的信息；和/或，判断第二用户提供的群组信息中是否包括非法信息，是否包括规定字符(大写英文字符、小写英文字符、数字等)，群组信息的字符长度是否符合要求，比如，判断群组名称中是否包括大写英文字符、小写英文字符、数字等规定的字符，群组名称的字符长度是否小于预设阈值；若第二用户的用户信息中不包括非法信息，和/或，第二用户提供的群组信息中不包括非法信息，包括规定字符，并且群组信息的字符长度符合要求，则将该创建请求确定为合法请求。

在创建目标群组时，对应有两种创建方式，作为一种可选的实施方式，对应有提供服务的第一小程序，第一小程序的服务器在确定第二用户发送的创建请求为合法请求后，生成一个以第二用户为队长的目标群组，该目标群组的群组信息为第二用户提供的群组信息，比如，第二用户提供的群组名称为“123打车群”，服务器生成一个群名为“123打车群”的目标群组。需要说明的是，在登录第一小程序后，第二用户才可以创建目标群组。

作为另一种可选的实施方式，对应有提供服务的第一小程序，以及组建服务群组的第二小程序，第二小程序的服务器在确定第二用户发送的创建请求为合法请求后，生成一个以第二用户为队长的目标群组，该目标群组的群组信息为第二用户提供的群组信息。需要说明的是，在登录第二小程序后，第二用户才可以创建目标群组。

S203、接收所述第二用户发送的针对所述目标群组的支付账号配置请求，为所述目标群组配置目标支付账号。

该步骤中，由于包含于目标群组内的第一用户，可以使用目标群组的公共支付账号支付服务金额，因此，在创建目标群组时，需要为目标群组配置公共的支付账号，由第二用户为目标群组配置目标支付账号，具体的，第二用户终端响应第二用户针对目标群组的支付账号配置操作，生成对应的支付账号配置请求，并将生成的支付账号配置请求发送给服务器，服务器在接收到关于目标群组的支付账号配置请求后，将目标群组的公共支付账号配置为目标支付账号。

作为一种可选的实施方式，对应有提供服务的第一小程序，第二用户进入第一小程序的支付账号配置页面，第二用户终端响应第二用户的支付账号配置操作，将与支付账号配置操作相匹配的支付账号配置请求发送给第一小程序的服务器。

作为另一种可选的实施方式，对应有提供服务的第一小程序，以及组建服务群组的第二小程序，第二用户进入第二小程序的支付账号配置页面，第二用户终端响应第二用户的支付账号配置操作，将与支付账号配置操作相匹配的支付账号配置请求发送给第二小程序的服务器。

进一步的，在为目标群组配置目标支付账号之后，第二用户还可以对目标支付账号的支付方式进行设置，通过如下方式将目标支付账号设置为免密支付账号：

接收所述第二用户发送的针对所述目标支付账号的免密设置请求，将所述目标支付账号设置为免密支付账号。

具体的，第二用户终端响应第二用户的免密设置操作，将与免密设置操作相匹配的免密设置请求发送给服务器，服务器在接收到针对目标支付账号的免密设置请求后，将目标支付账号设置为免密支付账号。

通过如下方式将目标支付账号设置为验证成功后再支付的账号：

接收所述第二用户发送的针对所述目标支付账号的验证信息设置请求，将所述目标支付账号的验证信息设置为所述第二用户提供的目标验证信息。

具体的，第二用户终端响应第二用户的验证信息设置操作，将与验证信息设置操作相匹配的验证信息设置请求发送给服务器，服务器在接收到针对目标支付账号的验证信息设置请求后，将目标支付账号的验证信息设置为第二用户提供的目标验证信息。

其中，目标验证信息包括数字密码、手势密码、付款二维码、序列号等可识别用户身份的信息。

通过如下方式设置目标支付账号的上限支付额度：

接收所述第二用户发送的针对所述目标支付账号的支付额度设置请求，将所述目标支付账号的支付额度设置为所述第二用户提供的目标支付额度。

具体的，第二用户终端响应第二用户的支付额度设置操作，将与支付额度设置操作相匹配的支付额度设置请求发送给服务器，服务器在接收到针对目标支付账号的支付额度设置请求后，将目标支付账号的支付额度设置为第二用户提供的目标支付额度。

统计从目标支付账号中转出的每笔与目标群组相关的支付金额，得到目标群组中每个第一用户发起的每个服务请求的总支付金额，若总支付金额超过目标支付额度，则目标群组中的第一用户无法使用目标支付账号支付服务请求所对应的支付金额。

相应的，参见图3所示，图3为本申请实施例提供的另一种服务处理方法的流程图，若目标支付账号为免密支付账号，所述根据所述目标支付账号和所述第一服务订单对应的支付金额，生成已完成的第二服务订单，包括：

S301、从所述目标支付账号中转出所述第一服务订单对应的支付金额，生成第一支付完成信息。

该步骤中，在检测到第一服务订单完成时，将此时的服务金额确定为第一服务订单对应的支付金额，并从免密的目标支付账号中转出支付金额，生成第一支付完成信息，并将第一支付完成信息发送给第一用户对应的第一用户终端，提示第一用户此次服务的费用已支付完成。

S302、根据所示第一支付完成信息和所述第一服务订单，生成所述第二服务订单。

该步骤中，在第一服务订单对应的支付金额支付完成后，生成此次服务对应的第二服务订单，这里，第二服务订单的订单信息至少包括：第一用户发送服务请求的时间，目标服务提供方响应服务请求的时间，第一用户的第一服务信息，目标服务提供方的第二服务信息，支付时间，支付金额，支付方式(免密支付)，订单的评价信息。

进一步的，参见图4所示，图4为本申请实施例提供的另一种服务处理方法的流程图，若目标支付账号为身份验证的支付账号，所述根据所述目标支付账号和所述第一服务订单对应的支付金额，生成已完成的第二服务订单，还包括：

S401、向所述第一用户对应的第一用户终端发送身份验证提示信息。

该步骤中，在检测到第一用户的第一服务订单完成时，获取第一用户所在的目标群组的目标支付账号，若目标支付账号为需要身份验证的支付账号，则向第一用户对应的第一用户终端发送身份验证提示信息，以提示第一用户提供可以用于验证身份的验证信息，比如，提示第一用户输入目标支付账号的支付密码。

S402、接收所述第一用户提供的验证信息，若所述验证信息为所述目标验证信息，则从所述目标支付账号中转出所述第一服务订单对应的支付金额，生成第二支付完成信息。

该步骤中，第一用户在获取身份验证提示信息之后，通过第一用户终端向服务器提供待验证的验证信息，服务器接收第一用户终端发送的验证信息，服务器本地预存有每个目标群组的目标支付账号的目标验证信息，将接收到验证信息与目标验证信息进行对比，若验证信息与目标验证信息相一致，则确定第一用户身份验证通过，从目标支付账号中转出支付金额，生成第二支付完成信息，并将第二支付完成信息发送给第一用户对应的第一用户终端，提示第一用户此次服务的费用已支付完成。

S403、根据所示第二支付完成信息和所述第一服务订单，生成所述第二服务订单。

该步骤中，在第一服务订单对应的支付金额支付完成后，生成此次服务对应的第二服务订单，这里，第二服务订单的订单信息至少包括：第一用户发送服务请求的时间，目标服务提供方响应服务请求的时间，第一用户的第一服务信息，目标服务提供方的第二服务信息，支付时间，支付金额，支付方式(身份验证支付)，订单的评价信息。

进一步的，参见图5所示，图5为本申请实施例提供的另一种服务处理方法的流程图，若目标支付账号对应有目标支付额度，所述根据所述目标支付账号和所述第一服务订单对应的支付金额，生成已完成的第二服务订单，还包括：

S501、获取所述目标支付账号的剩余支付额度，若所述剩余支付额度大于等于所述第一服务订单对应的支付金额，则从所述目标支付账号中转出所述支付金额，生成所述第二服务订单。

该步骤中，在检测到第一用户的第一服务订单完成时，获取第一用户所在的目标群组的目标支付账号，若目标支付账号对应有目标支付额度，根据目标支付账号的目标支付额度，以及目标群组已从目标支付账号转出的总支付金额，确定目标支付账号的剩余支付额度，并判断剩余支付额度和当前第一服务订单的支付金额的大小，若剩余支付额度大于等于支付金额，即该次服务的支付金额可以从目标群组的目标支付账号扣除，在第一服务订单对应的支付金额支付完成后，生成此次服务对应的第二服务订单，这里，第二服务订单的订单信息至少包括：第一用户发送服务请求的时间，目标服务提供方响应服务请求的时间，第一用户的第一服务信息，目标服务提供方的第二服务信息，支付时间，支付金额，支付方式(免密支付或者身份验证支付)，订单的评价信息。

S502、若所述剩余支付额度小于所述第一服务订单对应的支付金额，则从所述第一用户对应的候选支付账号中转出所述支付金额，生成所述第二服务订单。

该步骤中，若剩余支付额度小于支付金额，即该次服务的支付金额不可以从目标群组的目标支付账号扣除，需要从第一用户的个人支付账号中扣除，进而，获取第一用户对应的候选支付账号，从候选支付账号中转出本次服务的支付金额，并在第一服务订单对应的支付金额支付完成后，生成此次服务对应的第二服务订单。

进一步的，参见图6所示，图6为本申请实施例提供的另一种服务处理方法的流程图，在配置目标群组的目标支付账号之前，需要判断第二用户的信用信息是否满足信用条件，只有信用信息满足信用条件的第二用户，才可以创建共享支付的目标群组，所述接收所述第二用户发送的针对所述目标群组的支付账号配置请求，为所述目标群组配置目标支付账号，包括：

S601、接收所述第二用户发送的针对所述目标群组的支付账号配置请求，获取所述第二用户对应的目标支付账号的信用信息。

该步骤中，第二用户终端响应第二用户针对目标群组的支付账号配置操作，生成与支付账号配置操作相匹配的支付账号配置请求，并将支付账号配置请求发送给服务器，服务器在接收到第二服务终端发送的支付账号配置请求后，获取第二用户名下的目标支付账号，以及目标支付账号的信用信息，其中，信用信息可以为以下信息之一：信息分值、信用等级，比如，微信支付分。

S602、若所述信用信息满足信用条件，则将所述目标群组的支付账号设置为所述目标支付账号。

该步骤中，信用条件为信用分值大于预设阈值，或者，信用等级高于预设等级，如果目标支付账号的信用信息满足信用条件，则将目标支付账号设置为目标群组的公共支付账号，如果目标支付账号的信用信息不满足信用条件，则终止目标群组的创建。

进一步的，参见图7所示，图7为本申请实施例提供的另一种服务处理方法的流程图，在第二用户配置目标群组的目标支付账号之后，需要向目标群组中添加新用户，以实现目标群组内多个用户的共享支付，在添加新用户时，可以是第二用户主动向目标群组中添加新用户，所述方法还包括：

S701、向第三用户发送邀请信息；所述邀请信息用于邀请所述第三用户加入所述目标群组。

该步骤中，第二用户终端响应第二用户在创建群组成功页面或者个人主页针对邀请按钮的触发操作，这里，触发操作可以是点击、滑动、长按等操作，生成邀请用户请求，并将邀请用户请求发送给服务器，服务器在接收到第二用户发送的邀请用户请求后，查找第二用户已组建的多个群组，并将多个群组发送给第二用户终端，第二用户终端响应第二用户针对多个群组中的目标群组的第一选择操作，以及针对多个候选用户中的第三用户的第二选择操作，将目标群组和第三用户发送给服务器，服务器在接收到目标群组和第三用户之后，向第三用户对应的第三用户终端发送加入目标群组的邀请信息，比如，将邀请链接发送给第三用户终端。这里，候选用户为不同于第二用户的任一用户。

S702、在接收到所述第三用户返回的第一确认信息后，若所述目标群组符合添加条件，则将所述第三用户确定为所述第一用户。

该步骤中，第三用户终端在接收到加入目标群组的邀请信息后，响应第三用户针对邀请信息的确认操作，比如，点击邀请链接，生成第一确认信息，并将第一确认信息发送给服务器，服务器在接收到第三用户终端返回的第一确认信息后，确认第三用户同意加入目标群组，进而判断当前的目标群组是否符合添加条件，即当前的目标群组能否添加新的用户，其中，所述添加条件至少包括以下条件之一：存在包括所述第二用户的目标群组、所述目标群组对应有目标支付账号、所述目标群组内包括的用户的数量小于预设阈值。

相应的，服务器在接收到第三用户终端返回的第一确认信息后，若当前存在第二用户已创建的、未解散的目标群组；并且，当前的目标群组对应有目标支付账号，即目标支付账号的信用信息满足信用条件；并且，当前的目标群组包括的用户数量小于预设阈值，即目标群组没有加满，则将第三用户确定为第一用户，将第三用户加入目标群组。

若当前并不存在第二用户已创建的目标群组，或者，目标群组已被第二用户解散，则向第二用户的第二用户终端发送创建服务群组的提示信息，以提示第二用户及时创建服务群组，并在目标群组创建完成后，再次判断目标群组是否符合添加条件，如果符合，则将第三用户确定为第一用户，将第三用户加入目标群组。

若当前的目标群组没有目标支付账号，或者，并没有获取第二用户的信用信息，则向第二用户的第二用户终端发送配置目标支付账号的提示信息，以提示第二用户及时配置目标支付账号，并在目标支付账号配置完成后，再次判断目标群组是否符合添加条件，如果符合，则将第三用户确定为第一用户，将第三用户加入目标群组。

若当前的目标群组包括的用户数量大于等于预设阈值，则向第二用户的第二用户终端发送群组已满、无法添加新用户的提示信息，以提示第二用户当前目标群组用户数量已达到上限。

进一步的，参见图8所示，图8为本申请实施例提供的另一种服务处理方法的流程图，在第二用户配置目标群组的目标支付账号之后，需要向目标群组中添加新用户，以实现目标群组内多个用户的共享支付，在添加新用户时，可以是第三用户主动要求加入第二用户创建的目标群组，所述方法还包括：

S801、接收第三用户发送的加入所述目标群组的入群请求，并将所述入群请求发送给第二用户对应的第二用户终端。

该步骤中，第三用户终端响应第三用户在群组管理页面针对加入群组按钮的触发操作，这里，触发操作可以是点击、滑动、长按等操作，生成加入第三用户选择的(或者添加的)目标群组的入群请求，并将加入目标群组的入群请求发送给服务器，服务器接收第三用户终端发送的入群请求，并将入群请求发送给创建目标群组的第二用户对应的第二用户终端，比如，将申请链接发送给第二用户终端。

S802、在接收到所述第二用户返回的第二确认信息后，若所述目标群组符合添加条件，则将所述第三用户确定为所述第一用户。

该步骤中，第二用户终端在接收到第三用户的入群请求后，响应第二用户针对入群请求的确认操作，比如，点击申请链接，生成第二确认信息，并将第二确认信息发送给服务器，服务器在接收到第二用户终端返回的第二确认信息后，确认第二用户同意第三用户加入目标群组，进而判断当前的目标群组是否符合添加条件，即当前的目标群组能否添加新的用户，其中，所述添加条件至少包括以下条件之一：存在包括所述第二用户的目标群组、所述目标群组对应有目标支付账号、所述目标群组内包括的用户的数量小于预设阈值。

相应的，服务器在接收到第二用户终端返回的第二确认信息后，若当前存在第二用户已创建的、未解散的目标群组；并且，当前的目标群组对应有目标支付账号，即目标支付账号的信用信息满足信用条件；并且，当前的目标群组包括的用户数量小于预设阈值，即目标群组没有加满，则将第三用户确定为第一用户，将第三用户加入目标群组。

若当前并不存在第二用户已创建的目标群组，或者，目标群组已被第二用户解散，则向第二用户的第二用户终端发送创建服务群组的提示信息，以提示第二用户及时创建服务群组，并在目标群组创建完成后，再次判断目标群组是否符合添加条件，如果符合，则将第三用户确定为第一用户，将第三用户加入目标群组。

若当前的目标群组没有目标支付账号，或者，并没有获取第二用户的信用信息，则向第二用户的第二用户终端发送配置目标支付账号的提示信息，以提示第二用户及时配置目标支付账号，并在目标支付账号配置完成后，再次判断目标群组是否符合添加条件，如果符合，则将第三用户确定为第一用户，将第三用户加入目标群组。

若当前的目标群组包括的用户数量大于等于预设阈值，则向第二用户的第二用户终端发送群组已满、无法添加新用户的提示信息，以提示第二用户当前目标群组用户数量已达到上限。

进一步的，第二用户可以随时查看目标群组内每个第一用户的服务请求情况，所述方法还包括：

接收所述第二用户发送的针对所述目标群组的订单查看请求，查找所述目标群组对应的每个第二服务订单的订单信息，并将所述订单信息发送给第二用户对应的第二用户终端。

具体的，第二用户终端响应第二用户针对目标群组的订单查看操作，生成订单查看请求，并将订单查看请求发送给服务器，服务器在接收到针对目标群组的订单查看请求后，查找目标群组中每个第一用户对应的每个第二服务订单的订单信息，并将所有的订单信息发送给第二用户终端，以使第二用户终端对订单信息进行显示。

进一步的，参见图9所示，图9为本申请实施例提供的另一种服务处理方法的流程图，第二用户可以请求生成目标群组内每个第二用户订单的电子发票，所述方法还包括：

S901、接收所述第二用户发送的针对所述目标群组的电子发票生成请求，查找所述目标群组对应的每个第二服务订单的订单信息，并将所述订单信息发送给第二用户对应的第二用户终端。

该步骤中，第二用户终端响应第二用户针对目标群组的电子发票生成操作，生成电子发票生成请求，并将电子发票生成请求发送给服务器，服务器在接收到针对目标群组的电子发票生成请求后，查找目标群组中每个第一用户对应的每个第二服务订单的订单信息，并将所有的订单信息发送给第二用户终端，以使第二用户终端对订单信息进行显示。

S902、接收所述第二用户发送的从所述第二服务订单中选取的目标服务订单，生成所述目标服务订单的电子发票，并将所述电子发票发送给所述第二用户对应的第二用户终端。

该步骤中，第二用户终端响应第二用户针对多个第二服务订单中的目标服务订单的选择操作，其中，目标服务订单可以为一个第二服务订单，也可以为多个第二服务订单，并将目标服务订单返回给服务器，服务器在接收到目标服务订单后，生成目标服务订单的电子发票，并将电子发票发送给第二用户对应的第二用户终端，以使第二用户终端对电子发票进行显示，还可以提供打印和保存的功能选择，将生成的电子发票打印出来，或者将生成的电子发票保存在第二用户终端本地。

基于同一发明构思，本申请实施例中还提供了与服务处理方法对应的服务处理装置，由于本申请实施例中的装置解决问题的原理与本申请实施例上述服务处理方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。

参见图10所示，图10为本申请一实施例提供的一种服务处理装置的结构示意图，该服务处理装置包括：

第一接收模块1001，用于接收目标群组中的第一用户发送的服务请求，所述服务请求中包括第一服务信息和群组信息；

第一生成模块1002，用于根据所述服务请求中的第一服务信息以及响应所述服务请求的目标服务提供方的第二服务信息，生成服务中的第一服务订单；

第一确定模块1003，用于在检测到所述第一服务订单完成后，根据所述群组信息确定目标支付账号；

第二生成模块1004，用于根据所述目标支付账号和所述第一服务订单对应的支付金额，生成已完成的第二服务订单。

在一种可能的实施方式中，所述服务处理装置还包括：

第二接收模块，用于接收第二用户发送的创建请求；其中，所述创建请求中包括群组信息；所述第二用户为所述第一用户中满足预设条件的用户；

创建模块，用于若所述创建请求为合法请求，则根据所述群组信息创建所述目标群组；

配置模块，用于接收所述第二用户发送的针对所述目标群组的支付账号配置请求，为所述目标群组配置目标支付账号。

在一种可能的实施方式中，所述服务处理装置还包括：

第一设置模块，用于接收所述第二用户发送的针对所述目标支付账号的免密设置请求，将所述目标支付账号设置为免密支付账号。

在一种可能的实施方式中，所述服务处理装置还包括：

第二设置模块，用于接收所述第二用户发送的针对所述目标支付账号的验证信息设置请求，将所述目标支付账号的验证信息设置为所述第二用户提供的目标验证信息。

在一种可能的实施方式中，所述服务处理装置还包括：

第三设置模块，用于接收所述第二用户发送的针对所述目标支付账号的支付额度设置请求，将所述目标支付账号的支付额度设置为所述第二用户提供的目标支付额度。

在一种可能的实施方式中，所述第二生成模块1004，在根据所述目标支付账号和所述第一服务订单对应的支付金额，生成已完成的第二服务订单时，包括：

从所述目标支付账号中转出所述第一服务订单对应的支付金额，生成第一支付完成信息；

根据所示第一支付完成信息和所述第一服务订单，生成所述第二服务订单。

在一种可能的实施方式中，所述第二生成模块1004，在根据所述目标支付账号和所述第一服务订单对应的支付金额，生成已完成的第二服务订单时，还包括：

向所述第一用户对应的第一用户终端发送身份验证提示信息；

接收所述第一用户提供的验证信息，若所述验证信息为所述目标验证信息，则从所述目标支付账号中转出所述第一服务订单对应的支付金额，生成第二支付完成信息；

根据所示第二支付完成信息和所述第一服务订单，生成所述第二服务订单。

在一种可能的实施方式中，所述第二生成模块1004，在根据所述目标支付账号和所述第一服务订单对应的支付金额，生成已完成的第二服务订单时，还包括：

获取所述目标支付账号的剩余支付额度，若所述剩余支付额度大于等于所述第一服务订单对应的支付金额，则从所述目标支付账号中转出所述支付金额，生成所述第二服务订单；

若所述剩余支付额度小于所述第一服务订单对应的支付金额，则从所述第一用户对应的候选支付账号中转出所述支付金额，生成所述第二服务订单。

在一种可能的实施方式中，所述配置模块，在接收所述第二用户发送的针对所述目标群组的支付账号配置请求，为所述目标群组配置目标支付账号时，包括：

接收所述第二用户发送的针对所述目标群组的支付账号配置请求，获取所述第二用户对应的目标支付账号的信用信息；

若所述信用信息满足信用条件，则将所述目标群组的支付账号设置为所述目标支付账号。

在一种可能的实施方式中，所述服务处理装置还包括：

第一发送模块，用于向第三用户发送邀请信息；所述邀请信息用于邀请所述第三用户加入所述目标群组；

第二确定模块，用于在接收到所述第三用户返回的第一确认信息后，若所述目标群组符合添加条件，则将所述第三用户确定为所述第一用户。

在一种可能的实施方式中，所述服务处理装置还包括：

第二发送模块，用于接收第三用户发送的加入所述目标群组的入群请求，并将所述入群请求发送给第二用户对应的第二用户终端；

第三确定模块，用于在接收到所述第二用户返回的第二确认信息后，若所述目标群组符合添加条件，则将所述第三用户确定为所述第一用户。

在一种可能的实施方式中，所述服务处理装置还包括：

第一查找模块，用于接收所述第二用户发送的针对所述目标群组的订单查看请求，查找所述目标群组对应的每个第二服务订单的订单信息，并将所述订单信息发送给第二用户对应的第二用户终端。

在一种可能的实施方式中，所述服务处理装置还包括：

第二查找模块，用于接收所述第二用户发送的针对所述目标群组的电子发票生成请求，查找所述目标群组对应的每个第二服务订单的订单信息，并将所述订单信息发送给第二用户对应的第二用户终端；

第三生成模块，用于接收所述第二用户发送的从所述第二服务订单中选取的目标服务订单，生成所述目标服务订单的电子发票，并将所述电子发票发送给所述第二用户对应的第二用户终端。

在一种可能的实施方式中，所述添加条件至少包括以下条件之一：存在包括所述第二用户的目标群组、所述目标群组对应有目标支付账号、所述目标群组内包括的用户的数量小于预设阈值。

本申请实施例提供的一种服务处理装置，目标群组内的第一用户的服务请求完成后，从目标群组的目标支付账号中扣除服务请求对应的支付金额，通过组建对应有目标支付账号的目标群体，实现同一目标群体内的各个用户使用公共的目标支付账号支付服务费用，简化群体内服务费用的支付过程，提高服务费用的清算效率。

参见图11所示，图11为本申请实施例提供的一种电子设备的示意图，该电子设备1100包括：处理器1101、存储器1102和总线1103，所述存储器1102存储有所述处理器1101可执行的机器可读指令，当电子设备运行时，所述处理器1101与所述存储器1102之间通过总线1103通信，所述处理器1101执行所述机器可读指令，以执行如上述服务处理方法的步骤。

具体地，上述存储器1102和处理器1101能够为通用的存储器和处理器，这里不做具体限定，当处理器1101运行存储器1102存储的计算机程序时，能够执行上述服务处理方法。

对应于上述服务处理方法，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行上述服务处理方法的步骤。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上所述实施例，仅为本申请的具体实施方式，用以说明本申请的技术方案，而非对其限制，本申请的保护范围并不局限于此，尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本申请实施例技术方案的精神和范围，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (17)

1.一种服务处理方法，其特征在于，所述方法包括：

接收目标群组中的第一用户发送的服务请求，所述服务请求中包括第一服务信息和群组信息；

根据所述服务请求中的第一服务信息以及响应所述服务请求的目标服务提供方的第二服务信息，生成服务中的第一服务订单；

在检测到所述第一服务订单完成后，根据所述群组信息确定目标支付账号；

根据所述目标支付账号和所述第一服务订单对应的支付金额，生成已完成的第二服务订单。

2.根据权利要求1所述的服务处理方法，其特征在于，通过如下方式创建所述目标群组：

接收第二用户发送的创建请求；其中，所述创建请求中包括群组信息；所述第二用户为所述第一用户中满足预设条件的用户；

若所述创建请求为合法请求，则根据所述群组信息创建所述目标群组；

接收所述第二用户发送的针对所述目标群组的支付账号配置请求，为所述目标群组配置目标支付账号。

3.根据权利要求2所述的服务处理方法，其特征在于，所述方法还包括：

接收所述第二用户发送的针对所述目标支付账号的免密设置请求，将所述目标支付账号设置为免密支付账号。

4.根据权利要求2所述的服务处理方法，其特征在于，所述方法还包括：

接收所述第二用户发送的针对所述目标支付账号的验证信息设置请求，将所述目标支付账号的验证信息设置为所述第二用户提供的目标验证信息。

5.根据权利要求2所述的服务处理方法，其特征在于，所述方法还包括：

接收所述第二用户发送的针对所述目标支付账号的支付额度设置请求，将所述目标支付账号的支付额度设置为所述第二用户提供的目标支付额度。

6.根据权利要求3所述的服务处理方法，其特征在于，所述根据所述目标支付账号和所述第一服务订单对应的支付金额，生成已完成的第二服务订单，包括：

从所述目标支付账号中转出所述第一服务订单对应的支付金额，生成第一支付完成信息；

根据所示第一支付完成信息和所述第一服务订单，生成所述第二服务订单。

7.根据权利要求4所述的服务处理方法，其特征在于，所述根据所述目标支付账号和所述第一服务订单对应的支付金额，生成已完成的第二服务订单，还包括：

向所述第一用户对应的第一用户终端发送身份验证提示信息；

接收所述第一用户提供的验证信息，若所述验证信息为所述目标验证信息，则从所述目标支付账号中转出所述第一服务订单对应的支付金额，生成第二支付完成信息；

根据所示第二支付完成信息和所述第一服务订单，生成所述第二服务订单。

8.根据权利要求5所述的服务处理方法，其特征在于，所述根据所述目标支付账号和所述第一服务订单对应的支付金额，生成已完成的第二服务订单，还包括：

获取所述目标支付账号的剩余支付额度，若所述剩余支付额度大于等于所述第一服务订单对应的支付金额，则从所述目标支付账号中转出所述支付金额，生成所述第二服务订单；

若所述剩余支付额度小于所述第一服务订单对应的支付金额，则从所述第一用户对应的候选支付账号中转出所述支付金额，生成所述第二服务订单。

9.根据权利要求2所述的服务处理方法，其特征在于，所述接收所述第二用户发送的针对所述目标群组的支付账号配置请求，为所述目标群组配置目标支付账号，包括：

接收所述第二用户发送的针对所述目标群组的支付账号配置请求，获取所述第二用户对应的目标支付账号的信用信息；

若所述信用信息满足信用条件，则将所述目标群组的支付账号设置为所述目标支付账号。

10.根据权利要求2所述的服务处理方法，其特征在于，所述方法还包括：

向第三用户发送邀请信息；所述邀请信息用于邀请所述第三用户加入所述目标群组；

在接收到所述第三用户返回的第一确认信息后，若所述目标群组符合添加条件，则将所述第三用户确定为所述第一用户。

11.根据权利要求2所述的服务处理方法，其特征在于，所述方法还包括：

接收第三用户发送的加入所述目标群组的入群请求，并将所述入群请求发送给第二用户对应的第二用户终端；

在接收到所述第二用户返回的第二确认信息后，若所述目标群组符合添加条件，则将所述第三用户确定为所述第一用户。

12.根据权利要求2所述的服务处理方法，其特征在于，所述方法还包括：

接收所述第二用户发送的针对所述目标群组的订单查看请求，查找所述目标群组对应的每个第二服务订单的订单信息，并将所述订单信息发送给第二用户对应的第二用户终端。

13.根据权利要求2所述的服务处理方法，其特征在于，所述方法还包括：

接收所述第二用户发送的针对所述目标群组的电子发票生成请求，查找所述目标群组对应的每个第二服务订单的订单信息，并将所述订单信息发送给第二用户对应的第二用户终端；

接收所述第二用户发送的从所述第二服务订单中选取的目标服务订单，生成所述目标服务订单的电子发票，并将所述电子发票发送给所述第二用户对应的第二用户终端。

14.根据权利要求10或11所述的服务处理方法，其特征在于，所述添加条件至少包括以下条件之一：存在包括所述第二用户的目标群组、所述目标群组对应有目标支付账号、所述目标群组内包括的用户的数量小于预设阈值。

15.一种服务处理装置，其特征在于，所述装置包括：

第一接收模块，用于接收目标群组中的第一用户发送的服务请求，所述服务请求中包括第一服务信息和群组信息；

第一生成模块，用于根据所述服务请求中的第一服务信息以及响应所述服务请求的目标服务提供方的第二服务信息，生成服务中的第一服务订单；

第一确定模块，用于在检测到所述第一服务订单完成后，根据所述群组信息确定目标支付账号；

第二生成模块，用于根据所述目标支付账号和所述第一服务订单对应的支付金额，生成已完成的第二服务订单。

16.一种电子设备，其特征在于，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述处理器执行所述机器可读指令，以执行如权利要求1至14任一项所述的服务处理方法的步骤。

17.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如权利要求1至14任一项所述的服务处理方法的步骤。

Images