CN104616141A - 信息处理方法及支付平台 - Google Patents

Abstract

本发明公开了一种信息处理方法及支付平台，所述方法包括：支付平台查询待支付信息；依据所述待支付信息控制第一账户向第二账户进行支付操作，并形成支付结果；依据所述支付结果，生成支付反馈信息；向所述第一账户和所述第二账户的客户端发送所述支付反馈信息；当所述支付结果表明支付成功时，更新所述第一账户和所述第二账户的收支信息；其中，所述第一账户和所述第二账户均为注册在所述支付平台的操作账号。

Description

信息处理方法及支付平台

技术领域

本发明涉及通信领域的信息处理技术，尤其涉及一种信息处理方法及支付平台。

背景技术

在资金支付系统中，用户进行支付(如还款)方法有两种：

第一种：线下还款；无论是银行柜台还是小贷公司的柜台，对用户都会造成额外的时间和金钱成本。同时线下支付具有特定的营业时间才能操作的不便利性。现有支付流程，用户需要知道小贷公司的银行账户信息，容易出现差错，这就会给用户造额外的支付成本。现有支付流程，用户支付额度控制不方便，对于用户来说，每次支付需要通过额外的渠道来了解应还金额，容易造成用户少还或者多还资金，带来额外的损失。

第二种：利用互联网等通信工具，进行线上支付，但是现有技术中的线上支付是银行系统或小贷公司通过一定的通信应用进行绑定，由于这些通信应用的主要用途是进行通信的，用户在通信应用进行线上支付之前需要用户手动或手动触发连接到对应的账户，获取待支付金额，再进行支付。如用于通过电话或通讯应用工具A发送查询信息待支付金额，再通过具有支付功能的通信应用工具B来进行支付，由于现有支付平台之间的智能性不够的问题，导致的这种信息转移，很容易出现因操作失误等问题形成支付差错，且这种支付方式，显然操作繁琐。

不管采用哪种方式，现有的支付系统的智能性显然不够，且很容易因用户手动操作待支付金额而导致差错率高的问题，进而导致用户使用满意度差。

发明内容

有鉴于此，本发明实施例期望提供一种信息处理方法，以提高支付平台的智能性及降低人为操作因素导致的差错率，简化用户利用支付平台进行支付的操作。

为达到上述目的，本发明的技术方案是这样实现的：

本发明实施例第一方面提供一种信息处理方法，所述方法包括：

支付平台查询待支付信息；

依据所述待支付信息控制第一账户向第二账户进行支付操作，并形成支付结果；

依据所述支付结果，生成支付反馈信息；

向所述第一账户和所述第二账户的客户端发送所述支付反馈信息；

当所述支付结果表明支付成功时，更新所述第一账户和所述第二账户的收支信息；

所述第一账户和所述第二账户均为注册在所述支付平台的操作账号。

优选地，

所述依据所述待支付信息控制第一账户向第二账户进行支付操作，并形成支付结果，包括：

依据所述待支付信息，判断第一账户是否为满足预设自动支付条件的账户；

当所述第一账户为满足预设自动支付条件的账户时，控制所述第一账户向所述第二账户进行自动支付操作。

优选地，

所述依据所述待支付信息，判断第一账户是否为满足预设自动支付条件的账户，包括：

当所述第一账号向所述第二账户支付的支付截止日到期或指定支付日到期时，确定所述第一账户为满足预设自动支付条件的账户；

其中，所述指定支付日为所述第一账户的用户指定的且早于所述支付截止日的支付日。

优选地，

所述待支付信息包括待支付金额；

所述控制第一账户向所述第二账户进行自动支付操作，包括：

依据所述待支付信息控制所述第一账户向所述第二账户进行N次自动支付操作；

其中，第n次自动支付操作的支付金额为第n金额；

第n+1次自动支付操作在第1次至第n次自动支付操作的支付失败时进行，且第n+1金额小于第n金额；

所述N为不小1的正整数；所述n为小于所述N的正整数；

第1金额不大于所述待支付金额。

优选地，

所述控制第一账户向所述第二账户进行自动支付操作，

包括：

查询所述第一账户的可用余额；

当所述第一账户有可用余额时，依据待支付金额以及所述可用余额使所述第一账户向所述第二账户进行支付操作，并形成支付结果。

优选地，

所述当所述第一账户有可用余额时，依据待支付金额以及所述可用余额使所述第一账户向所述第二账户进行支付，并形成支付结果，包括：

当所述第一账户的可用余额不小于所述待支付金额时，控制所述第一账户向所述第二账户进行全额支付。

优选地，

所述当所述第一账户有可用余额时，依据待支付金额以及所述可用余额使所述第一账户向所述第二账户进行支付，并形成支付结果，包括：

当所述第一账户的可用余额小于所述待支付金额时，控制所述第一账户向所述第二账户进行部分支付。

优选地，

所述方法还包括：

判断所述第一账户是否为满足预设自动延期条件的账户；

当所述第一账户为满足所述预设自动延期条件的账户时，向所述第二账户的客户端发送支付延期请求；

接收所述第二账户的客户端基于所述支付延期请求形成的延期响应；

依据所述延期响应重新确定支付日。

优选地，

所述待支付信息包括第一账户需向所述第二账户支付的待支付金额；

所述依据所述待支付信息控制第一账户向第二账户进行支付操作，并形成支付结果，包括：

向第一账户的客户端发送所述待支付信息；

接收所述第一账户的客户端返回的实际支付金额；

控制所述第一账户向所述第二账户支付所述实际支付金额。

优选地，

所述方法还包括：

核算支付结果；

当依据所述支付结果确定第一账户向第二账户的支付金额超过待支付金额时，控制所述第二账户向所述第一账户进行返款操作。

优选地，

所述方法还包括：

接收所述第一账户的客户端发送的登录请求；

基于所述登录请求查询所述第一账户的待支付信息；所述待支付信息包括支付日和待支付金额；

响应所述登录请求，允许所述客户端登录并向所述客户端发送包括所述待支付信息的第一登录附加信息或第二登录附件信息；

所述第一登录附加信息，用于控制所述客户端在登录后显示第一界面；所述第二登录附加信息，用于控制所述客户端在登录后显示第二界面；

所述第一界面不同于所述第二界面。

优选地，

所述方法还包括：

核算所述第一账户的收支信息和支付结果；所述收支信息包括所述第一账户支付的实际支付日；所述支付结果中包括支付平台或所述第二账户收到支付的收到支付日；

当所述第一账户的支付信息表明所述实际支付日早于收到支付日时，以所述实际支付日校正支付结果。

本发明实施例第二方面提供一种支付平台，所述支付平台包括：

第一查询单元，用于查询待支付信息；

支付单元，用于依据所述待支付信息控制第一账户向第二账户进行支付操作，并形成支付结果；

生成单元，用于依据所述支付结果，生成支付反馈信息；

发送单元，用于向所述第一账户和所述第二账户的客户端发送所述支付反馈信息；

更新单元，用于当所述支付结果表明支付成功时，更新所述第一账户和所述第二账户的收支信息；

所述第一账户和所述第二账户均为注册在所述支付平台的操作账号。

优选地，

所述支付平台还包括：

判断单元，用于依据所述待支付信息，判断第一账户是否为满足预设自动支付条件的账户；

所述支付单元，用于当所述第一账户为满足预设自动支付条件的账户时，控制所述第一账户向所述第二账户进行自动支付操作。

优选地，

所述判断单元，用于当所述第一账号向所述第二账户支付的支付截止日到期或指定支付日到期时，确定所述第一账户为满足预设自动支付条件的账户；

其中，所述指定支付日为所述第一账户的用户指定的且早于所述支付截止日的支付日。

优选地，

所述待支付信息包括待支付金额；

所述支付单元，具体用于依据所述待支付信息控制所述第一账户向所述第二账户进行N次自动支付操作；

其中，第n次自动支付操作的支付金额为第n金额；

第n+1次自动支付操作在第1次至第n次自动支付操作的支付失败时进行，且第n+1金额小于第n金额；

所述N为不小1的正整数；所述n为小于所述N的正整数；

第1金额不大于所述待支付金额。

优选地，

所述支付平台还包括：

第二查询单元，用于当所述第一账户为满足预设自动支付条件的账户时，查询所述第一账户的可用余额；

所述支付单元，具体用于当所述第一账户有可用余额时，依据待支付金额以及所述可用余额使所述第一账户向所述第二账户进行支付操作，并形成支付结果。

优选地，

所述支付单元，具体用于当所述第一账户的可用余额不小于所述待支付金额时，控制所述第一账户向所述第二账户进行全额支付。

优选地，

所述支付平台，具体用于当所述第一账户的可用余额小于所述待支付金额时，控制所述第一账户向所述第二账户进行部分支付。

优选地，

所述判断单元还用于判断所述第一账户是否为满足预设自动延期条件的账户；

所述支付平台还包括：

延期单元，用于当所述第一账户为满足所述预设自动延期条件的账户时，向所述第二账户的客户端发送支付延期请求；

接收单元，用于接收所述第二账户的客户端基于所述支付延期请求形成的延期响应；

确定单元，用于依据所述延期响应重新确定支付日。

优选地，

所述支付平台还包括接收单元；

所述发送单元，还用于向第一账户的客户端发送所述待支付信息；

所述接收单元，用于接收所述第一账户的客户端返回的实际支付金额；

所述支付单元，还用于控制所述第一账户向所述第二账户支付所述实际支付金额。

优选地，

所述支付平台还包括：

核算单元，用于核算支付结果；

所述支付单元，还用于当依据所述支付结果确定第一账户向第二账户的支付金额超过待支付金额时，控制所述第二账户向所述第一账户进行返款操作。

优选地，

所述支付平台还包括接收单元及响应单元：

所述接收单元，用于接收所述第一账户的客户端发送的登录请求；

所述第一查询单元，还用于基于所述登录请求查询所述第一账户的待支付信息；所述待支付信息包括支付日和待支付金额；

所述响应单元，用于响应所述登录请求，允许所述客户端登录并向所述客户端发送包括所述待支付信息的第一登录附加信息或第二登录附件信息；

所述第一登录附加信息，用于控制所述客户端在登录后显示第一界面；所述第二登录附加信息，用于控制所述客户端在登录后显示第二界面；

所述第一界面不同于所述第二界面。

优选地，

所述支付平台还包括：

