CN114581094B - 一种支付渠道动态决策方法、服务器及计算机可读介质 - Google Patents

Abstract

本申请涉及网络金融支付的技术领域，尤其是涉及一种支付渠道动态决策方法、服务器及计算机可读介质，其包括获取付款方的付款请求；响应于付款请求，获取静态特征，以及根据静态特征，从付款方和收款方之间的各支付渠道中确定第一候选支付渠道；获取各支付渠道的服务状态，以及根据服务状态，从各支付渠道中确定第二候选支付渠道；根据第一候选支付渠道和第二候选支付渠道，确定目标支付渠道，生成与付款请求对应的目标交易指令，以及将目标交易指令存储到与目标支付渠道对应的交易指令队列中。本申请具有在网上支付时给企业推荐最优支付线路，降低人力和财务成本的效果。

Description

一种支付渠道动态决策方法、服务器及计算机可读介质

技术领域

本申请涉及网络金融支付的技术领域，尤其是涉及一种支付渠道动态决策方法、服务器及计算机可读介质。

背景技术

随着经营理念的转变和管理水平的提高，大量集团企业客户纷纷提出资金集中管理、提高资金使用效率、降低经营成本的财务管理需求。银企直联是一种新的网上银行系统与企业的财务软件系统在线直接联接的接入方式，银企直联通过因特网或专线连接方式，实现了银行和企业计算机系统的有机融合和平滑对接，企业通过财务系统的界面就可直接完成对银行账户以及资金的管理和调度，进行信息查询、转账支付等各项业务操作。

银企直连服务由各家银行基于各自的技术标准和服务标准提供的，具体表现在交易指令处理的性能不一致、交易结果确认时长不一致、可服务时间段不一致、服务稳定性不一致、可支持服务范围不一致、收费标准不一致等。

企业在使用银企直联服务时需同各银行签署直联协议，协议内容包含银企直联功能范围、费用标准、流量标准等。企业提供的服务器配置标准、网络配置标准等也不尽相同。目前这些因素变化带来的影响都需要企业人为来判断和决策，无法实时有效计算出最优结算费用的渠道，且只有在付款失败情况下才能根据直联返回的失败信息确认直联服务状态，很容易错过业务所需要的付款截止时间而造成损失且这种处理模式严重限制了企业资金运营能力的提升。

发明内容

为了在网上支付时给企业推荐最优支付线路，降低人力和财务成本，本申请提供一种支付渠道动态决策方法、服务器及计算机可读介质。

第一方面，本申请提供的一种支付渠道动态决策方法，采用如下的技术方案：

一种支付渠道动态决策方法，包括：

获取付款方的付款请求，其中，所述付款请求包括交易信息和收款方的标识信息；

响应于所述付款请求，获取静态特征，以及根据所述静态特征，从所述付款方和所述收款方之间的各支付渠道中确定第一候选支付渠道，其中，所述静态特征至少包括：所述收款方的交易特征，以及各所述支付渠道的付款限制及费率信息；

获取各所述支付渠道的服务状态，以及根据所述服务状态，从各所述支付渠道中确定第二候选支付渠道，其中，各所述支付渠道对应设置有交易指令队列，所述交易指令队列用于存储相应的支付渠道将要处理的交易指令，以及在处于队列头部的交易指令被相应的支付渠道成功处理后删除该处于队列头部的交易指令；

根据所述第一候选支付渠道和所述第二候选支付渠道，确定目标支付渠道，生成与所述付款请求对应的目标交易指令，以及将所述目标交易指令存储到与所述目标支付渠道对应的交易指令队列中。

在其中的一些实施例中，所述服务状态包括以下至少之一：服务器可达性、服务可用性和服务及时性；获取各所述支付渠道的服务状态包括：

基于心跳监测机制，确定各所述支付渠道对应的服务器的服务器可达性；

发送用于查询支付服务的服务状态的非交易指令至各所述支付渠道的服务器，根据各所述支付渠道的服务器对所述非交易指令的响应结果，确定各所述支付渠道的支付服务的服务可用性；

获取各所述支付渠道对应的交易指令队列中排队的交易指令的数量，根据所述交易指令的数量，确定各所述支付渠道的服务及时性。

在其中的一些实施例中，根据所述交易指令的数量，确定各所述支付渠道的服务及时性包括：

根据所述支付渠道的流量限制和所述交易指令的数量，确定所述支付渠道对应的交易指令队列中所有交易指令被处理完所需的总时长；

判断所述总时长是否大于预设时长阈值；

在所述总时长大于所述预设时长阈值的情况下，确定所述支付渠道未具备服务及时性；以及

在所述总时长不大于所述预设时长阈值的情况下，确定所述支付渠道具备服务及时性。

在其中的一些实施例中，所述服务状态还包括服务稳定性，获取各所述支付渠道的服务状态还包括，

