CN109493067A - 针对餐饮订单的支付方法及装置，存储介质和电子设备 - Google Patents

Abstract

本申请公开一种针对餐饮订单的支付方法及装置，计算机存储介质和电子设备，其中，所述支付方法包括：获取当前餐饮订单的支付数据；根据确定的针对所述当前餐饮订单支付方的信用评估数据，确定所述支付方的信用支付数据范围；根据所述信用支付数据范围，输出针对所述当前餐饮订单的支付数据的信用支付提醒。从而能够实现支付方进行信用支付，且信用该支付可以在支付方离开店铺之后进行，提高用餐和支付的便利性。

Description

针对餐饮订单的支付方法及装置，存储介质和电子设备

技术领域

本申请涉及计算机互联网应用领域，具体涉及一种针对餐饮订单的支付方法以及支付装置，计算机存储介质和电子设备。

背景技术

传统餐饮行业，需要用户针对餐饮订单的支付金额采用现金支付方式完成支付。随着计算机互联网技术的不断发展，支付方式不仅可以通过现金支付还可以通过电子终端设备完成支付。

现有技术中通过电子终端设备对餐饮订单进行支付时，通常情况下是在电子终端设备上输入服务员提供的支付金额，通过支付平台完成支付或者是直接通过电子终端设备上提供的支付金额完成相应的支付操作。

现有技术中提供的支付方式，均存在以下缺点：

1、需要用户针对当前餐饮订单所产生的支付金额必须及时完成支付；

2、通过电子终端设备上提供支付平台的支付操作提示一步步完成支付，操作过程较为繁琐；

3、通过电子终端设备进行支付时，如果用户电子终端设备中的现有支付金额不足时无法完成针对此次餐饮订单的线上支付，还需改变支付方式或至通过其他方式转入金额方能完成，造成支付不便。

发明内容

本申请提供一种针对餐饮订单的支付方法，以解决现有技术中在针对餐饮订单进行支付时造成的支付不便的问题。

本申请提供一种针对餐饮订单的支付方法，包括：

获取当前餐饮订单的支付数据；

根据确定的针对所述当前餐饮订单支付方的信用评估数据，确定所述支付方的信用支付数据范围；

根据所述信用支付数据范围，输出针对所述当前餐饮订单的支付数据的信用支付提醒。

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

根据设定的信用评估项目，确定针对所述当前餐饮订单支付方的信用评估数据。

在一些实施例中，所述信用评估项目至少包括如下一种：

餐饮行业黑名单评估项目；

所述支付方的资产评估项目；

所述支付方的负面信息评估项目；

所述支付方的信息验证评估项目；

所述支付方的信用指数评估项目；

所述支付方的历史用餐评估项目；

所述支付方的历史付款评估项目。

在一些实施例中，所述根据设定的信用评估方式，确定针对所述当前餐饮订单支付方的信用评估数据，包括：

当所述评估项目为一个时，根据所述评估项目的评估值，确定针对所述当前餐饮订单支付方的信用评估数据；

当所述评估项目为两个或两个以上时，根据参与评估的所述评估项目的平均评估值，确定针对所述当前餐饮订单支付方的信用评估数据。

在一些实施例中，所述根据确定的针对所述当前餐饮订单支付方的信用评估数据，确定所述支付方的信用支付数据范围，包括：

根据所述信用评估数据建立评估等级；

针对所述评估等级设定对应的信用支付数据范围。

在一些实施例中，所述根据所述信用支付数据范围，输出针对所述当前餐饮订单的信用支付提醒信息：

判断所述当前餐饮订单的支付数据是否在所述信用支付数据范围内，若是，则输出针对所述当前餐饮订单的信用支付提醒。

在一些实施例中，所述根据所述信用支付数据范围，输出针对所述当前餐饮订单的信用支付提醒信息，包括：

判断所述当前餐饮订单的支付数据是否在所述信用支付数据范围内，若否，则输出针对所述当前餐饮订单不支持信用支付的提醒。

在一些实施例中，所述输出针对所述当前餐饮订单的信用支付提醒至少包括如下一种提醒信息：

针对所述当前餐饮订单的信用支付的确认提醒信息；

针对所述当前餐饮订单的信用支付的支付时间提醒信息；

针对所述当前餐饮订单的信用支付的还款时间提醒信息；

针对所述当前餐饮订单支付方的信用支付数据范围的支付上限提醒信息。

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

根据所述输出针对所述当前餐饮订单的信用支付提醒，发送针对所述当前餐饮订单支付数据的信用代扣请求。

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

获得针对所述输出针对所述当前餐饮订单的信用支付提醒的响应；

所述发送针对所述当前餐饮订单支付数据的信用代扣请求包括：

根据所述响应，发送针对所述当前餐饮订单支付数据的信用代扣请求。

在一些实施例中，所述根据所述响应，发送针对所述当前餐饮订单支付数据的信用代扣请求，包括：

判断所述支付方是否离开产生所述当前餐饮订单的位置，若是，则发送针对所述当前餐饮订单支付数据的信用代扣请求。

在一些实施例中，还包括：对所述当前餐饮订单的支付方进行身份认证；

所述根据确定的针对所述当前餐饮订单支付方的信用评估数据，确定所述支付方的信用支付数据范围，包括：

根据所述身份认证结果以及确定的针对所述当前餐饮订单支付方的信用评估数据，确定所述支付方的信用支付数据范围。

在一些实施例中，所述对所述当前餐饮订单的支付方进行身份认证至少包括以下一种方式：

对所述支付方联系方式信息的认证；

对所述支付方常驻地址信息的认证；

