支付交易——路由系统

摘要

老王有家杂货店,承蒙街坊照顾,生意一直非常红火,慢慢地店面从一家,到两家,到三家,到最后基本上哪里有商业中心,哪里就有老王的店。店面也从当初只有几十平方米的杂货店变成几千平方米的老王连锁超巿。

店面大了,大家都喜欢来老王的店里买东西,老王要管理的事情越来越多,要打交道的人越来越多,遇到的问题也越来越多。

  • 店越来越多是个问题。老王有社区店、有中心店,有旗舰店;有的店开在省会城市,有的开在三四线城市,也有一些开在农村或者城乡接合部。“百里不同风,千里不同俗。”不同级别、不同区域的店,不同类型的客户偏好的商品不一样。老王要考虑给什么店铺什么样的货,一开始自己亲力亲为制定每个店的货品种类;后来生意越来越忙,只能手把手指导店长怎么做;再后来生意大了,店越来越多,连指导也没时间了。不同客户的付款要求也不一样,比如个人客户肯定都一手交钱一手交货,企业客户基本都要求有账期。老王有成千上万个企业客户,需要管理大量的客户付款方式和账期,老王很是头疼。
  • 订单越来越多是个问题。最开始只是街坊来买日常用品,现在各大集团、大企业都来老王这里定点采购。每天人流量也大,资金流也大,一家店一个小时处理的交易笔数就可能高达几千笔。“人无远虑,必有近忧。"老王就担心要是临时哪个供货商货供应不上来,或者哪家店里人手不够、导致收银台排队太长,客户不愿等待就直接走了,那可就损失惨重了。
  • 供应商越来越多是个问题。店越开越大,商品种类越来越多,提供这些商品的供应商也越来越多,甚至同一个商品也有不同渠道给老王供货。之所以选择这些供应商,有的是因为关系好,有的是因为价格低,有的是因为地理位置好,有的是出于商业风险考量。总之这些关系都要维护好,为了拿到好的折扣和便于开展生意,老王在进货的时候除了考量商业利益外,还要平衡好各方利益。

还有很多诸如此类的问题。“顾客就是上帝。”对于这些问题,老王有着朴素的想法,就是希望服务好顾客,让顾客再满意一点,自己赚得再多一点。发现问题,就要解决问题,我们看看老王是怎么解决这些问题的。

  • 方法一:老王有模板。店面越来越多,分布越来越广,老王就把全国的店按照地理位置分成不同的区,将所有店的级别简单分成一级店、二级店、三级店。老王根据不同地区不同级别的店设计了多套模板,每套模板配置了一些品种和备货数量。店长们新开了店,可以直接选用-一-套模板,如有特殊需求再单独配置。自从有了这些模板,实现备货方案秒生成,老王开多少店都能应对。对于客户的付款账期也是一样,老王把企业客户分成了大客户、中客户、小客户,账期设置成60天、45天、30天三档。如果客户需要有账期就按照这个模板来,不支持其他账期和要求。
  • 方法二:老主有分流和备份。订单越来越多,基于客户体验和未知风险的考量,老王规定收银台排队人数到达一定的量就必须新开收银台进行分流,减少每个队伍的排队人数。另外,对于每一类供应商,老王建立长期合作关系的不止一家,保证如果有一家出了问题,供不上货,其他家能够迅速补上。
  • 方法三:老王采购有策略。老王合作的渠道越来越多,有因为关系好合作的,有因为成本低合作的,有因为返点促销多合作的,还有出于备份考量合作的。从商业合作角度考虑,老王需要平衡各供应商对于进货量的要求。

老王定了3条策略,要求每个店长严格按照策略优先级执行。

  • 策略一:把合作的渠道分成组,保证每个合作渠道哪怕再差,每个月都能得到最低进货量。
  • 策略二:在满足最低进货量之后,老王就要考虑自己的成本和利润了,谁家的进货成本低、货好卖,就进谁家的货。
  • 策略三:有时候,有的供应商虽然成本不占优势,但是贴补营销费用,给的返点多,从那里进货反而划算;还有的时候,货要得急,只有某个供应商能及时供货,那就什么都不看了,就指定这个供应商。

策略优先级:策略一、策略三、策略严二依次递减。通过这些策略老王兼顾了自身和供应商的利益,维护了供应商关系,实现了自身利益的最大化。老王遇到的问题、处理问题的方式,其实就类似于路由做的事;合作渠道分组对应路由算法里的分组路由算法;按成本最低选择供应商对应路由算法里的基础路由算法;根据营销费用有返点找供应商对应路由算法里的短路路由算法;设置进货模板给不同的店使用对应路由的引导路由规则;多开收银台对应路由算法里的流量路由算法。对于老王,收益管理是既要看得见的利润,也要看不见的碑。对于支付,收益管理是既要看得见的真金,也要看不见的体验。

一、支付路由概述

在通信工程领域中,“路由”被定义为-个交换中心呼叫另.一一-个交换中心时,在多个可传递信息的途径中进行选择。选择途径的过程就是路由。生活中,我们常常见到各种路牌,如图所示。路牌的作用是指示目的地的方向,有的路近但比较崎岖,有的路远但比较平坦。路由就像智能路牌一样,作用就是指路,根据每个人的具体情况在无数的道路中选择最优的路。

在支付里,路就是接人的支付通道,比如银联、工行上海分行直连等。支付路由就是要找到既符合客户支付要求也符合自身收益最大化的路。路要求是有效的,不能是处于维护中的;路要满足客户需求,不能客户要快捷支付(好比客户要求坐飞机),你给个无磁无密支付(安排坐汽车)。

1.1 路由的定义

