CN116308333A - 确定支付渠道的方法、系统、设备与存储介质 - Google Patents

Abstract

本申请公开一种确定支付渠道的方法、系统、设备及存储介质，属于金融支付技术领域，所述方法包括获取支付请求中包含的用于确定支付渠道的各属性值；根据预设的对于待生成的属性值组合中各属性值的排列位置要求，分别确定各属性值在待生成的属性值组合中的排列位置；根据排列位置以及各属性值，生成属性值组合；其通过遍历渠道路由模板表，从渠道路由模板表中，确定与生成的属性值组合相匹配的各条渠道路由；从各条渠道路由分别包含的支付渠道中确定目标支付渠道，作为支付请求所采用的支付渠道。本方案仅进行一次遍历即可实现支付渠道的匹配，提高了渠道路由效率。

Description

确定支付渠道的方法、系统、设备与存储介质

技术领域

本申请涉及金融支付领域，尤其涉及一种确定支付渠道的方法、系统、设备及存储介质。

背景技术

支付渠道即资金转移的通道，也称为资金渠道、支付通道，比如微信、支付宝、通联、易宝等。由于一个交易平台可能会对接多个支付渠道，因此出现了渠道路由的概念。

渠道路由，指基于发起的支付请求，根据配置的渠道路由策略选择匹配的优先级最高的支付渠道完成支付的过程。

目前，基于渠道路由来确定支付渠道的过程一般包括如下步骤：

在接收到用户发起的支付请求后，获取支付请求包含的用于确定支付渠道的各属性；从内存中获取对应的渠道路由表，渠道路由表内存储的单条渠道路由，包括属性组合、属性组合(如商户、商户的机构和收款业务类型)中各属性值与支付渠道(具体可以为支付渠道的名称或代码)的对应关系；将支付请求中的各属性逐一遍历渠道路由表内的各属性组合，确定能够与支付请求中包含的属性匹配的属性组合；进而，将支付请求中包含的属性对应的属性值，赋值给确定出的属性组合中的属性，以进一步匹配得到与属性组合的属性值相对应的支付渠道，作为与所述支付请求对应的支付渠道。其中，举例来说，“商户、商户的机构和收款业务类型”这一属性组合，它的属性值比如可以为：属性“商户”的属性值为某保险集团，属性“商户的机构”的属性值为该集团的财险公司，属性“收款业务类型”的属性值为“车险保费”。

需要说明的是，按照现有技术，上述“将支付请求中的各属性逐一遍历渠道路由表内的各属性组合”的具体实现过程为：

先从自支付请求中获取的各属性中，选择第一个属性，与渠道路由表内的各属性组合进行匹配，以筛选出包含该第一个属性的第一组属性组合；

然后，从自支付请求中获取的各属性中，选择第二个属性，与第一组属性组合再次匹配，得到既包含第一个属性，又包含第二个属性的第二组属性组合；

以此类推，……直至支付请求中的各属性均匹配完毕。

上述匹配过程存在的问题在于：效率较低，进而导致支付渠道的确定效率较低。

发明内容

本申请实施例提供一种确定支付渠道的方法、系统、设备及存储介质，用以解决采用现有技术确定支付渠道，所存在的效率较低的问题。

本申请实施例采用下述技术方案：

一种确定支付渠道的方法，包括：

获取支付请求中包含的用于确定支付渠道的各属性值；

根据预设的对于待生成的属性值组合中各属性值的排列位置要求，分别确定所述各属性值在所述待生成的属性值组合中的排列位置；

根据所述排列位置以及所述各属性值，生成属性值组合；其中，生成的属性值组合中的所述各属性值按照确定的所述排列位置排列；

通过遍历预设的渠道路由模板表，从所述渠道路由模板表中，确定与所述生成的属性值组合相匹配的各条渠道路由；其中，所述渠道路由模板表中包含若干条渠道路由；单条渠道路由，包括支付渠道，以及相应的按照所述排列位置要求构建的属性值组合；

从所述各条渠道路由分别包含的支付渠道中确定目标支付渠道，作为所述支付请求所采用的支付渠道。

一种确定支付渠道的系统，包括：

请求处理单元，用于获取支付请求中包含的用于确定支付渠道的各属性值；

属性值定位单元，根据预设的对于待生成的属性值组合中各属性值的排列位置要求，分别确定所述各属性值在所述待生成的属性值组合中的排列位置；

