文档章节

支付路由管理

村长杨京京
 村长杨京京
发布于 2016/09/01 15:17
字数 3607
阅读 459
收藏 3

作者:王小憨
链接:https://zhuanlan.zhihu.com/p/20060139
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
 

老王开了个杂货店,蒙街坊照顾,生意一直红红火火,慢慢地店面从一家到两家到三家,最后基本上有商业中心的地方都有了老王的店,而店面也从当初的几十平米的杂货店变成了几千平米的老王连锁超市。

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

  • 客户多了,从以前的街坊到集团大企业都来这采购,得处理的交易要好多,要能够都能交易,别临时断电断水或者人手不够,让客户买不了;
  • 合作多了,每个种类商品都有供应商,甚至同一个商品也都有很多渠道给老王供货,这些关系都要处理好,才能拿到好折扣和给到老王更多的营销费用;
  • 要求多了,那些大客户们由于地理位置、公司规定和员工喜好,每个客户要求的服务都不一样;
  • 每天的流水更大了,进进出出都是钱,老王那么大流水,总想能够怎么才能成本少一点?
  • 员工多了,供应商多了,环节多了,谁有个事怎么办,哪个环节出问题了怎么办?
  • 大主顾们、一些老朋友们和一些比较重要的客人体验得照顾好,最好能记住他们常买的,常用的,不用说就知道喜欢什么要什么;

老王对于这些问题,有着朴素的想法,就是希望都服务好。

  • 客人越来越多,老王去买了更多地收银台和准备了充电箱,防止排队过长和临时断电;
  • 合作的渠道越来越多,老王会根据合作关系、进货成本、给的营销费用以及要求,每家都进点货,维持好大家关系;
  • 大客户们的要求不太一样,老王做了好多种方案,能够根据客人的要求提供对应的打包方案,让客人们都一样;
  • 流水越来越大,老王会根据供应商们的提供的不同产品和报价,每种商品选择最合适的进货渠道;比如大米用哪种供应商的,洗发水找谁提供
  • 中间环节多了,有事了或者预计有问题了怎么办?老王多雇了些员工和多准备了供应商,并且设计了一个报表,谁有问题了,就立马找其他供应商来支持下,或者预计谁有问题了,也能自动提醒老王,让老王好提早就安排好,那个时间点应该找谁。
  • 大主顾们、老朋友和那些VIP们,一开始老王还是小杂货铺的时候纯粹靠脑记后来大了老王给他们发了个贵宾卡,通过他们刷卡消费,老王知道他们买什么,喜欢什么,下次打电话或者刷卡的时候,老王也好店员也好都知道要买什么了,客人们也满意,老王也好提前准备。

 

这是老王开店的故事,老王的遇到的问题,朴素的想法,和坚持的处理方式,其实就是一个支付路由机制的体现,承担了一个支付的收益管理职能,致力于提升用户支付成功率,做到了自动熔断、智能分流;处理高并发、大吞吐、做到支付成本最低的选择。。。。。。


那么如何实现这些了,由于一些涉及到保密,所以不便于讲的太细的请谅解 。

支付路由做为一个机制,它承担了一个支付的收益管理职能;而支付的收益管理追求的就是建立以用户需求满意度、支付成功率和收益率为目的,实现效益最大化的机制;而路由的实现是以通道为基础的,需要有丰富的通道。

如下图,作为一个路由的机制,建立引导模板展示控制场景支持支付方式展现和顺序,通过这个控制推荐支付从而达到影响用户支付行为的目的,并且引导模板支持不同商家不同展现模板,从而实现支付方式量身定制,用户支付行为记录与优化,提升用户体验,控制引导方案展示和推荐实现胡搜一最大化(里面涉及到的细节很多,不便讲的太细)。这也就是老王遇到要求的服务都不同的问题。

通过交易路由规则能够做到把适合的交易推荐到合适的地方,达到降低成本的目的;本身路由规则能够控制通道维护时间处理和通过路由的运维策略实现自动熔断,也就是故障自动切换通道,保证成功率,在支付行业中“支付成功率是第一优先级”。这里面所说的就是老王如何节省成本、老王该找谁进货以及老王遇到了问题怎么办的方案。

由于背后通道都是对应银行,平时都要处理关系,所以很多时候需要切量且自然。 通过分流的路由规则,可以设定权重、限额,实现通道流量强制分布。以及通过流量分配算法形成或正态分布或强制策略达到各支付包装产品通道控制,甚至于在降成本的方式上使得指定交易不同的通道类型又使得通道显得正常。这个也就是故事里面老王要处理各个供应商的关系。

这套机制能够走下去的前提是需要有丰富的通道,才能实现路由的分流、熔断、交易适配等等。文章里由于机密所致,很多地方只能说道浅尝即止,请大家理解。

 

