一种24小时提现方法和系统与流程

本发明涉及数据处理领域，特别涉及一种24小时提现方法和系统。

背景技术：

随着互联网电子商务的飞速发展，用户在提现方面的需要越来越大，对提现过程中实时性和效率的要求也越来越高。为了满足用户的交易需求，中国人民银行提供了大额支付系统，利用现代计算机技术和通信网络快速处理同城和异地跨行之间、行内的大额贷记、紧急小额贷记以及其他支付业务，从而给各银行和广大企业单位以及金融市场提供快速、高效、安全、可靠的支付服务。但是大额支付系统每天17点之后会关闭，即客户在营业日当日下午17：00前办理的大额支付业务都可实现实时到达收款行，当大额系统关闭后，无法通过大额系统进行正常转账，影响了资金的提现速度和处理效率。

技术实现要素：

本发明旨在至少解决上述技术问题之一。

为此，本发明的一个目的在于提出一种24小时提现方法,可以通过预设支付系统进行提现，不再受制于大额系统运行时间的限制，有效的提高了资金的提现速度和处理效率。

本发明的另一个目的在于提供一种24小时提现系统。

为了实现上述目的，本发明的一个实施例提出了一种24小时提现方法，包括以下步骤：

s1，应用服务器接收用户的提现请求，并记录所述提现请求的接收时间；

s2，应用服务器判断所述接收时间是否处于预设时间范围，若是，则通过预设方法进行提现；若否，则执行步骤s3；

s3，应用服务器暂停接收用户的提现请求，并根据在预设支付系统中开设支付中心账号的各个银行当日的未提现金额和已提现金额计算对应的账户准备金额度，并根据所述账户准备金额度生成各个银行对应的资金转账请求，以使每个银行支付中心账号的余额均达到对应的账户准备金额度，然后继续接收用户的提现请求，并通过所述预设方法进行提现。

根据本发明实施例的24小时提现方法，用户不仅可以选择预设支付系统中合适的银行账户进行转账，节约了跨行转账的手续费，也提高了转账速度和效率，而且在大额系统关闭后，仍旧可以通过预设支付系统进行提现，不再受制于大额系统运行时间的限制，有效的提高了资金的提现速度和处理效率。

另外，根据本发明上述实施例的一种24小时提现方法还可以具有如下附加的技术特征：

在一些示例中，所述预设时间范围为9：00～a1，a1的取值范围为16:00～16:30。

在一些示例中，步骤s3中，应用服务器生成资金转账请求包括以下步骤：

s301，查询应用服务器的数据库，获取在预设支付系统中开设支付中心账号的每个银行当日未处理的所有提现请求、已处理的所有提现请求、每个提现请求对应的提现金额以及每个银行的历史日平均提现额；

s302，计算每个银行当日未处理的提现金额总和以及当日已处理的提现金额总和；

s303，根据当日未处理的提现金额总和、当日已处理的提现金额总和以及每个银行的历史日平均提现额，计算每个银行的账户准备金额度；

s304，获取每个银行支付中心账号的余额，并根据每个银行的账户准备金额度生成每个银行对应的资金转账请求，所述资金转账请求包括转账金额和目标交易银行；

s305，通过银行api服务器和目标交易银行对应的请求转发服务器将所述资金转账请求发送至目标交易银行的银企前置机，以使每个银行支付中心账号的余额均达到对应的账户准备金额度。

在一些示例中，通过预设方法进行提现包括以下步骤：

s401，应用服务器获取在预先建立的支付系统中开设支付中心账号的所有银行名单；

s402，应用服务器对所述提现请求进行解析，生成提现金额和提现请求对应的第一目标银行；

s403，应用服务器判断第一目标银行是否在所述银行名单上，若是，则获取第一目标银行对应支付中心账号的第一余额，以及银行名单上其他银行对应支付中心账号的第二余额；若否，则结束提现流程；

s404,应用服务器判断所述第一余额是否大于或等于所述提现金额，若是，则向所述支付系统发送第一冻结指令，并生成提现指令发送到银行api服务器，所述第一冻结指令用于冻结第一目标银行对应支付中心账号中的所述提现金额；若否，则获取银行名单上第二余额大于或者等于所述提现金额的第二目标银行，向所述支付系统发送第二冻结指令，并生成提现指令发送到银行api服务器，所述第二冻结指令用于冻结第二目标银行对应支付中心账号中的所述提现金额；