核算单元，用于核算所述第一账户的收支信息和支付结果；所述收支信息包括所述第一账户支付的实际支付日；所述支付结果中包括支付平台或所述第二账户收到支付的收到支付日；

校正单元，用于当所述第一账户的支付信息表明所述实际支付日早于收到支付日时，以所述实际支付日校正支付结果。

本发明实施例所述的信息处理方法和支付平台，支付平台可以查询待支付信息，并依据待支付信息可以控制第一账户向第二账户进行支付，相对于线下支付，显然用户不用跑到专门的柜台进行支付，节省了用户的时间和精力，相对于现有的线上支付，直接在该支付平台上就能查询待支付信息，不用通过其他支付工具来查询待支付信息，显然提高了支付平台的智能性和用户使用满意度；且同时避免了用户在不同平台查询待支付信息导致的差错问题。

附图说明

图1为本发明实施例所述的信息处理方法的流程示意图之一；

图2为本发明实施例所述的支付平台和客户端的连接示意图；

图3为本发明实施例所述的一种自动支付操作的流程示意图；

图4为本发明实施例所述的信息处理方法的流程示意图之二；

图5为本发明实施例所述的支付平台和客户端的信息交互示意图之一；

图6为本发明实施例所述的支付平台和客户端的信息交互示意图之二；

图7为本发明实施例所述的信息处理方法的流程示意图之三；

图8为本发明实施例所述的信息处理方法的流程示意图之四；

图9为本发明实施例所述的信息处理方法的流程示意图之五；

图10为本发明实施例所述的信息处理方法的效果示意图；

图11为本发明实施例所述的支付平台的结构示意图之一；

图12为本发明实施例所述的支付平台的结构示意图之二；

图13为本发明示例所述的信息处理效果图之一；

图14为本发明示例所述的信息处理效果图之二；

图15为本发明示例所述的支付系统的结构示意图；

图16为本发明示例所述的信息处理的流程示意图之一；

图17为本发明示例所述的信息处理的流程示意图之二；

图18为本发明示例所述的借款单的状态迁移示意图。

具体实施方式

以下结合说明书附图及具体实施例对本发明的技术方案做进一步的详细阐述。

方法实施例一：

如图1所示，本实施例提供一种信息处理方法，所述方法包括：

步骤S110：支付平台查询待支付信息；

步骤S120：依据所述待支付信息控制第一账户向第二账户进行支付操作，并形成支付结果；

步骤S130：依据所述支付结果，并生成支付反馈信息；已支付信息；

步骤S140：向所述第一账户和所述第二账户的客户端发送所述付反馈信息；

步骤S150：当所述支付结果表明支付成功时，更新所述第一账户和所述第二账户的收支信息。

本实施例所述信息处理方法的执行主体为支付平台(如图2中的支付平台100)，具体如财付通、支付宝、手机QQ的支付后台等在线支付平台。所述支付平台100可以为不隶属于第一账户和第二账户任意一方用户的中间支付平台。如第一账户和第二账户可为个人用户、企业用户或其他团体在所述支付平台上注册的用于支付、贷款或放贷等操作的操作账户。所述操作账户可以用于进行存款操作、支付操作、过账操作等操作。

所述支付平台对所述第一账户和所述第二账户的收支信息进行生成和管理，同时还用于根据支付等操作，进行资金结算和过账处理。

在本实施例中控制所述第一账户向所述第二账户进行支付操作，可包括所述支付平台在所述第一账户和所述第二账户之间进行过账信息处理。具体的如所述第二账户为开设在所述支付平台的操作账户，所述支付平台可以在所述第一账户进行支付时，待为接收所述第一账户支付的金额，并在所述支付平台与所述第二账户的结算日，一并与所述第二账户进行收支结算和支付。这样的话，当所述第二账户在一个结算周期内通过所述支付平台进行了多比交易时，可以减少支付平台与第二账户绑定的银行卡或第二账户的收支系统之间的多次支付，可以简化操作。在步骤S120中所述支付结果为表征支付是否成功的结果信息，包括支付成功和支付结果。

在图2中包括客户端201和客户端202；所述客户端201和客户端202可通过互连网连接到所述支付平台100中。客户端201的用户为第一用户在所述支付平台中注册的账户为所述第一账户。所述客户端202的用户为所述第二用户，在所述支付平台100中注册的账户为第二账户。

在图2中执行主体支付平台100，包括服务器、网关及支付数据库；其中，网关通过互连网(如移动网络或有线网络)连接到各个账户的客户端。网关可用于新信息过滤，以提高支付平台的安全性。

所述数据库可为专门存储数据的存储阵列等存储介质。所述数据库单独与服务器连接，服务器通过各种类型的通信接口，如USB、串口或并口与所述数据库连接，可以到所述数据库中查询所述待支付信息，如可用金额。

服务器用于数据处理，数据库用于存储服务器进行数据处理后形成的操作数据，这样能提高支付平台的安全性。具体如，服务器访问数据库中的数据，还可需要进行授权鉴定。所述支付网关可以为通用(General Gateway Interface，CGI)。

在具体实现时，所述支付平台还可以将所述支付网关、数据库和服务器集成设置在一个具有多种功能的服务器中。通常集成服务器都会自带存储介质，可用于充当所述数据库，所述集成处理器的处理芯片执行各种数据操作；运行在所述集成服务器上的防火墙可充当所述支付网关。

在本实施例中支付平台将自动查询到待支付信息，如定期的自动查询待支付信息等。支付平台依据待支付信息，在用户操作指令下或在满足预设自动支付条件时，控制第一账户向第二账户进行支付操作，无需用户到柜台进行支付，也无需用户通过其他方式查询待支付信息，因信息传输错误导致的多还或少还的现象。

所述步骤S120中具体可以是基于支付平台内的自动支付操作进行支付操作，也可以是基于用户操作的支付操作，当基于用户操作的支付时，所述方法还包括将所述待支付信息发送给第一账户的客户端，并接收用户输入的还款金额等操作。所述第一账户可以是个人用户或企业用户，现金流可以由第一账户绑定的银行卡向第二账户还的。本实施例提供了一种在线还款方式，提高了支付平台的智能性和用户使用满意度。

所述支付结果可包括支付成功结果和支付失败结果；所述支付成功结果包括全额支付结果和差额支付结果。所述全额支付结果为在支付时，第一账户全额支付所述待支付金额；差额支付为第一账户支付了部分所述待支付金额。

所述支付反馈信息可包括已支付信息和支付失败信息；当支付成功时，所述支付反馈信息为已支付信息，当支付失败时，所述支付反馈信息为支付失败信息。所述已支付成功信息包括实际已支付金额，还可包括仍需再次支付的待支付金额。

为了方便所述支付平台后续对第一账户和第二账户的精确和有效管理，在支付成功时，需要更新所述第一账户和第二账户的收支信息。所述方法还可把包括在支付失败时，形成支付操作记录，方便支付平台已经自动执行了达到指定支付操作次数时停止支付，避免做更多无用的支付操作。

综合上述，本实施例提供了一种信息处理方法，提高了支付平台的智能性且能够简化用户还款或支付流程。

方法实施例二：

如图1所示，本实施例提供一种信息处理方法，所述方法包括：

步骤S110：支付平台查询待支付信息；

步骤S120：依据所述待支付信息控制第一账户向第二账户进行支付操作，并形成支付结果；

步骤S130：依据所述支付结果，并生成支付反馈信息；已支付信息；

步骤S140：向所述第一账户和所述第二账户的客户端发送所述付反馈信息；

步骤S150：当所述支付结果表明支付成功时，更新所述第一账户和所述第二账户的收支信息。

所述第一账户和所述第二账户均为注册在所述支付平台上的操作账户。

所述步骤S120中控制所述第一账户向所述第二账户进行支付，具体可包括：

依据所述待支付信息，判断第一账户是否为满足预设自动支付条件的账户；

当所述第一账户为满足预设自动支付条件的账户时，控制所述第一账户向所述第二账户进行自动支付操作。

在本实施例在上一实施例的基础上做了进一步的改进，当所述第一账户时满足自动支付条件的账户时，在没有用户指示的条件下，所述支付平台将控制所述第一账户向所述第二账户进行自动支付，这样能够避免第一账户的用户忘记支付时，而并非恶意拖欠时导致逾期支付等问题，可以减少逾期利息或罚款，保障第一账户的用户的信用度不被损坏。

如何确定所述第一账户是满足所述预设自动支付的用户，可包括以下几种方式：

方式一：所述支付平台可以通过所述待支付信息的查询，确定出第一账户的支付日是否到期，所述支付可为支付截止日或指定支付日。

判断第一账户的支付日是否到期，即判断当前日是否为第一账户的支付日。所述支付日可以是支付截止日，还可以是指定支付日。所述支付截止日可以为第一账户与第二账户的约定支付日，通常为最后支付日，具体如信用卡还贷最后日。所述指定支付日为第一账户的用户自行指定的比支付截止日早的支付日。

所述支付日是否到期的判断，具体如当前日为2014年10月4日，而支付日为2014年10月5日，通过日期匹配可以判断支付为并非为当前日，所述支付日表明第一账户的支付并未到期；若支付日完成2014年10月4日，显然当前日便是支付日；则表明第一账户的支付到期。当支付未到期时，所述支付平台也不进行自动支付操作。

方式二：

当第一账户的待支付金额超过预设待支付额度时，确定所述第一账户为满足预设自动支付条件的账户。具体如，第一账户的待支付额度为2万，但是此时用户的需要偿还的待支付金额已经达到了3万，为了防止第一账户的自动借贷或帮助第一账户进行理财，此时同样可以触发支付平台进行自动支付操作。

具体的如何确定第一账户是满足预设自动支付条件的账户的判断方法不局限上述两种。

值得注意的是，在执行所述自动支付操作时，可能还需要确定第一账户是否为用户授权进行自动支付操作的用户，如通过查询授权标记等操作来确定所述第一账户是否已授权支付平台进行自动支付操作的用户，这样能提高用户对第一账户的收支处理的控制性。

方法实施例三：

如图1所示，本实施例提供一种信息处理方法，所述方法包括：

步骤S110：支付平台查询待支付信息；

步骤S120：依据所述待支付信息控制第一账户向第二账户进行支付操作，并形成支付结果；

步骤S130：依据所述支付结果，并生成支付反馈信息；已支付信息；