获取各所述支付渠道的历史崩溃次数及崩溃发生时间，根据各支付渠道的历史崩溃次数及发生时间，确定各支付渠道的服务稳定性，其中，各所述支付渠道的历史崩溃包括历史各所述支付渠道服务器的不可达和历史各所述支付渠道的服务不可用；

判断所述支付渠道的历史崩溃次数是否大于预设次数；

在所述支付渠道的历史崩溃次数大于所述预设次数的情况下，确定所述支付渠道未具备服务稳定性；

在所述支付渠道的历史崩溃次数小于所述预设次数的情况下，确定所述支付渠道具备服务稳定性；

判断所述支付渠道的历史崩溃发生时间是否处于付款请求所在的时间段内，其中，所述付款请求所在的时间段定义为所述付款请求发出的时间加上预设时间长度后得到的时间长度；

若所述支付渠道的历史崩溃发生时间处于所述付款请求所在的时间段内，则确定所述支付渠道未具备服务稳定性；

若所述支付渠道的历史崩溃发生时间不处于所述付款请求所在的时间段内，则确定所述支付渠道具备服务稳定性。

在其中的一些实施例中，所述收款方的交易特征包括以下至少之一：付款金额、最迟付款日、银行账户；所述支付渠道的付款限制及费率信息包括以下至少之一：单笔限额、批次笔数限额、服务时间范围、手续费规则；其中，根据所述静态特征，从所述付款方和所述收款方之间的各支付渠道中确定第一候选支付渠道包括：

根据所述收款方的交易特征和各所述支付渠道的单笔限额、批次笔数限额和服务时间范围，从各所述支付渠道中确定所述第一候选支付渠道；和/或，

根据所述收款方的银行账户确定收款方银行，确定各所述支付渠道中与所述收款方银行对应的支付渠道为所述第一候选支付渠道；和/或，

根据各所述支付渠道的手续费规则、所述付款金额，确定采用各所述支付渠道付款的手续费金额，根据所述手续费金额确定所述第一候选支付渠道。

在其中的一些实施例中，所述交易对手的交易特征还包括交易对手的评级，其中，根据所述第一候选支付渠道和所述第二候选支付渠道，确定目标支付渠道，包括以下步骤：

判断所述交易对手的评级是否大于预设的评级；

若所述交易对手的评级大于预设的评级，则确定该交易对手为重要用户；

若所述交易对手为重要用户，则剔除所有不具备所述服务稳定性的目标支付渠道。

在其中的一些实施例中，生成与所述付款请求对应的目标交易指令包括：

根据所述付款方的账户特征，确定用于付款的银行账户，其中，所述付款方的账户特征包括以下至少之一：所述付款方各银行账户的可用余额、所述付款方各银行账户的监管约束；

根据所述目标支付渠道的手续费规则和批次笔数限额，将多笔付款金额进行合并，或将单笔付款金额进行拆分，以使得手续费金额最低；

根据用于付款的银行账户，生成一个或者多个所述目标交易指令，其中，每个目标交易指令对应于一个拆分或合并后的付款金额。

在其中的一些实施例中，生成与所述付款请求对应的目标交易指令还包括：

在付款金额超出所述目标支付渠道的单笔限额的情况下，将所述付款金额拆分为多笔付款金额。

第二方面，本申请提供的一种服务器，采用如下的技术方案：

一种服务器，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述的支付渠道动态决策方法。

第三方面，本申请提供的一种计算机可读存储介质，采用如下的技术方案：

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述的支付渠道动态决策方法。

通过本申请实施例提供的一种支付渠道动态决策方法基于企业支付数据和各银行的银企直连接口特征数据，提供一种实时动态化的计算能力，以最低费用成本、最高时效等推荐最优的目标支付渠道，还可以根据企业客户的不同需求实现自动化的路由支付，降低人力和财务成本。

附图说明

图1是本申请实施例的整体流程步骤示意图；

图2是本申请实施例中确定第一候选支付渠道的方法示意图；

图3是获取各支付渠道的服务状态的方法示意图；

图4是确定各支付渠道的服务及时性的方法示意图；

图5是生成与付款请求相应的目标交易指令的流程示意图。

具体实施方式

为更清楚地理解本申请的目的、技术方案和优点，下面结合附图和实施例，对本申请进行了描述和说明。然而，本领域的普通技术人员应该明白，可以在没有这些细节的情况下实施本申请。在一些情形下，为了避免不必要的描述使本申请的各方面变得晦涩难懂，对已经在较高的层次上描述了众所周知的方法、过程、系统、组件和/或电路将不作过多赘述。对于本领域的普通技术人员来说，显然可以对本申请所公开的实施例作出各种改变，并且在不偏离本申请的原则和范围的情况下，本申请中所定义的普遍原则可以适用于其他实施例和应用场景。因此，本申请不限于所示的实施例，而是符合与本申请所要求保护的范围一致的最广泛范围。

