CN106910054A - 一种支付业务数据处理的方法和装置 - Google Patents

Abstract

本申请实施例提供了一种支付业务数据处理的方法，包括：服务器预先针对第一用户支付行为的个性化信息，生成第一用户的信用额度数据；获得所述第一用户的一个或多个账户及各账户的支付业务处理时间；当达到某个账户的支付业务处理时间时，采用第一用户当前的信用额度数据对所述账户进行支付业务处理；统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户；接收第一用户针对所花费的信用额度数据提交的还款数据。本申请实施例通过基于用户支付行为的个性化信息生成信用额度，当用户的各个账户需要缴费时，采用信用额度进行支付。用户只需对信用额度进行还款，而无需对每个账户进行支付操作，减少了用户的操作量。

Description

一种支付业务数据处理的方法和装置

技术领域

本申请涉及数据处理技术领域，特别是涉及一种支付业务数据处理的方法和一种支付业务数据处理的装置。

背景技术

随着人们生活水平的提高，人们的生活支出越来越多，需要缴纳的生活费用也越来越多，人们每个月都要为水费、电费、煤气费、物业费、有线电视费等生活费用的缴纳花费很多时间，虽然目前，人们已经可以通过网络平台进行缴费而不用去到网点排队缴费，但是基于网络平台的生活缴费，人们每次缴纳都需要在填写相应的账户账单信息、并且针对每个账户账单都要进行一次支付。当用户需要缴纳多个生活费用时，多次的信息填写、支付操作相对变大繁琐。

发明内容

鉴于上述问题，提出了本申请实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种支付业务数据处理的方法和相应的一种支付业务数据处理的装置。

为了解决上述问题，本申请实施例公开了一种1、一种支付业务数据处理的方法，包括：

服务器预先针对第一用户支付行为的个性化信息，生成第一用户的信用额度数据；

获得所述第一用户的一个或多个账户及各账户的支付业务处理时间；

当达到某个账户的支付业务处理时间时，采用第一用户当前的信用额度数据对所述账户进行支付业务处理；

统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户；

接收第一用户针对所花费的信用额度数据提交的还款数据。

优选的，所述统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户的步骤包括：

按预设时间统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户。

优选的，所述统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户的步骤包括：

当前剩余的信用额度数据少于预设的数值时，统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户。

优选的，还包括：

接收所述第一用户发送的用于关联第二用户的信用额度数据的关联请求；所述关联请求中包括：第一用户指定的一个或多个到达支付业务处理时间的目标账户；

向所述第二用户转发所述关联请求；

当接收到所述第二用户针对所述关联请求的同意响应后，采用所述第二用户当前的信用额度数据对所述目标账户进行支付业务处理。

优选的，还包括：

将所述第二用户对所述目标账户所花费的信用额度数据推送给第一用户。

优选的，还包括：

分别统计所述第一用户的各个逾期账户的信用额度数据的还款日期超过预设还款日期的逾期天数；所述逾期账户为未在预设还款日期之内进行支付业务处理的账户；

采用所述逾期天数计算特征参数。

优选的，还包括：

记录所述第一用户的一个或多个账户的业务处理信息；

当接收到第一用户的查询请求时，向第一用户发送与所述查询请求中指定的查询账户对应的业务处理信息。

同时本申请实施例还公开了一种支付业务数据处理的装置，包括：

位于服务器的生成模块，用于预先针对第一用户支付行为的个性化信息，生成第一用户的信用额度数据；

位于服务器的获得模块，用于获得所述第一用户的一个或多个账户及各账户的支付业务处理时间；

位于服务器的第一支付处理模块，用于当达到某个账户的支付业务处理时间时，采用第一用户当前的信用额度数据对所述账户进行支付业务处理；

位于服务器的额度统计模块，用于统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户；

位于服务器的还款接收模块，用于接收第一用户针对所花费的信用额度数据提交的还款数据。

优选的，所述额度统计模块进一步包括：

位于服务器的第一统计子模块，用于按预设时间统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户。

优选的，所述额度统计模块进一步包括：

位于服务器的第二统计子模块，当前剩余的信用额度数据少于预设的数值时，统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户。

优选的，还包括：

位于服务器的请求接收模块，用于接收所述第一用户发送的用于关联第二用户的信用额度数据的关联请求；所述关联请求中包括：第一用户指定的一个或多个到达支付业务处理时间的目标账户；