在支付领域,我们这么定义路由:路由系统是支付核心系统。对商户支付页面进行管理与输出、根据商户需求及通j道特性其础对交易行处理,并在此基础.上:对支付中的异常情况进行支付灾备处理。路由系统在满足用户支付交易需求的前提下,从下单到支付,进行了多处细节及系统处理,是一种以提升用户需求林验满意理、支付成功率。收益率指标和支付安全度为[目的,实现效盗地太化的收益管理机制。

另外,支付路由一般并不会直接对接前端的支付平台或者后端的支付渠道,都由支付网关或者支付系统内的支付引擎等服务调用,但为了描述方便,我们将调用服务方都统一称为“支付平台”。

路由系统的机制主要通过引导路由和交易路出运作。引导路由用来决定用户看得到的,每个商户展示哪些支付品牌以及这些﹑支付品牌的排序;交易路由用来决定用户看不到的,每笔交易走什么支付通道,如图所示。

交易订单经过交易路由系统时,系统会向支付平台返回支付引导放哪。具体包括以下方案。

  • 推荐支付方式:支付平台高亮推荐给用户支付方式。
  • 生成支付品牌列表:生成在支付产品下各个支付品牌的排列次序。
  • 推荐常用卡策略:向客户推荐常用卡的策略,如上次使用或成本优先。

交易订单经过交易路由系统时、系统会向支付平台返间支付品牌所支持的支付通道方案,决策过程如下。

  1. 计算交易手续费。交易路由系统调用计费模块,计算当前交易在每个可用通道中所需的手续费,并将通道按此次交易成本从低到高排序。
  2. 匹配路由规则。交易路由系统根据交易请求,将可用通道按照路由算法优先级进行匹配,与规则匹配的目标通道会进行交易转发。
  3. 匹配分流策略。如果交易需要分流,那么按分流策略进行转发。

1.2 路由规则发布机制

上述引导路由与交易路由的规则与方案,甚至支撑这些系统的基础信息,都是通过运营配置后台系统来实现的。首先在配置后台录入规则,然后依次将所有规则批量提交、批量审核、批量发布。发布机制生效流程如图所示,主要操作环节说明如下。

录入

  • 在录入操作中由管理员先行配置,为不同用户分配不同角色和模块权限(如查看、编辑、审核)。
  • 录入状态包括新增、编辑、设置规则状态(生效/失效)。此外,在规则尚未提交时均可再编辑,提交后则不可编辑,需要整体撤回或者等审核被拒绝后才可再编辑。

批量提交

  • 要确定生效的路由规则,必须将所有规则按照优先级顺序一起计算,因此需要将规则批量提交。在各个模块对应页面下方均有提交按钮,可进行整体批量提交,不可单一或者部分提交。
  • 整体批量提交后,无法进行此规则的增删改。
  • 提交被驳回或者主动撤回后,录人状态恢复为可编辑。
  • 提交后,流转至批量审核环节。

批量审核

  • 对提交后的规则进行审核,审核结果要么是整体通过,要么是整体被拒绝,不支持单独规则审核通过。
  • 由于有些规则是提前维护的,或者策略不是当下执行的场景,在设定规则时,需要设定生效时间。审核通过后流程流转至批量发布环节,可以设定规则生效时间。

批量发布

  • 整体批量发布可以用来进行规则的发布、驳回操作。所有成功发布的内容进入生产线上,而被驳回的内容则进入规则配置模块,规则配置模块内容变为可操作。
  • 发布完成后,每个批量发布都会有一个批次号,规则按照生效时间定时生效。
  • 我们把每次整体批量发布的规则称为一个版本,比如版本1、版本2。发布后,可以进行发布内容的查看、版本回退和数据同步。

回退代表应用于生产的规则内容回退到此版本,但此时配置后台中的数据不会变动。之所以有这个功能,主要是因为当发布的新版本有问题时,需要先回退到原版本,对新版本规则内容进行查看、修改、复盘。数据同步则代表配置后台的库数据同步为此版本数据,也就是后台系统模块看到的数据都批量更新为此版本数据。这样做是希望数据直接同步更新成某个版本的规则内容。发布确认页及版本操作页。

有些公司出于某种考虑,会让开发人员直接把路由逻辑写在代码逻辑里,等到需要调整时再通知开发修改并发布。笔者不建议这样做,从时效性和操作性来看都不合适,原因如下。

第一、支付需要接入大量的支付通道、是高颊操作.每个通道接入后都需要配置规则及策略。

  • 支付里涉及支付品牌多。全国性银行、中小行、地方城乡行、外卡组织、外卡银行,每家银行都要单独接一个通道的话,量级就是几十个乃至上百个通道。
  • 口支付里涉及交易产品多。出款产品、收款产品、转账产品、鉴权产品,不同的产品都需要接入不同的通道。每个产品里又有多个细分,比如出款产品中,同一家银行可以分快捷(协议)支付产品、代扣支付产品、无磁无密支付产品。
  • 支付里涉及交易类型多。支付里有预授权、消费、代扣、代付、鉴权等交易类型,有些通道无法满足所有类型,比如只有消费,没有预授权,这时就需要为不同的交易类型分别接人相应的通道。

  • 支付里涉及通道互备。平台出于风险、成本、交易稳定性等方面的考虑,对于同一银行特性完全相同的产品,也会接人多个通道。比如通道之间会出现系统维护,一旦维护,该通道支持的银行就不能用了,所以需要有备份通道。

第二、支付需要接人大量商户,部分大商户的规则与策略需要定制。

  • 支付里如果是对外提供收单服务,需要接入大量商户。利用引导路由的模板方案可以解决单独配置的问题,但是有很多大商户的规则与策略是需要定制的,所以就需要单独配置,且配置频率高。

第三、支付需要频繁处理日常事务。

  • 路由系统维护需要配置处理。支付通道因为系统发布、系统维护等原因,会有固定维护时间和临时维护时间。维护时间内,支付交易是无法处理的。对于这些情况,每次收到支付通道方通知,路由系统就需要进行维护,如果接入的通道数量多,那么维护就是一件很高频的事,因此需要配置处理。
  • 当出现支付通道问题时,相关的配置上下线需要操作。由于自身系统原因、商户原因或者支付通道问题本身的原因,会出现故障,造成支付成功率下降甚至不能支付。有的是系统有监控系统,可以自动下线通道,然后核查问题;有的是人工发现或者客户反馈问题,需要手动下线通道,核查问题,在将问题处理完成后再上线。

第四、路由系统的操作和配置复杂.需要有专门的运常人员负责。

  • 路由系统配置复杂,需要专门人员来配置及审核。路由系统中存在多个维度规则(如短路路由规则、基础路由规则、风控路由规则、分组路由规则等),且每个维度规则中又存在多个优先级,这些规则叠加呈现路由效果。
  • 每个规则都与通道流量分配、商户展示有关,配错了,轻则通道或自身收益受影响,重则交易无法支付成功。因此在日常配置中,除了有专门人员进行后台配置外,还需要有人进行审核,审核通过后才能生效,甚至于还要有整体规则回滚机制。

1.3 路由收益管理

路由系统通过引导路由与交易路由,从支付成本管理、支付能力覆盖面、支付通道健康度等方面做出贡献,实现自身的收益管理。

1.3.1 支付成本管理

支付成本管理是指路由系统通过自身处理机制实现手续费成本最优、人力成本下降、以不同策略保证不同场景下的偏好,达到成本最低。

支付成本最低

一个支付品牌可以有多个支付通道。比如有的按笔收费.有的按百分比收费;有的采用固定费率,有的采用阶梯费率;有的有封顶手续费,有的没有。路由机制在运作时,会根据通道属性和算法策略,实现支付成本最低。

降低人力成本

系统会将商户进行抽象,比如抽象出行业这个维度,有酒旅、零售等。有了这些抽象后的维度,在后续配置引导路由和交易路由模板时.可以极大解放人力。比如按照行业维度配置模板,将全国商户抽象成20个行业,每个行业配置一个统--模板,提前配置完成。这样商务或者运营团队即使一天接入上万家商户,因为每个商户都可以归属到某个具体行业,所以路由系统不需要额外配置,就能支撑交易的进行,达到轻量化运营,降低人力配置成本。

支付收益最大化

这里的收益是仅针对通道商业策略而言的。在商业策略上,对于交易流量的分配,除了绝对成本,还有很多需要考虑的因素,包括但不限于:

  • 日常的合作关系维护、需要每天保证合作通道固定量;
  • 通道方营销费用补贴,需要分配给指定的通道等;
  • !对于风险客户的交易,需要加强验证或者将风险转移至包赔通道;
  • 用户体验优化,如根据用户的常用品牌进行个性化展示。

路由系统在决策过程中,可按照路由策略组合的优先级实现收益的最大化。下面通过几个不同方面的例子来进一步了解交易流量的分配问题。

  • 合作关系维护方面。商户日常都会接入多个通道进行备份,也许有些通道成功率或者费率不占优势,但是也不能“有事钟无艳,无事夏迎春”,对方商务人员也需要对内交代;否则,对方长期无量,会终止合作,商户就会失去备份通道。出于合作的考虑,每天需要保证合作方有个基本量,通过路由系统可以实现给合作通道分配最低保障量,可以按交易额总量保障,也可以按交易笔数保障。通过这样的方式,维护好长期合作关系。
  • 通道指定方面。出于一些原因考虑,有时候我们需要强制指定交易走某个通道。比如出于营销补贴的考虑。拿工行的银联通道和直连通道举例,虽然银联通道手续费成本不占优势,但由于银联会出营销费用补贴给用户或者商户,对用户和商户来说,体验或者收益是最好的,那么路由系统就会指定走这个通道。再比如出于验证新通道质量的考虑。某新通道刚上线,成功率和稳定性都不确定,需要验证这个通道质量。路由系统会在上线初期配置规则,划定一部分商户走此新通道,以此来对比新l旧通道表现。
  • 风险控制方面。支付交易时,风险程度不一样,需要针对不同风险程度进行针对性处理。比如支付通道A对风险交易进行赔付,但需要验证的要素多、费率高;支付通道B验证要素少、体验好、费率低,但对风险交易不赔付。那么一笔交易如果经风险评估有潜在风险,路由就会将交易输出到支付通道A而不是B,因为A对风险交易包赔;反过来,一笔优质客户交易无风险,路由就会将交易输出到支付通道B而不是A,因为B的费率更低。
  • 成功率保证方面。在支付里,成功率是最为看重的指标,通过路由系统可以实现通道自动切换,保证交易稳定性。比如工行直连通道、工行银联通道均支持工行信用卡,工行直连21:00-23:00 临时维护,而银联不维护,那么在此期间工行信用卡交易就会自动切换到工行银联通道,实现自动熔断,从而保证成功率。
  • 商户用户的需求和体验满意度方面。支付里有多种支付方式,商户与支付方式亲近关系不一样,用户偏好不--样,都会要求按照自己的意愿展示支付方式。在商户层面,比如有的商户和微信合作关系密切,希望微信展示在前面,支付宝放在后面;有的和支付宝合作关系密切,希望支付宝展示在前面,微信放在后面。路由通过为不同商户配置不同的模板来实现这样的需求。在用户层面,比如用户希望自己常用的支付品牌展示在前面,路由系统就会在输出支付品牌时,结合常用卡服务,先输出用户常用的支付品牌。对于每个支付品牌,还可以选择是用户最近使用的通道优先还是成本最低的优先。

1.3.2 支付能力覆盖

路由系统作为支付核心系统,可以为商户在不同维度输出不同结果,覆盖各商户与业务所需能力。

  • 支付方式产身定制。在支付展业、接人大量商户的过程中,大中小不同体量、不同业务的商户对支付方式的需求存在差异。引导路由会根据行业、指定商户、平台等可拆分的原子级属性配置不同的模板,以满足用户的个性化需求。
  • 支付营销能力——活动文案量身定制。在支付业务中,银行、卡组织或者商户本身时常会有一些营销活动,用于提升其业务或者支付品牌的交易量。这时可在支付引导路由的品牌列表中通过配置展示相关的活动说明,也可控制对哪些商户展示营销文案,对哪些不展示。(引导路由只展示营销文案,具体营销的减免由营销系统完成。)
  • 支付产品能力多场景应用。在商户接人支付服务商的过程中,支付服务商会为其开通支付产品,而支撑支付产品的是一个个具体的支付通道,如图4-7所示。比如商户开通信用卡快捷产品,对应这个产品的通道可以有信用卡代扣通道、信用卡快捷/协议支付通道、无磁无密(不需要输入CVV和短信验证码)通道。根据商户接人时签订协议开通的支付产品,路由配置商户所支持的通道,而每个支付通道决定了能支持哪些支付品牌,这些品牌属于什么支付方式。

此外,在支付交易中存在多个交易类型,如预授权、消费等。在酒店商户交易场景中使用预授权交易较多,交易路由系统中为酒店配置的通道一般需要支持预授权交易类型。

1.3.3 支付通道健康度

在支付交易的过程中会遇到通道故障、网络掉线、服务不好、流量过大等异常情况,进而造成支付成功率低。针对这些异常情况,路由系统需要通过其处理机制保障通道健康与高可用。

高并发、大吞吐

在支付业务的开展中会出现以下情形。在一些特定的时间点或者大促(如 618、双11)期间,商户的订单量会比平常高出很多倍;支付展业方拓展的商户越来越多,支付交易笔数也就越来越多。路由会分析当前流量及通道的负载,进行智能分流,以保障交易的高可用。

前端收单交易笔数越来越多,但是后端接入的每个支付通道的交易处理量是限定的,银行通道的TPS ( Transactions PerSecond,每秒处理量)一般为10~l5笔/秒。遇到交易量太大、后端交易完全处理不过来的情况,如果不管不顾而直接提交交易请求,会遭遇交易失败或者系统繁忙之类的报错。即便后端支付通道处理系统进行了队列处理,也要等待较长时间,而支付交易又是极度讲究成功率和实时性的。

为了解决以上问题,前后端都做出了各种努力,比如进行队列处理、由公网接入改为专线接入等,这里说一下交易路由如何处理。路由系统在处理一笔支付交易时,如果存在多个通道均支持该交易,那么在其策略优先级里,可以做如下处理。

  1. 每个通道都在路由系统里配置 TPS容量。
  2. 建立一个计数服务,用于记录各个通道目前在一定时间内的每秒平均交易笔数,比如最近一分钟内。
  3. 路由系统计算交易可用通道时,筛选出多个通道可用,按照算法计算出最优通道的同时,调用计数服务,校验该通道目前的每秒交易笔数,看看是否已经满负荷或者触发阈值。
  4. 如果该通道TPS满负荷或者触发阈值,则路由系统筛选出次优通道,依次校验;如果 TPS还未满负荷或者触发阈值,则通过,输出该通道。

不良通道自动熔断

在金融领域,熔断机制(Circuit Breaker)是指当股指波幅达到规定的熔断点时,交易所为控制风险而采取的暂停交易措施。在支付交易系统中也存在熔断点,路由系统根据熔断点自动下线不良通道,切换至优秀通道,以保证成功率和交易可用性。支付交易系统中的熔断点有以下3个维度。

  1. 通道维度整个通道因为系统维护或升级,或者因为系统成功率较低,触发了系统阈值,而被认为不可用。这个维护时间或者阈值就是熔断点,自动下线的机制就是熔断机制。比如工行储蓄卡直连通道21:00-24:00临时维护,那么在这个时间段内系统就会将交易自动切换到另一个通道工行储蓄卡银联通道,等过了24:00后,该通道再自动上线,重新变为可用。又比如系统规定通道可用的标准是,非客户自身原因的通道交易处理成功率应该达到95%以上。注意这里说的是通道交易处理成功率,不是客户支付成功率,不论支付处理是成功还是失败,只要是合理的,都算作交易处理成功。如果交易结果是失败,但返回原因是客户卡信息有误或者余额不足,那么客户支付算作失败,但是交易处理是成功的,因为通道明确做出了反馈,并给出了对应返回码。而如果交易结果是失败,但返回原因是系统繁忙或者系统异常之类的错误,那么客户支付算作失败,通道交易处理也是失败的,因为非客户自身原因,是通道原因造成的失败。对于这种场景,支付通道每处理一笔交易,就会根据结果进行计数统计,用于计算通道健康度,触发阈值时进行下线或者降权处理。
  2. 支付路由系统维度、整个交易路由系统因故障而导致不可用,需要有个托底方案。因故障而导致不可用就是熔断点,托底方案就是熔断机制。比如在交易系统正常时,所有交易通道均应由路由输出;但是在路由系统故障、整体不可用时,前台收单网关收不到反馈,就会输出事先配置好的一套托底方案。托底方案中包括最小可用也最稳定的一些支付品牌及与之对应的通道,以保证系统可用性。
  3. 商户维度﹒某商户交易支付不成功,可能是商户自身原因,也可能是收单方系统原因。监控报警机制中有两个指标维度,一个是某商户连续多少笔交易失败,另一个是某商户在某个通道上连续多少笔交易失败。如果监控到只有某个商户或某个商户的某个通道有问题,而其他商户在该通道上的交易表现良好,那基本可以定位是商户问题,而不是通道问题。

支付路由作为支付核心中的重要机制,通过引导路由和交易路由,完整承担了由用户需求体验满意度、支付成功率和收益率所构成的支付的收益管理职能。下一-节介绍引导路由和交易路由。

二、引导路由

支付平台或者网关系统向服务清求获得所支持支付方式及品牌展示,然后服务对这个请求做出处理、并间商广返回涵兹支付方式及品牌、营销文案、推荐支付方式.常用支付习惯等信息的一揽子方案。这个服务被称为引导路出。

简单来说,引导路由用来决定用户看得到的,即每个用户看到什么样的支付列表,这个列表包含推荐支付方式下各支付品牌以及高亮、顺序、营销文案等信息。通过引导路由来实现支付列表从千人一面演进成千人千面乃至一人千面。就像老王开店一样,不同的店面进货策略决定了用户是先看到北冰洋汽水还是可口可乐。

那么整个机制是如何实现的呢?引导路由由3个核心模块构成,分别是品牌列表、引导方案和引导规则。这3个模块是包含与被包含关系,并且是依次进行的:先配置品牌列表,再在引导方案中设置(方案中包含品牌列表分流配置),最后在引导规则中配置规则(规则中包含配置使用哪一套方案)。如果只是公司内部业务,因为业务线单一,无须再与合同系统中商户所配置支付内容取交集,所以中用虚线表示商户合同系统。

2.1 品牌列表

品牌列表是一个支付品牌列表的集合,其主要职能有两个:其一,配置各个支付品牌的排列次序;其二,配置具体支付品牌的营销文案说明。

关于“支付品牌列表”创建,说明如下。

  1. 配置“列表编号”项。作为“品牌列表”主键、为方便检索和有问题时定位,列表编号-般是在定义好命名规则后自动生成。
  2. 配置“列表描述”项。这一项由编辑人员自己定义,以便于规则查找和通过描述知道规则内容。
  3. 配置“添加支付方式”项。每个列表由支付方式和品牌构成,可以添加一种或多种支付方式,每种支付方式可对应多个支付品牌。
    • 支付方式。在全集支付方式中选择配置支付方式,支付方式的配置顺序就是最终展示给用户的排列顺序。比如第一行配置支付方式信用卡支付、第二行配置支付方式借记卡支付,那么最终展示的支付方式就是信用卡支付排序第一,借记卡支付排序第二。

    • 支付品牌。根据选择对应支付方式,展示该支付方式下所映射的支付品牌。支付品牌的顺序就是最终展示给用户的排列顺序。

    • 营销文案说明。如果该支付方式有卡组织或者银行贴补营销活动,可根据需要配置好营销文案,定义好交互触发条件,比如用户选中时展示活动文案。当然此文案也可以用于维护、通知等灵活配置。

    • 配置交互设定说明。交互可以很灵活,如直接拖动调整排序,在添加支付方式或者支付品牌时指定序号,或者将每种支付方式做成单张表,这些就看具体的交互设计和产品要求了。例如,配置001为工商银行信用卡,002为农业银行信用卡。那么用户在使用信用卡支付时,就会看到排在第一的是工商银行信用卡,排在第二的是农业银行信用卡。

    • 编辑完成后,保存内容留作后续操作,也可以提交,待审核后生效。

2.2 引导方案

引导方案是设置“支付方式”与对应“品牌列表”偏好的集合,其主要职能如下:

  1. 设置方案支持的支付方式;
  2. 配置支付方式推荐高亮;
  3. 向用户推荐常用卡的策略,是最近使用优先还是成本优先。

关于“引导方案”创建,说明如下。

  1. 配置“方案编号”项。作为“引导方案”主键,为方便检索和有问题时定位,方案编号一般是在定义好命名规则后自动生成。
  2. 配置“方案描述”项。这一项由编辑人员自己定义,以便于规则查找和通过描述知道规则内容。
  3. 配置“支付方式”项。选择该方案支持的支付方式,一个方案里可以允许添加一种或多种支付方式。
  4. 配置“推荐支付方式”项。可配置一种或多种推荐支付方式,用于表明优先推荐这些支付方式。展示效果由前台控制,常见的效果有高亮等。
  5. 配置“支付品牌列表号”项。选择具体使用的品牌列表集合。品牌列表配置时并不需要配得很精细,或者与方案一一对应,最后呈现给用户的支付方式是交集--这套方案里支付方式与支付品牌列表号的交集。例如,配置品牌列表时为了减轻工作量和可复用,一个品牌列表号中配置了信用卡、借记卡和网银支付,而应用给商户时配置的方案里只有信用卡支付。那么“支付方式”与“品牌列表”的支付方式交集只有信用卡支付,用户只会看到信用卡支付下的各品牌。
  6. 配置“常用卡推荐”项。常用卡是指经过用户授权,平台保存的用户使用过的银行卡。常用卡的作用是方便用户下次快速使用。保存的银行卡数据有卡号、姓名、手机号、证件类型、证件号、有效期等。当用户有多张常用卡时,前台可根据“常用卡推荐策略”展示这些卡。若配置的是“最近使用优先”,那么就会按照常用卡的使用时间排序,优先展示使用时间近的;若配置的是“成本优先”,那么就会按照本次交易时常用卡中各支付品牌的手续费排序,优先展示成本低的。常见的展示效果有排序、高亮、隐藏等。
  7. 编辑完成后,保存用户留作后续操作,也可以提交,待审核后生效。

通过上述步骤,一个引导方案就编辑完成了。同样,根据不同分流需要、不同行业需要等场景,可以继续编辑,完成多个引导方案。

2.3 引导规则

引导规则用来根据所设置条件匹配传参,并根据命中的规则输出对应的方案。其主要职能有两个:一是配置行业或者商户命中条件规则,二是配置该规则下依权重输出单一或者多种引导方案。

关于“引导规则”创建,说明如下。

  1. 配置“规则编号”项。作为“引导规则”主键,为方便检索和有问题时定位,规则编号一般是在定义好命名规则后自动生成。
  2. 配置“规则描述”项。这一项由编辑人员自己定义,以便于规则查找和通过描述知道规则内容。
  3. 配置“推荐匹配条件输入”项。
    1. 行业类型。业务展业中,一般接人商户均可按照行业分类。运营人员会根据行业事先在路由系统中配置引导规则。这样若商户无特殊需求,则均按此行业规则进行输出,实现规则可复用,轻量化运营。

    2. 商户号。出于某些考虑,运营人员会给大商户等配置定制规则,以满足定制需求或者便于重点关注。在该商户进行交易请求时,引导规则会判断是否配置了此商户号具体规则、若有﹐直接输出此商户号规则;若没有,再去检索此商户号所对应行业的配置规则并输出。注意,“商户号”并不是必须配置的。

    3. 接入方式。同样行业或者同样商户会有多种接入方式,不同接入方式下的配置方案会存在差异。比如在网页或者移动端可以支持网银支付,但是在POS里就无法支持。常见的接人方式有App 、 H5 、 Web、 IVR(语音支付).SDK等。交易类型。如消费、预授权、鉴权等。

    4. 交易币种。如人民币、美元、英镑等。如果只涉及国内业务或者支付处理能力只有人民币的,可以去掉此字段。交易金额。可设置该交易币种下交易金额区间范围内对应的规则,用于商户分流或者A/B测试。

  4. 配置“引导方案结果输出”项。

    引导方案输出。根据上述匹配规则条件输出对应配置的引导方案,可按权重输出多种方案,也可以输出单一方案,

  5. 配置方案。

    1. 依权重输出:如希望进行A/B测试,输出多种方案,可选择依权重输出。比如引导方案12的权重值为30,引导方案29的权重值为60,那么1/3 ( 30/(30+60))的用户会看到引导方案12,2/3 ( 60/(30+60))的用户会看到引导方案29。

    2. 无权重输出:如无特别要求,一套方案就能满足需求。在该条件下选择无权重输出即可输出唯一方案。

编辑完成后,保存用户留作后续操作,也可以提交,待审核后生效。通过上述步骤,一个引导规则就编辑完成了。同样,根据不同分流、不同行业、不同币种、不同接入方式需要等场景,可以继续编辑,完成多个引导规则。

三、交易路由

支付平台或:者例关系统向服务请求可用通道,服务粮据通道信息配及规则优光级进行决策,向支付平台或者网关返最优支付通道方案、这个服务被称为交易路由。简单来说,交易路由与引导路由正好相反,用来决定用户看不到的部分,比如计算交易手续费、匹配最优通道等。就像老王开店的例子里,用户只关心饮料是什么牌子的,并不关心是谁提供的。

3.1 交易路由整体思想

前面我们提过支付关注成本、风险、成功率、体验、合作关系等。在交易路由中,有不同算法来处理这些收益或者关注点,具体为基础路由算法、短路路由算法、风险路由算法和分组路由算法。同时,还有一些用于支持整个系统的基础或辅助服务,如通道健康度系统、通道信息配置。

那么交易路由的整个服务与机制是如何实现的呢?这要从两个维度来看,路由算法优先级和路由调用节点,如图所示。下面先来大致了解一下这两个维度,后面会详细介绍。

维度一:按路由算法优先级。

交易路由服务涉及的维度有风控维度、用户体验维度、通道自身特性维度、每天保量维度。按照这些维度,交易路由服务分成风险路由算法、短路路由算法、基础路由算法和分组路由算法。

这些算法之间是有优先级顺序的。比如公司更注重于保证满足合作方的最低量,那么算法优先级就会是风险路由算法优先于分组路由算法,分组路由算法优先于短路路由算法,短路路由算法优先于基础路由算法。

  • 风控维度:根据交易风险等级匹配对应通道。常见的有根据用户、商户、金额等多维度打分得出的风险结果(高风险、中风险、低风险)来吸配通道。
  • 风险路由:在可用通道内匹配与交易风险等级相符的通道。用户体验维度:根据用户或者商户的特定需求匹配通道。常见的如一些VIP用户需要匹配要素少、支付快的通道。短路路由:在可用通道内强制指定通道优先交易分配。
  • 通道自身特性维度:在保证通道能用的前提下寻求更优通道的过程。这些过程涉及的路由算法如下。
  • 基础路由:按照交易请求匹配能用的通道,并进行成本计算和排序。
  • 每天保星维度:根据合作关系,在保证通道能用的前提下优先保证每个合作通道的交易量。分组路由:将多个通道设置成一个组,在组内按权重、固定笔数或者最低保障金额进行交易分配。

交易订单经过路由系统时,系统处理时序如下。

  1. 支付平台上送交易信息,包含商户信息、行业、交易金额、交易类型、支付品牌、用户信息和卡号等参数。
  2. 匹配可用物理通道。根据交易请求参数和通道配置信息进行匹配筛选。
  3. 风险路由匹配。在可用通道中按照风险等级进一步筛选符合风险要求的通道。
  4. 用户体验维度筛选。根据用户与卡信息,按照体验优先(如外卡通道优先不需要姓名通道)进一步筛选候选最优通道。
  5. 短路规则维度筛选。按照是否设置短路优先规则,进一步筛选候选最优通道。
  6. 分组规则维度筛选。按照候选通道是否已设置及满足限额要求,筛选最终的最优通道。
  7. 路由系统返回给交易平台命中通道及信息。路由系统返回最优通道所涉及信息,包括支持的支付品牌列表以及这些支付品牌所需的卡要素内容等。

维度二:按路由调用节点。

前台系统与路由系统在交互中会发生多次握手,按照前台系统调用路由服务的不同节点,路由调用节点分为以下三类。

  • 事前路出:用户输入支付信息前,先请求获得支付方式和品牌所需信息。
  • 事中路由:支付过程中,因为卡BIN不符等问题,需要重新调用路由进行请求。
  • 事居路由:支付过程中,因为超限等通道自身问题,需要在用户无感的情况下重新进行路由计算并支付。

3.2 路由算法优先级

不同路由算法侧重方向不同,这些算法叠加在一起后,保证了支付收益的最大化。

3.2.1 通道信息

通道是指接入的具体实体对象的通道,类似物理上不可拆分的对象,可以理解为具体的某个实体服务商或者供应商。比如银联通道、招行直连通道,一般我们也称之为“物理通道”。通道信息就是将这些物理通道的支付能力和特性进行拆解细分后的属性及具体参数。

通道信息的主要职能如下。

  • 建设配置基础数据。在通道信息模块中设置通道命名与名称,将其作为后续各配置模块配置数据的依据和交易信息中的查询内容。比如后续配置基础路由时,需要选择对应物理通道,日常支付报表也需要统计支付通道交易情况。匹配通道风险等级。根据通道自身验证要素多少、是否要验短信验证码、是否包赔等因素,设置相关风险等级。匹配对应支付产品。根据自身产品和接入的通道属性,归类支付产品,比如通道是快捷或者无磁无密(无须验证短信验证码和CVV类型),那么我们就可以配置免密支付这样的支付产品。
  • 匹配物理通道支持的支付品牌。这项是可选的,如果不希望做双重校验,完全在基础路由中控制,那么这项可以不配置。
  • 匹配物理通道支持的交易类型,如消费、预授权。这项也是可选的,如果不希望做双重校验,完全在基础路由中控制,那么这项可以不配置。
  • 设置物理通道相关联系人。比如对方业务、运营或者开发人员相关信息。
  • 设置辅助信息,如是否是专线等。

3.2.2 基础路由算法

基础路由算法是指根据配置规则匹配可用逻辑通道。配置的规则是根据同一物理通道不同属性的具体内容进行配置,如不同支付品牌、交易类型、交易金额、限额、商户、计费方式和费率等。这样的配置规则是与物理通道相对的,我们将其称为“逻辑通道”。后面我们将更多地用“逻辑通道”来代指“基础路由中的配置规则”。物理通道与逻辑通道是一对多的关系。逻辑通道是配置内容,基础路由算法是计算过程

基础路由是最底层的路由规则,虽然优先级最低,但是它就像台基。没有台基,再好的大楼、再精美的设计蓝图都是空想;同样,没有基础路由,那么风险路由、短路路由、分组路由就都无从实现。基础路由与它们是包含和被包含的关系,如图所示。

基础路由的主要职能如下。

  • 建立查询主键。逻辑通道规则号会作为后续问题定位、数据交易查询的依据。比如后续交易记录需要查询时,会直接在日志中查询逻辑通道的规则号,通过规则号定位当时配置情况或者问题。因为逻辑通道是颗粒度最细的维度所以内部查询一般都用逻辑通道。
  • 匹配通道可用性。根据商户、行业、交易金额、交易类型、支付品牌、通道是否可用、验证要素等条件匹配支持交易的逻辑通道。
  • 通道熔断自动上下线处理。可以设置固定维护时间、临时维护时间,进行自动上下线。

3.2.3 分组路由算法

分组路由算法是指有多个物理通道或者逻辑通道可用、根据分组规则中保继金额或者权重比例进行路出计算,分配交易至H标通道,分组路由主要是出于商业合作考虑,通过保证合作方交易量来保持长期稳定的合作。“不能把鸡蛋都放在同一个篮子里”,同样,老王的一件商品也需要有多个供应商。但有多个就有比较,不同供应商的商品品质有好有坏,价格有高有低,老王如果“有事钟无艳,无事夏迎春”,那么很多供应商就不愿意与老王合作了,所以老王在保证供应商产品可用的基础上,也需要时不时向商品较贵的供应商进点货,以保证合作关系的长期稳定。

在分组路由中,将多个物理通道或逻辑通道分成一组,在组内可以按照固定金额进行限额,比如按照每日或每月进行限额;也可以在多个通道之间按照权重进行分配,比如某两个通道按照3 :5的比率进行分配;还可以同时采用这两种方式,即先保证每个通道的最低量,再按照比率进行分配。

注意,如果有多个通道可用,且既存在组内通道也存在组外通道,那么路由服务需要再按照基础路由将筛选出的组内最优通道与组外通道进行成本比较、从而得出最终的最优通道

3.2.4 短路由算法

“短路”顾名思义是最短的路。短路路由算法是指有多个物理通道或逻辑通道可用时,匹配规则优先级最高的通道,不看费率,不看分组,忽略其他规则。短路路由中的匹配条件有行业、商户号、交易类型、支付品牌、交易金额、卡号段、有效时间段等。注意,短路路由中的规则是优先原则,如果短路中的通道不可用,还是会按照基础路由和分组路由规则分配交易量。短路路由一般作用于以下3种情形。

  • 情形一:某通道不占优势,但是贴补蒿销费用后,用户或平台的整体体验或者收益反而最高。比如招行信用卡交易,银联通道虽然不占优势,但有段时间有大规模贴补市场的活动,平台出于保证用户体验的原则,在活动期间会将交易分配给银联通道。举例:拿老王开店来说,某商品有江苏和江西两个供应商,江苏供应商价格略高于江西供应商,平常老王都会找江西供应商进货。但江苏供应商推出了一个营销活动:价格不变,但是用户每买一个商品,都会随机发一个红包。这时候老王为了用户体验最大化,虽然成本高点,但是这段活动期间就会选择向江苏供应商进货。
  • 情形二:某新通道上线、通道质量未知、所以不能全量放开.需要先选择某个行业下的奥体小商户进行测试。比如配置短路路由,交易优先走新通道,观察交易稳定情况,再评估是否全量放开。举例:拿老王开店来说,刚谈了一家江苏新供应商,为了检验供应商供应链情况和客户反馈,挑了一个分店做摸底,这个分店优先向江苏供应商进货,如稳定无问题,再全线放开。
  • 情形三:某通道不占优势.但却是重点战略合作客广和流量场景、懦要在其流量场景里优先使用它的通道。举例:拿老王开店来说,老王在某个大型商场卖货,该商场也是某产品的批发商。商场规定:在该商场卖的某产品均需要向该集团批发,否则不允许经营。老王看重这个商场的流量与位置,为了合作,即使这个批发商的价格不占优势,也愿意优先找该集团批发其经营的这款商品。

3.2.5 风险路由算法

前面提过支付的收益管理是围绕支付成功率、收益率指标、用户需求体验满意度和支付安全度这几个方面进行的。我们认为其中支付安全度是第--位的.因为几笔欺诈交易就可能击垮一家创业公司当遇到风险交易时,路由系统会启动风险路由。风险路由,顾名思义,就是处理风险交易的路由机制。路由与风控的交互在交易前和交易中进行。

在交易前,能够获取到用户信息、地理位置、设备信息、交易商户等信息,风控系统能够对人识别交易风险并处理。路由机制的依据是通道信息中划分的通道风险等级、通道协议是否包赔、通道要素(如是否支持验证短信验证码)、有没有可选要素。总之,思路就是要么让风险交易的客户进行更多要素的验证,要么进行风险转移,将交易路由到通道服务商包赔通道。

在交易中,通过卡BIN识别,路由系统与风控系统进行卡信息交互。比如风控系统识别用户没风险,但卡存在风险,这个时候除了上述交易处理办法外,系统会进行交易拦截,然后让人工介入。

当交易平台经过路由系统时,路由系统会向风控系统发出请求,获取用户当前交易的风险等级。我们将风险划分为三个等级,并定义好各个风险等级对应的处理方式,具体如下。

风险等级为高风险。处理方式为,交易系统直接拦截并让人工介入。路由系统遇到这类情况时,要么直接反馈给交易平台,告知此为高风险交易,无可用支付方式;要么用户输入支付要素上送交易时,通道拦截交易并让人工介入,根据人工介人情况再决定是放行还是拒绝。

风险等级为中风险。处理方式为,路由系统下发支持中风险交易的通道并验证更多要素。在通道信息中,根据通道的特性和服务商的包赔情况,将支持中风险交易的通道进行归类。当遇到这类情况的时候,路由系统会优先下发当前交易可用、支持中风险的通道,如图4-25所示;并且会在下发验证要素时,下发最大验证要素集合,如图4-26所示;同时,如果用户有常用卡(通常会反显用户数据,以减少用户输入),不会反显用户数据。这样,通过更多的支付要素验证与风险转移,实现对中风险交易的控制。在这种情况下、每家公词对于风险的容忍度和策略可能不i、比如在无中风险交易通道可用、只有低风险交易通道时,有的公司选择风险第一,不让用户支付;有的则仅仅以风险优先,无中风险交易通道就下发低风险交易通道,让用户完成交易。

风险等级为低风险。我们将低风险交易视为正常交易,按照之前所述的基础路由、分组路由、短路路由进行交易即可。

一般我们设计的规则对于中风险交易,采用风险优先原则,即优先走支持中风险交易的通道。当无中风险交易通道可用时,下发支持低风险交易的通道。如果同一风险等级中有多个可用通道,那么依据上述的基础路由、分组路由、短路路由筛选出最优通道。

交易订单经过路由系统时,系统处理时序如下。

  1. 支付平台上送交易信息,包括商户信息、行业、交易金额、交易类型、支付品牌、用户信息和卡号等参数。
  2. 获取物理通道信息,包括通道是否关闭、通道支持行业、通道支持交易产品、通道支持交易类型、通道风险等级。
  3. 匹配可用物理通道。根据交易请求参数和通道配置信息进行匹配筛选。
  4. 筛选物理通道是否超限。根据匹配出的可用物理通道和是否有限额,查询计数服务通道是否超限,并筛掉超限通道。
  5. 筛选用户卡号在可用物理通道是否超限。根据用户信息及卡号判断用户在该物理通道和银行是否超限。
  6. 调用风险系统获取用户风险等级。根据风险契约要求,上送用户信息、商户信息等数据获取风险等级。
  7. 筛选可用逻辑通道。对于筛选出的最终符合限额规则的物理通道,根据配置行业、交易类型、单笔限额、通道是否关闭、卡要素等条件匹配对应的逻辑通道。
  8. 筛选符合风险等级通道。在多个可用通道中匹配通道信息中符合风险等级设定的通道。
  9. 如果有多个符合风险等级的通道,则依照路由规则(短路路由、分组路由、基础路由)逻辑筛选出最优通道。
  10. 下发最优逻辑通道的最大验证要素集舍。

在原有规则基础上增加风险路由规则,就完成了上述配置及应用。风险路由是保障交易安全的重要服务。通过上述各模块的应用,我们完成了初步的路由支付收益管理机制:既能满足成本最低,也能兼顾公平分流给备份通道;既可以通过配置化对特殊情形进行针对性的处理,又可以对风险交易进行很好的控制。以上讲的是路由各模块的功能,相当于路由的原子级能力,那么在不同的节点如何调用路由服务呢?

3.3 路由调节点

整个交易过程中有很多节点,有交易系统提交请求给支付系统,收银台暂时还未展示的节点;有在收银台界面输入支付要素的节点;有输入完成支付要素,提交整个订单的节点。在这些节点,支付系统前端都会与路由系统进行交互,以保证支付的高可用,从而不断提高支付成功率。我们将这些不同节点与调用路由的关系分别称为事前路由、事中路由和事后路由。

3.3.1 事前路由

事前路由是用户发起支付,支付平台为了向用户展示支付方式、银行、输入要素而向路由系统发起请求的过程。前文已经介绍了如何调用路由服务以及路由服务有哪些算法与功能,这里不再赘述。绝大多数公司都会做事前路由,但这还不够,会带来一些问题,我们将在介绍事中路由和事后路由时进一步说明。

3.3.2 事中路由

事中路由是指在支付交易过程中,用户输人卡号、护照等支付要素,支付平台根据输人要素进行判定,若事前路由下发的最优通道不支持此交易(如不支持此卡BIN或者证件类型),会再次请求路由服务,获得支持此要素的支付通道的处理机制。绝大多数公司只做了事前路由,甚至只做了路由中的基础路由,这样仅仅能够解决能用的问题,要想不断提高支付成功率,就需要做事中路由。

图]展示了平台支持的支付品牌,选择后会进一步展示需要的支付要素。但因为每个通道支持的卡 BIN不一致,支持的证件类型也不一样,如果只有事前一次路由,就会出现问题。比如用户输人卡号后,若最初下发的通道不支持用户所输入卡号的卡BIN;又如最初下发的最优通道只支持身份证,而用户要使用护照;这些场景都会造成支付失败。对于上述情况,大致有以下3种可能的应对方法。

