支付路由方法、装置、计算机设备和存储介质

技术领域

本申请涉及支付技术领域，特别是涉及一种支付路由方法、装置、计算机设备和存储介质。

背景技术

随着支付技术的发展，打款渠道多样化，可以通过互联网支付、移动支付、第三方支付向传统银行卡支付实现打款结算，例如，通过银企互联向银行卡进行支付、银企互联向信用社进行支付、支付宝向银行卡支付、微信向银行卡支付进行打款结算等。

由于全国大小银行、信用社、第三方支付平台等打款渠道的数量众多，因此，在进行跨行、跨第三方支付平台等打款时，使用不同打款渠道时，金额到账时间、打款费率(即通道费率)不等，即无法满足各个打款渠道秒级到账的要求，使得打款效率低。

发明内容

基于此，有必要针对上述技术问题，提供一种支付路由方法、装置、计算机设备和存储介质。

一种支付路由方法，该方法包括：

获取待处理的打款请求；该打款请求中携带有打款数额；确定多个打款渠道所对应的渠道数量、与每个打款渠道分别对应的打款费率、与每个打款渠道分别对应的打款队列请求数；基于该打款请求的发起方所对应的支付平台，确定与每个打款渠道分别对应的同行打款参数；根据该打款数额、该渠道数量、该打款费率、该打款队列请求数、以及该同行打款参数，生成与该打款请求对应的支付路由字典；该支付路由字典定义了每个打款渠道各自对应的当前优先级；基于该支付路由字典中各个打款渠道分别对应的当前优先级，从该多个打款渠道中确定与该打款请求相匹配的目标打款渠道；将该打款请求路由至与该目标打款渠道对应的目标设备，以触发该目标设备执行与该打款请求对应的打款操作。

在其中一个实施例中，根据该打款数额、该渠道数量、该打款费率、该打款队列请求数、以及该同行打款参数，生成与该打款请求对应的支付路由字典，包括：

对于各个打款渠道，分别将相应的打款费率乘以该打款数额，得到与各个打款渠道分别对应的预打款费；对于每个打款渠道，均综合相应的预打款费、该打款队列请求数、以及该同行打款参数，得到与相应打款渠道对应的打款数值；将各个打款渠道所对应的打款数值分别除以该渠道数量，得到与各个打款渠道分别对应的打款权重；基于与各个打款渠道分别对应的打款权重，将各个打款权重按照从大到小进行排序，生成与打款请求对应的支付路由字典，其中，最大打款权重对应的优先级最高。

在其中一个实施例中，基于该支付路由字典中各个打款渠道分别对应的当前优先级，从该多个打款渠道中确定与该打款请求相匹配的目标打款渠道，包括：

基于该支付路由字典，确定各个打款权重中最大打款权重；该最大打款权重对应的优先级最高；将该最大打款权重对应的打款渠道，作为与该打款请求相匹配的目标打款渠道。

在其中一个实施例中，该目标设备执行与该打款请求对应的打款操作，包括：

该目标设备将接收到的打款请求存储至对应的目标打款队列；该目标设备按照该目标打款队列中已存入打款请求的顺序，依次执行对应的打款操作；在该目标设备完成对该发起方发起的打款请求所对应的打款操作后，该目标设备反馈表征支付成功的支付信息。

在其中一个实施例中，该方法还包括：

当接收到目标设备反馈的表征打款不成功的反馈结果时，判断打款请求能否进行下一打款渠道的流转；若打款请求能进行下一打款渠道的流转，基于该支付路由字典，确定与打款请求对应的下一打款渠道；将该打款请求路由至与该下一打款渠道对应的下一目标设备，以触发该下一目标设备执行与该打款请求对应的打款操作。

在其中一个实施例中，若打款请求能进行下一打款渠道的流转，基于该路由字典，确定与打款请求对应的下一打款渠道，包括：

若打款请求能进行下一打款渠道的流转，根据该支付路由字典，获取优先级在该目标打款渠道之后的下一打款渠道。

在其中一个实施例中，该方法还包括：

若打款请求不能进行下一打款渠道的流转时，将表征打款不成功的反馈结果，发送至该打款请求的发起方。

一种支付路由装置，该装置包括：

获取模块，用于获取待处理的打款请求；该打款请求中携带有打款数额；

第一确定模块，用于确定多个打款渠道所对应的渠道数量、与每个打款渠道分别对应的打款费率、与每个打款渠道分别对应的打款队列请求数；

第二确定模块，用于基于该打款请求的发起方所对应的支付平台，确定与每个打款渠道分别对应的同行打款参数；

生成模块，用于根据该打款数额、该渠道数量、该打款费率、该打款队列请求数、以及该同行打款参数，生成与该打款请求对应的支付路由字典；该支付路由字典定义了每个打款渠道各自对应的当前优先级；

第三确定模块，用于基于该支付路由字典中各个打款渠道分别对应的当前优先级，从该多个打款渠道中确定与该打款请求相匹配的目标打款渠道；

路由模块，用于将该打款请求路由至与该目标打款渠道对应的目标设备，以触发该目标设备执行与该打款请求对应的打款操作。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现如上述任一该的支付路由方法。

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上述任一该的支付路由方法。