步骤S140：向所述第一账户和所述第二账户的客户端发送所述付反馈信息；

步骤S150：当所述支付结果表明支付成功时，更新所述第一账户和所述第二账户的收支信息。

所述第一账户和所述第二账户均为注册在所述支付平台上的操作账户。

所述待支付信息包括待支付金额；

所述步骤S120中的控制第一账户向所述第二账户进行自动支付操作，包括：

依据所述待支付信息控制所述第一账户向所述第二账户进行N次自动支付操作；

其中，第n次自动支付操作的支付金额为第n金额；

第n+1次自动支付操作在第1次至第n次自动支付操作的支付失败时进行，且第n+1金额小于第n金额；

所述N为不小1的正整数；所述n为小于所述N的正整数；

第1金额不大于所述待支付金额。

第一账户的可支付金额包括存储在支付平台上的可支付金额，还可以包括与所述第一账户绑定的银行卡内的可支付金额；但是所述支付平台可以要求银行系统向支付平台的第一账户进行支付。在具体实现时，支付平台可能无法从银行系统获取到第一账户的银行卡的可支付金额，利用要求银行系统向支付平台的第一账户进行支付的特点，直接在无法获知第一账户的可支付金额的情况下进行自动支付操作。

第1次执行自动支付时，支付平台可以控制所述第一账户向所述第二账户进行全额自动支付。若第1次执行自动支付时支付失败，导致失败的原因可能时要求进行支付的金额过高，第一账户的银行卡及支付平台上存储的可支付金额不够，还可能是其他原因。显然当要求支付金额过高时，可以通过降低要求支付金额，实现后续的差额自动支付，故若全额自动支付失败，则进行第2次自动支付操作，不过第2次自动支付操作的第2金额小于所述第1金额而已，反复执行直至所述第N金额为0或执行的次数达到预定次数为止。所述第1金额至所述第N金额均为自动支付金额，即支付平台以该自动支付金额控制所述第一账户向所述第二账户进行支付。

在具体的实现过程中，后一次自动支付操作的自动支付金额可以为前一次自动支付操作的自动支付金额的1/2或1/3。

当所述N＝1时，即所述支付平台仅执行1次自动支付操作，当所述N大于或等于2时，所述支付平台将执行多次自动支付操作。

具体如，第一账户需要向第二账户支付1000元，若所述第一账户是满足预设自动支付条件的账户，支付平台第1次执行自动支付操作时，控制所述第一账户向所述第二账户支付1000元，但是操作失败，此时根据前后两次支付金额的梯度额，确定下一次自动支付金额。若所述梯度额为500，即为待支付金额的1/2，则第2次进行自动支付的自动支付金额为500。若第2次失败，还可以进行第3次，直至达到第N次；或自动支金额为0为止。

图3为本实例中所述自动支付操作的一个流程示意图；

所述步骤S120可包括：

步骤S1201：依据自动支付梯度额确定第n金额，其中，当n等于1时，所述第n金额为所述待支付金额，所述自动支付梯度额可以预先设定好的递减支付额度或依据支付梯度函数关系确定的递减额度；

步骤S1202：依据所述第n金额，控制所述第一账户向所述第二账户执行第n次自动支付操作；

步骤S1203：判断第n次自动支付操作是否支付成功；若否则进入步骤S1204，若是可以停止自动支付；

步骤S1204：所述n执行加1操作；

步骤S1205：判断所述n是否小于所述N，所述N可为最大自动支付操作次数；若是，则返回步骤S1201。

本实施例所述的方法可以在与第一账户绑定的银行系统拒绝提供第一账户绑定的银行账户中的可支付金额时，依据能够进行自动支付，以减少用户金钱和信用损失。

方法实施例四：

如图4所示，本实施例提供一种信息处理方法，所述方法包括：

步骤S210：查询待支付信息；

步骤S220：依据所述待支付信息，判断第一账户是否为满足预设自动支付条件的账户；若所述第一账户为满足预设自动支付条件的账户，则进入步骤S230；

步骤S230：查询所述第一账户的可用余额；

步骤S240：当所述第一账户有可用余额时，依据待支付金额以及所述可用余额使所述第一账户向所述第二账户进行支付操作，并形成支付结果；

步骤S250：依据所述支付结果，形成支付反馈信息；

步骤S260：向所述第一账户和所述第二账户的客户端发送所述支付反馈信息；所述支付反馈信息为已支付信息或支付失败信息。

所述方法还包括：

当依据所述支付结果确定支付成功时，更新所述第一账户和所述第二账户的收支信息。

本实施例是在上一方法实施例上的进一步详细限定，方法实施例一中的步骤S120可详细包括本实施例中的步骤S220至步骤S240。

在本实施例中，所述支付平台可在每天的指定时间内检测每一个待款用户账户的待支付信息。其中，所述指定时间，可以是在任意支付平台处理任务繁重度较小的时候，具体如夜里22：00以后，通常此时，支付平台收到的用户基于客户端发送的各种支付请求、还贷请求或借款请求数较少。

步骤S210中查询所述待支付信息包括以下三种方式：

第一种：批量以支付到期日为检索索引，查询待支付信息；所述待支付信息中可包括支付账户；此外还可包括待支付金额以及接收支付的账户。具体如，通常一个支付平台是由多个服务器通过互联网等设备形成的设备群；这些设备群管理成千上万，甚至更多的账户，采用以支付到期日为检索索引进行查询，方便支付平台一次性确定出所有支付到期的账户等信息；具有信息处理效率高的优点。具体如通过检索发现，2014年10月10日，用户张三需要向小贷公司A偿还贷款、李四向商家B支付货款、吴七向王五支付借款的支付日都到期了，此时，若张三、李四和吴七都向授权支付平台到期自动支付，则所述支付平台通过此次批量查询首先查询到待支付账户，再逐个账户查询待支付金额以及接收支付账户进行自动支付。

第二种：以第一账户为检索索引，查询第一账户的待支付信息；所述待支付信息可包括支付日，还可包括待支付金额以及接收支付的账户。以上述张三、李四和吴七，则支付平台需要逐个建立张三、李四和吴七的待支付信息，逐个查询张三、李四和吴七的待支付信息来进行确定。

第三种：以第二账户检索索引，查询第二账户对应借款金的支付日；所述待支付信息可包括第一账户；还可包括待支付金额等信息。本方式不同于上述两种方式的是，在本方式中支付平台查询的是小贷公司A、商家B以及王五在支付平台上建立的账户(即所述第二账户)，而非张三、李四和吴七在支付平台上申请注册的账户。

无论采用哪种方式，支付平台都可以通过查询待支付信息确定出哪些账户今天需要向其他账户支付，支付平台要执行自动支付操作。上述三种查询待支付信息的方法不局限于本实施例中，同样可以用于方法实施例一至方法实施例三中。

值得注意的是：在本实施例中所述方法还包括：确定第一用户是否授权支付平台进行导致支付的操作的步骤，当第一账户已向支付平台授权进行自动支付操作时，支付平台才在第一账户有可用余额时，使第一账户向所述第二账户进行支付操作。

在具体中，进行确定授权验证的方法也有很多种，具体如，针对第一种待支付信息查询方法，可视根据授权标注授权账户，建立授权账户到期支付信息表；在进行查询时，凡是该支付信息表中的用户都可认为是授权自动支付的账户。所述确定是否授权支付平台进行自动支付操作的授权账户，在支付平台的数据库中为所述授权账户建立授权信息，如授权属性，或将账户分为授权账户类型和非授权账户类型，在执行步骤S210之前或执行步骤S220之前，通过查询授权属性和/或账户类型等授权标记来确定第一账户是否授权支付平台进行自动支付操作。当第一账户并非授权账户时，支付平台不执行自动支付操作。

当所述步骤S210中采用第二种或第三种方式进行待支付信息的查询时，在步骤S220中还包括依据待支付信息确定第一账户是否为满足自动支付条件的账户，具体如何判断可以是：判断第一账户的支付日是否到期，即判断当前日是否为第一账户的支付日。所述支付日可以是支付截止日，还可以是指定支付日。所述支付截止日可以为第一账户与第二账户的约定支付日，通常为最后支付日，具体如信用卡还贷最后日。所述指定支付日为第一账户的用户自行指定的比支付截止日早的支付日。

所述支付日是否到期的判断，具体如当前日为2014年10月4日，而支付日为2014年10月5日，通过日期匹配可以判断支付为并非为当前日，所述支付日表明第一账户的支付并未到期；若支付日完成2014年10月4日，显然当前日便是支付日；则表明第一账户的支付到期。当支付未到期时，所述支付平台也不进行自动支付操作。

在本实施例中，根据步骤S220的判断结果为第一账户为满足预设自动支付条件的账户时，可认为当有账户的支付日为当前日，且没有收到用户通过客户端发送的支付请求时，自动由第一账户向出借账户(即上述第二账户)进行支付，只要所述第一账户有可用余额就能进行支付；这样能够避免用户在忘记支付时，而非恶意拖欠时导致逾期未还利息增加和罚金等问题，提高了支付服务器的智能性。

在具体的实现过程中，所述满足预设自动支付条件的账户的判断，还可以是：当第一账户的待支付金额超过预设待支付额度时，确定所述第一账户为满足预设自动支付条件的账户。具体如，第一账户的待支付额度为2万，但是此时用户的需要偿还的待支付金额已经达到了3万，为了防止第一账户的自动借贷或帮助第一账户进行理财，此时同样可以触发支付平台进行自动支付操作。

当步骤S220中的判断结果为否，即所述第一账户为非满足预设自动支付条件的账户时，可以转入其他处理流程或结束本实施例所述的信息处理流程。

所述第一账户的可用资金可以为如财付通内的可用余额，也可以是所述第一账户绑定的银行卡中的可用余额。

所述使所述第一账户向所述第二账户进行支付，具体可以可包括向第一账户发送现金提取信息，从所述第一账户中提取可用余额转账到第二账户；使所述第一账户向所述第二账户进行支付的结果是，所述第一账户的可用金额在没有进账的情况下，可用金额减少；第二账户在没有出账的情况先可用金额增加。

在具体的实现过程中，还可以是从第一账户提取出待支付金额，转账到中间平台，如本实施例中所述的支付平台，仅向第二账户发送关于支付的信息，待到支付平台与第二账户的结算日，由中间平台将第一账户支付的待支付金额转账到第二账户。