对所述支付方生物特征信息的认证。

本申请还提供针对餐饮订单的支付装置，包括：

获取单元，用于获取当前餐饮订单的支付数据；

确定单元，用于根据确定的针对所述当前餐饮订单支付方的信用评估数据，确定所述支付方的信用支付数据范围；

输出单元，用于根据所述信用支付数据范围，输出针对所述当前餐饮订单的支付数据的信用支付提醒。

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

评估数据确定单元，用于根据设定的信用评估项目，确定针对所述当前餐饮订单支付方的信用评估数据。

在一些实施例中，所述信用评估方式中至少包括如下一种评估项目：

餐饮行业黑名单评估项目；

所述支付方的资产评估项目；

所述支付方的负面信息评估项目；

所述支付方的信息验证评估项目；

所述支付方的信用指数评估项目；

所述支付方的历史用餐评估项目；

所述支付方的历史付款评估项目。

在一些实施例中，所述评述数据确定单元具体用于：

当所述评估项目为一个时，根据所述评估项目的评估值，确定针对所述当前餐饮订单支付方的信用评估数据；

当所述评估项目为两个或两个以上时，根据参与评估的所述评估项目的平均评估值，确定针对所述当前餐饮订单支付方的信用评估数据。

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

评估等级建立子单元，用于根据所述信用评估数据建立评估等级；

所述确定单元具体用于针对所述评估等级建立单元中建立的所述评估等级设定对应的信用支付数据范围。

在一些实施例中，所述输出单元，包括：

第一判断子单元，用于判断所述当前餐饮订单的支付数据是否在所述信用支付数据范围内，若是，则输出针对所述当前餐饮订单的信用支付提醒。

在一些实施例中，所述输出单元，包括：

第二判断子单元，判断所述当前餐饮订单的支付数据是否在所述信用支付数据范围内，若否，则输出针对所述当前餐饮订单不支持信用支付的提醒。

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

针对所述当前餐饮订单的信用支付的确认提醒信息；

针对所述当前餐饮订单的信用支付的支付时间提醒信息；

针对所述当前餐饮订单支付方的信用支付数据范围的支付上限提醒信息。

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

代扣请求发送单元，用于根据所述输出针对所述当前餐饮订单的信用支付提醒，发送针对所述当前餐饮订单支付数据的信用代扣请求。

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

响应获得单元，用于获得针对所述输出针对所述当前餐饮订单的信用支付提醒的响应；

所述代扣请求发送单元具体用于根据所述响应，发送针对所述当前餐饮订单支付数据的信用代扣请求。

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

位置判断子单元，用于判断所述支付方是否离开产生所述当前餐饮订单的位置，若是，则执行所述发送针对所述当前餐饮订单支付数据的信用代扣请求。

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

身份认证单元，用于对所述当前餐饮订单的支付方进行身份认证；

所述确定单元具体用于根据所述身份认证结果以及确定的针对所述当前餐饮订单支付方的信用评估数据，确定所述支付方的信用支付数据范围。

在一些实施例中，所述身份认证单元至少包括以下一种方式：

对所述支付方联系方式信息的认证；

对所述支付方常驻地址信息的认证；

对所述支付方生物特征信息的认证。

本申请还提供一种计算机存储介质，用于存储网络平台产生数据，以及对应所述网络平台产生数据进行处理的程序；

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

获取当前餐饮订单的支付数据；

根据确定的针对所述当前餐饮订单支付方的信用评估数据，确定所述支付方的信用支付数据范围；

根据所述信用支付数据范围，输出针对所述当前餐饮订单的信用支付提醒。

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

处理器；

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

获取当前餐饮订单的支付数据；

根据确定的针对所述当前餐饮订单支付方的信用评估数据，确定所述支付方的信用支付数据范围；

根据所述信用支付数据范围，输出针对所述当前餐饮订单的信用支付提醒。

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

本申请提供的针对餐饮订单的支付方法，通过获取当前餐饮订单的支付数据，根据确定的针对所述当前餐饮订单支付方的信用评估数据，确定所述支付方的信用支付数据范围，根据所述信用支付数据范围，输出针对所述当前餐饮订单的支付数据的信用支付提醒；从而能够实现支付方进行信用支付，且信用该支付可以在支付方离开店铺之后进行，提高支付的便利性。

附图说明

图1是本申请提供的一种针对餐饮订单的支付方法实施例的流程图；

图2是本申请提供的一种针对餐饮订单的支付方法中信用评估数据确定过程的交互示意图；

图3是本申请提供的一种针对餐饮订单的支付方法中信用支付过程的交互示意图；

图4是本申请提供的一种针对餐饮订单的支付装置实施例的结构示意图。

具体实施方式

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

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

请参考图1所示，图1是本申请提供的一种针对餐饮订单的支付方法实施例的流程图。该针对餐饮订单的支付方法包括：

步骤S101：获取当前餐饮订单的支付数据。

所述步骤S101获取当前餐饮订单的支付数据具体可以是指，顾客在餐饮的店铺进行消费时产生的餐饮订单作为当前餐饮订单，所述当前餐饮订单可以是通过点餐平台完成，例如：顾客通过第三方应用平台或者商家自身的应用平台进行点餐，通过点餐平台获取当前餐饮订单的支付数据。所述第三方应用平台可以是安装在所述顾客移动终端设备上的应用软件，或者是安装在所述商家终端设备上的应用软件，或者是商家自身在其终端设备上安装的用于进行点餐服务的应用软件。

