CN112258167A - 支付平台侧的可动态切换支付路由的方法和支付平台系统 - Google Patents

Abstract

本公开涉及一种支付平台侧的可动态切换支付路由的方案，包括：（1）接收来自用户的应用的交易请求；（2）根据所述交易请求从数据库读取路由配置信息；（3）根据所述路由配置信息判断是否存在可用的银行通道，其中：如果存在可用的银行通道，则选择所述可用的银行通道之一来将所述交易请求转发给银行；将交易结果存储在所述数据库中并转发给监听服务模块；所述监听服务模块根据所述交易结果判断是否需要切换至备用银行通道，其中：如果确定需要切换至备用银行通道，则将所选银行通道标记为“不可用”，并返回步骤（3）判断是否还存在其他可用的银行通道；如果确定不需要切换至备用银行通道，则返回到步骤（1）接收下一交易请求。

Description

支付平台侧的可动态切换支付路由的方法和支付平台系统

技术领域

本公开涉及支付通道的切换，尤其是涉及一种在支付平台侧的可动态切换支付路由的方法和相应的支付平台系统。

背景技术

随着互联网通信和安全技术的迅猛发展，传统金融机构与互联网企业利用互联网技术、信息通信和安全技术实现了一种集资金融通、支付、投资和信息中介服务于一体的新型金融业务模式，该模式可被称为“互联网金融”。互联网金融不是互联网和金融业的简单结合，而是在实现安全、移动等网络技术水平上，被用户熟悉接受后（尤其是对电子商务的接受），自然而然为适应新的需求而产生的新模式及新业务。是传统金融行业与互联网技术相结合的新兴领域。

而在“互联网金融”发展的过程中，第三方支付无疑是其中亮眼的明星。“第三方支付”是指具备一定实力和信誉保障的非银行机构，借助通信、计算机和信息安全技术，采用与各大银行签约的方式，在用户与银行支付结算系统间建立连接的电子支付模式。第三方支付已不仅仅局限于最初的互联网支付，而是成为线上线下全面覆盖，应用场景更为丰富的综合支付工具。由于第三方支付的交易便捷性（可同时对接多个银行的支付通道进行交易结算）、高安全性和高信用（支付牌照严格审批并且大多依托大型门户网站），因此，越来越受到电商和广大消费者的喜爱。

但同时，这种第三方支付平台也存在各种缺陷。其中之一就是支付平台只能被动与银行支付通道对接，当银行通道发生问题无法进行及时结算（例如银行服务器故障、升级等情况）时，缺乏相应的应对手段。例如，当某个银行通道出现问题后，支付平台上的大量通过该通道的用户交易就会被影响。就目前情况而言，支付平台在接到大量交易失败导致的用户投诉之前，平台难以主动发现所述通道存在的问题，更不用说及时切换到备用支付通道来保证交易结算的正常进行。

发明内容

本公开提供了一种在支付平台侧配置的可动态切换支付路由的方法和相应的支付平台系统。

根据本公开的一个方面，提供了一种支付平台侧的可动态切换支付路由的方法，包括：（1）接收来自用户的应用的交易请求；（2）根据所述交易请求从数据库读取路由配置信息；（3）根据所述路由配置信息判断是否存在可用的银行通道，其中：如果存在可用的银行通道，则选择所述可用的银行通道之一来将所述交易请求转发给银行；将交易结果存储在所述数据库中并转发给监听服务模块；所述监听服务模块根据所述交易结果判断是否需要切换至备用银行通道，其中：如果确定需要切换至备用银行通道，则将所选银行通道标记为“不可用”，并返回步骤（3）判断是否还存在其他可用的银行通道；如果确定不需要切换至备用银行通道，则返回到步骤（1）接收下一交易请求；如果不存在可用的银行通道，则告知所述用户支付失败。