在具体实现时，所述步骤S240根据第一账户中的可用余额数，执行的操作不同；

当所述第一账户的可用余额不小于所述待支付金额时，控制所述第一账户向所述第二账户进行全额支付。具体如，第一账户需要向第二账户支付500美元，而此时用户第一账户的可用余额不少于500美元，如1000美元；显然第一账户的可余额足以支付第二账户，于是进行全额支付，避免因逾期支付导致的支付罚金、支付利息以及支付信用度等问题。

当所述第一账户的可用余额不为零且小于所述待支付金额时，控制所述第一账户向所述第二账户进行部分支付。具体如，第一账户需要向第二账户支付500美元，而此时用户第一账户的可用余额不少于300美元；显然第一账户的可余额不足以支付第二账户，于是进行部分支付，至少可减少预期支付数，降低支付罚款和支付利息等问题。

在步骤S250支付结果包括两种；支付成功和支付失败；本实施例所述步骤S250在支付结果为支付成功时，才会根据支付结果更新第一账户和第二账户的收支信息。所述收支信息包括支付信息以及收入信息；支付信息为向外支付产生的信息，具体的包括对外支付时间、对外支付金额、对方账户信息。所述收入信息，收入金额、收入时间、支付收入的账户。更新这些信息具体包括在第一账户对应的信息记录中根据支付结果增加新的支付信息；在第二账户对应的信息记录中根据支付结果增加新的收入信息等。

通过收支信息的形成，方便后续用户通过客户端登录到支付平台，查询支付记录、收入记录；也方便后续支付平台进行对账与核算等操作。

此外，支付平台实现了第一账户到第二账户的自动支付操作，需要告知用户已经实现了支付，让用户知悉，故本实施例中还包括步骤S250生成已支付信息，告知用户已经完成了支付。所述已支付信息可以简单的表示已经完成了支付，也可以时支付详细信息，如支付金额、支付方式(从第一账户绑定的银行卡支付、财付通支付等快捷支付)、支付时间、支付后可用金额等信息。

综合上述，本实施例提供了一种自动支付的信息处理方法，可以实现避免第一账户的用户无暇或忘记支付，导致逾期支付，进而导致的罚金、逾期利息以及信用度降低的问题，同时对于第二账户的用户的资金无法得到支付，导致的财务问题等；总体提高了支付系统的智能性，降低了用户操作的繁琐性，提高了用户使用满意度。

以下结合图5至图7提供两个具体导致第一账户需要向第二账户进行支付的应用场景。

如图5所示，在应用场景1中在发送本发明实施例之间可能发生如下支付流程：

步骤S101：第一用户的客户端201向支付服务器发送借贷请求；

步骤S102：支付服务器将所述借贷请求发送给第二账户的客户端202所述借贷请求；

步骤S103：客户端202根据第二用户指示，向支付服务器发送借贷响应；

步骤S104：支付服务器向客户端201发送借贷响应；

步骤S105：支付服务器向支付数据库发送借贷记录；

步骤S106：支付数据库更新第一账户和第二账户的收支信息。

在具体实现时，所述步骤S101至步骤S104是顺序执行的，所述步骤S105与所述步骤S104之间没有一定的先后顺序，仅需保证所述步骤S105在所述步骤S103之后即可。

在执行步骤S106之前，所述第一账户的收支信息如图3中所示，在2014年10月4日12:00之前的可用金额为0:00元；从第二账户借贷了2000元后，于2014年4日12:01分以后可用金额为2000元。此后，第一用户可以从第一账户中到支付平台的现金支付客户端提取现金，也可以通过第一账户向连接在所述支付平台上的其他账户进行支付。

所述第二账户的收支信息如图5所示，在2014年10月4日12:00之前的可用金额为5.5万元；向第一账户出贷了2千元后，于2014年4日12:01分以后可用金额为5.2万元。

如图6所示，在应用场景2中在发送本发明实施例之间可能发生如下支付流程：

步骤S201：第一用户的客户端201向支付服务器发送代付请求；具体如，第一用户通过客户端在网络上购买了某一物品，但是不想自行支付或自己支付金额不足，此时可以申请代付；代付之后，第一账户需要在支付日进行还款。

步骤S202：支付服务器将所述借贷请求发送给第二账户的客户端202所述代付请求；

步骤S203：客户端202根据第二用户指示，向支付服务器发送代付响应；

步骤S204：支付服务器向客户端201发送代付响应；

步骤S205：支付服务器向支付数据库发送代付记录；

步骤S206：支付数据库更新第一账户、第二账户和第三账户的收支信息。

在具体实现时，所述步骤S201至步骤S204是顺序执行的，所述步骤S205与所述步骤S204之间没有一定的先后顺序，仅需保证所述步骤S205在所述步骤S203之后即可。

在执行步骤S206之前，所述第一账户的收支信息如图4中所示，在2014年10月5日8:00之前的可用金额为3千元；请第二账户代付5000元后，于2014年5日8:01分以后形成有欠第二账户5千元收支信息。此后，第一用户需要向第二账户支付5千元。

所述第二账户的收支信息如图5所示，在2014年10月5日8:00之前的可用金额为5.5万元；为第一账户向第三账户代付了5千元后，于2014年5日8:01分以后可用金额为5.0万元。

所述第三账户的收支信息如图6所示，在2014年10月5日8:00之前的可用金额为1千元；第三账户收到第一账户代付的5千元后，于2014年5日8:01可用金额变更为6千元。

若基于第一账户和第二账户的协商，第一账户需要向第二账户的支付贷款或代付金额的支付日为10月5日；则在10月5日基于本发明实施例所述的方法，会发生如图7或图8所示的支付流程：

如图7所示，在应用场景3中基于本发明实施例一可能发生如下支付流程之一：

步骤S301：支付服务器在支付数据库中待支付信息；

步骤S302：支付服务器接收支付数据库发送的待支付信息；

步骤S303：当依据所述待支付信息确定所述第一账户满足为满足所述预设自动支付条件的账户时，所述支付服务器执行自动支付操作，即实现根据待支付金额及第一账户的可用金额，在第一账户和第二账户之间进行转账。所述预设自动支付条件可包括：当根据所述待支付信息确定第一账户向第二账户进行支付的了支付日已经到期，则支付服务器进行自动支付操作；这种方式优选为当第一用户开设在支付平台100上还有可用金额或用户指定以第一账户开设在支付平台上的可用金额进行支付时，支付服务器仅需在其内部进行第一账户和第二账户之间信息流的更改，之后资金流的变更可以在支付平台与第二账户结算时来处理。

第一用户的客户端201向支付服务器发送代付请求；具体如，第一用户通过客户端在网络上购买了某一物品，但是不想自行支付或自己支付金额不足，此时可以申请代付；代付之后，第一账户需要在支付日进行还款。

步骤S304：支付服务器与所述支付数据库进行支付结果的交互。

步骤S305：支付数据库根据支付结果更新第一账户和第二账户的收支信息。具体如图7所示，第一账户在支付服务器执行自动支付操作之前(即图示脏鞥你的2014年10月5日8:00之前)的可用金额为1万元，在执行自动支付操作之后，可用金额为5千元，并形成了已支付第二账号5千元的已支付记录。

步骤S306：支付服务器生成已支付信息，分别向第一账户和第二账户的客户端发送。

如图8所示，在应用场景4中基于本发明实施例可能发生如下支付流程之二：

步骤S401：支付服务器在支付数据库中待支付信息；

步骤S402：支付服务器接收支付数据库发送的待支付信息；

步骤S403：当依据所述待支付信息确定所述第一账户满足为满足所述预设自动支付条件的账户时，所述支付服务器执行自动支付操作，即实现根据待支付金额及第一账户的可用金额，在第一账户和第二账户之间进行转账。在本应用场景中，第一账户在支付平台上没有直接可用金额，但是其绑定的第三方平台上的银行卡或支付账号中有可用金额，同样认为第一账户中有可用金额。此时，支付平台在执行自动支付操作时，包括支付服务器向与第一账号绑定的支付账号(如银行卡账号或其他支付平台的支付账号)发送提取请求，并接收与第一账号绑定的支付账户的响应提取；依据所述响应提取确定自动支付操作是否成功。所述响应提取包括与第一账号绑定的支付账号，依据提取请求中指定提取的金额向支付服务器所在的支付平台进行金额转账等操作。

步骤S404：支付服务器与所述支付数据库进行支付结果的交互。

步骤S405：支付数据库根据支付结果更新第一账户和第二账户的收支信息。具体如图8所示，第一账户在支付服务器执行自动支付操作之前(即图示中的2014年10月5日8:00之前)的可用金额为1万元，在执行自动支付操作之后，可用金额为5千元，并形成了已支付第二账号5千元的已支付记录。

步骤S406：支付服务器生成已支付信息，分别向第一账户和第二账户的客户端发送。

综合上述，本实施例中提供了一种支付平台在满足预设自动支付条件时，执行自动支付操作的信息处理方法，这样增加了支付平台的智能性，避免了用户在忘记支付时导致的支付逾期带来的额外的支付利息、罚金和信用不佳的问题，同时还能进而能的保证未等待接收支付的账户，准时收到支付，以免用户出现未接受到支付导致的资金中断等问题。

方法实施例五：

如图9所示，本实施例提供一种信息处理方法，所述方法包括：

步骤S110：支付平台查询待支付信息；

步骤S120：依据所述待支付信息控制第一账户向第二账户进行支付操作，并形成支付结果；步骤S120具体可为依据所述待支付信息，判断第一账户是否为满足预设自动支付条件的账户；当所述第一账户为满足预设自动支付条件的账户时，控制所述第一账户向所述第二账户进行自动支付操作；

步骤S130：依据所述支付结果，生成支付反馈信息；所述支付反馈信息可包括已支付信息或支付失败信息；

步骤S140：向所述第一账户和所述第二账户的客户端发送所述已支付信息；所述第一账户和所述第二账户均为注册在所述支付平台上的操作账户。

步骤S150：当所述支付结果表明支付成功时，依据所述支付结果更新所述第一账户和所述第二账户的收支信息；

步骤S160：判断所述第一账户是否为满足预设自动延期条件的账户；

步骤S170：当所述第一账户为满足所述预设自动延期条件的账户时,向所述第二账户的客户端发送支付延期请求；

步骤S180：接收所述第二账户的客户端基于所述支付延期请求形成的延期响应；

