[0001] 本发明涉及支付路由动态切换与维护技术领域，具体为一种多维度收款路由动态渠道调度方法。

[0002] 近年来，保险公司的业务部门、产品线均着力拓展基于互联网的销售模式，对于新场景下收款功能的需求量迅速膨胀，主要表现为：线上、移动展业、手机端等多样化的收款需求。电子商务的迅猛发展带来客户购买习惯的巨大变化，而客户消费习惯的变化对保险公司在线销售场景下在线缴费功能的便捷性、多样性提出更高要求，例如，有些用户喜欢用微信，有些用户喜欢用支付宝，有些用户喜欢用云闪付，有些用户喜欢用数字人民币等等。与此同时，为了能够提供7 24小时不间断的收款服务，就必须要有多渠道进行备份，当一个渠道出问题后，要实现渠道路由的智能切换，由一个渠道自动切换到另一个渠道，以免中断客户的支付动作，影响操作体验，并且，还需要实时监控各支付渠道可不可用，以免不可用的支付渠道被路由到，影响支付流程的顺利进行。

[0003] 现有技术通常根据渠道交易数量和时长与阈值的比值直接判断渠道服务及时性，或根据渠道的历史失败次数判定渠道可用性状态，或将包含前述的渠道历史交易数据构建预测模型进行渠道支付成功率的预测，从而选择出最优渠道；然而，现有技术中根据单一比值判断渠道服务及时性与可用性无法保障判断结果的可靠性和准确性，首先，阈值的设定存在绝对化，没有考虑不同时期用户需求的变化趋势对渠道造成的影响，导致无法自适应的调节阈值从而客观的评价渠道状态；其次，渠道的失败因素很多，根据崩溃总量决定渠道可用性状态存在误差，比如用户自身原因输入错误信息导致支付任务失败，以此判断渠道不可用是不合理的，影响了正常交易运营；同时，使用历史交易数据训练预测模型会存在如下问题：样本的划分、样本数据质量以及模型参数均影响着预测模型的准确性以及效率，数据质量一般会降低模型准确性，而要提高数据样本又会计算量降低了效率且无法保障高质量数据，导致渠道选择效率与准确率二者无法兼顾，影响整体运营效率且影响用户体验感。综上所述，现有技术中渠道切换策略相对固化且单一、不灵活，不能多维度动态分析路由以实现路由自由切换的同时对渠道状态进行动态调节、以确保路由效率以及节约计算资源，例如，不能根据渠道的服务时间、服务限额、历史成功率、风险等级以及拥堵程度等多维度实现动态路由切换并禁止不可用的渠道参与新的路由；此外，不能做到用户无感，例如，当一个渠道出问题后，通常需要用户再次点击或重新加载与选择其他支付通道；导致支付路由切换效率低，支付渠道选择可靠性差，用户体验差。

[0004] 中国专利，公开号：CN114581094A，公开日：2022年6月3日，公开了一种支付渠道动态决策方法、服务器及计算机可读介质，通过获取付款方的付款请求；响应于付款请求，获取静态特征，以及根据静态特征，从付款方和收款方之间的各支付渠道中确定第一候选支付渠道；获取各支付渠道的服务状态，以及根据服务状态，从各支付渠道中确定第二候选支付渠道；根据第一候选支付渠道和第二候选支付渠道，确定目标支付渠道，生成与付款请求对应的目标交易指令。该方案没有考虑支付渠道的维护时间、拥堵状态以及当前时间支付渠道的峰期情况，并且只是单纯的根据支付渠道的历史崩溃发生时间是否处于付款请求所在的时间段内进而判断历史崩溃次数是否超过阈值来判断支付渠道的可用性，存在偶发性错误、判断条件不准确判断结果不可靠，即网络信号延迟与拥堵等情况下导致支付失败，但并不代表渠道不可用；此外，该方案无法根据支付渠道的失败支付情况对其可用性状态进行动态调节，会导致不可用的渠道会参与下一次的路由，增加路由开销占用额外的计算资源。

