CN112990922A - 批量支付方法、装置、设备及存储介质 - Google Patents

Abstract

本申请提供一种批量支付方法、装置、设备及存储介质，涉及支付技术领域。该方法包括：获取批量支付指令；其中，所述批量支付指令中包括至少一个分指令；对所述批量支付指令的信息进行预处理，获取预处理后的所述批量支付指令为目标批量支付指令；根据所述目标批量支付指令对支付用户的信息进行登记；根据所述目标批量支付指令进行支付。相对于现有技术，避免了人工支付效率低导致的时效性不足且支付的准确性不足的问题。

Description

批量支付方法、装置、设备及存储介质

技术领域

本申请涉及支付技术领域，具体而言，涉及一种批量支付方法、装置、设备及存储介质。

背景技术

托管系统清算业务的核心之一是每日根据处理管理人发送的支付指令，完成在托管系统中对各支付指令的任务分拣、指令录入、信息验证及支付等操作。

现有的支付指令一般为人工根据支付指令的指示，由支付方向待支付方进行支付。

但是这样人工支付的方式一旦存在大批量的支付指令，就会存在支付效率低，导致支付的时效性不足，且人工支付容易出现支付的准确性不足的问题。

发明内容

本申请的目的在于，针对上述现有技术中的不足，提供一种批量支付方法、装置、设备及存储介质，以解决现有技术中人工支付效率低导致的时效性不足且支付的准确性不足的问题。

为实现上述目的，本申请实施例采用的技术方案如下：

第一方面，本申请一实施例提供了一种批量支付方法，所述方法包括：

获取批量支付指令；其中，所述批量支付指令中包括至少一个分指令；

对所述批量支付指令的信息进行预处理，获取预处理后的所述批量支付指令为目标批量支付指令；

根据所述目标批量支付指令对支付用户的信息进行登记；

根据所述目标批量支付指令进行支付。

可选地，所述获取批量支付指令，包括：

对获取的总指令信息进行数据解析，获取解析后的至少一个分指令；

根据所述至少一个分指令，确定所述批量支付指令。

可选地，所述获取批量支付指令，包括：

根据预设接口获取所述批量支付指令。

可选地，对所述批量支付指令的信息进行预处理，获取预处理后的所述批量支付指令为目标批量支付指令之前，所述方法还包括：

对所述批量支付指令进行检查，确定所述批量支付指令的金额信息是否通过检查。

可选地，所述对所述批量支付指令进行检查，确定所述批量支付指令的金额信息是否通过检查，包括：

根据各所述分指令对所述批量支付指令进行检查，确定所述批量支付指令的金额信息是否通过检查。

可选地，对所述批量支付指令的信息进行预处理，获取预处理后的所述批量支付指令为目标批量支付指令，包括：

验证各所述分指令的对应的待支付账户信息是否合法；

验证各所述分指令对应的待支付账户信息是否满足一致性；

向各所述分指令中补充支付系统的标识信息；

确定通过合法性验证、一致性验证，且补充所述支付系统的标识信息的各所分指令构成所述目标批量支付指令。

可选地，所述支付用户的信息包括下述至少一项：

支付方式、支付账号、业务类型、支付金额、支付时间信息、支付前余额信息或支付后余额信息。

可选地，所述根据所述目标批量支付指令进行支付，包括：

根据所述目标批量支付指令中，各所述分指令对应的所述支付用户的信息，确定支付方式；

根据所述支付方式执行对应的所述分指令。

可选地，所述根据所述目标批量支付指令中，各所述分指令对应的所述支付用户的信息，确定支付方式，包括：

在所述分指令的数量大于预设阈值且批量支付的功能为开启状态时，确定支付方式为批量支付；

在所述分指令的数量小于预设阈值或所述批量支付的功能为关闭状态时，确定所述支付方式为逐笔支付。

可选地，所述在所述分指令的数量大于预设阈值且批量支付的功能为开启状态时，确定支付方式为批量支付之后，所述方法还包括：

判断所述支付方式为批量支付的所述分指令的支付金额是否大于或等于预设金额阈值；

若大于，则确定所述分指令的支付方式为逐笔支付。

可选地，所述根据所述目标批量支付指令进行支付之后，所述方法还包括：

记录各所述分指令的执行结果。

可选地，所述根据所述目标批量支付指令进行支付之后，所述方法还包括：

根据各所述分指令的执行结果，对所述支付用户的信息进行更新。

第二方面，本申请另一实施例提供了一种批量支付装置，所述装置包括：获取模块、登记模块和支付模块，其中：