方法一:提示用户换卡,但也许用户并没有其他银行卡,想换也换不了;也许其他银行卡用的证件也是护照,换了也没用。另外,不管换了后是否成功,都会影响用户体验,因为支付时间

方法二:不管不问,直接将交易提交到支付通道﹑最终结果就是产生大量的支付失败和报错提示。用户自己根据报错提示,了解到要换卡;或者不停打电话给平台或银行的客服,询问为什么支付会失败。这样不仅会影响用户体验,支付成功率也会下降,而且用户还可能陷人死循环,比如用户一直输人护照号码尝试支付,虽然每次输入的要素都对,但系统一直报错“卡信息有误”。

方法三:将交易转移到支持此支付要素的通道。在支付过程中,如果已经识别卡号不支持或者证件类型不支持,那么最好的办法就是找到支持的通道,并且在用户无感知的前提下替换掉原有通道。至于实现,这就是事中路由要做的。

事中路由如何提高支付成功率?图4-29所示为用户选择某个支付品牌后平台展示的需要的支付要素,下面从卡BIN、证件类型、姓名三个支付要素出发,阐述如何提高支付成功率。

支付要素一: 卡BIN

用户输人卡号后,系统要判定通道是否支持这个卡号.其实就是判定通道是否支持这个卡号的卡BIN,前文介绍过,同一个支付品牌可对应多个支付通道,但每个通道支持的卡BIN并不完全一致,也并不能支持某发卡行发行的全部银行卡。如果只有事前一次路由,就会带来一些问题。

