CN110972500A - 用于支付管理的系统和方法 - Google Patents

Abstract

提供了用于支付管理的系统和方法。所述方法可以包括接收支付请求，所述支付请求可以包括与服务提供者提供的服务有关的信息。所述与所述服务有关的信息可以包括所述服务提供者的第一地理信息。所述方法还可以包括获取提供所述服务的位置的第二地理信息以及比较所述第一地理信息和所述第二地理信息。所述方法还可以包括至少基于所述两个地理信息的所述比较的结果，根据预设规则确定所述支付请求是否被批准。

Description

用于支付管理的系统和方法

交叉引用

本申请要求于2018年5月16日提交的中国专利申请No.201810467961.1以及于2018年6月4日提交的中国专利申请No.201810562977.0的优先权，其全部内容通过引用被包含于此。

技术领域

本申请一般涉及用于支付管理的系统和方法，尤其涉及用于确定是否批准支付请求的系统和方法。

背景技术

许多公司每个月都有大量的费用由员工报销。对于公司来说，识别费用的真实性，对这些费用进行统计支持，并设定适当的支付标准，这是一项繁琐而艰巨的任务。对于公司来说，要以电子方式执行这些支付任务的识别，统计和标准化是一个需要解决的问题。当公司执行报销时，通常很难验证相应报销项目的真实性，这可能导致许多不必要的报销费用。同时，员工可能必须自己处理不同的报销项目，如果没有完整的标准化流程让其他人代表员工并处理员工的报销项目，这可能需要员工花费很多时间。此外，当向用户提供服务时，可以发起支付请求以支付服务费用。如果可以快速安全地评估支付请求，则可以为用户带来很多便利。因此，希望提供更有效的系统和方法来管理支付。

发明内容

根据本披露的一个方面，提供了一种支付管理方法。所述支付管理方法可以在具有至少一个处理器和至少一个非暂时性存储介质的计算设备上实现。所述方法可以包括接收对应于消费行为的支付请求和相关消费凭证。所述消费凭证可以包括提供所述消费凭证的实体的位置信息。所述支付管理方法还可以包括获取所述消费行为发生的位置。所述支付管理方法还可以包括响应于确定所述位置信息与所述消费行为发生的所述位置不相关，确定不执行所述支付。

在一些实施例中，其中所述确定所述位置信息与所述消费行为发生的所述位置不相关，可以包括确定所述位置信息的第一字符串和所述消费行为发生的所述位置的第二字符串以及确定所述第一字符串和所述第二字符串之间的重合率。所述确定所述位置信息与所述消费行为发生的所述位置不相关还可以包括响应于确定所述重合率小于预设概率，确定所述位置信息与所述消费行为发生的所述位置不相关。

在一些实施例中，所述确定所述位置信息与所述消费行为发生的所述位置不相关可以包括确定与所述位置信息相关的第一区域和与所述消费行为发生的所述位置相关的第二区域以及确定所述第一区域和所述第二区域之间的重合面积。所述确定所述位置信息与所述消费行为发生的所述位置不相关还可以包括响应于确定所述重合面积小于预设面积，确定所述位置信息与所述消费行为发生的所述位置不相关。

在一些实施例中，响应于确定所述位置信息与所述消费行为发生的所述位置相关，所述支付管理方法还可以包括确定所述相关消费凭证的消费类别。所述支付管理方法还可以包括响应于确定与所述消费行为发生的所述位置相关的滞留时长小于对应于所述消费类别的预设时长，确定不执行所述支付。

根据本披露的另一方面，提供了一种支付管理系统。所述支付管理系统可以包括信息接收单元。所述信息接收单元可以被配置为接收对应于消费行为的支付请求和相关消费凭证。所述消费凭证可以包括提供所述消费凭证的实体的位置信息。所述支付管理系统还可以包括位置获取单元。所述位置获取单元可以被配置为获取所述消费行为发生的位置。所述支付管理系统还可以包括确定单元。所述确定单元可以被配置为响应于确定所述位置信息与所述消费行为发生的所述位置不相关，确定不执行所述支付。

根据本披露的又一方面，提供了一种计算设备。所述计算设备可以包括存储在所述存储器中并由所述处理器执行的存储器、处理器和计算机程序。当执行所述计算机程序时，所述处理器实现上述支付管理方法。

根据本披露的另一方面，提供了一种计算机可读存储介质。所述计算机可读存储介质可以存储计算机程序。当由所述处理器执行时，所述计算机程序实现上述支付管理方法。

根据本披露的又一方面，提供了一种费用支付管理方法。所述费用支付管理方法可以在具有至少一个处理器和至少一个非暂时性存储介质的计算设备上实现。所述费用支付管理方法可以包括接收与第二用户有关的由第一用户发起的费用支付请求，确定对应于所述费用支付请求的至少一条消费信息，并验证所述至少一条消费信息；所述费用支付管理方法还可以包括验证所述第一用户是否被授权发起与所述第二用户有关的所述费用支付请求。所述费用支付管理方法还可以包括响应于确定所述至少一条消费信息通过验证并且所述第一用户被授权发起与所述第二用户有关的所述费用支付请求，基于所述费用支付请求，将对应于所述至少一条消费信息的费用分配给所述第二用户的帐户。

在一些实施例中，所述费用支付管理方法还可以包括确定收到所述第一用户发起的所述费用支付请求的时间点与收到所述第二用户发起的费用支付请求的时间点之间的时间差。所述费用支付管理方法还可以包括响应于确定所述时间差不大于预设时间，基于所述第二用户发起的所述费用支付请求，确定所述至少一条消费信息。

在一些实施例中，所述费用支付管理方法还可以包括响应于确定所述至少一条消费信息通过验证并且所述第一用户被授权发起与所述第二用户有关的所述费用支付请求，删除对应于所述第二用户的至少一个第一用户的信息和所述至少一个第一用户的任何费用支付请求。

在一些实施例中，所述验证所述至少一条消费信息可以包括确定与所述至少一条消费信息相关的至少一个消费参数，以及基于存储所述至少一条消费信息的消费系统数据库，确定所述至少一个消费参数中的每一个的匹配度。所述验证所述至少一条消费信息还可以包括响应于确定所有所述至少一个匹配度大于至少一个对应的匹配阈值，确定所述至少一条消费信息被成功验证。所述验证所述至少一条消费信息还可以包括响应于确定并非所有所述至少一个匹配度大于所述至少一个对应的匹配阈值，确定所述至少一条消费信息未通过验证。所述至少一个消费参数可以包括消费时间、消费位置和消费类别中的一个或多个。

根据本披露的另一方面，提供了一种费用支付管理系统。所述费用支付管理系统可以包括请求接收单元，被配置为接收第一支付请求。该请求可以包括与提供给第二用户的服务有关的第一信息。所述费用支付管理系统还可以包括信息验证单元，被配置为确定对应于所述费用支付请求的至少一条消费信息，并验证所述至少一条消费信息。所述费用支付管理系统还可以包括代理验证单元，被配置为验证所述第一用户是否被授权发起与所述第二用户有关的所述费用支付请求。所述费用支付管理系统还可以包括执行单元，被配置为响应于确定所述至少一条消费信息通过验证并且所述第一用户被授权发起与所述第二用户有关的所述费用支付请求，基于所述费用支付请求，将对应于所述至少一条消费信息的费用分配给所述第二用户的帐户。

根据本披露的又一方面，提供了一种计算设备。所述计算设备可以包括存储在所述存储器中并由所述处理器执行的存储器、处理器和计算机程序，其中当执行所述计算机程序时，所述处理器可以实现上述费用支付管理方法。

根据本披露的另一方面，提供了一种计算机可读存储介质。所述计算机可读存储介质可以存储计算机程序。当由所述处理器执行时，所述计算机程序可以实现上述费用支付管理方法。

根据本披露的又一方面，提供了一种系统。所述系统可以包括包括一组指令的至少一个存储介质，以及至少一个处理器。所述至少一个处理器可以与所述至少一个存储介质通信。当执行所述指令时，所述至少一个处理器被配置为使所述系统执行操作，所述操作可以包括接收支付请求。所述支付请求可以包括与服务提供者提供的服务有关的信息，所述与所述服务有关的信息可以包括所述服务提供者的第一地理信息。所述至少一个处理器还可以被配置为使所述系统执行以下操作，包括获取提供所述服务的位置的第二地理信息，比较所述第一地理信息和所述第二地理信息以及至少基于所述两个地理信息的所述比较的结果，根据预设规则确定所述支付请求是否被批准。

在一些实施例中，所述服务由所述用户经由终端设备支付，并且所述第二地理信息由所述终端设备的定位收发器组件生成。

在一些实施例中，所述第二地理信息可以包括规定的地理位置。

在一些实施例中，所述服务提供者的所述第一地理信息可以包括所述服务提供者的实体的地理位置。

在一些实施例中，所述第一地理信息可以包括第一字符串，且所述第二地理信息可以包括第二字符串。为了至少基于所述两个地理信息的所述比较的所述结果，根据所述预设规则，来确定所述支付请求是否被批准，所述至少一个处理器被配置为使所述系统执行附加操作，所述附加操作可以包括确定所述第一字符串和所述第二字符串之间的相似度。

在一些实施例中，所述预设规则可以包括响应于确定所述第一字符串与所述第二字符串之间的所述相似度超过相似度阈值，确定所述支付请求被批准。

在一些实施例中，所述第一地理信息可以包括第一地理位置，且所述第二地理信息可以包括第二地理位置。为了至少基于所述两个地理信息的所述比较的所述结果，根据所述预设规则确定所述支付请求是否被批准，所述至少一个处理器被配置为使所述系统执行附加操作，所述附加操作可以包括确定所述第一地理位置与所述第二地理位置之间的相关性。

在一些实施例中，为了基于所述两个地理信息的所述比较的所述结果，根据所述预设规则，来确定所述支付请求是否被批准，所述至少一个处理器被配置为使所述系统执行附加操作，所述附加操作可以包括确定可以包括所述第一地理位置的第一区域和可以包括所述第二地理位置的第二区域以及基于所述第一区域和所述第二区域之间的重合，确定所述第一地理位置与所述第二地理位置之间的所述相关性。

在一些实施例中，所述预设规则可以包括比较所述第一区域和所述第二区域之间的所述重合与重合阈值，以及响应于所述第一区域和所述第二区域之间的所述重合超过重合阈值的所述比较的所述结果，确定所述支付请求被批准。

在一些实施例中，为了基于所述两个地理信息的所述比较的所述结果，根据所述预设规则，来确定所述支付请求是否被批准，所述至少一个处理器被配置为使所述系统执行附加操作，所述附加操作可以包括确定与所述服务相关的持续时间。

在一些实施例中，所述预设规则可以包括将与所述服务有关的所述持续时间与时间阈值进行比较。所述预设规则还可以包括响应于与所述服务相关的持续时间超过时间阈值的所述比较的所述结果，确定所述支付请求被批准。

在一些实施例中，所述支付请求可以是加密的，并且所述至少一个处理器可以进一步被配置为使所述系统执行附加操作，所述附加操作可以包括解密所述支付请求。

根据本披露的另一方面，提供了一种方法。所述方法可以在计算设备上实现，所述计算设备具有至少一个处理器和至少一个非暂时性存储介质。所述方法可以包括接收支付请求。所述支付请求可以包括与服务提供者提供的服务有关的信息。所述与所述服务有关的信息可以包括所述服务提供者的第一地理信息。所述方法还可以包括获取提供所述服务的位置的第二地理信息，比较所述第一地理信息和所述第二地理信息以及至少基于所述两个地理信息的所述比较的结果，根据预设规则确定所述支付请求是否被批准。

根据本披露的又一方面，提供了一种系统。所述系统可以包括获取模块，被配置为接收支付请求，所述支付请求可以包括与服务提供者提供的服务有关的信息。所述与所述服务有关的信息可以包括所述服务提供者的第一地理信息。所述获取模块还可以被配置为获取提供所述服务的位置的第二地理信息。所述系统还可以包括确定模块，被配置为比较所述第一地理信息和所述第二地理信息以及至少基于所述两个地理信息的所述比较的结果，根据预设规则确定所述支付请求是否被批准。

根据本披露的又一方面，提供了一种非暂时性计算机可读介质。所述非暂时性计算机可读介质可以包括至少一组指令。当由至少一个处理器执行时，所述至少一组指令被指示使所述至少一个处理器实现一种方法，所述方法可以包括接收支付请求。所述支付请求可以包括与服务提供者提供的服务有关的信息，所述与所述服务有关的信息可以包括所述服务提供者的第一地理信息。所述方法还可以包括获取提供所述服务的位置的第二地理信息，比较所述第一地理信息和所述第二地理信息以及至少基于所述两个地理信息的所述比较的结果，根据预设规则确定所述支付请求是否被批准。

根据本披露的另一方面，提供了一种系统，可以包括包括一组指令的至少一个存储介质和至少一个处理器。所述至少一个处理器与所述至少一个存储介质通信。当执行所述指令时，所述至少一个处理器被配置为使所述系统执行操作，所述操作可以包括接收第一用户发起的第一支付请求，所述第一支付请求与提供给第二用户的服务有关。所述操作还可以包括获取与提供给所述第二用户的所述服务有关的第一信息，以及根据第一预设规则，通过验证所述第一信息，生成第一验证结果。所述操作还可以包括根据第二预设规则，通过验证所述第一用户是否被授权发起所述第一支付请求，生成第二验证结果，以及至少基于所述第一验证结果和所述第二验证结果，确定所述第一支付请求是否被批准。

在一些实施例中，为了根据第二预设规则，通过验证所述第一用户是否被授权发起所述第一支付请求，生成所述第二验证结果，所述至少一个处理器被配置为使所述系统执行附加操作，所述附加操作可以包括接收由所述第二用户发起的第二支付请求，所述第二支付请求与提供给所述第二用户的所述服务有关。所述附加操作还可以包括获取与所述第二服务有关的第二信息以及确定与所述第一支付请求相关联的第一时间点和与所述第二支付请求相关联的第二时间点之间的时间差。所述附加操作还可以包括确定所述时间差是否小于或等于预设时间。所述附加操作还可以包括响应于确定所述时间差小于所述预设时间，验证所述第一用户是未经授权发起所述第一支付请求。

在一些实施例中，所述至少一个处理器被配置为使所述系统执行附加操作，所述附加操作可以包括删除所述第一支付请求的信息。

在一些实施例中，所述至少一个处理器被配置为使所述系统执行附加操作，所述附加操作可以包括根据第三预设规则，通过验证所述第二信息，生成第三验证结果以及至少基于所述第三验证结果，确定所述第二支付请求是否被批准。

在一些实施例中，为了根据所述第三预设规则，通过验证所述第二信息，生成所述第三验证结果，所述至少一个处理器被配置为使所述系统执行附加操作，所述附加操作可以包括基于所述第二信息，确定一个或多个第二参数以及确定与所述一个或多个第二参数相关的一个或多个第二匹配度。所述附加操作还可以包括比较所述一个或多个第二匹配度与一个或多个第二匹配阈值。所述附加操作还可以包括响应于所述一个或多个第二匹配度大于所述一个或多个第二匹配阈值的所述比较的结果，生成验证所述第二信息合格的所述第三验证结果。

在一些实施例中，为了根据所述第一预设规则，通过验证所述第一信息，生成所述第一验证结果，所述至少一个处理器被配置为使所述系统执行附加操作，所述附加操作可以包括基于所述第一信息，确定一个或多个第一参数以及确定与所述一个或多个第一参数相关的一个或多个第一匹配度。所述附加操作还可以包括比较所述一个或多个第一匹配度与一个或多个第一匹配阈值。所述附加操作还可以包括响应于所述一个或多个第一匹配度大于所述一个或多个第一匹配阈值的所述比较的结果，生成验证所述第一信息合格的所述第一验证结果。

在一些实施例中，所述一个或多个第一参数或所述一个或多个第二参数中的至少一个可以包括与提供给所述第二用户的所述服务相关的位置、所述服务提供给所述第二用户的时间、与提供给所述第二用户的所述服务有关的持续时间，或提供给所述第二用户的所述服务的类别中的至少一个。

在一些实施例中，所述至少一个处理器被配置为使所述系统执行附加操作，所述附加操作可以包括确定向所述第二用户提供所述服务的服务提供者的第一地理信息以及确定向所述第二用户提供所述服务的位置的第二地理信息。所述附加操作还可以包括基于所述第一地理信息和所述第二地理信息，确定所述一个或多个第一匹配度或所述一个或多个第二匹配度中的至少一个。

