退款后撤销访问权限：Apple 和 Google 不会替你完成的这一步

批准退款和移除访问权限是两个独立的步骤，其中只有一个是自动发生的。认为退款处理完成就等于购买已被撤销的开发者，在两大应用商店上都想错了，只是原因和方式各不相同。清楚知道自动化到底止于何处，正是在退款后真正撤销访问权限所需要的，而不是几个月后才发现这件事从未发生。

为什么退款默认不会撤销访问权限

Apple 和 Google 都把资金和访问权限当作两种不同的操作来处理。资金这一侧是商店政策：退款一旦获批，就是最终结果，账本随之更新。访问权限这一侧则是可选的，或者是开发者自己的责任，或者两者兼有，具体取决于平台和购买类型。两家商店都不会假定你希望退款一完成访问权限就立刻消失，因为很多合理情形（部分退款、善意抵扣、客服姿态）本来就不打算把产品拿走。

Google Play：那个没人注意的复选框

在 Play Console 中，为订单退款是一个分两部分的表单：先选择退款金额，再单独决定是否勾选 "Remove entitlement"。大多数客服人员默认不勾选它，因为大多数退款请求都是善意举动，客户会保留自己买到的东西。问题在于，退款确认界面上没有任何提示告诉你，这同样意味着客户会在一笔你本想彻底了结的退款之后，继续保留订阅或应用内项目。

API 路径也有同样的陷阱

代码里也存在同样的选择。orders.refund 接口接受一个可选的查询参数 revoke；当它为 true 时，该项目的访问权限会立即终止，对于连续订阅，未来所有的付款也会一并取消。如果省略这个参数，它默认是 false：退款照常提交，购买记录随之更新，用户则继续像以前一样使用产品。

最后那一行正是让集成栽跟头的地方。Voided Purchases API 的存在，是为了让你无需手动查看 Play Console 就能搭建撤销流程，但它只列出那些确实带撤销的作废订单。未勾选复选框、或未设置 revoke=true 处理的退款，对那个数据源来说是设计上的不可见，而不是漏洞。

解读 voidedReason 字段 当一笔购买确实显示为作废时，voidedReason 字段会告诉你原因，共有九种取值：other、remorse、not_received、defective、accidental_purchase、fraud、friendly_fraud、chargeback 和 unacknowledged_purchase。这不仅仅是记账。remorse 和 accidental_purchase 属于普通退款。fraud、friendly_fraud 和 chargeback 则值得转入欺诈审核队列，而不是简单地撤销了事，因为从统计上看，同一个账号更有可能再次出现这种情况。

如果你直接基于这个数据源开发，有一个操作细节很重要：purchases.voidedpurchases.list 每天最多 6,000 次查询，任何 30 秒时间窗口内最多 30 次查询。如果设计成紧密循环轮询，很快就会撞到这个上限；预期的模式是配合分页令牌的定时拉取，而不是持续轮询。

Apple：App Store 可以撤销授权，但撤销不了消耗型项目

Apple 的 App Store Server Notifications V2 会在退款完成的那一刻发送 REFUND 通知，无论是消耗型项目、非消耗型项目，还是自动续订订阅和非续订订阅，都一视同仁。这个通知之后会发生什么，完全取决于购买类型，因为 StoreKit 自身的撤销机制只覆盖这四种类型里的两种。

为什么消耗型项目是例外

非消耗型项目或订阅拥有一种持续性权益，Apple 的系统可以将其关闭。消耗型项目则不同：一旦被使用，就被视为已交付，StoreKit 里已经没有什么可撤销的了。如果客户购买了 500 枚金币，花掉之后又获得退款，从 Apple 的角度看这些金币早已不存在。唯一还留有这笔记录的账本是你自己的。REFUND 通知是你唯一的信号，让你去找到匹配的原始交易 ID，然后从自己的记录里扣减那笔余额；Apple 那边不会替你做这件事。

几乎没人处理的那个通知

REFUND_REVERSED 是大多数集成完全跳过的那个通知，因为它描述的是 Apple 撤回了自己的决定，这种情况很少有开发者在第一版设计里就考虑到。它到来时，交易上的 revocationDate 会重新变回 null：在 Apple 看来，这笔购买再次有效。如果你的服务器在最初的 REFUND 到来时删除了某项权益、取消了订阅记录、或把消耗型余额清零，那么 REFUND_REVERSED 就是把这一切恢复原状的信号。

如何逐步补上这个漏洞

• 在 Google Play 上，无论是通过 Play Console 还是 API，都把每条退款路径默认设为 revoke=true，除非某个具体的支持场景要求让客户保留访问权限。
• 使用带分页令牌的定时任务来查询 purchases.voidedpurchases.list，而不是紧密循环轮询，并将请求量控制在每天 6,000 次以内、每 30 秒 30 次以内。
• 把 voidedReason 值为 fraud、friendly_fraud 和 chargeback 的情况转入审核队列，而不是自动撤销并结案。
• 在 Apple 一侧，订阅 App Store Server Notifications V2，一旦 REFUND 通知中提到某个非消耗型项目或订阅，就立即撤销其访问权限。
• 为每一笔消耗型购买都保存好原始交易 ID，这样 REFUND 通知到达时就能直接找到要扣减的确切余额，而不必手动查找。
• 明确处理 REFUND_REVERSED，并将每一次撤销都与其交易 ID 或订单 ID 关联记录下来，这样在撤回发生时就能精确恢复被移除的内容。

这个漏洞实际上要付出什么代价

这与对客户是否公平无关，而是关于钱已经退回之后，仍在持续运转的那部分。一个已退款却仍在调用你的 API、存储数据、消耗计算资源的订阅，不是道德问题，而是一笔实实在在的账目：你为一笔已经退还了收入的购买支付了基础设施账单。商店不会替你追踪这笔成本，因为从它们的角度看，退款在资金转移的那一刻就已经完成。访问权限这一侧完全是你自己要控制的账单。

这正是 RefundHalt 把撤销当作退款流程的一部分，而不是事后补救的原因：REFUND 事件和访问权限变更被记录为同一个动作，REFUND_REVERSED 事件会自动恢复状态，而不是等着某个人注意到客户仍被锁在 Apple 已经归还的东西之外。