位于服务器的请求转发模块，用于向所述第二用户转发所述关联请求；

位于服务器的第二支付处理模块，用于当接收到所述第二用户针对所述关联请求的同意响应后，采用所述第二用户当前的信用额度数据对所述目标账户进行支付业务处理。

优选的，还包括：

位于服务器的推送模块，用于将所述第二用户对所述目标账户所花费的信用额度数据推送给第一用户。

优选的，还包括：

位于服务器的逾期统计模块，用于分别统计所述第一用户的各个逾期账户的信用额度数据的还款日期超过预设还款日期的逾期天数；所述逾期账户为未在预设还款日期之内进行支付业务处理的账户；

位于服务器的计算模块，用于采用所述逾期天数计算特征参数。

优选的，还包括：

位于服务器的记录模块，用于记录所述第一用户的一个或多个账户的业务处理信息；

位于服务器的发送模块，用于当接收到第一用户的查询请求时，向第一用户发送与所述查询请求中指定的查询账户对应的业务处理信息。

本申请实施例包括以下优点：

本申请实施例通过基于用户支付行为的个性化信息生成信用额度，当用户的各个账户需要缴费时，采用信用额度进行支付。用户只需对信用额度进行还款，而无需对每个账户进行支付操作，减少了用户的操作量。

在当前用户的信用额度不足时，可以采用当前用户指定的其他用户的信用额度进行支付，避免用户由于未交费用产生滞纳金的情况。

附图说明

图1是本申请的一种支付业务数据处理的方法实施例1的步骤流程图；

图2是本申请的一种支付业务数据处理的方法实施例2的步骤流程图；

图3是本申请的一种支付业务数据处理的装置实施例1的结构框图；

图4是本申请的一种支付业务数据处理的装置实施例2的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

本申请实施例的核心构思之一在于，通过基于用户支付行为的个性化信息生成信用额度，当用户的各个账户需要缴费时，采用信用额度进行支付。用户只需对信用额度进行还款。

参照图1，示出了本申请的一种支付业务数据处理的方法实施例1的步骤流程图，具体可以包括如下步骤：

步骤101，服务器预先针对第一用户支付行为的个性化信息，生成第一用户的信用额度数据；

支付行为的个性化信息具体可以包括：用户在不同网络购物平台中的网购买记录、理财产品记录、收入记录等。通过用户支付行为的个性化信息来训练评估模型，通过评估模型来生成用户的信用额度数据。

步骤102，获得所述第一用户的一个或多个账户及各账户的支付业务处理时间；

对于生活缴费而言，每个缴费项都是基于账单上的账户来进行的，用户在缴纳费用时需要输入账单账户以及缴纳费用的单位(收款方)。在本申请中，服务器中可以从缴纳费用的单位(收款方)中获取用户的账户的账单、需要缴纳的费用、以及支付业务处理时间(账单产生的时间)。

步骤103，当达到某个账户的支付业务处理时间时，采用第一用户当前的信用额度数据对所述账户进行支付业务处理；

当到达某个账户的支付业务处理时间(产生了某个账户账单)时，服务器主动采用用户当前的信用额度数据进行支付。例如，用户的水费支付业务处理时间(账单产生的时间)一般是每个月的15号，服务器从自来水公司中获取到用户的账户账单，当到达每个月的15号是，服务器自动采用用户当前的信用额度数据进行支付水费账单。

支付后剩余的信用额度数据，即为新的当前信用额度数据。

步骤104，统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户；

服务器统计一用户的一个或多个账户所花费的信用额度数据，例如，统计用户的水费、电费、煤气费总共花费的信用额度数据。然后将统计到的已花费的信用额度数据推送给用户。

步骤105，接收第一用户针对所花费的信用额度数据提交的还款数据。

当接收到用户的还款时，重置当前的剩余的信用额度。

用户只需对信用额度进行还款，而无需对每个账户进行支付操作，减少了用户的操作量。

作为本申请实施例的一种优选示例，所述的方法还可以包括如下步骤：

分别统计所述第一用户的各个逾期账户的信用额度数据的还款日期超过预设还款日期的逾期天数；所述逾期账户为未在预设还款日期之内进行支付业务处理的账户；

采用所述逾期天数计算特征参数。计算特征参数具体可以是滞纳金。

