出金系统:对接银联、网联。以完成用户资金结算(提现)。
出金系统是公司将资金结算到用户的最后一道流程,一旦出现异常导致重复结算,则会直接造成公司的资金损失,所以我们秉承一个原则:稳
出金:从备付金提现至用户银行卡
网联:这里特指网联付款业务
银联:这里特指银联客户资金结算
渠道:出金渠道,指银联客户资金结算,网联付款业务。可以利用其能力完成用户提现。
退票:银联渠道先告知出金成功,后因账户或者其它原因资金退回。
流水号在请求出金渠道前生成,一旦生成,则后期不再变更。保证单一,降低系统复杂度,充分利用渠道幂等。
之所以这样,我们做了以下分析:
记录第一次请求渠道的交易时间,之后与渠道交互不更换时间。这样以来可以充分利用渠道对于当天同一流水号的幂等的特性。
之所以这样,也源于渠道的幂等性,渠道给出的幂等保证为:同一机构,当天流水号唯一。
控制异常处理,未经确认的异常交易种类,不允许处理。
出金系统只自动处理渠道明确的成功响应。除此之外的响应均进入异常处理流程。
接入的出金渠道返回的异常信息比较繁多,对于每一类异常,出金系统接收后,先经人工判定,只有明确后,更新到运营操作里才可对其进行相关操作,没有确认并处理过的异常交易种类不允许处理。
采取这种方式,在前期会投入一些人工成本,但能保证其准确性。在处理了大部分异常种类后。人工投入也相应减少了。
在此基础之上,我们再考虑进行系统自动处理异常,逐渐减少人工成本。
在收到提现的请求,通过幂等判断及参数校验,就可存入数据库。出金就返回给上游受理状态。
剩下的异常都捕获,能让上游感知的,都是明确的、确保出金不能处理的异常。
出金受理提现请求后,异步进行提现渠道交互,不会因任何交互异常而影响上游获取结果的准确性。
接入资损防控系统,按照定义的监控规则,一旦有异常提现,会通过多种告警方式通知,以便能及时处理。
接入渠道对账系统,利用其能力及时发现交易不对等的情况,通过告警感知并及时处理。
提供多种主动熔断手段,在系统异常时及时中断出金以减少影响。
银联处理交易的方式:同步请求受理接口,得到受理结果,异步通过回调通知交易结果。
做为初入支付领域的新人,初次与银联打交道。发现接入文档中异常的罗列并不完整。因没有经验可遵照执行,为保证资金安全我们选择了仅处理明确的交易成功状态。对于其它状态归为异常。初期投入人工成本,对于常见的异常类型进行必要的统计,人工判定后,再进行重试、同步状态、置为失败等操作。以保证提现异常处理的准确性。
之所以做出初期投入人工成本,也是考虑到实际在投产后,异常交易数量占比应该不会太高,因为提现时用户进行信息填写时,相对还是较为谨慎。如果填错信息,一是浪费了提现处理时间,再者严重的话会导致资金损失。在实际上线后,也验证了我们的想法。
在经过梳理需求,参照银联客户资金结算接入文档后,定义出提现处理的主要流程:
以上阶段中,每个阶段都会出现异常情况,所以需要有补偿操作:
在处理所有异常交易前先将交易存在异常处理缓存池中,在每个补偿完成后,再将交易从缓存池中清除,以避免重复补偿。
一阶段:成功落库提现记录,但长时间处在申请状态。
补偿逻辑: 获取超过一定时长的申请提现单,查询缓存中是否有该交易,如无,则重新发起进入二阶段。
二阶段:请求超时或者无响应,这时系统需要进行补偿处理。
补偿逻辑:
a. 以入库的交易时间和交易流水号先发起交易查询,如果仍无响应,则等待下次补偿再次尝试
b. 得到查无交易响应,重新发送报文到银联
c. 得到重复交易响应,进入三阶段
三阶段:长时间未收到异步回调
补偿逻辑: 适时发起状态查询请求及时同步状态。避免异步回调时间较长或者没有收到异步回调导致交易状态不能及时更新。
四阶段:上游未能及时收到结果
补偿逻辑: 提供提现状态查询接口,上游可调用及时获取结果
设计并实现以上补偿逻辑后,从正常提现到异常处理就相对完整了。测试完成后投产上线,运行结果良好,出现的提现失败,做了对应统计,对银联的常见异常及处理方式有了很好的把握。
因系统只自动处理成功的提现(自动发送成功消息&通知上游业务系统),所有异常交易,需要人工进行判定并处理。
所以在上线银联渠道的同时,我们也上线了运营功能,提供后台页面以供使用。
出金运营功能:
因银联对于提现的异常交易,响应了不同的交易响应码。所以以上操作均是按响应码来判定是否可被操作。
新异常提现操作流程:
出金 --> 得到异常码 --> 人工确认 --> 配置此类异常可用操作 --> 运营操作(填写对应文案给上游及用户展示)--> 系统保存处理文案
同类异常出现后,下次处理时:
出金 --> 得到异常码 --> 运营操作(自动填充之前的处理文案)--> 操作
同类异常处理时,自动填充处理文案,提升了人工处理效率,也降低了不同处理人员在处理异常交易时的判定成本。
网联的交易处理方式:同步请求,同步响应提现结果。对于同步未能正常处理的,7分钟内做出异步通知。
提现如果仅有单一的一个出金渠道肯定是不满足需求的,所以紧接着我们着手接入网联。
提现流程仍和之前定义的一致,稍有不同的是,因网联将异步交易做成了同步响应,所以在提现正向请求时,少了处理异步回调的逻辑。但对于网联本身处理过程中,产生的一些处理中交易,网联仍会通过异步的形式来告知我们。所以处理异步回调。
由于网联的处理方式是同步响应出金结果,而在此过程中,对于账户不正确这类异常,也是能快速得知,不会产生退票(因为一旦有退票产生,会对上游也有影响。上游需要针对退票情况做出相应的资金调整)。所以网联上线后,我们将网联做为主要的出金渠道。
目前出金系统具有两个出金渠道,这就涉及到出金渠道的选择及控制。
我们面临的需求
在路由实现过程中,相对难以控制的是对于累计金额的处理,主要面临以下几个问题:
备选的两种方案
对比两种方案后,最后选择了数据库统计,并应用了优化的方案。经验证,完全可以满足性能需要。
概要设计
我们抽象了规则及规则详情,存入数据库:
规则:主要包括执行的优先权重,判定条件。
规则详情:用于填充判定条件的具体内容。
在执行规则时,用规则详情去填充规则里的判定条件,通过规则执行引擎来执行并拿到结果。
这样以来,具备了较好的灵活性,能通过配置和添加数据库数据来扩展路由。在之后我们通过这一功能,快速了添加了渠道黑名单控制这一需求。
对于累计金额的处理:利用数据库中sql的sum函数进行统计,只不过统计近1小时的实时数据。1小时之前的数据,以天的粒度,启动一个定时任务每半小时计算一次并存入一张辅助表。所以sum运算时联表相加即可。
实验证明,可满足每1小时50W笔提现量。如果有更大的提现量,可以再缩短实时统计的数据范围,比如缩短至统计近10分钟的实时数据,加上每5分钟计算更新前10分钟的提现金额。
面临一个相对陌生的领域,只能摸索前行,在没有经验指导的情况下,渠道的接入方式有所不同,加之面临紧张的上线周期安排,所以在有些设计细节回过头来想一下,可能并不很合适,还需投入精力做优化,但是,所有的改动及优化,前提还是只有一个:稳
欢迎关注我们的公众号
Original url: Access
Created at: 2019-09-26 13:18:22
Category: default
Tags: none
未标明原创文章均为采集,版权归作者所有,转载无需和我联系,请注明原出处,南摩阿彌陀佛,知识,不只知道,要得到
java windows火焰图_mob64ca12ec8020的技术博客_51CTO博客 - 在windows下不可行,不知道作者是怎样搞的 监听SpringBoot 服务启动成功事件并打印信息_监听springboot启动完毕-CSDN博客 SpringBoot中就绪探针和存活探针_management.endpoint.health.probes.enabled-CSDN博客 u2u转换板 - 嘉立创EDA开源硬件平台 Spring Boot 项目的轻量级 HTTP 客户端 retrofit 框架,快来试试它!_Java精选-CSDN博客 手把手教你打造一套最牛的知识笔记管理系统! - 知乎 - 想法有重合-理论可参考 安宇雨 闲鱼 机械键盘 客制化 开贴记录 文本 linux 使用find命令查找包含某字符串的文件_beijihukk的博客-CSDN博客_find 查找字符串 ---- mac 也适用 安宇雨 打字音 记录集合 B站 bilibili 自行搭建 开坑 真正的客制化 安宇雨 黑苹果开坑 查找工具包maven pom 引用地 工具网站 Dantelis 介绍的玩轴入坑攻略 --- 关于轴的一些说法 --- 非官方 ---- 心得而已 --- 长期开坑更新 [本人问题][新开坑位]关于自动化测试的工具与平台应用 机械键盘 开团 网站记录 -- 能做一个收集的程序就好了 不过现在没时间 -- 信息大多是在群里发的 - 你要让垃圾佬 都去一个地方看难度也是很大的 精神支柱 [超级前台]sprinbboot maven superdesk-app 记录 [信息有用] [环境准备] [基本完成] [sebp/elk] 给已创建的Docker容器增加新的端口映射 - qq_30599553的博客 - CSDN博客 [正在研究] Elasticsearch, Logstash, Kibana (ELK) Docker image documentation elasticsearch centos 安装记录 及 启动手记 正式服务器 39 elasticsearch 问题合集 不断更新 6.1.1 | 6.5.1 两个版本 博客程序 - 测试 - bug记录 等等问题 laravel的启动过程解析 - lpfuture - 博客园 OAuth2 Server PHP 用 Laravel 搭建带 OAuth2 验证的 RESTful 服务 | Laravel China 社区 - 高品质的 Laravel 和 PHP 开发者社区 利用Laravel 搭建oauth2 API接口 附 Unauthenticated 解决办法 - 煮茶的博客 - SegmentFault 思否 使用 OAuth2-Server-php 搭建 OAuth2 Server - 午时的海 - 博客园 基于PHP构建OAuth 2.0 服务端 认证平台 - Endv - 博客园 Laravel 的 Artisan 命令行工具 Laravel 的文件系统和云存储功能集成 浅谈Chromium中的设计模式--终--Observer模式 浅谈Chromium中的设计模式--二--pre/post和Delegate模式 浅谈Chromium中的设计模式--一--Chromium中模块分层和进程模型 DeepMind 4 Hacking Yourself README.md update 20211011
Laravel China 简书 知乎 博客园 CSDN博客 开源中国 Go Further Ryan是菜鸟 | LNMP技术栈笔记 云栖社区-阿里云 Netflix技术博客 Techie Delight Linkedin技术博客 Dropbox技术博客 Facebook技术博客 淘宝中间件团队 美团技术博客 360技术博客 古巷博客 - 一个专注于分享的不正常博客 软件测试知识传播 - 测试窝 有赞技术团队 阮一峰 语雀 静觅丨崔庆才的个人博客 软件测试从业者综合能力提升 - isTester IBM Java 开发 使用开放 Java 生态系统开发现代应用程序 pengdai 一个强大的博主 HTML5资源教程 | 分享HTML5开发资源和开发教程 蘑菇博客 - 专注于技术分享的博客平台 个人博客-leapMie 流星007 CSDN博客 - 舍其小伙伴 稀土掘金 Go 技术论坛 | Golang / Go 语言中国知识社区
最新评论