CN109214794A - 一种支付数据的处理和支付方法及装置，电子和存储设备 - Google Patents

Abstract

本申请公开一种支付数据的处理方法和装置，以及一种支付数据的支付方法和装置，以及一种餐饮行业的支付方法和装置，以及电子和存储设备。所述处理方法包括：获取针对业务对象的待支付总数据；以及确定针对所述业务对象的业务对象支付方，其中，所述业务对象支付方至少包括两个；确定所述业务对象支付方的支付数据下限；根据所述待支付总数据、所述支付数据下限以及所述业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据；其中，所述待支付子数据之和等于所述待支付总数据；进而提高随机分配的合理性，并且能够提高支付乐趣。

Description

一种支付数据的处理和支付方法及装置，电子和存储设备

技术领域

本申请涉及电子商务技术领域，具体涉及一种支付数据的处理方法和支付方法，以及支付数据的处理装置和支付装置。本申请同时涉及一种餐饮的支付方法和装置，电子设备和存储设备。

背景技术

随着互联的发展，线上支付已成为生活中必不可少的一部分。

现有技术中消费者消费时，特别是对于餐饮行业来说，支付费用仅通过一个终端设备完成消费金额的支付，即多人消费，仅通过一人完成消费金额的支付，之后在将消费金额按照消费者均摊到每人，通过现金或者终端设备将各自的消费金额转给完成支付总金额的消费者，该种支付方式需要在消费当时通过一个消费者终端完成支付，之后再将均摊金额转至完成支付的消费者，导致支付更为繁琐。

专利文献CN105631653A提出了一种支付请求处理方法、一种支付请求处理装置和一种终端，所述方法包括：在当前终端接收到支付请求后，提示当前终端的当前用户将支付请求中的总支付金额分配至多个用户；判断是否接收到为多个用户中的每个用户分配的第一目标支付金额，在判断结果为是时，提示每个用户通过每个用户的目标终端支付每个用户的第一目标支付金额；判断是否接收到每个目标终端支付的第一目标支付金额，在判断结果为接收到每个目标终端支付的第一目标支付金额时，允许响应支付请求；否则，拒绝响应支付请求。通过本申请的技术方案，实现了将支付方式扩展为多人支付、多卡支付，提高了支付效率，丰富了支付方式，方便了用户，从而提升了用户体验。该专利文献，实现线上针对同一笔支付金额能够拆分成多个不同子金额并发送至消费者完成支付，避免上支付的繁琐。但是，该种金额分配方式存在的缺陷包括：

1、支付金额为均等，即总金额均摊到每参与者，即AA形式，降低支付的趣味性；

2、支付金额非均等，每个参与者接收的金额不同，会导致金额分配差距较大。

因此，上述现有技术中的支付金额的分配方式，不能够提高支付的趣味性以及支付金额分配的合理性。

发明内容

本申请提供一种支付数据的处理方法，以解决现有技术中支付金额分配趣味性以及合理性的问题。

本申请提供一种支付数据的处理方法，包括：

获取针对业务对象的待支付总数据；以及

确定针对所述业务对象的业务对象支付方，其中，所述业务对象支付方至少包括两个；

确定所述业务对象支付方的支付数据下限；

根据所述待支付总数据、所述支付数据下限以及所述业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据；其中，所述待支付子数据之和等于所述待支付总数据。

在一些实施例中，所述根据所述待支付总数据、所述支付数据下限以及所述业务对象支付方，分别为每位所述业务对象支付方确定需要支付的待支付子数据，包括：

根据所述支付数据下限、所述业务对象支付方的数量和所述待支付总数据，确定分配支付数据；

将所述分配支付数据，按照所述业务对象支付方的数量进行随机分配，分别获得每位业务对象支付方的随机分配支付数据；

根据每位业务对象支付方的随机分配支付数据和所述支付数据下限，分别确定每位业务对象支付方需要支付的待支付子数据。

在一些实施例中，所述根据所述支付数据下限和所述待支付总数据，确定分配支付数据，包括：

将所述待支付总数据中扣除所述支付数据下限，获得所述分配支付数据；

所述将所述分配支付数据，按照所述业务对象支付方的数量进行随机分配，分别获得每位业务对象支付方的随机分配支付数据，包括：

将所述分配支付数据，按照所述业务对象支付方的数量进行拆分，获得至少一组与所述业务对象支付方数量匹配的所述随机分配支付数据。

在一些实施例中，所述根据所述待支付总数据、所述支付数据下限以及所述业务对象支付方，确定每位所述业务对象支付方需要支付的待支付子数据，包括：

根据所述待支付总数据、所述支付数据下限、所述业务对象支付方的数量以及已分配的第一随机支付数据，确定待分配支付数据；

判断所述待分配支付数据是否为最后一笔，若否，则在所述待分配支付数据中选取第二随机支付数据，根据所述第二随机支付数据和所述支付数据下限，确定所述待支付子数据，并跳转至所述确定待分配支付数据的步骤继续执行；若是，则将所述待分配支付数据和所述第一随机支付数据，确定为待支付子数据，并退出所述确定每位所述业务对象支付方需要支付的待支付子数据的步骤。

在一些实施例中，按照下述公式根据所述待支付总数据、所述支付数据下限、所述业务对象支付方的数量以及已分配的第一随机支付数据，确定待分配支付数据：待分配支付数据＝(M-A)-N×min；其中，M为待支付总数据，N为业务对象支付方的数量，min为支付数据下限，A为已分配的第一随机支付数据。

在一些实施例中，按照下述公式根据所述第二随机支付数据和所述支付数据下限，确定所述待支付子数据：待支付子数据＝Random((M-A)-N×min)+min；其中，Random((M-A)-N×min)为在((M-A)-N×min)中随机选取的第二随机支付数据。

在一些实施例中，按照以下至少一种方式确定所述业务对象支付方的支付数据下限：根据所述业务对象的地理位置信息，确定所述业务对象支付方的支付数据下限；根据所述待支付总数据的信息，确定所述业务对象支付方的支付数据下限；根据所述待支付总数据和业务对象支付方的数量，确定所述业务对象支付方的支付数据下限。

在一些实施例中，所述确定针对所述业务对象的业务对象支付方，包括：

根据选取所述业务对象信息的参与者，确定所述业务对象支付方；和/或，根据针对所述业务对象发出邀请且对所述邀请成功响应的被邀请接收方，确定所述业务对象支付方。

在一些实施例中，还包括：将所述确定的待支付子数据分发给所述业务对象支付方。

本申请还提供一种支付数据的处理装置，包括：

获取单元，用于获取针对业务对象的待支付总数据；以及

第一确定单元，用于确定针对所述业务对象的业务对象支付方，其中，所述业务对象支付方至少包括两个；

第二确定单元，用于确定所述业务对象支付方的支付数据下限；

第三确定单元，用于根据所述待支付总数据、所述支付数据下限以及所述业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据；其中，所述待支付子数据之和等于所述待支付总数据。

在一些实施例中，所述第三确定单元包括：

分配支付数据确定子单元，用于根据所述支付数据下限和所述待支付总数据，确定分配支付数据；

获得子单元，用于将所述分配支付数据，按照所述业务对象支付方的数量进行随机分配，分别获得每位业务对象支付方的随机分配支付数据；

确定子单元，用于根据每位业务对象支付方的随机分配支付数据和所述支付数据下限，分别确定每位业务对象支付方需要支付的待支付子数据。

在一些实施例中，所述分配支付数据确定子单元包括：

分配支付数据获取单元，用于将所述待支付总数据中扣除所述支付数据下限，获得所述分配支付数据；

所述获得子单元包括：拆分子单元，用于将所述分配支付数据，按照所述业务对象支付方的数量进行拆分，获得至少一组与所述业务对象支付方数量匹配的所述随机分配支付数据。

在一些实施例中，所述第三确定单元包括：

第一确定子单元，用于根据所述待支付总数据、所述支付数据下限、所述业务对象支付方的数量以及已分配的第一随机支付数据，确定待分配支付数据；