组合生成单元，根据所述排列位置以及所述各属性值，生成属性值组合；其中，生成的属性值组合中的所述各属性值按照确定的所述排列位置排列；

渠道匹配单元，通过遍历预设的渠道路由模板表，从所述渠道路由模板表中，确定与所述生成的属性值组合相匹配的各条渠道路由；其中，所述渠道路由模板表中包含若干条渠道路由；单条渠道路由，包括支付渠道，以及相应的按照所述排列位置要求构建的属性值组合；

渠道确定单元，用于从所述各条渠道路由分别包含的支付渠道中确定目标支付渠道，作为所述支付请求所采用的支付渠道。

一种计算设备，包括：存储器及处理器，其中，

所述存储器，用于存储计算机程序；

所述处理器，与所述存储器耦合，用于执行所述存储器中存储的所述计算机程序，以用于执行上述的方法。

一种存储有计算机程序的计算机可读存储介质，所述计算机程序被计算机执行时能够实现上述的方法。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

为支付请求中包含的各属性设置对应的属性值，且为各属性值设置排列位置要求，基于该排列位置，在渠道路由模板表内设置属性值组合，且对于当前支付请求中包含的各属性，生成相应的属性值组合，通过遍历渠道路由目标表，基于当前支付请求对应的属性值组合与渠道路由模板表内的各属性值组合的匹配，确定相匹配的支付渠道。可见本方案仅进行一次遍历即可实现支付渠道的匹配，提高了渠道路由效率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的一种确定支付渠道的方法的具体实现流程图；

图2为本申请实施例提供的一种确定支付渠道的方法另一实施例的流程示意图；

图3是本申请实施例提供的一种确定支付渠道的方法中其一实现方式的示意图；

图4是本申请实施例提供的一种确定支付渠道的方法中另一实现方式的示意图；

图5是本申请实施例提供的一种确定支付渠道的系统的结构示意图；

图6为本申请实施例提供的一种计算设备的具体结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本领域普通技术人员可知，随着技术的发展和新场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的术语在适当情况下可以互换，这仅仅是描述本申请的实施例中对相同属性的对象在描述时所采用的区分方式。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，以便包含一系列单元的过程、方法、系统、产品或设备不必限于那些单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它单元。

实施例1

本申请实施例1提供了一种确定支付渠道的方法，用以解决采用现有技术确定支付渠道，所存在的效率较低的问题。

该方法的执行主体，可以是任意的可实现该方法的计算设备，如服务器、手机、个人电脑、智能可穿戴设备、智能机器人，等等。

该方法的不同步骤可以是同一执行主体实现的，也可以是不同执行主体实现的，本申请实施例对采用怎样的执行主体来实现该方法不做限定。

此外，本申请实施例对不同步骤的执行顺序也不做限定。在使用本申请实施例提供的该方法时，可以根据实际需求，调整不同步骤的执行顺序。

为便于描述，以下以一种样本数据的增强设备作为本方法的执行主体为例，对本申请实施例提供的该方法进行详细介绍。

如图1所示，为本申请实施例提供的一种确定支付渠道的方法，包括以下步骤：

步骤101，获取支付请求中包含的用于确定支付渠道的各属性及各属性值。

其中确定支付渠道的属性可以是表征商户维度的属性，也可以是其他维度的信息。

商户维度的信息是指表征商户具体信息的维度，如商户的办公或营业地址、商户所属的分支机构、商户的业务类型、业务范围、成交金额等，均构成表征商户维度的属性。举例来说，属性有：商户、机构、收款业务类型和金额，其中商户可以是商户的名称、识别码等信息作为属性，如某超市、某公司；机构为当前收款方在商户的定位，如某超市二店、某公司深圳分公司；收款业务类型为当前机构的业务类型，如超市二店销售的家电业务、某公司深圳分公司的商标代理服务；金额为收款金额。

其他维度可以是支付方维度，如支付方式(如信用卡支付、支付宝支付)、支付账号(银行卡号、支付方的省份证号)等。

在一种实现方式中，通过预设属性配置表，该属性配置表中存储有若干个属性，以及每个属性对应的属性值。

步骤102，根据预设的对于待生成的属性值组合中各属性值的排列位置要求，分别确定所述各属性值在所述待生成的属性值组合中的排列位置。

在一种实现方式中，所述各属性值的排列位置要求，按照预设属性配置表中的各属性值确定，如属性配置表中存储了属性-属性值的对应关系有：属性-1、机构-2、收款业务类型-3、金额-4，则相应的属性值的排列位置要求为1-2-3-4。