在一些实施例中，所述第一地理信息可以包括第一字符串，且所述第二地理信息可以包括第二字符串。了基于所述第一地理信息和所述第二地理信息，确定所述一个或多个第一匹配度或所述一个或多个第二匹配度中的所述至少一个，所述至少一个处理器被配置为使所述系统执行附加操作，所述附加操作可以包括基于所述第一字符串和所述第二字符串，确定所述一个或多个第一匹配度或所述一个或多个第二匹配度中的所述至少一个。

在一些实施例中，为了基于所述第一地理信息和所述第二地理信息，确定所述一个或多个第一匹配度或所述一个或多个第二匹配度中的所述至少一个，所述至少一个处理器被配置为使所述系统执行附加操作，所述附加操作可以包括基于所述第一地理信息，确定第一区域以及基于所述第二地理信息，确定第二区域。所述附加操作还可以包括基于所述第一区域和所述第二区域，确定所述一个或多个第一匹配度或所述一个或多个第二匹配度的所述至少一个。

在一些实施例中，所述至少一个处理器可以被配置为使所述系统执行附加操作，所述附加操作可以包括确定与提供给所述第二用户的所述服务相关的持续时间以及基于所述持续时间和预设时长，确定所述一个或多个第一匹配度或所述一个或多个第二匹配度中的所述至少一个。

根据本披露的又一方面，提供了一种方法。所述方法可以在计算设备上实现，所述计算设备可以具有至少一个处理器和至少一个非暂时性存储介质。所述方法可以包括接收第一用户发起的第一支付请求，所述第一支付请求与提供给第二用户的服务有关。所述方法还可以包括获取与提供给所述第二用户的所述服务有关的第一信息以及根据第一预设规则，通过验证所述第一信息，生成第一验证结果。所述方法还可以包括根据第二预设规则，通过验证所述第一用户是否被授权发起所述第一支付请求，生成第二验证结果，以及至少基于所述第一验证结果和所述第二验证结果，确定所述第一支付请求是否被批准。

根据本披露的又一方面，提供了一种系统。所述系统可以包括获取模块。所述获取模块可以被配置为接收第一用户发起的第一支付请求。所述第一支付请求可以与提供给第二用户的服务有关。所述获取模块还可以被配置为获取与提供给所述第二用户的所述服务有关的第一信息。所述系统还可以包括确定模块，被配置为根据第一预设规则，通过验证所述第一信息，生成第一验证结果，以及根据第二预设规则，通过验证所述第一用户是否被授权发起所述第一支付请求，生成第二验证结果。所述确定模块还可以被配置为至少基于所述第一验证结果和所述第二验证结果，确定所述第一支付请求是否被批准。

根据本披露的另一方面，提供了一种非暂时性计算机可读介质。所述非暂时性计算机可读介质可以包括至少一组指令。当由至少一个处理器执行时，所述至少一组指令被指示使所述至少一个处理器实现一种方法，所述方法可以包括接收第一用户发起的第一支付请求，所述第一支付请求与提供给第二用户的服务有关。所述方法还可以包括获取与提供给所述第二用户的所述服务有关的第一信息。所述方法还可以包括根据第一预设规则，通过验证所述第一信息，生成第一验证结果。所述方法还可以包括根据第二预设规则，通过验证所述第一用户是否被授权发起所述第一支付请求，生成第二验证结果，以及至少基于所述第一验证结果和所述第二验证结果，确定所述第一支付请求是否被批准。

本申请的一部分附加特性可以在下面的描述中进行说明。通过对以下描述和相应附图的研究或者对实施例的生产或操作的了解，本申请的一部分附加特性对于本领域技术人员是明显的。本申请的特征可以通过对以下描述的具体实施例的各种方面的方法、手段和组合的实践或使用得以实现和达到。

附图说明

本申请将通过示例性实施例进行进一步描述。这些示例性实施例将通过附图进行详细描述。这些实施例是非限制性的示例性实施例，在这些实施例中，各图中相同的编号表示相似的结构，其中：

图1是根据本申请的一些实施例所示的示例性支付管理系统的示意图；

图2是根据本申请的一些实施例所示的示例性计算设备的示例性硬件和/或软件组件的示意图；

图3是根据本申请的一些实施例所示的示例性终端设备的示意图；

图4是根据本申请的一些实施例所示的示例性处理引擎的框图；

图5是根据本申请的一些实施例所示的用于支付管理的示例性过程的流程图；

图6是根据本申请的一些示例性实施例所示的支付管理方法的流程图；

图7是根据本申请的一些示例性实施例所示的支付管理方法的流程图；

图8是根据本申请的一些示例性实施例所示的支付管理方法的流程图；

图9是根据本申请的一些示例性实施例所示的支付管理方法的流程图；

图10是根据本申请的一些示例性实施例所示的支付管理系统的示意框图；

图11是根据本申请的一些示例性实施例所示的支付管理系统的示意图；

图12是根据本申请的一些示例性实施例所示的用于支付管理的示例性过程的流程图；

图13是根据本申请的一些示例性实施例所示的费用支付管理过程的流程图；

图14是根据本申请的一些示例性实施例所示的费用支付管理过程的流程图；

图15是根据本申请的一些示例性实施例所示的费用支付管理过程的流程图；

图16是根据本申请的一些示例性实施例所示的费用支付管理系统的示意图；

图17是根据本申请的一些示例性实施例所示的费用支付管理系统的示意图；

图18是根据本申请的一些示例性实施例所示的费用支付管理系统的示意图；

图19是根据本申请的一些示例性实施例所示的计算设备的示意图；

图20是根据本申请的一些示例性实施例所示的在费用支付管理中预先添加第一用户的终端接口的示意图；

图21是根据一些示例性实施例所示的在费用支付管理中预先添加第二用户的终端接口的示意图；

图22是根据本申请的一些示例性实施例所示的与费用支付管理相关的终端应用(APP)的示例性界面的示意图；

图23是根据本申请的一些示例性实施例所示的与费用支付管理方法有关的终端APP的示例性界面的示意图；

图24是根据本申请的一些示例性实施例所示的与费用支付管理相关的终端APP的示例性界面的示意图；

图25是根据本申请的一些示例性实施例所示的与费用支付管理相关的终端APP的示例性界面的示意图；

图26是根据本申请的一些示例性实施例所示的与费用支付管理相关的终端APP的示例性界面的示意图；

图27是根据本申请的一些示例性实施例所示的与费用支付管理相关的示例性计算机接口的示意图；以及

图28是根据本申请的一些示例性实施例所示的与费用支付管理相关的示例性计算机接口的示意图。

具体实施方式

以下描述是为了使本领域的普通技术人员能够实施和利用本申请，并且该描述是在特定的应用场景及其要求的环境下提供的。对于本领域的普通技术人员来讲，显然可以对所披露的实施例作出各种改变，并且在不偏离本申请的原则和范围的情况下，本申请中所定义的普遍原则可以适用于其他实施例和应用场景。因此，本申请并不限于所描述的实施例，而应该被给予与权利要求一致的最广泛的范围。

本申请中所使用的术语仅用于描述特定的示例性实施例，并不限制本申请的范围。如本申请使用的单数形式“一”、“一个”及“该”可以同样包括复数形式，除非上下文明确提示例外情形。还应当理解，如在本申请中所示，术语“包括”、“包含”仅提示存在所述特征、整体、步骤、操作、组件和/或部件，但并不排除存在或添加一个或多个其他特征、整体、步骤、操作、组件、部件和/或其组合的情况。

在考虑了作为本申请一部分的附图的描述内容后，本申请的特征和特点以及操作方法、结构的相关元素的功能、各部分的组合、制造的经济性变得显而易见。然而，应当理解，附图仅仅是为了说明和描述的目的，并不旨在限制本申请的范围。应当理解的是，附图并不是按比例绘制的。

本申请中使用了流程图用来说明根据本申请的一些实施例的系统所执行的操作。应当理解的是，流程图中的操作可以不按顺序执行。相反，可以按照倒序或同时处理各种步骤。同时，也可以将一个或多个其他操作添加到这些流程图中。也可以从流程图中删除一个或多个操作。

本申请的一个方面涉及用于支付管理的系统、方法和/或计算机可读介质。具体地，可以从与用户相关联的请求者终端接收由用户发起的支付请求。支付请求可以包括与提供给用户的服务有关的信息，例如住宿服务、运输服务等。基于与服务有关的信息，可以确定支付请求的合格性。例如，与服务有关的信息可以包括服务提供者的第一地理信息和向用户提供服务的位置的第二地理信息。可以比较第一地理信息和第二地理信息。响应于确定第一地理信息与第二地理信息相关，可以确定支付请求合格。可以将支付金额交易到用户的金融账户(例如，银行账户)。

在一些情况下，用户可以指定代理来代表用户并发起支付请求。代理可以被称为第一用户，并且被提供服务的用户可以被称为第二用户。可以确定第一信息是否合格以及第一用户是否有资格代表第二用户。响应于确定第一信息和第一用户有资格代表第二用户，对应于第一用户发起支付的支付金额可以被交易到第二用户的金融账户。在一些情况下，可以接收分别由第一用户和第二用户发起的两个支付请求。可以确定在接收由第一用户发起的支付请求的时间点(被称为第一支付请求)和接收由第二用户发起的支付请求的时间点(被称为一个第二支付请求)之间的时间差。响应于确定时间差小于或等于预设时间长度，可以将第一支付请求确定为不合格。可以确定第二支付请求是否有资格获得批准。响应于确定第二支付请求有资格被批准，对应于第二支付请求的支付金额可以被交易到第二用户的金融账户。

此外，在本申请的一些实施例中，系统和方法可以采用以下技术中的至少一种，包括：将支持请求和/或信息中的认证信息嵌入到请求者终端，加密数据以进行传输，如果嵌入的认证信息通过验证，则解密接收的数据等，或其组合。这可以允许从/到特定请求者终端的特定数据安全通信和/或准确传输。

如这里所使用的，术语“支付请求”可以指被支付金额的请求，或者支付金额的请求。在一些实施例中，支付请求可以与为商业原因提供给用户的服务相关联。用户可能已经为该服务付费，并且可以通过个人或组织(例如，雇用该用户的公司)发起支付请求，获得回报(即，作为报销)。在一些实施例中，用户(即，第一用户)可以代表被提供服务的用户(即，第二用户)发起支付请求。如果支付请求被批准，则可以向第二用户支付一定金额。在一些实施例中，支付请求可以与提供给用户(即，服务请求者)的服务的支付相关联。服务请求者或服务提供者可以发起支付请求。例如，如果服务请求者或服务提供者发起的支付请求被批准，则可以向服务提供者支付一定数额的钱。

图1是根据本申请的一些实施例所示的示例性支付管理系统的示意图。例如，支付管理系统100可以是用于管理对应于支付请求的支付请求和支付的系统。支付管理系统100可以包括服务器110、网络120、用户终端130和存储设备140。

服务器110可以被配置为处理与支付请求有关的数据。在一些实施例中，服务器110可以经由请求者终端(例如，用户终端130)从用户处接收支付请求。支付请求可以包括与提供给用户的服务有关的信息。服务器110可以基于与提供给用户的服务有关的信息，确定报销是否合格。在一些实施例中，服务器110可以是单个服务器，也可以是服务器组。所述服务器组可以是集中式的，也可以是分布式的(例如，服务器110可以是分布式的系统)。在一些实施例中，服务器110可以是本地的，也可以是远程的。例如，服务器110可以经由网络120访问存储于用户终端130,或存储设备140中的信息和/或数据。又例如，服务器110可以直接连接到用户终端130和/或存储设备140以访问信息和/或数据。在一些实施例中，服务器110可以在云平台上实施。仅作为示例，该云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多层云等或其任意组合。在一些实施例中，服务器110可以在本申请中的图2描述的包含了一个或多个组件的计算设备上执行。

在一些实施例中，服务器110可以包括处理引擎112。处理引擎112可以处理与支付请求相关联的数据，以执行本申请中描述的服务器110的一个或多个功能。在一些实施例中，处理引擎112可以从与用户相关联的请求者终端接收由用户发起的支付请求。处理引擎112可以进一步基于与提供给用户的服务有关的信息，确定支付请求是否合格。例如，处理引擎112可以比较第一地理信息和与支付请求相关联的第二地理信息。响应于确定第一地理信息和第二地理信息相关，处理引擎112可以确定支付请求合格。在一些实施例中，支付请求可以由另一个用户(被称为第一用户)代表提供服务的用户(被称为第二用户)发起。处理引擎112可以进一步确定第一用户是否有资格代表第二用户。在一些实施例中，所述处理引擎112可包括一个或多个处理引擎(例如，单芯片处理引擎或多芯片处理引擎)。仅作为范例，处理引擎112可包括中央处理器(CPU)、特定应用集成电路(ASIC)、特定应用指令集处理器(ASIP)、图像处理器(GPU)、物理运算处理单元(PPU)、数字信号处理器(DSP)、现场可编程门阵列(FPGA)、可编程逻辑设备(PLD)、控制器、微控制器单元、精简指令集计算机(RISC)、微处理器等或其任意组合。I在一些实施例中，处理引擎112可以能够解密来自请求者终端的加密的支付请求。

网络120可以促进信息和/或数据的交换。在一些实施例中，支付管理系统100中的一个或多个组件(例如，服务器110、用户终端130和/或存储设备140)可以经由网络120将信息和/或数据发送到支付管理系统100中的其他组件。例如，服务器110可以经由网络120从用户终端130获得/获取支付请求。在一些实施例中，网络120可以为任意形式的有线或无线网络，或其任意组合。仅作为示例，网络120可以包括有线网络、有线网络、光纤网络、远程通信网络、内联网、互联网、局域网(LAN)、广域网(WAN)、无线局域网(WLAN)、城域网(MAN)、广域网(WAN)、公共电话交换网(PSTN)、BluetoothTM网络、ZigBeeTM网络、近场通信(NFC)网络、全球移动通信系统(GSM)网络、码分多址(CDMA)网络、时分多址(TDMA)网络、通用分组无线业务(GPRS)网络、GSM演进(EDGE)网络、宽带码分多址(WCDMA)网络、高速下行链路分组接入(HSDPA)网络、长期演进(LTE)网络的增强数据速率、用户数据报协议(UDP)网络、传输控制协议/互联网协议(TCP/IP)网络、短消息服务(SMS)网络、无线应用协议(WAP)网络、超宽带(UWB)网络、红外线等，或其任何组合。在一些实施例中，网络120可以包括一个或多个网络接入点。例如，网络120可以包括有线或无线网络接入点，如基站和/或互联网交换点120-1、120-2……通过支付管理系统100的一个或多个部件可以连接到网络120以交换数据和/或信息。

用户终端130可以与用户相关联。在一些实施例中，用户可以经由用户终端130发起支付请求。用户终端130可以将支付请求发送到服务器110(例如，处理引擎112)。在一些实施例中，用户可以查看提交的支付请求，修改或撤销提交的支付请求。在一些实施例中，用户终端130可以配置有定位收发器组件。用户终端130可以确定第二地理信息，该第二地理信息指示经由定位收发器组件向用户提供服务的位置。

在一些实施例中，支付请求可以由用户终端130加密，处理引擎112可以在接收到加密的支付请求之后对加密的支付请求进行解密。仅作为示例，用户终端130可以使用其私钥和/或通过对支付请求进行数字签名，加密支付请求。处理引擎112可以使用用户终端130的公钥，解密支付请求。在一些实施例中，加密的支付请求可以包括与用户终端130和/或请求者有关的认证信息，例如请求者的标识、请求者输入的密码和/或用户终端130的数字签名。处理引擎112可以在解密之前验证用户终端130和/或请求者的认证信息。在一些实施例中，用户终端130可以包括移动设备130-1、平板计算机130-2、膝上型计算机130-3、台式计算机130-4等，或其任何组合。在一些实施例中，移动设备130-1可以包括智能家居设备、可穿戴设备、智能移动设备、虚拟现实设备、增强现实设备等，或其任意组合。在一些实施例中，智能家居设备可以包括智能照明设备、智能电器控制设备、智能监控设备、智能电视、智能摄像机、对讲机等，或其任意组合。在一些实施例中，该可穿戴设备可包括智能手镯、智能鞋袜、智能眼镜、智能头盔、智能手表、智能衣服、智能背包、智能配件等或其任意组合。在一些实施例中，智能移动设备可以包括智能电话、个人数字助理(PDA)、游戏设备、导航设备、销售点(POS)等，或其任意组合。在一些实施例中，虚拟现实设备和/或增强型虚拟现实设备可以包括虚拟现实头盔、虚拟现实眼镜、虚拟现实眼罩、增强现实头盔、增强现实眼镜、增强现实眼罩等，或其任意组合。例如，该虚拟现实设备和/或增强实境设备可包括GoogleGlass、Oculus Rift、HoloLens或Gear VR等。在一些实施例中，用户终端130可以是具有定位技术的无线设备，用于定位用户和/或用户终端130的位置。