上述支付路由方法、装置、计算机设备和存储介质，在获取到携带有打款数额的待处理的打款请求时，确定多个打款渠道所对应的渠道数量、与每个打款渠道分别对应的打款费率、与每个打款渠道分别对应的打款队列请求数，并基于打款请求的发起方所对应的支付平台，确定与每个打款渠道分别对应的同行打款参数，这样就能根据打款数额、渠道数量、打款费率、打款队列请求数以及同行打款参数，生成与打款请求对应的支付路由字典。该支付路由字典中定义了各个打款渠道分别对应的当前优先级。进而基于支付路由字典中各个打款渠道分别对应的当前优先级，可以迅速地从多个打款渠道中确定与打款请求相匹配的目标打款渠道，再将打款请求路由至与目标打款渠道对应的目标设备，以触发目标设备执行与打款请求对应的打款操作。由于该目标打款渠道是综合了打款花费和到账时间等多个维度而确定出的优选的打款渠道，通过该目标打款渠道实现打款转账，可以实现在各个支付平台中打款金额秒级到账，进而提高打款效率。此外，相对于通过单一打款渠道确定目标打款渠道的方式，本申请通过综合考虑多个打款渠道，智能选择出优选的目标打款渠道的方式，能够提高打款的成功率。

附图说明

图1为一个实施例中支付路由方法的应用环境图；

图2为一个实施例中支付路由方法的流程示意图；

图3为一个实施例中生成支付路由字典步骤的流程示意图；

图4为另一个实施例中支付路由方法的流程示意图；

图5为另一个实施例中支付路由方法的流程示意图；

图6为另一个实施例中支付路由方法的流程示意图；

图7为一个实施例中支付路由装置的结构框图；

图8为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请提供的支付路由方法，可以应用于如图1所示的应用环境中。其中，终端102通过网络与服务器104进行通信，服务器104通过网络与目标设备106。用户可通过终端102触发打款请求，终端102发送待处理的打款请求至服务器104，服务器104获取待处理的打款请求；服务器104确定多个打款渠道对应的渠道数量、与每个打款渠道分别对应的打款费率、与每个打款渠道分别对应的打款队列请求数；服务器104基于该打款请求的发起方所对应的支付平台，确定与每个打款渠道分别对应的同行打款参数；服务器104根据打款请求中的打款数额、该渠道数量、该打款费率、该打款队列请求数、以及该同行打款参数，生成与该打款请求对应的支付路由字典；服务器104基于该支付路由字典，从该多个打款渠道中确定与该打款请求相匹配的目标打款渠道；服务器104将该打款请求路由至与该目标打款渠道对应的目标设备106，以触发该目标设备执行与该打款请求对应的打款操作。其中，终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备，服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现，目标设备106可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

在一个实施例中，如图2所示，提供了一种支付路由方法，以该方法应用于图1中的服务器为例进行说明，包括以下步骤：

步骤202，获取待处理的打款请求；该打款请求中携带有打款数额。

具体地，服务器从存储有多个打款请求的消息队列中，获取待处理的打款请求，该打款请求为打款请求发起方将打款数额打款至与收款用户相关的账户上。例如，某直播平台将该直播平台中100个主播的银行卡号、支付宝号、微信账号等多个账户提供至服务器，若该直播平台要打款直播半年的直播费用给每个主播，服务器从存储有多个发起方的打款请求的消息队列中，获取与该直播平台对应的待处理打款请求，即对每个主播打款直播半年的直播费用。

其中，消息队列为将消息投递到队列的容器，可以从该消息队列中取出消息，再转发给消费者，例如，该消息队列可以为RabbitMQ(Rabbit Message Queue，消息队列)、kafka(高吞吐量的分布式发布订阅消息系统)等开源中间件，能够解决系统间耦合、异步发送消息、流量削锋等问题。

步骤204，确定多个打款渠道所对应的渠道数量、与每个打款渠道分别对应的打款费率、与每个打款渠道分别对应的打款队列请求数。

其中，打款渠道为打款请求发起方实现向收款用户打款的通道。该打款渠道可以为银行打款(银行打款包括同一个银行打款、跨行打款)、第三方打款平台(如支付宝、微信等)、地方信用社打款等。打款费率(即通道费率)为各个打款渠道对应的手续费，比如同一个银行打款的打款费率为零，通过支付宝打款的打款费率为打款数额的千分之一。打款队列请求数为每个打款渠道对应的打款队列中排队的打款请求数。

具体地，服务器在接收到打款请求后，基于打款请求，自动获取与多个打款渠道对应的渠道数量、与每个打款渠道分别对应的打款费率、与每个打款渠道分别对应的打款队列请求数。其中，在同一时刻会有多个发起方进行打款，服务器在处理与打款请求相关的过程中，可能会花费秒级的处理时间、或者会花费分钟级的处理时间，因此，一个或多个打款渠道会存在打款请求排队的情况，即每个打款渠道存在相应的打款队列请求数，该打款队列请求数可以是一个也可以是多个。

步骤206，基于该打款请求的发起方所对应的支付平台，确定与每个打款渠道分别对应的同行打款参数。

其中，同行打款参数是表征同行支付的常数，其中，同行支付为打款请求的发起方与收款方都是同一银行支付。该打款请求的发起方所对应的支付平台可以是银行支付平台、支付宝支付平台、微信支付平台等等。当打款双方采用同一银行进行打款操作时，同行打款参数不为零，当打款双方采用跨行打款、或者跨平台打款时，同行打款参数为零。