步骤S190：依据所述延期响应重新确定支付日。

在本实施例中，当所述第一账户没有可用金额时，可认为第一账户的可用资金不足时，确定所述第一账户为满足预设自动延期的账户；还可认为当进行了自动支付操作后，所述第一账户还有待支付金额未支付时，却床能第一账户为满足所述预设自动延期的账户。

在本实施例中，为了避免逾期支付导致的额外利息或罚金，进一步导致第一账户的用户的资金困难，此时可以基于第一账户的授权，进行自动请求支付延期。若第二账户的用户同意所述支付延期请求，则可以在所述第二账户的客户端发送的延期响应中进行指示。所述延期响应中可以携带各种延期事项，如延期支付截止日，延期附加费等问题。具体如，同意延期15天，所述延期附加费可包括延期手续费等。具体若第一账户预期支付，则将罚款1千元，但是进行了延期支付，则无需罚款，但是伴随延期可能导致支付平台以及第二账号一些额外的事宜，可能需要支付延期手续非20元，显然为第一账户节省了一笔钱，显然同样有利于提升用户使用满意度。

在具体的实现过程中，支付平台在第二账户的同意下对第一账户应付金额进行延期后，还可依据重新确定的支付日生成支付提醒信息；向所述第一账户的客户端发送所述支付提醒信息。

若在支付延期过程中产生了支付延期附加费或其他需要用户注意的事项，此时还包括向所述第一账户的客户端支付提醒信息中携带所述支付延期附加费或其他需要用户注意的事项。

方法实施例六：

如图1所示，本实施例提供一种信息处理方法，所述方法包括：

步骤S110：支付平台查询待支付信息；

步骤S120：依据所述待支付信息控制第一账户向第二账户进行支付操作，并形成支付结果；

步骤S130：依据所述支付结果，并生成支付反馈信息；已支付信息；

步骤S140：向所述第一账户和所述第二账户的客户端发送所述付反馈信息；

步骤S150：当所述支付结果表明支付成功时，更新所述第一账户和所述第二账户的收支信息。

所述待支付信息包括第一账户需向所述第二账户支付的待支付金额；

所述步骤S120可包括：向第一账户的客户端发送所述待支付信息；接收所述客户端返回的实际支付金额；及控制所述第一账户向所述第二账户支付所述实际支付金额。

在本实施例中不同于方法实施例二的地方在于，本实施例是将所述待支付信息发送给第一账户的客户端，客户端将向用户呈现这些待支付信息，并接收用户操作指示，在执行第一账户向第二账户进行支付的操作。

所述用户操作指示包括指示支付的金额、指示第一账户中用户支付的银行卡或财付通等支付账号。不管是以银行卡支付还是以财付通等支付账号进行支付，实际支付金额都需要经由第一账户转入到第二账户，并在第一账户形成响应的收支信息。

本实施例提供了一种基于用户操作指示的线上支付的信息处理方法，相对于线下支付显然节省了用户的时间和精力，且用户会直接接收到支付平台的待支付信息，不用对自行查询待支付信息，再次节省了用户的时间和精力，提高了平台的智能性和用户使用满意度。

方法实施例七：

如图1所示，本实施例提供一种信息处理方法，所述方法包括：

步骤S110：支付平台查询待支付信息；

步骤S120：依据所述待支付信息控制第一账户向第二账户进行支付操作，并形成支付结果；

步骤S130：依据所述支付结果，并生成支付反馈信息；已支付信息；

步骤S140：向所述第一账户和所述第二账户的客户端发送所述付反馈信息；

步骤S150：当所述支付结果表明支付成功时，更新所述第一账户和所述第二账户的收支信息。

所述方法还包括：

核算支付结果；

当依据所述支付结果确定第一账户向第二账户的支付金额超过待支付金额时，控制所述第二账户向所述第一账户进行返款操作。

具体的所述控制所述第二账户向所述第一账户进行返款操作，包括：

依据所述支付结果向所述第二账户发送返款请求；

接收所述第二账户基于所述返款请求生成的返款响应；

依据所述返款响应向所述第一账户支付返款。具体如和进行返款操作，与如图7或图8中第一账户向第二账户现金流的支付过程类似，在此就不再重复了。本实施例所述的核算支付结果等操作具体为方法实施例二或方法实施例三的基础上的进一步改进，在第一账户向第二账户支付了之后，通过支付结果的核算，避免第一账户有多支付出现溢出款等问题，支付平台通过控制第二账户向第一账户反馈，可以很好的解决上述问题。

在具体实现过程中，通过支付平台由第一账户向第二账户进行支付，并不是唯一的支付方式，用户还可能通过线下柜台或其他线上支付方式进行转账，可能会导致重复支付的问题，此时由于各个系统的支付之间没有及时结算或对账可能导致重复支付在用户支付的瞬间没有办法完成，在本实施例中为了方便用户申请退账导致的各种繁琐操作。支付平台将在指定时间内进行支付结果的核算，当出现支付金额超过待支付金额时，控制第二账户向所述第一账户进行返款操作，即将第一账户多支付的部分返回给第一账户。在本实施例中支付平台对所述第一账户的支付金额超过待支付金额的部分的返款操作，可认为是溢出款处理操作。本实施例中通过溢出款处理操作，进一步增加了支付平台的智能性，避免了用户填单进行申请返款或将溢出款作为留滞款等到下一个支付周期导致的用户不满的问题。

方法实施例六：

如图1所示，本实施例提供一种信息处理方法，所述方法包括：

步骤S110：支付平台查询待支付信息；

步骤S120：依据所述待支付信息控制第一账户向第二账户进行支付操作，并形成支付结果；

步骤S130：依据所述支付结果，并生成支付反馈信息；已支付信息；

步骤S140：向所述第一账户和所述第二账户的客户端发送所述付反馈信息；

步骤S150：当所述支付结果表明支付成功时，更新所述第一账户和所述第二账户的收支信息。所述第一账户和所述第二账户均可为注册在所述支付平台上的操作账户。

所述方法还包括：

接收所述第一账户的客户端发送的登录请求；

基于所述登录请求查询所述第一账户的待支付信息；所述待支付信息包括支付日和待支付金额；

响应所述登录请求，允许所述客户端登录并向所述客户端发送包括所述待支付信息的第一登录附加信息或第二登录附件信息；

所述第一登录附加信息，用于控制所述客户端在登录后显示第一界面；所述第二登录附加信息，用于控制所述客户端在登录后显示第二界面；

所述第一界面不同于所述第二界面。

用户在通过客户端登录支付平台100，以查看用户在支付平台100申请注册的账户的收支信息以及可用金额等信息时，可能需要先申请登录支付平台，此时，支付平台100根据用户的登录请求，进行用户名和密码等鉴权操作之后，认为当前申请登录的用户为合法用户，则运行对应的客户端登录，建立该客户端与支付平台之间的链路和信息交互连接。

于此同时，本实施例所述的方法，还将根据客户端对应的账户的收支信息，向所述客户端发送第一登录附加信息或第二登录附件信息。

具体如，若第一账户需要向第二账户进行支付，且当前时间距离所述支付日在指定时间范围内时，则向所述客户端发送第一登录附加信息；否则，向所述客户端发送所述第二登录附加信息。所述第二账户可以为一个账户或多个账户，为第一账户需要进行支付的账户。

所述第一界面可以为支付界面，因为第一账户需要对第二账户进行支付，则登录直接进入支付界面，并在支付界面显示待支付信息，如待支付金额、接收支付账户等信息，以便提醒用户进行支付，再次提高了支付平台的智能性。当用户无需向其他账户进行支付的情况下，请求登录，用户有很大的记录可能是需要向其他账户进行借贷或请求第二账户进行代付，或对第一账户的信息进行查询，若还是显示支付界面显然会干扰到用户操作，故此时，向客户端发送第二支付附件信息，控制客户端显示第二界面，如查询收支信息的查询界面或可以进行申请借贷的借贷界面。

具体如图10所示，客户端A和客户端B分别向支付平台100发送登录请求，客户端A在被允许登录后，还接收到了支付平台100发送的第一登录附加信息，而客户端B则接收到了支付平台100发送的第二登录附加信息。

客户端A根据所述第一登录附加信息由登录界面切换到了支付界面，而客户端B根据所述第二登录附加信息由登录界面切换到了借贷界面。

在具体的实现过程中，所述第一登录附加信息和第二登录附加信息，均可以是控制指令；客户端中都相应的存储有支付界面和借贷界面(即第一界面和第二界面)等界面信息，客户端根据所述控制指令，选择显示对应的界面。

所述第一登录附加信息还可以是第一界面的第一显示信息，所述第一显示信息可以包括界面信息和待支付信息等信息内容。第二登录附加信息还可以是第二界面的第二显示信息，所述第二显示信息包括界面信息和可借贷或收支信息等信息的信息内容。客户端接收到第一登录附加信息和第二登录附加信息后，直接依据所述第一或第二显示信息进行显示。

在图10中，客户端A显示的支付界面显示有的待支付信息包括：待还金额600元，支付日：2014年10月7日，周六等。客户端B显示的接待界面显示的信息包括：借贷方：小贷公司A，还贷周期30天等信息。

在实际执行时，不管所述支付平台采用哪一种方式是基于用户操作指示或是第一账户为满足预设自动支付条件的账户的自动支付，用户都可以通过登录支付平台查看信息，本实施例中利用用户登录支付平台的间隙，控制客户端的显示界面，在用户有待支付金额时，可控制客户端显示待支付界面，从而达到提示的作用，在用户没有支付金额时，预计用户可能需要借款或查询收支信息，从而控制客户端显示查询界面或借贷界面，以提高包括支付平台的整个系统的智能性。

方法实施例七：

如图1所示，本实施例提供一种信息处理方法，所述方法包括：

步骤S110：支付平台查询待支付信息；

步骤S120：依据所述待支付信息控制第一账户向第二账户进行支付操作，并形成支付结果；

步骤S130：依据所述支付结果，并生成支付反馈信息；已支付信息；

步骤S140：向所述第一账户和所述第二账户的客户端发送所述付反馈信息；

步骤S150：当所述支付结果表明支付成功时，更新所述第一账户和所述第二账户的收支信息。所述第一账户和所述第二账户均可为注册在所述支付平台上的操作账户。

所述方法还包括：