除另作定义外，本申请所涉及的技术术语或者科学术语应具有本申请所属技术领域具备一般技能的人所理解的一般含义。本申请所使用的术语仅出于描述特定实施例的目的，而不旨在于对本申请的限制。如本申请所使用的“一”、“一个”、“一种”、“该”、“这些”等类似的词并不表示数量上的限制，它们可以是单数或者复数。在本申请中所涉及的术语“包括”、“包含”、“具有”及其任何变体，其目的是涵盖不排他的包含；例如，包含一系列步骤或模块（单元）的过程、方法和系统、产品或设备并未限定于列出的步骤或模块（单元），而可包括未列出的步骤或模块（单元），或者可包括这些过程、方法、产品或设备固有的其他步骤或模块（单元）。

在本申请中所涉及的“多个”是指两个或两个以上。通常情况下，字符“/”表示前后关联的对象是一种“或”的关系。在本申请中所涉及的术语“第一”、“第二”、“第三”等，只是对相似对象进行区分，并不代表针对对象的特定排序。

本申请所涉及的术语“系统”、“引擎”、“单元”、“模块”和/或“块”是一种用于按级别区分不同级别的不同组件、元件、零件、部件、装配件、或功能的一种方法。这些术语可以被其他能够达到相同目的的表达替换。通常，本申请涉及的“模块”、“单元”或“块”是指硬件或者固件中体现的逻辑或软件指令的集合。本申请描述的“模块”、“单元”或“块”可以作为软件和/或硬件实现，并且在作为软件实现的情形下，他们可以被存储在任何类型的非易失性计算机可读存储介质或存储设备中。

在一些实施例中，软件模块/单元/块可以被编译并被链接到可执行程序中。将意识到，软件模块可以是可从其他模块/单元/块或从其自身调用的，和/或可以响应于检测到的事件或中断而被调用。配置为在计算设备上执行的软件模块/单元/块可以设置在计算机可读存储介质上，例如光盘、数字视频盘、闪存驱动器、磁盘、或任何其他有形媒体，或作为数字下载（并且可以最初以压缩或可安装的格式存储，该格式需要在执行之前进行安装、解压或解密）。这样的软件代码可以部分地或全部地存储在正在执行的计算设备的存储设备上，并应用在计算设备的操作之中。软件指令可以被嵌入到固件，例如EPROM中。还将意识到，硬件模块/单元/块可以被包括在连接的逻辑组件中，例如门和触发器，和/或可以被包括在可编程单元中，例如可编程门阵列或处理器。本文描述的模块/单元/块或计算设备功能可以被实现为软件模块/单元/块，还可以以硬件或固件来表示。通常，本文描述的模块/单元/块，它们可以与其他模块/单元/块组合，或者尽管它们是物理组织或存储的，但也可以被划分为子模块/子单元/子块。该描述可以适用于系统、引擎或其一部分。

将理解的是，当单元、引擎、模块或块被称为在另一单元、引擎、模块或块“上”、“连接”或“耦合至”另一单元、引擎、模块或块时，其可以直接在其它单元、引擎、模块或块上，与其连接或耦合或与之通信，或者可以存在中间单元、引擎、模块或块，除非上下文另有明确说明。在本申请中，术语“和/或”可包括任何一个或以上相关所列条目或其组合。

以下结合附图1-5对本申请作进一步详细说明。

本申请实施例公开一种支付渠道动态决策方法。

如图1所示，一种支付渠道动态决策方法包括：

S100，获取付款方的付款请求。

其中，付款请求包括交易信息和收款方的标识信息。交易信息包括款项性质（包括预收款、近期应收款、跨年度应收款、质保金等）、最迟付款日、付款金额和付款用途（工资发放、劳务费发放、还借款、采购、进口付汇等）。

其中，获取方法为：当付款方发出付款请求时，服务器自动获取付款请求，并识别付款请求内的各交易信息和付款方的标识信息。

S200，响应于付款请求，获取静态特征，并根据静态特征，从付款方和收款方之间的各支付渠道中确定第一候选支付渠道。

其中，静态特征至少包括收款方的交易特征以及支付渠道的付款限制及费率信息。

在一个实施例中，收款方的交易特征包括以下至少一种：付款金额、最迟付款日、银行账户；支付渠道的付款限制及费率信息包括至少以下之一：单笔限额、批次笔数限额、服务时间范围、手续费规则。根据静态特征，从付款方和收款方之间的各支付渠道中确定第一候选支付渠道的方式包括：

S210，根据收款方的交易特征和各支付渠道的单笔限额、批次笔数限额和服务时间范围，从各支付渠道中确定第一候选支付渠道。

例如，当A单位使用小额支付的时候，将A支付渠道作为第一候选支付渠道，当A单位在每日的17点之后进行小额支付的时候，选用B支付渠道作为第一候选支付渠道，当A单位交易超过五万元时，选用单笔限额大于五万元的C、D支付渠道作为第一候选支付渠道等等。