具体地，服务器基于打款请求的发起方所对应的支付平台，将与支付平台不一致的打款渠道所对应的同行打款参数设置为零，将与支付平台一致的打款渠道所对应的同行打款参数设置为对应参数。例如，某直播平台采用A银行的支付平台向各个主播的账号进行打款，服务器确定该直播平台对应的支付平台为A银行，将打款渠道为A银行对应的同行打款参数H设置为100，将其他打款渠道(如支付宝打款渠道)对应的同行打款参数H设置为0。

步骤208，根据该打款数额、该渠道数量、该打款费率、该打款队列请求数、以及该同行打款参数，生成与该打款请求对应的支付路由字典；该支付路由字典定义了每个打款渠道各自对应的当前优先级。

其中，支付路由字典中包括所有打款渠道优先级组成的当前优先顺序。该支付路由字典可以整合多支打款渠道，其中，各个打款渠道中绑定有收款方的收款账号。

具体地，服务器根据打款请求中的打款数额、渠道数量、与各个打款渠道对应的打款费率、与各个打款渠道对应的打款队列请求数、以及与各个打款渠道对应的同行打款参数，确定各个打款渠道对应的当前优先级，基于各个打款渠道的当前优先级，生成与打款请求对应的支付路由字典。例如，某直播平台要通过A银行实现给各个主播打款，打款数额为M，服务器基于各个主播账号已绑定的首款平台确定打款渠道的数量、每个打款渠道的打款费率、每个打款渠道当前队列请求数、以及根据打款方对应的A银行确定每个打款渠道的同行打款参数，确定各个打款渠道对应的当前优先级，该优先级可以通过最优、优、良、一般进行评定，服务器按照最优、优、良、一般进行排列，得到倒排路由列表，服务器基于该倒排路由列表，生成与打款请求对应的支付路由字典。其中，每一个当前优先级可以对应有一个打款渠道或者对应有多个打款渠道。

步骤210，基于该支付路由字典中各个打款渠道分别对应的当前优先级，从该多个打款渠道中确定与该打款请求相匹配的目标打款渠道。

具体地，服务器基于该支付路由字典中各个打款渠道分别对应的当前优先级，获得包含有各个打款渠道当前优先级排列的倒排路由列表，确定与打款请求相匹配的目标打款渠道。

在其中一个实施例中，服务器根据各个打款渠道分别对应的当前优先级进行排序，获得包含有各个打款渠道当前优先级排列的倒排路由列表，其中，该当前优先级为最优对应有一个打款渠道，服务器选取倒排路由列表中当前优先级为最优对应的打款渠道作为目标打款渠道。

在其中一个实施例中，服务器根据各个打款渠道分别对应的当前优先级进行排序，获得包含有各个打款渠道当前优先级排列的倒排路由列表，其中，该当前优先级为最优对应有多个打款渠道，服务器随机选取当前优先级为最优对应的多个打款渠道中的一个打款渠道，作为目标打款渠道。

在其中一个实施例中，服务器根据各个打款渠道分别对应的当前优先级进行排序，获得包含有各个打款渠道当前优先级排列的倒排路由列表，其中，该当前优先级为最优对应有多个打款渠道，服务器随机选取当前优先级为最优、以及当前优先级为优对应的多个打款渠道中的一个打款渠道，作为目标打款渠道。

可以理解的是，服务器还可采用其他的选取方式，基于各个打款渠道当前优先级排列的倒排路由列表，从多个打款渠道中选取目标打款渠道，本申请实施例对此不作限定。

步骤212，将该打款请求路由至与该目标打款渠道对应的目标设备，以触发该目标设备执行与该打款请求对应的打款操作。

其中，目标设备为与收款方对应的收款平台，该目标设备可以为各个银行的后台服务器、支付宝的后台服务器、信用社的后台服务器。

具体地，服务器基于确定的目标打款渠道，将待处理的打款请求路由到与目标打款渠道对应的目标设备，该目标设备根据获取到的待处理的打款请求，执行与打款请求对应的打款操作。例如，服务器确定目标打款渠道为A银行打款渠道，根据A银行打款渠道提供的API(Application Programming Interface，应用程序接口)，服务器通过对接银企互联的API方式，将待处理的打款请求路由至与A银行打款渠道对应的后台目标设备，该后台目标设备实现单次或批量打款操作。

上述支付路由方法中，在获取到携带有打款数额的待处理的打款请求时，确定多个打款渠道所对应的渠道数量、与每个打款渠道分别对应的打款费率、与每个打款渠道分别对应的打款队列请求数，并基于打款请求的发起方所对应的支付平台，确定与每个打款渠道分别对应的同行打款参数，这样就能根据打款数额、渠道数量、打款费率、打款队列请求数以及同行打款参数，生成与打款请求对应的支付路由字典。该支付路由字典中定义了各个打款渠道分别对应的当前优先级。进而基于支付路由字典中各个打款渠道分别对应的当前优先级，可以迅速地从多个打款渠道中确定与打款请求相匹配的目标打款渠道，再将打款请求路由至与目标打款渠道对应的目标设备，以触发目标设备执行与打款请求对应的打款操作。由于该目标打款渠道是综合了打款花费和到账时间等多个维度而确定出的优选的打款渠道，通过该目标打款渠道实现打款转账，可以实现在各个支付平台中打款金额秒级到账，进而提高打款效率。此外，相对于通过单一打款渠道确定目标打款渠道的方式，本申请通过综合考虑多个打款渠道，智能选择出优选的目标打款渠道的方式，能够提高打款的成功率。