确定所述各属性值在所述待生成的属性值组合中的排列位置具体为：若待生成的属性值组合中包含的属性有商户和收款业务类型，则对应的属性值在属性值组合的排列位置为1-空-3，空表示该位置没有属性值，即当前支付请求或属性值组合中不包含对应的属性。

步骤103，根据所述排列位置以及所述各属性值，生成属性值组合；其中，生成的属性值组合中的所述各属性值按照确定的所述排列位置排列。

接步骤102的举例，对于属性商户和收款业务类型，生成的属性值组合为1_3。

在一种实现方式中，据所述排列位置以及所述各属性值，生成属性值组合，具体包括：

选取所述各属性中的至少两个属性，将每次选取的所述至少两个属性均按照排列位置以及对应的属性值，生成若干个属性值组合。

例如当前支付请求中，包含的属性有商户、机构和收款业务类型，分别选取商户和机构、商户和收款业务类型、机构和收款业务类型、商户和机构和收款业务类型，形成4个组合，则每个组合及属性值组合表示为：商户_机构对应1_2、商户和收款业务类型对应1_3、机构和收款业务类型对应2_3、商户和机构和收款业务类型1_2_3。

步骤104，通过遍历预设的渠道路由模板表，从所述渠道路由模板表中，确定与所述生成的属性值组合相匹配的各条渠道路由；所述渠道路由模板表中包含若干条渠道路由；其中单条渠道路由包括支付渠道，以及相应的按照所述排列位置要求构建的属性值组合。

渠道路由模板表内存储有属性组合清单，即支付请求中可能出现的表征商户维度的各种属性形成的能够匹配到支付渠道的所有的属性组合。所述所有的属性组合中的每个属性组合，其内的各属性均按照确定的排列位置排列，生成属性值组合。

例如，对于支付请求中表征商户维度的属性：商户、机构和收款业务类型，选取商户和机构、商户和收款业务类型、机构和收款业务类型、商户和机构和收款业务类型，形成4个组合，以及每个组合对应的属性值组合：商户_机构对应1_2、商户_收款业务类型对应1_3、机构_收款业务类型对应2_3、商户_机构_收款业务类型1_2_3。

在属性组合清单中，关于属性商户、机构和收款业务类型的属性组合以及对应的属性值组合：商户_机构对应1_2、商户_收款业务类型对应1_3、商户_机构_收款业务类型对应1_2_3，三种属性组合及对应的3个属性值组合。因此基于当前支付请求的表征商户维度的属性形成的4个属性值组合，遍历渠道路由模板表时，对于属性值组合2_3无对应的匹配结果，即机构_收款业务类型形成的组合没有匹配的支付渠道，可通过另外三个组合的属性值组合对应的支付渠道中选取优先级最高的支付渠道作为最终的支付渠道。

在一种实现方式中，所述通过遍历预设的渠道路由模板表，从所述渠道路由模板表中，确定与所述生成的属性值组合相匹配的各条渠道路，包括：

判断所述各属性值中是否存在数值定义，若存在数值定义，则将所述数值定义与渠道路由模板表内的哈希表匹配，获取所述数值定义所在数值范围对应的支付渠道，所述哈希表中存储有数值范围与支付渠道的对应关系。

所述数值定义对应的属性包括支付金额。

本实现方式中，对于有数值定义的情况，直接匹配当前支付请求中的数值所述的数值定义范围，快速确定支付渠道，进一步提高确定支付渠道的效率。

在一种实现方式中，所述通过遍历预设的渠道路由模板表，从所述渠道路由模板表中，确定与所述生成的属性值组合相匹配的各条渠道路，还包括：基于所述属性值组合，遍历预设数据库中的渠道路由模板表；若所述预设数据库中未匹配到支付渠道，则基于所述属性值组合遍历备份数据库中的渠道路由模板表。

实施例2

本申请实施例1提供了一种确定支付渠道的方法，用以解决采用现有技术确定支付渠道，所存在的效率较低的问题。

该方法的执行主体，可以是任意的可实现该方法的计算设备，如服务器、手机、个人电脑、智能可穿戴设备、智能机器人，等等。

该方法的不同步骤可以是同一执行主体实现的，也可以是不同执行主体实现的，本申请实施例对采用怎样的执行主体来实现该方法不做限定。