所述获取模块，用于获取批量支付指令；其中，所述批量支付指令中包括至少一个分指令；对所述批量支付指令的信息进行预处理，获取预处理后的所述批量支付指令为目标批量支付指令；

所述登记模块，用于根据所述目标批量支付指令对支付用户的信息进行登记；

所述支付模块，用于根据所述目标批量支付指令进行支付。

可选地，所述装置还包括：确定模块，其中：

所述获取模块，具体用于对获取的总指令信息进行数据解析，获取解析后的至少一个分指令；

所述确定模块，用于根据所述至少一个分指令，确定所述批量支付指令。

可选地，所述获取模块，具体用于根据预设接口获取所述批量支付指令。

可选地，所述确定模块，具体用于对所述批量支付指令进行检查，确定所述批量支付指令的金额信息是否通过检查。

可选地，所述确定模块，具体用于根据各所述分指令对所述批量支付指令进行检查，确定所述批量支付指令的金额信息是否通过检查。

可选地，所述装置还包括：验证模块和补充模块，其中：

所述验证模块，用于验证各所述分指令的对应的待支付账户信息是否合法；验证各所述分指令对应的待支付账户信息是否满足一致性；

所述补充模块，用于向各所述分指令中补充支付系统的标识信息；

所述确定模块，具体用于确定通过合法性验证、一致性验证，且补充所述支付系统的标识信息的各所分指令构成所述目标批量支付指令。

可选地，所述确定模块，具体用于根据所述目标批量支付指令中，各所述分指令对应的所述支付用户的信息，确定支付方式；

所述支付模块，具体用于根据所述支付方式执行对应的所述分指令。

可选地，所述确定模块，具体用于在所述分指令的数量大于预设阈值且批量支付的功能为开启状态时，确定支付方式为批量支付；在所述分指令的数量小于预设阈值或所述批量支付的功能为关闭状态时，确定所述支付方式为逐笔支付。

可选地，所述装置还包括：判断模块，用于判断所述支付方式为批量支付的所述分指令的支付金额是否大于或等于预设金额阈值；

所述确定模块，具体用于若大于，则确定所述分指令的支付方式为逐笔支付。

可选地，所述装置还包括：记录模块，用于记录各所述分指令的执行结果。

可选地，所述装置还包括：更新模块，用于根据各所述分指令的执行结果，对所述支付用户的信息进行更新。

第三方面，本申请另一实施例提供了一种批量支付设备，所述设备包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当所述批量支付设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行上述第一方面任一项所述的方法。

第四方面，本申请另一实施例提供了一种存储介质，所述存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如上述第一方面任一所述方法的步骤。

本申请的有益效果是：采用本申请提供的方法，可以在获取批量支付指令后，对批量支付指令中的信息进行预处理，确定预处理后的目标批量支付指令，随后根据目标批量支付指令对支付用户的信息进行登记，在登记结束后根据目标批量支付指令进行支付，这样的支付方式由于在支付前需要对批量支付指令的信息进行预处理，从而在保证资金账务完整性的前提下，通过批量支付的方式极大提升了支付的效率以及支付的准确性；在确定目标批量支付指令后还会对支付用户的信息进行登记，从而保证了支付用户的账务信息的完整性。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请一实施例提供的批量支付方法的流程示意图；

图2为本申请一实施例提供的预处理的流程示意图；

图3为本申请另一实施例提供的预处理的流程示意图；

图4为本申请一实施例提供的目标批量支付指令登记的流程示意图；

图5为本申请另一实施例提供的批量支付方法的流程示意图；

图6为本申请另一实施例提供的批量支付方法的流程示意图；

图7为本申请另一实施例提供的批量支付方法的流程示意图；

图8为本申请一实施例提供的批量支付后的登账记录的流程示意图；

图9为本申请另一实施例提供的批量支付方法的流程示意图；

图10为本申请一实施例提供的批量支付装置的结构示意图；

图11为本申请另一实施例提供的批量支付装置的结构示意图；

图12为本申请一实施例提供的批量支付设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。

通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

另外，本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。

为方便对本申请实施例的理解，下述对本申请实施例涉及的部分名词进行解释：

托管指令：以各种渠道录入或生成系统可处理的标准格式，并在后续具有高度流程化处理，进行系统自动化操作及接口交易。

年金计划：是一种属于企业雇主自愿为员工建立的福利计划，为企业职工提供一定程度退休收入保障的补充性养老金制度。

年金待遇支付(待遇发放)：是指参与年金计划的受益人符合退休年龄等法定条件时，应当享受的年金养老待遇。