[0028] 为使本发明的目的、技术方案以及优点更加清楚明白，下面结合附图和实施例对本发明作进一步详细说明，应当理解的是，此处所描述的具体实施方式仅是本发明的一种最佳实施例，仅用以解释本发明，并不限定本发明的保护范围，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

[0029] 实施例1：如图1所示，一种多维度收款路由动态渠道调度方法，包括步骤S1‑S5，其中：S1、响应于支付方式结合支付环境状态进行一次路由选择，确定预备支付渠道，其中，支付环境状态至少包括：支付渠道可用性状态、渠道升级维护状态以及支付渠道拥堵状态。

[0030] 具体地，如图2和图3所示，S1包括如下子步骤：根据用户选择的支付方式获取相应的全部支付渠道，判断各支付渠道是否处于渠道升级维护时间内，对当前处于渠道升级维护状态的支付渠道进行一次过滤；
获取支付渠道的历史交易数据以及实时支付请求量，确定当前时间支付渠道的时域负载；
基于时域负载判断支付渠道状态的可用性，筛选出渠道状态为可用的支付渠道；
实时计算支付渠道的拥堵率判断当前时间支付渠道的是否拥堵，若是，则重新执行S1；若否，则将支付渠道作为预备支付渠道。

[0031] 进一步地，第三方渠道商进行支付渠道维护升级时，此时该支付渠道是暂停服务的，即从维护开始时间到结束时间这个区间渠道不能被路由到，只有等过了这段时间，渠道自动变为可用；筛选支付渠道的可用性状态、判断支付渠道是否处于服务时间，两个步骤之间的顺序是可以调换的，用户可以根据自身需求自适应调整两个步骤之间的顺序；例如，对状态可用的支付渠道进行服务时间的筛选，将当前处于维护升级时间段的支付渠道进行屏蔽，可以减小系统计算量，避免因暂停服务导致交易失败影响用户支付流程，耽误支付完成时间；例如，先进行渠道维护升级时间的筛选，再进行渠道可用性状态的判断，例如不在维护升级时间的渠道刚好状态不可用，如此还是会产生计算资源的开销，因此，顺序是可以动态调整的；但是，判断渠道拥堵需要在判断渠道状态和渠道维护升级时间之后。

[0032] 此外，在一次路由选择中，还可以进行支付路由最基本的成本筛选，考虑支付渠道的成本，适用于成本优先的支付场景，需要制定成本优先策略，可以通过相关寻优算法将成本最低作为目标获得最优解，即可获得成本最低的支付渠道。

[0033] 具体地，获取支付渠道的历史交易数据以及实时支付请求量，确定当前时间支付渠道的时段负载，包括如下子步骤：基于支付渠道的日志文件调取历史交易数据，根据历史交易数据划分出若干个支付渠道在自然日期二十四小时内路由频率的第一时段负载，包括高峰期、平峰期以及低峰期；
计算若干第一时段负载中各峰期的运营特征统计值以及特征标准差，根据运营特征统计值结合特征标准差确定各峰期的峰期阈值；
将支付渠道的支付队列中实时的第一支付请求数与峰期阈值的范围进行匹配，确定支付渠道在当前时间范围内的峰期类型，并将峰期类型作为支付渠道的时域负载。

[0034] 作为一种实施方式，调取支付渠道的历史交易数据，例如，调取过去五天内的交易数据，获取每天相同时段处理的支付请求数，以及请求队列中增加的支付请求数，然后来综合划分支付渠道在一天24小时中各时段属于什么峰期（高峰期、低峰期、平峰期）；或，每天相同时段内处理的支付请求数的平均处理时间，以平均处理时间作为处理效率来区分峰期类型；再然后，以过去五天内相同时段的支付请求数或支付请求数的平均处理时间，计算特征均值和标准差，以特征均值和标准差来设置各峰期的支付请求阈值（峰期阈值），例如，特征均值+标准差，或特征均值‑标准差，得到一个支付请求阈值；实时获取支付渠道的支付队列中的请求数量（待处理的请求量）和峰期阈值比较，在相应峰期阈值的范围内，就表示该支付渠道当前处于相应峰期。例如，高峰期阈值为500笔支付请求，范围是上下浮动20笔，当前支付渠道的支付队列中有490笔，则认为当前支付渠道当前时间处于高峰期，判断状态是否可用或是否拥堵时，时间就要更短。