此外，本申请实施例对不同步骤的执行顺序也不做限定。在使用本申请实施例提供的该方法时，可以根据实际需求，调整不同步骤的执行顺序。

为便于描述，以下以一种样本数据的增强设备作为本方法的执行主体为例，对本申请实施例提供的该方法进行详细介绍。

如图2所示，为本申请实施例提供的一种确定支付渠道的方法，包括以下步骤：

本实施例中，属性配置表、路由模板表以及哈希表Hash Map中的内容均是示例，并不造成对方案的限定。本实施例中提到的key值对应实施例1中的表征值。本实施例中的路由模板表相当于实施例1的渠道路由模板表。

步骤201，从预设的属性配置表里，读取key值配置顺序，确定预设数据库Redis的key的映射规则。本步骤中的key值相当于实施例1中的属性值。

在一种实现方式中，属性配置表内包含的属性有商户、机构、收款业务类型和金额，且各属性对应的Key值配置顺序依次为1、2、3和4，形成属性与顺序值的映射关系。此处顺序值及本实施例中下文提到的顺序值均相当于实施例1中的属性值。

系统属性配置表中的顺序值定义了渠道匹配维度在业务层面的优先级，在本实现方式中，对应的优先级由高到低的顺序为商户、机构、收款业务类型、金额。

步骤202，获取支付请求对应的各属性，从属性配置表内读取所述各属性对应的顺序(即属性值)，按照路由模板表内的属性组合清单，拼接支付请求中对应的各属性，得到每种组合的key值。

在一种实现方式中，路由模板表中会配置属性组合清单，如商户_收款业务类型、商户_机构_收款业务类型等。根据路由模板表中的属性组合清单，各属性在属性配置表中的顺序，得到对应的属性组合key值。例如，属性组合清单中的属性组合：商户_收款业务类型，商户在属性配置表中的顺序为1，收款业务类型在属性配置表中的顺序为3，则对应的属性组合key值为1_3。

步骤203，得到key值后，确定key值是否有范围定义，若否，执行步骤204，若是执行步骤205。

步骤204，根据key值对应的哈希值到Redis数据库中进行匹配，并在匹配成功时返回匹配到的收款账户。通过key值匹配收款账户，遍历一次路由配置信息即可得到对应的收款账户。

在一种实现方式中，可以预先在Redis数据库中存储各key值对应的收款账户。

步骤205，根据key值从Redis数据库中匹配对应的哈希表hash map，hashmap中定义了范围field与收款账户的对应关系，本实现方式中预设了超出定义范围的key值与收款账户的对应关系。得到hash map后，轮询hash map，将拿到的field值按照符号_进行拆解，对比支付请求中的数值是否在范围内，若找到对应范围，则进一步确定对应的收款账户。Hash map中*代表无穷大，若在一个filed未找到对应数值，则继续查找下一个field，直至找到对应的范围field为止。

步骤206，判断步骤204和步骤205是否找到了对应的收款账户，若是，执行步骤207，若否，执行步骤208。

步骤207，获取步骤204和步骤205找到的收款账户。

步骤208，判断key值是否已全部匹配，若否，执行步骤203，若是，执行步骤209。

在一种实现方式中，步骤202得到的key值可能存在多个，如支付请求中存在属性商户、机构和收款业务类型，基于属性组合清单，对应的属性组合有：商户_收款业务类型、商户_机构_收款业务类型以及商户_机构，3中属性组合，对应得到3个key值。因此步骤208会判断key值是否匹配完毕。

步骤209，按照收款账户的优先级对获取到的收款账户进行排序，选取优先级最高的收款账户作为确定的收款账户，基于收款账户与支付渠道的对应关系，根据得到的收款账户，确定支付渠道。

在一种实现方式中，所述路由配置信息存储在预设数据库中，所述预设数据库为key-value数据库，表征值作为key，所述收款账户作为value。所述路由配置信息包括上述实施例中所述的渠道路由模板表。

如图3所示，本申请还提供了缓存同步及刷新机制。在保存路由配置时，可以同步写入南中心301的备份数据库TBase3011和预设数据库Redis3012中，或北中心302的备份数据库3021和预设数据库3022中，然后通过分布式数据处理平台kafka将数据从一个中心(南中心)复制到另一个中心(北中心)，保证配置数据的同步。

在一种实现方式中，如图4所示，读取路由配置时的执行过程为：

步骤401，首先从预设数据库Redis中读取路由配置信息，若读取到，执行步骤402，若未读取到，执行步骤403。