存储设备140可以存储数据和/或指令。在一些实施例中，存储设备140可以存储从用户终端130获得/获取的数据。例如，存储设备140可以存储从用户终端130接收的支付请求。在一些实施例中，存储设备140可以存储服务器110用来执行或使用来完成本申请中描述的示例性方法的数据和/或指令。在一些实施例中，存储设备140可包括大容量存储器、可移动存储器、易失性读写存储器、只读存储器(ROM)等或其任意组合。示例性的大容量存储器可以包括磁盘、光盘、固态磁盘等。示例性可移动存储器可以包括闪存驱动器、软盘、光盘、存储卡、压缩盘、磁带等。示例性易失性读写存储器可以包括随机存取存储器(RAM)。示例性RAM可包括动态随机存取存储器(DRAM)、双倍数据速率同步动态随机存取存储器(DDRSDRAM)、静态随机存取存储器(SRAM)、晶闸管随机存取存储器(T-RAM)和零电容随机存取存储器(Z-RAM)等。示例性只读存储器可以包括掩模型只读存储器(MROM)、可编程只读存储器(PROM)、可擦除可编程只读存储器(PEROM)、电可擦除可编程只读存储器(EEPROM)、光盘只读存储器(CD-ROM)和数字多功能磁盘只读存储器等。

在一些实施例中，所述存储设备140可在云端平台上执行。仅作为示例，该云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多层云等或其任意组合。在一些实施例中，存储设备140可以连接到网络120以与支付管理系统100中的一个或多个组件(例如，服务器110、用户终端130等)通信。支付管理系统100中的一个或多个组件可以经由网络120访问存储设备140中存储的数据或指令。在一些实施例中，存储设备140可以直接连接到支付管理系统100(例如，服务器110、用户终端130等)中的一个或多个组件或与之通信。在一些实施例中，存储设备140可以是服务器110的一部分。

在一些实施例中，支付管理系统100中的一个或多个组件(例如，服务器110，用户终端130等)可以具有访问存储设备140的许可。在一些实施例中，当满足一个或多个条件时，支付管理系统100中的一个或多个组件可以读取和/或修改与用户相关的信息。例如，服务器110可以从存储设备140获得目标数据，包括样本关键字、流行度信息、与用户终端130的用户相关联的偏好信息、与至少一个旅行设备相关的统计数据(也称为旅行设备信息)等，或其组合。

本领域的普通技术人员将理解，当支付管理系统100的元件执行操作时，该元件可以通过电信号和/或电磁信号执行。例如，在用户经由终端130提交支付请求之后，终端设备130可以将编码支付请求的电信号发送到处理引擎112。当处理引擎112处理任务时，例如确定报销是否合格，处理引擎112可以操作逻辑电路以执行这样的任务。

图2是根据本申请的一些实施例所示的计算设备的示例性硬件组件和/或软件组件的示意图；在一些实施例中，服务器110和/或用户终端130可以在图2中所示的计算设备200上实现。例如，所述处理引擎112可以在所述计算设备200上实施并执行本申请所披露的所述处理引擎112的功能。

计算设备200可用于实现如本文所述的支付管理系统100的任何组件。例如，处理引擎112可以在计算设备200上通过其硬件、软件程序、固件或其组合实现。尽管仅示出了一个这样的计算机，但是为了方便，与本文所述的支付管理有关的计算机功能可以在多个类似平台上以分布式方式实现，以分配处理负载。

例如，计算设备200可以包括与网络相连接通信端口250，以实现数据通信。计算设备200还可以包括处理器(例如，处理器220)，其形式为一个或多个处理器(例如，逻辑电路)，用于执行程序指令。例如，处理器220可以包括其中的接口电路和处理电路。接口电路可以被配置为从总线210接收电信号，其中电信号编码用于处理电路的结构化数据和/或指令。处理电路可以进行逻辑计算，然后将结论、结果和/或指令编码确定为电信号。然后，接口电路可以经由总线210从处理电路发出电信号。

示例性计算设备还可以包括不同形式的程序存储和数据存储，包括：例如，磁盘270，以及只读存储器(ROM)230或随机存取存储器(RAM)240，用于由计算设备处理和/或发送的各种数据文件。示例性计算设备也可以包括储存于ROM 230、RAM 240和/或其他形式的非暂时性存储介质中的能够被处理器220执行的程序指令。本申请的方法和/或流程可以以程序指令的方式实现。计算设备200还包括输入/输出组件260，用来支持计算机和其他组件之间进行输入/输出。计算设备200也可以通过网络通信接收编程和数据。

仅用于说明，图2中仅示出了一个处理器。还考虑了多个处理器220；因此，如本申请中所描述的由一个处理器220执行的操作和/或方法步骤也可以由多个处理器联合或单独执行。例如，如果在本申请中，计算设备200的处理器执行步骤A和步骤B，应当理解的是，步骤A和步骤B也可以由计算设备200的两个不同的处理器共同地或独立地执行(例如，第一处理器执行步骤A，第二处理器执行步骤B，或者第一和第二处理器共同地执行步骤A和步骤B)。

图3是根据本申请的一些实施例所示的终端设备的示例性硬件和/或软件组件的示意图。在一些实施例中，用户终端130可以在图3中所示的终端设备300上实现。终端设备300可以是移动设备，例如移动电话、智能手表等。如图3所示，终端设备300可以包括通信平台310、显示器320、图形处理单元(GPU)330、中央处理单元(CPU)340、I/O350、内存360和存储器390。在一些实施例中，任何其他合适的组件，包括但不限于系统总线或控制器(未示出)，也可包括在终端设备300内。

在一些实施例中，操作系统370(例如，iOS^TM、Android^TM、Windows Phone^TM等)和一个或多个应用程序380可从存储器390下载至内存360以及由CPU 340执行。在一些实施例中，终端设备300可以包括定位收发器组件。终端设备300可以确定第二地理信息，该第二地理信息指示经由定位收发器组件向用户提供服务的位置。在一些实施例中，用户可以经由终端设备300发起支付请求。用户还可以通过终端设备300查看、修改或撤销支付请求。用户交互可以通过I/O 350实现，并通过网络120提供给服务器110和/或支付管理系统100的其他组件。

图4是根据本申请的一些实施例所示的示例性处理引擎的框图。处理引擎112可以与存储介质(例如，支付管理系统100的存储设备140和/或终端设备300的存储器390)通信，并且可以执行存储在存储介质中的指令。在一些实施例中，处理引擎112可包括获取模块410、确定模块420、交易模块430和传输模块440。在一些实施例中，处理引擎112可以集成到服务器110中。

获取模块410可以获取与支付管理有关的数据。在一些实施例中，获取模块410可以接收支付请求，该支付请求包括与服务提供者提供给用户的服务有关的信息。与服务有关的信息可以包括服务提供者的第一地理信息。具体地，获取模块410可以从与用户相关联的请求者终端(例如，图1中所示的用户终端130)接收支付请求。例如，用户可以是公司、政府部门、非营利组织等的雇员。支付请求可以与报销相关联。又例如，用户可以是服务请求者。在一些实施例中，用户可以发起支付请求以支付提供给用户的服务(即，服务请求者)。用户可以通过提供与服务有关的信息，发起支付请求。在一些实施例中，获取模块410还可以获取向用户提供服务的位置的第二地理信息。

在一些实施例中，获取模块410可以接收由第一用户发起的第一支付请求和与提供给第二用户的服务有关的第一信息。在一些实施例中，出于商业原因，第一支付请求可以与提供给第二用户的服务相关联。第二个用户可能已经为该服务支付了费用。第一用户可以发起支付请求以允许第二用户通过个人或组织(例如，雇用用户的公司)获得回报(即，作为报销)。在一些实施例中，第一用户可以经由第一请求者终端(例如，用户终端130)代表第二用户(即，作为第二用户的代理)发起第一支付请求。如果确定支付请求被批准(即，合格)，则可以向第二用户支付对应于该服务的一定金额。在一些实施例中，支付请求可以与由第一用户向第二用户(即，服务请求者)提供的服务的支付相关联。服务请求者或服务提供者可以发起支付请求。例如，如果服务请求者或服务提供者发起的支付请求被批准，则可以向服务提供者支付金额。附加地或替代地，获取模块410可以接收由第二用户发起的第二支付请求和与提供给第二用户的服务有关的第二信息。

确定模块420可以确定与支付管理有关的数据。在一些实施例中，确定模块420可以至少基于第一地理信息与第二地理信息之间的比较的结果，根据预设规则，确定支付请求是否被批准(即，有资格被批准)。在一些实施例中，第一地理信息可包括第一字符串(例如，用于描述服务提供者的实体的位置的字符或单词)，且第二地理信息可以包括第二字符串(用于描述向用户提供服务的位置的字符或单词)。确定模块420可以确定第一字符串和第二字符串之间的相似度。响应于确定第一字符串与第二字符串之间的相似度超过相似度阈值(例如，0.4、0.5)，确定模块420可以确定支付请求合格(即，支付请求被成功验证)。

在一些实施例中，确定模块420可以基于第一地理信息确定第一区域，并基于第二地理信息确定第二区域。确定模块420还可以确定第一区域和第二区域之间的重合。预设规则可以包括响应于确定第一区域和第二区域之间的重合超过重合阈值，确定模块420可以确定服务提供者的位置(可互换地称为第一地理位置)与向用户提供服务的位置(可互换地称为第二地理位置)相关，并且报销合格。在一些实施例中，重合阈值可以表示为第一区域或第二区域的比例(例如，0.4、0.5)。

在一些实施例中，确定模块420可以确定与服务有关的持续时间(即，滞留时长)。预设规则可以包括响应于确定与服务有关的持续时间超过时间阈值，确定模块420可以确定支付请求合格。

在一些实施例中，确定模块420可以根据第一预设规则，通过验证第一信息，生成第一验证结果。确定模块420可以根据第二预设规则，通过验证第一用户是否被授权发起一支付请求，生成第二验证结果。确定模块420还可以至少基于第一验证结果和第二验证结果，确定第一用户发起的第一支付请求是否有资格被批准。在一些实施例中，确定模块420可以确定与第一支付请求相关联的第一时间点和与第二报销相关联的第二时间点之间的时间差。响应于确定时间差小于预设时间，处理引擎112可以验证第一用户没资格发起第一支付请求。在一些实施例中，确定模块420还可以根据第三预设规则，通过验证第二信息，生成第三验证结果。确定模块420可以至少基于第三验证结果，确定第二支付请求是否有资格被批准。

交易模块430可以将金额交易到金融账户。在一些实施例中，支付请求可以与报销相关联。交易模块430可以将支付金额交易到第二用户的金融账户。在一些实施例中，支付请求可以与提供给第二用户的服务的支付相关联。交易模块430可以将支付金额交易到第一用户的金融账户(例如，服务提供者)。

图4中的模块可以通过有线连接或无线连接彼此连接或通信。有线连接可以包括金属线缆、光缆、混合电缆等或其任意组合。无线连接可以包括局域网络(LAN)、广域网络(WAN)、蓝牙、紫蜂网络、近场通信(NFC)等或其任意组合。在一些实施例中，可以将两个或以上模块组合成单个模块，并且可以将任何一个模块划分为两个或以上单元。在一些实施例中，图4中的模块中的一个或多个可以被省略。例如，交易模块430可以被省略。

图5是根据本申请的一些实施例所示的用于支付管理的示例性过程的流程图。过程500可以由支付管理系统100执行。例如，过程500可以实现为存储在存储器(例如，计算设备200的ROM 230或RAM 240)中的一组指令(例如，应用程序)。处理引擎112、图4中的模块和/或图10中的单元可以执行一组指令，并且当执行指令时，处理引擎112和/或模块可以被配置为执行过程500。以下呈现的所示过程500的操作旨在是说明性的。在一些实施例中，过程500可以利用未描述的一个或多个附加操作，和/或没有所讨论的一个或多个操作来完成。另外，如图5所示和下面描述的过程500的操作的顺序不是限制性的。

在502中，处理引擎112(例如，获取模块410)可以接收支付请求，该支付请求包括与服务提供者提供给用户的服务有关的信息。与服务有关的信息可以包括服务提供者的第一地理信息。具体地，处理引擎112可以从与用户相关联的请求者终端(例如，图1中所示的用户终端130)接收支付请求。例如，用户可以是公司、政府部门、非营利组织等的雇员。支付请求可以与报销相关联。又例如，用户可以是服务请求者。在一些实施例中，用户可以发起支付请求以支付提供给用户的服务(即，服务请求者)。用户可以通过提供与服务有关的信息来发起支付请求。如这里所使用的，支付请求可互换地被称为支付请求或费用支付请求。如果确定支付请求合格，则用户的雇主可以向用户支付对应于服务的支付金额。例如，服务可以包括但不限于住宿服务、食品和饮料服务、运输服务等，或其任何组合。

在一些实施例中，与服务有关的信息可以包括向服务提供者提供服务的时间、向服务提供者提供服务的位置、为服务支付的费用、服务的持续时间、支付金额等，或其任何组合。用户可以经由请求者终端在报销单上填写与服务有关的信息。在一些实施例中，与服务有关的信息可以包括向用户提供服务的服务提供者的第一地理信息。具体地，第一地理信息可以包括服务提供者的实体(例如，餐馆或旅馆)的地理位置。在一些实施例中，与服务有关的信息可以包括对应于服务的消费凭证(例如，发票的照片、电子发票)，其可以包括服务提供者的地址。可以基于服务提供者的地址来确定第一地理信息。

在一些实施例中，请求者终端可以加密支付请求，并将加密的支付请求传输到处理引擎112。例如，请求者终端可以使用其私钥和/或通过对支付请求进行数字签名来加密支付请求。在一些实施例中，加密的支付请求可以包括与请求者终端和/或请求者(即，请求者终端的用户)有关的认证信息，例如请求者的标识、请求者输入的密码、请求者终端的数字签名。认证信息可以允许处理引擎112验证请求者终端和/或请求者。

在504中，处理引擎112(例如，获取模块410)可以获取向用户提供服务的位置的第二地理信息。在一些实施例中，第二地理信息可以由终端设备(例如，移动电话或智能手表)的定位收发器组件使用定位技术生成。例如，定位技术可以通过全球定位系统(GPS)、全球导航卫星系统(GLONASS)、伽利略定位系统、准天顶卫星系统(QZSS)、北斗导航卫星系统、无线保真(WiFi)定位技术等，或其任何组合来实现。在一些实施例中，第二地理信息可以包括规定的地理位置。规定的地理位置可以由用户的雇主预先确定。例如，规定的地理位置可以是为用户预订的酒店的位置，或者是用户的商务旅行的目的地。

在506中，处理引擎112(例如，确定模块420)可以至少基于第一地理信息和第二地理信息之间的比较的结果，根据预设规则，确定支付请求是否被批准(即，有资格被批准)。在一些实施例中，第一地理信息可包括第一字符串(例如，用于描述服务提供者的实体的位置的字符或单词)，且第二地理信息可以包括第二字符串(用于描述向用户提供服务的位置的字符或单词)。处理引擎112可以确定第一字符串和第二字符串之间的相似度。响应于确定第一字符串与第二字符串之间的相似度超过相似度阈值(例如，0.4、0.5)，处理引擎112可以确定支付请求合格(即，支付请求被成功验证)。在一些实施例中，预设规则可以包括响应于确定第一字符串和第二字符串之间的相似度小于或等于相似度阈值，处理引擎112可以确定支付请求不合格(即，支付请求可以不被批准)。

在一些实施例中，处理引擎112可以基于第一地理信息确定第一区域，并基于第二地理信息确定第二区域。处理引擎112还可以确定第一区域和第二区域之间的重合。预设规则可以包括响应于确定第一区域和第二区域之间的重合超过重合阈值，处理引擎112可以确定服务提供者的位置(可互换地称为第一地理位置)与向用户提供服务的位置(可互换地称为第二地理位置)相关联，并且报销合格。在一些实施例中，重合阈值可以表示为第一区域或第二区域的比例(例如，0.4、0.5)。

在一些实施例中，处理引擎112可以确定与服务相关的持续时间(即，滞留时长)。预设规则可以包括响应于确定与服务有关的持续时间超过时间阈值，处理引擎112可以确定支付请求合格。关于确定报销是否合格的更多描述可以在本申请的其他地方找到，例如，在图7、图8、图9和/或其描述中。

在508中，响应于确定支付请求被批准，处理引擎112(例如，确定模块420)可以基于支付请求，确定与提供给用户的服务相关联的支付金额。具体地，可以基于支付请求中包括的发票(例如，电子发票)，确定支付金额。

