支付手续费设计思路

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

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

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

第三方支付架构可按照交易是否涉及银行实资金变动划为两种类型：一是转账，指从支付机构用户A账户余额划转至支付机构用户B账户余额(支付机构的账户余额实际资金皆在支付机构的银行备付金，所以账户余额的互转，并不影响支付机构在银行的备付金)。二是代扣代发，涉及用户银行实资金账户余额变动。

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

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

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

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

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

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

而转账类交易的设计思路不同，如下：

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

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

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

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

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

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

文章作者系 @owl未经许可，禁止转载。

（编辑：ASP站长网）