步骤402，将预设数据库Redis存储的路由配置信息返回。

步骤403，读取备份数据库TBase中的路由配置信息。

步骤404，将备份数据库TBase中的路由配置信息缓存到预设数据库Redis中。

从备份数据库TBase中读取路由配置信息时，可以通过分布式锁减少对库表的重复访问。

实施例3

为解决采用现有技术确定支付渠道，所存在的效率较低的问题。出于与本申请上述各实施例相同的发明构思，本申请实施例3提供一种确定支付渠道的系统。

该系统的具体结构示意图如图5所示，包括如下功能单元：

请求处理单元501，用于获取支付请求中包含的用于确定支付渠道的各属性值；

属性值定位单元502，根据预设的对于待生成的属性值组合中各属性值的排列位置要求，分别确定所述各属性值在所述待生成的属性值组合中的排列位置；

组合生成单元503，根据所述排列位置以及所述各属性值，生成属性值组合；其中，生成的属性值组合中的所述各属性值按照确定的所述排列位置排列；

渠道匹配单元504，通过遍历预设的渠道路由模板表，从所述渠道路由模板表中，确定与所述生成的属性值组合相匹配的各条渠道路由；其中，所述渠道路由模板表中包含若干条渠道路由；单条渠道路由，包括支付渠道，以及相应的按照所述排列位置要求构建的属性值组合；

渠道确定单元505，用于从所述各条渠道路由分别包含的支付渠道中确定目标支付渠道，作为所述支付请求所采用的支付渠道。

请求处理单元501中，通过预设属性配置表获取支付请求中用于生成支付渠道的各属性及各属性值，该属性配置表中存储有若干个属性，以及每个属性对应的属性值。

属性组合单元502中所述各属性值的排列位置要求，按照预设属性配置表中的各属性值确定，如属性配置表中存储了属性-属性值的对应关系有：属性-1、机构-2、收款业务类型-3、金额-4，则相应的属性值的排列位置要求为1-2-3-4。

确定所述各属性值在所述待生成的属性值组合中的排列位置具体为：若待生成的属性值组合中包含的属性有商户和收款业务类型，则对应的属性值在属性值组合的排列位置为1-空-3，空表示该位置没有属性值，即当前支付请求或属性值组合中不包含对应的属性。

在一种实现方式中，渠道匹配单元504，通过遍历预设的渠道路由模板表，从所述渠道路由模板表中，确定与所述生成的属性值组合相匹配的各条渠道路，具体用于：

判断所述各属性值中是否存在数值定义，若存在数值定义，则将所述数值定义与渠道路由模板表内的哈希表匹配，获取所述数值定义所在数值范围对应的支付渠道，所述哈希表中存储有数值范围与支付渠道的对应关系。

所述通过遍历预设的渠道路由模板表，从所述渠道路由模板表中，确定与所述生成的属性值组合相匹配的各条渠道路，还用于：

基于所述属性值组合，遍历预设数据库中的渠道路由模板表；若所述预设数据库中未匹配到支付渠道，则基于所述属性值组合遍历备份数据库中的渠道路由模板表。

渠道确定单元505按照各支付渠道的优先级，从所述各条渠道路由分别包含的支付渠道中确定目标支付渠道，作为所述支付请求所采用的支付渠道。

实施例4

出于与本申请前述各实施例相同的发明构思，本申请实施例4提供一种计算设备，用以解决采用现有技术确定支付渠道，所存在的效率较低的的问题。

如图6所示，所述计算设备包括：存储器601及处理器602。存储器601可被配置为存储其它各种数据以支持在电子设备上的操作。这些数据的示例包括用于在电子设备上操作的任何应用程序或方法的指令。存储器601可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

处理器602，与存储器601耦合，用于执行存储器601中存储的计算机程序，以用于执行本申请实施例1或实施2中所述的一种确定支付渠道的方法。

处理器602在执行存储器601中的计算机程序时，除了上面的功能之外，还可实现其它功能，具体可参见前面各实施例的描述。

进一步的，如图6所示，计算设备还包括：显示器604、通信组件603、电源组件605、音频组件606等其它组件。图6中仅示意性给出部分组件，并不意味着计算设备只包括图6所示组件。

相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，所述计算机程序被计算机执行时能够实现上述各实施例提供的方法。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (12)

1.一种确定支付渠道的方法，其特征在于，包括：

获取支付请求中包含的用于确定支付渠道的各属性值；