支付系统行号：是一个地区银行的唯一识别标志，用于大额支付系统\小额支付系统\城市商业银行汇票系统\全国支票影像系统等跨区域支付结算业务。由12位组成：3位银行代码+4位城市代码+4位银行编号+1位校验位。

托管资金台账：针对托管运营的组合对应的托管账户，对发生的每一笔收款、出款进行流水记录的登记，包括资产组合、账号、业务类型、借贷方向、发生额、发生前余额、发生后余额、流水时间等。

本申请提供的批量支付方法应用于年金计划的批量支付场景中，在本申请的下述实施例中，均以针对年金计划的批量支付为例进行说明；应当理解虽然本申请的实施例主要围绕年金计划的批量支付进行解释说明，但是本申请提供的方法的应用场景并不局限于此，本申请提供的方法可以应用于任何需要进行批量支付的场景，例如每月工资的批量支付、年终奖的批量支付等，具体应用场景可以根据用户需要灵活调整，并不以上述实施例给出的为限。

在本申请提出的方法之前，现有技术中一般为人工根据支付指令的指示，由支付方向待支付方进行支付，但是这样的检测方式一旦存在大批量的支付指令，就会存在支付效率低的问题，从而造成支付的时效性不足，且人工支付容易出现支付的准确性不足的问题。

如下结合多个具体的应用示例，对本申请实施例所提供的一种批量支付方法进行解释说明。图1为本申请一实施例提供的一种批量支付方法的流程示意图，如图1所示，该方法包括：

S101：获取批量支付指令。

其中，所述批量支付指令中包括至少一个分指令。

示例地，在本申请的一个实施例中，获取批量支付指令的方式可以包括两种：文件解析方式和外部数据接口直接接入方式。

文件解析方式例如可以为对获取的总指令信息进行数据解析，获取解析后的至少一个分指令；根据所述至少一个分指令，确定所述批量支付指令。即托管的业务操作员录入一笔总指令信息，即录入指令信息组合、支付方信息以及支付总金额和支付总笔数。随后根据支付方客户发送的分指令文档例如可以为EXCEL文档，由操作员对该文档进行关联并对该文档进行解析产生分指令。在本申请的一个实施例中，托管系统提供了一套指令解析模板的配置，可根据不同组合或管理人以及业务类型，定制对应的指令解析规则，从而避免了由于每个管理人、受托人发送的文档样式五花八门导致解析的分指令格式无法统一的问题，从而提升了托管系统的灵活性，满足不同支付方客户的要求；其中文档的接入方式例如可以为由邮件直接接入系统，本申请在此并不做任何限制。

可选地，指令解析模板中例如可以包括：业务类型、参与人角色类型、适用机构、汇总行数、资产组合、参与人、分指令起始行号和审核状态等，应当理解上述实施例仅为示例性说明，具体解析模板中包括的内容可以根据用户需要灵活调整，并不以上述实施例给出的为限。

具体的，支付方客户可通过邮件方式的方式直接将包括多个分指令的文档发送至托管系统，托管业务人员可先录入总指令信息，并通过托管系统功能关联支付方客户发送的分指令文档，进行数据解析。并且系统支持文档追加的方式，将多个分指令文件数据解析到同一批次的同一总指令下。

其中，例如可以根据资产组合、管理人、业务类型等维度，配置对应的解析规则，例如支付方客户excel文档中的A列对应账号字段，是否为必输入字段，有效数据从第N行开始，汇总数据为最后N行等配置信息，从而使得托管系统能应对不同支付方、不同样式的文档，极大提升系统的灵活性和扩展性。

其次，对支付方的文档进行解析并产生托管系统可识别的指令信息。根据总指令的组合、业务类型等信息，加载解析后的配置信息，并分批次读取文档数据进行加工处理，对解析数据进行有效性判断，例如：对日期、金额格式等进行判断，判断是否合规，必输入字段是否为空等，对不合规数据进行异常提示，提醒操作员解析数据存在异常。

外部数据接口直接接入方式例如可以为采用数据交换直连接口接入，这种接口为第三方接口，接口格式统一，但是需要支付方客户有对应的系统进行对接。当收到支付方客户通过接口发送的待遇支付指令数据时，托管系统自动进行报文解析，并产生对应的指令信息。

S102：对所述批量支付指令的信息进行预处理，获取预处理后的所述批量支付指令为目标批量支付指令。

