写点什么

稳字当先的出金系统的演进

  • 2020-03-15
  • 本文字数:3555 字

    阅读完需:约 12 分钟

稳字当先的出金系统的演进

一、引言

出金系统:对接银联、网联。以完成用户资金结算(提现)。


出金系统是公司将资金结算到用户的最后一道流程,一旦出现异常导致重复结算,则会直接造成公司的资金损失,所以我们秉承一个原则:

二、名词解释

出金:从备付金提现至用户银行卡


网联:这里特指网联付款业务


银联:这里特指银联客户资金结算


渠道:出金渠道,指银联客户资金结算,网联付款业务。可以利用其能力完成用户提现。


退票:银联渠道先告知出金成功,后因账户或者其它原因资金退回。

三、“稳” 的几个原则

3.1 不更换提现流水号

流水号在请求出金渠道前生成,一旦生成,则后期不再变更。保证单一,降低系统复杂度,充分利用渠道幂等。


之所以这样,我们做了以下分析:


  • 流水号在什么场景下需要更换?

  • 在当天第一次请求渠道后,如果因系统在处理报文过程中有数据异常导致渠道提现失败,需要重新修正数据更换新流水号请求渠道。

  • 这种情况出现次数多吗?

  • 报文拼装等异常,在测试阶段已经基本排除,极少会出现拼装异常导致渠道失败,正常的情况下,渠道能达到 99.9%以上正常受理,而且就算失败,也多是因为账户本身错误相关,与流水号无关。

  • 出现了渠道失败,但账户本身没问题,换流水号能解决的时候怎么办?

  • 我们目前有两个出金渠道,网联与银联。我们优先使用网联,如果出现异常,我们不换流水号,在确保当前渠道确实失败的前提下,切换到银联渠道重试。

  • 如果切渠道还是不能成功怎么办?

  • 此次提现置为失败,用户检查账户信息重新发起。

3.2 不更换交易时间

记录第一次请求渠道的交易时间,之后与渠道交互不更换时间。这样以来可以充分利用渠道对于当天同一流水号的幂等的特性。


之所以这样,也源于渠道的幂等性,渠道给出的幂等保证为:同一机构,当天流水号唯一。

3.3 严格控制异常交易处理

控制异常处理,未经确认的异常交易种类,不允许处理。


出金系统只自动处理渠道明确的成功响应。除此之外的响应均进入异常处理流程。


接入的出金渠道返回的异常信息比较繁多,对于每一类异常,出金系统接收后,先经人工判定,只有明确后,更新到运营操作里才可对其进行相关操作,没有确认并处理过的异常交易种类不允许处理。


采取这种方式,在前期会投入一些人工成本,但能保证其准确性。在处理了大部分异常种类后。人工投入也相应减少了。


在此基础之上,我们再考虑进行系统自动处理异常,逐渐减少人工成本。

3.4 捕获所有系统和业务异常

在收到提现的请求,通过幂等判断及参数校验,就可存入数据库。出金就返回给上游受理状态。


剩下的异常都捕获,能让上游感知的,都是明确的、确保出金不能处理的异常。


出金受理提现请求后,异步进行提现渠道交互,不会因任何交互异常而影响上游获取结果的准确性。

3.5 充分利用资金监控手段

接入资损防控系统,按照定义的监控规则,一旦有异常提现,会通过多种告警方式通知,以便能及时处理。


接入渠道对账系统,利用其能力及时发现交易不对等的情况,通过告警感知并及时处理。

3.6 提供多种快速熔断手段

提供多种主动熔断手段,在系统异常时及时中断出金以减少影响。

四、系统建设过程

4.1 接入银联客户资金结算业务

银联处理交易的方式:同步请求受理接口,得到受理结果,异步通过回调通知交易结果。


做为初入支付领域的新人,初次与银联打交道。发现接入文档中异常的罗列并不完整。因没有经验可遵照执行,为保证资金安全我们选择了仅处理明确的交易成功状态。对于其它状态归为异常。初期投入人工成本,对于常见的异常类型进行必要的统计,人工判定后,再进行重试、同步状态、置为失败等操作。以保证提现异常处理的准确性。


之所以做出初期投入人工成本,也是考虑到实际在投产后,异常交易数量占比应该不会太高,因为提现时用户进行信息填写时,相对还是较为谨慎。如果填错信息,一是浪费了提现处理时间,再者严重的话会导致资金损失。在实际上线后,也验证了我们的想法。在经过梳理需求,参照银联客户资金结算接入文档后,定义出提现处理的主要流程:



以上阶段中,每个阶段都会出现异常情况,所以需要有补偿操作:


在处理所有异常交易前先将交易存在异常处理缓存池中,在每个补偿完成后,再将交易从缓存池中清除,以避免重复补偿


一阶段:成功落库提现记录,但长时间处在申请状态。


补偿逻辑 获取超过一定时长的申请提现单,查询缓存中是否有该交易,如无,则重新发起进入二阶段。


二阶段:请求超时或者无响应,这时系统需要进行补偿处理。


补偿逻辑


a. 以入库的交易时间和交易流水号先发起交易查询,如果仍无响应,则等待下次补偿再次尝试


b. 得到查无交易响应,重新发送报文到银联


c. 得到重复交易响应,进入三阶段


三阶段:长时间未收到异步回调


补偿逻辑: 适时发起状态查询请求及时同步状态。避免异步回调时间较长或者没有收到异步回调导致交易状态不能及时更新。


四阶段:上游未能及时收到结果


补偿逻辑: 提供提现状态查询接口,上游可调用及时获取结果


设计并实现以上补偿逻辑后,从正常提现到异常处理就相对完整了。测试完成后投产上线,运行结果良好,出现的提现失败,做了对应统计,对银联的常见异常及处理方式有了很好的把握。

4.2 出金运营功能

因系统只自动处理成功的提现(自动发送成功消息 &通知上游业务系统),所有异常交易,需要人工进行判定并处理。


所以在上线银联渠道的同时,我们也上线了运营功能,提供后台页面以供使用。


出金运营功能:


  • 打回:设置提现为失败,并发送失败消息通知上游。

  • 同步:主动查询渠道状态,同步出金交易状态。

  • 重试:重新按原交易信息封装报文请求渠道。

  • 切渠道:此功能是网联上线后才具备的,用于网联渠道提现失败后,切换到银联重新提现。前提是保证不重复出金。


因银联对于提现的异常交易,响应了不同的交易响应码。所以以上操作均是按响应码来判定是否可被操作。


新异常提现操作流程:


出金 --> 得到异常码 --> 人工确认 --> 配置此类异常可用操作 --> 运营操作(填写对应文案给上游及用户展示)–> 系统保存处理文案


同类异常出现后,下次处理时:


出金 --> 得到异常码 --> 运营操作(自动填充之前的处理文案)–> 操作


同类异常处理时,自动填充处理文案,提升了人工处理效率,也降低了不同处理人员在处理异常交易时的判定成本。

4.3 接入网联代付业务

网联的交易处理方式:同步请求,同步响应提现结果。对于同步未能正常处理的,7 分钟内做出异步通知。


提现如果仅有单一的一个出金渠道肯定是不满足需求的,所以紧接着我们着手接入网联。提现流程仍和之前定义的一致,稍有不同的是,因网联将异步交易做成了同步响应,所以在提现正向请求时,少了处理异步回调的逻辑。但对于网联本身处理过程中,产生的一些处理中交易,网联仍会通过异步的形式来告知我们。所以处理异步回调。



由于网联的处理方式是同步响应出金结果,而在此过程中,对于账户不正确这类异常,也是能快速得知,不会产生退票(因为一旦有退票产生,会对上游也有影响。上游需要针对退票情况做出相应的资金调整)。所以网联上线后,我们将网联做为主要的出金渠道。

4.4 设计出金路由

目前出金系统具有两个出金渠道,这就涉及到出金渠道的选择及控制。


我们面临的需求


  1. 当出现渠道不可用的情况,比如银行维护,专线维护等,我们可以暂停或者关掉某一渠道。

  2. 对提现单笔超限额,月累计,日累计进行控制。

  3. 路由初期,无法预料之后出金路由的规则的变化及数量,希望能做到灵活,可扩展。


在路由实现过程中,相对难以控制的是对于累计金额的处理,主要面临以下几个问题:


  • 一:数据计算的实时性

  • 二:数据计算准确性

  • 三:计算性能

  • 四:实现复杂度


备选的两种方案


  1. 缓存加内存计算

  2. 数据库统计



对比两种方案后,最后选择了数据库统计,并应用了优化的方案。经验证,完全可以满足性能需要。