在510中，处理引擎112(例如，确定模块420)可以生成包括支付金额的授权消息。授权消息可以被发送到与雇用用户的组织(例如，公司)的财务人员相关联的终端设备。授权消息可以用于授权财务人员将支付金额交易给用户。在一些实施例中，处理引擎122可以生成通知消息以通知用户支付请求已经被批准，并且一定金额将被交易到用户的金融账户。

在512中，处理引擎112(例如，交易模块430)可以将支付金额交易到金融账户。在一些实施例中，支付请求可以与报销相关联。支付金额可以被交易到用户的金融账户。在一些实施例中，支付请求可以与提供给第二用户的服务的支付相关联。支付金额可以被交易到服务提供者的金融账户。金融账户可以包括例如银行账户，或者诸如微信钱包、支付宝、PayPal等账户的第三方电子账户。在一些实施例中，支付金额可以由财务人员交易到用户的金融账户。

应当注意以上对图5的描述仅用于说明的目的，而不是为了限制本申请的范围。对于本领域的普通技术人员来说，可以根据本申请的描述，做出各种各样的变化和修改。然而，这些变化和修改不会背离本申请的范围。在一些实施例中，操作502和操作504可以以任何顺序同时或按顺序执行。

图6是根据本申请的一些示例性实施例所示的支付管理过程的流程图。过程600可以由图1中所示的支付管理系统100或图10中所示的支付管理系统1000执行。例如，过程600可以实现为存储在存储器(例如，计算设备200的ROM 230或RAM 240)中的一组指令(例如，应用程序)。处理引擎112、图4中的模块和/或图10中的单元可以执行一组指令，并且当执行指令时，处理引擎112和/或模块可以被配置以执行过程600。以下呈现的所示过程600的操作旨在是说明性的。在一些实施例中，过程600可以利用未描述的一个或多个附加操作，和/或没有所讨论的一个或多个操作来完成。另外，如图6所示和下面描述的过程600的操作的顺序不是限制性的。如图6所示，根据本申请的实施例的支付管理过程可包括以下操作。

在602中，可以接收对应于消费行为的支付请求和相关消费凭证。消费凭证可以包括提供消费凭证的实体的位置信息。

在604中，可以获取消费行为发生的位置。

在606中，响应于确定位置信息与消费行为发生的位置不相关，处理引擎112可以确定不执行支付。

在日常工作中，每天都会发生大量的消费行为，因此产生了报销支付需求。在一些实施例中，消费凭证可包括收据、发票、交易记录等，或其任何组合。支付请求可以由用户(例如，雇员)发起以进行报销。在一些实施例中，支付请求可互换地被称为偿还支付请求。在一些实施例中，在接收到支付请求和消费凭证之后，通常手动检查支付请求和消费凭证。通过这种方式，需要进行大量的筛选和验证工作，这很容易导致错误和遗漏。

例如，来自用户的支付请求可以与某个地方的住宿费用相关联。用户可以提供五张发票。财务人员可能需要检查并对五个发票中的每一个进行统计，以获得诸如发票是不是住宿发票、与发票相关的金额、住宿日期等，或其任何组合的信息。该过程可能是低效且棘手的，并且财务人员只能根据来自用户的检查发票的请求，确定消费发生的地点。

在一些实施例中，由报销支付请求提供的发票可以具有发票提供者的地址，也就是说，提供发票的服务提供者的实体的位置信息(可互换地称为第一地理信息)。例如，处理引擎112可以使用光学字符识别(OCR)技术，基于发票、电子发票等的照片，识别第一地理信息。可以基于提供证据的实体的位置信息，完成消费行为发生的实际位置与提供证据的实体的位置之间的比较，从而可以确定消费行为的有效性。仅作为示例，如果用户前往出差A，则A是消费行为发生的位置。但如果住宿发票是由酒店B发出的，显然，这两个地方不匹配。消费行为可以是无效的消费行为，并且可以不执行报销支付(例如，由处理引擎112或由财务人员执行)。

通过过程600，提供关于消费行为是否有效或消费凭证是否真实的证据，这样可以减少错误识别的可能性、支付工作的错误率、支付无效消费行为的可能性以及劳动强度。因此，可以提高公司的整体工作效率。

可以有各种方式来获取与消费行为有关的位置。例如，可以基于要执行的任务的地址，确定消费行为发生的位置，该地址可以包括在公司调度的任务中。公司安排的任务可以存储在处理引擎112可访问的存储设备中。又例如，可以通过使用用户持有的移动终端的定位技术，获取与消费行为有关的位置。具体地，可以通过与用户相关联的终端设备的定位收发器组件(例如，使用GPS定位技术)获取与第二地理信息的消费行为的位置有关的信息。关于确定位置信息是否与消费行为发生的位置相关的细节也可以在本申请的其他地方找到，例如，在图7和图8中。

图7是根据本申请的一些示例性实施例所示的支付管理过程的流程图。过程700可以由图1中所示的支付管理系统100或图10中所示的支付管理系统1000来执行。例如，过程700可以实现为存储在存储器(例如，计算设备200的ROM 230或RAM 240)中的一组指令(例如，应用程序)。处理引擎112、图4中的模块和/或图10中的单元可以执行一组指令，并且当执行指令时，处理引擎112和/或模块可以被配置为执行过程700。以下呈现的所示过程700的操作旨在是说明性的。在一些实施例中，过程700可以利用未描述的一个或多个附加操作，和/或没有所讨论的一个或多个操作来完成。另外，如图7所示和下面描述的过程700的操作的顺序不是限制性的。如图7所示，确定位置信息是否与消费行为发生的位置相关可以包括以下操作。

在702中，可以确定与位置信息(即，第一地理信息)有关的第一字符串和与消费行为发生的位置有关的第二字符串。

在704中，可以将第一字符串和第二字符串串之间的重合率(可互换地称为相似度)与预设概率进行比较，以确定重合率是否小于预设概率。

在706中，如果重合率大于或等于预设概率，则可以确定位置信息与消费行为发生的位置相关。

在708中，如果重合率小于预设概率，则可以确定位置信息与消费行为发生的位置不相关。

在一些实施例中，可以基于第一字符串和第二字符串中匹配(例如，完全相同或同义)的字符或单词(表示为“n”)的数量，确定第一字符串和第二字符串之间的重合率。具体地，重合率可以等于n除以第一字符串或第二字符串中的字符或字的总数。预设概率可以是支付管理系统100的默认值，或者可以由管理员(例如，负责管理支付管理系统100的系统管理员)设置。例如，预设概率可以是0.45、0.50、0.55、0.60，或更多或更小。

例如，用户可以发起与到达A省B市C路的商务旅行相关的支付请求(即规定的地理位置)，并提供住宿消费的发票，金额为500元。“Road C,City B,Province A”是指示消费行为发生的第二字符串。提供用户提供的发票的实体地址是A省B市C路13号，也就是说，表示提供发票的实体的位置信息的第一字符串是“No.13,Road C,City B,Province A”。在这种情况下，第一字符串和第二字符串之间的重合率高于60％。例如，预设概率可以是50％，并且重合率可以大于预设概率。因此，对于用户的住宿消费行为，应该确定位置信息与消费行为发生的位置相关，并且消费行为是有效的。支付请求可被确定为合格。500元可以交易到用户的金融账户。

如果发出用户提供的发票的实体地址为“No.15,Road E,City D,Province A”，字符串之间的重合率仅为25％，小于预设概率(例如，50％)。然后，发布用户提供的发票的实体的位置信息与消费行为发生的位置无关，并且用户的住宿消费行为被认为是无效的。支付请求可被确定为不合格。可以将通知消息发送到与用户相关联的请求者终端，以通知用户该支付请求不合格，并且用户可能需要检查与提供给用户的服务有关的信息和/或修改支付请求。

图8是根据本申请的一些示例性实施例所示的支付管理过程的流程图。过程800可以由图1中所示的支付管理系统100或图10中所示的支付管理系统1000执行。例如，过程800可以实现为存储在存储器(例如，计算设备200的ROM 230或RAM 240)中的一组指令(例如，应用程序)。处理引擎112、图4中的模块和/或图10中的单元可以执行一组指令，并且当执行指令时，处理引擎112和/或模块可以被配置以执行过程800.以下呈现的所示过程800的操作旨在是说明性的。在一些实施例中，过程800可以利用未描述的一个或多个附加操作，和/或没有所讨论的一个或多个操作来完成。另外，如图8所示和下面描述的过程800的操作的顺序不是限制性的。

图8提供了用于确定位置信息是否与消费行为发生的位置相关的备选确定过程。

如图8所示，确定位置信息是否与消费行为发生的位置相关可以包括以下操作。

在802中，可以确定与位置信息(即，第一地理信息)有关的第一区域和与消费行为发生的位置有关的第二区域。

在804中，可以确定第一区域和第二区域之间的重合面积(可互换地称为重合)。

在806中，可以确定重合面积是否小于预设面积。

在808中，如果重合面积小于预设面积，则可以确定位置信息与消费行为发生的位置不相关。

在810中，如果重合面积不小于(即，大于或等于)预设面积，则可以确定位置信息与消费行为发生的位置相关。

如这里所使用的，第一区域可以包括发布发票的服务提供者的实体的位置(即，第一地理位置)，和第二区域可以包括消费行为发生的位置(即第二地理位置)。在一些实施例中，第一区域或第二区域可以是住宅社区、区域、城镇、城市、省等。在一些实施例中，第一地理位置和第二地理位置可以由地理坐标表示。第一区域可以是距表示第一地理位置的地理坐标预定距离内的区域。第二区域可以是距表示第二地理位置的地理坐标预定距离内的区域。例如，预定距离可以是1千米(km)、1.5千米、2千米或更多或更少。

在一些实施例中，重合面积可以是由第一区域和第二区域两者覆盖的一定量的面积。预设面积可以是预设的面积量，例如200平方米(m²)、500平方米、1000平方米、3000平方米或更多或更少。在一些实施例中，重合面积可以表示为比率。例如，可以通过将第一区域和第二区域所覆盖的面积除以第一区域或第二区域的面积来确定比率。在一些实施例中，预设面积可以是重合面积的预设比率，例如0.30、0.35、0.40。

通过确定与位置信息有关的第一区域和与消费行为发生的位置有关的第二区域，可以确定第一区域和第二区域的重合面积，当重合面积小于预设面积时，可以确定位置信息与消费行为发生的位置不相关。以这种方式，从实际地理位置和覆盖实际地理位置的区域的角度提供确定基础，并且可以提供定量标准以确定消费行为是否有效。这可能有利于实施支付工作的电子操作。附加地或替代地，该方法可以降低公司财务人员的劳动强度，并提高其工作的工作效率、准确性和及时性。该过程还可以减少人为错误和/或任意确定的可能性。

例如，如果用户前往A市的B区出差，在此期间产生出租车费，则在他返回公司后，他可以发起支付请求并提供100元的出租车发票，发票的实体地址是A市C区。然后A区C区是第一区域。由于用户前往A市B区的商务旅行，消费行为发生的地点，或第二区域，是A市B区。假设第一区域和第二区域的重合面积是50％，其大于预设面积(例如，40％)，则认为位置信息与消费行为发生的位置相关。如果发出用户提供的出租车发票的实体的地址是城市E，则第一区域和第二区域的重合区域是0，小于预设区域。这样，位置信息被认为与消费行为发生的位置不相关。

图9是根据本申请的一些示例性实施例所示的支付管理过程的流程图。过程900可以由图1中所示的支付管理系统100或图10中所示的支付管理系统1000来执行。例如，过程900可以实现为存储在存储器(例如，计算设备200的ROM 230或RAM 240)中的一组指令(例如，应用程序)。处理引擎112、图4中的模块和/或图10中的单元可以执行一组指令，并且当执行指令时，处理引擎112和/或模块可以被配置为执行过程900。以下呈现的所示过程900的操作旨在是说明性的。在一些实施例中，过程900可以利用未描述的一个或多个附加操作，和/或没有所讨论的一个或多个操作来完成。另外，如图9所示和下面描述的过程900的操作的顺序不是限制性的。根据本申请的另一实施例，支付管理过程可以包括以下操作，用于确定位置信息是否与消费行为发生的位置相关。

在902中，可以确定相关消费凭证的消费类别(例如，发票)。

在904中，可以确定与消费行为发生的位置有关的滞留时长是否小于与消费类别相对应的预设时长(即，时间阈值)。

在906中，如果发生消费行为的位置的滞留时长大于或等于对应于消费类别的预设时长，则可以执行支付。

在908中，如果发生消费行为的位置的滞留时长小于对应于消费类别的预设时长，则处理引擎112可以确定不执行支付。

消费类别可以指提供给用户的服务的类别。例如，消费类别可包括住宿、食物和饮料、运输(例如，出租车费、火车票价或机票价格)、采购等，或其任何组合。在一些实施例中，不同消费类别的服务可以对应于不同的预设滞留时长。如这里所使用的，术语“滞留时长”指的是用户停留在消费行为发生的位置处或附近的时间段。例如，对应于住宿的预设时长可以与用户在酒店中停留的夜数(例如，一晚、三晚)相关联。又例如，对应于运输的预设时长可包括运输所需的小时数。

例如，用户可以前往城市A进行商务旅行并在同一天返回，但是他发起支付请求并提供住宿发票。显然，如果用户在同一天进行往返，则住宿消费行为发生在24小时内(从用户离开城市A的时间开始)。对于住宿的消费类别，预设的持续时间至少为24小时。因此，用户的滞留时长小于预设时长，并且可能不执行支付。支付请求可被确定为不合格。

又例如，对于从城市A到城市B的运输，预设时长为2小时，并且用户提供其中行程时间为1小时的发票。行程时间小于预设时长，因此可能不执行支付。

通过过程900，提供了更加科学和准确的确定过程，用于确定连续消费是否正常，这可以减少不正确确定的可能性和不正确的报销数量。附加地或替代地，该过程可以提高劳动效率。

应当注意关于图5-9的以上描述仅仅是出于说明的目的而提供的，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，可以根据本申请的描述，做出各种各样的变化和修改。然而，这些变化和修改不会背离本申请的范围。

图10是根据本申请的一些示例性实施例所示的支付管理系统的示意框图。在一些实施例中，支付管理系统1000可以在处理引擎112上实现。处理引擎112可以与存储介质(例如，支付管理系统100的存储设备140，和/或终端设备300的存储器390)通信，并且可以执行存储在存储介质中的指令。例如，支付管理系统1000可以被配置为分别执行图5-9中所示的过程500、600、700、800和/或900。如图10所示，根据本申请的一些实施例，提供了支付管理系统1000。支付管理系统1000可以包括信息接收单元1010、位置获取单元1020和确定单元1030。

当执行支付管理时，信息接收单元1010可以接收支付请求和相关的消费凭证(例如，与提供给用户的服务有关的发票)。消费凭证可以包括提供相关消费凭证的服务提供者的实体的位置信息。因此，可以获取提供证据的实体的位置信息。在许多情况下，提供相关消费凭证的实体的位置信息可以是消费行为发生的位置。因此，获取提供证据的实体的位置信息可以提供用于识别消费行为的有效性的基本条件。此外，消费行为发生的位置可以由位置获取单元1020获取，并且可以与提供证据的实体的位置信息进行比较。确定单元1030可以确定位置信息是否与消费行为发生的位置相关。如果位置信息与消费行为发生的位置不相关，则可以确定消费行为无效。这可能是由用户犯的错误或用户提供的虚假消费行为引起的。对于无效的消费行为，可以不执行任何支付。通过本申请的支付管理系统1000，可以提供消费行为的有效性的确定基础。可以减少关于由人类操作引起的消费行为的有效性的错误确定的可能性。可以减少支付工作的错误率，并且还可以减少支持无效消费行为的可能性。

具体地，如果用户发起用餐费用的支付请求，则信息接收单元1010可以接收餐费金额、餐馆名称和餐馆地址。餐厅的地址可能是位置A.位置获取单元1020可以基于例如用户提供的信息和/或用户携带的移动终端的定位信息，获取消费行为发生的位置B。确定单元1030可以确定消费行为的发生是B，然后确定单元1030可以确定A和B不是相同的位置。因此，确定单元1030可以确定用餐的位置信息与消费行为发生的位置不相关。消费行为被确定为无效。这一过程可以减少虚假报销的可能性，提高工作效率，从而提高支付审查的准确性，降低财务人员的劳动强度。

此外，确定单元1030具体可以包括字符确定子单元1040和第一执行子单元1050。

在一些实施例中，与位置信息有关的第一字符串和与消费行为发生的位置有关的第二字符串可以由字符确定子单元1040确定。第一执行子单元1050可以确定第一字符串和第二字符串之间的重合率。如果重合率小于预设概率，则第一执行子单元1050可以确定位置信息与消费行为发生的位置不相关。也就是说，从地理位置名称的角度来看，该过程为确定消费行为是否合格提供了定量标准。这可以有利于实施支付工作的电子化操作，降低公司财务人员的劳动强度，提高工作效率，工作的准确性和及时性，减少人为错误或任意确定的可能性。