在另一个实施例中，根据静态特征，从付款方和收款方之间的各支付渠道中确定第一候选支付渠道的方式包括：

S220，根据收款方的银行账户确定收款方银行，确定各支付渠道中与收款方银行对应的支付渠道为第一候选支付渠道。

例如，根据收款方的账户和卡BIN表自动匹配出收款方银行A，以此优先选用同行支付，也就是与收款方银行A所对应的支付渠道A1、A2、A3作为第一候选支付渠道。

在另一个实施例中，根据静态特征，从付款方和收款方之间的各支付渠道中确定第一候选支付渠道的方式包括：

S230，根据各支付渠道的手续费规则、付款金额，确定采用各支付渠道付款的手续费金额，根据手续费金额确定第一候选支付渠道。

例如，现在有银行A、银行B和银行C。

其中银行A的手续费收费规则为：

1、本行转账：本行同城不收费，本行异地转账金额0.2万元以下（含0.2万元），收费1元；0.2万—0.5万元（含0.5万元），收费2.5元；0.5万—1万元（含1万元），收费5元；1万—5万元（含5万元），收费7.5元；5万元以上，按转账金额的0.015%收取，最高收费25元。

2、跨行转账（含同城和异地）：转账金额0.2万元以下（含0.2万元），收费1元；0.2万—0.5万元（含0.5万元），收费2.5元；0.5万—1万元（含1万元），收费5元；1万—5万元（含5万元），收费7.5元；5万元以上，按转账金额的0.015%收取，最高收费25元。

银行B的手续费的收费规则为：

1、同行同城:不收费；

2、同行异地或跨行：

1万元（含）以下，5元/笔；

1万-10万元（含），10元/笔；

10万-50万元（含），15元/笔；

50万-100万元（含），20元/笔；

100万元以上按0.002％收取，最高200元/笔。

柜台加急汇款、电子银行选择“加急”和“跨行快汇”的，手续费上浮20%，每笔最高收费不变。

目前有三条支付渠道A、B、C。

银行C的手续费收费规则为：

1、同行同城:不收费；

2、同行异地或跨行：

1万元（含）以下，5元/笔；

10万-50万元（含），15元/笔；

50万-100万元（含），20元/笔；

100万元以上按0.002％收取，最高200元/笔。

网银对公汇款、对私汇款、定向汇款、统一对外支付、跨行速汇、B2B支付服务、跨行速汇（收款）服务暂时优惠为免费。

这时有多种决策方法，如：

当需要向异地或跨行的交易对手支付5万元时，银行A的手续费为7.5元，而银行B和银行C都需要10元的手续费，这时便可以将银行A作为第一候选支付渠道；

当需要向异地或跨行的交易对手支付10万元时，银行A的手续费为100000*0.015%=15元，而银行B和银行C的手续费也为15元。这时可以将银行A、银行B和银行C皆作为第一候选支付渠道；

当需要向异地或跨行的交易对手支付20万元时，银行A的手续费为200000*0.015%=30元，又因为银行A最多只收取25元的手续费，所以这时银行A收取25元，而银行B和银行C皆收取20元的手续费，这时可以将银行B和银行C作为第一候选支付渠道；

当需要向异地或跨行的交易对手支付200万或更多的超大额的时候，银行A的手续费保持25元不变，而银行B和银行C则要收取40元甚至更多的手续费，这时又可以将银行A作为第一候选支付渠道。

S300，获取各支付渠道的服务状态，以及根据服务状态，从各支付渠道中确定第二候选支付渠道，其中，各支付渠道对应设置有交易指令队列。

服务状态包括以下至少之一：服务器可达性、服务可用性和服务及时性。

如图2所示，其中，获取各支付渠道的服务状态包括：

S310，基于心跳监测机制，确定各支付渠道对应的服务器的服务器可达性。

心跳监测机制：网络中的接收和发送数据都是使用操作系统中的SOCKET进行实现。但是如果此套接字已经断开，那发送数据和接收数据的时候就一定会有问题。这个就需要在系统中创建心跳机制。其实TCP中已经为我们实现了一个叫做心跳的机制。如果你设置了心跳，那TCP就会在一定的时间（比如你设置的是3秒钟）内发送你设置的次数的心跳（比如说2次），并且此信息不会影响你自己定义的协议。所谓“心跳”就是定时发送一个自定义的结构体（心跳包或心跳帧），让对方知道自己“在线”，以确保链接的有效性。

所谓的心跳包就是客户端定时发送简单的信息给服务器端告诉它我还在而已。代码就是每隔几分钟发送一个固定信息给服务端，服务端收到后回复一个固定信息如果服务端几分钟内没有收到客户端信息则视客户端断开。比如有些通信软件长时间不使用，要想知道它的状态是在线还是离线就需要心跳包，定时发包收包。发包方：可以是客户也可以是服务端，看哪边实现方便合理。一般是客户端。服务器也可以定时轮询发心跳下去。事实上这是为了保持长连接，至于这个包的内容，是没有什么特别规定的，不过一般都是很小的包，或者只包含包头的一个空包。