在一个实施例中，如图3所示，根据该打款数额、该渠道数量、该打款费率、该打款队列请求数、以及该同行打款参数，生成与该打款请求对应的支付路由字典，包括：

步骤302，对于各个打款渠道，分别将相应的打款费率乘以该打款数额，得到与各个打款渠道分别对应的预打款费。

具体地，服务器基于打款请求中的打款数额，将每个打款渠道对应的打款费率乘以打款数额获得与各个打款渠道分别对应的预打款费。例如，某企业需要将打款数额M打款至收款方，其中，同家银行打款不收取打款费率，支付宝打款费率为打款数额的0.1％，微信打款费率为打款数额的0.1％，跨行采取某银行打款费率为打款数额的0.15％，服务器计算支付宝预打款费为M·0.1％,微信预打款费为M·0.1％、跨行采用某银行预打款费为M·0.15％。

步骤304，对于每个打款渠道，均综合相应的预打款费、该打款队列请求数、以及该同行打款参数，得到与相应打款渠道对应的打款数值。

具体地，服务器基于每个打款渠道对应的预打款费、打款队列请求数、同行打款参数，采用相加求和或者加权求和的方法，获得与相应打款渠道对应的打款数值。

例如，服务器获取跨行打款渠道的方式进行打款，则同行打款参数H为0，预打款费为M·0.15％(M为打款数额)，该打款队列请求数为P，则该打款渠道对应的打款数值N可以为H+M·0.15％+P。或者，服务器分别设置预打款费、打款队列请求数、同行打款参数的计算权重，获得预打款费计算权重为a、打款队列请求数计算权重为b、同行打款参数计算权重为c，则打款渠道对应的打款数值N可以为H·c+M·a·0.15％+P·b。需要特别说明的是，该计算权重只用于计算打款数值的步骤。

步骤306，将各个打款渠道所对应的打款数值分别除以该渠道数量，得到与各个打款渠道分别对应的打款权重。

具体地，服务器基于打款渠道的渠道数量，将各个打款渠道对应获得的打款数值除以渠道数量，获得每个打款渠道对应的打款权重。例如，服务器通过相加求和获得某跨行打款渠道对应的打款数值N、以及打款数量n，则计算机获得该跨行打款渠道对应打款权重W，即(H+M·0.15％+P)/n。或者，服务器通过加权求和获得某跨行打款渠道对应的打款数值N、以及打款数量，获得该打款渠道对应打款权重W,即(H·c+M·a·0.15％+P·b)/n。

步骤308，基于与各个打款渠道分别对应的打款权重，将各个打款权重按照从大到小进行排序，生成与打款请求对应的支付路由字典，其中，最大打款权重对应的优先级最高。

具体地，服务器计算获得各个打款渠道分别对应的打款权重，基于各个打款权重进行从大到小排序，该打款权重的排序与优先级相匹配，得到倒排路由列表，其中打款权重最大对应为最优打款渠道、打款权重最小对应为劣打款渠道，服务器基于倒排路由列表生成与打款请求对应的支付路由字典。例如，某企业通过A银行需要完成打款，该打款数额为1000元，服务器获取支付宝打款队列有100个当前队列请求数、微信打款队列有50个当前队列请求数、A行打款队列有0个当前队列请求数，服务器为当前的打款请求动态实时生成一个支付路由字典，具体如下表1所示：

其中，A行的打款权重最高，服务器将A行的打款渠道作为最优的打款渠道；支付宝的打款权重居中，服务器将支付宝的打款渠道作为优的打款渠道；微信的打款权重最低，服务器将微信的打款渠道作为良的打款渠道。

在本实施例中，对于各个打款渠道，分别将相应的打款费率乘以该打款数额，得到与各个打款渠道分别对应的预打款费；对于每个打款渠道，均综合相应的预打款费、该打款队列请求数、该同行打款参数、该渠道数量，得到与各个打款渠道分别对应的打款权重；从而将各个打款权重按照从大到小进行排序，生成与打款请求对应的支付路由字典。因此，结合各个渠道的打款费率，对各个打款渠道的打款权重进行排序，以此作为目标打款渠道选取标准，能够降低跨行打款、跨平台打款的成本。

在一个实施例中，基于该支付路由字典中各个打款渠道分别对应的当前优先级，从该多个打款渠道中确定与该打款请求相匹配的目标打款渠道，包括：基于该支付路由字典，确定各个打款权重中最大打款权重；该最大打款权重对应的优先级最高；将该最大打款权重对应的打款渠道，作为与该打款请求相匹配的目标打款渠道。

具体地，服务器基于支付路由字典中倒排路由列表，确定各个打款权重对应的最大打款权重，服务器将该最大打款权重对应的打款渠道设置为与打款请求相匹配的目标打款渠道。其中，各个打款渠道的打款权重能够反映当前各个打款渠道的实际打款情况，例如，当存在打款渠道为同行打款、且打款队列请求数最少、打款费率最低时，该打款渠道对应的打款权重最高，服务器自动确定该打款渠道为目标打款渠道。