核算所述第一账户的收支信息和支付结果；所述收支信息包括所述第一账户支付的实际支付日；所述支付结果中包括支付平台或所述第二账户收到支付的收到支付日；

当所述第一账户的支付信息表明所述实际支付日早于收到支付日时，以所述实际支付日校正支付结果。

所述收支信息和支付结果包括基于用户操作指示进行支付的支付信息和支付结果，还可包括基于预设自动支付条件判断后执行支付的支付信息和支付结果。

在具体实现时，用户A可能指示支付平台对用户B的第二账户进行了支付，可是在支付的过程中，因为网络不稳定或支付延时的问题，导致支付平台没有及时或正确的收到支付结果，但是用户A实际已经进行了支付，如第三方的支付账号已经向第二账号进行了转账等操作时，可能会导致用户A的第一账户出现逾期还款的问题，导致用户A的第一账户出现罚金或信用透支等问题，进而导致用户不满。为了解决上述问题，在本实施例中还会进行第一账户的收支信息和支付结果的核算，以确定实际支付日，并根据实际支付日来校正支付结果；再次提高了支付平台的智能性和用户使用满意度。

此外，所述支付平台还可以接收所述第一账户的客户端发送的支付指示；响应所述支付指示，使所述第一账户向所述第二账户进行支付。所述支付指示可以是在支付截止后指定支付日之前发送的，也可以是在所述支付截日之后发送的，总之所述支付平台还包括提前支付和逾期支付接口，以便用户通过客户端进行手动支付。

综合上述，本实施例提供了多个信息处理方法的技术方案，上述技术方案在互不矛盾的情况下，均可以结合使用，以提高支付平台的综合处理能力和智能性，具体的如何一一结合使用，在此就不早一一赘述了。

设备实施例一：

如图11所示，本实施例提供一种支付平台，所述支付平台包括：

第一查询单元110，用于查询待支付信息；

支付单元120，用于依据所述待支付信息控制第一账户向第二账户进行支付操作，并形成支付结果；

生成单元130，用于依据所述支付结果，生成支付反馈信息；所述支付反馈信息为反馈给客户端的信息，通常可包括已支付信息或支付失败信息；

发送单元140，用于向所述第一账户和所述第二账户的客户端发送所述已支付信息；

更新单元150，用于当所述支付结果表明支付成功时，更新所述第一账户和所述第二账户的收支信息；所述第一账户和所述第二账户均可为注册在所述支付平台的操作账户。所述支付平台可为独立于所述第一账户和所述第二账户的中间操作平台或第三方操作平台。

本实施例所述第一查询单元110、支付单元120、生成单元130及更新单元150的具体结构可包括处理器及存储介质；所述存储介质和所述处理器通过总线连接；所述存储介质上存储有可执行代码，所述处理器通过读取并执行所述可执行代码，能够执行上述单元的功能。所述第一查询单元110、支付单元140及更新单元150中的任意两个可以集成对应一个处理器，或单独分别对应不同的处理器。当一个所述处理器对应两个上述功能单元时，所述处理器可以采用并发线程或时分处理等方式处理不同单元的功能。

所述处理器可以是应用处理器AP、中央处理器CPU、数字信号处理器DSP、可编程阵列PLC或微处理器MCU等结构。

所述发送单元140的具体结构可包括与外设连接的各种类型的通信接口，如有线通信接口或无线通信接口；所述有线通信接口可包括光缆通信接口及电缆通信接口的任意一种。所述无线通信接口可包括接收天线等。所述接收天线可以WIFI天线，2G、3G、4G或5G天线等。

本实施例提供了一种供用户线上还款的支付平台，可以方便用户线上还款，具有支付平台智能性高及用户使用满意度高的优点。

设备实施例二：

如图11所示，本实施例提供一种支付平台，所述支付平台包括：

第一查询单元110，用于查询待支付信息；

支付单元120，用于依据所述待支付信息控制第一账户向第二账户进行支付操作，并形成支付结果；

生成单元130，用于依据所述支付结果，生成支付反馈信息；所述支付反馈信息为反馈给客户端的信息，通常可包括已支付信息或支付失败信息；

发送单元140，用于向所述第一账户和所述第二账户的客户端发送所述已支付信息；

更新单元150，用于当所述支付结果表明支付成功时，更新所述第一账户和所述第二账户的收支信息；所述第一账户和所述第二账户均可为注册在所述支付平台的操作账户。

所述支付平台还包括：

判断单元，用于依据所述待支付信息，判断第一账户是否为满足预设自动支付条件的账户；

所述支付单元，用于当所述第一账户为满足预设自动支付条件的账户时，控制所述第一账户向所述第二账户进行自动支付操作。

本实施例所述判断单元的具体结构可包括处理器及存储介质；所述存储介质和所述处理器通过总线连接；所述存储介质上存储有可执行代码，所述处理器通过读取并执行所述可执行代码，能够执行上述单元的功能。所述判断单元120、支付单元120、生成单元130及更新单元150中的任意两个可以集成对应一个处理器，或单独分别对应不同的处理器。当一个所述处理器对应两个上述功能单元时，所述处理器可以采用并发线程或时分处理等方式处理不同单元的功能。

所述处理器可以是应用处理器AP、中央处理器CPU、数字信号处理器DSP、可编程阵列PLC或微处理器MCU等结构。

本实施例所述的支付平台为方法实施例二所述的信息处理方法提供实现硬件，在判断所述第一账户是否为满足预设自动支付条件的账户时，所述判断单元，具体用于当所述第一账号向所述第二账户支付的支付截止日到期或指定支付日到期时，确定所述第一账户为满足预设自动支付条件的账户；

其中，所述指定支付日为所述第一账户的用户指定的且早于所述支付截止日的支付日。

通过自动支付操作，可以在所述第一账户的用户忘记支付时，由所述支付平台自动支付，从而所述支付平台具有智能性高及用户使用满意度高的优点。

支付平台自动支付的方案有多种，根据自动支付方式不同，所述支付平台的结构不同，以下提供两种可选方案：

方案一：所述支付单元120，具体用于依据所述待支付信息控制所述第一账户向所述第二账户进行N次自动支付操作；

其中，第n次自动支付操作的支付金额为第n金额；

第n+1次自动支付操作在第1次至第n次自动支付操作的支付失败时进行，且第n+1金额小于第n金额；

所述N为不小1的正整数；所述n为小于所述N的正整数；

第1金额不大于所述待支付金额。

方案二：

在图11所示的结构之上，所述支付平台还包括：

第二查询单元，用于当所述第一账户为满足预设自动支付条件的账户时，查询所述第一账户的可用余额；

所述支付单元120，具体用于当所述第一账户有可用余额时，依据待支付金额以及所述可用余额使所述第一账户向所述第二账户进行支付操作，并形成支付结果。

第一种结构为支付平台在不进行第一账户的可用金额的查询，就直接进行自动支付；第二种结构为支付平台上还设有第二查询单元；所述第二查询单元的具体结构可与所述第一查询单元的具体结构类似，在此就不再重复了；在第二种结构中，先查询可支付金额，再根据可支付金额进行自动支付操作。

如图12所示，所述支付平台可包括：

处理器301、外部通信接口301、内部通信结构303及存储介质304。所述内部通信接口303具体可以是PCI总线等总线接口，用于连接处理器301和存储介质303；所述处理器301通过运行存储在存储介质304上的代码可以执行方法实施例中任一项所述的方法。所述外部通信接口301用于与客户端等外设进行信息交互，具体如向客户端发送已支付信息或从客户端接收登录请求等。

此外，为了方便工作人员查看和控制所述支付平台，本实施例中所述支付平台还可包括如图13中所示的显示器305；所述显示器可以是液晶显示器、电子墨水显示器或投影显示器等显示结构。

在一些实施例中，所述支付平台还可以如图2至图6所示，所述支付平台除包括支付服务器外，还可包括支付数据库及支付网关等结构。所述支付数据库用于存储第一账户和第二账户的账号信息和收支信息等信息，所述账号信息包括账号、密码、账号用户的身份认证信息、账号注册时间、账号级别以及安全等级等于账号关联的信息。所述收支信息为基于用户操作或支付平台的自动支付操作等形成的与收入和支出相关的账目信息。所述支付数据库显现是包括存储介质的。所述支付服务器为执行所述查询、支付、更创以及收发信息等操作的设备，具体如各种类型的电脑或服务器。所述网关主要用于进行安全防护等操作。

综合上述，本实施例提供了一种支付平台，为用于上述任意方法实施例中所述的信息处理方法提供了硬件实施结构，具有结构简单、智能性高以及用户使用满意度高的优点。

设备实施例三:

如图11所示，本实施例提供一种支付平台，所述支付平台包括：

第一查询单元110，用于查询待支付信息；

支付单元120，用于依据所述待支付信息控制第一账户向第二账户进行支付操作，并形成支付结果；

生成单元130，用于依据所述支付结果，生成支付反馈信息；所述支付反馈信息为反馈给客户端的信息，通常可包括已支付信息或支付失败信息；

发送单元140，用于向所述第一账户和所述第二账户的客户端发送所述已支付信息；

更新单元150，用于当所述支付结果表明支付成功时，更新所述第一账户和所述第二账户的收支信息；所述第一账户和所述第二账户均可为注册在所述支付平台的操作账户。

所述判断单元还用于判断所述第一账户是否为满足预设自动延期条件的账户；

在本实施例中所述支付平台还包括：

延期单元，用于当所述第一账户没有可用余额时，向所述第二账户发送支付延期请求；

接收单元，用于接收所述第二账户基于所述支付延期请求形成的延期响应；

确定单元，用于依据所述延期响应重新确定支付日。

所述第一查询单元110至发送单元140的具体结构可参见设备实施例一，在此就不再重复了，所述延期单元和确定单元的结构与所述第一查询单元110的结构类似，可以包括各种类型的处理器。所述发送单元的具体结构可包括各种类型的外部通信接口，如有线通信接口或无线通信接口等。

本实施例中所述支付平台，通过延期单元和确定单元的引入，可以自行自动延期的操作，进一步提高了支付平台的智能性和用户使用满意度。

设备实施例四：

如图11所示，本实施例提供一种支付平台，所述支付平台包括：

第一查询单元110，用于查询待支付信息；

支付单元120，用于依据所述待支付信息控制第一账户向第二账户进行支付操作，并形成支付结果；

生成单元130，用于依据所述支付结果，生成支付反馈信息；所述支付反馈信息为反馈给客户端的信息，通常可包括已支付信息或支付失败信息；

