支付--出款中如何计费

出款系统来说: 付款方就是出款的源头(通常为商户),收款方就是收钱的那一方(通常为个人)

计费中心---怎么计算手续费 收费模式:实收 后收 预付实扣 均有有效期概念,有效期立即生效

实收---退款时,是否退手续费 后收--退款时,是否退手续费,后收结算周期--日结,周结,月结,季结,年结 预付实扣--退款时,是否退手续费

如果为付款方出手续费,那么可以支持三种收费模式;

如果为收款方出手续费,则只可支持实收收费模式;

计费策略:简单的说是一笔出款按照什么样的公式来收你的钱;

固定比例 最低收取多钱 最高收取多钱

固定费额

固定费额+固定比例 最低收取多钱 最高收取多钱

区间固定费额/固定费率/固定费额+固定比例 例如:区间固定费额 区间1 0---100元 收取1元 区间2 100--500元 收取 5元

例如:区间固定比例 区间1 0---100元 按照0.38%收取 最低1元 区间2 100--500元 按照0.3%收取 最低5元

例如:区间固定费额+固定费率 区间1 0---100元 按照1+0.38%收取 最低1元 区间2 100--500元 按照5+0.3%收取 最低5元

让商户来告诉我们传递哪方来收取手续费;但是,此种情况下,手续费的配置就比较繁琐,那就需要2种计费策略,一种是付款方的,一种是收款方的; 在商户跟支付公司签订好协议后,手续费的变动理应来说不会经常变动。所以,在商户入网时候,就将手续费的收取方式设定号好可,不需要再实际出款的时候在进行告知;

付款方出手续费(商户出)

出款金额为100元,计费策略为每笔出款收取1元手续费;

实收的时候怎么扣:出款金额100元不变,在商户的账户余额中扣除1元,当做手续费,如果商户账户余额不足,则出款失败;

后收的时候怎么扣:出款金额100元不变,在商户的后收表中记录一条手续费数据,待计费周期结束后收取;

预付实扣的时候怎么扣:出款金额100元不变,在商户的手续费账户余额中扣除1元,当做手续费,若商户的手续费账户不足,则出款失败;

收款方出手续费(用户出)

收款方出手续费,只能支持实收模式,其余2种不能支持,因为用户在支付公司没有任何账户的概念,没法扣钱;

出款金额为100元,计费策略为每笔出款收取1元手续费;

实收的时候怎么扣:出款金额100元,扣除手续费1元,实际出款金额99元,进行出款,用户收到99元;

在实际进行出款时候,为了应对各种场景下的需求;计费侧,建议提供预计费接口,和实际计费接口,逻辑相同,只是一个会入库,一个只在内存中计算;

实际出款中,一种是商户请求支付公司接口进行出款操作;

另一种,是商户在支付公司的商户后台进行页面形式的出款操作;

第一种情况下还可以分为2种,展示计费和实际出款;

例如,商户接口请求,想先看下计费结果,那么此时的接口逻辑应当包含计费和参数的校验;

商户不看计费结果,直接进行出款操作,那么就包含实际出款流程,检验,计费,出款。。。

第二种,也就是商户后台,通常情况下,会展示给用户计费的结果和要出款的校验结果。所以跟接口中的第一类相似;

如果计费异常,则拒绝后续出款流程;

疑问点?到底谁来做扣除手续费的操作?

计费中心? 出款系统? 后面的账务账户系统?

手续费的计算理应由计费中心来实现,计费结果计费中心保留;

出款系统,也会保存计费的结果;

我认为由账务来做手续费的扣减比较合适,因为无论怎么操作,账务都需要对商户账户的余额进行扣减,手续费账户也保留在账务系统,那么由账务来做统一的扣减比较合适;

但是对于账务账户来说,他理应不关注付款方还是收款方的概念。

传递给账务账户时,出款的商户编码,出款的金额,出款的手续费,传递给账务即可;

但是在传递的时候,需要注意,如果是收款方承担手续费(只有实时一种情况),那么手续费字段为0,出款金额为:出款金额-计算出的手续费金额;

后续在做手续费统计等统计工作的时候,统计出款系统中的出款成功明细即可;