判断子单元，用于判断所述待分配支付数据是否为最后一笔，若否，则进入第二确定子单元；若是，则进入第三确定子单元；

所述第二确定子单元，用于在所述待分配支付数据中选取第二随机支付数据，根据所述第二随机支付数据和所述支付数据下限，确定所述待支付子数据，并跳转至所述第一确定子单元继续执行；

所述第三确定子单元，用于将所述待分配支付数据和所述第一随机支付数据，确定为待支付子数据，并退出所述确定每位所述业务对象支付方需要支付的待支付子数据的步骤。

在一些实施例中，所述第二确定单元具体采用如下至少一种方式，确定所述业务对象支付方的支付数据下限：根据所述业务对象的地理位置信息，确定所述业务对象支付方的支付数据下限；根据所述待支付总数据的信息，确定所述业务对象支付方的支付数据下限；根据所述待支付总数据和业务对象支付方的数量，确定所述业务对象支付方的支付数据下限。

在一些实施例中，所述第一确定子单元采用如下公式，确定所述待分配支付数据：待分配支付数据＝(M-A)-N×min；其中，M为待支付总数据，N为业务对象支付方的数量，min为支付数据下限，A为已分配的第一随机支付数据。

在一些实施例中，所述第二确定子单元采用如下公式，确定所述待支付子数据：待支付子数据＝Random((M-A)-N×min)+min；其中，Random((M-A)-N×min)为在((M-A)-N×min)中随机选取的第二随机支付数据。

在一些实施例中，所述第一确定单元，包括：参与者确定子单元和/或邀请确定子单元；所述参与者确定子单元，用于根据选取所述业务对象信息的参与者，确定所述业务对象支付方；所述邀请确定子单元，用于根据针对所述业务对象发出邀请且对所述邀请成功响应的被邀请接收方，确定所述业务对象支付方。

在一些实施例中，还包括：发送单元，用于将所述确定的待支付子数据分发给所述业务对象支付方。

本申请还提供一种支付数据的支付方法，包括：

基于根据待支付总数据、支付数据下限以及业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据，接收业务对象支付方针对所述待支付子数据已支付的已支付子数据；

将所述已支付子数据发送至针对所述业务对象的业务对象提供方；

调整针对所述业务对象的支付信息。

在一些实施例中，还包括：

接收针对所述业务对象的支付请求；

根据所述支付请求获取业务对象的待支付总数据；确定针对所述业务对象的业务对象支付方，其中，所述业务对象支付方至少包括两个；以及确定所述业务对象支付方的支付数据下限；

根据所述待支付总数据、所述支付数据下限以及所述业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据；其中，所述待支付子数据之和等于所述待支付总数据；

将确定的所述待支付子数据分别发送给所述业务对象支付方。

在一些实施例中，所述根据所述待支付总数据、所述支付数据下限以及所述业务对象支付方，分别为每位所述业务对象支付方确定需要支付的待支付子数据，包括：

根据所述支付数据下限和所述待支付总数据，确定分配支付数据；

将所述分配支付数据，按照所述业务对象支付方的数量进行随机分配，分别获得每位业务对象支付方的随机分配支付数据；

根据每位业务对象支付方的随机分配支付数据和所述支付数据下限，分别确定每位业务对象支付方需要支付的待支付子数据。

在一些实施例中，所述根据所述支付数据下限和所述待支付总数据，确定分配支付数据，包括：

将所述待支付总数据中扣除所述支付数据下限，获得所述分配支付数据；

所述将所述分配支付数据，按照所述业务对象支付方的数量进行随机分配，分别获得每位业务对象支付方的随机分配支付数据，包括：

将所述分配支付数据，按照所述业务对象支付方的数量进行拆分，获得至少一组与所述业务对象支付方数量匹配的所述随机分配支付数据。

在一些实施例中，所述根据所述待支付总数据、所述支付数据下限以及所述业务对象支付方，确定每位所述业务对象支付方需要支付的待支付子数据，包括：

根据所述待支付总数据、所述支付数据下限、所述业务对象支付方的数量以及已分配的第一随机支付数据，确定待分配支付数据；

判断所述待分配支付数据是否为最后一笔，若否，则在所述待分配支付数据中选取第二随机支付数据，根据所述第二随机支付数据和所述支付数据下限，确定所述待支付子数据，并跳转至所述确定待分配支付数据的步骤继续执行；若是，则将所述待分配支付数据和所述第一随机支付数据，确定为待支付子数据，并退出所述确定每位所述业务对象支付方需要支付的待支付子数据的步骤。

在一些实施例中，按照下述公式根据所述待支付总数据、所述支付数据下限、所述业务对象支付方的数量以及已分配的第一随机支付数据，确定待分配支付数据：剩余待支付数据＝(M-A)-N×min；其中，M为待支付总数据，N为业务对象支付方的数量，min为支付数据下限，A为已分配的第一随机支付数据。

在一些实施例中，按照下述公式根据所述第二随机支付数据和所述支付数据下限，确定所述待支付子数据：分配支付数据＝Random((M-A)-N×min)+min；其中，Random((M-A)-N×min)为在((M-A)-N×min)中随机选取的第二随机支付数据。

在一些实施例中，按照以下至少一种方式确定所述业务对象支付方的支付数据下限：根据所述业务对象的地理位置信息，确定所述业务对象支付方的支付数据下限；根据所述待支付总数据的信息，确定所述业务对象支付方的支付数据下限；根据所述待支付总数据和业务对象支付方的数量，确定所述业务对象支付方的支付数据下限。

在一些实施例中，将所述已支付子数据发送至针对所述业务对象的业务对象提供方，包括：

接收每位所述业务对象支付方支付的所述已支付子数据；

将所述已支付子数据合并，获得合并后的总支付数据；

判断所述总支付数据是否等于针对所述业务对象的待支付总数据，若是，则将所述总支付数据发送给所述业务对象提供方。

在一些实施例中，还包括：如果所述总支付数据不等于针对所述业务对象的待支付总数据，则向所述业务对象支付方发送提示信息。

在一些实施例中，所述提示信息包括至少以下一种信息：

所述总支付数据与所述待支付总数据不匹配的信息；

支付错误的信息；

所述总支付数据与所述待支付总数据差值的信息。

在一些实施例中，所述调整针对所述业务对象的支付信息，包括：

将针对所述业务对象的支付状态从待支付状态调整为已支付状态；和/或，调整所述业务对象的进度信息。

在一些实施例中，还包括输出至少以下一种信息：

输出针对所述业务对象支付成功后的优惠信息；

输出针对所述业务对象支付成功后的支付关闭信息；

输出针对所述业务对象支付成功后的所述业务对象显示信息；

输出针对所述业务对象支付成功后的已支付子数据退还信息。

本申请还提供一种支付数据的支付装置，包括：

接收单元，用于基于根据待支付总数据、支付数据下限以及业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据，接收业务对象支付方针对所述待支付子数据已支付的已支付子数据；

发送单元，用于将所述已支付子数据发送至针对所述业务对象的业务对象提供方；

调整单元，用于调整针对所述业务对象的支付信息。

在一些实施例中，还包括：

支付请求接收单元，用于接收针对所述业务对象的支付请求；

第一确定单元，用于根据所述支付请求获取业务对象的待支付总数据；确定针对所述业务对象的业务对象支付方，其中，所述业务对象支付方至少包括两个；以及确定所述业务对象支付方的支付数据下限；

第二确定单元，用于根据所述待支付总数据、所述支付数据下限以及所述业务对象支付方，确定每位业务对象支付方需要支付的待支付子数据；其中，所述待支付子数据之和等于所述待支付总数据；

支付子数据发送单元，用于将确定的所述待支付子数据分别发送给所述业务对象支付方。

在一些实施例中，所述第二确定单元，包括：

第一确定子单元，用于根据所述支付数据下限和所述待支付总数据，确定分配支付数据；

获得子单元，用于将所述分配支付数据，按照所述业务对象支付方的数量进行随机分配，分别获得每位业务对象支付方的随机分配支付数据；

第二确定子单元，用于根据每位业务对象支付方的随机分配支付数据和所述支付数据下限，分别确定每位业务对象支付方需要支付的待支付子数据。

在一些实施例中，所述第一确定子单元，包括：

扣除子单元，用于将所述待支付总数据中扣除所述支付数据下限，获得所述分配支付数据；

所述获得子单元，包括：

拆分子单元，用于将所述分配支付数据，按照所述业务对象支付方的数量进行拆分，获得至少一组与所述业务对象支付方数量匹配的所述随机分配支付数据。

在一些实施例中，所述第二确定单元，包括：

第一确定子单元，用于根据所述待支付总数据、所述支付数据下限、所述业务对象支付方的数量以及已分配的第一随机支付数据，确定待分配支付数据；

判断子单元，用于判断所述待分配支付数据是否为最后一笔，若否，则进入第二确定子单元；若是，则进入第三确定子单元；

所述第二确定子单元，用于在所述待分配支付数据中选取第二随机支付数据，根据所述第二随机支付数据和所述支付数据下限，确定所述待支付子数据；

所述第三确定子单元，用于将所述待分配支付数据和所述第一随机支付数据，确定为待支付子数据。

在一些实施例中，所述第一确定子单元采用如下公式，确定所述待分配支付数据：待分配支付数据＝(M-A)-N×min；其中，M为待支付总数据，N为业务对象支付方的数量，min为支付数据下限，A为已分配的第一随机支付数据。

在一些实施例中，所述第二确定子单元采用如下公式，确定所述待支付子数据：待支付子数据＝Random((M-A)-N×min)+min；其中，Random((M-A)-N×min)为在((M-A)-N×min)中随机选取的第二随机支付数据。

在一些实施例中，所述第一确定单元具体按照以下至少一种方式确定所述业务对象支付方的支付数据下限：根据所述业务对象的地理位置信息，确定所述业务对象支付方的支付数据下限；根据所述待支付总数据的信息，确定所述业务对象支付方的支付数据下限；根据所述待支付总数据和业务对象支付方的数量，确定所述业务对象支付方的支付数据下限。

在一些实施例中，所述发送单元包括：

接收子单元，用于接收每位所述业务对象支付方支付的所述已支付子数据；

合并子单元，用于将所述已支付子数据合并，获得合并后的总支付数据；

总数据判断子单元，用于判断所述总支付数据是否等于针对所述业务对象的待支付总数据，若是，则将所述总支付数据发送给所述业务对象提供方。

在一些实施例中，还包括：提示信息发送子单元，用于当所述总数据判断子单元判断结果为所述总支付数据不等于针对所述业务对象的待支付总数据，则向所述业务对象支付方发送提示信息。

在一些实施例中，所述提示信息发送子单元具体用于发送至少以下一种信息：

所述总支付数据与所述待支付总数据不匹配的信息；

支付错误的信息；

所述总支付数据与所述待支付总数据差值的信息。

在一些实施例中，所述调整单元包括：状态调整子单元和/或进度信息调整子单元；

所述状态调整子单元，用于将针对所述业务对象的支付状态从待支付状态调整为已支付状态；

所述进度信息调整子单元，用于调整所述业务对象的进度信息。

在一些实施例中，还包括：输出单元，所述输出单元输出至少以下一种信息：

输出针对所述业务对象支付成功后的优惠信息；

输出针对所述业务对象支付成功后的支付关闭信息；

输出针对所述业务对象支付成功后的所述业务对象显示信息；

输出针对所述业务对象支付成功后的已支付子数据退还信息。

本申请还提供一种餐饮行业的支付方法，包括：

接收针对点餐业务的点餐请求，所述点餐请求中包括：餐品信息、餐品提供商家以及点餐者信息，其中，餐品信息包括餐品支付总金额，所述点餐者信息包括点餐者数量，且至少两个；

确定所述点餐者的支付金额下限；

根据所述点餐请求中的餐品支付总金额、所述点餐者数量以及所述支付金额下限，确定每位所述点餐者需要支付的支付子金额；

将所述支付子金额发送给所述点餐者；

接收来自所述点餐者的所述支付子金额，并发送至所述餐品提供商家。

本申请还提供一种餐饮行业的支付装置，包括：

接收单元，用于接收针对点餐业务的点餐请求，所述点餐请求中包括：餐品信息、餐品提供方以及点餐者信息，其中，餐品信息包括餐品支付总金额，所述点餐者信息包括点餐者数量，且至少两个；

第一确定单元，用于确定所述点餐者的支付金额下限；

第二确定单元，用于根据所述点餐请求中的餐品支付总金额、所述点餐者数量以及所述支付金额下限，确定每位所述点餐者需要支付的支付子金额；

第一发送单元，用于将所述支付子金额发送给所述点餐者；

第二发送单元，用于接收来自所述点餐者的所述支付子金额，并发送至所述餐品提供方。

本申请还提供一种电子设备，包括：

处理器；

存储器，用于存储对网络平台产生数据进行处理的程序，所述程序在被所述处理器读取执行时，执行如下操作：

获取针对业务对象的待支付总数据；以及

确定针对所述业务对象的业务对象支付方，其中，所述业务对象支付方至少包括两个；

确定所述业务对象支付方的支付数据下限；

根据所述待支付总数据、所述支付数据下限以及所述业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据；其中，所述待支付子数据之和等于所述待支付总数据。

本申请还提供一种存储设备，存储网络平台产生数据，以及对应所述网络平台产生数据进行处理的程序；

所述程序在被所述处理器读取执行时，执行如下操作：

获取针对业务对象的待支付总数据；以及

确定针对所述业务对象的业务对象支付方，其中，所述业务对象支付方至少包括两个；

确定所述业务对象支付方的支付数据下限；

根据所述待支付总数据、所述支付数据下限以及所述业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据；其中，所述待支付子数据之和等于所述待支付总数据。

本申请还提供一种电子设备，包括：

处理器；

存储器，用于存储对网络平台产生数据进行处理的程序，所述程序在被所述处理器读取执行时，执行如下操作：

基于根据待支付总数据、支付数据下限以及业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据，接收业务对象支付方针对所述待支付子数据已支付的已支付子数据；

将所述已支付子数据发送至针对所述业务对象的业务对象提供方；

调整针对所述业务对象的支付信息。

本申请还提供一种存储设备，存储网络平台产生数据，以及对应所述网络平台产生数据进行处理的程序；

所述程序在被所述处理器读取执行时，执行如下操作：

基于根据待支付总数据、支付数据下限以及业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据，接收业务对象支付方针对所述待支付子数据已支付的已支付子数据；

将所述已支付子数据发送至针对所述业务对象的业务对象提供方；

调整针对所述业务对象的支付信息。

与现有技术相比，本申请具有以下优点:

本申请提供的一种支付数据的处理方法，通过获取针对业务对象的待支付总数据以及确定的针对所述业务对象的业务对象支付方和支付数据下限，之后根据所述待支付总数据、所述支付数据下限以及所述业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据；其中，所述待支付子数据之和等于所述待支付总数据，能够使得分配给每位业务对象支付方的待支付子数据更具有合理性，避免随机分配的极端现象。

本申请还提供的一种支付数据的支付方法，基于根据待支付总数据、支付数据下限以及业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据，接收业务对象支付方针对所述待支付子数据已支付的已支付子数据；将所述已支付子数据发送至针对所述业务对象的业务对象提供方；调整针对所述业务对象的支付信息；该支付方法不仅能够避免随机分配的极端现象，提高随机分配的合理性，并且能够提高多个业务对象支付方针对同一业务对象支付时的支付乐趣。

本申请还提供一种餐饮行业的支付方法，该方法通过接收针对点餐业务的点餐请求，所述点餐请求中包括：餐品信息、餐品提供商家以及点餐者信息，其中，餐品信息包括餐品支付总金额，所述点餐者信息包括点餐者数量，且至少两个；确定所述点餐者的支付金额下限；根据所述点餐请求中的餐品支付总金额、所述点餐者数量以及所述支付金额下限，确定每位所述点餐者需要支付的支付子金额；将所述支付子金额发送给所述点餐者；接收来自所述点餐者的所述支付子金额，并发送至所述餐品提供商家；从而使得消费人员(点餐者)在餐厅进行消费时可以将同一张订单拆分成多个支付子订单进行支付，参与多单支付的消费人员(点餐者)，能够获得随机分配的金额，由于设定了支付金额下限，因此避免随机分配出现极端值，进一步提高随机分配的合理性，并且能够提高支付乐趣。