以上是对所述当前餐饮订单的产生以及获取进行说明，可以理解的是，所述当前餐饮订单产生以及获取不仅仅可以通过上述内容中通过线上的第三方应用平台或商家自身的应用平台，还可以在线下产生，通过线上获取，例如：顾客在餐饮的店铺进行消费时产生的餐饮订单可以是根据商家提供的线下餐饮食谱的选择而产生，再通过线上的应用平台将产生的餐饮订单进行上传，该上传可以是手动输入，也可以是自动产生(例如：扫描已选择餐饮信息)。换言之，所述当前餐饮订单的产生可以是线下或线上产生，所述当前餐饮订单的支付数据可以通过线上的应用平台进行发送或者是获取。

在本实施例中，所述支付数据可以包括：针对所述当前餐饮订单的支付金额，当然，还可以包括如下至少一种数据；

所述当前餐饮订单的顾客数据，例如：顾客的识别数据；

所述当前餐饮订单的餐饮明细，例如：餐饮名称；

所述当前餐饮订单产生的桌号数据。

以上仅为所述支付数据的举例说明，实际上，所述支付数据所涵盖的数据内容可以根据实际需要进行调整，并不限于上述数据内容。

步骤S102：根据确定的针对所述当前餐饮订单支付方的信用评估数据，确定所述支付方的信用支付数据范围。

首先，对于所述步骤S102中涉及的一些词语进行解释，所述信用评估数据可以是指所述当前餐饮订单支付方其对于商家而言的可信度。

所述支付方可以是指，针对所述当前餐饮订单承担订单金额支付的一方，可以是当前餐饮订单的享用者，也可以是第三方。

所述信用支付数据范围可以是指当前餐饮订单支付方根据自身所具有的通过第三方代付平台为当前餐饮订单进行支付的范围。顾客无需通过电子终端设备绑定银行卡或在支付应用软件中存储金额款项等方式进行线上支付，信用支付数据可以通过第三方代付平台对当前餐饮订单进行代付，代付后，顾客在设定的期限内进行还款即可。

请结合图1参考图2所示，图2是本申请提供的一种针对餐饮订单的支付方法中信用评估数据确定过程的交互示意图。

在所述步骤S102中，所述确定所述支付方的信用支付数据范围是需要根据所述当前餐饮订单支付方的信用评估数据实现，因此，可以理解的是，在本实施例中，还需要确定当前餐饮订单支付方的信用评估数据，而当前餐饮订单支付方的信用评估数据可以通过当前餐饮订单的支付数据进行分析，所以还可以包括：

根据设定的信用评估项目，确定针对所述当前餐饮订单支付方的信用评估数据。该确定的过程可以通过信用评估平台完成。

其中，所述信用评估项目至少包括如下一种：

餐饮行业黑名单评估项目；所述餐饮行业黑名单可以是指在餐饮行业中以例如以推荐产品为目的的消费可以被列入黑名单，也可以是对餐饮行业中行业关注的黑名单数据。

所述支付方的资产评估项目；

所述支付方的负面信息评估项目；所述负面信息可以是指在餐饮行业或与餐饮行业有关联关系的行业中是否有差评和/或中评的评论信息，所述关联关系的行业可以包括如下至少一种：休闲娱乐行业、交通行业、旅游行业等等。

所述支付方的信息验证评估项目；

所述支付方的信用指数评估项目；所述信用指数评述项目可以是在其他行业中是否按期支付或按期支付超期的时间长度等。

所述支付方的历史用餐评估项目；即：用户在餐饮行业中历史用餐的情况信息。

所述支付方的历史付款评估项目；即：用户在餐饮行业中历史用餐的付款情况信息。

上述评估项目的数据信息可以通过获取的当前餐饮订单的支付数据获得，在所述步骤S101中描述了支付数据包括的数据内容，因此，根据当前餐饮订单的支付数据可以得到当前餐饮订单的支付方的其他数据信息，其他数据信息的获得可以通过支付方的历史行为数据等获得，此处不再一一赘述。

在根据上述评估项目确定针对所述当前餐饮订单支付方的信用评估数据时，可以包括：

当所述评估项目为一个时，根据所述评估项目的评估值，确定针对所述当前餐饮订单支付方的信用评估数据；即：将所述评估项目的评估值确定为信用评估数据。

当所述评估项目为两个或两个以上时，根据参与评估的所述评估项目的平均评估值，确定针对所述当前餐饮订单支付方的信用评估数据；即：选取多个评估项目的平均值，作为评估值，确定所述信用评估数据。

根据评估项目确定所述信用评估数据时，存在多个评估值不同的信用评估数据，因此，所述根据确定的针对所述当前餐饮订单支付方的信用评估数据，确定所述支付方的信用支付数据范围，包括：

根据所述信用评估数据建立评估等级；

针对所述评估等级设定对应的信用支付数据范围。

例如：信用评估数据在0-2之间对应评估等级为一级；信用评估数据在3-5之间对应评估等级为二级；信用评估数据在6-8之间对应评估等级为三级，信用评估数据在9-10之间对应评估等级为四级，即信用评估数据越大，评估等级也越高，支付方的信用度越高。

在本实施例中，对应不同的评估等级设定不同的信用支付数据范围，例如：一级对应的信用支付数据范围可以是信用支付数据上限为100元，二级对应的信用支付数据范围可以是信用支付数据上限为200元，三级对应的信用支付数据范围可以是信用支付数据上限为300元，四级对应的信用支付数据范围可以是信用支付数据上限为400元，因为信用支付数据范围可以通过设定信用支付数据的上限即可，即支付方拥有的信用支付额度为信用支付数据上限，无需考虑信用支付数据的下限。

