虚拟商品退款的产品设计中，有哪些坑你需要了解( 二 )

为什么？因为这样反而增加了他们的成本，如果不想增加他们的成本，那就会增加系统的成本。所以呀，成本！一切都关乎成本！
所以我的处理原则是，完全继承客服之前的处理逻辑，尊重他们的专业程度，只是把这样的逻辑代码化。另一方面，客服真正的痛点是资金原路返回，所以产品经理应该将这个小功能做到100分。
而对财务来说，最核心的诉求是把账算清楚。一个退款账单，最核心的大概有这么几个要素：用户id、订单id、订单金额、应退金额、实退金额、支付时间、退款时间。
任何支持退款的订单，都应该将这几个要素记清楚，记准。这几个核心要素中，最关键的又是应退金额和实退金额。
应退金额，代表的是公司理论上应该付出的成本，比如会期还剩一半的时候用户要退款，那应退金额就是订单总价的一半。
实退金额，代表的是公司实际退回给用户的钱，是实际付出成本。有时候客服根据用户的情绪，多做一些安抚，或者根据用户的等级做一些临时操作，都有可能导致根据逻辑算出来的应退金额无法满足一个退款工单的处理。
为了把账算清楚，这两个金额就必须要分开处理。
03 第三个坑：轻易就去动订单。
如果你不是做订单系统的产品，然后你去做退款功能了，这时候你可能会说，我在订单里增加一个退款的属性好不好，在这个属性里去记录退款过程中的各种状态。
千万不要！为什么，因为对于大多数公司来说，当有第一笔交易发生时，就很可能会有订单系统（除非用excel手动记账）。订单相关的数据，在各种跟钱相关的报表里都有应用。去改订单的数据，这才是踩了一个大坑，如果你不是那个做订单的产品经理，你很可能不会知道自己会少考虑什么情况。
我的做法是：数据解耦、状态关联。
数据解耦，说的是退款订单要单独管理。打个比方，如果说订单系统是一个大宇宙，那么退款相关的订单就是一个独立的小宇宙，两个宇宙之间通过状态的映射来连接。
用户无论是在平台申请退款，还是在第三方申请退款，相关的订单都会进入到退款流。退款流包括权益的流转、订单状态的流转、资金的流转等，这些流转是独立的，他们的数据不会影响原先订单系统里的数据。
所以我在后台新增了一个菜单去管理退款流中的所有订单，完全不去动原来的订单系统。
另一方面，对于每一个退款订单，都会有一个退款状态，这个状态描述了一个订单在退款流中的关键节点：

发起退款：用户正式向平台发起退款，以客服在后台完成操作为触发节点。
退款到账中：平台完成权益回收，触发资金回退流。
退款完成：资金通过原支付渠道回到用户账户，需要有各支付渠道关于退款成功的回执。
退款撤销：退款流中的逆向流程，以客服操作为触发。
退款失败：获取支付渠道退款成功的回执失败，用户没有收到钱。

每一个退款状态，都会映射一个订单状态。这样做的好处一方面是数据解耦，对原系统干扰最小，另一方面实现数据上的互查。
04 第四个坑：退款里的逆向流程不能忽视。
想不到吧，退款这个逆向操作里，也存在逆向流程。负负得正，最终就是，钱还是在用户那里。当然退款的逆向流程，也是从客服那里了解到的。
确实对于一部分用户来说，他们申请退款之后，会打电话过来说因为一些原因不想退了。那这个逆向流程怎么处理。
我的灵感来自于电商退款设计，我在京东下单后，如果想要退款并且选择了上门自提，那我能够修改收货地址的次数是有限的（好像是三次），我将这样的处理方法称之为：有限条件下的逆向支持。