作者:梁川
链接:http://www.zhihu.com/question/38278938/answer/79493500
来源:知乎
著作权归作者所有,转载请联系作者获得授权。
 

这里简单说一下第三方支付在做支付渠道路由设计的一些思路,供参考。作为商户,接入多家第三方支付,在渠道路由策略上比第三方支付的简单多。

1、支付渠道的封装层次
一般分为:银行接口->银行通道->支付渠道->支付产品->支付解决方案
银行接口指的是银行等提供的技术接口。
银行通道是对银行接口的封装,并包含了诸如具体合作银行及通道的详细信息。例如同为某家商业银行的某个支付接口,非总对总的情况,支付公司可能同时在北京分行、上海分行接入。
支付渠道是对银行通道的业务封装,包含了诸如通道成本、最低商户费率等信息。
支付产品是第三方支付对外提供的产品,例如快捷支付。
支付解决方案是针对某个行业的整体解决方案,包含了多个支付及行业定制需求。

所谓的支付渠道路由在以上的几个封装层次上都可以发生,因此以下指的“支付渠道路由”的概念是泛指,可能涉及以上各层次。

2、支付渠道路由的设计
一般采用规则引擎或类似方案(例如基于groovy),以支持对规则集灵活调整。

一个相对丑陋的支付渠道路由的设计方案(不一定很合理,仅供参考)

3、支付渠道路由的一些例子
按费率。
按业务级别。
按业务类型。
按渠道交易总额、单笔交易额、渠道限额等额度信息。
按支付渠道类型:移动支付,在线,代扣,b2b,信用卡无磁无密,游戏点卡等。
按支付渠道可靠性要求,例如支付成功率。
按商户类型。
按渠道状态,例如监控系统发现某渠道掉单率较高时候。
按照到账时效。
按所在银行账户的资金头寸。
按营销策略,例如某个渠道年底有营销活动。
按支付渠道优先级,可以是静态优先级,也可以是动态优先级,实际上优先级的也概念包含了以上各种路由规则。

其实支付渠道路由并没那么高大上,如果单纯只是满足企业当前的业务需要,用最丑陋的If-Else方式也能搞定。最复杂的问题是怎样让支付渠道路由的架构设计能够快速响应业务快速发展、业务模式创新的需要。

 

作者:MrColin
链接:https://zhuanlan.zhihu.com/p/21567401
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
 

路由系统,即智能选择最优‘‘线路’’,对于支付结算系统而言,就是要智能选择入款、出款渠道,那如何体现其智能呢?我们先看几个例子:

例子1: 现有2个渠道,渠道A的收费规则是1‰,渠道B的收费规则是2元1笔。毫无疑问,在其他条件相同的情况下,我们更愿意使用更便宜的渠道,而手续费到底哪家便宜,会根据交易金额有所不同。

路由,就是要实现节约成本!

例子2: 现有2个出款渠道,收费都是2元1笔,渠道A的到账时效一般在30分钟内,渠道B的到账时效一般在2小时内。显然,通常我们会选择到账时效快的。

路由, 就是要提高用户体验!

例子3:现有2个渠道,不管从成本上来说还是从用户体验来说渠道A都占尽优势,可是有个硬伤,此笔交易渠道A走不通, 虽然渠道B成本高点速度慢点,但是毕竟能走通且满足用户的需求,也只好使用渠道B了。

路由,就是要确保渠道可用!

还有还有,如果某个渠道突然瘫痪怎么办,傻傻的等到对方恢复吗?

以上,我们对几个最基本的点进行了考虑,总结下来就是:

路由系统,在满足当前交易的前提条件下,选择我们最希望的结果。其中,前提条件有很多,入款和出款还不太一样,一般有单笔限额、渠道当前是否可用等,后面会详述;最希望的结果,与公司的政策策略相关,一般可能考虑的是成本和用户体验。

我们看下入款(支付) 、出款(提现)渠道常见的几个限制维度:

入款:单笔限额、卡种、银行、当日限额、 当月限额等;

出款:到账时效、金额、发卡行、发起时间、账户类型(对公、对私)等,出款这块的知识可以参考之前的一篇文章《提现业务流程》;

路由系统逻辑图可以参考下图:

相关说明:

1、按照手续费从低到高对渠道进行排序,对于手续费相同的,则再依据渠道权重进行排序;

2、按照渠道排序依次对渠道条件进行检查,如果当前渠道有任一条件不满足,则该渠道不满足条件,进行下一渠道条件检查

3、直到找出满足的渠道,如果所有渠道皆不满足,则不支持本次交易。

以上路由系统逻辑模式比较适合渠道较多,判断规则较复杂的场景,如果是出款路由,且规则相对简单,也可以使用如下模型:

大致逻辑为:

1、配置N条规则及1条默认渠道