发送单元140，用于向所述第一账户和所述第二账户的客户端发送所述已支付信息；

更新单元150，用于当所述支付结果表明支付成功时，更新所述第一账户和所述第二账户的收支信息；所述第一账户和所述第二账户均可为注册在所述支付平台的操作账户。

本实施例是基于上述任意实施例的基础上，所述支付平台还包括接收单元；

所述发送单元140，还用于向第一账户的客户端发送所述待支付信息；

所述接收单元，用于接收所述客户端返回的实际支付金额；

所述支付单元120，还用于控制所述第一账户向所述第二账户支付所述实际支付金额。

所述接收单元可为各种类型的外部通信接口，所述外部通信接口的类型可以参见设备实施例一或设备实施例二，在此就不再详细叙述了。

本实施例所述的支付平台，接收单元和发送单元的设置，根据与客户端之间的交互获取用户操作指示，进而进行支付，提高了用户对支付平台支付的控制性。

设备实施例五：

如图11所示，本实施例提供一种支付平台，所述支付平台包括：

第一查询单元110，用于查询待支付信息；

支付单元120，用于依据所述待支付信息控制第一账户向第二账户进行支付操作，并形成支付结果；

生成单元130，用于依据所述支付结果，生成支付反馈信息；所述支付反馈信息为反馈给客户端的信息，通常可包括已支付信息或支付失败信息；

发送单元140，用于向所述第一账户和所述第二账户的客户端发送所述已支付信息；

更新单元150，用于当所述支付结果表明支付成功时，更新所述第一账户和所述第二账户的收支信息；所述第一账户和所述第二账户均可为注册在所述支付平台的操作账户。

本实施例是基于上述任意实施例的基础上，所述支付平台还包括：

核算单元，用于核算支付结果；

所述支付单元120，还用于当依据所述支付结果确定第一账户向第二账户的支付金额超过待支付金额时，控制所述第二账户向所述第一账户进行返款操作。

所述核算单元可包括计算器或具有计算功能的处理器。

所述核算单元与支付单元以及更新单元等结构相连，或与支付数据库相连。

本实施例中，通过核算单元的引入，所述支付平台可以执行溢款处理功能，再次提高了支付平台的智能性和用户使用满意度。

作为本实施例的进一步改进，所述核算单元，还可用于核算所述第一账户的收支信息和支付结果；所述收支信息包括所述第一账户支付的实际支付日；所述支付结果中包括支付平台或所述第二账户收到支付的收到支付日。

所述支付单元还可包括校正单元；校正单元，用于当所述第一账户的支付信息表明所述实际支付日早于收到支付日时，以所述实际支付日校正支付结果。

所述校正单元的结构同样可为各种类型的处理器。设备实施例六：

如图11所示，本实施例提供一种支付平台，所述支付平台包括：

第一查询单元110，用于查询待支付信息；

支付单元120，用于依据所述待支付信息控制第一账户向第二账户进行支付操作，并形成支付结果；

生成单元130，用于依据所述支付结果，生成支付反馈信息；所述支付反馈信息为反馈给客户端的信息，通常可包括已支付信息或支付失败信息；

发送单元140，用于向所述第一账户和所述第二账户的客户端发送所述已支付信息；

更新单元150，用于当所述支付结果表明支付成功时，更新所述第一账户和所述第二账户的收支信息；所述第一账户和所述第二账户均可为注册在所述支付平台的操作账户。

在上述任意实施例的基础上，所述支付平台还包括接收单元及响应单元：

所述接收单元，用于接收所述第一账户的客户端发送的登录请求；

所述第一查询单元，还用于基于所述登录请求查询所述第一账户的待支付信息；所述待支付信息包括支付日和待支付金额；

所述响应单元，用于响应所述登录请求，允许所述客户端登录并向所述客户端发送包括所述待支付信息的第一登录附加信息或第二登录附件信息；

所述第一登录附加信息，用于控制所述客户端在登录后显示第一界面；所述第二登录附加信息，用于控制所述客户端在登录后显示第二界面；

所述第一界面不同于所述第二界面。

所述接收单元的结构可为各种类型的外部通信接口。

本实施例中所述响应单元为运行所述登录请求的硬件结构，如处理器，还可包括如图2中所示的网关等结构。

本实施例所述的支付平台可以通过控制客户端在登录后显示的界面，达到提醒用户及时支付的作用。

在具体的实现过程中，所述支付平台可以如图3所示，包括支付数据库和支付服务器；所述支付服务器可以为一台或多台；所述支付数据可以为多个，优选为所述支付平台为一个分布式支付系统，这样能够提高与客户端的信息交互速率、降低集中处理导致的处理时延等问题。

在具体实现时，所述支付平台还可以是一个云平台，提供支付服务的服务者通过租用他人的云设备搭建的所述支付平台。

本发明任意实施例中所述的客户端可以是个人电脑、笔记本电脑、平板电脑或智能手机等用户使用的终端设备。

所述发送给客户端的信息，可以是以账号为发送端标识，当客户端打开所述账号时，客户端可能显示对应的信息，这样无论用户用哪个客户端登录对应的账号都会查看到支付平台发送的信息(如已支付信息)；此外，还可以是登记在支付平台中的客户端，如以手机号等通信号登录的客户端。

以下结合上述任意实施例提供几个具体应用示例：

本发明实施例所述的方法可以应用在手机QQ的生活服务号，因此需要客户端的系统中应该安装有手机QQ软件；所述客户端的系统可以是android安卓系统或ios系统的客户端。系统为android系统的客户端如三星的手机、华为或中兴的手机等。所述ios系统的客户端如苹果手机或苹果的平板电脑等。

图13至图14为手机QQ响应用户操作形成的显示页面图；其中，图14为续所述图13的显示页面。

例如用户通过手机QQ登录到支付平台向第二账户进行借款，借款成功后将显示图14中左边的第1页面；在第1页面显示有借款金额、到账时间、借款时间、借款单号、放款银行等与借贷相关的信息。

在图13的第2页面，可为用户下次登录的时显示的页面，该页面为还款页面，在该页面内有需还金额，该需还金额对应为本发明实施例中所述待支付金额，所述第2页面上还西那是有到期还款日，所述到期还款日为本发明实施例中所述的支付日的一种。第2页面中的还款银行对应的所述第二账户。

在图13的第3页面为客户端在接收到用户指示的提权还款时，进入的还款信息确认页面，在该页面由还款金额以及确认还款确定键等信息。

在图14左边第1页面为续接图13中第3页面的第4页面；在第4页面中有支付密码等信息。在第5页面中为了提高还款安全性，还包括短信验证码等输入操作。在第6页面中有交易详情等操作。

图13和图14提供的是基于本发明实施例中，支付平台依据用户操作指示进行支付的信息处理方法在客户端的显示效果流程图。

图15为包括本发明实施例所述支付平台、客户端的支付系统。所述支付系统包括：客户端及支付平台和第三方信贷系统。所述第三方信贷系统可包括银行系统或其他借贷公司系统。所述客户端包括手Q支付SDK(手Q为手机QQ的缩写，所述SDK为软件开发工具包的英文缩写)及手Q UI展示。所述手Q UI为手机QQ的用户界面。所述支付平台包括现金贷还款通用网关界面CGI、现金贷还款服务系统、手Q支付后台、数据存储系统、财付通基础交易系统及代理前置机。

图16为基于上述支付系统的信息处理流程之一：

步骤S1：用户进入服务号后开始还款。所述服务号可如第一账号或第二账号。

步骤S2：现金贷还款系统到数据存储系统中查询用户的借款单信息，如果用户已经还清，则控制客户端进入用户借界面。如果用户借款单处于欠款，未还清，或者逾期状态，则引导用户的客户端进入还款界面。所述借款单信息为所述待支付信息的一种。

步骤S3：现金贷还款CGI到现金贷还款服务系统查询用户需还金额。

步骤S4：现金贷还款服务系统到第三方信道系统查询用户需还金额，具体可包括查询借款信息和还款信息，计算用户需还金额。

步骤S5：在UI显示用户应还金额，并接收用户选择还款金额。

步骤S6：进行还款操作，对还款金额做校验，用户的还款金额不能超出用户的应还金额，避免出现还款溢出的情况发生。

步骤S7：现金贷还款后台调用手Q支付后台，生成唯一的用户还款订单，并将唯一的还款订单识别序列号id返回UI。

步骤S8：UI调用手Q支付SDK进行还款，接收用户选择的还款卡信息、手机验证码和支付密码，手Q支付后台验证信息后，完成交易支付并将结果返回前端。

步骤S9：手Q支付SDK向手Q支付后台，支付还款，

步骤S10：手Q支付后台同时调用现金贷后台CGI，通知UI还款成功或者失败的支付单交易结果。

图17为一种基于用户还款的流程图，所述流程包括：

步骤S21：手Q支付后台向现金贷还款CGI发送用户还款完成的消息。

步骤S22：现金贷还款CGI向现金贷还款服务系统发送用户支付信息。

步骤S23：现金贷还款服务系统向财付通基础交易系统发送查询支付单交易结果。

步骤S24：现金贷还款服务系统向第三方信贷系统发送铜鼓用户还款单信息。

步骤S25：现金贷还款服务系统更新借款单状态，例如是否为还清等。

步骤S26：现金贷还款服务系统通知用户还款结果。

图18为基于本发明实施例所述的支付平台的借款单元状态迁移图。首先用户签约，以表达用户借款意愿，此时借款单处于支付未审核状态。

接着支付平台对借款单进行crf审核，若crf审核通过则借款单的状态变迁为签约成功待借款，若crf返回签约失败，表示借款单签约审核失败。

签约审核失败，则可能将所述借款单视为异常借款单或中止借款单处理，中止借款单的处理流程。

支付平台对状态为签约成功等待贷款的借款单进行放款；放款之后可能生成放款单失败或放款单成功的放款结果。放款单失败显然表示放款失败，放款当成功显然表示放款成功待还款。

放款成功之后，开始对还款日期是否超过还款期进行确定，若借款单的状态为未还款已逾期，基于用户操作指示可进行部分还款或全部还款。当进行部分还款之后，该借款单的状态切换到部分还款已逾期的状态。当全部还清时，当该借款单的状态为已还款，并终止该借款单的处理。