在一些实施例中，确定单元1030还可包括区域确定子单元1060和第二执行子单元1070。

可以通过区域确定子单元1060，确定位置信息的第一区域和消费行为发生的位置的第二区域。通过第二执行子单元1070，可以确定第一区域和第二区域的重合面积，并且如果重合面积小于预设面积，可以确定位置信息与消费行为发生的位置不相关。也就是说，可以从实际地理位置和覆盖地理位置的区域的角度提供确定基础，并且提供定量标准以确定消费行为是否有效。这可以有利于实施支付工作的电子操作。附加地或替代地，该过程可以降低公司财务人员的劳动强度，提高他们工作的工作效率、准确性和及时性。该过程还可以减少人为错误和/或任意确定的可能性。

在一些实施例中，确定单元1030还可以包括类别确定子单元1080和拒付子单元1090。

确定子单元1080可以确定相关消费凭证的消费类别，并且可以粗略地确定消费类别的一般消费持续时间，也称为预设时长。如果消费行为发生的位置的滞留时长小于对应于消费类别的预设时长，拒付子单元1090可以确定用户在该位置没有消费行为，或者消费时间大大减少。该消费行为可能与正常的消费行为不一致。因此，消费行为很可能是无效的消费行为，并且可能不会执行支付。该过程可以提高支付管理的效率和确定的准确性，并提高与电子操作有关的便利性。

具体地，用户可以前往地点A进行商务旅行，并且用户可以请求支付住宿费。可以预定行程时间为3天，即预设时长为3天。但是通过移动终端或其他消费凭证(例如发票)的定位，发现用户实际上在地点A只住了一晚。也就是说，消费行为发生的位置的滞留时长小于预设时长。因此，可以确定用户的消费行为是无效的。可以不执行支付，并且可能需要修改或撤销支付请求。

图10中的单元可以通过有线连接或无线连接彼此连接或通信。有线连接可以包括金属线缆、光缆、混合电缆等或其任意组合。无线连接可以包括局域网络(LAN)、广域网络(WAN)、蓝牙、紫蜂网络、近场通信(NFC)等或其任意组合。在一些实施例中，可以将两个或以上模块组合成单个模块，并且可以将任何一个模块划分为两个或以上单元。

图11是根据本申请的一些示例性实施例所示的支付管理系统的示意图。该实施例与前述实施例相结合，提供了计算设备1120，如图11所示，用于控制支付管理系统1000。计算设备1120可以包括处理器1130和用作计算机可读存储介质的存储器1110，其中可以存储对应于支付管理方法的计算机程序。通过在计算设备1120上读取和执行计算机程序，可以执行支付管理方法以使支付管理系统1000能够执行支付管理的电子操作。这样，可以提高支付工作的自动化程度和工作效率，并且可以减少错误报销的可能性。

以上参考附图详细描述了本申请提供的支付管理方法。通过该方法，提供了支付管理的量化标准，可以促进支付管理的电子化操作，有效提高支付管理的便利性和准确性。附加地或替代地，该方法可以提高工作效率，降低劳动强度，并降低错误支持的可能性。

图12是根据本申请的一些示例性实施例所示的用于支付管理的示例性过程的流程图。过程1200可以由支付管理系统100执行。例如，过程1200可以实现为存储在存储器(例如，计算设备200的ROM 230或RAM240)中的一组指令(例如，应用程序)。处理引擎112、图4中的模块和/或图16-18中的单元可以执行一组指令，并且当执行指令时，处理引擎112和/或模块可以被配置为执行过程1200。以下呈现的所示过程1200的操作旨在是说明性的。在一些实施例中，过程1200可以利用未描述的一个或多个附加操作，和/或没有所讨论的一个或多个操作来完成。另外，如图12所示和下面描述的过程1200的操作的顺序不是限制性的。

在1202中，处理引擎112(例如，获取模块410)可以接收由第一用户发起的第一支付请求和与提供给第二用户的服务有关的第一信息。在一些实施例中，第一支付请求可以与由于商务原因提供给第二用户的服务相关联。第二个用户可能已经为该服务支付了费用。第一用户可以发起支付请求以允许第二用户通过个人或组织(例如，雇用用户的公司)获取回报(即，作为报销)。在一些实施例中，第一用户可以经由第一请求者终端(例如，用户终端130)代表第二用户(即，作为第二用户的代理)发起第一支付请求。如果确定支付请求被批准(即，合格)，则可以向第二用户支付对应于该服务的一定金额。在一些实施例中，支付请求可以与由第一用户向第二用户(即，服务请求者)提供的服务的支付相关联。服务请求者或服务提供者可以发起支付请求。例如，如果服务请求者或服务提供者发起的支付请求得到批准，则可以向服务提供者支付一定金额。

在一些实施例中，服务可以包括但不限于住宿服务、食品和饮料服务、运输服务等，或其任何组合。处理引擎112可以基于与服务相关的第一信息，确定一个或多个第一参数，例如，向第二用户提供服务的时间、向第二用户提供服务的位置、为服务支付的费用、服务的持续时间、支付金额等，或其任何组合。

在一些实施例中，第二用户可以由他/她自己经由第二请求者终端发起第二支付请求。处理引擎112还可以获取与提供给第二用户的服务有关的第二信息。

在1204中，处理引擎112(例如，确定模块420)可以确定第一信息是否合格。处理引擎112可以通过根据第一预设规则，验证第一信息，生成第一验证结果。在一些实施例中，处理引擎112可以基于与提供给第二用户的服务有关的第一信息，确定第一支付请求是否有资格被批准。具体地，处理引擎112可以基于与服务有关的第一信息，确定一个或多个第一参数。对于一个或多个第一参数，处理引擎112可以基于第一数据库，确定一个或多个第一匹配度。处理引擎112可以进一步确定第一匹配度是否大于对应的第一匹配阈值。响应于确定与一个或多个第一参数相关联的第一匹配度中的至少一个大于对应的第一匹配阈值，处理引擎112可以验证第一信息是否合格，即第一信息被成功验证。过程1200可以进行到操作1206。响应于确定一个或多个第一匹配度中的至少一个小于或等于一个或多个对应的第一匹配度，处理引擎112可以确定第一支付请求不合格。过程1200可以进行到操作1212。关于第一支付请求的验证的更多细节可以在本申请的其他地方找到，例如，在图14、图15和/或其描述中。

在1206中，处理引擎112(例如，确定模块420)可以确定第一用户是否有资格发起第一支付请求。处理引擎112可以根据第二预设规则，通过验证第一用户是否被授权发送第一支付请求，生成第二验证结果。处理引擎112可以至少基于第一验证结果和第二验证结果，确定第一支付请求是否被批准。例如，响应于确定第一信息是合格的并且第一用户有资格发起第一支付请求，处理引擎112可以确定第一支付请求有资格被批准。

例如，处理引擎112可以从存储设备(例如，支付管理140的存储设备140)获取与第一用户和/或第二用户有关的代理信息。代理信息可以指示第一用户是否有资格表示第二用户(例如，发起第一支付请求)。响应于确定第一用户有资格代表第二用户，过程1200可以进行到操作1208。响应于确定第一用户没有代表第二用户的资格，过程1200可以进行到操作1212。

在一些实施例中，处理引擎112可以接收由第一用户发起的第一支付请求和由第二用户发起的第二支付请求。在一些实施例中，处理引擎112可以确定与第一支付请求相关联的第一时间点和与第二报销相关联的第二时间点之间的时间差。具体地，第一时间点可以是接收到第一报销的时间点，并且第二时间点可以是接收到第二报销的时间点。处理引擎112可以进一步将时间差与预设时间进行比较。响应于确定时间差小于预设时间，处理引擎112可以验证第一用户没有发起第一支付请求的资格。在这种情况下，第一支付请求和第二支付请求可以对应于提供给第二用户的相同服务。为了避免为相同的服务支付两次报销，处理引擎112可以拒绝和/或忽略第一支付请求。

在一些实施例中，处理引擎112还可以通过根据第三预设规则，验证第二信息，生成第三验证结果。处理引擎112可以至少基于第三验证结果，确定第二支付请求是否有资格被批准。处理引擎112还可以以与操作1204类似的方式确定第二支付请求是否合格。具体地，处理引擎112可以基于与第二支付请求的服务相关的第二信息，确定一个或多个第二参数，并基于一个或多个第二参数，验证第二支付请求是否合格。

在1208中，处理引擎112(例如，确定模块420)可以生成授权消息，该授权消息包括与提供给第二用户的服务相关联的支付金额。如果第一支付请求有资格被批准，则处理引擎112可以基于与第一支付请求的服务相关的第一信息，确定支付金额。如果第二支付请求合格，则处理引擎112可以基于与第二支付请求的服务相关的第二信息，确定支付金额。

在1210中，处理引擎112(例如，交易模块430)可以将支付金额交易到金融账户。在一些实施例中，支付请求可以与报销相关联。支付金额可以交易到第二用户的金融账户。在一些实施例中，可以不允许第一用户改变用于接收对应于第一支付请求的支付金额的金融账户，这可以降低第二用户的财产损失风险。在一些实施例中，支付请求可以与提供给第二用户的服务的支付相关联。支付金额可以交易到第一用户的金融账户(例如，服务提供者)。

第一用户或第二用户的金融账户可以包括，例如，银行账户，或第三方电子账户，例如微信钱包、支付宝、PayPal等的账户。在一些实施例中，支付金额可以由财务人员交易到第一用户或第二用户的金融账户。

在1212中，处理引擎112可以确定拒绝或忽略第一支付请求。第一请求者终端可以向第一用户提供修改选项。第一用户可以修改与第一支付请求相关的不正确信息，并重新提交第一支付请求。或者，第一用户可以撤销第一支付请求。

应当注意以上对图12的描述仅用于说明的目的，而不是为了限制本申请的范围。对于本领域的普通技术人员来说，可以根据本申请的描述，做出各种各样的变化和修改。然而，这些变化和修改不会背离本申请的范围。应当注意，操作1204和操作1206可以以任何顺序同时或按顺序执行。例如，处理引擎112可以首先确定第一用户是否有资格代表第二用户，然后确定第一信息是否合格。

图13是根据本申请的一些示例性实施例所示的费用支付管理过程的流程图。过程1300可以由支付管理系统100执行。例如，过程1300可以实现为存储在存储器(例如，计算设备200的ROM 230或RAM 240)中的一组指令(例如，应用程序)。处理引擎112、图4中的模块和/或图16-18中的单元可以执行一组指令，并且当执行指令时，处理引擎112和/或模块可以被配置为执行过程1300。以下呈现的所示过程1300的操作旨在是说明性的。在一些实施例中，过程1300可以利用未描述的一个或多个附加操作，和/或没有所讨论的一个或多个操作来完成。另外，如图13所示和下面描述的过程1300的操作的顺序不是限制性的。如图13所示，费用支付管理的过程可以包括以下操作。

在1302中，可以接收与由第一用户发起的第二用户有关的费用支付请求(可互换地称为支付请求)。

在1304中，可以确定并验证与费用支付请求相对应的至少一条消费信息。

在1306中，可以验证第一用户是否被授权发起与第二用户有关的费用支付请求。

在1308中，在验证至少一条消费信息并且验证第一用户被授权发起与第二用户有关的费用支付请求之后，对应于至少一条消费信息的费用可以基于费用支付请求分配给第二用户的账户。

在一些实施例中，在1302中，可以接收与由第一用户发起的第二用户有关的费用支付请求，其也可互换地称为第一支付请求。费用支付请求可以对应于第二用户的消费行为。与消费行为有关的费用可以通过例如雇用第二用户的人或组织(例如，公司、政府部门)报销。例如，消费行为可以与提供给第二用户的服务有关，包括但不限于住宿服务、食品和饮料服务、运输服务等，或其任何组合。在一些实施例中，第一用户还可以提供与消费行为有关的消费凭证，例如收据、交易记录等，或其任何组合。在1304中，可以确定和验证对应于费用支付请求的至少一条消费信息，从而防止支付不存在的消费并避免财产损失。如这里所使用的，至少一条消费信息可以指与提供给第二用户的服务有关的信息。例如，至少一条消费信息可以包括服务的消费类别、与服务相关的费用金额、服务的时间、服务的位置、服务的持续时间、消费凭证等，或其任何组合。不存在的消费是指由费用支付请求中的错误或未发生的消费行为(即假的消费行为)引起的一条虚假消费信息。在1306中，验证第一用户是否被授权发起与第二用户有关的费用支付请求可以避免误操作或作弊，并且减少第一用户的支付费用被第一用户侵犯的可能性。在1308中，在两次验证成功完成后，即当对应于费用支付请求的消费信息是可信的并且第一用户被授权代表第二用户发起费用支付请求时，对应于至少一条消费信息的费用可以基于费用支付请求分配给第二用户的账户，因此可以完成费用支付处理。可以理解，对应于第二用户的账户可以是银行账户，也可以是第三方电子账户，例如来自微信钱包、支付宝、PayPal等的账户。应当注意第一用户代表第二用户可以不被允许给出改变账户用以接收对应于支付请求的费用的指令，以确保支付的安全性。

如这里所使用的，第二用户指的是生成消费信息的人(即，被提供服务的人)，第一用户是指第二用户授权的人，也称为第二用户的代理。为了减少过程的重复性，第二用户(即，生成消费信息的人)可以指定一个或多个第一个用户作为代理，并且一个或多个第一个用户可以代表第二个用户处理报销过程。应当注意第一用户可以不被允许指示更改接收与费用支付请求有关的费用的帐户，以确保支付的安全性。

另外，可以理解的是，费用支付请求中可以存在多条消费信息，不同的消费信息可以对应不同的第二用户。在一些实施例中，不止一个第二用户可以指定相同的第一用户作为用于发起费用支付请求的代理。因此，作为代理的第一用户可以为多个第二用户执行费用支付程序。

应当注意以上对图13的描述仅用于说明的目的，而不是为了限制本申请的范围。对于本领域的普通技术人员来说，可以根据本申请的描述，做出各种各样的变化和修改。然而，这些变化和修改不会背离本申请的范围。

图20是根据本申请的一些示例性实施例所示的在费用支付管理中预先添加第一用户的终端接口的示意图。图21是示出根据一些示例性实施例的在费用支付管理中预先添加第二用户的终端接口的示意图。终端接口可以显示在终端设备上，例如台式计算机、膝上型计算机、平板计算机等。在一些实施例中，根据预设过程，如图20和图21所示，第二用户和第一用户可以由管理员添加到支付管理系统100。例如，管理员可以将第一用户添加到名为“代理人员组”的人员组中。可以通过界面输入与第一用户有关的信息，例如第一用户的姓名、第一用户的工号、第一用户的部门等。管理员可以批量添加至少两个第一用户作为代表一个或多个第二用户发起费用支付请求的代理。第二用户可以添加到名为“要代表的人员组”的人员组中。类似地，管理员可以输入与第二用户有关的信息。管理员可以批量添加由第一用户表示的至少两个第二用户。

图22-26是根据本申请的一些示例性实施例所示的与费用支付管理有关的终端应用(APP)的示例性界面的示意图。终端APP可以安装在终端设备(例如，用户终端130)上。第一用户可以在图22所示的界面上提供与费用支付请求有关的信息，以生成报销表格。例如，与费用支付请求有关的信息可能包括公司名称、部门名称、项目等。在填写终端界面顶部的信息后，第一用户可以点击界面右下角的“代理”按钮，如图23所示。终端界面中间的弹出框可以用于选择(或输入)要代表的用户(即第二用户)。第一用户还可以添加与费用支付请求有关的评论，以提供与费用支付请求有关的附加信息。在选择要表示的第二个用户之后，第一个用户可以点击“确认”按钮继续下一个操作，或者点击“取消”按钮修改与费用支付请求有关的信息。如图24所示，在第一用户点击“确认”按钮后，可以在终端界面上显示相应的代理信息。第一用户可以选择或输入他/她自己的名字，然后点击“确认”按钮和“下一步”按钮继续下一步操作。如图25所示，终端界面可以显示第一用户的提交信息，包括姓名、部门等，终端界面也可以显示支付金额。还可以显示与报销表格有关的简要信息，例如填写报销表格的日期、报销类别(例如，福利-其他)、支付金额、地点、有/无发票等。单击底部的“提交”按钮后，可以显示终端界面，如图26所示。报销表格的评论历史可以在下面显示以供查看。具体地，评论历史可以包括与报销表格相关的时间和状态。例如，评论历史可以示出在2018年4月8日17:56，A(例如，第一用户的名称)代表提交报销表格的B(例如，第二用户的名称)，并且报销表格正在等待C(例如，财务人员、部门经理)进行审查。