在本实施例中，根据最大打款权重，将与最大打款权重对应的打款渠道作为目标打款渠道，实现了结合多个打款渠道，考虑与打款渠道对应的打款情况，智能选择与打款请求相匹配的目标打款渠道，从而保证打款的成功率。

在其中一个实施例中，服务器设置定时任务机制，即服务器每隔一定的时间扫描各个打款渠道的排队情况，当服务器获取到打款渠道甲的打款权重为最大打款权重时，服务器通过定时任务机制扫描获得打款渠道甲的打款队列请求数很多，而打款渠道乙、打款渠道丙处于空闲状态，合理分配打款渠道。

在本实施例中，服务器通过定时任务机制，能够避免将打款请求都积压至打款队列请求数很多的打款渠道中，以此保证在短时间内完成打款，进而服务器能够在打款请求量很多的情况下，保证将数据及时分发。

在一个实施例中，该目标设备执行与该打款请求对应的打款操作，包括：该目标设备将接收到的打款请求存储至对应的目标打款队列；该目标设备按照该目标打款队列中已存入打款请求的顺序，依次执行对应的打款操作；在该目标设备完成对该发起方发起的打款请求所对应的打款操作后，该目标设备反馈表征支付成功的支付信息。

具体地，服务器将打款请求路由至目标打款渠道对应的目标设备，触发目标设备接收打款请求，并将获取到的打款请求定位至目标打款队列，并将打款请求存储至对应的打款队列；目标设备根据目标打款队列中的打款请求的顺序，通过与目标队列对应的打款服务依次订阅与该打款请求，当该接收到该打款请求后，打款服务执行对应的打款操作；目标设备通过打款服务执行与打款请求对应的打款操作，当该打款操作表征支付成功时，该目标设备将表征支付成功的支付信息反馈至服务器。

在本实施例中，目标设备将接收到的打款请求存储至对应的目标打款队列；目标设备按照该目标打款队列中已存入打款请求的顺序，以此执行对应的打款操作；在该目标设备完成对该发起方发起的打款请求所对应的打款操作后，该目标设备反馈标准支付成功的支付信息，服务器能够获取打款结果，从而能够基于打款结果能够及时做出对策，并且能够完整的记录当前的支付流程。

在一个实施例中，如图4所示，该方法还包括：

步骤402，当接收到目标设备反馈的表征打款不成功的反馈结果时，判断打款请求能否进行下一打款渠道的流转。

其中，下一打款渠道的流转为将打款请求从当前打款渠道路由至下一打款渠道的过程。

具体地，当目标设备进行打款操作的结果为打款不成功时，目标设备将表征打款不成功的反馈结果发送至服务器，服务器接收目标设备反馈的表征打款不成功的反馈结果时，基于目标打款渠道对应的打款权重，判断打款请求是否能够路由至下一打款渠道。

步骤404，若打款请求能进行下一打款渠道的流转，基于该支付路由字典，确定与打款请求对应的下一打款渠道。

具体地，若服务器基于目标打款渠道对应的打款权重，确定打款请求能够进行下一打款渠道的流转，服务器基于支付路由字典的倒排路由列表，通过除目标打款渠道对应的打款权重以外的各个打款渠道的优先级，确定与打款请求对应的下一打款渠道。例如，现支付路由字典中各个打款渠道排名为支付宝打款渠道、微信打款渠道、A银行打款渠道(该打款渠道为跨行打款渠道)、某地信用社打款渠道。若服务器确定支付宝打款渠道(目标打款渠道)的优先级不是最低，则服务器会自动选择支付路由字典中第二个打款渠道去完成打款业务，即确定微信打款渠道为下一打款渠道。

步骤406，将该打款请求路由至与该下一打款渠道对应的下一目标设备，以触发该下一目标设备执行与该打款请求对应的打款操作。

其中，与下一打款渠道对应的下一目标设备为收款方对应的另一收款平台，服务器中存储有收款方多个收款平台的账号。

具体地，服务器将待处理的打款请求路由至下一打款渠道对应的下一目标设备，该下一目标设备根据获取到的待处理的打款请求，执行与打款请求对应的打款操作。例如，服务器确定下一打款渠道为B银行打款渠道，根据B银行打款渠道提供的API(ApplicationProgramming Interface，应用程序接口)，服务器通过对接银企互联的API方式，将待处理的打款请求路由至与B银行打款渠道对应的后台目标设备，该后台目标设备实现单次或批量打款操作。

在本实施例中，当通过判断确定打款请求能进行下一打款渠道的流转时，基于该支付路由字典，确定与打款请求对应的下一打款渠道，并将打款请求路由至下一打款渠道对应的下一目标设备，以触发下一目标设备执行与该打款请求对应的打款操作。因此，能够在目标打款渠道对应的打款操作失败时，自动根据支付路由字典进行合理分配，实现自动匹配进行打款操作，极大减少人工干预。同时，相对于传统的单一打款渠道，通过支付路由字典能够获得多个打款渠道，满足小众群体的打款需求。

