消耗型应用内购买的退款是那种会让你付出两次代价的退款，因为你已经花钱把它交付出去了

每一笔退款都让人难受，但消耗型应用内购买的退款是那种在你已经把钱花掉之后又把钱拿走的退款。订阅退款退回的是你可以关闭的访问权限。非消耗型退款收回的是一次永久解锁。消耗型不一样。一包金币、一捆宝石、一包 AI 图片额度、一次加成，在它进入客户余额的那一刻就被兑现了，等到退款请求出现时，金币已经没了，额度已经烧完了，产生输出的算力也已经计入了你的账单。这就是消耗型商品成为一款应用中最尖锐的退款问题的原因，也是为什么关于证明价值的常规建议在这里救不了你。

消耗型退款与其他任何退款有何不同

商店把每一种购买类型都当作三样东西之一，退款对每一种的落点都不一样。这个区别并非纸上谈兵。它决定了你的成本能回来多少。

消耗型商品在你交付的那一刻就被花掉了

非消耗型商品，比如永久关卡解锁或去广告，会留在账户里。订阅授予的是你可以撤销的、有时限的访问权限。消耗型商品在兑现时就被用光。客户买了 1,000 个金币，花 600 个用在一个调用了你服务器的功能上，那 600 个就没了。这份价值并没有留作储备等着被评判。它当场就转化成了你已付出的成本。

这就是商店当初为消耗型商品单独建立一套退款证据流程的原因。对于订阅，商店可以推算已付周期过去了多少。对于消耗型商品，没有钟表可读。要么你交付了金币而客户用掉了，要么你没交付，只有你的服务器知道是哪一种。

已经被消耗的东西你无法收回交付

当一笔消耗型退款被批准时，钱退了回去，但金币不会自己把兑现撤销。如果一个客户买了一个额度包，用它生成了四十张图片，然后拿到了退款，那么你为四十次生成付了钱，却什么也没得到。撤销剩余余额是你最多能做的，而且只有在还剩下一些的情况下。一个完全消耗的消耗型商品什么也不剩下可收回。

消耗型应用内购买退款到底让你付出多少

消耗型退款最显眼的数字是从你的账面上划走的销售价格。真正的数字是销售价格，加上你为把这笔购买转化成已交付价值而已经花掉的一切。这第二部分的大部分永远不会回来。

退款退回的是价格，不是算力

假设一个客户买了一个 $9.99 的 AI 额度包，并把它们全部用来生成输出。每一次生成都让你付出了一次真实的 API 调用。当 Apple 批准退款时，$9.99 退了回去，Apple 也退回了它的佣金，所以你报告的收入净额归零。你为那些生成付出的算力账单不会归零。你付了它，它已经结算，而且一直是付掉的状态。退款没有碰它。这正是 RefundHalt 所针对构建的确切情形，因为已过去的时间无法证明关于消耗型商品的任何东西，唯一的防线就是知道实际交付了什么。

App Store 这一侧，唯一那个你的回应算数的 12 小时窗口

在 App Store 上你没有退款开关。你无法批准一笔消耗型退款，也无法拒绝一笔。每一笔退款都由 Apple 决定，一次一个请求，通过 reportaproblem.apple.com。你得到的只是一次开口说话的机会，而且很窄。

CONSUMPTION_REQUEST 是 Apple 唯一向你询问任何事情的地方

当一个客户对一个消耗型商品请求退款，并且该应用启用了消耗数据共享时，你的服务器会收到一条 CONSUMPTION_REQUEST 类型的 App Store Server Notification。然后你有 12 小时用 Send Consumption Information 来回复。错过这个窗口，决定就会在没有你的输入的情况下做出。Apple 专门为消耗型商品引入了这个流程，并在 2024 年把同样的通知扩展到了自动续期订阅。

回复中带有一组字段。对消耗型商品最重要的两个字段描述了它被使用了多少，以及你到底有没有交付它。

为什么在消耗型商品上你的回复比在订阅上更重要