在本实施例中，向服务器定时发送心跳包，并判断服务器是否会基于心跳包回复一个固定信息，如操作人员收到服务器回复的固定信息，则说明服务器具有可达性，这时则进一步说明该服务器内的所有提供的服务皆可用。若操作人员没有收到服务器回复的固定信息，则说明服务器不具备可达性，这时则进一步说明该服务器内的所有提供的服务皆不可用。

S320，发送用于查询支付服务的服务状态的非交易指令至各支付渠道的服务器，根据各支付渠道的服务器对非交易指令的响应结果，确定各支付渠道的支付服务的服务可用性。

服务可用性主要用于监测银企前置服务是否可用，当向支付渠道的服务器发送用于查询支付服务的服务状态的非交易指令后，当各支付渠道的服务器对非交易指令的响应异常，则代表该银企前置服务整体不可用。

S330，获取各支付渠道对应的交易指令队列中排队的交易指令的数量，根据交易指令的数量，确定各支付渠道的服务及时性。

如图3所示，其中根据交易指令的数量，确定各支付渠道的服务及时性具体包括以下步骤：

S331，根据支付渠道的流量限制和交易指令的数量，确定支付渠道对应的交易指令队列中所有交易指令被处理完所需的总时长。

S332，判断总时长是否大于预设时长阈值。

S333，在总时长大于预设时长阈值的情况下，确定支付渠道未具备服务及时性

S334，在总时长不大于预设时长阈值的情况下，确定支付渠道具备服务及时性。

其中，预设时长是由人工进行设定的，如可以定为20S。当总时长大于预设时长阈值，确定该渠道内的交易指令队列拥堵，指令数量较多，因此未具备及时性。

进一步的，确定支付渠道具备服务及时性后，对所有支付渠道进行排序以确定更优先的支付渠道。

在本实施例中，具体的排序方法是对总时长进一步进行分级以形成多个时间范围，每个时间范围对应有一个优先级。

在另一个实施例中，对于不具备服务及时性的渠道，也可以对支付渠道进行排序以确定不具备服务及时性的渠道的优先级。

其中具体的优先级可以由高到低以此定义为“空闲”、“顺畅”、“忙碌”、“阻塞”等，并定义“空闲”、“顺畅”两个优先级具有服务及时性，“忙碌”、“阻塞”两个优先级不具备服务及时性。并分别指定几个时间范围，分别是0-8s，8-14s，14-20s，20s及以上，当支付渠道A的总时长在0-8s内时，其对应的优先级为空闲，且说明支付渠道A具备服务及时性；当支付渠道B的总时长为15s时，其对应的优先级为忙碌，且说明支付渠道B不具备服务及时性。

服务状态还包括服务稳定性，获取各支付渠道的服务状态还包括：

S340，获取各支付渠道的历史崩溃次数及崩溃发生时间，根据各支付渠道的历史崩溃次数及发生时间，确定各支付渠道的服务稳定性。

其中，各支付渠道的历史崩溃包括历史各支付渠道服务器的不可达和历史各支付渠道的服务不可用。

具体的，服务器监测服务器的不可达发生的次数和时间点，服务不可用发生的次数和时间点，并将这些崩溃信息储存在存储器内，在判断支付渠道的服务稳定性时，直接从存储器中提取这些信息。

S341，判断支付渠道的历史崩溃次数是否大于预设次数。

S342，在支付渠道的历史崩溃次数大于预设次数的情况下，确定支付渠道未具备服务稳定性。

S343，在支付渠道的历史崩溃次数小于预设次数的情况下，确定支付渠道具备服务稳定性。

S344，判断支付渠道的历史崩溃发生时间是否处于付款请求所在的时间段中。

其中，付款请求所在的时间段定义为付款请求发出的时间加上预设时间长度都得到的时间长度。例如，我们设置预设时间长度为2分钟，付款请求发出的时间为17：31，这时，付款请求所在的时间段为17：31-17：33，判断这段时间内是否有历史崩溃发生。

S345，若支付渠道的历史崩溃发生时间处于付款请求所在的时间段内，则确定支付渠道未具备服务稳定性；

S346，若支付渠道的历史崩溃发生时间不处于付款请求所在的时间段内，则确定支付渠道具备服务稳定性。

例如，付款请求所在的时间段为17：31-17：33，而获取到支付渠道A中，历史崩溃曾多次在17：32发生崩溃，历史崩溃时间位于付款请求所在的时间段内，这就说明支付渠道B不具备服务稳定性。

S400，根据第一候选支付渠道和第二候选支付渠道，确定目标支付渠道，生成与付款请求对应的目标交易指令，以及将目标交易指令存储到与目标支付渠道对应的交易指令队列中。

进一步的，交易指令队列用于存储相应的支付渠道将要处理的交易指令，以及在处于队列头部的交易指令被相应的支付渠道成功处理后删除该处于队列头部的交易指令。

例如，当有A、B、C三个付款请求进入支付渠道中时，A、B、C三个付款请求所对应的交易指令A1、B1、C1按照付款请求发出的顺序进入到交易指令队列中，此时交易指令A1位于交易指令队列的头部，当交易指令A1被相应的支付渠道成功处理后删除A1，这时交易指令B1处于交易指令队列的头部。

在第一候选支付渠道和第二候选支付渠道之间确定目标支付渠道选用确定交集的方式。举例来说，根据静态特征，从付款方和收款方之间的各支付渠道中确定出了A、D、H三条第一候选支付渠道，根据服务状态，从各支付渠道中确定B、F、D、H四条第二候选支付渠道，这时对第一候选支付渠道和第二候选支付渠道之间的支付渠道进行交集确定，明显的，支付渠道D、H为交集，故确定D、H为目标支付渠道。当然，目标支付渠道可以为多条也可以为一条。

还有一种情况，当第一候选支付渠道和第二候选支付渠道确定后，第一候选支付渠道和第二候选支付渠道之间并不存在有交集的支付渠道，这时可以有多种选择处理方式。

例如，在一些实施例中，当第一候选支付渠道和第二候选支付渠道之间不存在交集时，可以将付款请求进行保留，并在经过一定的缓冲时间后，重新发出付款请求，并在发出付款请求后重新确定第一候选支付渠道和第二候选支付渠道，并对第一候选支付渠道和第二候选支付渠道的交集进行确定。

在另外的一些实施例中，当第一候选支付渠道和第二候选支付渠道之间不存在交集时，可以对第一候选支付渠道和第二候选支付渠道的选定规则进行一定的改变。例如，当付款请求用于进口付汇时，得到A、B、C三条第一候选支付渠道，这三个渠道适用于进口付汇的付款请求，而通过支付渠道的服务状态，确定出了D、F两条第二候选支付渠道，这时第一候选支付渠道和第二候选支付渠道之间并不存在交集，这时可以将第一候选支付渠道的选定规则从“适用于进口付汇”更改为“可以用于进口付汇”，此使，第一候选支付渠道的选定范围就会随之增大，理论上第一候选支付渠道的数量也会增加，例如增加到A、B、C、D、F、G六条，这时就会出现D这一存在交集的候选支付渠道，这时便可以将支付渠道D作为目标支付渠道。

这时再次回到上述描述中说到的当第一候选支付渠道和第二候选支付渠道之间不存在交集时，可以对第一候选支付渠道和第二候选支付渠道的选定规则进行一定的改变。

当第一候选支付渠道确定后，第二候选支付渠道在选取时，必定会先选取服务及时性最好的支付渠道，换句话说就是选取状态为“空闲”的支付渠道作为第二候选支付渠道，而当第一候选支付渠道和第二候选支付渠道之间不存在交集时，可以将第二候选支付渠道的选取阈值从“空闲”转变为“顺畅”，以此扩大第二候选支付渠道的选取数量。

获取支付渠道相对应的交易指令队列的交易指令的数量通过以下方式：针对交易指令队列中的每一条交易指令进行监测，通过处理开始时间和结束时间判断每一笔的处理时长，并通过队列长度判断渠道内的挤压状态和需等待的时长，并通过前一交易指令是否交易超时等异常状态确定该支付渠道是否具有及时性。

在另一个实施例中，交易对手的交易特征还包括交易对手的评级，其中，根据第一候选支付渠道和第二候选支付渠道，确定目标支付渠道包括以下步骤：

S401，判断交易对手的评级是否大于预设的评级。

S402，若交易对手的评级大于预设的评级，则确定该交易对手为重要用户。

S403，若交易对手为重要用户，则剔除所有不具备服务稳定性的目标支付渠道。

为了保证重要用户支付的稳定性，当通过第一候选渠道和第二候选渠道确定目标支付渠道后，为了避免对重要用户付款而出现异常情况，对于渠道的稳定性要求需要做严格的把控，所以当交易对手的评级较高时，在保证渠道支付的快速性的前提下，需要进一步限定支付请求发出的时候，留下的目标支付渠道的历史崩溃次数和发生历史崩溃的时间点都要避开支付请求发出的时间。

当然，对于评级不高的普通用户，在多渠道皆空闲的情况下，对于渠道的稳定性也需要进行把控，但是出现渠道选择较少，同时支付的付款请求较多的情况下，对于普通用户的分配渠道的服务稳定性权重则可以进行一定的降低。

如图4所示，生成与付款请求相应的目标交易指令包括：

S410，根据付款方的账户特征，确定用于付款的银行账户。

S420，根据目标支付渠道的手续费规则和批次笔数限额，将多笔付款金额进行合并，或将单笔付款金额进行拆分，以使得手续费金额最低。