根据本公开的另一个方面，提供了一种支付平台侧的可动态切换支付路由的支付平台系统，包括：数据库，被配置为用于存储包含路由配置信息的路由配置表，所述路由配置信息包括了能够与所述支付平台对接的银行和与每个银行相关联的银行通道；路由系统，被配置为：接收来自用户的应用的交易请求；根据所述交易请求从所述数据库中读取所述路由配置信息；根据所述路由配置信息判断是否存在可用的银行通道，其中：如果存在可用的银行通道，则选择所述可用的银行通道之一来将所述交易请求转发给银行；将交易结果存储在所述数据库中并转发给监听服务模块；如果不存在可用的银行通道，则告知所述用户支付失败；所述监听服务模块，被配置为：根据所述交易结果判断是否需要切换至备用银行通道，其中：如果确定需要切换至备用银行通道，则通知所述路由系统将所选银行通道标记为“不可用”并再次判断是否还存在其他可用的银行通道；如果确定不需要切换至备用银行通道，则通知所述路由系统接收下一交易请求。

提供本概述以便以简化的形式介绍以下在详细描述中进一步描述的一些概念。本概述并不旨在标识所要求保护主题的关键特征或必要特征，也不旨在用于限制所要求保护主题的范围。

附图说明

为了描述可获得本发明的上述和其它优点和特征的方式，将通过参考附图中示出的本发明的具体实施例来呈现以上简要描述的本发明的更具体描述。可以理解，这些附图只描绘了本发明的各典型实施例，并且因此不被认为是对其范围的限制，将通过使用附图并利用附加特征和细节来描述和解释本发明，在附图中：

图1示出了根据本公开的一个实施例的一种在支付平台侧使用的可动态切换支付路由的系统的示意性系统结构图。

图2示出了根据本公开的一个实施例的一种在支付平台侧使用的用于动态切换支付路由的方法的示意性流程图。

具体实施方式

为了克服支付平台在面对银行通道崩溃时的不利处境，本公开针对支付平台侧的支付流程和支付系统进行了优化，为它们提供了在发生通道崩溃的情况下能够动态切换支付通道的机制。具体而言，利用所述方案能够及时主动地监控银行支付通道的使用情况，并在当前支付通道发生问题时，智能选择其他支付通道以实现对银行通道路由选择的主动性和灵活性，同时也提高了支付公司的交易活动的稳定性、可靠性，并且改善了用户的交易体验。

在正式描述本公开的方案之前，先就所述方案可能涉及到的几个基本术语进行解释：

消息队列：是一种存放消息的容器，当我们需要使用消息的时候可以取出消息供自己使用。消息队列是分布式系统中重要的组件，使用消息队列主要是为了通过异步处理提高系统性能和削峰、降低系统耦合性。目前使用较多的消息队列有RabbitMQ，Kafka，RocketMQ等。

DUBBO服务：是一种微服务架构，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。具体而言，dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现，使得应用可通过高性能的 RPC 实现服务的输出和输入功能。本公开中使用分布式应用程序协调服务（Zookeeper）作为服务发现与注册中心。但应该理解，所述dubbo服务和Zookeeper仅仅是出于说明的目的被描述，并非进行限制。实际上，基于dubbo服务的其他架构或者其他类型的微服务架构也可以被应用于本公开的方案。

应该理解的是，尽管在本公开的各实施例中主要基于消息队列和dubbo服务来描述技术方案，但所述消息队列和dubbo服务仅仅是可以实现本公开的方案的示例之一，其他任何可以实现本公开方案所述的方法、模块和步骤的技术也属于本公开的保护范畴。

首先，如图1所示，示出了本公开的一个实施例的一种在支付平台侧使用的可动态切换支付路由的系统的示意性系统结构图。

如图所示，系统100可以分成三个部分，即在用户处的应用部分、在支付平台侧的支付平台系统以及在银行侧的银行通道部分。

首先，在用户侧，用户可以通过使用其用户设备（例如智能手机、PDA、笔记本、平板、个人计算机、游戏机等等）上安装的各种涉及支付的应用101(1)、101(2)、……、101n)（例如电子商务APP、金融APP、购物APP等等）中的一个应用来发起交易请求。需要注意的是，尽管在此以“应用”来统称在用户设备处发起交易的软件，但技术人员应该理解，所述应用不仅仅指安装在用户设备上的各种软件或APP，实际上它还可以包括例如用户通过互联网来发起交易的网站、插件等网络部件。用户可以利用所述各种应用来将要求交易的请求通过网络发送给支付平台侧的支付平台系统。所述网络可以包括互联网、WLAN、蜂窝网络等等能够联网的技术。

而在支付平台侧，可以提供一个支付平台系统，该系统主要包括路由系统（集群）103、监听服务模块105、数据库107以及预警服务模块111。它们之间可以通过有线或无线的方式被连接起来以进行彼此通信。

路由系统（集群）103可以由一个路由系统，或多个路由系统的集群构成。使用多个路由系统的集群的目的在于，当在某些特定时刻支付平台系统接收到大量交易请求时，能够将所述交易请求分流到各个路由系统上以分散负载并加快处理速度。例如，在节假日或购物促销的日子里，每一秒可能有成千上万甚至更多笔交易请求被同时发送给支付平台系统，如果由一个路由系统同时处理那么多交易请求，无疑会给路由系统带来极大的负担，甚至可能导致平台崩溃。而使用路由系统集群的话，支付平台系统就能将所述交易请求分派到各个路由系统中以进行分流，从而极大地减轻了整个系统的负荷。

在数据库107中存储有一个路由配置表，在该表中包括了能够与支付平台对接的银行和每个银行拥有的银行通道。支付平台系统中的路由系统（集群）103可以根据该路由配置表来为交易选择合适的银行通道。

当用户通过应用101向支付平台侧的支付平台系统提交交易请求后，支付平台系统中的路由系统（集群）103就接收来自用户的交易请求，通过对所述交易请求中的数据进行分析并基于从数据库107加载的路由配置表来选择一个合适的银行通道。所述分析可以包括提取交易请求中的与交易有关的数据。交易请求可以包括例如业去渠道号（区分业务系统）、商户号、订单号、交易时间、用户名、卡号、证件类型、证件号、手机号、交易金额等等数据。根据例如卡号（银行卡的卡号的前六位一般被称为卡的bin码，可用来区分发卡的银行），路由系统（集群）103可以从路由配置表中选择与该卡号相对应的银行的银行通道，并将交易数据转发给该银行通道。

随后，所述银行通道将交易数据提交给银行109的结算系统以对交易进行结算，即从银行系统中用户开立的与该银行卡有关的账户中划出交易的金额转账到用户购买商品的商家号的账户中。如果转账成功，则生成交易成功的交易消息。而如果转账失败（例如归因于用户的银行账户余额不足或交易密码错误等问题）则生成交易失败的交易消息。

无论是交易成功还是交易失败，所生成的交易消息都会作为交易结果通过银行通道返回给路由系统（集群）103。

另一方面，如果在路由系统（集群）103将交易数据转发给所选的银行通道达一预定持续时间（例如60秒），还未从该银行通道收到从银行返回的交易结果，则路由系统（集群）103可以确定所述银行通道发生了问题导致交易失败，这样，可以由路由系统（集群）103生成交易失败的交易结果。

所述交易结果可以包括订单号、结算时间、交易凭证、银行通道返回应答码（以下简称为“应答码”），银行通道返回应答描述、银行通道机构代码（银行通道唯一标识码）等数据字段。交易是失败还是成功一般可以根据银行通道返回的应答码来判断，例如交易领域中常用的应答码有：100015银行预留手机号不正确；0000交易成功；999999是交易超时；999998 交易异常 （由情况不明的原因导致的交易失败都被归于这一类）等等。