附图说明

图1是本申请提供的一种支付数据的处理方法的实施例的流程图；

图2是本申请提供的一种支付数据的处理装置的实施例的结构示意图；

图3是本申请提供的一种支付数据的支付方法的实施例的流程图；

图4是本申请提供的一种支付数据的支付装置的实施例的结构示意图；

图5是本申请提供的一种餐饮行业的支付方法的实施例的流程图；

图6是本申请提供的一种餐饮行业的支付装置的实施例的结构示意图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

本申请中使用的术语是仅仅出于对特定实施例描述的目的，而非旨在限制本申请。在本申请中和所附权利要求书中所使用的描述方式例如：“一种、“第一”、和“第二”等，并非对数量上的限定或先后顺序上的限定，而是用来将同一类型的信息彼此区分。

本申请提供的一种支付数据的处理方法，能够针对不同的业务对象支付方提供基于待支付总数据的待支付子数据，所述待支付子数据根据待支付总数据、支付数据下限以及业务支付方数量等确定，使得待支付子数据更加合理化，并进一步提高线上多人支付的乐趣。

请参考图1所示，图1是本申请提供的一种支付数据的处理方法，包括：

步骤S101：获取针对业务对象的待支付总数据。

在本实施中，所述步骤S101中的所述业务对象可以是指消费商品，例如：餐饮、娱乐等消费商品。待支付总数据可以是指针对消费商品产生的消费金额，即消费者需要针对消费商品所支付的金额。下述描述中，业务对象即为消费商品，待支付总数据即为待支付的消费总金额。

步骤S102：确定针对所述业务对象的业务对象支付方，其中，所述业务对象支付方至少包括两个。

在本实施例中，所述步骤S102中的所述业务对象支付方可以是指针对业务对象(消费商品)的消费者，可以是针对同一消费商品的同一消费订单的多个消费者，在本实施中，至少包括两个业务对象支付方(消费者)。下述描述中，业务对象支付方即为消费者。

所述确定针对所述业务对象的业务对象支付方，可以包括：

根据选取所述业务对象信息的参与者，确定所述业务对象支付方；和/或，

根据针对所述业务对象发出邀请且对所述邀请成功响应的被邀请接收方，确定所述业务对象支付方。

其中，选取所述业务对象信息的参与者可以是指，针对业务对象参与消费的人员，该参与消费的人员为在场人员。所述针对所述业务对象发出邀请且对所述邀请成功响应的被邀请接收方，被邀请接收方可以是非在场人员，即没有实际参与消费的参与者。例如：对于业务对象为餐饮的，实际上就餐人员可以确定为业务对象支付方，也可以将未就餐人员添加到业务对象支付方的行列中，当然，添加需要被添加人员确认后方能添加成功。

以上是对业务对象支付方的确定进行的举例说明，实际操作当中，业务对象支付方的确定还可以有多种方式，此处不一一列举，可以理解的是业务对象支付方也可以根据实际情况进行添加或删除。

步骤S103：确定所述业务对象支付方的支付数据下限。

所述步骤S103中的所述支付数据下限可以是指针对业务对象(消费商品)需要支付的待支付总数据(总金额)预先确定的业务对象支付方的最低支付金额。在本实施例中，可以按照以下至少一种方式确定所述业务对象支付方的所述支付数据下限：

方式一：根据所述业务对象的地理位置信息，确定所述业务对象支付方的支付数据下限。在所述方式一中所述业务对象的地址位置可以是指消费商品或消费商品的商家所处的地理位置，例如：消费商品位于上海，根据上海的消费水平设定支付数据下限，例如：支付下限为20元/人，消费商品位于杭州，根据杭州的消费水平设定支付数据下限，例如：支付下限为10元/人；消费商品位于北京，根据北京的消费水平设定支付数据下限，例如：支付下限为20元/人，等等。

方式二：根据所述待支付总数据的信息，确定所述业务对象支付方的支付数据下限。所述方式二中可以根据实际需要待支付总数据的信息确定支付数据下限，例如：当待支付总数据为100元，支付下限可以为10元，当待支付总数据为200元，支付下限可以为15元等等。

方式三：根据所述支付总数据和业务对象支付方的数量，确定所述业务对象支付方的支付数据下限。所述方式三中可以根据实际需要待支付总数据的信息以及实际支付人数(业务对象支付方的数量)来确定支付数据下限，也就是说，支付数据下限受到两个因素制约，即：待支付总数据和支付人数，例如：待支付总数据为100元，支付人数为3人，则支付数据下限可以设定为10元/人；当待支付总数据为100元，支付人数为5人，则支付数据下限可以设定为5元/人；当待支付总数据为500元，支付人数为4人，则支付数据下限可以设定为20元/人。

所述步骤S103中确定所述业务对象支付方的支付数据下限，可以在支付过程中随机选择上述方式进行确定，也可以预先设定，支付时直接使用。在本实施例中，因为采用了支付数据下限进而分配待支付子数据更为合理，避免极端现象出现。

步骤S104：根据所述待支付总数据、所述支付数据下限以及所述业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据；其中，所述待支付子数据之和等于所述待支付总数据。

所述步骤S104的具体实现过程有多种方式，本申请提供两种实施例进行说明，但并不限于下述方案，具体如下：

实施例1：

所述根据所述待支付总数据、所述支付数据下限以及所述业务对象支付方，分别为每位所述业务对象支付方确定需要支付的待支付子数据，包括：

根据所述支付数据下限、所述业务对象支付方的数量和所述待支付总数据，确定分配支付数据；

将所述分配支付数据，按照所述业务对象支付方的数量进行随机分配，分别获得每位业务对象支付方的随机分配支付数据；

根据每位业务对象支付方的随机分配支付数据和所述支付数据下限，分别确定每位业务对象支付方需要支付的待支付子数据。

其中，所述根据所述支付数据下限、所述业务对象支付方的数量和所述待支付总数据，确定分配支付数据，包括：

将所述待支付总数据中扣除所述支付数据下限，获得所述分配支付数据；例如：待支付总数据为100元，支付数据下限为10元/人，业务对象支付方的数量为3人，则将100-10×3＝70元，分配支付数据为70元。

所述将所述分配支付数据，按照所述业务对象支付方的数量进行随机分配，分别获得每位业务对象支付方的随机分配支付数据，包括：

将所述分配支付数据，按照所述业务对象支付方的数量进行拆分，获得至少一组与所述业务对象支付方数量匹配的所述随机分配支付数据。沿用上例，获得分配支付数据70元，将70元按照业务对象支付方的数量进行拆分，获得至少一组拆分金额，一组为3份，即每个业务对象支付方对应一个拆分金额，该三份拆分金额之和等于所述分配支付数据，例如：随机获得3份随机分配支付数据分别为：20元、30元和20元。

所述根据每位业务对象支付方的随机分配支付数据和所述支付数据下限，分别确定每位业务对象支付方需要支付的待支付子数据，也就是，将随机分配支付数据分别加上支付数据下限即为待支付子数据，例如：将20元、30元和20元分别加上支付数据下限10元之后，分别为30元、40元和30元，三者为三个待支付子数据，该三个待支付子数据之和等于待支付总数据，将三个待支付子数据随机分配给三个业务对象支付方。