S430，根据用于付款的银行账户，生成一个或者多个目标交易指令，其中，每个目标交易指令对应于一个拆分或合并后的付款金额。

S440，在付款金额超出目标支付渠道的单笔限额的情况下，将付款金额拆分为多笔付款金额。

其中，付款方的账户特征包括以下至少之一：付款方各银行账户的可用余额、付款方各银行账户的监管约束。

根据手续费规则自动将付款金额拆分为多笔付款金额，使手续费金额最低，例如：支付渠道A在付款金额低于一万时收取手续费5元，此使有3笔两千元的款项交易给同一个收款方对产生15元的手续费，而将3笔两千元的款项进行合并得到1笔六千元的付款金额时，只会产生5元的手续费，节省了10元的手续费。

具体的，根据大/小额、超级网银的限额和关闭时间情况，优先选择可用支付系统，超过限额时自动拆分为不超过最大发限额的多笔付款金额进行付款，例如，每日17点大额支付关闭后，目标支付渠道只接受一万元以下的支付指令，这时如需要交易3万元，则需要将3万元拆分为3笔1万元的付款金额进行交易。

进一步的，当选取到目标支付渠道后，用户还可以根据自身需求选择交易方式系统。交易方式系统包括大小额支付系统、超级网银和同城票据交换。

大小额支付系统指大额支付系统和小额支付系统。其中，大额支付系统是以电子方式实时全额处理跨行及跨区支付业务的应用系统，大额支付系统指令随笔实时发送，全额清算资金；小额支付系统主要处理跨行同城、异城纸质凭证截留的借记支付业务以及金额在规定点以下的小额贷记支付业务，实现不同地区、不同银行营业点的资源共享。

其中大小额支付系统的支付机制为：大额支付系统在每个周末或法定节假日期间的首日运行，并执行特殊业务规则；业务受理时间为前一自然日20：30至次日8：30。

小额支付系统实行7*24小时连续不间断工作。每日16：00进行日切处理，即前一日16：00至次日16：00为小额支付系统的一个工作日，小额支付系统资金清算时间为大额支付系统的工作时间。小额支付系统日切后仍可以正常接收小额业务，部分小额业务不再纳入当日清算，自动纳入次日第一场轧差清算（遇到节假日顺延至节假日后的第一个工作日）。

超级网银是继大小额支付系统后建设的又一人民币跨行支付系统，该系统主要处理客户在线提交的零售业务，包括支付业务和跨行账户信息查询业务等。超级网银的接入机构不再仅限于银行，支付宝、财付通等第三方支付也可以进行接入。7*24小时实时到账，单笔上限5万元。这就相当于在非工作日非营业时间增加了一种大额支付系统特性的渠道了。只不过金额限制是跟小额系统一致的。超级网银限额较低，且可以做到实时到账。

同城票据交换是指统一城市（或区域）范围内，各商业银行之间将相互代收、代付的票据，定时、定点集中相互交换并清算资金存欠的方法。票据交换之后的应收款、应付款总额最终都必须通过中央银行集中清算交换才能实现轧差。

其中每条渠道可以使用哪种交易方式系统是前期预设好的，服务器可以通过前期的预设插入和后期对付款请求的实时分析以确定目标支付渠道内最优的交易方式系统。

如渠道A三种交易方式系统皆可以使用，且最迟到款日要求较低，在考虑手续费的情况下可以选用同城票据交换的方式，因为这种方式的手续费最低。

如渠道B只可以使用大小额支付系统和超级网银，这时如有一笔小于5万元的付款请求在16：00之后发出，且需要当日交易时，可以选用超级网银进行支付，而不适用小额支付系统，因为小额支付系统在当日16：00之后的付款请求都要在下一个清算工作日进行交易。

本申请实施例还公开了一种服务器，包括存储器和处理器，存储器中存储有计算机程序，处理器被设置为运行计算机程序以执行上述的智能支付渠道动态决策方法。

本申请实施例还公开了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述的智能支付渠道决策方法。

Claims (8)

1.一种支付渠道动态决策方法，其特征在于包括：

获取付款方的付款请求，其中，所述付款请求包括交易信息和收款方的标识信息；

响应于所述付款请求，获取静态特征，以及根据所述静态特征，从所述付款方和所述收款方之间的各支付渠道中确定第一候选支付渠道，其中，所述静态特征至少包括：所述收款方的交易特征，以及各所述支付渠道的付款限制及费率信息；

获取各所述支付渠道的服务状态，以及根据所述服务状态，从各所述支付渠道中确定第二候选支付渠道，所述服务状态包括服务稳定性，其中，获取各所述支付渠道的服务状态包括：

获取各所述支付渠道的历史崩溃次数及崩溃发生时间，根据各支付渠道的历史崩溃次数及发生时间，确定各支付渠道的服务稳定性，其中，各所述支付渠道的历史崩溃包括历史各所述支付渠道服务器的不可达和历史各所述支付渠道的服务不可用；