接着，路由系统（集群）103对所述交易结果进行如下处理：

1）将交易结果存储到支付平台系统的数据库107中，以将交易数据备份存档；

2）将交易结果返回给用户处的应用101以告知交易是否成功；

3）将交易结果以消息队列形式发送给监听服务模块105以对交易结果进行进一步分析。

在监听服务模块105处，监听服务模块对交易结果进行进一步分析，所述分析可以包括例如基于交易结果中的应答码字段将包含交易超时（999999）或交易异常（999998）的交易结果筛选出来。因为交易超时（999999）一般都是由于支付平台和银行之间的支付（银行）通道存在问题（例如阻塞、断开、不稳定）而引起的。而交易异常（999998）尽管不一定归因于银行通道的问题，但也表示了使用该银行通道可能带来不明原因的交易失败，存在不稳定性。因此，本公开的路由切换机制一般监控和统计包含上述应答码的交易结果。

具体而言，一旦监听服务模块105检测到交易结果中含有999999的应答码，则表示在与该交易结果有关的银行通道上，路由系统（集群）103足足等待了例如60秒的预定持续时间也没有接到来自银行的交易反馈，因而生成了包括999999的应答码的交易结果，因此，该银行通道实际上无法执行交易。此时，监听服务模块105可以向路由系统（集群）103发送切换至备用路由（即备用银行通道）的通知。

另一方面，除了监听含有999999的应答码的交易结果之外，监听服务模块105还针对各银行通道对其在一个给定时间段内的含有交易异常（999998）的交易结果的数目进行统计。如果在该给定时间段内，例如5分钟，在该银行通道上的包括交易异常（999998）应答码的交易结果数/总交易结果数的比例超过阈值比例，例如50％，则表明通过该银行通道的交易存在严重问题，无法稳定地提供交易服务。因此，监听服务模块105也可以在此情况下向路由系统（集群）103发送切换至备用路由（即备用银行通道）的通知。

当监听服务模块105检测到含有999999的应答码的交易结果或者交易异常（999998）的交易结果在总交易结果数中的比例超过阈值比例而向路由系统（集群）103发送切换至备用路由的通知时，所述监听服务模块105还可以向预警服务模块111发送该银行通道存在问题的消息。

预警服务模块111根据该消息向例如支付平台的管理人员发送相应的通知、邮件或消息等信息，以提醒管理人员对该银行通道及时进行维修处理以恢复其正常工作。

在从监听服务模块105接收到切换至备用路由通知后，路由系统（集群）103先将当前所选的银行通道在路由配置表中将其归类为不可用，例如通过将其状态从“可用”标记为“不可用”来防止其被再次选中，随后，再从路由配置表中与该银行相关联的备用银行通道中选择一条新的银行通道以用于与该银行的交易活动。如果此时不存在任何可用的备用银行通道，则路由系统（集群）103就向用户告知他的交易请求支付失败，他可以选择其他银行的银行卡或其他支付平台来再次尝试交易。

而如果监听服务模块105没有检测到含有999999的应答码的交易结果或没有在给定时间段内检测到大量交易异常的交易结果，则表示所选的银行通道工作正常，并不需要进行任何银行通道路由切换。因此，系统100可以继续接收和处理后续的各种交易。

至此，所述在支付平台侧的可动态切换支付路由的系统的示意性系统结构图介绍完毕。应该理解，在上述内容中提及的“预定持续时间”、“给定时间段”、“阈值比例”之类的参数和所给出的具体示例仅仅是出于说明的目的，而非要将本方案局限于此。本领域的技术人员完全可以根据实际交易需求对这些参数进行重新配置。例如，可以将“阈值比例”修改为“20％”，也即只要有百分之二十的交易结果是交易异常就执行路由切换，以提高效率。而对于时效性要求高的交易，则可以将“预定持续时间”（也即路由系统等待银行通道响应的时间）设定得更短，例如10秒以满足交易要求。这些都属于本公开要求保护的范围。