图27-28是根据本申请的一些示例性实施例所示的与费用支付管理相关的示例性计算机接口的示意图。第一用户可以在图27所示的计算机接口上提供与费用支付请求有关的信息，以生成报销表格。例如，与费用支付请求有关的信息可能包括公司名称、部门名称、项目等。在添加要代表的人(即，第二用户)之后，第一用户可以点击“代理”按钮以创建新的报销表格。如图28所示，第一用户可以修改费用金额并提交该报销表格。类似地，评论历史可以显示在界面的左下角以供查看。

应当注意关于图20-28的以上描述仅仅是出于说明的目的而提供的，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，可以根据本申请的描述，做出各种各样的变化和修改。然而，这些变化和修改不会背离本申请的范围。例如，与终端设备上实现的费用支付管理系统相关联的界面中的图形和文字可能看起来与图20至28中所示的界面不同。又例如，可以通过接口实现更多功能或更少功能。

图14是根据本申请的一些示例性实施例所示的费用支付管理过程的流程图。过程1400可以由支付管理系统100执行。例如，过程1400可以实现为存储在存储器(例如，计算设备200的ROM 230或RAM 240)中的一组指令(例如，应用程序)。处理引擎112、图4中的模块和/或图16-18中的单元可以执行一组指令，并且当执行指令时，处理引擎112和/或模块可以被配置为执行过程1400。以下呈现的所示过程1400的操作旨在是说明性的。在一些实施例中，过程1400可以利用未描述的一个或多个附加操作，和/或没有所讨论的一个或多个操作来完成。另外，如图14所示和下面描述的过程1400的操作的顺序不是限制性的。如图14所示，费用支付管理的过程可以包括以下操作。

在1402中，可以接收与第一用户发起的第二用户有关的费用支付请求。

在1404中，可以确定接收到由第一用户发起的费用支付请求的时间点(即，第一支付请求)以及接收到第二用户发起的费用支付请求(即，第一支付请求)的时间点之间的时间差。

在1406中，如果时间差不大于预设时间长度，则可以基于第二用户发起的费用支付请求确定至少一条消费信息。

在1408中，可以验证至少一条消费信息和第一用户的代理。

在1410中，在验证至少一条消费信息并且验证第一用户被授权发起与第二用户有关的费用支付请求之后，对应于至少一条消费信息的费用可以基于费用支付请求分配给第二用户的账户。

在一些实施例中，在1402中，可以接收与第一用户发起的与第二用户有关的费用支付请求。费用支付请求可以与提供给第二用户的服务有关。还可以接收由第二用户发起的费用支付请求。在1404中，可以确定在接收到由第一用户发起的费用支付请求的时间点与接收到由第二用户发起的费用支付请求的时间点之间的时间差。在1406中，如果时间差不大于(即小于或等于)预设时间长度，则可以基于第二用户发起的费用支付请求确定至少一条消费信息。如果接收第一支付请求的时间点接近于接收第二支付请求的时间点，则第一支付请求和第二报销可以对应于提供给第二用户的相同服务。这可能导致与提供给第二用户的服务相关的费用被支付报销两次。因此，可以基于第二支付请求，确定至少一条消费信息。第一支付请求可以被拒绝。预设时间长度可以是例如三天、一周、两周、一个月等。预设时间长度可以是支付管理系统100的默认值或由管理员设置。在1408中，可以验证至少一条消费信息以及第一用户是否被授权发起与第二用户有关的费用支付请求，从而防止支付不存在的消费并避免财产损失。在1410中，在至少一条消费信息以及第一用户是否被授权发起与第二用户有关的费用支付请求被成功验证之后，对应于至少一条消费信息的费用可以基于费用支付请求，分配给第二用户的账户。费用支付过程可以由消费者用户(即第二用户)控制，从而确保支付的安全性。具体地，作为代理的第一用户可以不被允许给出改变用于接收与费用支付请求相关的费用的帐户的指令。

图15是根据本申请的一些示例性实施例所示的费用支付管理过程的流程图。过程1500可以由支付管理系统100执行。例如，过程1500可以实现为存储在存储器(例如，计算设备200的ROM 230或RAM 240)中的一组指令(例如，应用程序)。处理引擎112、图4中的模块和/或图16-18中的单元可以执行一组指令，并且当执行指令时，处理引擎112和/或模块可以被配置为执行过程1500。以下呈现的所示过程1500的操作旨在是说明性的。在一些实施例中，过程1500可以利用未描述的一个或多个附加操作，和/或没有所讨论的一个或多个操作来完成。另外，如图15所示和下面描述的过程1500的操作的顺序不是限制性的。

如图15所示，费用支付管理的过程包括以下操作。

在1502中，可以接收与第一用户发起的第二用户有关的费用支付请求。

在1504中，可以确定接收到由第一用户发起的费用支付请求的时间点(即，第一支付请求)以及接收到第二用户发起的费用支付请求(即，第一支付请求)的时间点之间的时间差。

在1506中，如果时间差不大于预设时间长度，则可以基于第二用户发起的费用支付请求，确定至少一条消费信息。

在1508中，可以验证至少一条消费信息以及第一用户是否被授权发起与第二用户有关的费用支付请求。

在1510中，在验证至少一条消费信息并且验证第一用户被授权发起与第二用户有关的费用支付请求之后。可以删除对应于第二用户的至少一个第一用户的信息和至少一个第一用户的任何/或费用支付请求。

在1512中，对应于至少一条消费信息的费用可以基于费用支付请求分配给第二用户的账户。

在一些实施例中，在1502中，可以接收与由第一用户发起的第二用户有关的费用支付请求。费用支付请求可以与提供给第二用户的服务有关。在1504中，可以确定在接收到第一用户发起的费用支付请求的时间点与第二用户发起的费用支付请求的时间点之间的时间差。在1506中，如果时间差不大于预设时间长度，则可以基于由第二用户发起的费用支付请求(即，第二支付请求)，确定至少一条消费信息。如果时间差大于预设时间长度，则处理引擎112可以基于由第一用户发起的费用支付请求(即，第一信息)，确定至少一条消费信息。在1508中，可以验证至少一条消费信息以及第一用户是否被授权发起与第二用户有关的费用支付请求，从而防止支付不存在的消费并避免财产损失。附加地或替代地，这可以防止第一用户的误操作或作弊，并且避免第一用户侵犯与第二用户有关的费用的可能性。在1510中，在至少一条消费信息之后，第一用户是否被授权发起与第二用户有关的费用支付请求被成功验证，可以删除与第二用户对应的至少一个第一用户的信息和至少一个第一用户的任何费用支付请求。换句话说，支付管理系统100可以取消第一用户代表第二用户发起或修改费用支付请求的代理。在一些实施例中，第一用户的代理可以在特定时间段(例如，一周或一个月)内保持被取消，然后在该特定时间段之后再次自动变为有效。在一些实施例中，第一用户的代理可以保持被取消，直到管理员或第二用户将代理重新指定给第一用户为止。支付管理系统100也可以删除第一用户的任何费用支付请求。在此阶段，只有第二用户可能有权在费用支付过程中修改第二支付请求，因此第一用户侵犯第二用户费用的可能性可能会降低。在1512中，对应于至少一条消费信息的费用可以基于费用支付请求分配给第二用户的账户。由于费用支付请求由消费者用户(即，第二用户)控制，因此可以确保支付的安全性。

可以进一步验证至少一条消费信息，具体可以包括：确定与消费信息相关的至少一个消费参数，基于存储至少一条消费信息的消费系统数据库，确定至少一个消费参数中的每一个的匹配度。如果所有匹配度都大于相应的匹配阈值，则可以确定验证成功(即，至少一条消费信息是真实的)；否则，可以将验证确定为失败(即，至少一条消费信息是不真实的)。消费参数可以包括但不限于消费时间、消费位置、消费类别、消费持续时间、费用金额等，或其组合。

在一些实施例中，可以具体地验证至少一条消费信息包括确定与消费信息有关的至少一个消费参数，并确定存储至少一条消费信息的消费系统数据库中的至少一个消费参数中的每一个的匹配度。可以理解，消费信息越相似，匹配度越高。因此，可以将匹配度与匹配阈值进行比较以验证至少一条消费信息。如果所有匹配度都大于相应的匹配阈值，则消费信息可能是真实的，验证可能成功；否则，消费信息可能是不真实的，验证可能会失败。消费参数可以包括但不限于消费时间、消费位置、消费类别、消费持续时间、费用金额等，或其组合。不同的消费参数可以用于验证不同的消费信息，从而提高验证的准确性。例如，对于与运输服务有关的消费信息，可以选择消费时间和消费持续时间，验证消费信息。又例如，对于与住宿服务有关的消费信息，可以选择消费位置和消费时长，验证消费信息。

在一些实施例中，消费系统数据库可以在存储设备上实现，例如支付管理系统100的存储设备140。在一些实施例中，消费系统数据库可以包括至少一条消费信息、与提供给第二用户的服务有关的规定信息、消费凭证等，或其任何组合。例如，与提供给第二用户的服务有关的规定信息可以由管理员规定，其可以包括但不限于商务旅行的规定位置(例如，目的地)、运输工具(例如，火车)的规定持续时间、运输工具的规定时间(例如，出发时间)等。在一些实施例中，可以基于规定信息或与提供给第二用户的服务有关的消费凭证，确定参考参数。可以确定消费参数和参考消费参数之间的匹配度。

在一些实施例中，可以以与图7至9中所示的过程700、过程800和过程900类似的方式来执行对至少一条消息信息的验证。与不同消费参数有关的匹配度可以对应于不同的匹配阈值。例如，可以基于服务提供者的第一地理信息和指示向第二用户提供服务的位置的第二地理信息，确定与消费位置相关联的匹配度。具体地，可以基于与第一地理信息(例如，地址)有关的第一字符串和与第二地理信息有关的第二字符串之间的相似，来确定与消费位置相关的匹配度。基于第一字符串和第二字符串串之间的相似度确定的匹配度的匹配阈值可以是例如0.40、0.45、0.50等。或者，可以基于与第一地理信息有关的第一区域和与第二地理信息有关的第二区域之间的重合率，确定与消费位置相关的匹配度。例如，匹配阈值可以是0.50、0.55、0.60等。

图16是根据本申请的一些示例性实施例所示的费用支付管理系统的示意图。在一些实施例中，费用支付管理系统1600可以在处理引擎112上实现。处理引擎112可以与存储介质(例如，支付管理系统100的存储设备140，和/或终端设备300的存储器390)通信，并且可以执行存储在存储介质中的指令。例如，支付管理系统1600可以被配置为分别执行图12-15中所示的过程1200、1300、1400和/或1500。如图16所示，费用支付管理系统1600可以包括：

请求接收单元1610，被配置为接收与第一用户发起的第二用户有关的费用支付请求；

信息验证单元1620，被配置为确定对应于费用支付请求的至少一条消费信息，并验证所述至少一条消费信息；

代理验证单元1630，被配置为验证第一用户是否被授权代表第二用户发起费用支付请求；以及

执行单元1640，在至少一条消费信息并且第一用户是否被授权发起与第二用户有关的费用支付请求被成功验证之后，基于费用支付请求，被配置为分配向第二用户的账户对应于至少一条消费信息的费用。

在一些实施例中，请求接收单元1610可以被配置为接收与第一用户发起的第二用户有关的费用支付请求。信息验证单元1620可以被配置为确定与费用支付请求相对应的至少一条消费信息并验证至少一条消费信息，从而防止支付不存在的消费并避免财产损失。代理验证单元1630可以被配置为验证第一用户是否被授权代表第二用户发起费用支付请求。在至少一条消费信息和第一用户是否被授权发起与第二用户有关的费用支付请求成功验证之后，执行单元408可以基于对第二用户的账户的费用支付请求，分配与消费信息相对应的费用。可以理解的是，第二用户对应的账户可以是银行账户，也可以是第三方账户，如微信钱包、支付宝、PayPal等账户。应当注意代表第二用户(即第一用户)的代理可以不被允许给出改变接收支付账户的指令，以确保支付的安全性。

如这里所使用的，第二用户指的是生成消费信息的人(即，被提供服务的人)，第一用户是指第二用户授权的人，也称为第二用户的代理。为了减少过程的重复性，第二用户(即，生成消费信息的人)可以指定一个或多个第一个用户作为代理，并且一个或多个第一用户可以代表生成消费的第二用户处理报销过程。应当注意第一个代理用户可能不被允许指示更改接收与费用支付请求有关的费用的帐户，以确保支付的安全性。

另外，可以理解的是，费用支付请求中可以存在多条消费信息，不同的消费信息可以对应不同的第二用户。而且，每个第二用户指定的第一用户可以是独立的。在一些实施例中，不止一个第二用户可以指定相同的第一用户作为用于发起费用支付请求的代理。因此，作为代理的第一用户可以为多个第二用户执行费用支付程序。

图17是根据本申请的一些示例性实施例所示的费用支付管理系统的示意图。在一些实施例中，费用支付管理系统1700可以在处理引擎112上实现。处理引擎112可以与存储介质(例如，支付管理系统100的存储设备140，和/或终端设备300的存储器390)通信，并且可以执行存储在存储介质中的指令。例如，支付管理系统1700可以被配置为分别执行图12至15中所示的过程1200、1300、1400和/或1500。如图17所示，费用支付管理系统1700可以包括：

请求接收单元1710，被配置为接收与第一用户发起的第二用户有关的费用支付请求；

时间差确定单元1720，被配置为确定收到第一用户发起的费用支付请求(即第一支付请求)的时间点与第二用户发起的费用支付请求(即，第一支付请求)的时间点之间的时间差；

代理覆盖单元1730被配置为如果时间差不大于预设时间长度，则基于第二用户发起的费用支付请求，确定至少一条消费信息；

信息验证单元1740，被配置为验证至少一条消费信息；

代理验证单元1750，被配置为验证第一用户是否被授权代表第二用户发起费用支付请求；以及

执行单元1760，被配置为在至少一条消费信息之后，根据费用支付请求，将与至少一条消费信息对应的费用分配给第二用户的账号以及是否成功验证了第一用户是否被授权发起与第二用户有关的费用支付请求。

在一些实施例中，请求接收单元1710可以接收与第一用户发起的第二用户有关的费用支付请求。时间差确定单元1720可以确定在接收到由第一用户发起的费用支付请求的时间点与接收到由第二用户发起的费用支付请求的时间点之间的时间差。如果第二用户与第一用户之间的时间差不大于预设时长，则代理覆盖单元1730可以基于第二用户发起的费用支付请求，确定至少一条消费信息。此时，费用支付请求可以由第二用户控制，从而确保支付的安全性。信息验证单元1740可以验证至少一条消费信息，从而防止支付不存在的消费并避免财产损失。代理验证单元1750可以被配置为验证第一用户是否被授权代表第二用户发起费用支付请求。在至少一条消费信息和第一用户是否被授权发起与第二用户有关的费用支付请求成功验证之后，执行单元1760可以基于费用支付请求将对应于至少一条消费信息的费用，分配给第二用户的账户。因此，可以完成费用支付过程。可以理解的是，第二用户对应的账户可以是银行账号，也可以是第三方电子账户，如微信钱包账号、支付宝、PayPal等。

图18是根据本申请的一些示例性实施例所示的费用支付管理系统的示意图。在一些实施例中，费用支付管理系统1800可以在处理引擎112上实现。处理引擎112可以与存储介质(例如，支付管理系统100的存储设备140，和/或终端设备300的存储器390)通信，并且可以执行存储在存储介质中的指令。例如，支付管理系统1800可以被配置为分别执行图12-15中所示的过程1200、1300、1400和/或1500。

如图18所示，费用支付管理系统1800可以包括：

请求接收单元1810，被配置为接收与第一用户发起的第二用户有关的费用支付请求；

时间差确定单元1820，被配置为确定收到第一用户发起的费用支付请求(即第一支付请求)的时间点与第二用户发起的费用支付请求(即，第一支付请求)的时间点之间的时间差；

代理覆盖单元1830，被配置为基于第二用户发起的费用支付请求，确定至少一条消费信息，如果时间差不大于预设时长；

信息验证单元1840，被配置为验证至少一条消费信息；

请求消除单元1850，被配置为在所述至少一条消费信息以及第一用户是否被授权发起与第二用户有关的费用支付请求被成功验证之后，删除所述第二用户对应的至少一个第一用户的信息和所述至少一个第一用户的费用支付请求；

代理验证单元1860，被配置为验证第一用户是否被授权代表第二用户发起费用支付请求；以及