可以理解的是，在本实施例中，采用信用支付数据上限来确定信用支付数据的范围，实际上，也可以设定信用支付数据的下限进一步确定支付方是否可以通过信用支付对当前餐饮订单进行信用支付，即：所述当前订单在满足信用支付数据的下限时，可以通过信用支付对该笔当前餐饮订单进行支付。由于该内容不作为本申请的重点，因此，此处仅为笼统介绍。

以上介绍了针对信用评估方式，确定支付方具有的信用评估数据，即：针对支付方的历史行为数据等信息，确定信用评估数据。

可以理解的是，为了根据有针对性，保证支付数据的安全性以及降低支付的风险，在本实施例中，所述根据确定的针对所述当前餐饮订单支付方的信用评估数据，确定所述支付方的信用支付数据范围，还可以在基于上述确定过程中，将所述当前餐饮订单的支付数据作为信用支付数据范围确定的一个考虑参数，换个角度来说，所述信用支付数据的范围根据每次餐饮订单的支付数据不同而不同，当餐饮订单的支付金额为500元时，可以通过上述方式将信用支付数据范围的上限确定为500元，进而使得信用支付数据范围更贴合用户当前消费的情况，降低支付风险。该过程可以无需考虑评估等级，仅需要根据信用评估数据结合当前餐饮订单的支付数据进行确定信用支付数据范围的上限即可。

为降低支付风险，本申请在确定所述支付方的信用支付数据范围之前，还可以包括：

对所述当前餐饮订单的支付方进行身份认证；

所述根据确定的针对所述当前餐饮订单支付方的信用评估数据，确定所述支付方的信用支付数据范围，包括：

根据所述身份认证结果以及确定的针对所述当前餐饮订单支付方的信用评估数据，确定所述支付方的信用支付数据范围。

其中，所述对所述当前餐饮订单的支付方进行身份认证至少包括以下一种方式：

对所述支付方联系方式信息的认证；

对所述支付方常驻地址信息的认证；

对所述支付方生物特征信息的认证。

在本实施例中，通过对支付方进行身份认证，进一步确保支付的安全性，降低支付风险。

步骤S103：根据所述信用支付数据范围，输出针对所述当前餐饮订单的支付数据的信用支付提醒。

所述步骤S103的具体实现过程可以包括：

判断所述当前餐饮订单的支付数据是否在所述信用支付数据范围内，若是，则输出针对所述当前餐饮订单的信用支付提醒。

具体地，可以通过将所述当前餐饮订单的支付金额与所述信用支付数据范围的支付上限进行比较，若当前餐饮订单的支付金额小于或等于所述信用支付数据范围的支付上限，则说明可以通过信用支付平台针对当前餐饮订单的支付金额进行代扣或代扣，无需顾客通过自身支付账户中扣款。

本实施例中，输出针对所述当前订单的信用支付提醒至少可以包括如下一种提醒信息：

针对所述当前餐饮订单的信用支付的确认提醒信息；

例如：输出针对所述当前餐饮订单是否进行信用支付的操作界面，当选择是时，则所述当前餐饮订单则通过信用支付平台进行代扣，无需通过支付方的私人账户中扣除，具体可以是，当顾客针对确认提醒信息进行操作后跳转到代扣界面完成针对所述当前餐饮订单的支付金额的代扣。

针对所述当前餐饮订单的信用支付的支付时间提醒信息；

可以理解为，针对所述当前餐饮订单的支付金额通过信用支付平台进行代扣的时间范围，例如：在用餐完毕后的3小时之内或一天之内进行代扣等等。

针对所述当前餐饮订单的信用支付的还款时间提醒信息；例如：信用支付平台针对当前餐饮订单的支付金额进行代扣，将代扣金额的还款时间输出，以便用户了解还款期限避免延误造成不必要的损失。

针对所述当前餐饮订单支付方的信用支付数据范围的支付上限提醒信息；

可以理解为告知支付方其具有的信用支付数据范围的最高额度。

基于上述，当判断所述当前餐饮订单的支付数据是否在所述信用支付数据范围内，若否，则输出针对所述当前餐饮订单不支持信用支付的提醒。

具体地，如果比较结果不符合小于或等于信用指数数据范围的支付上限要求时，则可以输出针对所述当前餐饮订单不支持信用支付的提醒，进而告知支付方针对该笔当前餐饮订单不支持信用支付。

所述输出针对所述当前餐饮订单不支持信用支付的提醒可以包括至少如下一种提醒信息：

针对所述当前餐饮订单的不支持信用支付原因的提醒信息；

针对所述当前餐饮订单的不支持信用支付的解决方案的提醒信息。

可以理解的是，当所述当前餐饮订单的支付数据不在所述信用支付数据范围内，即：当前餐饮订单的支付金额大于信用支付数据范围的支付上限时，则也可以不做任何处理，支付方不能够通过信用支付平台针对当前餐饮订单的支付金额进行代付，仅能够通过自身账户进行线上支付，或者通过现金形式进行线下支付。

请参考图1结合图2和图3所示，图3是本申请提供的一种针对餐饮订单的支付方法中信用支付过程的交互示意图。

在本实施例中，还可以包括：

根据所述输出针对所述当前餐饮订单的信用支付提醒，发送针对所述当前餐饮订单支付数据的信用代扣请求，所述信用代扣请求可以是通过电子终端设备向所述代扣平台发出，或者是信用支付平台向所述代扣平台发出。其中，所述电子终端设备也可以理解为点餐平台，即可是顾客自己的移动终端设备，也可以是商家的电子终端设备。所述代扣平台在接收到代扣请求后针对所述当前餐饮订单进行代扣相应订单支付金额的操作。