对于自动续期订阅，Apple 已经计算出计费周期过去了多少并依赖于此。你的消耗回复大多只是推动一个偏好。对于消耗型商品，没有已过去的周期可衡量。你发送的 consumptionStatus 几乎是 Apple 拥有的唯一使用信号。如果你的服务器能够确定地说，客户消耗了这个包的 100%，那就是一笔可辩护的交易和一次无声的白送之间的区别。如果 customerConsented 为 false，这些都不会被读取，所以同意必须在请求到达之前很久就在你的购买流程中被采集。

Google Play 这一侧，你可以退款，但商品已经没了

Google Play 给开发者的直接控制权比 Apple 多，而它带来的帮助比你想象的要少，因为最快的退款路径根本到不了你这里。

48 小时自助窗口完全跳过了你

在购买后的 48 小时内，一个 Google Play 客户可以通过商店请求退款，而且往往会自动获得，无需你的参与。没有人问你，你不发表意见，而对于消耗型商品，这意味着在你知道有请求发生之前，金币已经花掉，钱也已经没了。Voided Purchases API 是你在事后得知此事的方式，好让你能撤销剩下的任何权益。

退款与撤销，以及撤销做不到什么

你可以自己从 Play Console 或 Order Management API 发起一笔消耗型退款，带一个可选的撤销参数来收回访问权限。撤销在会持续存在的东西上运作干净利落，比如订阅或一项持久权益。它无法把一个消耗型商品的花费撤回。如果客户已经把金币变成了一个已交付的结果，撤销就没有任何可追回的东西，而你要背负履约成本，却没有一笔销售来抵消。

当拒付规则改变时，用金钱来算意味着什么

退款和拒付不是同一种损失，而在消耗型商品上这个差距即将拉大。退款会撤销销售，并且通常会退回商店的佣金。拒付是客户的银行强行把钱要回去，而且它是最终的。

从 2026 年 8 月 3 日起，Google Play 把一次拒付的成本转嫁给开发者：购买价格减去 Play 的服务费，再加上银行的拒付费用。对于一个你已经交付的消耗型商品，这笔账算起来很残酷。你付了算力去履约，你损失了购买价格，现在你还要在上面付银行的费用。一包有争议的金币可能比卖出的好几包所赚的还要贵。教训不是在事后去争拒付，那你很少能赢，而是把不满意的客户留在退款路径上，那里损失更小、商店那一份会回来，而不是纠纷路径，在那里它不会回来。

如何在消耗型退款上少损失一些

你无法阻止商店退款。你可以确保当它们退款时，你已经诚实地交付、完整地回应，并且能在苗头长大之前看到它。

在服务器端交付并记录下来

在你验证交易之后从你的服务器发放消耗型商品，并针对交易 id 记录交付和消耗的时刻。那条记录就是让你能用一个真实的 consumptionStatus 而不是一个猜测来回应 CONSUMPTION_REQUEST 的东西。一个你交付了却无法证明你交付了的消耗型商品，是一笔你会默认输掉的退款。

回应每一个 CONSUMPTION_REQUEST，并且回应得直截了当

在 12 小时内回复，每一次都要。报告真实的 consumptionStatus。对一个确实没有收到金币的客户夸大使用情况，会招来你本想避免的拒付，而拒付是更昂贵的结果。诚实、完整、准时。这就是全部的打法，而且只有在请求到来之前数据已经被采集的情况下它才管用。

把消耗型商品作为它们自己的退款群组来观察

把消耗型退款混进你的整体退款率里，信号就消失了。单独追踪它们。某一包金币或某一档额度上的退款激增，通常指向一个具体问题，一次坏掉的兑现、一个误导的价格、一个交付得比图标暗示的更少的包。把消耗型退款对照消耗型销售来读，按产品来看，原因通常显而易见。

简短版本

消耗型应用内购买的退款是那种在你甚至还没听说之前就已经让你付出代价的退款，因为金币已经花掉，额度已经烧完，算力在客户购买的那一刻就已计入账单。Apple 让你开口一次，为时 12 小时，通过 CONSUMPTION_REQUEST，而在消耗型商品上，那次回复几乎是存在的唯一证据。Google Play 让你退款，但很少先问你，而从 2026 年 8 月起，一次消耗型拒付的代价比这笔销售还大。在服务器端交付，记录你交付了什么，如实回应每一个请求，并把损失留在退款车道而不是纠纷车道。