Apple CONSUMPTION_REQUEST：如何回应 App Store 退款请求

有人打开"报告问题"页面，选中你的 App，向 Apple 申请退款。Apple 不会直接做决定。它会先向你的服务器发送一条通知，询问你对这笔购买了解多少，然后等待大约 12 小时。

这条通知就是 Apple CONSUMPTION_REQUEST。不少拥有可观 IAP 收入的团队从未听说过它。还有更多团队在日志里见过一次，然后就放在那里不管了。如果你也是这样，我们的
Apple CONSUMPTION_REQUEST 详解 已经讲清了它是什么以及为什么重要。本文讲的是回应这部分：该发什么，不该发什么，以及那些尝试过的人后来怎么样了。

要点速览

• 用户申请退款时，Apple 会发送 CONSUMPTION_REQUEST。你有大约 12 小时。过了这个时间，Apple 就会在没有你参与的情况下做出裁决。

• 回应只有五个字段。不是五十个，是五个。

• 你的退款倾向就只是一个倾向。Apple 以前否决过，以后也还会。

• 用户没有同意，就不要回应。这是 Apple 的原话，不是我们说的。

• 有一款 App 仅靠开始回应，就在大约两周内把退款率从 3% 降到了 1.9%。它从未要求 Apple 拒绝任何退款。

• 没有人能长期靠手工处理。时间窗口太短，请求又总在不方便的时候到来。

那么，Apple CONSUMPTION_REQUEST 到底是什么？

它是一条服务器通知，是 Apple 通过 App Store Server Notifications V2 推送的众多通知之一。当有人对某项 App 内购买申请退款时，这条通知就会触发。以前它只针对消耗型项目，自 WWDC24 起也覆盖了自动续期订阅，而后者才是大部分收入所在。

载荷中包含：已签名的交易、产品 ID，以及用户选择的退款原因。Apple 的
consumption Request Reason 文档列出了五种：UNINTENDED_PURCHASE、FULFILLMENT_ISSUE、UNSATISFIED_WITH_PURCHASE、LEGAL、OTHER。

你在其中找不到用户姓名或 Apple ID，只有一个交易标识符。把它变成"这是用户 48213，她购买后已经打开 App 40 次"是你的工作，而且只有在结账时附加了 appAccountToken 才能做到。我们专门写了
一整篇关于 appAccountToken 的文章 ，因为太多人跳过了这一步。

Apple 提问，你回答，Apple 裁决。这就是开发者面对 Apple 退款请求的基本流程。

如何回应 Apple CONSUMPTION_REQUEST

你需要向 Apple 的 Send Consumption Information 端点 PUT 一个小的 JSON 请求体，交易 ID 放在路径中。这个请求体就是退款系统所读取的 Apple 消耗信息。

首先是 Customer Consented，取值 true 或 false。如果是 false，就此打住，什么都不要发。Apple 的文档明确说，未经用户同意就完全不应回应。有点奇怪，但规则就是如此。

然后是交付状态。成功交付就填 DELIVERED。如果没有，还有针对质量问题、发错商品、服务器故障及其他情况的 UNDELIVERED 变体。

Sample Content Provided 是一个是/否字段，表示用户在购买前是否能够试用。有免费试用，填是。有内容预览，填是。只有三条要点的付费墙，大概率填否。

Consumption Percentage 最容易出错。它以千分单位（milliunits）表示，所以 100000 表示已全部消耗，50000 表示消耗了一半。自动续期订阅不要填这个字段，Apple 会根据计费周期自行计算。

最后是 refund Preference：DECLINE、GRANT_FULL 或 GRANT_PRORATED。可选。也是唯一能让你表达自己意愿的地方。

一份针对已被花掉的金币包的回应：

Apple 只回一个 202，别无其他。没有裁决结果。早在 2021 年，一位 Apple 工程师就在开发者论坛上说过：202 意味着你的数据"将被纳入考量"。承诺仅此而已。

不要对所有请求都发 DECLINE

我知道这很诱人。忍住。

先看原因。FULFILLMENT_ISSUE 意味着要去查你的交付日志。如果购买确实没有送达，就发送对应的 UNDELIVERED 状态加 GRANT_FULL，然后翻篇。这种案例你赢不了，硬争只会让你之后的 DECLINE 显得更没有说服力。