可以理解的是，上述实施例中以一组举例说明，实际上，所述随机分配支付数据可以多组，为两组时，两组之和应为所述分配支付数据。例如：第一组为：10元、15元、10元，第二组为10元、10元、15元，分配时可以先将第一组随机分配给所述业务对象支付方(本实施例中为3个)，在将最后一组随机分配支付数据分别加上支付数据下限，再随机分配给所述业务对象支付方，进而完成待支付总数据的分配。在多组组合情况下，所述支付下限可以在其中任意一组中加入，能够保证待支付子数据之和等于待支付总数据即可。当存在多组随机分配支付数据时，需要满足多组之和等于所述分配支付数据即可。所述支付数据下限并不代表限制随机分配支付数据需要大于或等于支付数据下限，例如：以两组举例，根据所述待支付总数据为100元，分配支付数据为70元，支付下限为10元/人，第一组随机分配支付数据可以是5元、20元和15元，第二组随机分配支付数据可以是20元、5元和5元，可以在所述第一组随机分配支付数据上分别加入所述支付数据下限，或者在所述第二组随机分配支付数据上分别加入所述支付数据下限。也就是说，所述支付数据下限并不限制随机支付数据的分配，而是在确定待支付子数据时，为保证出现不合理的分配金额而提供的一种方式，进而保证每个业务对象支付方的待支付子数据合理，差距不会太大。

实施例2：所述步骤S104的具体实现还可以采用如下方式：

所述根据所述待支付总数据、所述支付数据下限以及所述业务对象支付方，确定每位所述业务对象支付方需要支付的待支付子数据，包括：

根据所述待支付总数据、所述支付数据下限、所述业务对象支付方的数量以及已分配的第一随机支付数据，确定待分配支付数据。

判断所述待分配支付数据是否为最后一笔，若否，则在所述待分配支付数据中选取第二随机支付数据，根据所述第二随机支付数据和所述支付数据下限，确定所述待支付子数据，并跳转至所述确定待分配支付数据的步骤继续执行；若是，则将所述待分配支付数据和所述第一随机支付数据，确定为待支付子数据，并退出所述确定每位所述业务对象支付方需要支付的待支付子数据的步骤。

其中，所述根据所述待支付总数据、所述支付数据下限、所述业务对象支付方的数量以及已分配的第一随机支付数据，确定待分配支付数据可以采用如下公式获得：待分配支付数据＝(M-A)-N×min；其中，M为待支付总数据，N为业务对象支付方的数量，min为支付数据下限，A为已分配的第一随机支付数据。

需要说明的是，所述已分配的第一随机支付数据，在未存在任何分配情况下，已分配的第一随机支付数据为0(即初始随机支付数据)，当存在分配情况下，所述已分配的第一随机支付数据为所有已分配数据的和，例如：沿用上例，待支付总数据为100元，业务对象支付方的数量为3人，支付数据下限为10元/人，首次分配时，已分配的第一随机支付数据为0，根据上述公式可知，首次分配确定的待分配支付数据为(100-0)-3×10＝70元，70元为此次分配确定的待分配支付数据。如果不是首次分配，且已分配的第一随机支付数据为10元，根据上述公式可知，此次分配确定的待分配支付数据为(100-10)-3×10＝60元，60元为此次分配确定的待分配支付数据。如果已分配的第一随机支付数据有两笔分别为10和20元，则再次进行确定待分配支付数据时，所述待分配支付数据为(100-(10+20))-3×10＝40元，40元即为此次待分配支付数据。在确定待分配支付数据后，按照下述公式根据所述第二随机支付数据和所述支付数据下限，确定所述待支付子数据：待支付子数据＝Random((M-A)-N×min)+min；其中，Random((M-A)-N×min)为在((M-A)-N×min)中随机选取的第二随机支付数据。

需要说明的是，在实施例2中，所述待分配支付数据的次数根据业务对象支付方的数量进行确定，即如果业务对象支付方为3人，则确定待分配支付数据的次数为3次，可以理解的是，当确定待分配支付数据为最后一次时，无需在所述待分配支付数据中选择第二随机支付数据，直接将其与支付数据下限合并确定为最后一笔待支付子数据即可。因此，在确定待分配支付数据后需要对其进行判断，判断该笔确定的待分配支付数据是否为最后一笔。例如：待支付总数据为100元，业务对象支付方为3人，支付数据下限为10元/人；待分配支付数据＝(100-0)-3×10＝70元，并记录为第一笔待分配支付数据；判断70元的该笔待分配支付数据是否为最后一笔，具体判断可以是在每计算一次待支付子数据就记录一次，将其与业务对象支付方的数量进行比较，若相同则为最后一笔，若不同则需要执行待支付子数据的技术，具体记录形式不限。基于上述计算获得70元待分配支付数据，判断出其记录的待分配支付数据的笔数为1笔与人数3人不同，则继续执行如下内容：通过公式Random((M-A)-N×min)+min得到待支付子数据，即：70元中随机选取一个10元，10+10＝20元，20元为待支付子数据。循环所述待分配支付数据的确定步骤，即：待分配支付数据＝(100-10)-3×10＝60元，并记录为第二笔待分配支付数据，判断60元的该笔(第2笔)待分配支付数据的笔数与业务对象支付方的数量(3人)是否相同，得到比较结果为不同，则继续执行如下内容：通过公式Random((M-A)-N×min)+min得到待支付子数据，即：60元中随机选取一个30元，30+10＝40元，40元为待支付子数据。循环所述待分配支付数据的确定步骤，即：待分配支付数据＝(100-(30+10))-3×10＝30元，并记录为第三笔待分配支付数据，判断30元的该笔(第3笔)待分配支付数据的笔数与业务对象支付方的数量(3人)是否相同，得到比较结果为相同，则说明无需在循环，直接将待分配支付数据与支付数据下限之和确定为第3笔的待支付子数据即可，即：30+10＝40元。最后，获得三笔待支付子数据为：20元、40元和40元，三笔待支付子数据之和等于待支付总数据100元。如果业务对象支付方为4人，则可以继续循环至确定分配支付数据的步骤，直到业务对象支付方的人数与确定的待分配支付数据的笔数相同，停止确定待支付子数据的步骤，之后可以将确定的待支付子数据分发给业务对象支付方。

因此，本申请提供的支付数据的处理方法，还可以包括：将所述确定的待支付子数据分发给所述业务对象支付方。所述将所述确定的待支付子数据分发给所述业务对象支付方可以是：在为每位业务对象支付方确定待支付子数据后，同时随机分发给每位业务对象支付方，也可以每确定一笔待支付子数据后随机发送给所述业务对象支付方中的一位。将所述待支付子数据分发给所述业务对象支付方式不受上述限制，满足每位业务对象支付方对应具有一个待支付子数据即可。

需要说明的是，实施例2也可以在实施例1的基础实现，即所述将所述分配支付数据，按照所述业务对象支付方的数量进行随机分配，分别获得每位业务对象支付方的随机分配支付数据，包括：将所述分配支付数据，按照所述业务对象支付方的数量进行拆分，获得至少一组与所述业务对象支付方数量匹配的所述随机分配支付数据。其中拆分可以按照实施例2提供的公式完成。

以上是对本申请提供一种支付数据的处理方法实施例的说明，与前述支付数据的处理方法实施例相对应，本申请还公开一种支付数据的处理装置，请参看图2，由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。

获取单元201，用于获取针对业务对象的待支付总数据；以及

第一确定单元202，用于确定针对所述业务对象的业务对象支付方，其中，所述业务对象支付方至少包括两个；

第二确定单元203，用于确定所述业务对象支付方的支付数据下限；

第三确定单元204，用于根据所述待支付总数据、所述支付数据下限以及所述业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据；其中，所述待支付子数据之和等于所述待支付总数据。

本实施例中对于所述第三确定单元204提供两种实现方式，第一中实现方式包括：

分配支付数据确定子单元，用于根据所述支付数据下限和所述待支付总数据，确定分配支付数据；

获得子单元，用于将所述分配支付数据，按照所述业务对象支付方的数量进行随机分配，分别获得每位业务对象支付方的随机分配支付数据；

确定子单元，用于根据每位业务对象支付方的随机分配支付数据和所述支付数据下限，分别确定每位业务对象支付方需要支付的待支付子数据。

所述分配支付数据确定子单元包括：分配支付数据获取单元，用于将所述待支付总数据中扣除所述支付数据下限，获得所述分配支付数据；