其中，对批量支付指令的信息进行预处理，是为了对接入系统的批量支付指令进行数据清洗、检查和加工。从而最大限度的补充支付方客户提供的指令信息，将不是特别准确或存在缺失的分指令信息进行清洗、反填和纠错，以确保支付方客户提供的批量支付指令信息能准确的高效的完成支付，并且预处理会提前确定存在支付风险的分指令，并将对有支付风险的分指令提前暴露提示给业务人员，避免支付时才发现异常，导致支付方客户利益受损或影响支付效率等问题。

可选地，在本申请的一个实施例中，预处理内容例如可以包括：验证各所述分指令的对应的待支付账户信息是否合法；验证各所述分指令对应的待支付账户信息是否满足一致性；向各所述分指令中补充支付系统的标识信息；确定通过合法性验证、一致性验证，且补充所述支付系统的标识信息的各所分指令构成所述目标批量支付指令。

图2为本申请一实施例提供的预处理的流程示意图，如图2所示，在指令接入和计算完成后，随即进入批量指令信息(批量支付指令信息)的补录环节，建立后台批量任务后，对批量指令信息多线程分批次进行处理，在本申请的一个实施例中，例如可以开启5个线程，每批次的线程开启2000个指令，随后对各线程进行预设的预处理步骤，即：账户信息的检查、支付信息的补充、是否可直连支付的检查，最后汇总所有检查结果，将通过且查且成功补充信息的批量支付指令确定为目标批量支付指令，目标量支付指令中的各指令信息均为补录完成的指令信息。

图3为本申请另一实施例提供的预处理的流程示意图，如图3所示，预处理的具体流程例如可以为：账户检查阶段，在获取待处理的指令列表(批量支付指令中的各分指令)后，验证各所述分指令的对应的待支付账户信息是否合法例如可以包括：验证各分指令中的账号是否包括非法字符、金额是否合规性、标志信息是否正确(标志信息例如可以包括：个人/非个人标志)、开户行名称是否超长、付款摘要信息是否超长等，若存在验证不通过的分指令，则记录并返回存在异常的分指令事项。应当理解上述实施例仅为示例性说明，具体合法性的检测内容可以根据用户需要灵活调整，并不以上述实施例给出的为限。

可直连支付检查验证阶段，在获取待处理的指令列表后，各所述分指令对应的待支付账户信息是否满足一致性例如可以包括：对各分指令中的账号信息和户名信息的一致性进行检查，对跨行转账支付系统号进行检查，系统号不能为空；对支付信息中的支付路由渠道进行检测，检测是否合法，若存在验证不通过的分指令，则记录并返回存在异常的分指令事项。应当理解上述实施例仅为示例性说明，具体一致性检测的内容可以根据用户需要灵活调整，并不以上述实施例给出的为限。

支付信息的补充阶段，在获取待处理的指令列表后，向各分指令中补充支付系统的标识信息可以包括：根据开户行名称通过预设标准文件以及常用账户信息、支付成功指令信息对支付系统行号进行反填，根据支付系统行号对行内/跨行标志进行识别，通过行别信息对上支付跨行清算系统(超级网银)的支付行号进行补充等，若存在未成功补充的分指令，则记录并返回存在异常的分指令事项；应当理解上述实施例仅为示例性说明，具体补充信息的内容可以根据用户需要灵活调整，并不以上述实施例给出的为限。

最后的校验信息汇总阶段，根据异常事项，更行分指令状态，确定存在异常的分指令状态为异常，将分指令状态为正常的分指令进行汇总，汇总得到的多个分指令为目标批量支付指令。

这种对批量支付指令的信息进行预处理的方式，可以对批量支付指令中的各分指令进行预处理，从而保证了各分指令的准确性，保证了后续支付过程中的支付准确性，同时避免了支付过程中由于分指令异常的问题造成支付失败，影响支付效率的问题，进一步提高了支付的时效性。

S103：根据目标批量支付指令对支付用户的信息进行登记。

示例地，在本申请的一个实施例中，登记会在批量指令信息补录成功后调起，批量登记对应付款方的资金台账流水。例如可以包括：支付组合、支付方式、支付账号、业务类型、借贷方向、支付金额、支付时间信息、支付前余额信息或支付后余额信息等信息。正常情况下，各分指令在支付前需要先登记对应的资金台账，使得账户余额减少，能有效的防止该笔指令头寸被其他同账号指令占用而支付失败的情况发生，当该笔指令支付失败时，对应的冲正对应的台账流水，使得余额恢复。但不同于普通单笔的划款指令，批量指令如果数量较大时，登记台账会耗时较长，所以本申请中的系统根据可以根据配置的阈值及控制开关，自动选择登账方式：若分指令数量小于阈值，则可进行逐笔登账；若大于阈值，则采用后登账模式，在支付前只登记一笔总的冻结金额，在每笔分指令支付完成后再解冻分指令对应的金额并记录真正的一笔台账流水。采用后登账模式，能有效的缩短支付前登账环节的耗时，提升系统处理效率；具体登记方式和登记内容可以根据用户需要灵活调整，并不以上述实施例给出的为限。