在描述完系统示例之后，在图2中，示出了根据本公开的一个实施例的一种在支付平台侧使用的用于动态切换支付路由的方法的示意性流程图。

如图所示，在开始所述流程后，在步骤210，支付平台上运行的支付平台系统通过网络从用户的用户设备处的各种应用接收交易请求，例如，用户通过购物应用选定了一款商品并选择使用银行卡通过该支付平台进行结算，那么，应用就会将相应的交易请求发送给支付平台系统。如上所述，交易请求可以包括业去渠道号（区分业务系统）、商户号、订单号、交易时间、用户名、卡号、证件类型、证件号、手机号、交易金额等等数据内容。

在步骤220，支付平台系统将所述交易请求转发给支付平台上的路由系统，路由系统对所述交易请求进行分析以从数据库所存储的路由配置表（该路由配置表预先存储了与支付平台有合作的所有银行以及相关联的银行通道信息）中读取与该交易请求相关联的路由配置信息。所述路由配置信息可以包括与银行卡相关联的银行和与该银行相关联的所有的银行通道。例如路由系统可以从交易请求中提取卡号信息。随后，根据所述卡号的bin码，路由系统可以从路由配置表检索出与该bin码相关联的银行和其所拥有的银行通道等信息。

在步骤230中，路由系统根据所读取的路由配置信息判断是否有可用的银行通道。如上所述，在路由配置表中的每条银行通道可以具有状态信息，例如，当所述银行通道工作正常时，其状态可以标注为“可用”，而当银行通道发生问题（例如阻塞、时断时续的不稳定、彻底瘫痪）时，可以将其状态标注为“不可用”。因此，如果在所读取的路由配置信息中所有的银行通道的状态都是“不可用”，则可以判定不存在可用的通道路由，这样，流程就进入步骤294，在此，支付平台系统可以生成一个支付失败通知消息，并将其转发给用户侧的应用以告知用户所选支付方式无法在支付平台上使用。此时，用户可以选择更换其他银行卡或更换其他支付平台来完成交易。

如果在步骤230中确定有可用的银行通道用于路由（也即存在状态为“可用”的银行通道），则流程行进至步骤240，在该步骤可以从所有可用的银行通道中选择一个来转发所述交易请求给银行。

随后，在步骤250中，路由系统判断在一预定持续时间内，例如60秒内，是否通过所选银行通道接收到来自银行的交易结果。如果在该预定持续时间内没有接收到银行的处理结果，则表明该银行通道存在问题。所述问题可能包括严重阻塞、时断时续的不稳定、彻底瘫痪等等。这样，流程行进至步骤260，如前所述，如果在预定持续时间内未从银行接收到交易结果，则可以由路由系统来本地生成交易失败的交易结果。而所述交易结果中的“应答码”数据字段则被赋值为999999，以代表交易超时。

另一方面，如果在步骤250中，路由系统在一预定持续时间内，例如60秒内，通过所选银行通道接收到了来自银行的交易结果，则路由系统可以通过网络向用户的应用返回交易结果以告知用户交易是否成功，并且，接着流程行进至步骤270。

在步骤270中，无论是从银行接收到的交易结果还是由路由系统自己生成的交易结果，都先被路由系统存储到了数据库中以进行存档，并且随后转发给监听服务模块。所述转发可以以消息队列的方式发送交易结果到监听服务模块。使用消息队列的好处是可以通过异步处理来提高系统性能，实现削峰、并能降低系统耦合性。该技术已经是本领域经常使用的消息发送机制，因此，在此不再详述。应该理解，所述消息队列发送模式仅仅是出于说明的目的进行举例，而非要将交易结果的发送局限于消息队列发送模式。其他的消息发送模式也可以被应用于本公开的方案中。

在步骤280中，监听服务模块对从路由服务接收到的交易结果进行分析以判断是否需要切换至备用银行通道。

