简易版出款系统架构

参数:

出款请求号(批次号)

出款业务方

出款商户id

出款商户编号

出款商户的父商户id

出款商户的父商户编号

使用的出款产品----worktime nonworktime 工作时间出款,非工作时间出款

回调通知地址

出款明细 出款明细号

出款金额

出款备注信息--传递给银行需要

手续费类型--出款人出/收款人出

收款人银行编码

收款人银行卡号

收款人银行省编码

收款人银行市编码

收款人银行支行编码

收款人姓名

收款人手机号

收款人邮箱

出款类型 秒到(几分钟到) 普通(2小时内到) 下一天(隔天到)

对字典进行空格去掉

字段非空验证

字段长度验证

商户id验证

父商户id验证

判断商户是否激活

判断商户账户是否存在,并且余额是否充足,与出款总金额是否充足

判断出款明细一共有多少笔,可以限制笔数

明细的金额,不能小于0

验证出款明细订单号是否有重复的

明细字段非空校验

明细字段参数长度校验

验证出款明细中,是否有相同的收款人账号,收款金额(可以加个限制,超过几笔就认定为出款有问题)

自建风控,对明细拦截出款金额---对于某个商户在一定时间范围超过一定的出款次数,就拦截下来 
验证明细中传递的支行编码,总行编码,是否正确。调用公司的统一接口,或者本地有保存数据
判断明细的出款类型,如果是秒到的,则看其传递的银行编码,是否为我们支持的直连银行编码,不是的话,修改为普通出款,或者直接报错;

可以再商户维度,增加是否开通工作时间出款和非工作时间出款,判断当前时间是工作时间还是非工作日时间,如果两者都开通了,则不做校验;如果只开通了其中一者,则去判断当前时间是工作时间还是非工作时间;

对于不同的银行,校验不同的备注信息,每个银行的备注信息,要求的最大长度不同;超过了就截取;其实,没准银行内部就会自动截取。

判断对公直连银行和对私直连银行,如果传递的是非直连银行,则需要去支行,省编码市编码进行校验,必填;

因为客户需要知道每一笔明细的校验结果,所以在给客户返回的过程,需要告知每笔明细的处理情况,成功或者失败; 对于失败的,需要告知明确的错误信息;

判断商户是否开通了限额设置,是否超过了出款的限额; 判断商户是否开通了对私对公出款,可以对其出款做限额;怎么做判断---验证收款人的名字,是否包含公司。研究所、等等之类字段;

校验结束后,需要实际的入库操作了,我们对于校验通过的数据,进行入库保存,后续在异步进行计费,扣账,打款操作;

这样,客户可以再后续的流程中,观察到这笔打款是否成功,状态是如何了,利于客户的查询操作。。如果没入库的记录,则会直接返回错误信息;

我们还可以基于这些数据,做到账时间的可视化展示,类似于微信提现那种;

以上为基础字段的校验,现在来做 订单唯一性的校验;

对于出款请求号+请求方的唯一性验证,类似于订单表的校验;

订单明细表的校验:业务方+订单明细号+请求批次号 做唯一性校验;

有的系统,有数据库插入的限制,所以需要对明细进行拆分插入,一次插入1000笔或者2000笔不等,如果唯一性索引校验住的话,就将该记录返回响应错误码,告知用户。

没有唯一性错误的就直接保存。

对于出款明细来说,有一点值得注意的是,有的银行有出款限额设置,但是客户方面很大可能会超过此限额,我们需要对明细进行拆分,而拆分的依据就是该笔出款明细收款人银行的金额限制;

由于拆分后,订单明细号重复,所以对于整体数据库设计来说,我们可以增加订单拆分明细表,将拆分后的订单保存到数据库中;

还需要对每一笔订单 设置超时时间,如果超过某段时间还是初始化状态,则进行自动撤销操作,可以视为无效订单;

对于商户来说,主流程结束,后续异步操作。。。同步返回商户。

对于有错误信息的明细来说,均是没有保存入库的,没有错误信息的明细,都是已经保存入库的。。可以通过接口啊,页面啊来查询到。

商户出款请求表;用户展示查询

商户出款请求明细表;用户展示查询

商户出款请求明细拆分表;内部逻辑计算