由于事前路由的时候并不知道用户卡号,只能假设通道支持该支付品牌的所有卡 BIN,根据路由各模块优先级筛选出最优通道。比如用户输入卡号后,支付平台发现最初下发的通道不支持用户所输入的卡 BIN,如果继续提交支付,会支付失败,只能提示用户换卡。甚至会让用户陷入死循环,用户不仅无法支付成功,而且不知道原因,这样既影响支付成功率,也影响业务的成交。

卡号再第一行(在所有卡号甚至单独占一个页面),用户往往先输入卡号,这样的设计背后是有逻辑处理原因的。用户输完卡号,会针对卡号进行校验,判断此卡号路由下发的最优通道是否支持,如果支持则继续按照原有流程进行,如果不支持,会去找支持此卡号的通道。如果找到支持的通道,页面要素会换成此通道需要的要索。如果没有支持的通道,那么就直接提示“用户暂不支持该卡,建议更换其他银行卡”,不让用户再继续下去了。这样的机制可解决卡号不支持问题。

我们还是拿老王开店的故事来举例。老王的管理结构如图4-30所示,就像路由系统没有事中路由的时候。老王要批发康师傅红烧牛肉面,系统根据比价推荐,只比品牌,康师傅供应商老甲的货便宜。老王找到老甲批发,老甲没有红烧牛肉面,但有鸡汤面。老王要么换种面,就跟用户换个支付品牌一样,从工商银行信用卡换成农业银行信用卡,要么再打电话找其他供应商。这种情况下,如果运气好,那么多打个电话,费点电话费,就能找到供应渠道,解决问题,就像支付里成功率下降了一些。但如果系统只维护了哪个供应商支持什么牌子,每次都推荐老甲,其他支持的供应商怎么都出不来,老王只能放弃购买。