执行单元1870，被配置为在至少一条消费信息以及第一用户是否被授权发起与第二用户有关的费用支付请求被成功验证之后，基于费用支付请求将对应于至少一条消费信息的费用，分配给第二用户的账户。

在一些实施例中，请求接收单元1810可以接收与第一用户发起的第二用户有关的费用支付请求。时间差确定单元1820可以确定在接收到由第一用户发起的费用支付请求的时间点与接收到由第二用户发起的费用支付请求的时间点之间的时间差。当第二用户与第一用户之间的时间差不大于预设时长时，代理覆盖单元1830可以基于第二用户发起的费用支付请求，确定至少一条消费信息。此时，费用支付请求可以由第二用户控制，从而确保支付的安全性。信息验证单元1840可以验证至少一条消费信息，从而防止支付不存在的消费并避免财产损失。代理验证单元1860可以被配置为验证第一用户是否被授权代表第二用户发起费用支付请求。在至少一条消费信息和第一用户是否被授权发起与第二用户有关的费用支付请求成功验证之后，请求消除单元1850可以删除与第二用户对应的至少一个第一用户的信息和至少一个第一用户的费用支付请求。此时，只有第二用户可以有权修改费用支付请求，从而降低了第一用户的费用被第一用户侵占的可能性，并增加了费用支付流程的安全性。执行单元1860可以基于费用支付请求将与至少一条消费信息相对应的费用，分配给第二用户的账户。因此，可以完成费用支付过程。可以理解的是，第二用户对应的账户可以是银行账号，也可以是第三方电子账户，如微信钱包账号、支付宝、PayPal等。

具体地，信息验证单元1840还可以包括：参数匹配单元，被配置为确定与消费信息有关的至少一个消费参数，并基于存储消费信息的消费系统数据库，确定每个消费参数的匹配度；比较单元，被配置为将每个消费参数的匹配度与对应的匹配阈值进行比较，并在所有匹配度大于对应的匹配阈值时确定验证成功；否则，验证可能会失败。消费参数可以包括但不限于消费时间、消费位置、消费类别、消费持续时间、费用金额等，或其组合。

在一些实施例中，参数匹配单元可以确定与消费信息有关的至少一个消费参数，并基于存储消费信息的消费系统数据库，确定每个消费参数的匹配度。可以理解，消费信息越相似，匹配度越高。因此，可以将匹配度与匹配阈值进行比较以验证至少一条消费信息。比较单元可以将每个获取的消费参数的匹配程度与相应的匹配阈值进行比较。如果所有匹配度都大于相应的匹配阈值，则消费信息可能是真实的，验证可能成功；否则，消费信息可能是不真实的，验证可能会失败。消费参数可以包括但不限于消费时间、消费位置、消费类别、消费持续时间、费用金额等，或其组合。不同的消费参数可以用于验证不同的消费信息，从而提高验证的准确性。

图19是根据本申请的一些示例性实施例所示的计算设备的示意图。图19是根据本申请的一些示例性实施例的计算设备的结构的示意图。

如图19所示，计算设备1900可以包括处理器1910和存储器1920.存储器1920可以存储可由处理器执行的计算机程序。当执行计算机程序时，处理器1910可以实现前述实施例的费用支付管理方法。

在一些实施例中，当计算设备的处理器1910执行存储器1920中的计算机程序时，可以实现任何前述实施例中的费用支付管理方法。因此，可以实现费用支付过程的标准化管理，这可以使得报销的费用支付更方便并且提高支付的安全性。

本申请还提出了一种存储计算机程序的计算机可读存储介质，该计算机程序在由处理器执行时实现任何实施例的费用支付管理方法。

在一些实施例中，当处理器执行计算机可读介质中的计算机程序时，可以实现任何实施例中的费用支付管理方法，并且可以实现费用支付处理的标准化管理。这可以使报销费用更方便，并提高支付的安全性。

上面参考附图详细描述了本申请提供的费用支付管理的过程。在该过程中，可以验证与费用支付请求相对应的至少一条消费信息，从而确保消费信息的真实性并防止支付费用被错误支付。该过程还包括验证费用支付请求的代理的资格，以确保第一用户具有代表第二用户的资格，这可以提高劳动效率并降低第一用户的费用被第一用户侵占的可能性。报销费用支付过程可能更加标准化，使报销费用支付更方便，提高了支付的安全性。

应当注意，关于图14-19的以上描述仅仅是出于说明的目的而提供的，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，可以根据本申请的描述，做出各种各样的变化和修改。然而，这些变化和修改不会背离本申请的范围。

上文已对基本概念做了描述，显然，对于阅读此申请后的本领域的普通技术人员来说，上述发明披露仅作为示例，并不构成对本申请的限制。虽然此处并未明确说明，但本领域的普通技术人员可能会对本申请进行各种修改、改进和修正。该类修改、改进和修正在本申请中被建议，所以该类修改、改进、修正仍属于本申请示范实施例的精神和范围。

同时，本申请使用了特定词语来描述本申请的实施例。例如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本申请至少一个实施例相关的某一特征、结构或特性。因此，应当强调并注意的是，本说明书中在不同位置两次或以上提及的“一实施例”或“一个实施例”或“一替代性实施例”并不一定是指同一实施例。此外，本申请的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。

此外，本领域的普通技术人员可以理解，本申请的各方面可以通过若干具有可专利性的种类或情况进行说明和描述，包括任何新的和有用的过程、机器、产品或物质的组合，或对其任何新的和有用的改进。相应地，本申请的各个方面可以完全由硬件执行、可以完全由软件(包括韧体、常驻软件、微代码等)执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“单元”、“模块”或“系统”。此外，本申请的各方面可以采取体现在一个或多个计算机可读介质中的计算机程序产品的形式，其中计算机可读程序代码包含在其中。

计算机可读信号介质可能包含一个内含有计算机程序代码的传播数据信号，例如在基带上或作为载波的一部分。此类传播信号可以有多种形式，包括电磁形式、光形式等或任何合适的组合。计算机可读信号介质可以是除计算机可读存储介质之外的任何计算机可读介质，该介质可以通过连接至一个指令执行系统、装置或设备以实现通信、传播或传输供使用的程序。位于计算机可读信号介质上的程序代码可以通过任何合适的介质进行传播，包括无线电、电缆、光纤电缆、RF等，或任何上述介质的组合。

本申请各部分操作所需的计算机程序编码可以用任意一种或以上程序语言编写，包括面向主体编程语言如Java、Scala、Smalltalk、Eiffel、JADE、Emerald、C++、C#、VB.NET、Python等，常规程序化编程语言如C语言、Visual Basic、Fortran 2003、Perl、COBOL 2002、PHP、ABAP，动态编程语言如Python、Ruby,和Groovy，或其他编程语言等。该程序代码可以完全在用户计算机上运行、或作为独立的软件包在用户计算机上运行、或部分在用户计算机上运行部分在远程计算机运行、或完全在远程计算机或服务器上运行。在后种情况下，远程计算机可以通过任何网络形式与用户计算机连接，比如局域网(LAN)或广域网(WAN)，或连接至外部计算机(例如通过因特网)，或在云计算环境中，或作为服务使用如软件即服务(SaaS)。

此外，除非权利要求中明确说明，本申请所述处理元素和序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本申请流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的发明实施例，但应当理解的是，该类细节仅起到说明的目的，附加的权利要求并不仅限于披露的实施例，相反，权利要求旨在覆盖所有符合本申请实施例实质和范围的修正和等价组合。例如，虽然以上所描述的系统组件可以通过硬件设备实现，但是也可以只通过软件的解决方案得以实现，如在现有的服务器或移动设备上安装所描述的系统。

同理，应当注意的是，为了简化本申请披露的表述，从而帮助对一个或多个发明实施例的理解，前文对本申请实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。然而，本申请的该方法不应被解释为反映所声称的待扫描对象物质需要比每个权利要求中明确记载的更多特征的意图。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

Claims (70)

1.一种支付管理方法，在具有至少一个处理器和至少一个非暂时性存储介质的计算设备上实现，所述方法包括：

接收对应于消费行为的支付请求和相关消费凭证，所述消费凭证包括提供所述消费凭证的实体的位置信息；

获取所述消费行为发生的位置；以及

响应于确定所述位置信息与所述消费行为发生的所述位置不相关，

确定不执行所述支付。

2.根据权利要求1所述的支付管理方法，其中所述确定所述位置信息与所述消费行为发生的所述位置不相关，包括：

确定所述位置信息的第一字符串和所述消费行为发生的所述位置的第二字符串；

确定所述第一字符串和所述第二字符串之间的重合率；以及

响应于确定所述重合率小于预设概率，

确定所述位置信息与所述消费行为发生的所述位置不相关。

3.根据权利要求1所述的支付管理方法，其中所述确定所述位置信息与所述消费行为发生的所述位置不相关，包括：

确定与所述位置信息相关的第一区域和与所述消费行为发生的所述位置相关的第二区域；

确定所述第一区域和所述第二区域之间的重合面积；以及

响应于确定所述重合面积小于预设面积，

确定所述位置信息与所述消费行为发生的所述位置不相关。

4.根据权利要求1至3中任一项所述的支付管理方法，其中响应于确定所述位置信息与所述消费行为发生的所述位置相关，所述方法还包括：

确定所述相关消费凭证的消费类别；以及

响应于确定与所述消费行为发生的所述位置相关的滞留时长小于对应于所述消费类别的预设时长，

确定不执行所述支付。

5.一种支付管理系统，包括：

信息接收单元，被配置为接收对应于消费行为的支付请求和相关消费凭证，所述消费凭证包括提供所述消费凭证的实体的位置信息；

位置获取单元，被配置为获取所述消费行为发生的位置；以及

确定单元，被配置为

响应于确定所述位置信息与所述消费行为发生的所述位置不相关，

确定不执行所述支付。

6.根据权利要求5所述的支付管理系统，其中所述确定单元还包括：

字符确定子单元，被配置为确定所述位置信息的第一字符串和所述消费行为发生的所述位置的第二字符串；以及

第一执行子单元，被配置为

确定所述第一字符串和所述第二字符串之间的重合率；以及

响应于确定所述重合率小于预设概率，

确定所述位置信息与所述消费行为发生的所述位置不相关。

7.根据权利要求5所述的支付管理系统，其中所述确定单元包括：

区域确定子单元，被配置为确定与所述位置信息相关的第一区域和与所述消费行为发生的所述位置相关的第二区域；以及

第二执行子单元，被配置为

确定所述第一区域和所述第二区域之间的重合面积；以及

响应于确定所述重合面积小于预设面积，

确定所述位置信息与所述消费行为发生的所述位置不相关。

8.根据权利要求5至7中任一项所述的支付管理系统，其中响应于确定所述位置信息与所述消费行为发生的所述位置相关，所述确定单元还包括：

类别确定子单元，被配置为确定所述相关消费凭证的消费类别；以及拒付子单元，被配置为

响应于确定与所述消费行为发生的所述位置相关的滞留时长小于对应于所述消费类别的预设时长，

确定不执行所述支付。

9.一种计算设备，包括存储在所述存储器中并由所述处理器执行的存储器、处理器和计算机程序，其中当执行所述计算机程序时，所述处理器实现根据权利要求1至4中任一项所述的支付管理方法。

10.一种存储计算机程序的计算机可读存储介质，其中当由所述处理器执行时，所述计算机程序实现根据权利要求1至4中任一项所述的支付管理方法。

11.一种费用支付管理方法，在具有至少一个处理器和至少一个非暂时性存储介质的计算设备上实现，所述方法包括：

接收与第二用户有关的由第一用户发起的费用支付请求；

确定对应于所述费用支付请求的至少一条消费信息，并验证所述至少一条消费信息；

验证所述第一用户是否被授权发起与所述第二用户有关的所述费用支付请求；以及

响应于确定所述至少一条消费信息通过验证并且所述第一用户被授权发起与所述第二用户有关的所述费用支付请求，

基于所述费用支付请求，将对应于所述至少一条消费信息的费用分配给所述第二用户的帐户。

12.根据权利要求11所述的费用支付管理方法，还包括：

确定收到所述第一用户发起的所述费用支付请求的时间点与收到所述第二用户发起的费用支付请求的时间点之间的时间差；以及

响应于确定所述时间差不大于预设时间，

基于所述第二用户发起的所述费用支付请求，确定所述至少一条消费信息。

13.根据权利要求11所述的费用支付管理方法，还包括：

响应于确定所述至少一条消费信息通过验证并且所述第一用户被授权发起与所述第二用户有关的所述费用支付请求，

删除对应于所述第二用户的至少一个第一用户的信息和所述至少一个第一用户的任何费用支付请求。

14.根据权利要求11至13中任一项所述的费用支付管理方法，其中所述验证所述至少一条消费信息，包括：

确定与所述至少一条消费信息相关的至少一个消费参数，

基于存储所述至少一条消费信息的消费系统数据库，确定所述至少一个消费参数中的每一个的匹配度；

响应于确定所有所述至少一个匹配度大于至少一个对应的匹配阈值，

确定所述至少一条消费信息被成功验证；以及

响应于确定并非所有所述至少一个匹配度大于所述至少一个对应的匹配阈值，

确定所述至少一条消费信息未通过验证，

其中所述至少一个消费参数包括消费时间、消费位置和消费类别中的一个或多个。

15.一种费用支付管理系统，包括：

请求接收单元，被配置为接收第一支付请求，所述第一支付请求包括与提供给第二用户的服务有关的第一信息；

信息验证单元，被配置为确定对应于所述费用支付请求的至少一条消费信息，并验证所述至少一条消费信息；

代理验证单元，被配置为验证所述第一用户是否被授权发起与所述第二用户有关的所述费用支付请求；以及

执行单元，被配置为

响应于确定所述至少一条消费信息通过验证并且所述第一用户被授权发起与所述第二用户有关的所述费用支付请求，

基于所述费用支付请求，将对应于所述至少一条消费信息的费用分配给所述第二用户的帐户。

16.根据权利要求15所述的费用支付管理系统，还包括：

时间差确定单元，被配置为确定收到所述第一用户发起的所述费用支付请求的时间点与收到所述第二用户发起的费用支付请求的时间点之间的时间差；以及

代理覆盖单元，被配置为

响应于确定所述时间差不大于预设时间，

基于所述第二用户发起的所述费用支付请求，确定所述至少一条消费信息。

17.根据权利要求15所述的费用支付管理系统，还包括：

请求消除单元，被配置为

响应于所述确定所述至少一条消费信息通过验证并且所述第一用户被授权发起与所述第二用户有关的所述费用支付请求，

删除对应于所述第二用户的至少一个第一用户的信息和所述至少一个第一用户的任何费用支付请求。

18.根据权利要求15至17中任一项所述的费用支付管理系统，其中所述信息验证单元还包括：

参数匹配单元，被配置为

确定与所述至少一条消费信息相关的至少一个消费参数，以及

基于存储所述至少一条消费信息的消费系统数据库，确定所述至少一个消费参数中的每一个的匹配度；

比较单元，被配置为

响应于确定所有所述至少一个匹配度大于至少一个对应的匹配阈值，

确定所述至少一条消费信息被成功验证；以及

响应于确定并非所有所述至少一个匹配度大于所述至少一个对应的匹配阈值，

确定所述至少一条消费信息未通过验证，

其中所述至少一个消费参数包括消费时间、消费位置和消费类别的一个或多个。

19.一种计算设备，包括存储在所述存储器中并由所述处理器执行的存储器、处理器和计算机程序，其中当执行所述计算机程序时，所述处理器实现根据权利要求1至4中任一项所述的所述费用支付管理方法。

20.一种存储计算机程序的计算机可读存储介质，其中当由所述处理器执行时，所述计算机程序实现根据权利要求1至4中任一项所述的费用支付管理方法。

21.一种系统，包括：

至少一个存储介质，包括一组指令；以及

至少一个处理器，与所述至少一个存储介质通信，其中当执行所述指令时，所述至少一个处理器被配置为使所述系统执行操作，所述操作包括：

接收支付请求，所述支付请求包括与服务提供者提供的服务有关的信息，所述与所述服务有关的信息包括所述服务提供者的第一地理信息；

获取提供所述服务的位置的第二地理信息；

比较所述第一地理信息和所述第二地理信息；以及

至少基于所述两个地理信息的所述比较的结果，根据预设规则来确定所述支付请求是否被批准。

22.根据权利要求21所述的系统，其中所述服务由所述用户经由终端设备支付，并且所述第二地理信息由所述终端设备的定位收发器组件生成。

23.根据权利要求21所述的系统，其中所述第二地理信息包括规定的地理位置。

24.根据权利要求21所述的系统，其中所述服务提供者的所述第一地理信息包括所述服务提供者的实体的地理位置。