但是计费中心处,出款系统需要对后收的计费进行处理,可以使用定时通知的方式,将后收的出款订单告诉计费中心,出款成功,在结算周期结束后,找商户收钱去;

麻烦点是,出款可能成功可能失败,但是计费是在实际出款前就进行了的,所以对于后收的来说需要知道这笔计费是否真的要跟商户去要钱。 站在计费中心的角度来说,对于实收和预付实扣来说并不关注其是否成功还是失败;当然我们也可以将成功和失败告诉计费中心;还有一点就是计费中心不关注当时计费记录的成功失败,如果想对后收的商户在手续费统计收取,那么计费中心可以开个接口来接收后收的计费,只要有唯一流水号关联当时的计费记录即可。

还有一点在于,实际银行的操作出款中,银行侧有可能出款打款成功,但实际打款失败;打款失败,但实际打款成功的情况。 这样,我们整个链路上的系统,状态就会出现终态后不一致的情况,如果多个系统保留了出款状态,那么后续想让状态保持一致,就需要单独开发功能来保证了,麻烦事;建议出款的状态不要侵略到其他业务系统中。

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏区块链中本聪

区块链技术分布式数据库解决隐私

​ 主链侧链开发数字货币交易所白皮书区块链浏览器跨境支付场内场外宠物挖矿游戏基金会牌照 181-4069-6008 微信电话同号

1313
来自专栏申龙斌的程序人生

SC(SiaCoin)取出到钱包的图解教程

友情提醒:云币中的SC钱包仍在维护中,暂时还不能取现,先做好准备吧。 中国各大数字货币交易平台将在9月底关闭,为此需要将数字货币提取到自己的钱包中,这是区块链世...

54111
来自专栏数据库

DATUM和BigchainDB

2017年12月14日OKEx上线DAT币。该币的官方网站是datum.org。通过阅读其白皮书,发现该币的技术实现依赖一个叫做BigchainDB的技术,号称...

5368
来自专栏区块链入门

第三课 以太坊术语说明及开发者资源列表

也称钱包,提供账户管理、挖矿、转账、智能合约的部署和执行等等功能,以太坊节点利用以太坊客户端接入到以太坊网络。 现在以太坊客户端主要有:Wallent/ist ...

812
来自专栏Seebug漏洞平台

以太坊智能合约 Owner 相关 CVE 漏洞分析

最近学习了下以太坊的智能合约,而且也看到挺多厂家pr智能合约相关的漏洞,其中《ERC20智能合约整数溢出系列漏洞披露》文章中披露了6个CVE编号的漏洞,而这些漏...

1763
来自专栏极客编程

一个EOS区块链RPC API接口的PHP SDK包

作为我们Block Producer对社区利益的承诺的一部分,我们希望专注于构建有助于提高EOS平台采用率的工具/应用程序。与大多数大型应用程序一样,当你只有少...

1691
来自专栏区块链源码分析

联盟链Fabric和公有链比特币的区别

最近研究了一下联盟链的代表超级账本这个开源项目,准备再做一个Fabric的源码分析系列,本文先总结一下Fabric和比特币的一些关键性的区别或者也...

4153
来自专栏区块链技术指北

以太坊生态中的工具与技术

这是「区块链技术指北」的第 32 篇文章。 如果对我感兴趣,想和我交流,我的微信号:Wentasy,加我时简单介绍下自己,并注明来自「区块链技术指北」。同时我...

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

SAP最佳业务实践:FI–资产会计(162)-3资产浏览器

4.2 AW01N资产浏览器 资产浏览器允许您分析个别资产主记录的值的更改。它用不同的形式和汇总级别来表示固定资产的已计划和过帐的资产负债表值和折旧值。 资产浏...

3458
来自专栏蜉蝣禅修之道

以太坊DApp系列(二)---从入门到出家

以太坊自2013年V神提出后,被无数人赋予美好的愿景,甚至被称为区块链2.0,其代币发行量更是达到了全球第二,仅次于比特币,而其带来的智能合约概念颠覆了人们对区...

1.1K18

扫码关注云+社区