专栏名称: 凤凰牌老熊
互联网金融,软件架构,资深Java工程师
目录
相关文章推荐
芋道源码  ·  Redis Plus 来了,性能炸裂! ·  昨天  
芋道源码  ·  防止超卖的七种实现 ·  2 天前  
芋道源码  ·  DeepSeek+Spring有搞头么? ·  2 天前  
芋道源码  ·  老板爱瞎改权限怎么办:注解+AOP ... ·  3 天前  
Java编程精选  ·  国产 DeepSeek V3 ... ·  5 天前  
51好读  ›  专栏  ›  凤凰牌老熊

20180206-互金行业支付路由实践

凤凰牌老熊  · 公众号  · Java  · 2018-02-09 06:30

正文

主题分享

支付路由通过分析支付请求的入参返回当前支付请求分配的支付渠道(支付通道)。支付路由主要作用是降低公司支付手续费、提升支付成功率。

下面以公司A作为业务主体,举例说明一下支付路由是如何设计的。

1. 业务介绍

公司有两个业务:P2P撮合业务、助贷业务。

1. P2P网贷信息撮合(已上线银行存管)

存管银行提供出金服务(提现服务)、银行存管系统负责对接支付公司,公司A不用和支付公司做系统对接,但是需要单独和各家支付公司签署支付合同,向支付公司支付手续费。

2. 助贷(自有放款、金融机构放款(直融))

  • 自有放款通过个人资金放款给借款人,然后通过债权转让模式转让给助贷机构,此种模式监管认定为不合规,业务暂停;

  • 直融模式下公司A向金融机构推荐借款人,金融机构直接放款给借款人,此种模式下还款有两种模式,一种借款人直接还款给金融机构;另一种是借款人还款给公司A,公司A通过归集还款的模式对公还款给金融机构。

公司A在助贷模式下需要和支付公司做系统对接,提供入金、出金服务。直融模式业务流程如下

2 系统框图

3 支付流程介绍

下面介绍涉及支付相关流程。

【存管支付流程】

  1. 投资人/借款人充值: 投资人/借款人在A公司的前端充值,前端请求内部存管系统,存管后台系统请求支付路由,支付路由返回支付公司代码,前端跳转到银行存管系统发起支付,银行存管系统向指定支付公司发起支付请求,支付公司支付成功后,异步通知银行存管系统,银行存管系统异步通知给A公司存管系统,存管系统通知调用方。

  2. 代扣还款: 业务系统调用存管系统发起代扣,存管系统请求支付路由,支付路由返回支付公司代码,存管系统请求银行存管系统,银行存管系统向指定支付公司发起代扣支付,支付公司支付成功后,异步通知银行存管系统,银行存管系统异步通知给A公司存管系统,存管系统异步通知业务系统代扣成功,业务系统开始记账入账等操作。

【助贷支付流程】

  1. 借款人充值还款: 借款人通过A公司还款前端充值,前端请求后台系统,后台系统请求统一支付平台,统一支付平台请求支付路由,支付路由返回支付公司代码,统一支付平台向支付公司发起支付(未鉴权先鉴权,鉴权通过后发起支付),支付公司支付成功后,异步通知统一支付平台,统一支付平台异步通知后台系统。如果支付公司没有异步通知机制,统一支付平台定时查询支付公司查询接口,内部包装异步接口,通知内部调用方。

  2. 代扣还款: 业务系统调用统一支付平台发起代扣,统一支付平台请求支付路由,支付路由返回支付公司代码,统一支付平台向支付公司发起支付(未鉴权先鉴权,鉴权通过后发起支付),支付公司支付成功后,异步通知统一支付平台,统一支付平台异步通知后台系统。如果支付公司没有异步通知机制,统一支付平台定时查询支付公司查询接口,内部包装异步通知接口,通知内部调用方,业务系统记账入账等操作。

  3. 代付业务: 暂时未接入路由,由业务系统指定支付公司,由支付平台负责和指定支付公司对接。