所述代扣请求可以是在输出针对所述当前餐饮订单的信用支付提醒时，根据对所述信用支付提醒的响应进行发送，因此，还可以包括：

获得针对所述输出针对所述当前餐饮订单的信用支付提醒的响应；

所述发送针对所述当前餐饮订单支付数据的信用代扣请求包括：

根据所述响应，发送针对所述当前餐饮订单支付数据的信用代扣请求。

例如：信用支付提醒可以是“请确认是否进行信用支付代扣”的提醒，根据该提醒，顾客可以进行响应操作，若顾客针对该提醒选择为确认的响应，即进行信用支付代扣，则根据该确认信用支付代扣的响应，发送针对所述当前餐饮订单支付数据的信用代扣请求。如果顾客针对该提醒选择的取消响应，即不进行信用支付代扣，则无需针对所述当前餐饮订单支付数据发送信用代扣请求。

在本实施例中，信用代扣请求可以根据设定的发送条件进行发送，所述发送条件可以包括：位置条件和/或时间条件。

具体地，当发送条件为位置条件时，可以通过判断所述支付方是否离开产生所述当前餐饮订单的位置，若是，则发送针对所述当前餐饮订单支付数据的信用代扣请求。例如，当顾客离开所述当前餐饮订餐产生的商家店铺的位置后，将针对所述当前餐饮订单所需要代扣的支付金额进行发送。更进一步的，可以设定离开所述当前餐饮订单产生的商家店铺的距离，例如：大于等于200米时，则确定为顾客已离开所述商家店铺。

当发送条件为时间条件时，可以根据所述获取当前餐饮订单的支付数据中餐饮提供完成的时间点开始计时，之后判断所述计时时间是否大于设定的时间阈值，若满足则发送针对所述当前餐饮订单支付数据的信用代扣请求。所述时间阈值可以是根据餐饮的用时时间设定，更进一步的可以根据不同的餐饮订单中餐饮类型进行设定，例如：餐饮类型为火锅则时间阈值可以设定为3小时，如果餐饮类型为快餐则可以将时间阈值设定为1小时。例如：当餐饮提供完毕时间为18：30，则从18：30开始计时，当到21：00时，计时时间为2小时30分，如果设定的时间阈值为2小时，则此时判断计时时间已满足设定的时间阈值，可以发送针对所述当前餐饮订单支付数据的信用代扣请求，可以理解的是，判断可以实时进行。

通过设定的发送条件，可以使得顾客根据自身信用评估情况实现餐后付费的支付方式，即顾客离开商家店铺后在设定的条件下进行自动支付；进而实现离店后付，提高顾客的用餐便利性。

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

如图4所示，图4是本申请提供的一种针对餐饮订单的支付装置实施例的结构示意图，该支付装置包括：

获取单元401，用于获取当前餐饮订单的支付数据。

所述获取单元401所获取的所述当前餐饮订单的支付数据具体可以是指，顾客在餐饮的店铺进行消费时产生的餐饮订单作为当前餐饮订单，所述当前餐饮订单可以是通过点餐平台完成，例如：顾客通过第三方应用平台或者商家自身的应用平台进行点餐，通过点餐平台获取当前餐饮订单的支付数据。所述第三方应用平台可以是安装在所述顾客移动终端设备上的应用软件，或者是安装在所述商家终端设备上的应用软件，或者是商家自身在其终端设备上安装的用于进行点餐服务的应用软件。

以上是对所述当前餐饮订单的产生以及获取进行说明，可以理解的是，所述当前餐饮订单产生以及获取不仅仅可以通过上述内容中通过线上的第三方应用平台或商家自身的应用平台，还可以在线下产生，通过线上获取，例如：顾客在餐饮的店铺进行消费时产生的餐饮订单可以是根据商家提供的线下餐饮食谱的选择而产生，再通过线上的应用平台将产生的餐饮订单进行上传，该上传可以是手动输入，也可以是自动产生(例如：扫描已选择餐饮信息)。换言之，所述当前餐饮订单的产生可以是线下或线上产生，所述当前餐饮订单的支付数据可以通过线上的应用平台进行发送或者是获取。

在本实施例中，所述支付数据可以包括：针对所述当前餐饮订单的支付金额，当然，还可以包括如下至少一种数据；

所述当前餐饮订单的顾客数据，例如：顾客的识别数据；

所述当前餐饮订单的餐饮明细，例如：餐饮名称；

所述当前餐饮订单产生的桌号数据。

以上仅为所述支付数据的举例说明，实际上，所述支付数据所涵盖的数据内容可以根据实际需要进行调整，并不限于上述数据内容。

确定单元402，用于根据确定的针对所述当前餐饮订单支付方的信用评估数据，确定所述支付方的信用支付数据范围。

所述确定单元402中所述信用评估数据可以是指所述当前餐饮订单支付方其对于商家而言的可信度。

所述支付方可以是指，针对所述当前餐饮订单承担订单金额支付的一方，可以是当前餐饮订单的享用者，也可以是第三方。

所述信用支付数据范围可以是指当前餐饮订单支付方根据自身所具有的通过第三方代付平台为当前餐饮订单进行支付的范围。顾客无需通过电子终端设备绑定银行卡或在支付应用软件中存储金额款项等方式进行线上支付，信用支付数据可以通过第三方代付平台对当前餐饮订单进行代付，代付后，顾客在设定的期限内进行还款即可。

