不同类型的支付，或许会有不同的退款时效，那么如果过了退款时效之后想将钱退回去，可以怎么操作？这篇文章里，作者就阐述了“基于付款能力的退款产品”该如何设计，一起来看看吧。

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

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

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

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

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

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

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

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

一、基础性的退款能力

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

1. 怎么退

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

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

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

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

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

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

2. 从哪里出钱

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

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

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

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

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

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

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

3. 退回哪里

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

四、退转付，流程解析

基于退转付的业务规则和模型，梳理整个退转付的核心流程，一步步展开，得到最后的流程图

先定全局流程

整个流程图有三个泳道组成，左边是退款业务发起方，右边是退款渠道，中间是支付核心的退款处理流程

再定退款流程的分支

退款处理流程部分也包含三部分，超过退款时效的退款处理、退款主流程、正常退款处理

其中两个子流程之间有一条通路，通过退款失败是否超时效链接

对流程图进行细化

基于上面的设计框架进行细化，即可以得到完整的流程图，如下图所示

• 退款发起：业务系统发起退款申请，用户取消了订单、申请退货、售后等一系列业务操作，产生了退款业务；退款请求发往支付核心
• 退款主流程：支付核心接收到退款请求，在主流程上退款模块创建退款单，然后判断退款时效是否超期，该判断是分化出两个子流程的关键节点
• 正常退款的处理子流程：在没有超期的情况下判定为正常退款，请求原付款通道申请退款即可，不过这里要特别注意，对于退款失败的情况，要再次判断是否因为超过退款时效，从而有一条从正常退款流程转入退转付流程的通路
• 超过退款时效的退转付处理子流程：如果最初的退款判断出，超过了退款时效则创建退转付订单，完成收款账号信息获取以后发起付款申请
• 退款结果通知：对于成功的退款或者付款结果通知业务方
• 失败业务的处理：对于失败的付款或者退款根据失败原因进行处理，是调整后继续发起或者将失败结果通知业务方；比如退转付失败原因是收款账户信息有误，则返回用户进行修改后重新发起；如果是付款账户余额不足，则进行充值后再次发起
• 最后要说明的是，退转付的付款业务应该归属于“退款”模块，或者说退款业务，而不是付款业务。

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