概要设计


我们抽象了规则及规则详情,存入数据库:


规则:主要包括执行的优先权重,判定条件。


规则详情:用于填充判定条件的具体内容。


在执行规则时,用规则详情去填充规则里的判定条件,通过规则执行引擎来执行并拿到结果。


这样以来,具备了较好的灵活性,能通过配置和添加数据库数据来扩展路由。在之后我们通过这一功能,快速了添加了渠道黑名单控制这一需求。


对于累计金额的处理:利用数据库中 sql 的 sum 函数进行统计,只不过统计近 1 小时的实时数据。1 小时之前的数据,以天的粒度,启动一个定时任务每半小时计算一次并存入一张辅助表。所以 sum 运算时联表相加即可。


实验证明,可满足每 1 小时 50W 笔提现量。如果有更大的提现量,可以再缩短实时统计的数据范围,比如缩短至统计近 10 分钟的实时数据,加上每 5 分钟计算更新前 10 分钟的提现金额。

4.5 目前提现流程

五、后续的优化

面临一个相对陌生的领域,只能摸索前行,在没有经验指导的情况下,渠道的接入方式有所不同,加之面临紧张的上线周期安排,所以在有些设计细节回过头来想一下,可能并不很合适,还需投入精力做优化,但是,所有的改动及优化,前提还是只有一个:稳


2020-03-15 20:191135

评论

发布
暂无评论
发现更多内容

作为铭文跨链赛道龙头,SoBit 有何突出之处?

BlockChain先知

年底离职潮来了!来聊聊程序员的离职跳槽

伤感汤姆布利柏

程序员 涨薪 离职 跳槽

基于E3PO平台设计的一种自适应360°视频传输方案

Geek-yan

漫谈人工智能在各行业的应用以及促进和发展

迷彩

人工智能 AI 发展趋势 AIGC

人工智能与教育:机遇与挑战

啊川..

ARBT阿尔比特质押挖矿系统开发丨源码详情

l8l259l3365

如何使用 NFTScan NFT API 在 Gnosis 网络上开发 Web3 应用

NFT Research

API NFT\ NFTScan

2024新趋势下的“电力行业数字化转型建设方案”

优秀

数字化转型 电力 电力可视化

大数据、人工智能与大模型:技术融合的未来趋势

liang

物联网时序数据库 IoTDB 荣获清华校友三创大赛 AI 大数据赛道种子组一等奖

Apache IoTDB

深入解析 C 语言中的 for 循环、break 和 continue

小万哥

程序人生 编程语言 软件工程 C/C++ 后端开发

WorkPlus局域网即时通讯软件的领航者,连接高效协作的利器

BeeWorks

客户说|PolarDB分布式版助力韵达“客户管家”全面上线

阿里云瑶池数据库

数据库 阿里云 云原生 韵达

冠赢互娱基于 OpenKrusieGame 实现游戏云原生架构升级

阿里巴巴云原生

阿里云 云原生

Linux升级指南:保持系统安全和高效运行

不在线第一只蜗牛

Linux 架构 运维 前端

WorkPlus:实现即时通讯的理想之选,专为企业打造的高效工具

BeeWorks

统一入口,全面提升工作效率,WorkPlus超级APP引领数字化办公新潮流

BeeWorks

借贷协议 Tonka Finance:铭文资产流动性的新破局者

股市老人

跟着坚果构建首个蓝河应用

坚果

坚果派 蓝河应用 蓝哥OS

为什么市场称SoBit 是铭文跨链赛道真正的龙头?

石头财经

阿里云瑶池数据库2023年度精彩时刻回顾

阿里云瑶池数据库

数据库 阿里云 云原生 年终总结

2023 IoTDB Summit:天谋科技 CTO 乔嘉林《IoTDB 企业版 V1.3: 时序数据管理一站式解决方案》

Apache IoTDB

定了!12月31日19时30分,来华为视频看2023-2024湖南卫视芒果TV跨年晚会

最新动态

基于图卷积神经网络和卷积注意力模块的癫痫检测

Authing 分级管理员重磅上线,实现权限超细粒度分级管控

Authing

权限管理 Authing 管理员

2023锐炫显卡全面发展,让“英特尔蓝”成为GPU市场中的一抹亮色

E科讯

稳字当先的出金系统的演进_文化 & 方法_敦敏_InfoQ精选文章