所述确定单元402中确定所述支付方的信用支付数据范围是需要根据所述当前餐饮订单支付方的信用评估数据实现，因此，在本实施例中，还需要确定当前餐饮订单支付方的信用评估数据，而当前餐饮订单支付方的信用评估数据可以通过当前餐饮订单的支付数据进行分析，所以，还可以包括：

评估数据确定单元，用于根据设定的信用评估项目，确定针对所述当前餐饮订单支付方的信用评估数据。

所述评估数据确定单元采用至少如下一种评估项目，确定针对所述当前餐饮订单支付方的信用评估数据，评估项目包括：

餐饮行业黑名单评估项目；所述餐饮行业黑名单可以是指在餐饮行业中以例如以推荐产品为目的的消费可以被列入黑名单，也可以是对餐饮行业中行业关注的黑名单数据。

所述支付方的资产评估项目；

所述支付方的负面信息评估项目；所述负面信息可以是指在餐饮行业或与餐饮行业有关联关系的行业中是否有差评和/或中评的评论信息，所述关联关系的行业可以包括如下至少一种：休闲娱乐行业、交通行业、旅游行业等等。

所述支付方的信息验证评估项目；

所述支付方的信用指数评估项目；所述信用指数评述项目可以是在其他行业中是否按期支付或按期支付超期的时间长度等。

所述支付方的历史用餐评估项目；即：用户在餐饮行业中历史用餐的情况信息。

所述支付方的历史付款评估项目；即：用户在餐饮行业中历史用餐的付款情况信息。

上述评估项目的数据信息可以通过获取的当前餐饮订单的支付数据获得，在所述获取单元401中描述了支付数据包括的数据内容，因此，根据当前餐饮订单的支付数据可以得到当前餐饮订单的支付方的其他数据信息，其他数据信息的获得可以通过支付方的历史行为数据等获得，此处不再一一赘述。

根据上述内容可理解，所述评估项目可以以一个为准，也可以以多个为准，因此，在本实施例中，给出评估项目为一个时当前餐饮订单支付方的信用评估数据的确定方式，以及评估项目为多个时当前餐饮订单支付方的信用评估数据的确定方式，具体如下：

当所述评估项目为一个时，根据所述评估项目的评估值，确定针对所述当前餐饮订单支付方的信用评估数据；即：将所述评估项目的评估值确定为信用评估数据。

当所述评估项目为两个或两个以上时，根据参与评估的所述评估项目的平均评估值，确定针对所述当前餐饮订单支付方的信用评估数据；即：选取多个评估项目的平均值，作为评估值，确定所述信用评估数据。

可以理解的是，通过上述其中一个评估项目即可确定当前餐饮订单支付方的信用评估数据，为了更全面和更准确的确定所述当前餐饮订单支付方的信用评述数据，所述评估项目可以选取多个。

根据评估项目确定所述信用评估数据时，存在多个评估值不同的信用评估数据，因此，所述根据确定的针对所述当前餐饮订单支付方的信用评估数据，确定所述支付方的信用支付数据范围，包括：

评估等级建立子单元，用于根据所述信用评估数据建立评估等级；

所述确定单元402具体用于针对所述评估等级设定对应的信用支付数据范围。

例如：信用评估数据在0-2之间对应评估等级为一级；信用评估数据在3-5之间对应评估等级为二级；信用评估数据在6-8之间对应评估等级为三级，信用评估数据在9-10之间对应评估等级为四级，即信用评估数据越大，评估等级也越高，支付方的信用度越高。

在本实施例中，对应不同的评估等级设定不同的信用支付数据范围，例如：一级对应的信用支付数据范围可以是信用支付数据上限为100元，二级对应的信用支付数据范围可以是信用支付数据上限为200元，三级对应的信用支付数据范围可以是信用支付数据上限为300元，四级对应的信用支付数据范围可以是信用支付数据上限为400元，因为信用支付数据范围可以通过设定信用支付数据的上限即可，即支付方拥有的信用支付额度为信用支付数据上限，无需考虑信用支付数据的下限。

可以理解的是，在本实施例中，采用信用支付数据上限来确定信用支付数据的范围，实际上，也可以设定信用支付数据的下限进一步确定支付方是否可以通过信用支付对当前餐饮订单进行信用支付，即：所述当前订单在满足信用支付数据的下限时，可以通过信用支付对该笔当前餐饮订单进行支付。由于该内容不作为本申请的重点，因此，此处仅为笼统介绍。

以上介绍了针对信用评估方式，确定支付方具有的信用评估数据，即：针对支付方的历史行为数据等信息，确定信用评估数据。

可以理解的是，为了根据有针对性，保证支付数据的安全性以及降低支付的风险，在本实施例中，所述根据确定的针对所述当前餐饮订单支付方的信用评估数据，确定所述支付方的信用支付数据范围，还可以在基于上述确定过程中，将所述当前餐饮订单的支付数据作为信用支付数据范围确定的一个考虑参数，换个角度来说，所述信用支付数据的范围根据每次餐饮订单的支付数据不同而不同，当餐饮订单的支付金额为500元时，可以通过上述方式将信用支付数据范围的上限确定为500元，进而使得信用支付数据范围更贴合用户当前消费的情况，降低支付风险。该过程可以无需考虑评估等级，仅需要根据信用评估数据结合当前餐饮订单的支付数据进行确定信用支付数据范围的上限即可。

为降低支付风险，还可以包括：

身份认证单元，用于对所述当前餐饮订单的支付方进行身份认证；

所述确定单元402具体用于根据所述身份认证结果以及确定的针对所述当前餐饮订单支付方的信用评估数据，确定所述支付方的信用支付数据范围。

