掌桥专利:专业的专利平台
掌桥专利
首页

多银行支付方法、系统、服务器和存储介质

文献发布时间:2023-06-19 10:57:17


多银行支付方法、系统、服务器和存储介质

技术领域

本发明实施例涉及金融领域技术,尤其涉及一种多银行支付方法、系统、服务器和存储介质。

背景技术

在现有技术中,集团打款方式多样,其中有一部分打款是人工登陆网银制单,这部分财务希望能统一系统化管理,为满足财务需求,在资金管理系统,接入银企直联支付管理,以方便财务打款。

其中,已有的代付系统接入的支付渠道只有平安、浦发、中信等几个银行,而集团公司的对公账号有很多,分布在不同的银行中,支付时需要登录不同银行的网银系统或扫描不同账号的支付吗进行转账支付,导致支付效率低。

发明内容

本发明提供一种多银行支付方法、系统、服务器和存储介质,通过将多银行的支付生成支付单并统一发送至代付系统进行支付,使资金代付能够支持多个不同银行的结算需求,提高了多银行财务支付管理的效率。

第一方面,本发明提供一种多银行支付方法,由账务管理平台执行,包括:

从第一数据库读取预存的第一支付单,所述第一支付单包括收款账号、收款银行和支付金额;

基于所述收款账号、收款银行和支付金额生成第一支付请求,将所述第一支付请求发送至代付交易系统,以使代付交易系统向所述收款银行执行支付操作,收款银行生成订单流水号发送至代付交易系统;

从所述代付交易系统获取所述订单流水号;

基于第一支付单和订单流水号生成第一支付成功信息,将所述第一支付成功信息发送至企业邮箱,以提示财务人员完成所述第一支付单的支付。

进一步地,在所述从第一数据库读取预存的第一支付单之前,还包括:

获取财务人员上传的第一支付单,所述第一支付单包括收款账号、收款银行和支付金额;

基于所述第一支付单生成审批请求,将所述审批请求发送至OA审批系统;

获取OA审批系统的审批结果;

若所述审批结果为审批通过,则将所述第一支付单存储在第一数据库中;

若所述审批结果为审批不通过,则基于所述第一支付单生成审批不通过的提示信息并发送至企业邮箱,以提示财务人员审批不通过。

进一步地,在所述基于所述收款账号、收款银行和支付金额生成第一支付请求,将所述第一支付请求发送至代付交易系统之后,还包括:

从所述代付交易系统获取交易失败提示信息,所述交易失败提示信息包括交易失败账号、交易失败银行和交易失败时间;

基于所述第一支付单、交易失败账号、交易失败银行和交易失败时间生成第二支付单;

将所述第二支付单存入预设的第二数据库。

进一步地,在所述将所述第二支付单存入预设的第二数据库之后,还包括:

每隔预设时间间隔,从所述第二数据库读取预存的第二支付单,所述第二支付单包括支付金额、交易失败账号、交易失败银行和交易失败时间;

基于所述支付金额、交易失败账号、交易失败银行生成第二支付请求,将所述第二支付请求发送至代付交易系统,以使代付交易系统向所述收款银行执行支付操作,收款银行生成订单流水号发送至代付交易系统;

从所述代付交易系统获取所述订单流水号;

基于第二支付单和订单流水号生成第二支付成功信息,将所述第二支付成功信息发送至企业邮箱,以提示财务人员完成所述第二支付单的支付。

进一步地,所述第一支付单还包括预设支付时间,则从第一数据库读取预存的第一支付单之后,还包括:

基于所述收款账号、收款银行和支付金额生成第一支付请求,在所述预设支付时间将所述第一支付请求发送至代付交易系统,以使代付交易系统向所述收款银行执行支付操作,收款银行生成订单流水号发送至代付交易系统。

进一步地,所述第一支付单还包括收款银行的单笔支付限额,则所述从第一数据库读取预存的第一支付单之后,还包括:

判断所述支付金额是否大于所述单笔支付限额;

若小于等于所述单笔支付限额,则基于所述收款账号、收款银行和支付金额生成第一支付请求,将所述第一支付请求发送至代付交易系统;

若大于所述单笔支付限额,则将所述支付金额拆为N个子支付金额,其中N=支付金额/单笔支付限额,其中N为正整数,当N非整数则向上取整,第1笔至第N-1笔的每一笔子支付金额=单笔支付限额,第N笔子支付金额=支付金额-(N-1)单笔支付限额。

基于所述收款账号、收款银行和子支付金额生成N个支付子请求,将所述支付子请求发送至代付交易系统,以使代付交易系统向所述收款银行执行支付操作,收款银行生成N个子订单流水号发送至代付交易系统;

