快好知 kuaihz

支付手续费设计思路

怎样在不影响用户正常交易的情况下确保收到手续费?这是本文章分享的核心主旨。

第三方支付公司商业模式主要分为两种:一是tob,即将支付服务接口提供给商户,商户自行封装接口,设计页面,商户平台上的用户对第三方支付公司不可知;二是toc,即开放自身支付公司的sdk或页面,用户直接在其页面操作,用户对第三方支付公司可知,如支付宝APP。

如果一个支付公司只有第一种商业模式,因其躲在用户身后,其他盈利模式难突破,所以绝大部分盈收来源为用户提供支付服务收取的手续费。怎样在不影响用户正常交易的情况下确保收到手续费?这是本文章分享的核心主旨。

一、手续费相关知识普及

二、手续费实收设计思路

第三方支付架构可按照交易是否涉及银行实资金变动划为两种类型:

转账,指从支付机构用户A账户余额划转至支付机构用户B账户余额(支付机构的账户余额实际资金皆在支付机构的银行备付金,所以账户余额的互转,并不影响支付机构在银行的备付金)。

代扣代发,涉及用户银行实资金账户余额变动。

转账类交易不需要像代扣代发一样与银行网关交互,转账类交易以自身记录为准,代扣代发以银行返回状态为准。两种类型的交易在手续费设计时存在不同。

 比如代扣的手续费设计思路通常为:

如图为代扣设计手续费的大致流程,这里值得注意的是,一定要控制手续费内扣(银行也俗称坐扣)时,要求入账金额大于手续费,不然用户为首次代扣,银行通道已经返回代扣成功。但是,你去先入账再扣手续费,扣手续费失败,事务全部回滚,导致交易失败。而银行已经扣了用户的钱,又要进入退款流程,这样会导致流程拉长,且更难控制成功与否。

手续费外扣时,需要考虑的是先查询手续费账户余额是否足够,还是先扣了手续费再发通道交易。

若是手续费外扣,先扣手续费,再发通道,因为通道有可能交易不成功,之后你得退手续费。这种方式是保证支付公司的收益。

若是手续费外扣,先查手续费足够,通道成功了再来扣取手续费,在高并发的情况下手续费扣取失败,通道成功你视为成功还是失败?需不需要发起退款?若是视为成功,保证用户体验,增加支付公司手续费收不到的风险呢,这时可以做个手续费差错流程,来处理这种小概率事件。但是具体设计逻辑还是看各自公司业务场景。

而转账类交易的设计思路不同,如下:

手续费外扣设计思路一致,不再累赘。而内扣因为转账类交易不涉及银行代扣代发网关交互,可以不判断:入账余额≥手续费金额。可以直接先入账再扣手续费,这样能保证入账账户有余额时,账户余额+入账金额≥手续费金额,转账交易也可正常完成。

三、手续费后收设计思路

手续费后收设计主要流程阶段如下:

这里的手续费可以在交易时实时计算,也可以在账单日期生成,再逐笔计算手续费

因为手续费后收,是保证用户支付交易不会因手续费原因导致失败,这会让用户体验特别棒。但是手续费后收存在问题即手续费不能收回。

现有市场上,有事先与用户签订协议,互相约定在固定手续费账单日期向指定账户扣取手续费,这时必须要求该手续费账户有足够余额,若是余额不够就涉及催款及催收系统,甚至会让公司内部人员上门催缴。

此篇文章主要侧重于手续费扣取逻辑,不涉及具体的手续费计算及手续费分润方案。手续费计算一般是读取系统里面的配置的手续费方案,按照指定方案算出;手续费分润方案是将手续费收入分配给交易的几方,共同获利。

本站资源来自互联网,仅供学习,如有侵权,请通知删除,敬请谅解!
搜索建议:支付手续费设计思路  手续费  手续费词条  思路  思路词条  支付  支付词条  设计  设计词条  
设计

 iOS应用中常用的临时层归纳

很多组件功能有重叠,使用的规则边界不甚明显,有些可替换使用。具体使用何种形式,需要结合自己的产品和业务目的决定。临时层是什么《支付宝体验设计精髓》中根据页面元素...(展开)