s405，银行api服务器接收所述提现指令，并经与第一目标银行或者第二目标银行对应的请求转发服务器将所述提现指令发送给所述第一目标银行或者第二目标银行，同时定时查询所述第一目标银行或者第二目标银行返回的提现结果，且将所述提现结果发送给所述应用服务器；

s406，应用服务器接收所述提现结果，并根据提现结果向所述支付系统发送用于解除提现金额冻结状态的解冻指令或用于将所述提现金额从第一余额或者第二余额中扣除的扣除指令。

在一些示例中，所述步骤s405包括提现指令发送步骤和提现结果获取步骤，所述提现指令发送步骤具体为：

s500，所述银行api服务器接收所述提现指令，并将所述提现指令记录到银行api服务器的数据库；

s501，所述银行api服务器对数据库进行查询，获取未处理的所有提现请求，并将所有提现请求按照第一目标银行或者第二目标银行封装为对应的第一提现报文；

s502，所述银行api服务器获取所述第一目标银行或者所述第二目标银行对应的配置文件，根据所述配置文件定时将所述第一提现报文转发至第一目标银行或者第二目标银行对应的请求转发服务器；

s503，所述请求转发服务器接收所述第一提现报文，并对所述第一提现报文进行数据封装后生成第二提现报文，然后将所述第二提现报文通过tomcat发送至第一目标银行或者第二目标银行的银企前置机；

s504，所述请求转发服务器获取对应的第一目标银行或者第二目标银行返回的业务流水号或者业务参考号，并将所述业务流水号或者所述业务参考号发送至银行api服务器；

s505，所述银行api服务器记录所述业务流水号或者所述业务参考号；

所述提现结果获取步骤具体为：

s510，所述银行api服务器对数据库进行查询，获取处理中的所有提现请求以及所述提现请求对应的业务流水号或者业务参考号；

s511，所述银行api服务器根据所述业务流水号或者所述业务参考号将所述提现请求按照第一目标银行或者第二目标银行封装为对应的第一查询报文；

s512，所述银行api服务器根据所述配置文件定时将所述第一查询报文转发至所述第一目标银行或者第二目标银行对应的请求转发服务器；

s513，所述请求转发服务器接收所述第一查询报文，并对所述第一查询报文进行数据封装后生成第二查询报文，然后将所述第二查询报文通过tomcat发送至对应第一目标银行或者第二目标银行的银企前置机；

s514，所述请求转发服务器获取对应第一目标银行或者对应第二目标银行返回的提现结果，并将所述提现结果发送至银行api服务器；

s515，所述银行api服务器接收提现结果并将所述提现结果发送至应用服务器。

在一些示例中，所述步骤515中，提现结果包括提现状态，所述提现状态包括提现成功状态和提现失败状态，当提现状态为提现失败状态时，所述提现结果还包括失败原因；所述银行api服务器接收所述提现结果后，当提现状态为提现成功状态时，将数据库中对应提现请求标记为成功，当提现状态为提现失败状态时，将数据库中对应提现请求标记为失败，并写入所述失败原因。

在一些示例中，步骤s404中，所述银行api服务器包括主银行api服务器和备用银行api服务器，应用服务器发送提现指令前，先获取所述主银行api服务器的状态，判断所述主银行api服务器是否失效，若是，则将所述提现指令发送至备用银行api服务器；若否，则将所述提现指令发送至主银行api服务器。

本发明第二方面的实施例还提出了一种24小时提现系统，包括至少一个应用服务器，所述应用服务器包括第一接收模块、判断模块、提现模块和转账请求生成模块，

所述第一接收模块用于接收用户的提现请求，并记录所述提现请求的接收时间；

所述判断模块用于判断所述接收时间是否处于预设时间范围，若是，则驱动提现模块采用预设方法进行提现；若否，则驱动转账请求生成模块；

所述转账请求生成模块用于暂停接收用户的提现请求，并根据在预设支付系统中开设支付中心账号的各个银行当日的未提现金额和已提现金额计算对应的账户准备金额度，并根据所述账户准备金额度生成各个银行对应的资金转账请求，以使每个银行支付中心账号的余额均达到对应的账户准备金额度，然后继续接收用户的提现请求，并通过所述预设方法进行提现。