老王针对问题升级了产品索引表,新的管理结构如图4-31所示。就像路由系统有了事中路由,系统先找产品型号再去找具体的供应商,这样保证每次都能找对人。

支付要素:证件类型

支付要素中证件类型不仅有身份证,还有护照、士兵证、回乡证、台胞证等。在支付中如果下发的最优通道不支持用户所选的证件类型,就需要事中路由进行再次路由,找出匹配的通道,从而避免用户因证件类型不被支持而无法完成支付。

为了避免前台进行无效请求,路由系统也会在事前路由阶段将下发证件类型分为两个字段:当前通道支持证件类型,其他通道可用证件类型。当前通道支持证件类型指的是下发的最优通道支持的证件类型,其他通道可用证件类型指的是支持当前交易的其他通道的证件类型全集。

例如,某交易有A、B、C三个通道可用,A通道支持证件类型为身份证,B通道支持证件类型为护照、身份证,C通道支持证件类型为护照、台胞证,那么事前路由下发参数时,就会下发类似如下结果:最优通道为A通道,当前通道支持证件类型为身份证,其他可用证件类型为身份证、护照、台胞证(B+C证件类型的全集)。这样用户在选择不同的证件类型时,前台就会知道通道是否支持,是否需要直接提示用户换卡等,从而避免无效请求路由,提升效率。