由于后续步骤都是异步来完成,所以异步时候,有可能需要加上redis锁来处理,怕的就是某一天机器挂了,大面的订单延误b,而定时捞取的频率也很快,前一笔的定时还未处理完成,后一批的定时又开始执行了;

这样,可能会出现重复调用扣账,重复打款的情况发生。

异步: 计算每一笔出款明细的手续费,手续费的配置可以是自己系统来设计,也可以交给单独的计费中心来处理。

需要注意的是,每一笔出款因为时间的不同,而手续费计费的费率也不同。

当商户用秒到出款时,我们就会多收手续费,例如:可以收取基本手续费+秒到手续费+额外手续费(工作时间/非工作时间)+垫资手续费(使用到垫资,则有垫资手续费);

商户来决定是 自己出还是收款人来出手续费;

商户在入网后,还有配置一个手续费收取类型-----实时收取、后收、预付实扣 当是商户自己来承担手续费时,则会出现--实时收取、后收、预付实扣三种情况。

实时收取----收款收到的钱=商户出款的钱-手续费的钱;例如:收款人收取100元,那么商户传递105元过来,手续费为5元。

后收----收款收到的钱=商户出款的钱;

预付实扣----收款收到的钱=商户出款的钱;

当由收款人承担时候,则只会有实时收取的情况。收款收到的钱=商户出款的钱-手续费的钱。例如:收款人应该收到100元,手续费自己承担2元,那么商户传递的是100元过来

理财类app提现: 用户(收款人)承担:提现100元,实际得到98元。 商户(出款人)承担:提现100元,实际得到100元。

手续费计算完成后,把手续费具体金额保存到出款明细中,供后续商户查询,以及扣费操作。

会调用风控系统,风控对出款明细进行校验。。具体规则有待了解;

之后,我们会根据工作时间还是非工作时间,来进行判断是否需要进行垫资逻辑。

如果是非工作时间,则需要进行垫资处理,来调用垫资系统,对系统中的垫资方额度进行校验,看垫资方此时的额度是否充足,是否足够;额度足够,才可以进行流转。

扣减可用打款余额,此概念后续再看怎么加进来。

后续,我们就需要调用账务系统,让账务系统扣减商户的账户余额,并且完成实际的扣手续费操作,并调用打款中心,银行通道进行实际的出款。

实际调用账务系统前,可以增加一个小配置,如果是测试商编,则直接标记为调用账务成功,而不会实际的去进行扣账操作。

调用账务系统,需要设置本方出款系统的回调地址,好让账务再处理完成后,回调我们实际出款结果; 一般来说,账务系统都有一系列交易码,交易相关字段,所以出款这边可能需要根据不同的业务方来传递不同的值;

给账务传递出款的金额和手续费:

收款人承担:则实际请求账务出款的金额 = 请求出款金额-手续费金额

出款人承担:则实际请求账务出款的金额 = 请求出款金额,,手续费直接扣减商户在第三方支付公司所在的账户余额;

非秒到情况下: 如果出款类型为下一天,则设置预约打款时间 为下一天的0点;

如果出款类型为普通,则设置预约打款时间当前时间的2小时后;

关于手续费的扣减,可以完全交给下层账务系统来操作,即容易保证事务的一致性,也可以统一进行余额的管理;而上层业务方只需要将扣减的金额,以及谁来出手续费告诉账务就行;

而之前调用计费的逻辑,如果是单独的系统,例如计费中心来完成的,那么在我们调动账务时候,账务如果不信任上层业务方,则可以去计费中心反查一次,比较数据即可保证金额的准备性;

之后实际的调用账务系统,账务系统回进行余额的扣减操作,如果有失败,账务系统建议做成幂等操作,可以重复请求,但只会进行一次出款。

如果,是余额不足的失败,那么需要将此笔订单进行挂起操作,等待商户对余额进行充值。

如果是别的失败,则需要对出款的订单进行撤销,修改订单状态,并通知商户,告诉此笔订单已经撤销;

接下来,需要进行一系列回滚操作:增加可用打款余额,如果是商户承担手续费的话 增加金额 = 出款金额+手续费金额

回滚垫资额度,银行额度等;

调用完成后,更新订单状态,更新打款状态;

等待下层业务方回调操作;