图4为本申请一实施例提供的目标批量支付指令登记的流程示意图，如图4所示，在批量指令信息补录后，系统将自动调起批量登记资金台账模块，进行批量指令登记资金台账，确定批量指令是否允许登账，检查付款方账户是否有效，随后根据内扣＝实际金额+手续费的方式，更新各分指令实际支付金额，登记包括支付组合、支付方式、支付账号、业务类型、借贷方向、支付金额、支付时间信息、支付前余额信息或支付后余额信息等信息。根据后登账模式开关以及该批次指令数量阈值，选择普通逐笔登账或者后登账模式。其中例如可以包括：

头寸检查：判断支付方账号对应的当前台账余额是否大于等于当前批次需支付的总金额，包括实际支付金额+手续费金额。

其中，登账模式包括普通模式和后登账模式，后登账模式开关设置：系统提供了一套灵活的配置参数，可由业务人员自行进行配置。当且仅当后登账模式开关为″是″并且批量指令数量大于设置的阈值时，触发后登账模式，否则，将进行普通的逐笔登账模式。

普通逐笔登记资金台账：将根据总指令(批量支付指令)获取分指令信息，在本申请的一个实施例中，例如可以分批次循环获取该批次的分指令信息，随后逐笔登记分指令台账流水，即进行付款方资金台账流水的登记，最随后更新账户状态为待对账状态，再更新历史变动余额后，更新余额。

后登账模式：若满足条件进行后登账模式，则该环节不会对每笔分指令进行台账流水的登记，只登记总指令冻结金额，即总金额的一笔冻结台账，通过检查账户状态的方式的登记资金流水冻结，随后更新该付款方账户的冻结余额，和可用余额，以及更新历史冻结余额。后登账模式主要目的是提高支付效率，缩短支付前的时间消耗，将逐笔登记台账的耗时移到真正支付完成后再补。

S104：根据目标批量支付指令进行支付。

采用本申请提供的方法，可以在获取批量支付指令后，对批量支付指令中的信息进行预处理，确定预处理后的目标批量支付指令，随后根据目标批量支付指令对支付用户的信息进行登记，在登记结束后根据目标批量支付指令进行支付，这样的支付方式由于在支付前需要对批量支付指令的信息进行预处理，从而在保证资金账务完整性的前提下，通过批量支付的方式极大提升了支付的效率以及支付的准确性；在确定目标批量支付指令后还会对支付用户的信息进行登记，从而保证了支付用户的账务信息的完整性。

可选地，在上述实施例的基础上，本申请实施例还可提供一种批量支付方法，如下结合附图对上述方法的实现过程进行示例说明。图5为本申请另一实施例提供的批量支付方法的流程示意图，如图5所示，S102之前，该方法还可包括：

S105：对批量支付指令进行检查，确定批量支付指令的金额信息是否通过检查。

示例地，在本申请的一个实施例中，例如可以根据各分指令对批量支付指令进行检查，确定批量支付指令的金额信息是否通过检查。即无论是文件解析方式还是外部数据接口接入的方式，都需要对该批次的总批量支付指令信息与分指令信息进行总检查和分检查，例如确定各分指令的金额汇总是否等于总指令金额、各分指令的个税金额汇总是否等于总指令的个税金额、各分指令的汇总笔数是否等于总指令的总比数字段等。若检查不通过，则提示操作员该批量支付指令为异常信息，并且该批量支付指令不能往下流转；具体检查方式可以根据用户需要灵活调整，并不以上述实施例给出的为限制。

可选地，在上述实施例的基础上，本申请实施例还可提供一种批量支付方法，如下结合附图对上述方法中进行支付的实现过程进行示例说明。图6为本申请另一实施例提供的批量支付方法的流程示意图，如图6所示，S104可包括：

S106：根据目标批量支付指令中，各分指令对应的支付用户的信息，确定支付方式。

可选地，在本申请的一个实施例中，支付方式例如可以包括批量支付和逐笔支付，其中在分指令的数量大于预设阈值且批量支付的功能为开启状态时，确定支付方式为批量支付；在分指令的数量小于预设阈值或批量支付的功能为关闭状态时，确定支付方式为逐笔支付。