支付要素:姓名

在银行柜面办理银行卡时,护照的姓名录人方式为字母。但由于不同地区、不同阶段历史、不同柜面办理人员存在差异,以及历史上对于姓名英文录入规范的缺失,导致同一个姓名用字母录人后的结果多种多样,这会带来一-些问题。下面以中国用户WANG XIAO HAN为例来说明。

  1. 大小写问题。有的系统对姓名是首字母大写,有的是全部大写,有的是全部小写。对于用户WANG XIAO HAN,系统就会存在WANGXIAOHAN、WangXiaohan , wangxiaohan等样式。
  2. 空格问题。在录入姓名时,有的业务人员在姓和名之间加空格,有的不加空格,还有的在每个字的字母之间都加空格。系统里就存在WANG XIAOHAN、WANGXIAOHAN、WANGXIAO HAN等样式。
  3. 姓和名位置问题。按照英文写法名在前,姓在后,但在实际操作时,由于业务人员的录人差异,会存在有的是名在前、姓在后,有的是姓在前、名在后。于是在有的地区是WANGXIAOHAN,而在别的地区可能就成了XIAOHANWANG。

以上三方面问题加在一起.一个姓名的排列组合有几十种。毫不夸张地说、当用户字母作为姓名时.支付时很可能要尝试好几十次。结果就是支付成功率受到严重影响、用户体验很差,大多数人可能试了儿次不成功后就放弃了。