从所述代付交易系统获取所述N个子订单流水号并合并为订单流水号;

基于第一支付单和订单流水号生成第一支付成功信息,将所述第一支付成功信息发送至企业邮箱,以提示财务人员完成所述第一支付单的支付。

第二方面,本发明提供一种多银行支付系统,包括:

读取模块,用于从第一数据库读取预存的第一支付单,所述第一支付单包括收款账号、收款银行和支付金额;

第一支付模块,用于基于所述收款账号、收款银行和支付金额生成第一支付请求,将所述第一支付请求发送至代付交易系统,以使代付交易系统向所述收款银行执行支付操作,收款银行生成订单流水号发送至代付交易系统;

获取模块,用于从所述代付交易系统获取所述订单流水号;

发送模块,用于基于第一支付单和订单流水号生成第一支付成功信息,将所述第一支付成功信息发送至企业邮箱,以提示财务人员完成所述第一支付单的支付。

进一步地,还包括审批模块,用于:

获取财务人员上传的第一支付单,所述第一支付单包括收款账号、收款银行和支付金额;

基于所述第一支付单生成审批请求,将所述审批请求发送至OA审批系统;

获取OA审批系统的审批结果;

若所述审批结果为审批通过,则将所述第一支付单存储在第一数据库中;

若所述审批结果为审批不通过,则基于所述第一支付单生成审批不通过的提示信息并发送至企业邮箱,以提示财务人员审批不通过

第三方面,本发明提供一种服务器,包括存储器、处理器及存储在存储器上并可在处理器上运行的程序,所述处理器执行所述程序时实现如上述任意所述的多银行支付方法。

第四方面,本发明提供一种终端可读存储介质,其上存储有程序,所述程序被处理器执行时能够实现如上述任一所述的多银行支付方法。

本发明通过将多银行的支付生成支付单并统一发送至代付系统进行支付,使资金代付能够支持多个不同银行的结算需求,提高了多银行财务支付管理的效率。

附图说明

图1为本发明实施例一的多银行支付方法流程图;

图2是本发明实施例一的替代实施例图;

图3是本发明实施例一的替代实施例图;

图4为本发明实施例二的多银行支付方法流程图;

图5是本发明实施例三的多银行支付方法流程图;

图6为本发明实施例三的替代实施例图;

图7是本发明实施例四的多银行支付系统结构图;

图8为本发明实施例四的替代实施例图;

图9是本发明实施例五的一种服务器的结构示意图。

具体实施方式

下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是,此处所描述的具体实施例仅仅用于解释本发明,而非对本发明的限定。另外还需要说明的是,为了便于描述,附图中仅示出了与本发明相关的部分而非全部结构。

在更加详细地讨论示例性实施例之前应当提到的是,一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各步骤描述成顺序的处理,但是其中的许多步骤可以被并行地、并发地或者同时实施。此外,各步骤的顺序可以被重新安排。当其操作完成时处理可以被终止,但是还可以具有未包括在附图中的附加步骤。处理可以对应于方法、函数、规程、子例程、子程序等等。

此外,术语“第一”、“第二”等可在本文中用于描述各种方向、动作、步骤或元件等,但这些方向、动作、步骤或元件不受这些术语限制。这些术语仅用于将第一个方向、动作、步骤或元件与另一个方向、动作、步骤或元件区分。举例来说,在不脱离本申请的范围的情况下,第一打包模块可以为第二打包模块或第三打包模块,类似地,第二打包模块、第三打包模块可以为第一打包模块。第一打包模块和第二打包模块、第三打包模块都是分布式文件系统的打包模块,但其不是同一打包模块。术语“第一”、“第二”等而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本发明的描述中,“多个”、“批量”的含义是至少两个,例如两个,三个等,除非另有明确具体的限定。

下述实施例中提及的专有名词及英文缩写含义如下:

联行号就是一个地区银行的唯一识别标志。用于人民银行所组织的大额支付系统\小额支付系统\城市商业银行银行汇票系统\全国支票影像系统(含一些城市的同城票据自动清分系统)等跨区域支付结算业务。由12位组成:3位银行代码+4位城市代码+4位银行编号+1位校验位

备款:银行的客户自己的钱,可以是银行现在能用的资金,包括现金、准备金、存放同业。拿商票质押换银票业务举例,在票到期之前,缴纳的是保证金,到期时交的是备款,若备款不足,需要银行垫款。

实施例一