[0035] 具体地，判断支付渠道状态的可用性，包括如下子步骤：提取支付渠道对应的统计渠道队列中的第一个失败记录数，当第一个失败记录数的记录时间处于当前时刻相邻的历史时区时，统计出统计渠道队列中的全部失败记录数，获取第一失败记录统计值；
其中，根据支付渠道的时域负载动态调整历史时区；
将第一失败记录统计值与失败统计阈值进行比对，若第一失败记录统计值大于失败统计阈值，则支付渠道异常，支付渠道状态为不可用。

[0036] 具体地，计算支付渠道的拥堵率判断当前时间支付渠道的是否拥堵，包括如下子步骤：基于时域负载相对应的历史交易数据评估并确定支付渠道在单位时间的预处理支付请求数；
统计支付渠道在单位时间内实际处理的第二支付请求数，根据预处理支付请求数与第二支付请求数计算得到拥堵率；
当拥堵率大于等于拥堵限值且支付队列中实时的第一支付请求数增加，则支付渠道发生拥堵。

[0037] 进一步地，拥堵率计算公式如下：拥堵率 =（单位时间内预处理的笔数‑单位时间内实际处理的笔数）/ 单位时间内预处理的笔数 100%；
如果实际处理的笔数大于等于预处理的笔数，则说明渠道处理很快，效率高，未发生拥堵；如果拥堵率的值持续变大，且支付队列里的记录数越多，说明当前渠道很拥堵。

[0038] 通过计算过去一段时间内的支付请求处理效率，可以精准预测渠道当前的处理效率，进一步精确的判断支付渠道是否存在拥堵的可能。其中，单位时间内的预处理支付请求数主要根据当前时间支付渠道的峰期类型来进行预设，使得预设值更加可靠、合理，进而使得计算出来的拥堵率更准确。例如，当前时间支付渠道处于高峰期，那么此时实时支付请求量就会大量增加，相比低峰期相同的时间内处理的支付请求量也会增加，因此高峰期的预处理的请求数就需要比低峰期的预处理请求数高，实现实际处理量达成平衡，使得计算出来的结果可靠和准确；消除了支付渠道存在的偶发性误差倒是状态误判。此外，计算支付渠道历史峰期，实现对当支付渠道在当前时间内峰期类型的预测，从而来设定定时器扫描渠道统计队列的时间，提高对不同时期支付渠道状态可用性判断的精确性，例如，高峰期交易量大，所以要在更短时间内判断出渠道的问题，以将影响的交易业务控制在最小范围。

[0039] 传统的渠道拥堵判断方法，如图4所示，从向用户端发送渠道开始到渠道返回结果所花的时间，若连续N笔交易都超过一定时间（如5秒），同时支付队列里的请求达到50笔，则认为渠道拥堵。具体过程如下：在发送渠道前，计数器加1，然后记录发起时间（这里记为时间A），其中，计数器用于支付队列记录该渠道所接收的支付请求，每发送一次该渠道，表示有一次支付请求，计数器就加1；
渠道返回结果后，计数器减1，然后记录结束时间（这里记为时间B），其中，计数器减1表示完成一次支付请求，支付队列的支付请求对应减1；
根据实际业务需要设置标准时间阈值为5秒，设置支付队列的最大请求承载量为
50，若B‑A超过5秒，且计数器的值大于50，则认为该渠道存在拥堵；
由于用户自身的网络连接条件以及支付渠道的网络连接条件都可能会有偶发性延迟，因此，传统渠道拥堵判断方式，即B‑A超过5秒来判断渠道拥堵不够准确，会因网络因素造成误判。因此，本实施例提出的计算支付渠道拥堵率，对接下来时间里预处理的情况做了准确预测，更够直观的了解当前渠道的支付请求负载情况和处理进度，考虑了当前正在处理的支付请求数量，以及考虑支队队列中的支付请求数量，如果处理中的支付请求数据量有变多的趋势，同时每一笔处理的时间又在变长，这就说明渠道已拥堵。通过多重因素综合判断拥堵情况，确保了判断结果的精准性和可靠性。