根据预设的对于待生成的属性值组合中各属性值的排列位置要求，分别确定所述各属性值在所述待生成的属性值组合中的排列位置；

根据所述排列位置以及所述各属性值，生成属性值组合；其中，生成的属性值组合中的所述各属性值按照确定的所述排列位置排列；

通过遍历预设的渠道路由模板表，从所述渠道路由模板表中，确定与所述生成的属性值组合相匹配的各条渠道路由；其中，所述渠道路由模板表中包含若干条渠道路由；单条渠道路由，包括支付渠道，以及相应的按照所述排列位置要求构建的属性值组合；

从所述各条渠道路由分别包含的支付渠道中确定目标支付渠道，作为所述支付请求所采用的支付渠道。

2.根据权利要求1所述的方法，其特征在于，所述获取支付请求中包含的用于确定支付渠道的各属性值，具体包括：

获取支付请求中包含的用于确定支付渠道的各属性；

从预设的属性配置表中，确定所述各属性对应的各属性值，所述属性配置表中包含若干个属性，以及每个属性的属性值。

3.根据权利要求2所述的方法，其特征在于，所述根据所述排列位置以及所述各属性值，生成属性值组合，具体包括：

选取所述各属性中的至少两个属性，将每次选取的所述至少两个属性均按照排列位置以及对应的属性值，生成若干个属性值组合。

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

对于所述若干个属性值组合；

利用所述每个属性值组合遍历渠道路由模板表，确定所述每个属性值组合对应的支付渠道；

从所所述每个属性值组合对应的支付渠道中确定目标支付渠道，作为所述支付请求所采用的支付渠道。

5.根据权利要求1所述的方法，其特征在于，所述通过遍历预设的渠道路由模板表，从所述渠道路由模板表中，确定与所述生成的属性值组合相匹配的各条渠道路由，包括：

判断所述各属性值中是否存在数值定义，

若存在数值定义，则将所述数值定义与所述渠道路由模板表内的哈希表匹配，获取所述数值定义所在数值范围对应的支付渠道，所述哈希表中存储有数值范围与支付渠道的对应关系。

6.根据权利要求5所述的方法，其特征在于，所述数值定义对应的属性包括支付金额。

7.根据权利要求1所述的方法，其特征在于，包括：

所述渠道路由模板表存储在预设数据库中，所述预设数据库为key-value数据库，所述表征值作为key，所述收款账户作为value。

8.根据权利要求1所述的方法，其特征在于，包括：

所述渠道路由模板表分别存储在第一数据中心的预设数据库和备份数据库中；

通过分布式数据处理平台将所述渠道路由模板表复制到第二数据中心的预设数据库和备份数据库中。

9.根据权利要求8所述的方法，其特征在于，所述通过遍历预设的渠道路由模板表，从所述渠道路由模板表中，确定与所述生成的属性值组合相匹配的各条渠道路由，还包括：

基于所述属性值组合，遍历预设数据库中的渠道路由模板表；

若所述预设数据库中未匹配到支付渠道，则基于所述属性值组合遍历备份数据库中的路由配置信息。

10.一种确定支付渠道的系统，其特征在于，包括：

请求处理单元，用于获取支付请求中包含的用于确定支付渠道的各属性值；

属性值定位单元，根据预设的对于待生成的属性值组合中各属性值的排列位置要求，分别确定所述各属性值在所述待生成的属性值组合中的排列位置；

组合生成单元，根据所述排列位置以及所述各属性值，生成属性值组合；其中，生成的属性值组合中的所述各属性值按照确定的所述排列位置排列；

渠道匹配单元，通过遍历预设的渠道路由模板表，从所述渠道路由模板表中，确定与所述生成的属性值组合相匹配的各条渠道路由；其中，所述渠道路由模板表中包含若干条渠道路由；单条渠道路由，包括支付渠道，以及相应的按照所述排列位置要求构建的属性值组合；

渠道确定单元，用于从所述各条渠道路由分别包含的支付渠道中确定目标支付渠道，作为所述支付请求所采用的支付渠道。

11.一种计算设备，其特征在于，包括：存储器及处理器，其中，

所述存储器，用于存储计算机程序；

所述处理器，与所述存储器耦合，用于执行所述存储器中存储的所述计算机程序，以用于执行权利要求1～9任一权项所述的方法。

12.一种存储有计算机程序的计算机可读存储介质，所述计算机程序被计算机执行时能够实现权利要求1～9任一权项所述的方法。

Images