本实施例提供一种采用预存的支付单对多银行进行统一批量支付的方法,账务管理平台分别和代支付系统、银行系统、OA审核系统链接,账务管理平台向代支付系统发起指令以进行确定账户和银行的转账操作。账务管理平台同时能够获取OA审批系统的审批结果。管理平台同时与企业微信、企业邮箱等连接,当产生信息时向企业微信、邮箱发送信息。

如图1,包括如下步骤:

S101、从第一数据库读取预存的第一支付单,所述第一支付单包括收款账号、收款银行和支付金额;

本实施中,账务管理平台预存有支付单,该步骤的第一支付单指财务人员上传的支付单,用于记录发起打款的收款账号、收款银行和支付金额等信息。第一数据库用于存储第一数据单。

S102、基于所述收款账号、收款银行和支付金额生成第一支付请求,将所述第一支付请求发送至代付交易系统,以使代付交易系统向所述收款银行执行支付操作,收款银行生成订单流水号发送至代付交易系统。

该步骤中,收款银行当接收到汇款之后,若支付成功,则生成订单流水号发送至代付交易系统。

在该步骤中,还包括查询支付状态。具体地,将所述第一支付请求发送至代付交易系统,以使代付交易系统向所述收款银行执行支付操作之后,若还未收到收款银行的订单流水号,则账务管理平台将该笔支付单的支付状态置为“付款中”,并每隔5分钟向代付系统发起支付结果查询请求。当查询到支付结果后,代付系统会将支付结果返回账务管理系统,以使账务管理系统将该笔支付单的支付状态由“付款中”变更为“付款完成”。如果支付结果是失败的,将人工再次核对失败结果是否为银行返回的,避免重复打款,减少集团资金损失。

S103、从所述代付交易系统获取所述订单流水号;

S104、基于第一支付单和订单流水号生成第一支付成功信息,将所述第一支付成功信息发送至企业邮箱,以提示财务人员完成所述第一支付单的支付。

发送至企业邮箱或企业微信都可以。

如图2,在替代实施例中,所述第一支付单还包括预设支付时间,则在步骤S101之后,还包括:

S105、基于所述收款账号、收款银行和支付金额生成第一支付请求,在所述预设支付时间将所述第一支付请求发送至代付交易系统,以使代付交易系统向所述收款银行执行支付操作,收款银行生成订单流水号发送至代付交易系统。

如图3,在替代实施例中,所述第一支付单还包括收款银行的单笔支付限额,则在步骤S101之后,还包括:

S1061、判断所述支付金额是否大于所述单笔支付限额;

S1062、若小于等于所述单笔支付限额,则基于所述收款账号、收款银行和支付金额生成第一支付请求,将所述第一支付请求发送至代付交易系统;

S1063、若大于所述单笔支付限额,则将所述支付金额拆为N个子支付金额,其中N=支付金额/单笔支付限额,其中N为正整数,当N非整数则向上取整,第1笔至第N-1笔的每一笔子支付金额=单笔支付限额,第N笔子支付金额=支付金额-(N-1)单笔支付限额。

S1064、基于所述收款账号、收款银行和子支付金额生成N个支付子请求,将所述支付子请求发送至代付交易系统,以使代付交易系统向所述收款银行执行支付操作,收款银行生成N个子订单流水号发送至代付交易系统;

S1065、从所述代付交易系统获取所述N个子订单流水号并合并为订单流水号;

本实施例通过将多银行的支付生成支付单并统一发送至代付系统进行支付,使资金代付能够支持多个不同银行的结算需求,提高了多银行财务支付管理的效率。

实施例二

如图4,本实施例在上述实施例的基础上增加了对存入第一数据库之前的第一支付单进行审批的步骤,具体步骤如下:

S2011、获取财务人员上传的第一支付单,所述第一支付单包括收款账号、收款银行和支付金额;

S2012、基于所述第一支付单生成审批请求,将所述审批请求发送至OA审批系统;

S2013、获取OA审批系统的审批结果;

S2014、若所述审批结果为审批通过,则将所述第一支付单存储在第一数据库中;

S2015、若所述审批结果为审批不通过,则基于所述第一支付单生成审批不通过的提示信息并发送至企业邮箱,以提示财务人员审批不通过。

S202、从第一数据库读取预存的第一支付单,所述第一支付单包括收款账号、收款银行和支付金额;

S203、基于所述收款账号、收款银行和支付金额生成第一支付请求,将所述第一支付请求发送至代付交易系统,以使代付交易系统向所述收款银行执行支付操作,收款银行生成订单流水号发送至代付交易系统;

S204、从所述代付交易系统获取所述订单流水号;

S205、基于第一支付单和订单流水号生成第一支付成功信息,将所述第一支付成功信息发送至企业邮箱,以提示财务人员完成所述第一支付单的支付。