回调中,可以参考的参数有:打款状态 打款时间 系统间唯一流水号 实际使用的打款通道(调用账务时候可以传递我方规定的打款通道)

账务回调后,如果为打款成功:

账务回调后,如果为打款失败(打款撤销):

失败:一般是用户信息在银行端报错 打款中心透传返回失败状态和信息。也有银行系统故障返回失败。 撤销:订单到了打款中心 用户发现出款有误需要撤销。只要打款中心还没有请求银行打款就能撤销。(只有打款中心手动操作,我们无权处理)

与调用账务时,失败的时候类似,当打款失败时候,我们需要进行退款操作,其实退款操作就是对商户当时扣减的账户余额进行调增处理,手续费和出款的金额都要给用户增加回来;

但是,在实际操作中,我们也可以对商户的属性进行设置,例如退款不返回手续费;

如果出款和打款失败发生在同一天,则需要进行银行额度的调整(垫资情况下);

实际上,退款的操作,还可以交给退款中心来完成,服务化更加明确,职责更加单一,其实也是操作账户的逻辑;

后续,在进行通知商户操作,告知商户一笔打款的处理结果。

思考: 在商户维度下,增加一些配置,更加细粒度的控住出款的金额时间,收取手续费的大小;

逻辑补偿: 调用账务处理 通知商户处理 调用退款处理

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏圆方圆学院精选

【许晓笛】深入理解 EOS 账户权限映射

名词解释:本篇文章出现很多 “Action” 和 “Active”,Action (动作)为 EOS 中账户可以接受的动作,也就是别人可以对你做什么;Activ...

1042
来自专栏区块链入门

第二十六课 如何从零开始搭建一个Truffle框架的DAPP应用1,摘要2, 需求描述3,操作步骤4,总结

第六课 技术小白如何开发一个DAPP区块链应用(以宠物商店为例)介绍了如何获取宠物商店的TRUFLLE框架代码,并完成部署的过程。 但是这个是已经成熟的代码框...

1561
来自专栏智能计算时代

超级账本项目:架构设计

image.png 架构设计 整个架构如下图所示。 ? 包括三大组件:区块链服务(Blockchain)、链码服务(Chaincode)、成员权限管理(Memb...

3244
来自专栏程序猿DD

如何在Spring Boot中玩转智能合约【修订版】

本文是由链博科技 ChainBoard.IO 为大家带来的web3j 对智能合约的调用。让 java 程序可以和我们的智能合约愉快的交互起来~ 一、 什么是 w...

38112
来自专栏网站漏洞修补

网站漏洞修补针对区块链网站安全分析

目前移动互联网中,区块链的网站越来越多,在区块链安全上,很多都存在着网站漏洞,区块链的充值以及提现,会员账号的存储性XSS窃取漏洞,账号安全,等等关于这些区块链...

1064
来自专栏岑玉海

RChain的跨分片交易算法

1912
来自专栏区块链大本营

千万别惹牛人!小哥被盗22元后,整出了这篇以太坊钱包安全攻略,黑客看完得哭了...

对于区块链动辄几十万行的代码量,安全漏洞时不时就冒出来。敏锐的黑客们,虎视眈眈地盯着漏洞的闸门,一旦看见开闸,便以迅雷不及掩耳的速度展开偷袭。

1222
来自专栏极客编程

使用truffle部署以太坊智能合约到区块链

truffle是以太坊(ethereum)开发智能合约(smart contract)过程中最受欢迎的框架,本教程来安装构建一个基本的Truffle项目并部署一...

1373
来自专栏区块链入门

第十三课 如何在DAPP应用实现自带钱包转账功能?

区块链是一个伟大的发明,它改变了生产关系。很多生态,有了区块链技术,可以由全公司员工的"全员合伙人"变成了全平台的”全体合伙人”了,是真正的共享经济模式。

1726
来自专栏SAP最佳业务实践

SAP最佳业务实践:FI–资产会计(162)-2资产主数据

4 流程步骤 4.1 主数据维护 固定资产是企业拥有的对象、权限或其他项目,旨在长期使用并可在资产负债表中个别标识。维护固定资产包含创建、更改和显示资产主记录...

3556

扫码关注云+社区

领取腾讯云代金券