所述获得子单元包括：拆分子单元，用于将所述分配支付数据，按照所述业务对象支付方的数量进行拆分，获得至少一组与所述业务对象支付方数量匹配的所述随机分配支付数据。

所述第三确定单元204的第二种实现方式，包括：

第一确定子单元，用于根据所述待支付总数据、所述支付数据下限、所述业务对象支付方的数量以及已分配的第一随机支付数据，确定待分配支付数据；

判断子单元，用于判断所述待分配支付数据是否为最后一笔，若否，则进入第二确定子单元；若是，则进入第三确定子单元；

所述第二确定子单元，用于在所述待分配支付数据中选取第二随机支付数据，根据所述第二随机支付数据和所述支付数据下限，确定所述待支付子数据，并跳转至所述第一确定子单元继续执行，即执行确定待分配支付数据的步骤；

所述第三确定子单元，用于将所述待分配支付数据和所述第一随机支付数据，确定为待支付子数据，并退出所述确定每位所述业务对象支付方需要支付的待支付子数据的步骤。

其中，第一确定子单元中根据所述待支付总数据、所述支付数据下限、所述业务对象支付方的数量以及已分配的第一随机支付数据，确定待分配支付数据可以采用如下公式获得：待分配支付数据＝(M-A)-N×min；其中，M为待支付总数据，N为业务对象支付方的数量，min为支付数据下限，A为已分配的第一随机支付数据。

所述第二确定子单元可以是在待分配支付数据＝(M-A)-N×min的公式中选取一个第二随机支付数据，即：Random((M-A)-N×min)。

所述第三确定子单元可以在确定待分配支付数据后，按照下述公式根据所述第二随机支付数据和所述支付数据下限，确定所述待支付子数据：待支付子数据＝Random((M-A)-N×min)+min。

所述第二确定单元具体采用如下至少一种方式，确定所述业务对象支付方的支付数据下限：

根据所述业务对象的地理位置信息，确定所述业务对象支付方的支付数据下限；

根据所述待支付总数据的信息，确定所述业务对象支付方的支付数据下限；

根据所述待支付总数据和业务对象支付方的数量，确定所述业务对象支付方的支付数据下限。

所述第一确定单元202包括：参与者确定子单元和/或邀请确定子单元；所述参与者确定子单元，用于根据选取所述业务对象信息的参与者，确定所述业务对象支付方；所述邀请确定子单元，用于根据针对所述业务对象发出邀请且对所述邀请成功响应的被邀请接收方，确定所述业务对象支付方。

本申请提供的一种支付数据的处理装置还可以包括：

发送单元，用于将所述确定的待支付子数据分发给所述业务对象支付方。所述发送单元可以是在为每位业务对象支付方确定待支付子数据后，同时随机分发给每位业务对象支付方，也可以每确定一笔待支付子数据后随机发送给所述业务对象支付方中的一位。将所述待支付子数据分发给所述业务对象支付方式不受上述限制，满足每位业务对象支付方对应具有一个待支付子数据即可。

以上是本申请提供的一种支付数据的处理方法和装置，相应的，本申请还提供一种支付数据的支付方法和装置，下面对本申请提供的一种支付数据的支付方法进行详细说明，实际上，该支付方法是基于支付数据的处理方法进行，因此，在相同描述的详细解释可以参考上述支付数据的处理方法。如图3所示，图3是本申请提供的一种支付数据的支付方法实施例的流程图，支付方法包括：

步骤S301：基于根据待支付总数据、支付数据下限以及业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据，接收业务对象支付方针对所述待支付子数据已支付的已支付子数据。

所述步骤S301中接收的是针对根据待支付总数据、支付数据下限以及业务对象支付方为每位业务对象支付方确定的待支付子数据，而支付的已支付子数据，例如：待支付总数据为100元，支付数据下限为10元/人，业务对象支付方的数量为3人，根据上述支付数据的处理方法中的实施例确定的待支付子数据分别为20元、40元和40元，将三个待支付子数据随机分发给业务对象支付方，接收针对待支付子数据进行支付的已支付子数据。

需要说明的是，所述接收业务对象支付方针对所述待支付子数据已支付的已支付子数据的接收方可以是终端设备的应用平台，终端设备可以是业务对象支付方的终端设备，也可以是业务对象提供方的终端设备，具体不做限制，能够满足接收针对待支付子数据进行支付的已支付子数据即可。

步骤S302：将所述已支付子数据发送至针对所述业务对象的业务对象提供方。所述步骤S302具体实现过程可以是：

接收每位所述业务对象支付方支付的所述已支付子数据；

将所述已支付子数据合并，获得合并后的总支付数据；

判断所述总支付数据是否等于针对所述业务对象的待支付总数据，若是，则将所述总支付数据发送给所述业务对象提供方。如果所述总支付数据不等于针对所述业务对象的待支付总数据，则向所述业务对象支付方发送提示信息。

其中所述提示信息可以包括至少以下一种信息：所述总支付数据与所述待支付总数据不匹配的信息；支付错误的信息；其中，支付错误的信息可以包括业务对象支付方的支付错误的信息，例如：哪位业务对象支付方支付出现错误，还可以包括错误的原因等。所述总支付数据与所述待支付总数据差值的信息。

步骤S303：调整针对所述业务对象的支付信息。所述步骤S303的具体实现过程可以是：将针对所述业务对象的支付状态从待支付状态调整为已支付状态，可以理解为支付完成，订单关闭的状态；和/或，调整所述业务对象的进度信息。所述调整所述业务对象的进度信息可以是针对业务对象的进度信息实时进行调整，例如：在支付完毕后，可将进度信息调整为支付完毕，服务进行中；对于餐饮行业，可以实时监测并调整菜品提供状态等等。

本申请提供的支付数据的支付方法，还包括：

步骤A：接收针对所述业务对象的支付请求；所述步骤A的支付请求中可以包括：业务对象支付方的信息、待支付总数据的信息、业务对象的信息等等，所述业务对象的信息可以包括：业务对象支付方所处的位置信息，例如：桌号、房间号等，以便对应该位置信息提供相应的业务对象服务。所述支付请求中的该些信息可以采用结构化的记录方式，记录在终端设备上，终端设备可以是业务对象支付方的终端设备，也可以是业务对象提供方的终端设备，也可以是第三方的终端设备，具体记录在何种介质没有具体限定。

步骤B：根据所述支付请求获取业务对象的待支付总数据；确定针对所述业务对象的业务对象支付方，其中，所述业务对象支付方至少包括两个；以及确定所述业务对象支付方的支付数据下限。

步骤C：根据所述待支付总数据、所述支付数据下限以及所述业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据；其中，所述待支付子数据之和等于所述待支付总数据。

步骤D：将确定的所述待支付子数据分别发送给所述业务对象支付方。其中，所述步骤B中的所述根据所述待支付总数据、所述支付数据下限以及所述业务对象支付方，分别为每位所述业务对象支付方确定需要支付的待支付子数据，包括：

根据所述支付数据下限和所述待支付总数据，确定分配支付数据；其中，所述分配支付数据的确定过程可以包括：将所述待支付总数据中扣除所述支付数据下限，获得所述分配支付数据。

将所述分配支付数据，按照所述业务对象支付方的数量进行随机分配，分别获得每位业务对象支付方的随机分配支付数据；其中，所述随机分配支付数据的获取可以包括：将所述分配支付数据，按照所述业务对象支付方的数量进行拆分，获得至少一组与所述业务对象支付方数量匹配的所述随机分配支付数据。

根据每位业务对象支付方的随机分配支付数据和所述支付数据下限，分别确定每位业务对象支付方需要支付的待支付子数据。

需要说明的是，关于确定待支付子数据的过程可以参考上述关于本申请提供的支付数据的处理方法的相关描述，此处不再赘述。

所述步骤B的另一种实现方式可以包括：根据所述待支付总数据、所述支付数据下限、所述业务对象支付方的数量以及已分配的第一随机支付数据，确定待分配支付数据；其中，待分配支付数据的确定可以采用如下公式：剩余待支付数据＝(M-A)-N×min；其中，M为待支付总数据，N为业务对象支付方的数量，min为支付数据下限，A为已分配的第一随机支付数据。