为了便于更清楚的了解本申请的技术方案，下述提供一个较为详细实施例进行描述，如图5所示，当服务器接收到打款请求的发起方对应的打款请求时，服务器基于打款请求中的打款数额，获取多个打款渠道所对应的渠道数量、与每个打款渠道分别对应的打款费率、与每个打款渠道分别对应的打款队列请求数、以及确定与每个打款渠道分别对应的同行打款参数，确定支付路由字典，服务器从包含多个打款请求的当前消息队列中获取待处理的打款请求，其中，服务器中服务有多个To B企业(主要是指以企业或组织机构为客户并通过某种产品/项目的交易打车合作从而获取收益的企业)，且有大量打款订单，服务器通过定时任务每隔一定时间，读取从企业已支付的订单批量向银企发起支付指令。服务器基于支付路由字典的支付宝打款渠道、银企互联(银行打款渠道)，确定与打款请求匹配的目标打款渠道，从而将打款请求路由至目标打款渠道对应的目标设备进行打款操作。

当目标打款渠道关闭时，服务器可根据支付路由字典自行选择下一打款渠道，并将打款请求路由至新的打款渠道对应的新的服务器，将打款请求重新定位到新的打款渠道对应的打款队列中，新的打款服务通过订阅打款请求，进行打款操作，若打款成功，新的服务器将打款结果返回至服务器，并由服务器通知用户打款成功，若打款失败，服务器通过确定下一打款渠道，将打款请求路由至下一打款渠道对应的下一目标设备，该打款请求会再次被调起，完成打款操作。

在本实施例中，通过支付路由字典能够自动且合理选择不同的打款渠道，实现在各个打款环境中秒级到账，提高打款效率，并且满足各个用户的打款需求。

在一个实施例中，该若打款请求能进行下一打款渠道的流转，基于该支付路由字典，确定与打款请求对应的下一打款渠道，包括：若打款请求能进行下一打款渠道的流转，根据该支付路由字典，获取优先级在该目标打款渠道之后的下一打款渠道。

具体地，若服务器基于目标打款渠道对应的打款权重，确定打款请求能够进行下一打款渠道的流转，服务器基于支付路由字典的倒排路由列表，通过各个打款渠道的优先级，确定优先级在该目标打款渠道之后的下一打款渠道，服务器将打款请求路由至下一打款渠道对应的下一目标设备。例如，现支付路由字典中各个打款渠道的优先级从高至低依次为支付宝打款渠道、微信打款渠道、A银行打款渠道(该打款渠道为跨行打款渠道)、某地信用社打款渠道。若服务器确定支付宝打款渠道(目标打款渠道)的优先级不是最低，则服务器会自动选择支付路由字典中优先级排名第二的打款渠道去完成打款业务，即确定微信打款渠道为下一打款渠道。

在本实施例中，若打款请求能进行下一打款渠道的流转，根据该路由字典，能够智能选择相对于目标打款渠道外，优先级高的下一打款渠道，避免人为确定，提高打款效率。

在一个实施例中，该方法还包括：若打款请求不能进行下一打款渠道的流转时，将表征打款不成功的反馈结果，发送至该打款请求的发起方。

具体地，若服务器基于目标打款渠道对应的打款权重，确定打款请求不能够进行下一打款渠道的流转，即该目标打款渠道对应的打款权重为支付路由字典各个打款权重中的最小，服务器接收表征打款不成功的反馈结果，并将该反馈结果发送至打款请求的发起方，同时服务器将发送报警信息，以提醒工作人员。例如，现支付路由字典中各个打款渠道的优先级从高至低依次为支付宝打款渠道、微信打款渠道、A银行打款渠道(该打款渠道为跨行打款渠道)、某地信用社打款渠道。若服务器确定A银行打款渠道(目标打款渠道)的优先级不是最低，则服务器会自动选择支付路由字典中优先级排名在某地信用社打款渠道之后的打款渠道去完成打款业务，由于支付路由字典中不存在排名在某地信用社打款渠道之后的打款渠道，服务器会发出报警信息，以便于人工介入，该报警信息可以是计算机显示界面显示文字信息，或者是服务器的声响装置发出报警声音。

在本实施例中，当通过判断确定打款请求不能进行下一打款渠道的流转时，将表征打款不成功的反馈结果，发送至打款请求的发起方。因此，能够在目标打款渠道对应的打款操作失败时，自动根据支付路由字典进行合理分配，实现自动匹配进行打款操作，极大减少人工干预。

