支付结算之路由系统设计

本篇文章主要介绍支付结算系统中的路由系统设计，在阅读本篇文章之前，需要一定的支付结算基础知识，为了方便您的理解，建议您先参考本人知乎专栏文章《支付结算杂谈》。

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

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

路由，就是要实现节约成本！

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

路由， 就是要提高用户体验！

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

路由，就是要确保渠道可用！

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

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

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

我们看下入款（支付） 、出款（提现）渠道常见的几个限制维度：

• 入款：单笔限额、卡种、银行、当日限额、 当月限额等；
• 出款：到账时效、金额、发卡行、发起时间、账户类型（对公、对私）等，出款这块的知识可以参考之前的一篇文章《提现业务流程》；

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

相关说明：

• 按照手续费从低到高对渠道进行排序，对于手续费相同的，则再依据渠道权重进行排序；
• 按照渠道排序依次对渠道条件进行检查，如果当前渠道有任一条件不满足，则该渠道不满足条件，进行下一渠道条件检查
• 直到找出满足的渠道，如果所有渠道皆不满足，则不支持本次交易。

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

大致逻辑为：

• 配置N条规则及1条默认渠道
• 每条规则包含‘‘条件’’和‘‘渠道’’2个组成部分，条件由若干个条件维度组成条件集合
• 当满足此条件时使用该渠道，如此规则不满足则进入下一规则判断直到找到符合的规则
• 如果所有规则都不满足，则使用默认渠道

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

银行A：所有出款都免费，但是到账周期偏长；

银行B：行内转账免费，实时到账，跨行转账收费；

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

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

其他说明：

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

• 每个渠道能配置是否可用，当第三方渠道出现异常时可以进行切换
• 每条规则支持配置生效时间、失效时间，不需要进行蹲守进行变更操作
• 规则调整支持热插拨，而不是写死在代码里面，不需要重启应用

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

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

 

作者：MrColin，支付结算产品经理，略懂技术。如对支付结算感兴趣请移步《支付结算杂谈》

本文由 @MrColin 原创发布于人人都是产品经理。未经许可，禁止转载。