在本申请实施例中，用户的信用额度只在用户提交了还款时才重置，而当用户当前剩余的信用额度数据不足够对账户账单进行支付，不会对账户账单进行支付，当账户账单未在预设的还款日期内支付，将会产生滞纳金，滞纳金的数值具体取决于超过预设还款日期的天数。

作为本申请实施例的一种优选示例，所述的方法还可以包括如下步骤：

记录所述第一用户的一个或多个账户的业务处理信息；

当接收到第一用户的查询请求时，向第一用户发送与所述查询请求中指定的查询账户对应的业务处理信息。

业务处理信息具体包括账户账单需要缴纳的金额、账户账单中各项细分信息，例如，该月需要缴纳的水费，该月使用的水量、用水性质等信息。

通过记录用户各个月的账户的业务处理信息，使得用户可以查询到具体的业务处理信息。

参照图2，示出了本申请的一种支付业务数据处理的方法实施例2的步骤流程图，具体可以包括如下步骤：

步骤201，服务器预先针对第一用户支付行为的个性化信息，生成第一用户的信用额度数据；

步骤202，获得所述第一用户的一个或多个账户及各账户的支付业务处理时间；

步骤203，当达到某个账户的支付业务处理时间时，采用第一用户当前的信用额度数据对所述账户进行支付业务处理；

步骤204，统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户；

作为本申请实施例的一种优选示例，所述步骤204可以包括如下子步骤：

子步骤S11，按预设时间统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户。

例如，每个月的最后一天统计用户这个月内，各个账户总共花费的信用额度数据，每个月进行一次结算。

在本申请实施例的另一种优选示例中，所述步骤204可以包括如下子步骤：

子步骤S12，当前剩余的信用额度数据少于预设的数值时，统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户。

预设的数值可以是由服务器设定的数值，也可以是由用户设定的数字。当当用户当前剩余的信用额度数据少于预设的数值时，可以认为用户的剩余信用额度不足以再支付其他未支付的账户账单，此时，需要通知用户进行结算。

步骤205，接收所述第一用户发送的用于关联第二用户的信用额度数据的关联请求；所述关联请求中包括：第一用户指定的一个或多个到达支付业务处理时间的目标账户；

当第一用户当前的信用额度不足以对账户账单进行支付业务处理时，可以由第一用户指定的第二用户对账户账单进行支付处理；

步骤206，向所述第二用户转发所述关联请求；

步骤207，当接收到所述第二用户针对所述关联请求的同意响应后，采用所述第二用户当前的信用额度数据对所述目标账户进行支付业务处理。

服务器中根据第二用户的支付行为的个性化信息，生成了相应的信用额度数据，当第二用户同意了第一用户的关联请求后，服务器采用第二用户的信用额度进行支付处理。

作为本申请实施例的一种优选示例，所述的方法还可以包括如下步骤：

将所述第二用户对所述目标账户所花费的信用额度数据推送给第一用户。

步骤208，接收第一用户针对所花费的信用额度数据提交的还款数据。

在本申请实施例中，在当前用户的信用额度不足时，可以采用当前用户指定的其他用户的信用额度进行支付，避免用户由于未交费用产生滞纳金的情况。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。

参照图3，示出了本申请的一种支付业务数据处理的装置实施例1的结构框图，具体可以包括如下模块：

位于服务器的生成模块31，用于预先针对第一用户支付行为的个性化信息，生成第一用户的信用额度数据；

位于服务器的获得模块32，用于获得所述第一用户的一个或多个账户及各账户的支付业务处理时间；

位于服务器的第一支付处理模块33，用于当达到某个账户的支付业务处理时间时，采用第一用户当前的信用额度数据对所述账户进行支付业务处理；

位于服务器的额度统计模块34，用于统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户；

位于服务器的还款接收模块35，用于接收第一用户针对所花费的信用额度数据提交的还款数据。

作为本申请实施例的一种优选示例，所述的装置还可以包括：

位于服务器的逾期统计模块，用于分别统计所述第一用户的各个逾期账户的信用额度数据的还款日期超过预设还款日期的逾期天数；所述逾期账户为未在预设还款日期之内进行支付业务处理的账户；

位于服务器的计算模块，用于采用所述逾期天数计算特征参数。

作为本申请实施例的一种优选示例，所述的装置还可以包括：

位于服务器的记录模块，用于记录所述第一用户的一个或多个账户的业务处理信息；