如前所述，交易结果可以包括订单号、结算时间、交易凭证、银行通道返回的应答码，银行通道返回应答描述、银行通道机构代码（银行通道唯一标识码）。交易是失败还是成功一般可以根据应答码来判断，例如交易领域中常用的应答码有：100015银行预留手机号不正确；0000交易成功；999999是交易超时；999998 交易异常 （一般情况不明的交易失败，都被归于这一类）等等。

因此，所述分析主要是基于交易结果中的应答码字段将包含交易超时（999999）或 交易异常（999998）的交易结果筛选出来。因为交易超时（999999）一般都是由于支付平台和银行之间的支付（银行）通道存在问题（例如阻塞、断开、不稳定）导致路由系统没有在预定持续时间内收到来自银行的反馈而在步骤260中产生的，该应答码可以明确指示所述银行通道存在问题。而交易异常（999998）则表示由于无法查明的各种原因而导致的交易失败的情况。尽管交易失败不一定归因于银行通道的问题，但也间接指示了使用该银行通道可能带来不明原因的交易失败，存在不稳定性。因此，本公开的路由切换机制主要监控和统计包含这两种类型的应答码的交易结果。

具体而言，一旦监听服务模块检测到交易结果中含有999999的应答码，则表示在与该交易结果有关的银行通道上，路由系统（集群）足足等待了例如60秒的预定持续时间也没有接到来自银行的反馈，因此，该银行通道实际上无法再进行交易。此时，监听服务模块可以直接向路由系统（集群）发送切换至备用路由（即备用银行通道）的通知（步骤290）。

另外，除了监听含有999999的应答码的交易结果之外，监听服务模块还对在一个给定时间段内的来自各银行通道的含有交易异常（999998）应答码的交易结果的数目进行统计。如果在该给定时间段内，例如5分钟，在该银行通道上的包括交易异常的交易结果数/总交易结果数的比例超过阈值比例，例如50％，则表明通过该银行通道上的交易存在严重问题，无法稳定地提供交易服务。因此，监听服务模块也可以在此情况下向路由系统（集群）发送切换至备用路由（即备用银行通道）的通知（步骤290）。

在一个实施例中，尽管未在图中示出，但当监听服务模块检测到含有交易超时应答码的交易结果或交易异常应答码的交易结果在总交易结果数中的比例超过阈值比例而向路由系统（集群）发送切换至备用路由的通知时，所述监听服务模块还可以向预警服务模块发送该银行通道存在问题的消息。预警服务模块根据该消息向例如支付平台的管理人员发送相应的通知、邮件或消息等信息，以提醒管理人员对该银行通道及时进行维修处理以恢复其正常工作。

在从监听服务模块接收到切换至备用路由通知后，如图所示，在步骤292中，路由系统通过在路由配置表和路由配置信息中将所选银行通道的状态从“可用”修改为“不可用”，以防止其被再次选中。

随后，流程返回到步骤230处，路由系统再次根据路由配置信息判断是否有可用的银行通道。如上所述，由于先前选择的银行通道已经被标注为“不可用”状态，因此，在本次判断中，它将被直接排除。如果还存在其他可用备用的银行通道，则流程继续执行步骤240及其后续的一系列步骤。如果所有的银行通道都不可用，则流程转至步骤294，将支付失败通知消息发送送给用户以结束流程。

另一方面，如果在步骤280中，监听服务模块没有检测到含有999999的应答码的交易结果或者没有在给定时间段内检测到大量交易异常的交易结果，则可判断出所选的银行通道工作正常，并不需要进行任何银行通道路由切换。因此，流程可以返回到开始阶段以继续接收和处理后续的各种交易。