根据本发明实施例的24小时提现系统，用户不仅可以选择预设支付系统中合适的银行账户进行转账，节约了跨行转账的手续费，也提高了转账速度和效率，而且在大额系统关闭后，仍旧可以通过预设支付系统进行提现，不再受制于大额系统运行时间的限制，有效的提高了资金的提现速度和处理效率。

另外，根据本发明上述实施例的24小时提现系统还可以具有如下附加的技术特征：

在一些示例中，所述转账请求生成模块包括：

查询单元，用于查询应用服务器的数据库，获取在预设支付系统中开设支付中心账号的每个银行当日未处理的所有提现请求、已处理的所有提现请求、每个提现请求对应的提现金额以及每个银行的历史日平均提现额；

第一计算单元，用于计算每个银行当日未处理的提现金额总和以及当日已处理的提现金额总和；

第二计算单元，用于根据当日未处理的提现金额总和、当日已处理的提现金额总和以及每个银行的历史日平均提现额，计算每个银行的账户准备金额度；

转账请求生成单元，用于获取每个银行支付中心账号的余额，并根据每个银行的账户准备金额度生成每个银行对应的资金转账请求，所述资金转账请求包括转账金额和目标交易银行；

转账请求发送单元，用于通过银行api服务器和目标交易银行对应的请求转发服务器将所述资金转账请求发送至目标交易银行的银企前置机，以使每个银行支付中心账号的余额均达到对应的账户准备金额度。

在一些示例中，所述提现模块包括：

获取单元，用于获取在预先建立的支付系统中开设支付中心账号的所有银行名单；

解析单元，用于对所述提现请求进行解析，生成提现金额和提现请求对应的第一目标银行；

第一判断单元，用于判断第一目标银行是否在所述银行名单上，若是，则获取第一目标银行对应支付中心账号的第一余额，以及银行名单上其他银行对应支付中心账号的第二余额；若否，则结束提现流程；

第二判断单元，用于判断所述第一余额是否大于或等于所述提现金额，若是，则向所述支付系统发送第一冻结指令，并生成提现指令发送到银行api服务器，并经第一目标银行对应的请求转发服务器将所述提现指令发送给所述第一目标银行，若否，则获取银行名单上第二余额大于或者等于所述提现金额的第二目标银行，向所述支付系统发送第二冻结指令，并生成提现指令发送到银行api服务器，并经第二目标银行对应的请求转发服务器将所述提现指令发送给所述第二目标银行；所述第一冻结指令用于冻结第一目标银行对应支付中心账号中的所述提现金额；所述第二冻结指令用于冻结第二目标银行对应支付中心账号中的所述提现金额；

结果查询单元，用于定时查询所述银行api服务器返回的提现结果，并根据提现结果向所述支付系统发送用于解除提现金额冻结状态的解冻指令或用于将所述提现金额从第一余额或者第二余额中扣除的扣除指令。

本发明的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解，其中：

图1为实施例1提供的一种24小时提现方法的流程示意图；

图2为实施例2提供的24小时提现方法中步骤s3的流程示意图；

图3为实施例3提供的24小时提现方法中通过预设方法进行提现的流程示意图；

图4为实施例4提供的24小时提现方法步骤s405中提现指令发送步骤的流程示意图；

图5为实施例5提供的24小时提现方法步骤s405中提现结果获取步骤的流程示意图；

图6为实施例6提供的一种24小时提现系统的结构示意图；

图7为实施例7提供的一种24小时提现系统的结构示意图。

具体实施方式

在本发明的描述中，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性。

参照下面的描述和附图，将清楚本发明的实施例的这些和其他方面。在这些描述和附图中，具体公开了本发明的实施例中的一些特定实施方式，来表示实施本发明的实施例的原理的一些方式，但是应当理解，本发明的实施例的范围不受此限制。相反，本发明的实施例包括落入所附加权利要求书的精神和内涵范围内的所有变化、修改和等同物。

以下结合附图描述根据本发明实施例的24小时提现方法和系统。

图1为实施例1一种24小时提现方法的流程示意图，如图1所示，包括以下步骤：

s1，应用服务器接收用户的提现请求，并记录所述提现请求的接收时间；

s2，应用服务器判断所述接收时间是否处于预设时间范围，若是，则通过预设方法进行提现；若否，则执行步骤s3；