对于上述情形,大多数情况下银行系统接口无法适配所有情况,因此对于支付平台而言,解决的办法就只有尽可能不让用户输人姓名,但前提是有支付通道支持。

我们在检索到用户输入姓名需要为字母的时候,可以优先路由不需要姓名的支付通道,从而规避掉此类问题。比如在外卡交易中,只需要用户输人卡号、有效期、cVV的支付通道是比较常见的。那么当我们识别道卡商外卡或者证件类型是护照时候,让系统有限不需要走证件类型的通道。

3.3.3 事后路由

事后路由是指在支付交易过程中,识别通道方返回的交易码,将一些因为通道方原因(如通道超限)造成的交易失败进行重试以挽回交易。

这需要根据返回码进行精确筛选、区分,每个通道的返回码都不一样,这里不一—举例说明。

在路由调用的节点按照路由算法优先级做出最优支付选择,实现对交易决策的最优解、达到对支付成功率、支付体验满足度、支付收益、支付安全度等方面的收益管理。

博文参考

《支付方法论》

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
使用青苹果影视系统(MacCms)可以快速搭建一个免更新、免维护的影视聚合、影视导航、影视点播网站。 青苹果影视系统(MacCms)功能列表 1、数据模块 一键对接市面上的影视资源站API接口、现已支持FeiFeiCms、MacCms、MaxCms、SeaCms等常用的影视CMS接口。 2、自适应模板 系统支持一套模板自适应电脑、手机、平板、公众号等多个终端入口,也可以独立设置移动端与PC端模板分离。 3、点播模块 视频模块的基础在线点播功能,使用大名鼎鼎的Dplayer作为H5播放器、常见的包括mp4、m3u8、flv、mp3等格式都支持。 4、微信公众号 可对接微信公众号开发者工具(影视机器人系统),对接后微信用户可以通过回复关键字直接搜索相对应的影片进生点播。 5、图片延迟加载 网站前台图片列表采用图片按需加载技术,加快用户对网站的访问速度,同时也可以节约服务器带宽。 6、简繁体转换 网站前台已集成简繁体自动转换功能,网页加载完毕后会自动根据浏览器地区进行语言转换,是做繁体点播站的首选。 7、焦点图模块 通过焦点图模块可以在首页首屏重点推荐与展示视频或广告图片,移动端与PC端独立管理,支持手机滑动。 8、广告模块 系统预留多个广告位,移动端与PC端独立管理,只需在后台对应广告位添加广告代码即可,可通过标签在模板里扩展调用。 9、链接模块 系统预留首页友情链接、全站链接,友情链接用于站长之间互换,全站链接主要用于一系列关键词主题内部链接使用。 10、导航模块 基于DaiCuo后台开发框架的导航组件调用,主导航为系统全站频道链接,图标导航为移动端首页图标小组件。 11、分类模块 基于DaiCuo后台开发框架的分类组件设计,可支持一级分类与二级分类,支持不同分类调用不同资源站独立设计。 12、搜索模块 支持同一关键词调用不同资源站的搜索结果,搜索条件需要根据资源站支持的类型,通常为主演、片名、导演搜索。 青苹果影视系统(MacCms)程序优点 1、开源免费:我们传播开源的理念、MacCms是一款免费、开源的PHP电影程序,无任何加密代码、源代码完全公开、安全有保障、无后门隐患。 2、稳定安全:内核安全稳定、PHP+MYSQL架构、跨平台运行。ThinkPhp+Jquery+BootStrap组合、超强负载能力助您轻松运营百万级站点。 3、返璞归真:没有那些花里胡哨的鸡肋功能、回归电影视频站的核心本质“免费观看”、本程序试图以最简单的架构方式免费为网民提供点播服务功能。 4、自动站群:如果您已经拥有一个影视聚合、点播网站,则可以通过其API接口直接与MacCms对接,主站更新、所有站群体系自动同步。 5、插件多:系统基于DaiCuo后台开发框架进行开发,在网站后台可以通过DaiCuo的应用市场在线安装与管理网站多个实用插件。 6、免维护:一次安装即可、24小时跟随影视资源站自动更新,省去采集、生成等繁锁工作,您只需专心运营网站与流量变现即可。 7、伪静态:系统依赖于ThinkPhp5强大的路由模块,通过后台可根据站长需求设计非常有利于搜索引擎喜欢的目录结构方式。 8、云解析:系统提供的云播放器使用Dplayer集成各主流视频网站的点播、解析功能,您也可以在后台一键设置调用第三方解析接口服务。 9、强缓存:系统依赖于ThinkPhp5强大的缓存模块,通过后台可随时切换为文件缓存、Xcache、Memcached、Redis等缓存方式。 青苹果影视系统(MacCms)安装说明 1、将文件夹下所有的文件上传至您的网站空间 2、如果您的主机为 window 操作系统,请将以下文件夹的IIS用户加上写入权限 3、如果您的主机为 linux 操作系统,请设置如下文件夹权限为 777     ./datas/* 系统运行缓存目录 4、通过浏览器访问后台进行网站基本配置(强列建议将admin.php改一个不容易猜到的名字)     http://您的域名/admin.php,默认用户名是admin 密码是admin888 5、系统默认是Sqlite3数据库,如果需要转换为Mysql则通过后台的数据库转换功能完成
睿谷信息管理系统(简称:RGCMS)是一套开源的建站管理系统,使用PHP语言编写,框架为Thinkphp5.1.+,数据库采用MYSQL数据库。 睿谷信息管理系统特点: 自定义各种栏目模型、功能模型,以便适应各种生产场景,模板路径文件自由定义 扩展字段,灵活调用,系统没有太多的固定模板标签,大多数标签都是根据自定义的字段来调用 后台使用LAYUI框架,强大的TP模板标签和缓存机制使得内容以毫秒级呈现 过滤机制以及黑名单阻止非法入侵,同步TP官方更新框架,及时修补各种问题 一个后台管理N个站点,可以创作多语言站,也可创作站群,也可根据需求定制各种应用 系统免费提供邮件、七牛、短信等第三方流行接口 有层次的权限分级,让管理变得轻松方便,自定义不同的组别,分配不同的权限 节省空间资源,同一张图片或同一个文件,在第二次上传时会自动获取原来上传的文件地址,有效节省空间资源 一键复制站点,快速创建分站 多图上传可以标注每个图的描述标题等 无限分级,前台可无限调用,同时可对栏目字段进行向上追溯调用,如当前栏目无栏目图,可自动调用上一级栏目图,直到有图为止 可设置栏目访问级别,如对会员组设置访问权限等 内置素材库存储所有上传资料,直接点击选取即可调用素材 关键词内链机制、SEO标题、关键词、描述设置,自动百度链接提交功能 在线模板编辑,无需FTP即可在线管理 批量添加栏目、批量添加内容 免费开源:无任何授权,无任何后门和加密,放心免费使用,RGCMS的发展离不开您的宝贵建议 睿谷信息管理系统更新日志: 版本号:1.12 更新时间:2020-02-01 更新内容 更新Layui至最新版本2.5.6 新增HOME模块和USER模块的中间件 修复搜索和功能模型标签冲突的BUG 修复域名绑定分站存在的逻辑上的缺陷 完善栏目会员阅读权限 版本号:1.11 更新时间:2019-12-10 更新内容 修复插件在某些环境下不解析插件标签的bug 修复系统在安装时,数据库表丢失以及数据不全的bug HOME模块增加2种语言包(zh、en) 新增简易编辑器字段 新增多内容字段以及多内容调用标签rg:cons 新增文件下载路由规则 新增会员系统路由规则 新增会员表单功能,需要会员登录的表单为会员表单 新增会员功能配置 新增多文件字段以及多文件调用标签,可隐藏实际下载地址rg:files 新增会员所属管理员管理功能,user表新增admin_id字段 新增会员提交表单,只允许所属管理员管理功能 新增会员系统(开发中) 新增后台会员菜单管理(开发中) 新增开发者管理员可在后台直接登陆其他管理员后台 更新敏感词库 更新SEO站点链接提交规则 更新系统标签,完善优化了标签的功能,手册同步更新 调整了搜索模型,支持更多模型和多字段、多条件搜索 调整缓存结构,优化了系统执行流程,效率进一步提升 调整详情页路由规则,去除show字样 版本号:1.10 不建议覆盖升级 更新时间:2019-11-11 更新内容 后台layui更新至v2.5.5 新增后台列表数据筛选功能,支持时间筛选 新增后台列表点击表头排序功能 新增插件机制,免费提供筛选插件 新增地区库(暂无用途,以便后期开发地区站群功能) 新增设置访问记录条数,避免造成爆库 新增站点起始访问数字段 新增全站页面敏感词过滤功能,敏感词将过滤成*星号 新增系统安装时php版本小于7.0环境下检测always_populate_raw_post_data是否支持 新增开启打印、导出EXCEL功能 新增域名绑定分站,后台新增域名管理板块 新增、调整部分标签,使用更直观更合理 新增删除站点时自动清除当前站点Session 新增栏目模型、功能内容、表单的内容列表设置默认排序字段及规则 新增日期自定义字段的类型选择 修复前台表单提交存在XSS漏洞 修复UE编辑器插入动态地图不显示的bug 修复后台编辑器插入视频不生效的bug 修复后台管理员列表内容丢失问题 修复高版本安装系统时eregi函数报错 修复后台模板编辑中存在的安全漏洞 修复后台模板管理对中文目录和中文命名的支持 修复系统全面支持https协议 增强后台登陆时数据过滤 改进delete_dir函数,优化清理缓存和清理静态首页的过程 局部更新了系统语言变量 优化后台权限验证方法 重构seo标题、关键词及描述规则,取消了Rgseo类 重构后台系统配置模块,以便后期二次开发 后台强制token验证,有效防范CSRF攻击 重构路由,提升访问性能 调整后台功能模型和表单管理,新增统一管理页面 调整了前台home模块内核,重构了首页、栏目页、详情页以及其他页面程序代码 合并栏目内容列表中的移至回收站和彻底删除功能按钮 优化访问记录,去除获取第三方IP数据 后台配置取消了模板路径设置,取消了对后

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

庄小焱

我将坚持分享更多知识

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值