[0040] S2、基于支付渠道的风险因子对预备支付渠道进行二次路由选择，确定目标支付渠道。

[0041] 具体地，S2包括如下子步骤：基于风险因子的风险规则手册对预备支付渠道进行渠道风险稽查，根据稽查结果对预备支付渠道进行二次过滤，获得支付主渠道，并将主渠道作为目标支付渠道，完成二次路由选择；
其中，风险因子至少包括支付渠道的监管处罚事件、重复收款事件、服务类事件。

[0042] 本实施例中，监管处罚事件表示该支付渠道对应的第三方渠道商受监管机构处罚，未遵守支付机构监督管理条例，例如违规留存客户资金，泄露客户的支付账户信息等；重复收款事件表示该支付渠道出现过重复收款的事件；服务类事件表示该支付渠道对应的第三方渠道商问题响应和处理不及时，例如客户经理更换等引起的响应变慢等问题。渠道风险事件因子可根据实际业务场景进行计算，例如，以一个季度为计算时间，在一个季度内，一旦有监管处罚事件发生，或有三起重复收款事件，或有五起问题响应不及时，给业务带来影响的服务类事件，则对该支付渠道做无效处理或直接弃用该渠道，以确保支付环境的安全性，减少支付过程中可能发生的风险。

[0043] S3、用户端响应于目标支付渠道执行支付动作。

[0044] 进一步地，一次路由选择（进行第一层路由逻辑）是必须的，二次路由选择（进行第二层路由逻辑）是可选的，但从安全角度考虑，为了减少风险，如果渠道最近有很大的风险事件已发生，则认为该渠道是不能被路由到的，因此，渠道风险的筛选也是必须要考虑的；通常按照一层路由逻辑到二层路由逻辑的顺序来进行最优支付渠道的切换，如图5所示，也可根据实际业务场景与支付业务类型合理的、自适应的安排一层路由逻辑与二层路由逻辑的顺序。

[0045] S4、基于目标支付渠道返回的支付失败结果，分析并获取支付失败原因，根据支付失败原因记录并更新目标支付渠道的支付失败统计信息。

[0046] 具体地，S4包括如下子步骤：基于用户支付信息进行失败支付结果的失败原因分析；
其中，若是用户提供的支付信息不匹配或/和信息输入错误引起目标支付渠道支付失败，则判定为用户信息类原因；若用户提供的支付信息准确，则判定为非用户信息类原因，用户支付信息至少包括：银行卡账户信息、户名信息、身份证信息；
为目标支付渠道分配用于存储支付失败记录信息的统计渠道队列，当目标支付渠道返回一笔数据支付失败的信息时，将相应的支付失败信息写入统计渠道队列。

[0047] 本实施例中，通过分析目标支付渠道返回的支付结果，以根据支付结果实时统计该支付渠道的支付失败情况，为判断该支付渠道后续是否能继续进行正常工作提供数据支撑；在判断支付失败原因时，先对用户信息类原因进行排查，例如，根据比对用户的账户信息，包括卡号与户名、身份证号是否匹配、账户余额是否充足、用户输入的支付密码是否正确等信息判断本次支付失败是属于用户信息类还是非用户信息类，若是用户信息类原因导致的支付渠道支付失败，则无需重新路由新的支付渠道，提示用户错误信息让用户重新输出正确的信息即可完成本次支付请求，无需切换支付渠道，因为这些错误原因无论路由到哪一个支付渠道，同样都会失败的；若是非用户信息类原因，例如网络错误、系统错误等，则需要路由并切换其他支付渠道，以确保支付任务的顺利进行，例如，A渠道的系统错误导致失败，那就通过路由换到B渠道再次发起请求，此时B就可能会成功。因此，通过渠道返回结果，区分出客户类/非客户类原因失败，再次路由，能提高系统间交互的效率，以及系统间一次交互的成功率，也可以减少人工操作，节省人工工作量。

[0048] S5、基于支付失败统计信息判断目标支付渠道是否异常，根据异常结果对目标支付渠道进行禁用状态决策，对目标支付渠道是否投入新一轮路由选择进行动态管理，并重新执行S1，切换其他支付渠道完成支付任务。

[0049] 具体地，S5包括如下子步骤：A1、定时扫描统计渠道队列中的支付失败信息并提取第一个失败记录数；
A2、基于第一个失败记录数的时间信息与当前时间的差判断第一个失败记录数是否超出统计范围，若是，则将第一个失败记录数进行移除，重新执行A1；若否，则统计出统计渠道队列中所有的支付失败记录数，获得第二失败记录统计值；
A3、将第二失败记录统计值与失败统计阈值进行比对，若第二失败记录统计值小于失败统计阈值，则目标支付渠道状态正常，将目标支付通道添加至新一轮渠道路由列表；
若第二失败记录统计值大于等于失败统计阈值，则将目标支付渠道的可用状态重置为禁用状态，表征目标支付渠道异常，并清空其相对应的统计渠道队列，同步发出支付渠道异常预警信息。

[0050] 作为一种实施方式，如图6所示，S5具体步骤如下：B1、给每一个渠道分配一个队列（如有a，b，c，d 共4个渠道，对应分配a1，b1，c1，d1 共4个渠道统计队列），当a渠道发生非客户类原因失败时，就往a1队列写入消息（记录当时失败的时间，精确到毫秒），其它渠道类似；
B2、针对每一个队列都有对应的定时器，可定时扫描统计渠道队列里的失败记录数及失败发生时间；定时器可做到秒级统计，通常为1分种统计一次即可；
B3、定时器统计队列里的错误记录时，先判断排在第一位的错误时间与当前时间的差是不是超过预先设定的值T0，若超出了，则从队列里移除，继续下一个判断，直到找到一个没有超出的，然后进入B4；
B4、统计队列里的失败记录数，与失败统计阈值进行比对，以判断是否需要重置支付渠道的状态，以及是否清空队列；
其中，若失败记录数小于失败统计阈值，则不需要重置支付渠道的状态，等下一周期的统计；
若失败记录数大于等于失败统计阈值，则将支付渠道置为“禁用”状态，同时清空队列，并发出预警信息，通过页面告知相关工作人员。

[0051] 可以理解的是，如果失败记录数大于等于失败统计阈值不清空队列，在定时器统计时，队列里的第一个失败时间肯定会超过T0值，还是会被一个个移除，如此一来，增加了系统计算负荷，浪费了计算资源，因此将支付渠道的状态置为不可用时，一次性清空队列，以防止旧的、可能已经过时的数据影响对支付通道当前状态的判断，以确保在重新启用渠道时，系统是基于最新的、准确的数据来做出决策；同时，清除失败次数统计意味着在渠道重新启用后，它将从一个初始的状态开始，不再受到之前失败次数的影响，可以重新开始收集新的数据，有助于公平地评估渠道的性能和稳定性，从而更准确地监控支付渠道的运行状况，确保及时发现潜在的问题并采取相应的措施。