s3，应用服务器暂停接收用户的提现请求，并根据在预设支付系统中开设支付中心账号的各个银行当日的未提现金额和已提现金额计算对应的账户准备金额度，并根据所述账户准备金额度生成各个银行对应的资金转账请求，以使每个银行支付中心账号的余额均达到对应的账户准备金额度，然后继续接收用户的提现请求，并通过所述预设方法进行提现。

根据本实施例的方法，用户不仅可以选择预设支付系统中合适的银行账户进行转账，节约了跨行转账的手续费，也提高了转账速度和效率，而且在大额系统关闭后，仍旧可以通过预设支付系统进行提现，不再受制于大额系统运行时间的限制，有效的提高了资金的提现速度和处理效率。

在具体实施例中，可以根据大额支付系统的营业时间设定预设时间范围，比如当大额支付系统的运行时间为9:00～17:00时，所述预设时间范围可以设置为9:00～16:00，或者9:00～16:30等等，即在大额支付系统关闭前，进行步骤s3，使每个银行支付中心账号的余额均达到对应的账户准备金额度，从而在大额支付系统关闭后，也可以处理对应的转账、提现业务。

图2为实施例2的24小时提现方法中步骤s3的流程示意图，如图2所示，步骤s3中，应用服务器生成资金转账请求包括以下步骤：

s301，查询应用服务器的数据库，获取在预设支付系统中开设支付中心账号的每个银行当日未处理的所有提现请求、已处理的所有提现请求、每个提现请求对应的提现金额以及每个银行的历史日平均提现额；

s302，计算每个银行当日未处理的提现金额总和以及当日已处理的提现金额总和；

s303，根据当日未处理的提现金额总和、当日已处理的提现金额总和以及每个银行的历史日平均提现额，计算每个银行的账户准备金额度；

s304，获取每个银行支付中心账号的余额，并根据每个银行的账户准备金额度生成每个银行对应的资金转账请求，所述资金转账请求包括转账金额和目标交易银行；

s305，通过银行api服务器和目标交易银行对应的请求转发服务器将所述资金转账请求发送至目标交易银行的银企前置机，以使每个银行支付中心账号的余额均达到对应的账户准备金额度。

在该优选实施例中，根据当日未处理的提现金额总和、当日已处理的提现金额总和以及每个银行的历史日平均提现额，计算每个银行的账户准备金额度，所述历史日平均提现额可以为预设时间范围内的日平均提现额，通过历史日平均提现额估计用户当日还可能发生的提现请求，从而保证大额系统关闭后，预设支付系统中各个银行支付中心账号的余额也可以满足预计的提现需求，从而提高了资金的提现速度和处理效率。

图3为实施例3的24小时提现方法中通过预设方法进行提现的流程示意图，如图3所示，包括以下步骤：

s401，应用服务器获取在预先建立的支付系统中开设支付中心账号的所有银行名单；

s402，应用服务器对所述提现请求进行解析，生成提现金额和提现请求对应的第一目标银行；

s403，应用服务器判断第一目标银行是否在所述银行名单上，若是，则获取第一目标银行对应支付中心账号的第一余额，以及银行名单上其他银行对应支付中心账号的第二余额；若否，则结束提现流程；

s404,应用服务器判断所述第一余额是否大于或等于所述提现金额，若是，则向所述支付系统发送第一冻结指令，并生成提现指令发送到银行api服务器，所述第一冻结指令用于冻结第一目标银行对应支付中心账号中的所述提现金额；若否，则获取银行名单上第二余额大于或者等于所述提现金额的第二目标银行，向所述支付系统发送第二冻结指令，并生成提现指令发送到银行api服务器，所述第二冻结指令用于冻结第二目标银行对应支付中心账号中的所述提现金额；

s405，银行api服务器接收所述提现指令，并经与第一目标银行或者第二目标银行对应的请求转发服务器将所述提现指令发送给所述第一目标银行或者第二目标银行，同时定时查询所述第一目标银行或者第二目标银行返回的提现结果，且将所述提现结果发送给所述应用服务器；

s406，应用服务器接收所述提现结果，并根据提现结果向所述支付系统发送用于解除提现金额冻结状态的解冻指令或用于将所述提现金额从第一余额或者第二余额中扣除的扣除指令。