在日期未超过还款期之前，基于用户操作指示，也可以进行部分还款或全部还清的操作。当执行了部分还款之后，接续监控借款的还款期，若为到还款日期，则借款单状态为部分还款未到期，否则部分还款已逾期。

到了还款日，支付平台将执行自动支付操作，执行自动支付的日期为代扣日。在代扣日代扣时可能出现全部代扣成功，则借款单的状态为已还款，并进入终止借款单的处理；还可能出现部分代扣成功，则借款单的状态为部分还款已逾期；还可能出现代扣失败。代扣失败后借款单的状态可能会是未还款逾期(此时可能已还款为0)，若之前有偿还部分，则可能出现借款单的状态为部分还款已逾期。上述代扣日即为本发明实施例中所述支付日。

最后还清余额或全额还款后，则借款单的状态更换为已还款并最终终止借款单的状态迁移和处理。

在具体的实现过程中，所述客户端与所述支付平台之间可以基于Html5进行信息交互。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

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

另外，在本发明各实施例中的各功能单元可以全部集成在一个处理模块中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (24)

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

支付平台查询待支付信息；

依据所述待支付信息控制第一账户向第二账户进行支付操作，并形成支付结果；

依据所述支付结果，生成支付反馈信息；

向所述第一账户和所述第二账户的客户端发送所述支付反馈信息；

当所述支付结果表明支付成功时，更新所述第一账户和所述第二账户的收支信息；

所述第一账户和所述第二账户均为注册在所述支付平台的操作账号。

2.根据权利要求1所述的方法，其特征在于，

所述依据所述待支付信息控制第一账户向第二账户进行支付操作，并形成支付结果，包括：

依据所述待支付信息，判断第一账户是否为满足预设自动支付条件的账户；

当所述第一账户为满足预设自动支付条件的账户时，控制所述第一账户向所述第二账户进行自动支付操作。

3.根据权利要求2所述的方法，其特征在于，

所述依据所述待支付信息，判断第一账户是否为满足预设自动支付条件的账户，包括：

当所述第一账号向所述第二账户支付的支付截止日到期或指定支付日到期时，确定所述第一账户为满足预设自动支付条件的账户；

其中，所述指定支付日为所述第一账户的用户指定的且早于所述支付截止日的支付日。

4.根据权利要求2所述的方法，其特征在于，

所述待支付信息包括待支付金额；

所述控制第一账户向所述第二账户进行自动支付操作，包括：

依据所述待支付信息控制所述第一账户向所述第二账户进行N次自动支付操作；

其中，第n次自动支付操作的支付金额为第n金额；

第n+1次自动支付操作在第1次至第n次自动支付操作的支付失败时进行，且第n+1金额小于第n金额；

所述N为不小1的正整数；所述n为小于所述N的正整数；

第1金额不大于所述待支付金额。

5.根据权利要求2所述的方法，其特征在于，

所述控制第一账户向所述第二账户进行自动支付操作，

包括：

查询所述第一账户的可用余额；

当所述第一账户有可用余额时，依据待支付金额以及所述可用余额使所述第一账户向所述第二账户进行支付操作，并形成支付结果。

6.根据权利要求4所述的方法，其特征在于，

所述当所述第一账户有可用余额时，依据待支付金额以及所述可用余额使所述第一账户向所述第二账户进行支付，并形成支付结果，包括：

当所述第一账户的可用余额不小于所述待支付金额时，控制所述第一账户向所述第二账户进行全额支付。

7.根据权利要求5所述的方法，其特征在于，

所述当所述第一账户有可用余额时，依据待支付金额以及所述可用余额使所述第一账户向所述第二账户进行支付，并形成支付结果，包括：

当所述第一账户的可用余额小于所述待支付金额时，控制所述第一账户向所述第二账户进行部分支付。

8.根据权利要求2所述的方法，其特征在于，

所述方法还包括：

判断所述第一账户是否为满足预设自动延期条件的账户；

当所述第一账户为满足所述预设自动延期条件的账户时，向所述第二账户的客户端发送支付延期请求；

接收所述第二账户的客户端基于所述支付延期请求形成的延期响应；

依据所述延期响应重新确定支付日。

9.根据权利要求1所述的方法，其特征在于，

所述待支付信息包括第一账户需向所述第二账户支付的待支付金额；

所述依据所述待支付信息控制第一账户向第二账户进行支付操作，并形成支付结果，包括：

向第一账户的客户端发送所述待支付信息；

接收所述第一账户的客户端返回的实际支付金额；

控制所述第一账户向所述第二账户支付所述实际支付金额。

10.根据权利要求1、2或9所述的方法，其特征在于，

所述方法还包括：

核算支付结果；

当依据所述支付结果确定第一账户向第二账户的支付金额超过待支付金额时，控制所述第二账户向所述第一账户进行返款操作。

11.根据权利要求1、2或9所述的方法，其特征在于，

所述方法还包括：

接收所述第一账户的客户端发送的登录请求；

基于所述登录请求查询所述第一账户的待支付信息；所述待支付信息包括支付日和待支付金额；

响应所述登录请求，允许所述客户端登录并向所述客户端发送包括所述待支付信息的第一登录附加信息或第二登录附件信息；

所述第一登录附加信息，用于控制所述客户端在登录后显示第一界面；所述第二登录附加信息，用于控制所述客户端在登录后显示第二界面；

所述第一界面不同于所述第二界面。

12.根据权利要求1、2或9所述的方法，其特征在于，

所述方法还包括：

核算所述第一账户的收支信息和支付结果；所述收支信息包括所述第一账户支付的实际支付日；所述支付结果中包括支付平台或所述第二账户收到支付的收到支付日；

当所述第一账户的支付信息表明所述实际支付日早于收到支付日时，以所述实际支付日校正支付结果。

13.一种支付平台，其特征在于，所述支付平台包括：

第一查询单元，用于查询待支付信息；

支付单元，用于依据所述待支付信息控制第一账户向第二账户进行支付操作，并形成支付结果；

生成单元，用于依据所述支付结果，生成支付反馈信息；

发送单元，用于向所述第一账户和所述第二账户的客户端发送所述支付反馈信息；

更新单元，用于当所述支付结果表明支付成功时，更新所述第一账户和所述第二账户的收支信息；

所述第一账户和所述第二账户均为注册在所述支付平台的操作账号。

14.根据权利要求13所述的支付平台，其特征在于，所述支付平台还包括：

判断单元，用于依据所述待支付信息，判断第一账户是否为满足预设自动支付条件的账户；

所述支付单元，用于当所述第一账户为满足预设自动支付条件的账户时，控制所述第一账户向所述第二账户进行自动支付操作。

15.根据权利要求14所述的支付平台，其特征在于，

所述判断单元，用于当所述第一账号向所述第二账户支付的支付截止日到期或指定支付日到期时，确定所述第一账户为满足预设自动支付条件的账户；

其中，所述指定支付日为所述第一账户的用户指定的且早于所述支付截止日的支付日。

16.根据权利要求14所述的支付平台，其特征在于，

所述待支付信息包括待支付金额；

所述支付单元，具体用于依据所述待支付信息控制所述第一账户向所述第二账户进行N次自动支付操作；

其中，第n次自动支付操作的支付金额为第n金额；

第n+1次自动支付操作在第1次至第n次自动支付操作的支付失败时进行，且第n+1金额小于第n金额；

所述N为不小1的正整数；所述n为小于所述N的正整数；

第1金额不大于所述待支付金额。

17.根据权利要求14所述的支付平台，其特征在于，

所述支付平台还包括：

第二查询单元，用于当所述第一账户为满足预设自动支付条件的账户时，查询所述第一账户的可用余额；

所述支付单元，具体用于当所述第一账户有可用余额时，依据待支付金额以及所述可用余额使所述第一账户向所述第二账户进行支付操作，并形成支付结果。

18.根据权利要求17所述的支付平台，其特征在于，

所述支付单元，具体用于当所述第一账户的可用余额不小于所述待支付金额时，控制所述第一账户向所述第二账户进行全额支付。

19.根据权利要求17所述的支付平台，其特征在于，

所述支付平台，具体用于当所述第一账户的可用余额小于所述待支付金额时，控制所述第一账户向所述第二账户进行部分支付。

20.根据权利要求14所述的支付平台，其特征在于，

所述判断单元还用于判断所述第一账户是否为满足预设自动延期条件的账户；

所述支付平台还包括：

延期单元，用于当所述第一账户为满足所述预设自动延期条件的账户时，向所述第二账户的客户端发送支付延期请求；

接收单元，用于接收所述第二账户的客户端基于所述支付延期请求形成的延期响应；

确定单元，用于依据所述延期响应重新确定支付日。

21.根据权利要求13所述的支付平台，其特征在于，所述支付平台还包括接收单元；

所述发送单元，还用于向第一账户的客户端发送所述待支付信息；

所述接收单元，用于接收所述第一账户的客户端返回的实际支付金额；

所述支付单元，还用于控制所述第一账户向所述第二账户支付所述实际支付金额。

22.根据权利要求13、14或21所述的支付平台，其特征在于，

所述支付平台还包括：

核算单元，用于核算支付结果；

所述支付单元，还用于当依据所述支付结果确定第一账户向第二账户的支付金额超过待支付金额时，控制所述第二账户向所述第一账户进行返款操作。

23.根据权利要求13、14或21所述的支付平台，其特征在于，

所述支付平台还包括接收单元及响应单元：

所述接收单元，用于接收所述第一账户的客户端发送的登录请求；

所述第一查询单元，还用于基于所述登录请求查询所述第一账户的待支付信息；所述待支付信息包括支付日和待支付金额；

所述响应单元，用于响应所述登录请求，允许所述客户端登录并向所述客户端发送包括所述待支付信息的第一登录附加信息或第二登录附件信息；

所述第一登录附加信息，用于控制所述客户端在登录后显示第一界面；所述第二登录附加信息，用于控制所述客户端在登录后显示第二界面；

所述第一界面不同于所述第二界面。

24.根据权利要求13、14或21所述的支付平台，其特征在于，

所述支付平台还包括：

核算单元，用于核算所述第一账户的收支信息和支付结果；所述收支信息包括所述第一账户支付的实际支付日；所述支付结果中包括支付平台或所述第二账户收到支付的收到支付日；

校正单元，用于当所述第一账户的支付信息表明所述实际支付日早于收到支付日时，以所述实际支付日校正支付结果。