其中，所述对所述当前餐饮订单的支付方进行身份认证至少包括以下一种方式：

对所述支付方联系方式信息的认证；

对所述支付方常驻地址信息的认证；

对所述支付方生物特征信息的认证。所述生物特征信息的认证包括：指纹人脸、瞳孔等认证方式。

在本实施例中，通过对支付方进行身份认证，进一步确保支付的安全性，降低支付风险。

输出单元403，用于根据所述信用支付数据范围，输出针对所述当前餐饮订单的支付数据的信用支付提醒。

所述输出单元403包括：

第一判断子单元，用于判断所述当前餐饮订单的支付数据是否在所述信用支付数据范围内，若是，则输出针对所述当前餐饮订单的信用支付提醒。

具体地，可以通过将所述当前餐饮订单的支付金额与所述信用支付数据范围的支付上限进行比较，若当前餐饮订单的支付金额小于或等于所述信用支付数据范围的支付上限，则说明可以通过信用支付平台针对当前餐饮订单的支付金额进行代扣或代扣，无需顾客通过自身支付账户中扣款。

本实施例中，输出针对所述当前订单的信用支付提醒至少可以包括如下一种提醒信息：

针对所述当前餐饮订单的信用支付的确认提醒信息；

例如：输出针对所述当前餐饮订单是否进行信用支付的操作界面，当选择是时，则所述当前餐饮订单则通过信用支付平台进行代扣，无需通过支付方的私人账户中扣除，具体可以是，当顾客针对确认提醒信息进行操作后跳转到代扣界面完成针对所述当前餐饮订单的支付金额的代扣。

针对所述当前餐饮订单的信用支付的支付时间提醒信息；

可以理解为，针对所述当前餐饮订单的支付金额通过信用支付平台进行代扣的时间范围，例如：在用餐完毕后的3小时之内或一天之内进行代扣等等。

针对所述当前餐饮订单的信用支付的还款时间提醒信息；

例如：信用支付平台针对当前餐饮订单的支付金额进行代扣，将代扣金额的还款时间输出，以便用户了解还款期限避免延误造成不必要的损失。

针对所述当前餐饮订单支付方的信用支付数据范围的支付上限提醒信息；

可以理解为告知支付方其具有的信用支付数据范围的最高额度。

所述输出单元403包括：

第二判断子单元，判断所述当前餐饮订单的支付数据是否在所述信用支付数据范围内，若否，则输出针对所述当前餐饮订单不支持信用支付的提醒。

具体地，如果比较结果不符合小于或等于信用指数数据范围的支付上限要求时，则可以输出针对所述当前餐饮订单不支持信用支付的提醒，进而告知支付方针对该笔当前餐饮订单不支持信用支付。

所述输出针对所述当前餐饮订单不支持信用支付的提醒可以包括至少如下一种提醒信息：

针对所述当前餐饮订单的不支持信用支付原因的提醒信息；

针对所述当前餐饮订单的不支持信用支付的解决方案的提醒信息。

可以理解的是，当所述当前餐饮订单的支付数据不在所述信用支付数据范围内，即：当前餐饮订单的支付金额大于信用支付数据范围的支付上限时，则也可以不做任何处理，支付方不能够通过信用支付平台针对当前餐饮订单的支付金额进行代付，仅能够通过自身账户进行线上支付，或者通过现金形式进行线下支付。

还包括：

代扣请求发送单元，用于根据所述输出针对所述当前餐饮订单的信用支付提醒，发送针对所述当前餐饮订单支付数据的信用代扣请求。

所述信用代扣请求可以是通过电子终端设备向所述代扣平台发出，或者是信用支付平台向所述代扣平台发出。其中，所述电子终端设备也可以理解为点餐平台，即可是顾客自己的移动终端设备，也可以是商家的电子终端设备。所述代扣平台在接收到代扣请求后针对所述当前餐饮订单进行代扣相应订单支付金额的操作。

所述代扣请求可以是在输出针对所述当前餐饮订单的信用支付提醒时，根据对所述信用支付提醒的响应进行发送，例如：信用支付提醒可以是“请确认是否进行信用支付代扣”的提醒，根据该提醒，顾客可以进行响应操作，若顾客针对该提醒选择为确认，即进行信用支付代扣，则根据该确认信用支付代扣的响应，发送针对所述当前餐饮订单支付数据的信用代扣请求。如果顾客针对该提醒选择的取消，即不进行信用支付代扣，则无需针对所述当前餐饮订单支付数据发送信用代扣请求。

因此，还包括：

响应获得单元，用于获得针对所述输出针对所述当前餐饮订单的信用支付提醒的响应；

所述代扣请求发送单元具体用于根据所述响应，发送针对所述当前餐饮订单支付数据的信用代扣请求。

信用代扣请求可以根据设定的发送条件进行发送，所述发送条件可以包括：位置条件和/或时间条件。

在本实施例中，所述代扣请求发送单元包括：

位置判断子单元，用于判断所述支付方是否离开产生所述当前餐饮订单的位置，若是，则发送针对所述当前餐饮订单支付数据的信用代扣请求。

例如，当顾客离开所述当前餐饮订餐产生的商家店铺的位置后，将针对所述当前餐饮订单所需要代扣的支付金额进行发送。更进一步的，可以设定离开所述当前餐饮订单产生的商家店铺的距离，例如：大于等于200米时，则确定为顾客已离开所述商家店铺。

以上是通过位置条件对是否进行发送信用代扣请求的判断，可以理解的是，除位置条件外，还可以通过时间条件对是否发送信用代扣请求进行判断，具体如下：