本实施例中,银行api服务器是一个外部服务器调用的接口服务器，负责接收来自于应用服务器的请求，提供统一的银行业务如支付转账、支付结果查询，背书转让、票据签收、操作结果查询等操作接口，并将请求结果返回给请求客户端。请求转发服务器主要处理单个银行请求业务的服务器，用于连接银行前置机、接受银行api服务器的业务请求，并根据各个银行的报文要求，将请求内容封装成对应的报文，并发送报文到银行前置机。之后，接收前置机返回的报文并解析该报文，将解析的结果返回给银行api服务器。一般各家银行均有自己的前置机环境，为了适应不通的前置机环境，设置了针对不通前置机环境的请求转发服务器。本实施例的基于银行api服务器的提现方法，不同银行对应一个不同的请求转发服务器，通过银行api服务器和请求转发服务器发送提现指令至对应的第一目标银行或者第二目标银行，在账户余额不足需要跨行转账时也可以实现快速提现，确保了用户提现的效率和实时性，另外，该方法实现简单，投入成本低。在另一实施例中，在银行api服务器和请求转发服务器之间增加消息服务器，应用服务器首先将所述提现指令发送到消息服务器进行存储，所述银行api服务器对消息服务器的提现指令进行监听，当监听到消息服务器中存储有提前指令时，获取所述提现指令，并进行以上后续步骤。

图4为实施例4的24小时提现方法的步骤s405中提现指令发送步骤的流程示意图，如图4所示，包括以下步骤：

s500，所述银行api服务器接收所述提现指令，并将所述提现指令记录到银行api服务器的数据库；

s501，所述银行api服务器对数据库进行查询，获取未处理的所有提现请求，并将所有提现请求按照第一目标银行或者第二目标银行封装为对应的第一提现报文；

s502，所述银行api服务器获取所述第一目标银行或者所述第二目标银行对应的配置文件，根据所述配置文件定时将所述第一提现报文转发至第一目标银行或者第二目标银行对应的请求转发服务器；

s503，所述请求转发服务器接收所述第一提现报文，并对所述第一提现报文进行数据封装后生成第二提现报文，然后将所述第二提现报文通过tomcat发送至第一目标银行或者第二目标银行的银企前置机；

s504，所述请求转发服务器获取对应的第一目标银行或者第二目标银行返回的业务流水号或者业务参考号，并将所述业务流水号或者所述业务参考号发送至银行api服务器；

s505，所述银行api服务器记录所述业务流水号或者所述业务参考号。

上述优选实施例中，不同银行在银行api服务器中预设了对应的配置文件，配置文件记载了第一提现报文的发送时间，因此可以定时将银行api服务器的数据库中没有处理的提现请求批量进行处理，提高了提现请求的处理效率，从而提高了提现速度；同时请求转发服务器采用了tomcat，不仅配置过程简单而且可以处理大量用户请求，进一步提高了提现请求的处理速度和效率。

图5为实施例5的24小时提现方法的步骤s405中提现结果获取步骤的流程示意图，如图5所示，包括以下步骤：

s510，所述银行api服务器对数据库进行查询，获取处理中的所有提现请求以及所述提现请求对应的业务流水号或者业务参考号；

s511，所述银行api服务器根据所述业务流水号或者所述业务参考号将所述提现请求按照第一目标银行或者第二目标银行封装为对应的第一查询报文；

s512，所述银行api服务器根据所述配置文件定时将所述第一查询报文转发至所述第一目标银行或者第二目标银行对应的请求转发服务器；

s513，所述请求转发服务器接收所述第一查询报文，并对所述第一查询报文进行数据封装后生成第二查询报文，然后将所述第二查询报文通过tomcat发送至对应第一目标银行或者第二目标银行的银企前置机；

s514，所述请求转发服务器获取对应第一目标银行或者对应第二目标银行返回的提现结果，并将所述提现结果发送至银行api服务器；

s515，所述银行api服务器接收提现结果并将所述提现结果发送至应用服务器。

上述优选实施例中，通过查询配置文件可以获取不同银行对应的第一查询报文的发送时间，因此可以定时获取第一目标银行或者第二目标银行返回的提现结果，获取方法简单且效率高，进一步提高了提现请求的处理速度和效率。