位于服务器的发送模块，用于当接收到第一用户的查询请求时，向第一用户发送与所述查询请求中指定的查询账户对应的业务处理信息。

参照图4，示出了本申请的一种支付业务数据处理的装置实施例2的结构框图，具体可以包括如下模块：

位于服务器的生成模块41，用于预先针对第一用户支付行为的个性化信息，生成第一用户的信用额度数据；

位于服务器的获得模块42，用于获得所述第一用户的一个或多个账户及各账户的支付业务处理时间；

位于服务器的第一支付处理模块43，用于当达到某个账户的支付业务处理时间时，采用第一用户当前的信用额度数据对所述账户进行支付业务处理；

位于服务器的额度统计模块44，用于统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户；

在本申请实施例的一种优选示例中，所述额度统计模块44可以包括：

位于服务器的第一统计子模块，用于按预设时间统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户。

在本申请实施例的另一种优选示例中，所述额度统计模块44可以包括：

位于服务器的第二统计子模块，当前剩余的信用额度数据少于预设的数值时，统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户。

位于服务器的请求接收模块45，用于接收所述第一用户发送的用于关联第二用户的信用额度数据的关联请求；所述关联请求中包括：第一用户指定的一个或多个到达支付业务处理时间的目标账户；

位于服务器的请求转发模块46，用于向所述第二用户转发所述关联请求；

位于服务器的第二支付处理模块47，用于当接收到所述第二用户针对所述关联请求的同意响应后，采用所述第二用户当前的信用额度数据对所述目标账户进行支付业务处理。

位于服务器的还款接收模块48，用于接收第一用户针对所花费的信用额度数据提交的还款数据。

作为本申请实施例的一种优选示例，所述的装置还可以包括：

位于服务器的推送模块，用于将所述第二用户对所述目标账户所花费的信用额度数据推送给第一用户。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

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

本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种支付业务数据处理的方法和一种支付业务数据处理的装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

本申请实施例公开了A1、一种支付业务数据处理的方法，包括：

服务器预先针对第一用户支付行为的个性化信息，生成第一用户的信用额度数据；

获得所述第一用户的一个或多个账户及各账户的支付业务处理时间；

当达到某个账户的支付业务处理时间时，采用第一用户当前的信用额度数据对所述账户进行支付业务处理；

统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户；

接收第一用户针对所花费的信用额度数据提交的还款数据。

A2、如A1所述的方法，所述统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户的步骤包括：

按预设时间统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户。

A3、如A1所述的方法，所述统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户的步骤包括：

当前剩余的信用额度数据少于预设的数值时，统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户。

A4、如A1或A2或A3所述的方法，还包括：

接收所述第一用户发送的用于关联第二用户的信用额度数据的关联请求；所述关联请求中包括：第一用户指定的一个或多个到达支付业务处理时间的目标账户；

向所述第二用户转发所述关联请求；

当接收到所述第二用户针对所述关联请求的同意响应后，采用所述第二用户当前的信用额度数据对所述目标账户进行支付业务处理。

A5、如A4所述的方法，还包括：

将所述第二用户对所述目标账户所花费的信用额度数据推送给第一用户。

A6、如A5所述的方法，还包括：

分别统计所述第一用户的各个逾期账户的信用额度数据的还款日期超过预设还款日期的逾期天数；所述逾期账户为未在预设还款日期之内进行支付业务处理的账户；

采用所述逾期天数计算特征参数。

A7、如A6所述的方法，还包括：

记录所述第一用户的一个或多个账户的业务处理信息；

当接收到第一用户的查询请求时，向第一用户发送与所述查询请求中指定的查询账户对应的业务处理信息。

同时，本申请实施例还公开了B8、一种支付业务数据处理的装置，包括：

位于服务器的生成模块，用于预先针对第一用户支付行为的个性化信息，生成第一用户的信用额度数据；

位于服务器的获得模块，用于获得所述第一用户的一个或多个账户及各账户的支付业务处理时间；

位于服务器的第一支付处理模块，用于当达到某个账户的支付业务处理时间时，采用第一用户当前的信用额度数据对所述账户进行支付业务处理；

位于服务器的额度统计模块，用于统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户；

位于服务器的还款接收模块，用于接收第一用户针对所花费的信用额度数据提交的还款数据。

B9、如B8所述的装置，所述额度统计模块进一步包括：

位于服务器的第一统计子模块，用于按预设时间统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户。