为了便于更清楚的了解本申请的技术方案，如图6所示，提供一个更为详细实施例进行描述。该支付路由方法主要应用于服务器，该服务器可以为支付路由系统。该支付路由系统为分布式集群结构，配备多个服务器，能够根据业务数据量的大小、响应时间等不同可以弹性伸缩，提升系统的效率稳定性。其中，支付路由系统可以根据订单需求调节服务器的数量，即在日常时期，通过固定数量的服务器运行，在订单高峰期，自动增加服务器以满足订单需求。该支付路由系统包括负载均衡装置、缓存装置、多个支付系统的节点和报警装置。支付路由系统接收企业的打款请求；并基于打款请求获取打款数额。支付路由系统基于确定的多个打款渠道所对应的渠道数量、与每个打款渠道分别对应的打款费率、与每个打款渠道分别对应的打款队列请求数、与每个打款渠道分别对应的同行打款参数以及打款数额生成各个打款渠道的打款权重，动态生成支付路由字典，该支付路由字典基于各个打款渠道的优先级，以倒排路由列表的形式存放各个打款渠道，并缓存当前支付字典的倒排路由列表。支付路由系统基于支付路由字典确定与打款请求相匹配的目标打款渠道，并将打款请求路由至与目标打款渠道对应的目标设备，进行打款服务，获得与目标打款渠道对应的打款结果。该目标设备将打款结果发送至支付路由系统中，该支付路由系统基于打款结果，判断打款是否成功。若成功，则将打款成功结果发送至企业打款的业务端。若不成功，则支付路由系统基于目标打款渠道的优先级，确定打款请求是否能进入下一打款渠道进行流转；若能进行流转，则支付路由系统自动确定优先级在目标打款渠道之后的下一打款渠道，将打款请求路由至下一打款渠道进行打款操作；若不能进行流转，则支付路由系统接收打款失败结果，将打款失败结果发送至企业打款的业务端，并且支付路由系统会发出报警信息，以便于人工介入，该报警信息可以是计算机显示界面显示文字信息，或者是服务器的声响装置发出报警声音。

其中，在生成支付路由字典的过程中，支付路由系统通过保存日志实现有效核对每天打款的数据是否一致，在保证效率的情况下保证资金的安全，完整。并且在出现系统故障时，能够根据日志进行排查。同时，根据日志报警功能，在系统故障的第一时间知晓，降低运维的响应时间，确保能及时排除问题，保障系统的正常使用。

在本实施例中，通过生成支付路由字典能够实现基于多个打款渠道进行智能匹配打款，可以实现在各个打款环境中打款金额秒级到账，提高打款效率，减少跨行、跨平台的打款成本，并且能够满足大众、以及小众的打款请求。此外，通过采用分布式集群架构，能够实现弹性伸缩，保证了系统的稳定性，财务人员的人力成本。

应该理解的是，虽然图2-6的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2-6中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图7所示，提供了一种支付路由装置，包括：获取模块702、第一确定模块702、第二确定模块706、生成模块708、第三确定模块710和路由模块712，其中：

获取模块702，用于获取待处理的打款请求；该打款请求中携带有打款数额。

第一确定模块702，用于确定多个打款渠道所对应的渠道数量、与每个打款渠道分别对应的打款费率、与每个打款渠道分别对应的打款队列请求数。

第二确定模块706，用于基于该打款请求的发起方所对应的支付平台，确定与每个打款渠道分别对应的同行打款参数。

生成模块708，用于根据该打款数额、该渠道数量、该打款费率、该打款队列请求数、以及该同行打款参数，生成与该打款请求对应的支付路由字典；该支付路由字典定义了每个打款渠道各自对应的当前优先级。

第三确定模块710，用于基于该支付路由字典中各个打款渠道分别对应的当前优先级，从该多个打款渠道中确定与该打款请求相匹配的目标打款渠道。

路由模块712，用于将该打款请求路由至与该目标打款渠道对应的目标设备，以触发该目标设备执行与该打款请求对应的打款操作。

在一个实施例中，该生成模块708，用于对于各个打款渠道，分别将相应的打款费率乘以该打款数额，得到与各个打款渠道分别对应的预打款费；对于每个打款渠道，均综合相应的预打款费、该打款队列请求数、以及该同行打款参数，得到与相应打款渠道对应的打款数值；将各个打款渠道所对应的打款数值分别除以该渠道数量，得到与各个打款渠道分别对应的打款权重；基于与各个打款渠道分别对应的打款权重，将各个打款权重按照从大到小进行排序，生成与打款请求对应的支付路由字典，其中，最大打款权重对应的优先级最高。

在一个实施例中，该第三确定模块710，用于基于该支付路由字典，确定各个打款权重中最大打款权重；该最大打款权重对应的优先级最高；将该最大打款权重对应的打款渠道，作为与该打款请求相匹配的目标打款渠道。

在一个实施例中，该路由模块712，用于该目标设备将接收到的打款请求存储至对应的目标打款队列；该目标设备按照该目标打款队列中已存入打款请求的顺序，依次执行对应的打款操作；在该目标设备完成对该发起方发起的打款请求所对应的打款操作后，该目标设备反馈表征支付成功的支付信息。

在一个实施例中，该路由模块712，还用于当接收到目标设备反馈的表征打款不成功的反馈结果时，判断打款请求能否进行下一打款渠道的流转；若打款请求能进行下一打款渠道的流转，基于该支付路由字典，确定与打款请求对应的下一打款渠道；将该打款请求路由至与该下一打款渠道对应的下一目标设备，以触发该下一目标设备执行与该打款请求对应的打款操作。

在一个实施例中，该路由模块712，用于若打款请求能进行下一打款渠道的流转，根据该支付路由字典，获取优先级在该目标打款渠道之后的下一打款渠道。

在一个实施例中，该路由模块712，还用于若打款请求不能进行下一打款渠道的流转时，将表征打款不成功的反馈结果，发送至该打款请求的发起方。

关于支付路由装置的具体限定可以参见上文中对于支付路由方法的限定，在此不再赘述。上述支付路由装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图8所示。该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储支付路由数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种支付路由方法。