[0052] 进一步地，支付渠道状态重置为不可用后，可以恢复至可用状态，恢复方式包括但不限于：第一种：纯人工操作；
第二种：自动恢复；系统通过探针原理，定时向渠道发起查询，以验证接口是否已恢复；
可用根据实际业务场景自适应选择恢复方式，由于第二种方式只能是通过探针原理，而且只能是调查询接口（查询接口不会产生新的交易），而渠道商那边查询和收款接口是分开，查询正常并不代表着收款正常，因此自动恢复方式具有一定的不准确性，因此，可用选择纯人工操作来重启支付渠道的可用状态，通过人工确认后再启用，更严谨，更安全，对业务的影响最小。

[0053] 进一步地，执行S3之前还包括：当二次路由选择后存在多个支付渠道满足执行支付任务的条件时，则进行目标支付渠道的三次选择，三次选择至少包括：
基于支付渠道类型与渠道成本制定渠道顺序策略，通过渠道顺序策略确定目标支付渠道；
或，
基于随机算法制定支付渠道的随机选择策略，通过随机选择策略确定目标支付渠道。

[0054] 具体地，制定渠道顺序策略包括：通过预先设置的顺序规则，为支付渠道进行顺序号编码或其他有序的标签标识，然后按照排序和选择约定优先选择其中一个支付渠道作为目标支付渠道。例如，顺序规则为按照第三方渠道商名称的首字母进行排序，首字母相同的以第二位字母排序，依此类推，选择约定为顺序号最小的、最大的或其他位置的支付渠道，以从多个满足要求的支付渠道中选择一个主渠道执行支付任务。

[0055] 具体地，随机选择策略包括：第1步：统计出满足条件的渠道一共有多少个，记为N；
第2步：生成1‑N的随机整数，记为R，R= random.nextInt(N) + 1；
第3步：取第R个渠道。

[0056] 进一步地，一种多维度收款路由动态渠道调度方法还包括：为每条支付渠道规划一条备用支付路线，备用支付路线对支付请求的执行程序与其对应的主支付渠道相同；
当支付渠道发生拥堵时，启用其备用支付路线，将支付渠道支付队列中的支付请求发送至备用支付路线执行支付任务。

[0057] 当支付渠道发生拥堵时，要暂停对该支付渠道发送支付请求，需等待渠道将支付队列中的支付请求处理到一定值（支付队列中的支付请求小于请求承载量）后，则可以继续往该渠道发送支付请求。

[0058] 实施例的有益效果：通过一次路由选择与二次路由选择，实现了从支付渠道状态、支付渠道拥堵情况、渠道维护时间、渠道的风险事故等多维度动态监控各支付渠道的实时运行情况，以便于在某一个支付渠道出问题后，可以快速且准确的自动切换到最优支付通道，同时，根据支付渠道的失败支付情况动态调节其可用性状态，避免不可用的问题渠道未恢复正常之前再次被路由到，进而影响业务的正常交易，确保将用户损伤降低最小，保证对外的用户体验一致性，实现用户无感，增强了用户体验感；降低人工操作成本，显著提高了支付渠道切换效率和渠道选择的可靠性与安全性，提高运营工作效率。其中，一次路由选择可以过滤掉渠道状态不可用的以及渠道不在服务时间的，然后，通过判断过滤后的渠道是否拥堵，能够有效避免向拥堵的渠道发送渠道请求，从而增加渠道承载负荷、延长渠道失效时长的问题，提高了支付渠道的有效利用率；再通过二次路由选择，排除存在风险的支付渠道实现最优的渠道选择，确定本次支付任务最终的支付渠道；最后，根据目标支付渠道返回的失败支付结果，计算并动态调节该支付渠道的可用性状态，有助于第一时间将异常渠道进行无效处理（这里为将该渠道的可用性状态重置为禁用），保障支付业务的顺利进行，保障第三方渠道商与用户的权益。通过备用通道来分解主支付渠道的处理负载，有效避免支付渠道的长时间拥堵，确保主支付渠道能够维持正常运行。

[0059] 以上的具体实施方式为本发明的较佳实施方式，非以此限定本发明的具体实施范围，本发明的范围包括并不限于本具体实施方式，凡依照本发明之形状、结构、方法所作的等效变化均在本发明的保护范围内。