判断所述待分配支付数据是否为最后一笔，若否，则在所述待分配支付数据中选取第二随机支付数据，根据所述第二随机支付数据和所述支付数据下限，确定所述待支付子数据；若是，则将所述待分配支付数据和所述第一随机支付数据，确定为待支付子数据。其中，所述待支付子数据的确定可以采用如下公式获得：分配支付数据＝Random((M-A)-N×min)+min；其中，Random((M-A)-N×min)为在((M-A)-N×min)中随机选取的第二随机支付数据。

确定所述业务对象支付方的支付数据下限可以按照以下至少一种方式确定：根据所述业务对象的地理位置信息，确定所述业务对象支付方的支付数据下限；根据所述待支付总数据的信息，确定所述业务对象支付方的支付数据下限；根据所述待支付总数据和业务对象支付方的数量，确定所述业务对象支付方的支付数据下限。

对于支付数据下限的描述较为概括，具体可以参考上述支付数据的处理方法中的描述，此处不再赘述。

本申请提供的支付数据的支付方法，还可以包括输出至少以下一种信息：输出针对所述业务对象支付成功后的优惠信息；输出针对所述业务对象支付成功后的支付关闭信息；输出针对所述业务对象支付成功后的所述业务对象显示信息；输出针对所述业务对象支付成功后的已支付子数据退还信息。

以上是对本申请提供一种支付数据的支付方法实施例的说明，与前述支付数据的支付方法实施例相对应，本申请还公开一种支付数据的支付装置，请参看图4，由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。

如图4所示，图4是本申请提供的一种支付数据的支付装置实施例的流程图，包括：

接收单元401，用于基于根据待支付总数据、支付数据下限以及业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据，接收业务对象支付方针对所述待支付子数据已支付的已支付子数据。

发送单元402，用于将所述已支付子数据发送至针对所述业务对象的业务对象提供方。所述发送单元402，包括：接收子单元，用于接收每位所述业务对象支付方支付的所述已支付子数据；合并子单元，用于将所述已支付子数据合并，获得合并后的总支付数据；总数据判断子单元，用于判断所述总支付数据是否等于针对所述业务对象的待支付总数据，若是，则将所述总支付数据发送给所述业务对象提供方。

还包括：提示信息发送子单元，用于当所述总数据判断子单元判断结果为所述总支付数据不等于针对所述业务对象的待支付总数据，则向所述业务对象支付方发送提示信息。其中，所述提示信息发送子单元具体用于发送至少以下一种信息：所述总支付数据与所述待支付总数据不匹配的信息；支付错误的信息；所述总支付数据与所述待支付总数据差值的信息。

调整单元403，用于调整针对所述业务对象的支付信息。所述调整单元403包括：状态调整子单元和/或进度信息调整子单元；所述状态调整子单元，用于将针对所述业务对象的支付状态从待支付状态调整为已支付状态；所述进度信息调整子单元，用于调整所述业务对象的进度信息。

还包括：

支付请求接收单元，用于接收针对所述业务对象的支付请求；

第一确定单元，用于根据所述支付请求获取业务对象的待支付总数据；确定针对所述业务对象的业务对象支付方，其中，所述业务对象支付方至少包括两个；以及确定所述业务对象支付方的支付数据下限。所述第一确定单元具体按照以下至少一种方式确定所述业务对象支付方的支付数据下限：根据所述业务对象的地理位置信息，确定所述业务对象支付方的支付数据下限；根据所述待支付总数据的信息，确定所述业务对象支付方的支付数据下限；根据所述待支付总数据和业务对象支付方的数量，确定所述业务对象支付方的支付数据下限。

第二确定单元，用于根据所述待支付总数据、所述支付数据下限以及所述业务对象支付方，确定每位业务对象支付方需要支付的待支付子数据；其中，所述待支付子数据之和等于所述待支付总数据；其中，在第一种实施例中：所述第二确定单元包括：第一确定子单元，用于根据所述支付数据下限和所述待支付总数据，确定分配支付数据；所述第一确定子单元包括：扣除子单元，用于将所述待支付总数据中扣除所述支付数据下限，获得所述分配支付数据。获得子单元，用于将所述分配支付数据，按照所述业务对象支付方的数量进行随机分配，分别获得每位业务对象支付方的随机分配支付数据；所述获得子单元包括：拆分子单元，用于将所述分配支付数据，按照所述业务对象支付方的数量进行拆分，获得至少一组与所述业务对象支付方数量匹配的所述随机分配支付数据。第二确定子单元，用于根据每位业务对象支付方的随机分配支付数据和所述支付数据下限，分别确定每位业务对象支付方需要支付的待支付子数据。

所述第二确定单元在第二种实施例中包括：第一确定子单元，用于根据所述待支付总数据、所述支付数据下限、所述业务对象支付方的数量以及已分配的第一随机支付数据，确定待分配支付数据；判断子单元，用于判断所述待分配支付数据是否为最后一笔，若否，则进入第二确定子单元；若是，则进入第三确定子单元；所述第二确定子单元，用于在所述待分配支付数据中选取第二随机支付数据，根据所述第二随机支付数据和所述支付数据下限，确定所述待支付子数据；所述第三确定子单元，用于将所述待分配支付数据和所述第一随机支付数据，确定为待支付子数据。支付子数据发送单元，用于将确定的所述待支付子数据分别发送给所述业务对象支付方。

本申请提供的一种支付数据的支付装置，还包括：输出单元，所述输出单元输出至少以下一种信息：输出针对所述业务对象支付成功后的优惠信息；输出针对所述业务对象支付成功后的支付关闭信息；输出针对所述业务对象支付成功后的所述业务对象显示信息；输出针对所述业务对象支付成功后的已支付子数据退还信息。

以上是基于本申请提供的一种支付数据的支付方法所对应的支付数据的支付装置进行的概要阐述，由于该装置与支付方法相对应，具体详细描述可以参考支付方法中的描述即可，此处不再做过多的详细描述。

为了更好的了解本申请提供的支付数据的处理和支付方法，本申请还一种餐饮行业的支付方法，对支付方法进行进一步的阐述。具体请参考图5所示，图5本申请提供一种餐饮行业的支付方法的实施例流程图。

本申请提供的一种餐饮行业的支付方法，包括：

步骤S501：接收针对点餐业务的点餐请求，所述点餐请求中包括：餐品信息、餐品提供商家以及点餐者信息，其中，餐品信息包括餐品支付总金额，所述点餐者信息包括点餐者数量，且至少两个；在所述步骤S501中的点餐请求中餐品信息可以包括餐桌信息或者用餐房间信息等，所述点餐请求中的信息可以采用结构化的形式进行记录，以便餐品的提供以及支付总金额与餐品的对应，进而构成点餐的餐饮订单。所述步骤S501中接收针对点餐业务的点餐请求可以是通过点餐者的终端设备，例如：手机等智能移动终端，进行点餐并将点餐结果发送，也可以是通过所述商家提供的点餐终端设备进行，也可以是第三方提供的终端设备。点餐请求可以是多人进行点餐后汇总成一个点餐请求。

步骤S502：确定所述点餐者的支付金额下限；所述步骤S502中点餐者的支付金额下限可以是根据所述商家的地理位置信息，确定所述点餐者的支付金额下限；根据所述待支付总金额，确定所述点餐者的支付金额下限；根据所述待支付总金额和所述点餐者的数量，确定所述点餐者的支付金额下限。

步骤S503：根据所述点餐请求中的餐品支付总金额、所述点餐者数量以及所述支付金额下限，确定每位所述点餐者需要支付的支付子金额。所述步骤S503的具体实现过程与支付数据的处理和支付方法相似，参考上述描述即可，此处不再过多赘述。

步骤S504：将所述支付子金额发送给所述点餐者。