2、每条规则包含‘‘条件’’和‘‘渠道’’2个组成部分,条件由若干个条件维度组成条件集合

3、当满足此条件时使用该渠道,如此规则不满足则进入下一规则判断直到找到符合的规则

4、如果所有规则都不满足,则使用默认渠道

为了便于理解,给大家举个例子

银行A:所有出款都免费,但是到账周期偏长;

银行B:行内转账免费,实时到账,跨行转账收费;

银行C:所有业务均收费,但是5万以下实时到账,5万以上到账周期也较长

根据以上条件我们设计方案为,如收款银行为B时,则使用银行B进行出款;如收款银行不为B&金额为5万内&到账时效要求高时使用银行C出款;除以上规则外,其他所有情况使用银行A出款。

其他说明:

以上讨论的仅是简单路由系统模式,仍有许多细节没有说明,挑几个需要注意的点介绍给大家

1、每个渠道能配置是否可用,当第三方渠道出现异常时可以进行切换

2、每条规则支持配置生效时间、失效时间,不需要进行蹲守进行变更操作

3、规则调整支持热插拨,而不是写死在代码里面,不需要重启应用

路由系统,对于出款来说有路由系统就够了,一般不涉及产品层面的改动;但是对于入款而言,则最好有产品层面的相应调整。

入款产品层面的设计将在后期给出,本篇先做铺垫,大家也可以先行思考下。

任何问题,评论留言!

===========================

欢迎拍砖,鼓励点赞,建议关注

===========================

 

 

 

 

 

 

本文转载自:https://zhuanlan.zhihu.com/p/20060139

村长杨京京
粉丝 161
博文 878
码字总数 907544
作品 0
杭州
程序员
私信 提问
小程序·云开发的云函数路由高级玩法

原文链接 概念回顾 在掘金开发者大会上,在推荐实践那里,我有提到一种云函数的用法,我们可以将相同的一些操作,比如用户管理、支付逻辑,按照业务的相似性,归类到一个云函数里,这样比较方...

李CHENGXI
2018/09/21
0
0
开源计费支付平台--KillBill

Kill Bill 是一个开源的计费及支付平台 特性: 有计划管理的订阅引擎,支持添加绑定多个订阅 计价赢钱,支持多种方式的账单 有状态改变路由的支付状态及,支持多种支付网关 插件架构,允许使用...

李三石
2015/09/22
7.2K
7
【支付系统设计从0到1】支付系统流程和典型架构设计

支付业务的核心流程 1.支付应用根据用户选择的支付工具来调用对应的支付产品来执行支付。 2.支付产品通过支付网关根据支付工具、渠道费率、接口稳定性等因素选择合适的支付渠道来落地支付。 ...

金融民工小曾
2018/08/25
0
0
一文读懂:完整的支付系统整体架构!

支付产品模块是按照支付场景来为业务方提供支付服务。这个模块一般位于支付网关之后,支付渠道之前。 它根据支付能力将不同的支付渠道封装成统一的接口,通过支付网关来对外提供服务。所以,...

技术小能手
2018/08/13
0
0
这样玩云函数路由,让你看起来很高级

欢迎大家前往腾讯云+社区,获取更多腾讯海量技术实践干货哦~ 本文由李成熙heyli发表于云+社区专栏 概念回顾 在掘金开发者大会上,在推荐实践那里,我有提到一种云函数的用法,我们可以将相同...

腾讯云+社区
2018/11/02
0
0

没有更多内容

加载失败,请刷新页面

加载更多

3_数组

3_数组

行者终成事
今天
7
0
经典系统设计面试题解析:如何设计TinyURL(二)

原文链接:https://www.educative.io/courses/grokking-the-system-design-interview/m2ygV4E81AR 编者注:本文以一道经典的系统设计面试题:《如何设计TinyURL》的参考答案和解析为例,帮助...

APEMESH
今天
7
0
使用logstash同步MySQL数据到ES

概述   在生成业务常有将MySQL数据同步到ES的需求,如果需要很高的定制化,往往需要开发同步程序用于处理数据。但没有特殊业务需求,官方提供的logstash就很有优势了。   在使用logstas...

zxiaofan666
今天
10
0
X-MSG-IM-分布式信令跟踪能力

经过一周多的鏖战, X-MSG-IM的分布式信令跟踪能力已基本具备, 特点是: 实时. 只有要RX/TX就会实时产生信令跟踪事件, 先入kafka, 再入influxdb待查. 同时提供实时sub/pub接口. 完备. 可以完整...

dev5
今天
7
0
OpenJDK之CyclicBarrier

OpenJDK8,本人看的是openJDK。以前就看过,只是经常忘记,所以记录下 图1 CyclicBarrier是Doug Lea在JDK1.5中引入的,作用就不详细描述了,主要有如下俩个方法使用: await()方法,如果当前线...

克虏伯
今天
8
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部