我们在自己的账户上执行了一次退款，用来验证账本是否正确地反向记录。它确实做到了。随后有人查看了账户状态的其余部分，真正的发现就藏在那里：套餐仍然处于激活状态，而且会一直保持到下个月中旬。
钱退回来了，访问权限却保留着。任何愿意点击「退款」的人，每个月都能重复这么做。这不是靠测试发现的，因为没有任何测试提出过这个问题。
结束那笔付款所购买的周期
在一次全额退款中，那笔付款开启的周期现在会立即结束，并且会记录一条生命周期事件来说明原因。
是立即结束——但不是什么都不留。如果你原本在某个套餐上，升级到了更贵的套餐，而升级的那笔付款被退款了，你会回到之前所在的套餐，而不是免费层级。那个月是你另外单独付费的，并没有被退款。如果连那个月也一并收回，就等于平台在拿走客户仍然拥有的东西。只有在没有任何仍处于激活状态的先前套餐时，才会降落到免费层级。
访问权利有两个部分
这项修复的第一个版本只是结束了订阅记录本身，然后就停在那里。但你享有什么权限，取决于两件事：预算读取的那条记录，以及付款成功时被授予的一个角色权限。任何其他结束订阅的路径都会明确撤销这个角色权限。而这一个没有，于是一个已退款的账户会在名义上被取消，实际上却仍然保留着付费层级的权限。
现在角色权限也会一并被撤销，并且会落在恢复后的那个套餐的层级上，而不是笼统地降到「免费」——这和恢复套餐本身的逻辑是一致的。
通知服务商
账户页面显示的是「免费层级」。支付服务商的后台却显示「已激活，下次扣费在下个月」。退款结束了我们这一侧的事情，却从未通知另一侧，于是客户被排在队列里，等着为一个他已经获得退款、也无法再使用的套餐再次被扣费——而且他没有办法从我们这边的界面上停止这一切，因为取消操作需要一个处于激活状态的订阅，而我们刚刚取消的正是他的那份订阅。
退款现在会在发起该笔付款的服务商那里停止自动续费。这不是立即终止：自动续费会停止，因此不会再有资金流动，服务商自己的记录会按照它自己的日程自然结束，而不是在它刚刚处理完的一笔退款之下被强行撕掉。
有一个例外，是所有者在发布前发现的。如果你被恢复到的套餐运行在同一个服务商订阅上，取消它就会让你留下一个永远不会续费、也永远不会扣费的套餐——这恰好是本次要修复的那个漏洞的镜像版本，而且同样悄无声息。这种情况现在会被明确指出并保持不变。
只有开启周期的那笔付款才能结束这个周期
在这个服务商这里，月中的一次升级会针对现有记录收取一笔小额的按比例差价。如果退还这笔小额费用，系统会找到一个订阅，把它全部取消，再去寻找之前的套餐，却什么都找不到，于是把客户降到免费层级——就因为一次月中的调整。现在只有开启当前周期的那笔付款才能结束这个周期。在此之后发生的一切都只是金钱层面的问题，而账本对此早已给出了答案。
四条支付通道全部覆盖，而不只是那条正在使用的
我们支持的四家支付处理商里，有三家今天没有任何客户在使用。撤销逻辑本可以只在正在使用的那条通道上修复，而这几乎就是最初的做法。改变这一点的理由是：一旦其他某家服务商在未来某天重新启用，这个漏洞就会卷土重来，而到那时，不会有人记得它曾经存在过。
这个代码仓库已经六次交付过同一类被遗忘的陷阱。现在撤销逻辑存在于一份统一的契约背后，四家处理商都通过同一行代码调用它——这样一来，未来重新启用其中某一家的维护者，无需读过这些内容中的任何一部分，就能自然获得这项能力。