本实施例通过将多银行的支付生成支付单并统一发送至代付系统进行支付,使资金代付能够支持多个不同银行的结算需求,提高了多银行财务支付管理的效率。

实施例三

本实施例增加了一种当出现交易失败的hold单操作,如图5,包括如下步骤:

S301、从第一数据库读取预存的第一支付单,所述第一支付单包括收款账号、收款银行和支付金额;

S302、基于所述收款账号、收款银行和支付金额生成第一支付请求,将所述第一支付请求发送至代付交易系统,以使代付交易系统向所述收款银行执行支付操作,收款银行生成订单流水号发送至代付交易系统。

现有打款方式中,在制单时无法实时了解到付款账号余额信息,容易因余额不足而导致打款失败,需要重新制单。因此在另一替代实施例中,第一支付单还包括付款账号和付款账号余额,在该步骤中,还包括:

判断所述付款账号余额是否大于等于所述支付金额,若大于等于,则基于所述收款账号、收款银行和支付金额生成第一支付请求;若小于所述支付金额,则生成余额不足信息发送至企业邮箱,以提示财务人员对所述付款账号进行备款。

S303、从所述代付交易系统获取交易失败提示信息,所述交易失败提示信息包括交易失败账号、交易失败银行和交易失败时间;

S304、基于所述第一支付单、交易失败账号、交易失败银行和交易失败时间生成第二支付单;

S305、将所述第二支付单存入预设的第二数据库。

在替代实施例中,如图6,步骤S305之后还包括:

S306、每隔预设时间间隔,从所述第二数据库读取预存的第二支付单,所述第二支付单包括支付金额、交易失败账号、交易失败银行和交易失败时间;

S307、基于所述支付金额、交易失败账号、交易失败银行生成第二支付请求,将所述第二支付请求发送至代付交易系统,以使代付交易系统向所述收款银行执行支付操作,收款银行生成订单流水号发送至代付交易系统;

S308、从所述代付交易系统获取所述订单流水号;

S309、基于第二支付单和订单流水号生成第二支付成功信息,将所述第二支付成功信息发送至企业邮箱,以提示财务人员完成所述第二支付单的支付。

本实施例通过将支付失败的制单存入第二数据库中,经过预设时间间隔重新尝试支付,避免了财务人员需要重新录入制单的麻烦,提高效率。

实施例四

如图7所示,本实施例提供了一种多银行支付系统4,具体包括:

读取模块401,用于从第一数据库读取预存的第一支付单,所述第一支付单包括收款账号、收款银行和支付金额;

第一支付模块402,用于基于所述收款账号、收款银行和支付金额生成第一支付请求,将所述第一支付请求发送至代付交易系统,以使代付交易系统向所述收款银行执行支付操作,收款银行生成订单流水号发送至代付交易系统。

其中,第一支付单还包括预设支付时间,则该模块还用于基于所述收款账号、收款银行和支付金额生成第一支付请求,在所述预设支付时间将所述第一支付请求发送至代付交易系统,以使代付交易系统向所述收款银行执行支付操作,收款银行生成订单流水号发送至代付交易系统。

获取模块403,用于从所述代付交易系统获取所述订单流水号;

发送模块404,用于基于第一支付单和订单流水号生成第一支付成功信息,将所述第一支付成功信息发送至企业邮箱,以提示财务人员完成所述第一支付单的支付。

如图8,还包括审批模块405,用于:获取财务人员上传的第一支付单,所述第一支付单包括收款账号、收款银行和支付金额;基于所述第一支付单生成审批请求,将所述审批请求发送至OA审批系统;获取OA审批系统的审批结果;若所述审批结果为审批通过,则将所述第一支付单存储在第一数据库中;若所述审批结果为审批不通过,则基于所述第一支付单生成审批不通过的提示信息并发送至企业邮箱,以提示财务人员审批不通过。

交易失败提示模块406,用于从所述代付交易系统获取交易失败提示信息,所述交易失败提示信息包括交易失败账号、交易失败银行和交易失败时间;基于所述第一支付单、交易失败账号、交易失败银行和交易失败时间生成第二支付单;将所述第二支付单存入预设的第二数据库。

在替代实施例中,还包括:

第二支付模块407,用于:每隔预设时间间隔,从所述第二数据库读取预存的第二支付单,所述第二支付单包括支付金额、交易失败账号、交易失败银行和交易失败时间;基于所述支付金额、交易失败账号、交易失败银行生成第二支付请求,将所述第二支付请求发送至代付交易系统,以使代付交易系统向所述收款银行执行支付操作,收款银行生成订单流水号发送至代付交易系统;从所述代付交易系统获取所述订单流水号;基于第二支付单和订单流水号生成第二支付成功信息,将所述第二支付成功信息发送至企业邮箱,以提示财务人员完成所述第二支付单的支付。