B10、如B8所述的装置，所述额度统计模块进一步包括：

位于服务器的第二统计子模块，当前剩余的信用额度数据少于预设的数值时，统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户。

B11、如B8或B9或B10所述的装置，还包括：

位于服务器的请求接收模块，用于接收所述第一用户发送的用于关联第二用户的信用额度数据的关联请求；所述关联请求中包括：第一用户指定的一个或多个到达支付业务处理时间的目标账户；

位于服务器的请求转发模块，用于向所述第二用户转发所述关联请求；

位于服务器的第二支付处理模块，用于当接收到所述第二用户针对所述关联请求的同意响应后，采用所述第二用户当前的信用额度数据对所述目标账户进行支付业务处理。

B12、如B11所述的装置，还包括：

位于服务器的推送模块，用于将所述第二用户对所述目标账户所花费的信用额度数据推送给第一用户。

B13、如B12所述的装置，还包括：

位于服务器的逾期统计模块，用于分别统计所述第一用户的各个逾期账户的信用额度数据的还款日期超过预设还款日期的逾期天数；所述逾期账户为未在预设还款日期之内进行支付业务处理的账户；

位于服务器的计算模块，用于采用所述逾期天数计算特征参数。

B14、如B13所述的装置，还包括：

位于服务器的记录模块，用于记录所述第一用户的一个或多个账户的业务处理信息；

位于服务器的发送模块，用于当接收到第一用户的查询请求时，向第一用户发送与所述查询请求中指定的查询账户对应的业务处理信息。

Claims (10)

1.一种支付业务数据处理的方法，包括：

服务器预先针对第一用户支付行为的个性化信息，生成第一用户的信用额度数据；

获得所述第一用户的一个或多个账户及各账户的支付业务处理时间；

当达到某个账户的支付业务处理时间时，采用第一用户当前的信用额度数据对所述账户进行支付业务处理；

统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户；

接收第一用户针对所花费的信用额度数据提交的还款数据。

2.根据权利要求1所述的方法，其特征在于，所述统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户的步骤包括：

按预设时间统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户。

3.根据权利要求1所述的方法，其特征在于，所述统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户的步骤包括：

当前剩余的信用额度数据少于预设的数值时，统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户。

4.根据权利要求1或2或3所述的方法，其特征在于，还包括：

接收所述第一用户发送的用于关联第二用户的信用额度数据的关联请求；所述关联请求中包括：第一用户指定的一个或多个到达支付业务处理时间的目标账户；

向所述第二用户转发所述关联请求；

当接收到所述第二用户针对所述关联请求的同意响应后，采用所述第二用户当前的信用额度数据对所述目标账户进行支付业务处理。

5.根据权利要求4所述的方法，其特征在于，还包括：

将所述第二用户对所述目标账户所花费的信用额度数据推送给第一用户。

6.根据权利要求5所述的方法，其特征在于，还包括：

分别统计所述第一用户的各个逾期账户的信用额度数据的还款日期超过预设还款日期的逾期天数；所述逾期账户为未在预设还款日期之内进行支付业务处理的账户；

采用所述逾期天数计算特征参数。

7.根据权利要求6所述的方法，其特征在于，还包括：

记录所述第一用户的一个或多个账户的业务处理信息；

当接收到第一用户的查询请求时，向第一用户发送与所述查询请求中指定的查询账户对应的业务处理信息。

8.一种支付业务数据处理的装置，包括：

位于服务器的生成模块，用于预先针对第一用户支付行为的个性化信息，生成第一用户的信用额度数据；

位于服务器的获得模块，用于获得所述第一用户的一个或多个账户及各账户的支付业务处理时间；

位于服务器的第一支付处理模块，用于当达到某个账户的支付业务处理时间时，采用第一用户当前的信用额度数据对所述账户进行支付业务处理；

位于服务器的额度统计模块，用于统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户；

位于服务器的还款接收模块，用于接收第一用户针对所花费的信用额度数据提交的还款数据。

9.根据权利要求8所述的装置，其特征在于，所述额度统计模块进一步包括：

位于服务器的第一统计子模块，用于按预设时间统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户。

10.根据权利要求8所述的装置，其特征在于，所述额度统计模块进一步包括：

位于服务器的第二统计子模块，当前剩余的信用额度数据少于预设的数值时，统计所述第一用户的一个或多个账户所花费的信用额度数据，并推送给第一用户。