CN114693169A - 一种收单支付交易路由方法及装置、存储介质及电子设备 - Google Patents
一种收单支付交易路由方法及装置、存储介质及电子设备 Download PDFInfo
- Publication number
- CN114693169A CN114693169A CN202210442102.3A CN202210442102A CN114693169A CN 114693169 A CN114693169 A CN 114693169A CN 202210442102 A CN202210442102 A CN 202210442102A CN 114693169 A CN114693169 A CN 114693169A
- Authority
- CN
- China
- Prior art keywords
- payment
- channel
- payment channel
- available
- transaction
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
- G06Q10/0635—Risk analysis of enterprise or organisation activities
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Human Resources & Organizations (AREA)
- Accounting & Taxation (AREA)
- Strategic Management (AREA)
- Finance (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Economics (AREA)
- Development Economics (AREA)
- Entrepreneurship & Innovation (AREA)
- Marketing (AREA)
- Computer Security & Cryptography (AREA)
- Educational Administration (AREA)
- Game Theory and Decision Science (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- Technology Law (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
本申请提供了一种收单支付交易路由方法及装置、存储介质及电子设备,该方法通过风控系统对收到支付交易进行风险检测,从而基于风险检测结果和收单支付交易对应店铺的渠道配置信息,从各个支付渠道中确定出可用支付渠道,并进一步在没有特殊路由策略的情况下,通过基于每个可用支付渠道的渠道成本、渠道风险因子和收单支付交易对应的发卡银行的支付成功率,计算得到的每个可用支付渠道的渠道权重,从各个可用支付渠道中确定出目标支付渠道,并将收单支付交易路由至目标支付渠道,以通过目标支付渠道执行支付。可见,本申请方案中,通过利用风控系统对收单支付交易进行风险检测,以及在渠道权重计算中引入渠道风险因子,从而提高支付成功率。
Description
技术领域
本申请涉及计算机应用领域,尤其涉及一种收单支付交易路由方法及装置、存储介质及电子设备。
背景技术
在收单业务场景下每个店铺会接入多个支付渠道,而一笔收单支付交易一般是通过一个支付渠道执行支付,因此,针对每笔收单支付交易,需要从多个支付渠道中确定出一个支付渠道,将收单支付交易路由至所确定的支付渠道。
现有技术中,收单支付交易路由方法一般是基于通道成本和发卡银行的支付成功率,确定目标支付渠道,并将收单支付交易路由至目标支付渠道,从而通过目标支付渠道执行支付。现在的收单支付交易路由方法,支付成功率较低。
发明内容
发明人在研究过程中发现,不同支付渠道的安全限制条件不同,并且支付安全会较大程度的影响最终支付的成功率,基于此,本申请提供了一种收单支付交易路由方法及装置、存储介质及电子设备,目的在于解决现有的支付成功率较低的问题。
为了实现上述目的,本申请提供了以下技术方案:
一种收单支付交易路由方法,包括:
获取待路由的收单支付交易的交易特征信息;
调用预设的风控系统,基于所述交易特征信息和预设的每个支付渠道各自对应的风险控制规则,对所述收单支付交易进行风险检测,得到每个支付渠道对应的风险检测结果;
获取所述收单支付交易对应店铺的渠道配置信息;所述渠道配置信息包括所述店铺支持的每个支付渠道的渠道信息和通过规则;
基于每个支付渠道对应的风险检测结果和所述渠道配置信息,从各个支付渠道中确定可用支付渠道;
在确定出可用支付渠道的情况下,判断是否存在所述店铺对应的特殊路由策略;
若不存在所述店铺对应的特殊路由策略,则获取每个可用支付渠道的渠道成本、渠道风险因子和所述收单支付交易对应的发卡银行的支付成功率;
针对每个可用支付渠道,基于所述可用支付渠道的所述渠道成本、所述渠道风险因子和所述支付成功率,计算所述可用支付渠道的渠道权重;
基于每个可用支付渠道的渠道权重,从各个可用支付渠道中确定目标支付渠道,并将所述收单支付交易路由至所述目标支付渠道,以通过所述目标支付渠道执行支付。
上述的方法,可选的,所述基于每个支付渠道对应的风险检测结果和所述渠道配置信息,从各个支付渠道中确定可用支付渠道,包括:
针对每个支付渠道,若所述支付渠道对应的风险检测结果表征允许所述收单支付交易通过,或,所述支付渠道对应的风险检测结果表征需对收单支付交易对应的持卡用户进行安全验证,且所述持卡用户通过所述安全验证,则判断所述店铺支持的各个支付渠道的渠道信息中是否存在与所述支付渠道相匹配的渠道信息,若存在,则基于所述交易特征信息,判断所述收单支付交易是否满足所述渠道配置信息包括的所述支付渠道对应的通过规则,若满足,则将所述支付渠道确定为可用支付渠道。
上述的方法,可选的,还包括:
若存在所述店铺对应的特殊路由策略,则运行所述特殊路由策略,以从各个可用支付渠道中确定出目标支付渠道;
获取运行所述特殊路由策略的运行结果;
若所述运行结果表征已确定出目标支付渠道,则将所述收单支付交易路由至所述目标支付渠道,以通过所述目标支付渠道执行支付;
若所述运行结果表征未确定出目标支付渠道,则返回执行所述获取每个可用支付渠道的渠道成本、渠道风险因子和所述收单支付交易对应的发卡银行的支付成功率的步骤。
上述的方法,可选的,所述基于每个可用支付渠道的渠道权重,从各个可用支付渠道中确定目标支付渠道,包括:
判断最高的渠道权重对应的可用支付渠道的个数是否为一个;
若最高的渠道权重对应的可用支付渠道的个数为一个,则将所述最高的渠道权重对应的可用支付渠道确定为目标支付渠道;
若最高的渠道权重对应的可用支付渠道的个数不为一个,则将最高的渠道权重对应的每个可用支付渠道确定为初始支付渠道,并基于每个初始支付渠道的优先级或创建时间,从各个初始支付渠道中确定目标支付渠道。
上述的方法,可选的,所述基于每个初始支付渠道的优先级或创建时间,从各个初始支付渠道中确定目标支付渠道,包括:
判断是否预先配置每个初始支付渠道的优先级;
若预先配置每个初始支付渠道的优先级,则将最高的优先级对应的初始支付渠道确定为目标支付渠道;
若未预先配置每个初始支付渠道的优先级,则将最近的创建时间对应的初始支付渠道确定为目标支付渠道。
上述的方法,可选的,所述将所述收单支付交易路由至所述目标支付渠道,以通过所述目标支付渠道执行支付之后,还包括:
判断是否支付成功;
若支付失败,则判断是否满足预设的重抛规则,在满足所述重抛规则的情况下,基于除目标支付渠道外的各个可用支付渠道,返回执行所述判断是否存在所述店铺对应的特殊路由策略的步骤。
一种收单支付交易路由装置,包括:
第一获取单元,用于获取待路由的收单支付交易的交易特征信息;
检测单元,用于调用预设的风控系统,基于所述交易特征信息和预设的每个支付渠道各自对应的风险控制规则,对所述收单支付交易进行风险检测,得到每个支付渠道对应的风险检测结果;
第二获取单元,用于获取所述收单支付交易对应店铺的渠道配置信息;所述渠道配置信息包括所述店铺支持的支付渠道的渠道信息和通过规则;
确定单元,用于基于每个支付渠道对应的风险检测结果和所述渠道配置信息,从各个支付渠道中确定可用支付渠道;
第一判断单元,用于判断是否存在所述商铺对应的特殊路由策略;
第三获取单元,用于若不存在所述店铺对应的特殊路由策略,则获取每个可用支付渠道的渠道成本、渠道风险因子和所述收单支付交易对应的发卡银行的支付成功率;
计算单元,用于针对每个可用支付渠道,基于所述可用支付渠道的所述渠道成本、所述渠道风险因子和所述支付成功率,计算所述可用支付渠道的渠道权重;
第一路由单元,用于基于每个可用支付渠道的渠道权重,从各个可用支付渠道中确定目标支付渠道,并将所述收单支付交易路由至所述目标支付渠道,以通过所述目标支付渠道执行支付。
上述的装置,可选的,所述确定单元具体用于:
针对每个支付渠道,若所述支付渠道对应的风险检测结果表征允许所述收单支付交易通过,或,所述支付渠道对应的风险检测结果表征需对收单支付交易对应的持卡用户进行安全验证,且所述持卡用户通过所述安全验证,则判断所述店铺支持的各个支付渠道的渠道信息中是否存在与所述支付渠道相匹配的渠道信息,若存在,则基于所述交易特征信息,判断所述收单支付交易是否满足所述渠道配置信息包括的所述支付渠道对应的通过规则,若满足,则将所述支付渠道确定为可用支付渠道。
一种存储介质,所述存储介质存储有指令集,其中,所述指令集被处理器执行时实现上述的收单支付交易路由方法。
一种电子设备,包括:
存储器,用于存储至少一组指令集;
处理器,用于执行所述存储器中存储的指令集,通过执行所述指令集实现上述的收单支付交易路由方法。
与现有技术相比,本申请包括以下优点:
本申请提供了一种收单支付交易路由方法及装置、存储介质及电子设备,该方法通过风控系统对收单支付交易进行风险检测,从而基于风险检测结果和收单支付交易对应店铺的渠道配置信息,从各个支付渠道中确定出可用支付渠道,并进一步在没有特殊路由策略的情况下,通过基于每个可用支付渠道的渠道成本、渠道风险因子和收单支付交易对应的发卡银行的支付成功率,计算得到的每个可用支付渠道的渠道权重,从各个可用支付渠道中确定出目标支付渠道,并将收单支付交易路由至目标支付渠道,以通过目标支付渠道执行支付。可见,本申请方案中,通过利用风控系统对收单支付交易进行风险检测,以及在渠道权重计算中引入渠道风险因子,从而提高支付成功率。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据提供的附图获得其他的附图。
图1为本申请提供的一种收单支付交易路由方法的方法流程图;
图2为本申请提供的一种收单支付交易路由方法的又一方法流程图;
图3为本申请提供的一种收单支付交易路由方法的又一方法流程图;
图4为本申请提供的一种收单支付交易路由方法的又一方法流程图;
图5为本申请提供的一种收单支付交易路由装置的结构示意图;
图6为本申请提供的一种电子设备的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
本文使用的术语“包括”及其变形是开放性包括,即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”;术语“另一实施例”表示“至少一个另外的实施例”;术语“一些实施例”表示“至少一些实施例”。其他术语的相关定义将在下文描述中给出。
需要注意,本申请公开中提及的“第一”、“第二”等概念仅用于对不同的装置、模块或单元进行区分,并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。
需要注意,本申请公开中提及的“一个”、“多个”的修饰是示意性而非限制性的,本领域技术人员应当理解,除非在上下文另有明确指出,否则应该理解为“一个或多个”。
本申请可用于众多通用或专用的计算装置环境或配置中。例如:个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器装置、包括以上任何装置或设备的分布式计算环境等等。
本实施例中,为了便于理解,对本申请涉及的相关名词进行说明如下:
银行卡收单业务:指签约银行向商户提供的本外币资金结算服务。就是最终持卡人在银行签约商户那里刷卡消费,银行结算。收单银行结算的过程就是从商户那边得到交易单据和交易数据,扣除按费率计算出的费用后打款给商户,并从中扣取一定比例的手续费。
收单行:收单行指跨行交易中兑付现金或与商户签约进行跨行交易资金结算,并且直接或间接地使交易达成转接的银行。
支付网关:是银行金融网络系统和Internet网络之间的接口,是由银行操作的将Internet上传输的数据转换为金融机构内部数据的一组服务器设备,或由指派的第三方处理商家支付信息和顾客的支付指令。
支付路由:基于支付通道的属性特点和业务系统的要求,为支付交易确定出符合业务要求的最优的通道。
3DS:3DS支付验证(以下简称3DS)服务是Visa、万事达等国际卡组织(以下统称卡组)为提高信用卡网上支付的安全性,保障客户网上支付安全,向所有信用卡个人卡主卡持卡人(以下简称持卡人)共同推出的一项安全验证服务。
卡BIN:信用卡BIN指的是发卡行识别码,银行卡卡号的前六位是用来表示发卡银行或机构的,这就是发卡行识别码。
本申请提供的一种收单支付交易路由方法,可应用于支付路由系统,参阅图1,收单支付交易路由方法的方法流程图如图1所示,具体包括:
S101、获取待路由的收单支付交易的交易特征信息。
本实施例中,获取待路由的收单支付交易的交易特征信息,其中,交易特征信息包括但不限于:卡品牌、币种、IP所属国家。
S102、调用预设的风控系统,基于交易特征信息和预设的每个支付渠道各自对应的风险控制规则,对收单支付交易进行风险检测,得到每个支付渠道对应的风险检测结果。
本实施例中,将收单支付交易的交易特征信息传输至预设的风控系统,风控系统基于交易特征信息和预设的每个支付渠道各自对应的风险控制规则,对收单支付交易进行风险检测,具体的,针对每个支付渠道,判断交易特征是否满足该支付渠道对应的风险控制规则,从而得到该支付渠道的对应的关于该收单支付交易的风险检测结果。示例性的,风险控制规则包括是否需要对持卡用户进行安全验证、对支付金额的限制条件、对支付笔数的限制条件、安全维护的黑名单,其中,安全维护的黑名单包括但不限于邮箱、发卡行标识码和IP。
本实施例中,每个支付渠道对应的风险检测结果表征允许收到支付交易通过、拒绝收单交易通过或需对收单支付交易对应的持卡用户进行安全验证。
对上述提及的调用预设的风控系统,基于交易特征信息和预设的每个支付渠道各自对应的风险控制规则,对收单支付交易进行风险检测,得到每个支付渠道对应的风险检测结果的过程,进行举例说明如下:
一笔1000usd用visa支付的交易,支付渠道A的限额是500usd,支付渠道B是用usd支付就需要3DS,那么支付渠道A对应的风险检测结果为支付渠道A拒绝(即拒绝收单交易通过),支付渠道B对应的风险检测结果为支付渠道B需要3DS(即需对收单支付交易对应的持卡用户进行安全验证)。
S103、获取收单支付交易对应店铺的渠道配置信息。
本实施例中,获取收单支付交易对应店铺的渠道配置信息,其中,渠道配置信息包括店铺支持的每个支付渠道的渠道信息和通过规则。
S104、基于每个支付渠道对应的风险检测结果和渠道配置信息,从各个支付渠道中确定可用支付渠道。
本实施例中,基于每个支付渠道对应的风险检测结果和渠道配置信息,从各个支付渠道中确定可用支付渠道,具体的,参阅图2,包括以下步骤:
S201、针对每个支付渠道,判断该支付渠道对应的风险检测结果是否表征允许收单支付交易通过,若否,执行S202,若是,执行S203。
本实施例中,针对预设的每个支付渠道,基于该支付渠道对应的风险检测结果,判断该支付渠道对应的风险检测结果是否表征允许收单支付交易通过。
S202、判断支付渠道对应的风险检测结果是否表征拒绝收单支付交易通过,若是,执行S204,若否,执行S205。
本实施例中,针对每个支付渠道,若该支付渠道对应的风险检测结果未表征允许收单交易通过,则进一步判断支付渠道对应的风险检测结果是否表征拒绝收单支付交易通过。
S203、判断店铺支持的各个支付渠道的渠道信息中是否存在与该支付渠道相匹配的渠道信息,若否,执行S204,若是,执行S206。
本实施例中,针对每个支付渠道,若支付渠道对应的风险检测结果表征允许收单支付交易通过,或,支付渠道对应的风险检测结果表征需对收单支付交易对应的持卡用户进行安全验证,且持卡用户通过安全验证,则进一步判断店铺支持的各个支付渠道的渠道信息中是否存在与该支付渠道相匹配的渠道信息,也就是判断该支付渠道是否为店铺支持的支付渠道。
S204、将支付渠道确定为不可用支付渠道。
本实施例中,若支付渠道对应的风险检测结果表征拒绝收单支付交易通过,或支付渠道对应的风险检测结果表征需对收单支付交易对应的持卡用户进行安全验证,但是,持卡用户未通过安全验证,则将支付渠道确定为不可用支付渠道。
本实施例中,针对每个支付渠道,在支付渠道对应的风险检测结果表征允许收单支付交易通过,或,支付渠道对应的风险检测结果表征需对收单支付交易对应的持卡用户进行安全验证,且持卡用户通过安全验证的情况下,若店铺支持的各个支付渠道的渠道信息中不存在与该支付渠道相匹配的渠道信息,或,收单支付交易不满足渠道配置信息包括的支付渠道对应的通过规则,则将该支付渠道确定为不可用支付渠道。
S205、对收单支付交易对应的持卡用户进行安全验证,并判断持卡用户是否通过安全验证,若否,执行S204,若是,执行S203。
本实施例中,针对每个支付渠道,若支付渠道对应的风险检测结果未表征允许收单支付交易通过,以及未表征拒绝收单支付交易通过,则说明风险检测结果表征需对持卡用户进行安全验证,并对收单支付交易对应的持卡用户进行安全验证。
示例性的,可以通过向持卡用户的用户终端发送校验信息,并在用户完成对校验信息的输入后,基于用户的输入,对持卡用户进行安全验证,得到安全验证结果。
本实施例中,针对每个支付渠道,基于安全验证结果,判断持卡用户是否通过安全验证,具体的,若安全验证结果表征持卡用户通过安全验证,则确定持卡用户通过安全验证,若安全验证结果表征持卡用户未通过安全验证,则确定持卡用户未通过安全验证。
S206、基于交易特征信息,判断收单支付交易是否满足渠道配置信息包括的支付渠道对应的通过规则,若否,执行S204,若是,执行S207。
本实施例中,针对每个支付渠道,若店铺支持的各个支付渠道的渠道信息中存在与支付渠道相匹配的渠道信息,则进一步基于交易特征信息,判断收单支付交易是否满足渠道配置信息包括的支付渠道对应的通过规则,例如,通过规则为支持visa卡,而收单支付交易是MasterCard,则确定收单支付交易不满足渠道配置信息包括的支付渠道对应的通过规则。
S207、将支付渠道确定为可用支付渠道。
本实施例中,针对每个支付渠道,若收单支付交易满足渠道配置信息包括的支付渠道对应的通过规则,则将该支付渠道确定为可用支付渠道。
S105、判断是否确定出可用支付渠道,若是,执行S106,若否,直接结束。
本实施例中,判断是否确定出可用支付渠道,若未确定出可用支付渠道,则直接结束。
S106、判断是否存在店铺对应的特殊路由策略,若是,执行S107,若否,执行S108。
本实施例中,在确定出可用支付渠道的情况下,进一步判断预设的路由策略中是否存在该店铺对应的特殊路由策略。
S107、运行特殊路由策略,以从各个可用支付渠道中确定出目标支付渠。道。
本实施例中,若存在店铺对应的特殊路由策略,则运行特殊路由策略,以从各个可用支付渠道中确定出目标支付渠道。
需要说明的是,通过运行特殊路由策略的目的是从各个可用支付渠道中确定出目标支付渠道,但是,运行特殊路由策略的运行结果可以是从各个支付渠道中确定出目标支付渠道,也可以是从各个支付渠道中未确定出目标支付渠道。
S108、获取每个可用支付渠道的渠道成本、渠道风险因子和收单支付交易对应的发卡银行的支付成功率。
本实施例中,若不存在店铺对应的特殊路由策略,则获取每个可用支付渠道的渠道成本、渠道风险因子和收单支付交易对应的发卡银行的支付成功率。
其中,渠道风险因子包括但不限于是否支持3DS、3DS成功率和3DS完成时间。
需要说明的是,每个渠道风险因子为支付路由系统预先基于历史数据计算得到的。
S109、获取运行特殊路由策略的运行结果,并判断运行结果是否表征已确定出目标支付渠道,若是,执行S110,若否,返回执行S108。
本实施例中,获取运行特殊路由策略的运行结果,运行特殊路由策略的运行结果包括从各个支付渠道中确定出目标支付渠道,或,从各个支付渠道中未确定出目标支付渠道。
本实施例中,判断运行结果是否表征确定出目标支付渠道。
S110、将收单支付交易路由至目标支付渠道,以通过目标支付渠道执行支付。
本实施例中,若运行结果表征确定出目标支付渠道,则将收单支付交易路由至目标支付渠道,以通过目标支付渠道执行支付。
本实施例中,在基于每个可用支付渠道的渠道权重,从各个可用支付渠道中确定目标支付渠道后,将收单支付交易路由至目标支付渠道,以通过目标支付渠道执行支付。
S111、针对每个可用支付渠道,基于可用支付渠道的渠道成本、渠道风险因子和支付成功率,计算可用支付渠道的渠道权重。
本实施例中,针对每个可用支付渠道,基于可用支付渠道的渠道成本、渠道风险因子和支付成功率,计算该可用支付渠道的渠道权重。
具体的,预设渠道成本、支付成功率和渠道风险因子各自对应的计算权重,基于每个可用支付渠道的渠道成本、渠道风险因子、支付成功率、渠道成本对应的计算权重,渠道风险因子对应的计算权重和支付成功对应的成功率,计算每个可用支付渠道的渠道权重。
S112、基于每个可用支付渠道的渠道权重,从各个可用支付渠道中确定目标支付渠道,并执行S110。
本实施例中,基于每个可用支付渠道的渠道权重,从各个可用支付渠道中确定目标支付渠道,具体的,参阅图3,包括以下步骤:
S301、判断最高的渠道权重对应的可用支付渠道的个数是否为一个,若是,执行S302,若否,执行S303。
本实施例中,基于每个可用支付渠道的渠道权重,从各个支付渠道中确定最高的渠道权重对应的可用支付渠道。
本实施例中,判断最高的渠道权重对应的可用支付渠道的个数是否为一个。
S302、将最高的渠道权重对应的可用支付渠道确定为目标支付渠道。
本实施例中,若最高的渠道权重对应的可用支付渠道的个数为一个,则直接将最高的渠道权重对应的可用支付渠道确定为目标支付渠道。
S303、将最高的渠道权重对应的每个可用支付渠道确定为初始支付渠道,并基于每个初始支付渠道的优先级或创建时间,从各个初始支付渠道中确定目标支付渠道。
本实施例中,若最高的渠道权重对应的可用支付渠道的个数不为一个,则将最高的渠道权重对应的每个可用支付渠道确定为初始支付渠道,并基于每个初始支付渠道的优先级或创建时间,从各个初始支付渠道中确定目标支付渠道。
参阅图4,基于每个初始支付渠道的优先级或创建时间,从各个初始支付渠道中确定目标支付渠道的过程,具体包括以下步骤:
S401、判断是否预先配置每个初始支付渠道的优先级,若是,执行S402,若否,执行S403。
S402、将最高的优先级对应的初始支付渠道确定为目标支付渠道。
本实施例中,若预先配置每个初始支付渠道的优先级,则基于每个初始支付渠道的优先级,从各个初始支付渠道中确定优先级最高的初始支付渠道,并将最高的优先级对应的初始支付渠道确定为目标支付渠道。
S403、将最近的创建时间对应的初始支付渠道确定为目标支付渠道。
本实施例中,若未预先配置每个初始支付渠道的优先级,则获取每个初始支付渠道的创建时间,将最近的创建时间对应的初始支付渠道确定为目标支付渠道。
其中,最近的创建时间为时间最新的创建时间。
S113、判断是否支付成功,若否,执行S114,若是,直接结束。
本实施例中,在通过目标支付渠道执行支付后,判断是否支付成功,若确定支付成功,则直接结束,若确定未支付成功,也就是确定支付失败,执行步骤S114。
S114、判断是否满足预设的重抛规则,若是,基于除目标支付渠道外的各个可用支付渠道,返回执行S106,若否,直接结束。
本实施例中,在支付失败的情况下,判断是否满足预设的重抛规则。示例性的,若失败原因为卡余额不足,则确定不满足重抛规则。
需要说明的是,若支付失败,已被确定为目标支付渠道的可用支付渠道将不再参与下一循环。
本申请实施例提供的收单支付交易路由方法,通过风控系统对收单支付交易进行风险检测,从而基于风险检测结果和收单支付交易对应店铺的渠道配置信息,从各个支付渠道中确定出可用支付渠道,并进一步在没有特殊路由策略的情况下,通过基于每个可用支付渠道的渠道成本、渠道风险因子和收单支付交易对应的发卡银行的支付成功率,计算得到的每个可用支付渠道的渠道权重,从各个可用支付渠道中确定出目标支付渠道,并将收单支付交易路由至目标支付渠道,以通过目标支付渠道执行支付。可见,本申请方案中,通过利用风控系统对收单支付交易进行风险检测,以及在渠道权重计算中引入渠道风险因子,从而提高支付成功率。
本申请实施例提供的收单支付交易路由方法,支付路由系统和风控系统归属于不同的系统,系统边界清晰,改造成本小,属于小成本大产出。如果把渠道风控系统在支付路由系统中,不仅会导致系统的职责划分不清,而且还会造成路由的复杂性。
需要说明的是,虽然采用特定次序描绘了各操作,但是这不应当理解为要求这些操作以所示出的特定次序或以顺序次序执行来执行。在一定环境下,多任务和并行处理可能是有利的。
应当理解,本申请公开的方法实施方式中记载的各个步骤可以按照不同的顺序执行,和/或并行执行。此外,方法实施方式可以包括附加的步骤和/或省略执行示出的步骤。本申请公开的范围在此方面不受限制。
与图1所述的方法相对应,本申请实施例还提供了一种收单支付交易路由装置,用于对图1中方法的具体实现,其结构示意图如图5所示,具体包括:
第一获取单元501,用于获取待路由的收单支付交易的交易特征信息;
检测单元502,用于调用预设的风控系统,基于所述交易特征信息和预设的每个支付渠道各自对应的风险控制规则,对所述收单支付交易进行风险检测,得到每个支付渠道对应的风险检测结果;
第二获取单元503,用于获取所述收单支付交易对应店铺的渠道配置信息;所述渠道配置信息包括所述店铺支持的支付渠道的渠道信息和通过规则;
确定单元504,用于基于每个支付渠道对应的风险检测结果和所述渠道配置信息,从各个支付渠道中确定可用支付渠道;
第一判断单元505,用于在确定出可用支付渠道的情况下,判断是否存在所述店铺对应的特殊路由策略;
第三获取单元506,用于若不存在所述店铺对应的特殊路由策略,则获取每个可用支付渠道的渠道成本、渠道风险因子和所述收单支付交易对应的发卡银行的支付成功率;
计算单元507,用于针对每个可用支付渠道,基于所述可用支付渠道的所述渠道成本、所述渠道风险因子和所述支付成功率,计算所述可用支付渠道的渠道权重;
第一路由单元508,用于基于每个可用支付渠道的渠道权重,从各个可用支付渠道中确定目标支付渠道,并将所述收单支付交易路由至所述目标支付渠道,以通过所述目标支付渠道执行支付。
本申请实施例提供的收单支付交易路由装置,通过利用风控系统对收单支付交易进行风险检测,以及在渠道权重计算中引入渠道风险因子,从而提高支付成功率。
在本申请的一个实施例中,基于前述方案,确定单元503具体用于:
针对每个支付渠道,若所述支付渠道对应的风险检测结果表征允许所述收单支付交易通过,或,所述支付渠道对应的风险检测结果表征需对收单支付交易对应的持卡用户进行安全验证,且所述持卡用户通过所述安全验证,则判断所述店铺支持的各个支付渠道的渠道信息中是否存在与所述支付渠道相匹配的渠道信息,若存在,则基于所述交易特征信息,判断所述收单支付交易是否满足所述渠道配置信息包括的所述支付渠道对应的通过规则,若满足,则将所述支付渠道确定为可用支付渠道。
在本申请的一个实施例中,基于前述方案,还可以配置为:
运行单元,用于若存在所述店铺对应的特殊路由策略,则运行所述特殊路由策略,以从各个可用支付渠道中确定出目标支付渠道;
第二获取单元,用于获取运行所述特殊路由策略的运行结果;
第二路由单元,用于若所述运行结果表征已确定出目标支付渠道,则将所述收单支付交易路由至所述目标支付渠道,以通过所述目标支付渠道执行支付;
第一返回单元,用于若所述运行结果表征未确定出目标支付渠道,则返回执行所述获取每个可用支付渠道的渠道成本、渠道风险因子和所述收单支付交易对应的发卡银行的支付成功率的步骤。
在本申请的一个实施例中,基于前述方案,第一路由单元508在基于每个可用支付渠道的渠道权重,从各个可用支付渠道中确定目标支付渠道时,具体用于:
判断最高的渠道权重对应的可用支付渠道的个数是否为一个;
若最高的渠道权重对应的可用支付渠道的个数为一个,则将所述最高的渠道权重对应的可用支付渠道确定为目标支付渠道;
若最高的渠道权重对应的可用支付渠道的个数不为一个,则将最高的渠道权重对应的每个可用支付渠道确定为初始支付渠道,并基于每个初始支付渠道的优先级或创建时间,从各个初始支付渠道中确定目标支付渠道。
在本申请的一个实施例中,基于前述方案,第一路由单元508在基于每个初始支付渠道的优先级或创建时间,从各个初始支付渠道中确定目标支付渠道时,具体用于:
判断是否预先配置每个初始支付渠道的优先级;
若预先配置每个初始支付渠道的优先级,则将最高的优先级对应的初始支付渠道确定为目标支付渠道;
若未预先配置每个初始支付渠道的优先级,则将最近的创建时间对应的初始支付渠道确定为目标支付渠道。
在本申请的一个实施例中,基于前述方案,还可以配置为:
第二判断单元,用于判断是否支付成功;
第二返回单元,用于若支付失败,则判断是否满足预设的重抛规则,在满足所述重抛规则的情况下,基于除目标支付渠道外的各个可用支付渠道,返回执行所述判断是否存在所述店铺对应的特殊路由策略的步骤。
本申请实施例还提供了一种存储介质,所述存储介质存储有指令集,其中,在所述指令集运行时执行如上文任一实施例公开的收单支付交易路由方法。
本申请实施例还提供了一种电子设备,其结构示意图如图6所示,具体包括存储器601,用于存储至少一组指令集;处理器602,用于执行所述存储器中存储的指令集,通过执行所述指令集实现如上文任一实施例公开的收单支付交易路由方法。
尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题,但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反,上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。
虽然在上面论述中包含了若干具体实现细节,但是这些不应当被解释为对本申请公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实施例中。相反地,在单个实施例的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实施例中。
以上描述仅为本申请公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解,本申请公开中所涉及的公开范围,并不限于上述技术特征的特定组合而成的技术方案,同时也应涵盖在不脱离上述公开构思的情况下,由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请公开中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。
Claims (10)
1.一种收单支付交易路由方法,其特征在于,包括:
获取待路由的收单支付交易的交易特征信息;
调用预设的风控系统,基于所述交易特征信息和预设的每个支付渠道各自对应的风险控制规则,对所述收单支付交易进行风险检测,得到每个支付渠道对应的风险检测结果;
获取所述收单支付交易对应店铺的渠道配置信息;所述渠道配置信息包括所述店铺支持的每个支付渠道的渠道信息和通过规则;
基于每个支付渠道对应的风险检测结果和所述渠道配置信息,从各个支付渠道中确定可用支付渠道;
在确定出可用支付渠道的情况下,判断是否存在所述店铺对应的特殊路由策略;
若不存在所述店铺对应的特殊路由策略,则获取每个可用支付渠道的渠道成本、渠道风险因子和所述收单支付交易对应的发卡银行的支付成功率;
针对每个可用支付渠道,基于所述可用支付渠道的所述渠道成本、所述渠道风险因子和所述支付成功率,计算所述可用支付渠道的渠道权重;
基于每个可用支付渠道的渠道权重,从各个可用支付渠道中确定目标支付渠道,并将所述收单支付交易路由至所述目标支付渠道,以通过所述目标支付渠道执行支付。
2.根据权利要求1所述的方法,其特征在于,所述基于每个支付渠道对应的风险检测结果和所述渠道配置信息,从各个支付渠道中确定可用支付渠道,包括:
针对每个支付渠道,若所述支付渠道对应的风险检测结果表征允许所述收单支付交易通过,或,所述支付渠道对应的风险检测结果表征需对收单支付交易对应的持卡用户进行安全验证,且所述持卡用户通过所述安全验证,则判断所述店铺支持的各个支付渠道的渠道信息中是否存在与所述支付渠道相匹配的渠道信息,若存在,则基于所述交易特征信息,判断所述收单支付交易是否满足所述渠道配置信息包括的所述支付渠道对应的通过规则,若满足,则将所述支付渠道确定为可用支付渠道。
3.根据权利要求1所述的方法,其特征在于,还包括:
若存在所述店铺对应的特殊路由策略,则运行所述特殊路由策略,以从各个可用支付渠道中确定出目标支付渠道;
获取运行所述特殊路由策略的运行结果;
若所述运行结果表征已确定出目标支付渠道,则将所述收单支付交易路由至所述目标支付渠道,以通过所述目标支付渠道执行支付;
若所述运行结果表征未确定出目标支付渠道,则返回执行所述获取每个可用支付渠道的渠道成本、渠道风险因子和所述收单支付交易对应的发卡银行的支付成功率的步骤。
4.根据权利要求1所述的方法,其特征在于,所述基于每个可用支付渠道的渠道权重,从各个可用支付渠道中确定目标支付渠道,包括:
判断最高的渠道权重对应的可用支付渠道的个数是否为一个;
若最高的渠道权重对应的可用支付渠道的个数为一个,则将所述最高的渠道权重对应的可用支付渠道确定为目标支付渠道;
若最高的渠道权重对应的可用支付渠道的个数不为一个,则将最高的渠道权重对应的每个可用支付渠道确定为初始支付渠道,并基于每个初始支付渠道的优先级或创建时间,从各个初始支付渠道中确定目标支付渠道。
5.根据权利要求4所述的方法,其特征在于,所述基于每个初始支付渠道的优先级或创建时间,从各个初始支付渠道中确定目标支付渠道,包括:
判断是否预先配置每个初始支付渠道的优先级;
若预先配置每个初始支付渠道的优先级,则将最高的优先级对应的初始支付渠道确定为目标支付渠道;
若未预先配置每个初始支付渠道的优先级,则将最近的创建时间对应的初始支付渠道确定为目标支付渠道。
6.根据权利要求1或3所述的方法,其特征在于,所述将所述收单支付交易路由至所述目标支付渠道,以通过所述目标支付渠道执行支付之后,还包括:
判断是否支付成功;
若支付失败,则判断是否满足预设的重抛规则,在满足所述重抛规则的情况下,基于除目标支付渠道外的各个可用支付渠道,返回执行所述判断是否存在所述店铺对应的特殊路由策略的步骤。
7.一种收单支付交易路由装置,其特征在于,包括:
第一获取单元,用于获取待路由的收单支付交易的交易特征信息;
检测单元,用于调用预设的风控系统,基于所述交易特征信息和预设的每个支付渠道各自对应的风险控制规则,对所述收单支付交易进行风险检测,得到每个支付渠道对应的风险检测结果;
第二获取单元,用于获取所述收单支付交易对应店铺的渠道配置信息;所述渠道配置信息包括所述店铺支持的支付渠道的渠道信息和通过规则;
确定单元,用于基于每个支付渠道对应的风险检测结果和所述渠道配置信息,从各个支付渠道中确定可用支付渠道;
第一判断单元,用于在确定出可用支付渠道的情况下,判断是否存在所述店铺对应的特殊路由策略;
第三获取单元,用于若不存在所述店铺对应的特殊路由策略,则获取每个可用支付渠道的渠道成本、渠道风险因子和所述收单支付交易对应的发卡银行的支付成功率;
计算单元,用于针对每个可用支付渠道,基于所述可用支付渠道的所述渠道成本、所述渠道风险因子和所述支付成功率,计算所述可用支付渠道的渠道权重;
第一路由单元,用于基于每个可用支付渠道的渠道权重,从各个可用支付渠道中确定目标支付渠道,并将所述收单支付交易路由至所述目标支付渠道,以通过所述目标支付渠道执行支付。
8.根据权利要求7所述的装置,其特征在于,所述确定单元具体用于:
针对每个支付渠道,若所述支付渠道对应的风险检测结果表征允许所述收单支付交易通过,或,所述支付渠道对应的风险检测结果表征需对收单支付交易对应的持卡用户进行安全验证,且所述持卡用户通过所述安全验证,则判断所述店铺支持的各个支付渠道的渠道信息中是否存在与所述支付渠道相匹配的渠道信息,若存在,则基于所述交易特征信息,判断所述收单支付交易是否满足所述渠道配置信息包括的所述支付渠道对应的通过规则,若满足,则将所述支付渠道确定为可用支付渠道。
9.一种存储介质,其特征在于,所述存储介质存储有指令集,其中,所述指令集被处理器执行时实现如权利要求1-6任意一项所述的收单支付交易路由方法。
10.一种电子设备,其特征在于,包括:
存储器,用于存储至少一组指令集;
处理器,用于执行所述存储器中存储的指令集,通过执行所述指令集实现如权利要求1-6任意一项所述的收单支付交易路由方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210442102.3A CN114693169A (zh) | 2022-04-25 | 2022-04-25 | 一种收单支付交易路由方法及装置、存储介质及电子设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210442102.3A CN114693169A (zh) | 2022-04-25 | 2022-04-25 | 一种收单支付交易路由方法及装置、存储介质及电子设备 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN114693169A true CN114693169A (zh) | 2022-07-01 |
Family
ID=82145165
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210442102.3A Pending CN114693169A (zh) | 2022-04-25 | 2022-04-25 | 一种收单支付交易路由方法及装置、存储介质及电子设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114693169A (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN115170099A (zh) * | 2022-09-08 | 2022-10-11 | 国网汇通金财(北京)信息科技有限公司 | 一种支付渠道确定方法及系统 |
-
2022
- 2022-04-25 CN CN202210442102.3A patent/CN114693169A/zh active Pending
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN115170099A (zh) * | 2022-09-08 | 2022-10-11 | 国网汇通金财(北京)信息科技有限公司 | 一种支付渠道确定方法及系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11416865B2 (en) | Authorization of credential on file transactions | |
US10096006B2 (en) | Mobile agent point-of-sale (POS) | |
US20170364890A1 (en) | System and method of payment of merchants on behalf of payment card system transaction acquirers | |
US9183591B2 (en) | Virtual accounts linked to financial accounts | |
US20050216424A1 (en) | Transaction system with special handling of micropayment transaction requests | |
US20100036741A1 (en) | Application currency code for dynamic currency conversion transactions with contactless consumer transaction payment device | |
US9767457B1 (en) | System, method, and computer program for dynamically identifying a merchant associated with an authorization request for a payment card | |
US20080191007A1 (en) | Methods and Systems for Identifying Fraudulent Transactions Across Multiple Accounts | |
KR20160121550A (ko) | 복합 요금결제를 하는 시스템과 방법 | |
US20150248657A1 (en) | System and method for recovering refundable taxes | |
US20070012757A1 (en) | Identity verification switch | |
US9613358B1 (en) | System, method, and computer program for capturing a unique identifier for a merchant used in purchase transaction approval requests | |
US20110270744A1 (en) | Mobile tangible value banking system | |
US20130253956A1 (en) | Chargeback insurance | |
US20140310176A1 (en) | Analytics rules engine for payment processing system | |
AU2022201486A1 (en) | Card continuity system and method | |
US20180060839A1 (en) | Systems and methods for predicting chargeback stages | |
CN114693169A (zh) | 一种收单支付交易路由方法及装置、存储介质及电子设备 | |
CN112819473A (zh) | 一种基于数字字典的订单处理方法、服务器、设备及介质 | |
TW202014954A (zh) | 用於信用卡交易的信用卡紅利點數折抵方法及系統 | |
US20210264411A1 (en) | Web merchant balance cash in via atm deposits | |
US20170330186A1 (en) | Decision Engine for Payments | |
WO2012042277A1 (en) | Transaction systems and methods | |
US20160063620A1 (en) | System and method of facilitating payday loans | |
KR20180001980A (ko) | 공용 가상 계좌 서비스를 이용한 금융 데이터 처리 방법 및 그 장치 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |