支付路由设计
2017-05-21 11:44
337 查看
我们支付接了多家通道之后,支付路由就是一个绕不过去的问题了。因为许多通道都有同卡进出的要求,因此不能简单地把所有支付的流程全部抛给支付模块,业务系统只关心支付结果。因此我们的支付路由设计得比较轻。当业务系统发起支付请求的时候,需要先带着支付四要素和支付用途先查询支付模块一次,看走哪个通道比较合适,然后再按照返回的结果来调用支付统一接口来进行支付。这样,当支付必须走某一个通道的时候,可以不用查询支付路由,直接走相应的支付通道进行支付。
在支付模块内部,实现了统一的发起代扣请求接口,代扣确认接口,代扣重新获取验证码接口,绑卡接口,绑卡确认接口,代付接口,订单查询接口,对账接口,支付路由查询接口,每种支付方式还各自实现了主动通知接口。在业务系统每次调用接口的时候,都会在最后返回结果前,记录当前调用的返回结果到数据库中,用于成功率分析,支持路由查询。系统有一个定时任务,每分钟执行一次,统计最近30分钟的支付成功率。同时每10分钟清除一次30分钟前的数据到历史数据中,减少当前表的总数据量,加快统计成功率的速度。
在用户调用支付路由的时候,首先根据支付金额选择可能合适的支付通道,然后逐一通道进行分析,具体进入某一通道进行分析的时候,先看该通道该张卡如果在30分钟内支付失败过,则直接跳过该通道。如果和该银行卡前6位相同的银行卡(银行卡前6位表示一家银行发行的一种银行卡)在30分钟内的支付笔数没有超过10笔,则尝试走该通道,如果支付笔数超过了10笔,并且成功率没有超过60%,则跳过该通道。如果尝试了所有的通道,都没有合适的,则直接返回没有合适的通道。
当然以上的介绍的支付路由比较简单,因为我们业务上将需要绑卡且只能绑一张卡的通道给去掉了。我们实现相关的逻辑,但是考虑到这种通道的引入会让用户的支付流程更加复杂,同样调度也更加复杂,因此去掉了该类型通道,并且没有介绍。
在支付模块内部,实现了统一的发起代扣请求接口,代扣确认接口,代扣重新获取验证码接口,绑卡接口,绑卡确认接口,代付接口,订单查询接口,对账接口,支付路由查询接口,每种支付方式还各自实现了主动通知接口。在业务系统每次调用接口的时候,都会在最后返回结果前,记录当前调用的返回结果到数据库中,用于成功率分析,支持路由查询。系统有一个定时任务,每分钟执行一次,统计最近30分钟的支付成功率。同时每10分钟清除一次30分钟前的数据到历史数据中,减少当前表的总数据量,加快统计成功率的速度。
在用户调用支付路由的时候,首先根据支付金额选择可能合适的支付通道,然后逐一通道进行分析,具体进入某一通道进行分析的时候,先看该通道该张卡如果在30分钟内支付失败过,则直接跳过该通道。如果和该银行卡前6位相同的银行卡(银行卡前6位表示一家银行发行的一种银行卡)在30分钟内的支付笔数没有超过10笔,则尝试走该通道,如果支付笔数超过了10笔,并且成功率没有超过60%,则跳过该通道。如果尝试了所有的通道,都没有合适的,则直接返回没有合适的通道。
当然以上的介绍的支付路由比较简单,因为我们业务上将需要绑卡且只能绑一张卡的通道给去掉了。我们实现相关的逻辑,但是考虑到这种通道的引入会让用户的支付流程更加复杂,同样调度也更加复杂,因此去掉了该类型通道,并且没有介绍。
相关文章推荐
- 详述支付路由的设计方案
- 详述支付路由的设计方案
- 支付系统路由系统设计
- 支付结算之路由系统设计
- 详述支付路由的设计方案
- 【支付系统学习笔记】-二支付系统设计(支付路由设计)
- BGP进阶学习之RR设计不合理导致的路由环路
- 基于SET协议的电子支付系统模块设计
- 支付系统数据库设计的关键问题
- 一个典型PHP支付系统的设计与实现
- 路由过滤与策略路由的设计
- 路由模拟——设计方案的实现(1)
- 2012-13学年上半学期路由与交换课程设计-题目
- 12条关于网上购物支付流程设计的建议
- 关于电子支付系统的数据库设计
- 系统架构--设计模式之“路由”
- 路由模拟——论文算法设计部分(3)
- 路由模拟——论文算法设计部分(4)
- 购物网站3:订单实体类设计----配送方式--留言--订单--订单联系方式--订单配送信息--订单项--订单状态--支付方式
- 路由模拟——类设计的声明部分