在图1和图2中分别描述了根据本公开的实施例的在支付平台侧使用的可动态切换支付路由的系统和方法的示例说明。本公开的整个系统架构的核心可以利用切换支付路由的系统的dubbo服务和监听dubbo服务两个部分来实现，也即可采用常用的分布式微服务框架技术dubbo+spring来实现文中所述的路由系统和监听服务模块的各种功能。dubbo属于一种注册消费型服务框架，是业内的开源的一个高性能框架，是一个面向接口的服务框架，非常符合本公开的后端系统的架构。在整个系统架构中路由系统作为dubbo服务提供方，对外暴露了切换备用路由接口；监控系统作为dubbo服务的消费方，注册并使用了路由系统暴露的路由切换接口，在检测到银行通道故障或异常的时，就可以调用路由切换服务接口通知路由系统该银行通道出现故障，启用备用的银行通道。但是，应该理解，也可以使用其他的微服务框架进行替代，如spring clound等等。这些技术都是本领域常用的服务架构，在此不再详细描述。

在一些实施例中，为了提高系统效率，在步骤220中，路由系统可以一次性将数据库中的路由配置表中的所有数据读取出来并进行高速缓存，这样，就无需在每次接收到交易请求时都要访问数据库获取相应路由配置信息。

在一些优选实施例中，针对交易成功的交易结果，监听服务模块也可以对其进行分析，例如对交易结果中的结算时间和发生交易的时间（可从交易请求中获取）进行比较以判断它们之间的等待时间是否超过设定的等待时间阈值（例如30秒钟），如果在一时间段内超过等待时间阈值的交易结果数目/总的交易结果的比例超过了阈值比例，例如90％，则暗示了路由系统所选的银行通道存在较大负载，即使其还能正常工作但也存在将来会发生阻塞的很大可能性。因此，在这种情况下，监听服务模块也可以向路由系统发送切换到备用银行通道的建议通知。路由系统可根据实际情况（例如当前的交易量、备用通道的使用情况等）决定是否要切换到备用通道。而如果结算时间和交易时间之间的等待时间没有超过设定的阈值，则表示路由系统所选的银行通道工作正常，那么，监听服务模块无需对路由系统做出任何指示。

尽管在上面的叙述中，银行109是以单家银行的形式出现，但在实际应用中，可以理解支付平台其实一般都会与几家甚至几十家银行进行合作，而每家银行都可以具有一个或多个银行支付通道。无论是一家银行还是多家银行，它们各自的银行通道的动态路由切换都可以依据本公开的方案来进行。

应该理解，在上述内容中提及的“预定持续时间”、“给定时间段”、“阈值比例”以及“等待阈值时间”之类的限定范围所给出的具体示例仅仅是出于说明的目的，而非要将本方案局限于此。本领域的技术人员完全可以根据实际交易需求对这些限定范围进行重新配置。例如可以将“阈值比例”修改为“20％”，也即只要该银行通道上有百分之二十的交易结果是交易失败就执行路由切换，以提高交易效率。而对于时效性要求高的交易，则可以将“预定持续时间”（也即路由系统等待银行通道响应的时间）设定得更短，例如10秒以满足交易要求。这些都属于本公开要求保护的范围。

上述内容对本公开特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。而且，相关领域的技术人员将领会，在不偏离如所附权利要求书所定义的本公开的精神和范围的情况下，所述实施例可以在形式和细节方面进行各种修改。因此，此处所公开的本公开的宽度和范围不应被上述所公开的示例性实施例所限制，而应当仅根据所附权利要求书及其等同替换来定义。

Claims (10)

1.一种支付平台侧的可动态切换支付路由的方法，包括：

（1）接收来自用户的应用的交易请求；

（2）根据所述交易请求从数据库读取路由配置信息；

（3）根据所述路由配置信息判断是否存在可用的银行通道，其中：

如果存在可用的银行通道，则选择所述可用的银行通道之一来将所述交易请求转发给银行；将交易结果存储在所述数据库中并转发给监听服务模块；所述监听服务模块根据所述交易结果判断是否需要切换至备用银行通道，其中：