在一种替代实施例中,第一支付单还包括收款银行的单笔支付限额,则还包括:

拆包模块408,用于从第一数据库读取预存的第一支付单之后,判断所述支付金额是否大于所述单笔支付限额;若小于等于所述单笔支付限额,则基于所述收款账号、收款银行和支付金额生成第一支付请求,将所述第一支付请求发送至代付交易系统;若大于所述单笔支付限额,则将所述支付金额拆为N个子支付金额,其中N=支付金额/单笔支付限额,其中N为正整数,当N非整数则向上取整,第1笔至第N-1笔的每一笔子支付金额=单笔支付限额,第N笔子支付金额=支付金额-(N-1)单笔支付限额。基于所述收款账号、收款银行和子支付金额生成N个支付子请求,将所述支付子请求发送至代付交易系统,以使代付交易系统向所述收款银行执行支付操作,收款银行生成N个子订单流水号发送至代付交易系统;从所述代付交易系统获取所述N个子订单流水号并合并为订单流水号;基于第一支付单和订单流水号生成第一支付成功信息,将所述第一支付成功信息发送至企业邮箱,以提示财务人员完成所述第一支付单的支付。

本实施例通过提供一种多银行支付系统4,可执行本发明任意实施例所提供的多银行支付方法,具备执行方法相应的功能模块和有益效果。

实施例五

本实施例提供了一种服务器的结构示意图,如图9所示,该服务器包括处理器501、存储器502、输入装置503和输出装置504;服务器中处理器501的数量可以是一个或多个,图中以一个处理器501为例;设备/终端/服务器中的处理器501、存储器502、输入装置503和输出装置504可以通过总线或其他方式链接,图9中以通过总线链接为例。

存储器502作为一种计算机可读存储介质,可用于存储软件程序、计算机可执行程序以及模块,如本发明实施例中的多银行支付对应的程序指令/模块。处理器501通过运行存储在存储器502中的软件程序、指令以及模块,从而执行设备/终端/服务器的各种功能应用以及数据处理,即实现上述的多银行支付。

存储器502可主要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需的应用程序;存储数据区可存储根据终端的使用所创建的数据等。此外,存储器502可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中,存储器502可进一步包括相对于处理器501远程设置的存储器,这些远程存储器可以通过网络链接至设备/终端/服务器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置503可用于接收输入的数字或字符信息,以及产生与设备/终端/服务器的用户设置以及功能控制有关的键信号输入。输出装置504可包括显示屏等显示设备。

本发明实施例五通过提供一种服务器,可执行本发明任意实施例所提供的多银行支付,具备执行方法相应的功能模块和有益效果。

实施例六

本发明实施例六还提供了一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现如本发明任意实施例所提供的多银行支付,该方法可以包括:

从第一数据库读取预存的第一支付单,所述第一支付单包括收款账号、收款银行和支付金额;

基于所述收款账号、收款银行和支付金额生成第一支付请求,将所述第一支付请求发送至代付交易系统,以使代付交易系统向所述收款银行执行支付操作,收款银行生成订单流水号发送至代付交易系统;

从所述代付交易系统获取所述订单流水号;

基于第一支付单和订单流水号生成第一支付成功信息,将所述第一支付成功信息发送至企业邮箱,以提示财务人员完成所述第一支付单的支付。

本发明实施例的计算机可读存储介质,可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括:具有一个或多个导线的电链接、便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

存储介质上包含的程序代码可以用任何适当的介质传输,包括但不限于无线、电线、光缆、RF等等,或者上述的任意合适的组合。

可以以一种或多种程序设计语言或其组合来编写用于执行本发明操作的计算机程序代码,程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++,还包括常规的过程式程序设计语言诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或终端上执行。在涉及远程计算机的情形中,远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—链接到用户计算机,或者,可以链接到外部计算机(例如利用因特网服务提供商来通过因特网链接)。

注意,上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解,本发明不限于这里所述的特定实施例,对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此,虽然通过以上实施例对本发明进行了较为详细的说明,但是本发明不仅仅限于以上实施例,在不脱离本发明构思的情况下,还可以包括更多其他等效实施例,而本发明的范围由所附的权利要求范围决定。

相关技术
  • 多银行支付方法、系统、服务器和存储介质
  • 服务器系统、非临时计算机可读存储介质以及用以增强服务器系统中的存储器容错率的方法
技术分类

06120112739294