UNINTENDED_PURCHASE 看的是使用情况。9:02 购买，9:05 申请退款，中间零次会话？多半是误触。放手吧。连续一周每天都在用？发 DECLINE，附上真实的消耗数据。

UNSATISFIED_WITH_PURCHASE 正是 Sample Content Provided 发挥作用的地方。有过试用且用了 80%？拒绝。几乎没打开过？GRANT_PRORATED 是一个公平的折中。

对于 LEGAL 和 OTHER，发送准确数据即可，除非你的记录能让结论一目了然，否则不必填写倾向。

在 95% 消耗率加免费试用的基础上发 DECLINE，是一份有力的回应。对只用了九十秒的东西发 DECLINE，看起来就像条件反射。

真正这么做的人，后来怎么样了

Dipsea 是 RevenueCat 于 2024 年 9 月收购的一款音频 App，被用来测试他们自己的退款处理器。10 月 23 日起，他们开始回应消耗请求，倾向设为"由 Apple 决定"。没有 DECLINE，只有数据。大约 15 天内，退款率从稳定的 3% 降到了 1.9%。
他们公布了图表。在我看来，这是这个话题上最有价值的数据点。仅凭数据本身就让数字动了。

再看另一面。2024 年 3 月，一家游戏工作室在 Apple Developer Forums 上发帖称，他们一直在发送消耗信息，但 Apple 仍然批准了"几乎所有"针对玩家已经花掉的金币的退款。消耗型项目是最棘手的情况。金币一旦花掉，Apple 无法收回。如果你在收到 REFUND 通知后不自行扣回余额，钱和金币就都没了。

2025 年 5 月，r/iOSProgramming 上的一个帖子涌入了大量 RevenueCat 用户，他们设置了"始终倾向拒绝"，却突然发现每一笔退款都被批准了。RevenueCat 表示这是 Apple 方面的政策变化。无论原因如何，这件事为一个老争论画上了句号：Refund Preference 不是开关。一刀切的 DECLINE 是一种模式，Apple 可以直接把它过滤掉。

收到 400 的几种方式

Apple 对请求体的要求很严格。下面这些是我们反复见到的。

千分单位的问题。有人看到"percentage"，就发了 100，结果等于告诉 Apple 用户只用了千分之一。范围是 0 到 100000。

未交付项目却填了非零百分比。如果 delivery Status 不是 DELIVERED，Consumption Percentage 必须为 0，否则请求会被退回。

自动续期订阅填了任何百分比。Apple 为此专门设了一个错误码。直接不填。

用错密钥。这个调用需要的是 In-App Purchase 密钥，在 App Store Connect 的"用户和访问"下的"集成"中生成。不是 App Store Connect API 密钥，尽管两者看起来一模一样。用错了会得到 401，然后花一小时怀疑自己的 JWT。

跳过同意环节。这不是 HTTP 错误，而是合规错误。上线之前先把相关条款写进你的用户协议。

先在沙盒中测试。有一点要注意：根据 Apple 的测试文档，沙盒里只给你五分钟，而不是十二小时。如果你的服务器用了六分钟，测试就会忽略你的数据。要强制触发拒绝，在退款表单中选择"其他"并输入 DECLINE。

退款请求很多时，开发者如何处理 App Store 退款请求

说白了，大多数情况是不处理。请求在凌晨 3 点到达。或者周六。或者某个假日，而唯一懂这条流水线的人正好不在线。十二小时过去，Apple 只凭用户的一面之词裁决。

开发者如何处理 Apple 退款请求，归根结底是一个选择。要么自己搭建整条链路（验证 JWS、查找用户、拉取使用数据、计算百分比、签发 JWT、调用端点、记录日志、重试），并永远维护下去；要么接入已经把这些做好的 Apple 退款管理软件。

Refund Sensor 是第二类中的一个选项。你把我们的通知 URL 粘贴到 App Store Connect，连接密钥，回应就会在几秒内发出。在目前接入的所有 App 中，77% 的符合条件的请求都得到了辩护，每个案例平均保住约 $33。这里没有任何高深之处，只是每次都在截止时间之前发出一份带有真实数据的回应。如果你想多比较几家，我们的 Apple 退款管理工具
指南列出了该问的问题。

这就是为什么面向开发者的 Apple 退款自动化话题一再被提起。十二小时、每一条请求、每一周，这不是人力能胜任的任务。无论你选哪种方案，总要选一种。沉默意味着 Apple 只能听到一方的说法。