25.根据权利要求21所述的系统，其中所述第一地理信息包括第一字符串，且所述第二地理信息包括第二字符串，以及

其中为了至少基于所述两个地理信息的所述比较的所述结果，根据所述预设规则来确定所述支付请求是否被批准，所述至少一个处理器被配置为使所述系统执行附加操作，所述附加操作包括：

确定所述第一字符串和所述第二字符串之间的相似度。

26.根据权利要求25所述的系统，其中所述预设规则包括：

响应于确定所述第一字符串与所述第二字符串之间的所述相似度超过相似度阈值，

确定所述支付请求被批准。

27.根据权利要求21所述的系统，其中所述第一地理信息包括第一地理位置，且所述第二地理信息包括第二地理位置，以及

其中为了至少基于所述两个地理信息的所述比较的所述结果，根据所述预设规则确定所述支付请求是否被批准，所述至少一个处理器被配置为使所述系统执行附加操作，所述附加操作包括：

确定所述第一地理位置与所述第二地理位置之间的相关性。

28.根据权利要求27所述的系统，其中为了基于所述两个地理信息的所述比较的所述结果，根据所述预设规则来确定所述支付请求是否被批准，所述至少一个处理器被配置为使所述系统执行附加操作，所述附加操作包括：

确定包括所述第一地理位置的第一区域和包括所述第二地理位置的第二区域；以及

基于所述第一区域和所述第二区域之间的重合，确定所述第一地理位置与所述第二地理位置之间的所述相关性。

29.根据权利要求28所述的系统，其中所述预设规则包括：

比较所述第一区域和所述第二区域之间的所述重合与重合阈值；以及响应于所述第一区域和所述第二区域之间的所述重合超过重合阈值的所述比较的所述结果，

确定所述支付请求被批准。

30.根据权利要求21所述的系统，其中为了基于所述两个地理信息的所述比较的所述结果，根据所述预设规则来确定所述支付请求是否被批准，所述至少一个处理器被配置为使所述系统执行附加操作，所述附加操作包括：

确定与所述服务相关的持续时间。

31.根据权利要求30所述的系统，其中所述预设规则包括：

将与所述服务有关的所述持续时间与时间阈值进行比较；以及

响应于与所述服务相关的持续时间超过时间阈值的所述比较的所述结果，

确定所述支付请求被批准。

32.根据权利要求21所述的系统，其中所述支付请求是加密的，并且所述至少一个处理器进一步被配置为使所述系统执行附加操作，所述附加操作包括：

解密所述支付请求。

33.一种在计算设备上实现的方法，所述计算设备具有至少一个处理器和至少一个非暂时性存储介质，所述方法包括：

接收支付请求，所述支付请求包括与服务提供者提供的服务有关的信息，所述与所述服务有关的信息包括所述服务提供者的第一地理信息；

获取提供所述服务的位置的第二地理信息；

比较所述第一地理信息和所述第二地理信息；以及

至少基于所述两个地理信息的所述比较的结果，根据预设规则确定所述支付请求是否被批准。

34.根据权利要求33所述的方法，其中所述服务由所述用户经由终端设备支付，并且所述第二地理信息由所述终端设备的定位收发器组件生成。

35.根据权利要求33所述的方法，其中所述第二地理信息包括规定的地理位置。

36.根据权利要求33所述的方法，其中所述服务提供者的所述第一地理信息包括所述服务提供者的实体的地理位置。

37.根据权利要求33所述的方法，其中所述第一地理信息包括第一字符串，且所述第二地理信息包括第二字符串，以及

其中所述至少基于所述两个地理信息的所述比较的结果，根据预设规则确定所述支付请求是否被批准包括：

确定所述第一字符串和所述第二字符串之间的相似度。

38.根据权利要求37所述的方法，其中所述预设规则包括：

响应于确定所述第一字符串与所述第二字符串之间的所述相似度超过相似度阈值，

确定所述支付请求被批准。

39.根据权利要求33所述的方法，其中所述第一地理信息包括第一地理位置，且所述第二地理信息包括第二地理位置，以及

其中所述至少基于所述两个地理信息的所述比较的结果，根据预设规则确定所述支付请求是否被批准包括：

确定所述第一地理位置与所述第二地理位置之间的相关性。

40.根据权利要求39所述的方法，其中所述至少基于所述两个地理信息的所述比较的结果，根据预设规则确定所述支付请求是否被批准包括：

确定包括所述第一地理位置的第一区域和包括所述第二地理位置的第二区域；以及

基于所述第一区域和所述第二区域之间的重合，确定所述第一地理位置与所述第二地理位置之间的所述相关性。

41.根据权利要求40所述的方法，其中所述预设规则包括：

比较所述第一区域和所述第二区域之间的所述重合与重合阈值；以及

响应于所述第一区域和所述第二区域之间的所述重合超过重合阈值的所述比较的所述结果，

确定所述支付请求被批准。

42.根据权利要求33所述的方法，其中所述至少基于所述两个地理信息的所述比较的结果，根据预设规则确定所述支付请求是否被批准包括：

确定与所述服务相关的持续时间。

43.根据权利要求42所述的方法，其中所述预设规则包括：

将与所述服务有关的所述持续时间与时间阈值进行比较；以及

响应于与所述服务相关的持续时间超过时间阈值的所述比较的所述结果，

确定所述支付请求被批准。

44.根据权利要求33所述的方法，其中所述支付请求是加密的，并且所述方法还包括：

解密所述支付请求。

45.一种系统，包括

获取模块，被配置为

接收支付请求，所述支付请求包括与服务提供者提供的服务有关的信息，所述与所述服务有关的信息包括所述服务提供者的第一地理信息；以及

获取提供所述服务的位置的第二地理信息；以及

确定模块，被配置为

比较所述第一地理信息和所述第二地理信息；以及

至少基于所述两个地理信息的所述比较的结果，根据预设规则确定所述支付请求是否被批准。

46.一种非暂时性计算机可读介质，包括至少一组指令，其中当由至少一个处理器执行时，所述至少一组指令被指示使所述至少一个处理器实现一种方法，所述方法包括：

接收支付请求，所述支付请求包括与服务提供者提供的服务有关的信息，所述与所述服务有关的信息包括所述服务提供者的第一地理信息；

获取提供所述服务的位置的第二地理信息；

比较所述第一地理信息和所述第二地理信息；以及

至少基于所述两个地理信息的所述比较的结果，根据预设规则确定所述支付请求是否被批准。

47.一种系统，包括：

至少一个存储介质，包括一组指令；以及

至少一个处理器，与所述至少一个存储介质通信，其中当执行所述指令时，所述至少一个处理器被配置为使所述系统执行操作，所述操作包括：

接收第一用户发起的第一支付请求，所述第一支付请求与提供给第二用户的服务有关；

获取与提供给所述第二用户的所述服务有关的第一信息；

根据第一预设规则，通过验证所述第一信息，生成第一验证结果；

根据第二预设规则，通过验证所述第一用户是否被授权发起所述第一支付请求，生成第二验证结果；以及

至少基于所述第一验证结果和所述第二验证结果，确定所述第一支付请求是否被批准。

48.根据权利要求47所述的系统，其中为了根据第二预设规则，通过验证所述第一用户是否被授权发起所述第一支付请求，生成所述第二验证结果，所述至少一个处理器被配置为使所述系统执行附加操作，所述附加操作包括：

接收由所述第二用户发起的第二支付请求，所述第二支付请求与提供给所述第二用户的所述服务有关；

获取与所述第二服务有关的第二信息；以及

确定与所述第一支付请求相关联的第一时间点和与所述第二支付请求相关联的第二时间点之间的时间差；

确定所述时间差是否小于或等于预设时间；以及

响应于确定所述时间差小于所述预设时间，

验证所述第一用户是未经授权发起所述第一支付请求。

49.根据权利要求48所述的系统，其中所述至少一个处理器被配置为使所述系统执行附加操作，所述附加操作包括：

删除所述第一支付请求的信息。

50.根据权利要求48所述的系统，其中所述至少一个处理器被配置为使所述系统执行附加操作，所述附加操作包括：

根据第三预设规则，通过验证所述第二信息，生成第三验证结果；以及

至少基于所述第三验证结果，确定所述第二支付请求是否被批准。

51.根据权利要求50所述的系统，其中为了根据所述第三预设规则，通过验证所述第二信息，生成所述第三验证结果，所述至少一个处理器被配置为使所述系统执行附加操作，所述附加操作包括：

基于所述第二信息，确定一个或多个第二参数；

确定与所述一个或多个第二参数相关的一个或多个第二匹配度；

比较所述一个或多个第二匹配度与一个或多个第二匹配阈值；以及

响应于所述一个或多个第二匹配度大于所述一个或多个第二匹配阈值的所述比较的结果，

生成验证所述第二信息合格的所述第三验证结果。

52.根据权利要求47所述的系统，其中为了根据所述第一预设规则，通过验证所述第一信息，生成所述第一验证结果，所述至少一个处理器被配置为使所述系统执行附加操作，所述附加操作包括：

基于所述第一信息，确定一个或多个第一参数；

确定与所述一个或多个第一参数相关的一个或多个第一匹配度；

比较所述一个或多个第一匹配度与一个或多个第一匹配阈值；以及

响应于所述一个或多个第一匹配度大于所述一个或多个第一匹配阈值的所述比较的结果，

生成验证所述第一信息合格的所述第一验证结果。

53.根据权利要求51或52中任一项所述的系统，其中所述一个或多个第一参数或所述一个或多个第二参数中的至少一个包括与提供给所述第二用户的所述服务相关的位置、所述服务提供给所述第二用户的时间、与提供给所述第二用户的所述服务有关的持续时间，或提供给所述第二用户的所述服务的类别中的至少一个。

54.根据权利要求53所述的系统，其中所述至少一个处理器被配置为使所述系统执行附加操作，所述附加操作包括：

确定向所述第二用户提供所述服务的服务提供者的第一地理信息；

确定向所述第二用户提供所述服务的位置的第二地理信息；以及

基于所述第一地理信息和所述第二地理信息，确定所述一个或多个第一匹配度或所述一个或多个第二匹配度中的至少一个。

55.根据权利要求54所述的系统，其中所述第一地理信息包括第一字符串，且所述第二地理信息包括第二字符串，以及

其中为了基于所述第一地理信息和所述第二地理信息，确定所述一个或多个第一匹配度或所述一个或多个第二匹配度中的所述至少一个，所述至少一个处理器被配置为使所述系统执行附加操作，所述附加操作包括：

基于所述第一字符串和所述第二字符串，确定所述一个或多个第一匹配度或所述一个或多个第二匹配度中的所述至少一个。

56.根据权利要求54所述的系统，其中为了基于所述第一地理信息和所述第二地理信息，确定所述一个或多个第一匹配度或所述一个或多个第二匹配度中的所述至少一个，所述至少一个处理器被配置为使所述系统执行附加操作，所述附加操作包括：

基于所述第一地理信息，确定第一区域；

基于所述第二地理信息，确定第二区域；以及

基于所述第一区域和所述第二区域，确定所述一个或多个第一匹配度或所述一个或多个第二匹配度的所述至少一个。

57.根据权利要求53所述的系统，其中所述至少一个处理器被配置为使所述系统执行附加操作，包括：

确定与提供给所述第二用户的所述服务相关的持续时间；以及

基于所述持续时间和预设时长，确定所述一个或多个第一匹配度或所述一个或多个第二匹配度中的所述至少一个。

58.一种在计算设备上实现的方法，所述计算设备具有至少一个处理器和至少一个非暂时性存储介质，所述方法包括：

接收第一用户发起的第一支付请求，所述第一支付请求与提供给第二用户的服务有关；

获取与提供给所述第二用户的所述服务有关的第一信息；

根据第一预设规则，通过验证所述第一信息，生成第一验证结果；

根据第二预设规则，通过验证所述第一用户是否被授权发起所述第一支付请求，生成第二验证结果；以及

至少基于所述第一验证结果和所述第二验证结果，确定所述第一支付请求是否被批准。

59.根据权利要求58所述的方法，其中所述根据第二预设规则，通过验证所述第一用户是否被授权发起所述第一支付请求，生成第二验证结果包括：

接收由所述第二用户发起的第二支付请求，所述第二支付请求与提供给所述第二用户的所述服务有关；

获取与所述第二服务有关的第二信息；以及

确定与所述第一支付请求相关联的第一时间点和与所述第二支付请求相关联的第二时间点之间的时间差；

确定所述时间差是否小于或等于预设时间；以及

响应于确定所述时间差小于所述预设时间，

验证所述第一用户是未经授权发起所述第一支付请求。

60.根据权利要求59所述的方法，还包括：

删除所述第一支付请求的信息。

61.根据权利要求59所述的方法，还包括：

根据第三预设规则，通过验证所述第二信息，生成第三验证结果；以及

至少基于所述第三验证结果，确定所述第二支付请求是否被批准。

62.根据权利要求61所述的方法，其中所述根据第三预设规则，通过验证所述第二信息，生成第三验证结果包括：

基于所述第二信息，确定一个或多个第二参数；

确定与所述一个或多个第二参数相关的一个或多个第二匹配度；

比较所述一个或多个第二匹配度与一个或多个第二匹配阈值；以及

响应于所述一个或多个第二匹配度大于所述一个或多个第二匹配阈值的所述比较的结果，

生成验证所述第二信息合格的所述第三验证结果。

63.根据权利要求58所述的方法，其中所述根据第一预设规则，通过验证所述第一信息，生成第一验证结果包括：

基于所述第一信息，确定一个或多个第一参数；

确定与所述一个或多个第一参数相关的一个或多个第一匹配度；

比较所述一个或多个第一匹配度与一个或多个第一匹配阈值；以及

响应于所述一个或多个第一匹配度大于所述一个或多个第一匹配阈值的所述比较的结果，

生成验证所述第一信息合格的所述第一验证结果。

64.根据权利要求62或63中任一项所述的方法，其中所述一个或多个第一参数或所述一个或多个第二参数中的至少一个包括与提供给所述第二用户的所述服务相关的位置、所述服务提供给所述第二用户的时间、与提供给所述第二用户的所述服务有关的持续时间，或提供给所述第二用户的所述服务的类别中的至少一个。

65.根据权利要求64所述的方法，还包括：

确定向所述第二用户提供所述服务的服务提供者的第一地理信息；

确定向所述第二用户提供所述服务的位置的第二地理信息；以及

基于所述第一地理信息和所述第二地理信息，确定所述一个或多个第一匹配度或所述一个或多个第二匹配度中的至少一个。

66.根据权利要求65所述的方法，其中所述第一地理信息包括第一字符串，且所述第二地理信息包括第二字符串，以及

其中所述根据第一预设规则，通过验证所述第一信息，生成第一验证结果包括：

基于所述第一字符串和所述第二字符串，确定所述一个或多个第一匹配度或所述一个或多个第二匹配度中的所述至少一个。

67.根据权利要求65所述的方法，其中所述基于所述第一地理信息和所述第二地理信息，确定所述一个或多个第一匹配度或所述一个或多个第二匹配度中的至少一个包括：

基于所述第一地理信息，确定第一区域；

基于所述第二地理信息，确定第二区域；以及

基于所述第一区域和所述第二区域，确定所述一个或多个第一匹配度或所述一个或多个第二匹配度的所述至少一个。

68.根据权利要求64所述的方法，还包括：

确定与提供给所述第二用户的所述服务相关的持续时间；以及

基于所述持续时间和预设时长，确定所述一个或多个第一匹配度或所述一个或多个第二匹配度中的所述至少一个。

69.一种系统，包括

获取模块，被配置为

接收第一用户发起的第一支付请求，所述第一支付请求与提供给第二用户的服务有关；以及

获取与提供给所述第二用户的所述服务有关的第一信息；以及

确定模块，被配置为

根据第一预设规则，通过验证所述第一信息，生成第一验证结果；

根据第二预设规则，通过验证所述第一用户是否被授权发起所述第一支付请求，生成第二验证结果；以及

至少基于所述第一验证结果和所述第二验证结果，确定所述第一支付请求是否被批准。

70.一种非暂时性计算机可读介质，包括至少一组指令，其中当由至少一个处理器执行时，所述至少一组指令被指示使所述至少一个处理器实现一种方法，所述方法包括：

接收第一用户发起的第一支付请求，所述第一支付请求与提供给第二用户的服务有关；

获取与提供给所述第二用户的所述服务有关的第一信息；

根据第一预设规则，通过验证所述第一信息，生成第一验证结果；

根据第二预设规则，通过验证所述第一用户是否被授权发起所述第一支付请求，生成第二验证结果；以及

至少基于所述第一验证结果和所述第二验证结果，确定所述第一支付请求是否被批准。

Images