步骤S505：接收来自所述点餐者的所述支付子金额，并发送至所述餐品提供商家。所述步骤S505可以是将来自各个点餐者的支付子金额进行合并，获得合并后的总支付数据，将所述总支付数据发送给所述商家。商家在确认支付订单后可以进行关闭支付，或者支付成功等操作，当然还可以针对此次订单提供退款的信息。

需要说明的是，所述接收来自所述点餐者的所述支付子金额，可以在餐品提供之前完成，也可以在餐品提供过程中完成，也可以在就餐完毕后完成。

以上是对本申请提供一种餐饮行业的支付方法实施例的说明，与前述餐饮行业的支付方法实施例相对应，本申请还公开一种餐饮行业的支付装置，请参看图6，由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。

本申请提供一种餐饮行业的支付装置，包括：

接收单元601，用于接收针对点餐业务的点餐请求，所述点餐请求中包括：餐品信息、餐品提供方以及点餐者信息，其中，餐品信息包括餐品支付总金额，所述点餐者信息包括点餐者数量，且至少两个；

第一确定单元602，用于确定所述点餐者的支付金额下限；

第二确定单元603，用于根据所述点餐请求中的餐品支付总金额、所述点餐者数量以及所述支付金额下限，确定每位所述点餐者需要支付的支付子金额；

第一发送单元604，用于将所述支付子金额发送给所述点餐者；

第二发送单元605，用于接收来自所述点餐者的所述支付子金额，并发送至所述餐品提供方。

基于上述内容，本申请还提供一种电子设备，包括：处理器；存储器，用于存储对网络平台产生数据进行处理的程序，所述程序在被所述处理器读取执行时，执行如下操作：获取针对业务对象的待支付总数据；以及确定针对所述业务对象的业务对象支付方，其中，所述业务对象支付方至少包括两个；确定所述业务对象支付方的支付数据下限；根据所述待支付总数据、所述支付数据下限以及所述业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据；其中，所述待支付子数据之和等于所述待支付总数据。

基于上述内容，本申请还提供一种存储设备，存储网络平台产生数据，以及对应所述网络平台产生数据进行处理的程序；所述程序在被所述处理器读取执行时，执行如下操作：获取针对业务对象的待支付总数据；以及确定针对所述业务对象的业务对象支付方，其中，所述业务对象支付方至少包括两个；确定所述业务对象支付方的支付数据下限；根据所述待支付总数据、所述支付数据下限以及所述业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据；其中，所述待支付子数据之和等于所述待支付总数据。

基于上述内容，本申请还提供一种电子设备，包括：处理器；存储器，用于存储对网络平台产生数据进行处理的程序，所述程序在被所述处理器读取执行时，执行如下操作：基于根据待支付总数据、支付数据下限以及业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据，接收业务对象支付方针对所述待支付子数据已支付的已支付子数据；将所述已支付子数据发送至针对所述业务对象的业务对象提供方；调整针对所述业务对象的支付信息。

基于上述内容，本申请还提供一种存储设备，存储网络平台产生数据，以及对应所述网络平台产生数据进行处理的程序；所述程序在被所述处理器读取执行时，执行如下操作：基于根据待支付总数据、支付数据下限以及业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据，接收业务对象支付方针对所述待支付子数据已支付的已支付子数据；将已支付子数据发送至针对所述业务对象的业务对象提供方；调整针对所述业务对象的支付信息。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

1、计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

2、本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

Claims (10)

1.一种支付数据的处理方法，其特征在于，包括：

获取针对业务对象的待支付总数据；以及

确定针对所述业务对象的业务对象支付方，其中，所述业务对象支付方至少包括两个；

确定所述业务对象支付方的支付数据下限；

根据所述待支付总数据、所述支付数据下限以及所述业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据；其中，所述待支付子数据之和等于所述待支付总数据。

2.一种支付数据的支付方法，其特征在于，包括：

基于根据待支付总数据、支付数据下限以及业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据，接收业务对象支付方针对所述待支付子数据已支付的已支付子数据；

将所述已支付子数据发送至针对所述业务对象的业务对象提供方；

调整针对所述业务对象的支付信息。

3.一种餐饮行业的支付方法，其特征在于，包括：

接收针对点餐业务的点餐请求，所述点餐请求中包括：餐品信息、餐品提供商家以及点餐者信息，其中，餐品信息包括餐品支付总金额，所述点餐者信息包括点餐者数量，且至少两个；

确定所述点餐者的支付金额下限；

根据所述点餐请求中的餐品支付总金额、所述点餐者数量以及所述支付金额下限，确定每位所述点餐者需要支付的支付子金额；

将所述支付子金额发送给所述点餐者；

接收来自所述点餐者的所述支付子金额，并发送至所述餐品提供商家。

4.一种支付数据的处理装置，其特征在于，包括：

获取单元，用于获取针对业务对象的待支付总数据；以及

第一确定单元，用于确定针对所述业务对象的业务对象支付方，其中，所述业务对象支付方至少包括两个；

第二确定单元，用于确定所述业务对象支付方的支付数据下限；

第三确定单元，用于根据所述待支付总数据、所述支付数据下限以及所述业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据；其中，所述待支付子数据之和等于所述待支付总数据。

5.一种支付数据的支付装置，其特征在于，包括：

接收单元，用于基于根据待支付总数据、支付数据下限以及业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据，接收业务对象支付方针对所述待支付子数据已支付的已支付子数据；

发送单元，用于将所述已支付子数据发送至针对所述业务对象的业务对象提供方；

调整单元，用于调整针对所述业务对象的支付信息。

6.一种餐饮行业的支付装置，其特征在于，包括：

接收单元，用于接收针对点餐业务的点餐请求，所述点餐请求中包括：餐品信息、餐品提供方以及点餐者信息，其中，餐品信息包括餐品支付总金额，所述点餐者信息包括点餐者数量，且至少两个；

第一确定单元，用于确定所述点餐者的支付金额下限；

第二确定单元，用于根据所述点餐请求中的餐品支付总金额、所述点餐者数量以及所述支付金额下限，确定每位所述点餐者需要支付的支付子金额；

第一发送单元，用于将所述支付子金额发送给所述点餐者；

第二发送单元，用于接收来自所述点餐者的所述支付子金额，并发送至所述餐品提供方。

7.一种电子设备，其特征在于，包括：

处理器；

存储器，用于存储对网络平台产生数据进行处理的程序，所述程序在被所述处理器读取执行时，执行如下操作：

获取针对业务对象的待支付总数据；以及

确定针对所述业务对象的业务对象支付方，其中，所述业务对象支付方至少包括两个；

确定所述业务对象支付方的支付数据下限；

根据所述待支付总数据、所述支付数据下限以及所述业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据；其中，所述待支付子数据之和等于所述待支付总数据。

8.一种存储设备，其特征在于，存储网络平台产生数据，以及对应所述网络平台产生数据进行处理的程序；

所述程序在被所述处理器读取执行时，执行如下操作：

获取针对业务对象的待支付总数据；以及

确定针对所述业务对象的业务对象支付方，其中，所述业务对象支付方至少包括两个；

确定所述业务对象支付方的支付数据下限；

根据所述待支付总数据、所述支付数据下限以及所述业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据；其中，所述待支付子数据之和等于所述待支付总数据。

9.一种电子设备，其特征在于，包括：

处理器；

存储器，用于存储对网络平台产生数据进行处理的程序，所述程序在被所述处理器读取执行时，执行如下操作：

基于根据待支付总数据、支付数据下限以及业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据，接收业务对象支付方针对所述待支付子数据已支付的已支付子数据；

将所述已支付子数据发送至针对所述业务对象的业务对象提供方；

调整针对所述业务对象的支付信息。

10.一种存储设备，其特征在于，存储网络平台产生数据，以及对应所述网络平台产生数据进行处理的程序；

所述程序在被所述处理器读取执行时，执行如下操作：

基于根据待支付总数据、支付数据下限以及业务对象支付方，分别为每位业务对象支付方确定需要支付的待支付子数据，接收业务对象支付方针对所述待支付子数据已支付的已支付子数据；

将所述已支付子数据发送至针对所述业务对象的业务对象提供方；

调整针对所述业务对象的支付信息。