本领域技术人员可以理解，图8中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现以下步骤：

获取待处理的打款请求；该打款请求中携带有打款数额；确定多个打款渠道所对应的渠道数量、与每个打款渠道分别对应的打款费率、与每个打款渠道分别对应的打款队列请求数；基于该打款请求的发起方所对应的支付平台，确定与每个打款渠道分别对应的同行打款参数；根据该打款数额、该渠道数量、该打款费率、该打款队列请求数、以及该同行打款参数，生成与该打款请求对应的支付路由字典；该支付路由字典定义了每个打款渠道各自对应的当前优先级；基于该支付路由字典中各个打款渠道分别对应的当前优先级，从该多个打款渠道中确定与该打款请求相匹配的目标打款渠道；将该打款请求路由至与该目标打款渠道对应的目标设备，以触发该目标设备执行与该打款请求对应的打款操作。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：

对于各个打款渠道，分别将相应的打款费率乘以该打款数额，得到与各个打款渠道分别对应的预打款费；对于每个打款渠道，均综合相应的预打款费、该打款队列请求数、以及该同行打款参数，得到与相应打款渠道对应的打款数值；将各个打款渠道所对应的打款数值分别除以该渠道数量，得到与各个打款渠道分别对应的打款权重；基于与各个打款渠道分别对应的打款权重，将各个打款权重按照从大到小进行排序，生成与打款请求对应的支付路由字典，其中，最大打款权重对应的优先级最高。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：

基于该支付路由字典，确定各个打款权重中最大打款权重；该最大打款权重对应的优先级最高；将该最大打款权重对应的打款渠道，作为与该打款请求相匹配的目标打款渠道。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：

该目标设备将接收到的打款请求存储至对应的目标打款队列；该目标设备按照该目标打款队列中已存入打款请求的顺序，依次执行对应的打款操作；在该目标设备完成对该发起方发起的打款请求所对应的打款操作后，该目标设备反馈表征支付成功的支付信息。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：

当接收到目标设备反馈的表征打款不成功的反馈结果时，判断打款请求能否进行下一打款渠道的流转；若打款请求能进行下一打款渠道的流转，基于该支付路由字典，确定与打款请求对应的下一打款渠道；将该打款请求路由至与该下一打款渠道对应的下一目标设备，以触发该下一目标设备执行与该打款请求对应的打款操作。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：

若打款请求能进行下一打款渠道的流转，根据该支付路由字典，获取优先级在该目标打款渠道之后的下一打款渠道。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：

若打款请求不能进行下一打款渠道的流转时，将表征打款不成功的反馈结果，发送至该打款请求的发起方。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：

获取待处理的打款请求；该打款请求中携带有打款数额；确定多个打款渠道所对应的渠道数量、与每个打款渠道分别对应的打款费率、与每个打款渠道分别对应的打款队列请求数；基于该打款请求的发起方所对应的支付平台，确定与每个打款渠道分别对应的同行打款参数；根据该打款数额、该渠道数量、该打款费率、该打款队列请求数、以及该同行打款参数，生成与该打款请求对应的支付路由字典；该支付路由字典定义了每个打款渠道各自对应的当前优先级；基于该支付路由字典中各个打款渠道分别对应的当前优先级，从该多个打款渠道中确定与该打款请求相匹配的目标打款渠道；将该打款请求路由至与该目标打款渠道对应的目标设备，以触发该目标设备执行与该打款请求对应的打款操作。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：

对于各个打款渠道，分别将相应的打款费率乘以该打款数额，得到与各个打款渠道分别对应的预打款费；对于每个打款渠道，均综合相应的预打款费、该打款队列请求数、以及该同行打款参数，得到与相应打款渠道对应的打款数值；将各个打款渠道所对应的打款数值分别除以该渠道数量，得到与各个打款渠道分别对应的打款权重；基于与各个打款渠道分别对应的打款权重，将各个打款权重按照从大到小进行排序，生成与打款请求对应的支付路由字典，其中，最大打款权重对应的优先级最高。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：

基于该支付路由字典，确定各个打款权重中最大打款权重；该最大打款权重对应的优先级最高；将该最大打款权重对应的打款渠道，作为与该打款请求相匹配的目标打款渠道。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：

该目标设备将接收到的打款请求存储至对应的目标打款队列；该目标设备按照该目标打款队列中已存入打款请求的顺序，依次执行对应的打款操作；在该目标设备完成对该发起方发起的打款请求所对应的打款操作后，该目标设备反馈表征支付成功的支付信息。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：

当接收到目标设备反馈的表征打款不成功的反馈结果时，判断打款请求能否进行下一打款渠道的流转；若打款请求能进行下一打款渠道的流转，基于该支付路由字典，确定与打款请求对应的下一打款渠道；将该打款请求路由至与该下一打款渠道对应的下一目标设备，以触发该下一目标设备执行与该打款请求对应的打款操作。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：

若打款请求能进行下一打款渠道的流转，根据该支付路由字典，获取优先级在该目标打款渠道之后的下一打款渠道。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：

若打款请求不能进行下一打款渠道的流转时，将表征打款不成功的反馈结果，发送至该打款请求的发起方。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-Only Memory，ROM)、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic Random Access Memory，DRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。