示例地，在一些可能的实施例中，确定支付方式为批量支付后，还需要判断支付方式为批量支付的分指令的支付金额是否大于或等于预设金额阈值；若大于，则确定分指令的支付方式为逐笔支付。

举例说明，在本申请的一个实施例中，可以根据该目标批量支付指令的规模数量，以及每笔分指令的信息，动态的选择不同的支付方式和支付渠道。根据配置的阈值以及批量支付开关，若分指令的数量大于或等于阈值并且批量支付的功能开关打开，则采用批量打包文件的支付方式；若分指令数量小于阈值或者批量支付的功能开关关闭，则采用逐笔支付方式。

在本申请的一个实施例中，批量支付方式例如可以为针对：行内转账指令打包行内批，行外小额支付指令按照3万一批分文件打包行外小额批，行外大额支付或超级网银支付则保持逐笔支付，其中逐笔支付的方式例如可以为多线程并发支付的方式。逐笔支付例如可以为：多线程并发支付，根据金额、支付系统行号以及行内外标志，选择行内转账、跨行小额支付渠道、跨行大额支付渠道、人民银行网上支付跨行清算系统(超级网银)渠道，逐笔进行支付。

S107：根据支付方式执行对应的分指令。

图7为本申请一实施例提供的批量支付的流程示意图，如图7所示，直连支付处理获取批量支付指令、批量检查支付结果和批量修改线下支付失败的指令数据，随后将获取的各指令数据提交支付或再次提交支付，随后根据批量支付开关+分指令支付渠道笔数，判断是否走批量支付，若是则提交三个批量任务，处理不同批次的任务，其中不同批次的任务例如可以包括：行内批量包、行外小额批量包或行外大额单笔批次；如不走批量支付则提交单笔处理批量任务，根据每笔分指令支付渠道，分别调不同接口完成支付；在本申请的一个实施例中，直连支持处理后还需要确定是否导出线下支付，若是则调用应急支付，导出分指令线下支付；若不需要导出线下支付则根据后登账模式下登记资金调整，随后确认支付完成。

可选地，在本申请的一个实施例中，S104之后，该方法还可包括：记录各分指令的执行结果，和/或根据各分指令的执行结果，对支付用户的信息进行更新。

示例地，在一些可能的实施例中，若之前登记台账采用的后登账模式，则在支付后需要该模块进行相应的补充登账处理。需要汇总分指令的支付状态，并且根据不同状态的结果，解冻总账的冻结金额，更新账户余额，并批量登记分指令的资金台账流水。若出现支付失败的分指令，则还应批量冲正对应的台账流水记录。

图8为本申请一实施例提供的批量支付后的登账记录的流程示意图，如图8所示，获取支付方账户余额后，更新对账状态为待对账，随后根据总指令(目标批量支付指令)编号获取开始登账日期，随后进行循环登记，循环登记的过程中检查实际支付的分指令是否到达终态，根据检测结果确定当日支付终态分指令汇总状态为Null，或根据检测结果确定不等于已支付，返回异常错误，或根据汇总后＝支付完成，确定汇总已支付/支付失败总金额，随后解冻当日实际支付金额，并对冻结余额进行更新，更新当前余额＝当前余额-支付成功金额，随后批量新增付款方资金台账流水，支付失败金额不为0，批量冲正支付失败台账流程，随后更新登账控制表为成功。

可选地，在本申请的一个实施例中，可以通过登账控制表获取开始登账日期，登记状态＝成功INSN_BTCH_ENTRACC_CTRL_TBL，为空默认py_dt，否则，将最新的登记日+1(同一个指令，出现跨日支付才会通过日期+1等第二天)；T日登账：开始和结束都是py_dt循环一次；T+1：如果T日终态已经登记了，则获取开始日期就是T+1即只登记T+1日；极端情况下，例如T日没有一笔分指令支付成功，故实际支付日期为空。只更新登记控制表。

图9为另一实施例提供的批量支付方法的流程示意图，如图9所示，批量支付方法主要包括：批量指令接入、批量指令信息补录、批量指令登记资金台账及头寸控制、批量指令支付模块和后登账模式处理登账；其中各部分的执行内容和执行方法于上述图1-图8实施例给出的相同，本申请在此不再赘述。