统一支付平台介绍:统一支付平台集中管理A公司所有和资金相关的业务,对外负责和支付公司交互,对内提供标准的接口:代扣接口、代付接口、鉴权接口和充值接口、异步通知接口,业务主要包括代扣、代付和充值。

4 支付路由规则

同一个业务比如还款,有存管还款或者助贷业务还款,如何区分,我们使用 支付场景 区分,

场景包括 :存管快捷充值、存管网银充值、存管代扣、非存管快捷充值、非存管代扣、非存管网银。

支付路由规则有 :单笔、单日、支付费用、通道维护、单日余额不足次数、最优次优通道切换 根据支付路由入参:用户、支付场景、金额和银行,返回给调用方支付通道(支付公司)代码。

具体 业务规则 如下:

(1)支持场景和银行下,是否有可用通道,如无可用支付通道则返回无可用支付通道,反之则进入(2)

(2)计算可用支付通道下的单笔最大限额,如果充值金额大于单笔最大限额则提示单笔超限,反之则进入(3)

(3)计算可用支付通道的单日限额是否满足,如果所有可用通道都不满足,则提示单日超限,反之进入(4)

(4)计算可用支付通道的单日失败次数是否满足,如果所有可用通道都不满足,则提示当日余额不足次数超限,反之进入(5)

(5)可用支付通道里排除单日、单笔和单日失败次数不满足的通道,如果剩余通道等于1,则返回支付通道代码,反之则进入(6)

(6)根据通道的费率,按照充值金额,计算(5)可用通道下每个支付通道的费用,按照费用从低往高排序,如果费用相同,则查询费用相同通道的优先级别,再按照优先级别从高往低排序。至此支付公司的支付优先级别排序完成,则进入(7)

(7)查询(6)排序最优的支付通道最近一笔是否支付成功或者无交易,如果支付成功或者无交易,则返回支付通道代码,反之进入(8)

(8)查询最优支付通道支付失败的原因,如果是用户原因,则返回最优支付通道,反之进入(9)

(9)查询(6)排序次优的支付通道最近一笔支付状态,如果支付失败并且失败原因非用户原因,则返回最优支付通道,反之返回次优支付通道。


Q&A

1 Q:您那个限额是针对到个人用户的每张卡的还是针对到某个支付通道的,还是两个都有啊?因为作为使用方,有的通道是有交易总额限制的。

A:支付通道,卡没有办法做,因为支付公司后面扣款通道我们不清楚,有可能支付公司是共用额度,有可能不是,我们都是依赖三方支付的。

Q:哦哦,一般代扣限额都是针对到某个个人卡的,比如单笔5万,单日20万这一类的,如果可以分别累加,实际上还是比较有用的。虽然现在代扣通道越来越少了。。。

A:这个是基于用户的,用户在支付通道1支付失败,他可能在支付通道2成功,所有我们系统在用户第二次支付时候,在满足一条条件下会自动切换成次有通道。您说的是通道成功率监测,这个我们整体会监控。额度问题,我们很头疼,支付公司给的额度,其实是不准确的,比如说单笔10万,单日10万,如果用户在其他商户使用同一家支付公司支付过,有可能在我们这里一笔都不能成功。这个没有什么解决方法,所以我们在前端会基于一些错误码,提示用户再次尝试支付。

Q:监控指标怎么影响通道可用性的方便介绍下么?

A:现在按照场景+银行+笔数+支付通道,笔数达到N笔,成功率低于阈值会预警。

2 Q:我有三个问题请教:

(1)批量扣款的时效性怎么保证的呢?

(2)鉴权不通过的是直接置为失败,还是重新选择路由?

(3)如果多家支付通道都需要先鉴权,您那里是怎么处理的呢?

A:回答如下:

(1)我们扣款需要实时,现在都是单笔接口,没有对接支付公司批量接口

(2)鉴权失败置为失败,不会再重试路由,为什么没有再重试,因为借款人/理财人在我司有一个前置绑卡(四要素鉴权),这个路由通道和鉴权通道鉴权结果不一致的比较少,后面可能会优化







请到「今天看啥」查看全文