在另一优选的实施例中，所述步骤515中，提现结果包括提现状态，所述提现状态包括提现成功状态和提现失败状态，当提现状态为提现失败状态时，所述提现结果还包括失败原因；所述银行api服务器接收所述提现结果后，当提现状态为提现成功状态时，将数据库中对应提现请求标记为成功，当提现状态为提现失败状态时，将数据库中对应提现请求标记为失败，并写入所述失败原因。通过以上方法可以及时获取提现请求的状态，当提现请求为失败状态时，也可以及时获取失败原因，从而对后续步骤进行改进。

在另一优选实施例的步骤s404中，所述银行api服务器包括主银行api服务器和备用银行api服务器，应用服务器发送提现指令前，先获取所述主银行api服务器的状态，判断所述主银行api服务器是否失效，若是，则将所述提现指令发送至备用银行api服务器；若否，则将所述提现指令发送至主银行api服务器。上述优选实施例设置了两个银行api服务器，在其中一个银行api服务器处于失效状态时，另一个银行api服务器还可以继续使用，提高了提现成功率。当然在其他的实施例中也可以根据两个或者多个银行api服务器的负载情况，选择负载较小的的银行api服务器进行使用，从而防止银行api服务器发送崩溃或失效，进一步提高了提现成功率和提现速度。

图6为实施例6提供的一种24小时提现系统的结构示意图，如图6所示，包括至少一个应用服务器，所述应用服务器包括第一接收模块、判断模块、提现模块和转账请求生成模块，

所述第一接收模块用于接收用户的提现请求，并记录所述提现请求的接收时间；

所述判断模块用于判断所述接收时间是否处于预设时间范围，若是，则驱动提现模块采用预设方法进行提现；若否，则驱动转账请求生成模块；

所述转账请求生成模块用于暂停接收用户的提现请求，并根据在预设支付系统中开设支付中心账号的各个银行当日的未提现金额和已提现金额计算对应的账户准备金额度，并根据所述账户准备金额度生成各个银行对应的资金转账请求，以使每个银行支付中心账号的余额均达到对应的账户准备金额度，然后继续接收用户的提现请求，并通过所述预设方法进行提现。

根据本实施例的24小时提现系统，用户不仅可以选择预设支付系统中合适的银行账户进行转账，节约了跨行转账的手续费，也提高了转账速度和效率，而且在大额系统关闭后，仍旧可以通过预设支付系统进行提现，不再受制于大额系统运行时间的限制，有效的提高了资金的提现速度和处理效率。

在一优选实施例中，所述转账请求生成模块包括：

查询单元，用于查询应用服务器的数据库，获取在预设支付系统中开设支付中心账号的每个银行当日未处理的所有提现请求、已处理的所有提现请求、每个提现请求对应的提现金额以及每个银行的历史日平均提现额；

第一计算单元，用于计算每个银行当日未处理的提现金额总和以及当日已处理的提现金额总和；

第二计算单元，用于根据当日未处理的提现金额总和、当日已处理的提现金额总和以及每个银行的历史日平均提现额，计算每个银行的账户准备金额度；

转账请求生成单元，用于获取每个银行支付中心账号的余额，并根据每个银行的账户准备金额度生成每个银行对应的资金转账请求，所述资金转账请求包括转账金额和目标交易银行；

转账请求发送单元，用于通过银行api服务器和目标交易银行对应的请求转发服务器将所述资金转账请求发送至目标交易银行的银企前置机，以使每个银行支付中心账号的余额均达到对应的账户准备金额度。

在另一实施例中，所述提现模块包括：

获取单元，用于获取在预先建立的支付系统中开设支付中心账号的所有银行名单；

解析单元，用于对所述提现请求进行解析，生成提现金额和提现请求对应的第一目标银行；

第一判断单元，用于判断第一目标银行是否在所述银行名单上，若是，则获取第一目标银行对应支付中心账号的第一余额，以及银行名单上其他银行对应支付中心账号的第二余额；若否，则结束提现流程；

第二判断单元，用于判断所述第一余额是否大于或等于所述提现金额，若是，则向所述支付系统发送第一冻结指令，并生成提现指令发送到银行api服务器，并经第一目标银行对应的请求转发服务器将所述提现指令发送给所述第一目标银行，若否，则获取银行名单上第二余额大于或者等于所述提现金额的第二目标银行，向所述支付系统发送第二冻结指令，并生成提现指令发送到银行api服务器，并经第二目标银行对应的请求转发服务器将所述提现指令发送给所述第二目标银行；所述第一冻结指令用于冻结第一目标银行对应支付中心账号中的所述提现金额；所述第二冻结指令用于冻结第二目标银行对应支付中心账号中的所述提现金额；