如果确定需要切换至备用银行通道，则将所选银行通道标记为“不可用”，并返回步骤（3）判断是否还存在其他可用的银行通道；

如果确定不需要切换至备用银行通道，则返回到步骤（1）接收下一交易请求；

如果不存在可用的银行通道，则告知所述用户支付失败。

2.如权利要求1所述的方法，其特征在于，所述方法还包括：

在将所述交易请求转发给所述银行之后，判断是否在预定持续时间内从所选的银行通道接收到来自所述银行的所述交易结果，其中：

如果未接收到来自所述银行的所述交易结果，则本地生成包含交易超时应答码的交易结果。

3. 如权利要求2所述的方法，其特征在于，所述根据所述交易结果判断是否需要切换至备用银行通道包括：

如果检测到包含所述交易超时应答码的交易结果，则确定需要切换至备用银行通道；或者

如果在一个给定时间段内的来自所选银行通道的含有交易异常的应答码的交易结果的数目与总交易结果数目的比例超过阈值比例，则确定需要切换至备用银行通道。

4.如权利要求1所述的方法，其特征在于，所述方法还包括：

如果确定需要切换至备用银行通道，则所述监听服务模块向预警服务模块发送所述银行通道存在问题的消息；

所述预警服务模块在接收到所述消息之后，通知所述支付平台的管理人员以对存在问题的所述银行通道进行维修。

5.如权利要求1所述的方法，其特征在于，所述将交易结果存储在所述数据库中并转发给监听服务模块的步骤是以消息队列形式将所述交易结果转发给所述监听服务模块。

6.一种支付平台侧的可动态切换支付路由的支付平台系统，包括：

数据库，被配置为用于存储包含路由配置信息的路由配置表，所述路由配置信息包括了能够与所述支付平台对接的银行和与每个银行相关联的银行通道；

路由系统，被配置为：

接收来自用户的应用的交易请求；

根据所述交易请求从所述数据库中读取所述路由配置信息；

根据所述路由配置信息判断是否存在可用的银行通道，其中：

如果存在可用的银行通道，则选择所述可用的银行通道之一来将所述交易请求转发给银行；将交易结果存储在所述数据库中并转发给监听服务模块；

如果不存在可用的银行通道，则告知所述用户支付失败；

所述监听服务模块，被配置为：

根据所述交易结果判断是否需要切换至备用银行通道，其中：

如果确定需要切换至备用银行通道，则通知所述路由系统将所选银行通道标记为“不可用”并再次判断是否还存在其他可用的银行通道；

如果确定不需要切换至备用银行通道，则通知所述路由系统接收下一交易请求。

7.如权利要求6所述的支付平台系统，其特征在于，所述支付平台系统的核心架构可以利用dubbo服务和监听dubbo服务两个部分来实现。

8.如权利要求6所述的支付平台系统，其特征在于，所述路由系统还被配置为：

在将所述交易请求转发给所述银行之后，判断是否在预定持续时间内从所选的银行通道接收到来自所述银行的所述交易结果，其中：

如果未接收到来自所述银行的所述交易结果，则本地生成包含交易超时应答码的交易结果。

9. 如权利要求8所述的支付平台系统，其特征在于，所述根据所述交易结果判断是否需要切换至备用银行通道包括：

如果检测到包含所述交易超时应答码的交易结果，则确定需要切换至备用银行通道；或者

如果在一个给定时间段内的来自所选银行通道的含有交易异常的应答码的交易结果的数目与总交易结果数目的比例超过阈值比例，则确定需要切换至备用银行通道。

10.如权利要求6所述的支付平台系统，其特征在于，其中所述支付平台系统还包括预警服务模块；

其中如果所述监听服务模块确定需要切换至备用银行通道，则向所述预警服务模块发送所述银行通道存在问题的消息；

其中预警服务模块被配置为在接收到所述消息之后，通知所述支付平台的管理人员以对存在问题的所述银行通道进行维修。

Images