当发送条件为时间条件时，可以根据所述获取当前餐饮订单的支付数据中餐饮提供完成的时间点开始计时，之后判断所述计时时间是否大于设定的时间阈值，若满足则发送针对所述当前餐饮订单支付数据的信用代扣请求。所述时间阈值可以是根据餐饮的用时时间设定，更进一步的可以根据不同的餐饮订单中餐饮类型进行设定，例如：餐饮类型为火锅则时间阈值可以设定为3小时，如果餐饮类型为快餐则可以将时间阈值设定为1小时。例如：当餐饮提供完毕时间为18：30，则从18：30开始计时，当到21：00时，计时时间为2小时30分，如果设定的时间阈值为2小时，则此时判断计时时间已满足设定的时间阈值，可以发送针对所述当前餐饮订单支付数据的信用代扣请求，可以理解的是，判断可以实时进行。

通过设定的发送条件，可以使得顾客根据自身信用评估情况实现餐后付费的支付方式，即顾客离开商家店铺后在设定的条件下进行自动支付。

以上是对本申请提供的一种针对餐饮订单的支付装置实施例的说明，基于上述本申请提供的针对餐饮订单的支付方法及装置实施例的说明，本申请还提供一种计算机存储介质，用于存储网络平台产生数据，以及对应所述网络平台产生数据进行处理的程序；

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

获取当前餐饮订单的支付数据；

根据确定的针对所述当前餐饮订单支付方的信用评估数据，确定所述支付方的信用支付数据范围；

根据所述信用支付数据范围，输出针对所述当前餐饮订单的信用支付提醒。

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

处理器；

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

获取当前餐饮订单的支付数据；

根据确定的针对所述当前餐饮订单支付方的信用评估数据，确定所述支付方的信用支付数据范围；

根据所述信用支付数据范围，输出针对所述当前餐饮订单的信用支付提醒。

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

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

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

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

本申请虽然以较佳实施例公开如上，但其并不是用来限定本申请，任何本领域技术人员在不脱离本申请的精神和范围内，都可以做出可能的变动和修改，因此本申请的保护范围应当以本申请权利要求所界定的范围为准。

Claims (10)

1.一种针对餐饮订单的支付方法，其特征在于，包括：

获取当前餐饮订单的支付数据；

根据确定的针对所述当前餐饮订单支付方的信用评估数据，确定所述支付方的信用支付数据范围；

根据所述信用支付数据范围，输出针对所述当前餐饮订单的支付数据的信用支付提醒。

2.根据权利要求1所述的针对餐饮订单的支付方法，其特征在于，还包括：

根据设定的信用评估项目，确定针对所述当前餐饮订单支付方的信用评估数据。

3.根据权利要求2所述的针对餐饮订单的支付方法，其特征在于，所述信用评估项目至少包括如下一种：

餐饮行业黑名单评估项目；

所述支付方的资产评估项目；

所述支付方的负面信息评估项目；

所述支付方的信息验证评估项目；

所述支付方的信用指数评估项目；

所述支付方的历史用餐评估项目；

所述支付方的历史付款评估项目。

4.根据权利要求3所述的针对餐饮订单的支付方法，其特征在于，所述根据设定的信用评估方式，确定针对所述当前餐饮订单支付方的信用评估数据，包括：

当所述评估项目为一个时，根据所述评估项目的评估值，确定针对所述当前餐饮订单支付方的信用评估数据；

当所述评估项目为两个或两个以上时，根据参与评估的所述评估项目的平均评估值，确定针对所述当前餐饮订单支付方的信用评估数据。

5.根据权利要求1所述的针对餐饮订单的支付方法，其特征在于，所述根据确定的针对所述当前餐饮订单支付方的信用评估数据，确定所述支付方的信用支付数据范围，包括：

根据所述信用评估数据建立评估等级；

针对所述评估等级设定对应的信用支付数据范围。

6.根据权利要求1所述的针对餐饮订单的支付方法，其特征在于，所述根据所述信用支付数据范围，输出针对所述当前餐饮订单的信用支付提醒信息：

判断所述当前餐饮订单的支付数据是否在所述信用支付数据范围内，若是，则输出针对所述当前餐饮订单的信用支付提醒。

7.根据权利要求6所述的针对餐饮订单的支付方法，其特征在于，所述根据所述信用支付数据范围，输出针对所述当前餐饮订单的信用支付提醒信息，包括：

判断所述当前餐饮订单的支付数据是否在所述信用支付数据范围内，若否，则输出针对所述当前餐饮订单不支持信用支付的提醒。

8.一种针对餐饮订单的支付装置，其特征在于，包括：

获取单元，用于获取当前餐饮订单的支付数据；

确定单元，用于根据确定的针对所述当前餐饮订单支付方的信用评估数据，确定所述支付方的信用支付数据范围；

输出单元，用于根据所述信用支付数据范围，输出针对所述当前餐饮订单的支付数据的信用支付提醒。

9.一种计算机存储介质，用于存储网络平台产生数据，以及对应所述网络平台产生数据进行处理的程序；

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

获取当前餐饮订单的支付数据；

根据确定的针对所述当前餐饮订单支付方的信用评估数据，确定所述支付方的信用支付数据范围；

根据所述信用支付数据范围，输出针对所述当前餐饮订单的信用支付提醒。

10.一种电子设备，包括：

处理器；

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

获取当前餐饮订单的支付数据；

根据确定的针对所述当前餐饮订单支付方的信用评估数据，确定所述支付方的信用支付数据范围；

根据所述信用支付数据范围，输出针对所述当前餐饮订单的信用支付提醒。