结果查询单元，用于定时查询所述银行api服务器返回的提现结果，并根据提现结果向所述支付系统发送用于解除提现金额冻结状态的解冻指令或用于将所述提现金额从第一余额或者第二余额中扣除的扣除指令。

图7为实施例7提供的一种24小时提现系统的结构示意图，如图7所示，还包括至少一个银行api服务器和至少一个请求转发服务器，

所述至少一个银行api服务器用于接收所述提现指令，并将所述提现指令发送至与第一目标银行或者第二目标银行对应的请求转发服务器；以及用于接收所述请求转发服务器发送的提现结果，并将所述提现结果发送至应用服务器；以及用于接收所述资金转账请求，并将所述资金转账请求发送至与目标交易银行对应的请求转发服务器；以及用于接收所述请求转发服务器发送的转账结果，并将所述转账结果发送至应用服务器；

所述至少一个请求转发服务器用于将所述提现指令发送给对应的所述第一目标银行或者第二目标银行，同时定时查询所述第一目标银行或者第二目标银行返回的提现结果，且将所述提现结果发送给银行api服务器；以及将所述资金转账请求发送给对应的目标交易银行，同时定时查询所述目标交易银行返回的提现结果，且将所述提现结果发送给银行api服务器。

在具体实施例中，所述至少一个银行api服务器包括：

第二接收模块，用于接收所述提现指令，并将所述提现指令记录到银行api服务器的数据库；

第一查询模块，用于对数据库进行查询，获取未处理的所有提现请求；

第一封装模块，用于将所有提现请求按照第一目标银行或者第二目标银行封装为对应的第一提现报文；

第一发送模块，用于获取所述第一目标银行或者所述第二目标银行对应的配置文件，根据所述配置文件定时将所述第一提现报文转发至所述第一目标银行或者第二目标银行对应的请求转发服务器；

记录模块，用于记录业务流水号或者所述业务参考号；

第二查询模块，用于对数据库进行查询，获取处理中的所有提现请求以及所述提现请求对应的业务流水号或者业务参考号；

第二封装模块，用于根据所述业务流水号或者所述业务参考号将所述提现请求按照第一目标银行或者第二目标银行封装为对应的第一查询报文；

第二发送模块，用于根据所述配置文件定时将所述第一查询报文转发至所述第一目标银行或者第二目标银行对应的请求转发服务器；

转发模块，用于接收提现结果并将所述提现结果发送至应用服务器。

该优选实施例中，每个请求转发服务器对应一个目标银行的银企前置机，每个所述请求转发服务器均包括：

第一收发模块，用于接收所述第一提现报文，并对所述第一提现报文进行数据封装后生成第二提现报文，然后将所述第二提现报文通过tomcat发送至对应的第一目标银行或者第二目标银行的银企前置机；

第二收发模块，用于获取第一目标银行或者第二目标银行返回的业务流水号或者业务参考号，并将所述业务流水号或者所述业务参考号发送至银行api服务器；

第三收发模块，用于接收所述第一查询报文，并对所述第一查询报文进行数据封装后生成第二查询报文，然后将所述第二查询报文通过tomcat发送至对应第一目标银行或者第二目标银行的银企前置机；

第四收发模块，用于获取对应的第一目标银行或者第二目标银行返回的提现结果，并将所述提现结果发送至银行api服务器。

在另一优选实施例中，所述银行api服务器包括主银行api服务器和备用银行api服务器，所述第二判断模块还用于发送提现指令前，先获取所述主银行api服务器的状态，判断所述主银行api服务器是否失效，若是，则将所述提现指令发送至备用银行api服务器；若否，则将所述提现指令发送至主银行api服务器。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本发明的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本发明的实施例所属技术领域的技术人员所理解。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，"计算机可读介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(ram)，只读存储器(rom)，可擦除可编辑只读存储器(eprom或闪速存储器)，光纤装置，以及便携式光盘只读存储器(cdrom)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(pga)，现场可编程门阵列(fpga)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本发明各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同限定。