“退款转付款”的设计方法

退款是一个比较常见的逆向业务。

但是退款不是说什么时候想退就能退，不同的渠道不同类型的支付有不同的退款时效。

过了退款时效，还能把钱退出去么？或者说，过了退款时效，怎么样才能把钱退回去呢？

渠道的退款时效是渠道开放给商户的权益，而商户和用户的退款协议是另一回事，二者难免存在错配。

比如，某平台就是敢承诺，永久可退，那么我想没有任何一个支付渠道可以满足他这个诉求，怎么办？

产品经理的神奇魔力就是，交给他，啥事都能给你办，不就是把超退款时效的款退回去么。

既然原渠道退不了了，那么……就得整点幺蛾子了。

退款的本质就是“把钱给他”，真想退，那就打破原路退的禁锢。

一、基础性的退款能力

支付的逆向是退款，而退款也有几种基础的模式，我们先把这个了解清楚。

1. 怎么退

一笔订单的内容构成是多样化的，那么也必然造成一笔退款的构成也是多样化的。

订单包含多个商家，多款商品，多种费用，那么退款的花样就多了。

从退款的基础能力上来说，一般的渠道会提供以下几种退款模式，我们可以把每一种退款模式当成一种退款产品。

对于平台来说，又可以基于渠道的基础退款模式，封装出更多场景的退款产品。

比如，可以将按商品退封装出一个按“商家退”的模式，将一个订单中的同一个商家的商品打包进行退款，从效果上就是按商家退。

这种处理手段，就是产品经理在设计上的灵活性；没有出路，也要基于手头的能力创造出新出路。

2. 从哪里出钱

钱不一定都在一个篮子里，那退款也就不一定从一个账户往回退。

退款的本质也不是必须原路退款到指定账户，而是将钱从收款者手里退回付款者手里。

那么，对于收款者来说，就没必要必须从收款的账户出。

在渠道签约产品时，往往会开通多个账户，比如基本户、运营账户、手续费账户、营销账户等，都属于该商户。

而同一个账户也可能有多种资金属性，比如可用余额、冻结余额、待结算余额等；

所以，在退款时，有的渠道会提供指定出款账户和资金类型的能力。

当然，对于一个交易体量很大的平台来说，对这一能力并没有太强的诉求，从原基本户退回足够了。

3. 退回哪里

前面我们讲了，退款的本质是退给付款的人，而不一定非得是付款的账户；

因为付款人在该平台可能有多个收款路径，比如在微信有绑定的银行卡、也有微信零钱，如果原路退回绑定的卡失败，那么微信可以决定退回用户的零钱账户。

这样我们就把退款的基础能力梳理清楚了。

二、必须退，把退款转成付款

开头介绍了，退款有退款时效，过了这个时效，原支付不再支持通过渠道退回。

但是，本身的业务存在这样的超时效退款场景，比如平台的退款协议就是比渠道的退款时效长；

比如家政行业，有的客户一次签约3年，那么其中的客户服务费就是在三年内可退，当2年半时要退剩下的半年单子，那么服务费就需要退回半年的。

这个时候很明显已经过了渠道的退款时效了，但是从业务上来说又必须退款。
怎么办？

基于退款的本质是退回付款人这一点，我们不难想到——走付款。

构建一个新的退款产品——退转付。

该退款产品的核心职能就是将超过退款时效的退款申请，转换成付款，将钱付给付款人。

要想实现这一退款产品能力，还有几件重要的事情要做，毕竟你要打破常规。

打破常规，往往需要更高的成本。

三、退转付，账号采集与状态联动

将退款转为付款的第一个难题就来了，钱付到哪里？

因为原渠道退回本身就有一个隐藏属性，那就是我们知道用户用哪个账户付的款，渠道就会退回这个已知的账户。

但是，付款给用户，难度就大了，因为我们不一定知道用户的收款账户信息。

将退款业务转换成付款要做的第一件事就是“采集用户的收款账户信息”。

如此，就将第一个难题转换成了一个可落地的需求，采集用户收款信息。

有了目标，实现起来就容易多了；

可以客户人工采集银行卡信息；

也可以在用户订单中心增加一个提示：已超原路退款的时效，需要您提交银行卡信息，平台将在3个工作日以内将款项打到该卡中；

以上的问题就变成了“采集入口”问题。

一个真正的产品难题会被一层层的分解，直到找到了答案，产品设计的过程其实就是这样一个过程。

那么怎么发起上述的采集动作呢？就是当后台点击“退转付”时，当然这个发起动作可以是人为触发，也可以是系统自动触发。

当退款失败的原因是“超过退款时效”同时用户退款协议约定又可退时，自动触发该退款路径。

当然了，在发起采集时可以先判断平台有没有用户的收款卡信息，如果有的话可以选择合适的付款通道将钱支付出去。

触发以后，在原退款订单基础之上生成一笔付款单。

该付款单是明确的“退转付”，与原退款单关联，付款类型定义为“退款转付款”。

还有非常重要的一个问题需要解决，就是付款与原退款在信息上的强关联，特别是状态的联动。
为什么？

因为退款业务是受到原支付单强制性限制，就是总退款金额不能超过原支付金额，而且，退款付的付款发起的前提是原退款单失败是由于超时效了。

如果退转付的付款业务不受上述条件的强制约，那么就可能发生资金损失，产生超额退款。

基于上述的控制链，那么退款状态和付款状态之间应该构建起联动性，退转付的状态去更新原退款失败的退款单的状态，原退款单的状态开始了新的流转。

最后要说明的是，退转付的付款业务应该归属于“退款”模块，或者说退款业务，而不是付款业务。

更精确的描述这个能力，我觉得应该是“基于付款能力的退款产品”。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！