采用本申请提供的方法，对于类似年金待遇支付这类大批量的指令，海量的数据人工处理显然无法应对，支付的效率以及支付的准确性无法满足客户及业务发展的要求，并且人工成本的花销太高，甚至根本无法完成支付。该解决方案解决了业务人员处理效率的问题，减少了托管业务人工处理时间，在保证资金账务完整性的前提下，极大提升了支付的效率以及支付的准确性。对于支付方客户提供的指令数据存在瑕疵或信息缺失的情况下，通过一系列措施仍然能最大限度的保证完成支付工作。采用灵活的登账方式，在支付效率满足业务及客户要求的前提下保证了账务的完备性。无需人工干预，系统能自动选择路由不同的支付方式和支付渠道，以保证指令支付的成功率和准确性。从而实现了对于大批量指令，系统可以实现自动化高效准确的完成支付的整体思路；为了准确完成支付，对于支付方客户指令数据的纠错、补充等的方法步骤；保证托管账务的完整性，同时提升整体支付效率的登账流程和方式；支持多种支付场景的自动化处理的思路和解决方案。

下述结合附图对本申请所提供的批量支付装置进行解释说明，该批量支付装置可执行上述图1-图9任一批量支付方法，其具体实现以及有益效果参照上述，如下不再赘述。

图10为本申请一实施例提供的批量支付装置的结构示意图，如图10所示，该装置包括：获取模块201、登记模块202和支付模块203，其中：

获取模块201，用于获取批量支付指令；其中，批量支付指令中包括至少一个分指令；对批量支付指令的信息进行预处理，获取预处理后的批量支付指令为目标批量支付指令；

登记模块202，用于根据目标批量支付指令对支付用户的信息进行登记；

支付模块203，用于根据目标批量支付指令进行支付。

图11为本申请一实施例提供的批量支付装置的结构示意图，如图11所示，该装置还包括：确定模块204，其中：

获取模块201，具体用于对获取的总指令信息进行数据解析，获取解析后的至少一个分指令；

确定模块204，用于根据至少一个分指令，确定批量支付指令。

可选地，获取模块201，具体用于根据预设接口获取批量支付指令。

可选地，确定模块204，具体用于对批量支付指令进行检查，确定批量支付指令的金额信息是否通过检查。

可选地，确定模块204，具体用于根据各分指令对批量支付指令进行检查，确定批量支付指令的金额信息是否通过检查。

如图11所示，该装置还包括：验证模块205和补充模块206，其中：

验证模块205，用于验证各分指令的对应的待支付账户信息是否合法；验证各分指令对应的待支付账户信息是否满足一致性；

补充模块206，用于向各分指令中补充支付系统的标识信息；

确定模块204，具体用于确定通过合法性验证、一致性验证，且补充支付系统的标识信息的各所分指令构成目标批量支付指令。

可选地，确定模块204，具体用于根据目标批量支付指令中，各分指令对应的支付用户的信息，确定支付方式；

支付模块203，具体用于根据支付方式执行对应的分指令。

可选地，确定模块204，具体用于在分指令的数量大于预设阈值且批量支付的功能为开启状态时，确定支付方式为批量支付；在分指令的数量小于预设阈值或批量支付的功能为关闭状态时，确定支付方式为逐笔支付。

如图11所示，该装置还包括：判断模块207，用于判断支付方式为批量支付的分指令的支付金额是否大于或等于预设金额阈值；

确定模块204，具体用于若大于，则确定分指令的支付方式为逐笔支付。

如图11所示，该装置还包括：记录模块208，用于记录各分指令的执行结果。

如图11所示，该装置还包括：更新模块209，用于根据各分指令的执行结果，对支付用户的信息进行更新。

上述装置用于执行前述实施例提供的方法，其实现原理和技术效果类似，在此不再赘述。

以上这些模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个特定集成电路(Application Specific Integrated Circuit，简称ASIC)，或，一个或多个微处理器(digital singnalprocessor，简称DSP)，或，一个或者多个现场可编程门阵列(FieldProgrammable Gate Array，简称FPGA)等。再如，当以上某个模块通过处理元件调度程序代码的形式实现时，该处理元件可以是通用处理器，例如中央处理器(CentralProcessing Unit，简称CPU)或其它可以调用程序代码的处理器。再如，这些模块可以集成在一起，以片上系统(system-on-a-chip，简称SOC)的形式实现。

图12为本申请一实施例提供的批量支付设备的结构示意图，该批量支付设备可以集成于服务器、或终端设备，或终端设备的芯片。

该批量支付设备包括：处理器501、存储介质502和总线503。