判断所述支付渠道的历史崩溃次数是否大于预设次数；

在所述支付渠道的历史崩溃次数大于所述预设次数的情况下，确定所述支付渠道未具备服务稳定性；

在所述支付渠道的历史崩溃次数小于所述预设次数的情况下，确定所述支付渠道具备服务稳定性；

判断所述支付渠道的历史崩溃发生时间是否处于付款请求所在的时间段内，其中，所述付款请求所在的时间段定义为所述付款请求发出的时间加上预设时间长度后得到的时间长度；

若所述支付渠道的历史崩溃发生时间处于所述付款请求所在的时间段内，则确定所述支付渠道未具备服务稳定性；

若所述支付渠道的历史崩溃发生时间不处于所述付款请求所在的时间段内，则确定所述支付渠道具备服务稳定性，

其中，各所述支付渠道对应设置有交易指令队列，所述交易指令队列用于存储相应的支付渠道将要处理的交易指令，以及在处于队列头部的交易指令被相应的支付渠道成功处理后删除该处于队列头部的交易指令；

根据所述第一候选支付渠道和所述第二候选支付渠道，确定目标支付渠道，生成与所述付款请求对应的目标交易指令，以及将所述目标交易指令存储到与所述目标支付渠道对应的交易指令队列中；

其中，所述交易对手的交易特征还包括交易对手的评级；

判断所述交易对手的评级是否大于预设的评级；

若所述交易对手的评级大于预设的评级，则确定该交易对手为重要用户；

若所述交易对手为重要用户，则剔除所有不具备所述服务稳定性的目标支付渠道。

2.根据权利要求1所述的一种支付渠道动态决策方法，其特征在于，所述服务状态包括以下至少之一：服务器可达性、服务可用性和服务及时性；获取各所述支付渠道的服务状态包括：

基于心跳监测机制，确定各所述支付渠道对应的服务器的服务器可达性；

发送用于查询支付服务的服务状态的非交易指令至各所述支付渠道的服务器，根据各所述支付渠道的服务器对所述非交易指令的响应结果，确定各所述支付渠道的支付服务的服务可用性；

获取各所述支付渠道对应的交易指令队列中排队的交易指令的数量，根据所述交易指令的数量，确定各所述支付渠道的服务及时性。

3.根据权利要求2所述的一种支付渠道动态决策方法，其特征在于，根据所述交易指令的数量，确定各所述支付渠道的服务及时性包括：

根据所述支付渠道的流量限制和所述交易指令的数量，确定所述支付渠道对应的交易指令队列中所有交易指令被处理完所需的总时长；

判断所述总时长是否大于预设时长阈值；

在所述总时长大于所述预设时长阈值的情况下，确定所述支付渠道未具备服务及时性；

在所述总时长不大于所述预设时长阈值的情况下，确定所述支付渠道具备服务及时性。

4.根据权利要求1所述的一种支付渠道动态决策方法，其特征在于，所述收款方的交易特征包括以下至少之一：付款金额、最迟付款日、银行账户；所述支付渠道的付款限制及费率信息包括以下至少之一：单笔限额、批次笔数限额、服务时间范围、手续费规则；其中，根据所述静态特征，从所述付款方和所述收款方之间的各支付渠道中确定第一候选支付渠道包括：

根据所述收款方的交易特征和各所述支付渠道的单笔限额、批次笔数限额和服务时间范围，从各所述支付渠道中确定所述第一候选支付渠道；和/或，

根据所述收款方的银行账户确定收款方银行，确定各所述支付渠道中与所述收款方银行对应的支付渠道为所述第一候选支付渠道；和/或，

根据各所述支付渠道的手续费规则、所述付款金额，确定采用各所述支付渠道付款的手续费金额，根据所述手续费金额确定所述第一候选支付渠道。

5.根据权利要求1所述的一种支付渠道动态决策方法，其特征在于，生成与所述付款请求对应的目标交易指令包括：

根据所述付款方的账户特征，确定用于付款的银行账户，其中，所述付款方的账户特征包括以下至少之一：所述付款方各银行账户的可用余额、所述付款方各银行账户的监管约束；

根据所述目标支付渠道的手续费规则和批次笔数限额，将多笔付款金额进行合并，或将单笔付款金额进行拆分，以使得手续费金额最低；

根据用于付款的银行账户，生成一个或者多个所述目标交易指令，其中，每个目标交易指令对应于一个拆分或合并后的付款金额。

6.根据权利要求5所述的一种支付渠道动态决策方法，其特征在于，生成与所述付款请求对应的目标交易指令还包括：

在付款金额超出所述目标支付渠道的单笔限额的情况下，将所述付款金额拆分为多笔付款金额。

7.一种服务器，其特征在于：包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行权利要求1至6中的任一项所述的支付渠道动态决策方法。

8.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至6中任一项所述的支付渠道动态决策方法。

Images