处理器501用于存储程序，处理器501调用存储介质502存储的程序，以执行上述图1-图9对应的方法实施例。具体实现方式和技术效果类似，这里不再赘述。

可选地，本申请还提供一种程序产品，例如存储介质，该存储介质上存储有计算机程序，包括程序，该程序在被处理器运行时执行上述方法对应的实施例。

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

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(英文：processor)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(英文：Read-Only Memory，简称：ROM)、随机存取存储器(英文：Random Access Memory，简称：RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

Claims (15)

1.一种批量支付方法，其特征在于，所述方法包括：

获取批量支付指令；其中，所述批量支付指令中包括至少一个分指令；

对所述批量支付指令的信息进行预处理，获取预处理后的所述批量支付指令为目标批量支付指令；

根据所述目标批量支付指令对支付用户的信息进行登记；

根据所述目标批量支付指令进行支付。

2.如权利要求1所述的方法，其特征在于，所述获取批量支付指令，包括：

对获取的总指令信息进行数据解析，获取解析后的至少一个分指令；

根据所述至少一个分指令，确定所述批量支付指令。

3.如权利要求1所述的方法，其特征在于，所述获取批量支付指令，包括：

根据预设接口获取所述批量支付指令。

4.如权利要求1所述的方法，其特征在于，对所述批量支付指令的信息进行预处理，获取预处理后的所述批量支付指令为目标批量支付指令之前，所述方法还包括：

对所述批量支付指令进行检查，确定所述批量支付指令的金额信息是否通过检查。

5.如权利要求4所述的方法，其特征在于，所述对所述批量支付指令进行检查，确定所述批量支付指令的金额信息是否通过检查，包括：

根据各所述分指令对所述批量支付指令进行检查，确定所述批量支付指令的金额信息是否通过检查。

6.如权利要求1所述的方法，其特征在于，对所述批量支付指令的信息进行预处理，获取预处理后的所述批量支付指令为目标批量支付指令，包括：

验证各所述分指令的对应的待支付账户信息是否合法；

验证各所述分指令对应的待支付账户信息是否满足一致性；

向各所述分指令中补充支付系统的标识信息；

确定通过合法性验证、一致性验证，且补充所述支付系统的标识信息的各所分指令构成所述目标批量支付指令。

7.如权利要求1所述的方法，其特征在于，所述支付用户的信息包括下述至少一项：

支付方式、支付账号、业务类型、支付金额、支付时间信息、支付前余额信息或支付后余额信息。

8.如权利要求1所述的方法，其特征在于，所述根据所述目标批量支付指令进行支付，包括：

根据所述目标批量支付指令中，各所述分指令对应的所述支付用户的信息，确定支付方式；

根据所述支付方式执行对应的所述分指令。

9.如权利要求8所述的方法，其特征在于，所述根据所述目标批量支付指令中，各所述分指令对应的所述支付用户的信息，确定支付方式，包括：

在所述分指令的数量大于预设阈值且批量支付的功能为开启状态时，确定支付方式为批量支付；

在所述分指令的数量小于预设阈值或所述批量支付的功能为关闭状态时，确定所述支付方式为逐笔支付。

10.如权利要求9所述的方法，其特征在于，所述在所述分指令的数量大于预设阈值且批量支付的功能为开启状态时，确定支付方式为批量支付之后，所述方法还包括：

判断所述支付方式为批量支付的所述分指令的支付金额是否大于或等于预设金额阈值；

若大于，则确定所述分指令的支付方式为逐笔支付。

11.如权利要求1所述的方法，其特征在于，所述根据所述目标批量支付指令进行支付之后，所述方法还包括：

记录各所述分指令的执行结果。

12.如权利要求1所述的方法，其特征在于，所述根据所述目标批量支付指令进行支付之后，所述方法还包括：

根据各所述分指令的执行结果，对所述支付用户的信息进行更新。

13.一种批量支付装置，其特征在于，所述装置包括：获取模块、登记模块和支付模块，其中：

所述获取模块，用于获取批量支付指令；其中，所述批量支付指令中包括至少一个分指令；对所述批量支付指令的信息进行预处理，获取预处理后的所述批量支付指令为目标批量支付指令；

所述登记模块，用于根据所述目标批量支付指令对支付用户的信息进行登记；

所述支付模块，用于根据所述目标批量支付指令进行支付。

14.一种批量支付设备，其特征在于，所述设备包括：所述设备包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当所述批量支付设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行上述权利要求1-12任一项所述的方法。

15.一种存储介质，其特征在于，所述存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行上述权利要求1-12任一项所述的方法。

Images