每种应用内购买类型的退款规则都不同，而只有其中两种会向你征询意见

你在 App Store Connect 或 Play Console 中选择的应用内购买类型，所决定的远不止商品如何销售。它决定了退款发生时的行为方式，决定了客户之后能否免费重新拿回该商品，以及在款项转移之前是否会征询你的意见。一个金币包、一个终身解锁、一个月度订阅和一个一次性的赛季通行证，是四种不同的法律与技术对象，退款规则也是这样对待它们的。大多数开发者用同一段购买代码发布它们全部，然后不明白为什么退款感觉如此不一致。它们并非不一致，而是因类型而异。

以下是每种应用内购买类型的定义、退款如何作用于它，以及为什么四种中只有两种会把决定路由到你的服务器。

四种应用内购买类型，以及退款为何沿着它们分道

Apple 定义了四种商品类型。消耗型商品是用掉后再买的：游戏货币、提示、能量补充。非消耗型商品是买一次就永久保留的：专业版解锁、去广告升级、可下载的关卡包。自动续订订阅按重复周期计费，直到客户取消。非续订订阅在一段固定期限内授予访问权，且不会自动续订，比如作为单一期限出售的一季内容。

Google Play 对同样的目录分类方式不同，却落在同一处。它把商品分为一次性商品和订阅，而一次性商品是否被标记为消耗型，取决于你的应用在购买后是否将其消耗。用词不同，退款后果却相同。

消耗型商品才是退款欺诈真正瞄准的类型

消耗型商品是你会遇到的最棘手退款情形，而它恰恰是 Apple 围绕其打造消耗请求的那一种，这绝非偶然。当客户购买 10,000 个金币、你的服务器发放的那一刻，价值就已交付。如果他们花掉这些金币再申请退款，商店可以退还他们的钱，但金币已经没了，你为兑现它们所付出的成本也一样。Apple 自己的工具也反映了这一点：消耗型商品一旦完成，就会离开交易记录，且永远不带取消日期，因为没有任何持久的东西可供取消。

这就是为什么消耗型是证据能带来回报的商品类型。当客户对消耗型商品申请退款时，Apple 会向你的服务器发送一个 CONSUMPTION_REQUEST，并等待最多 12 hours 以接收一次 Send Consumption Information 调用。在该调用中，你设置一个 deliveryStatus，并且在你已交付时，设置一个 consumptionPercentage。该百分比是以 milliunits 表示、从 0 到 100,000 的整数，其中 100,000 表示客户用掉了全部购买。一份你的记录显示已完全花掉的金币余额就是你可以上报的 100,000，也是你能在非本意购买主张面前摆出的最有力的单一事实。

消耗型商品无法恢复，所以时机就是一切

因为消耗型商品无法恢复，你不能像撤销订阅那样把它追回来。一旦退款获批，你唯一的保护就是你在销售时保留的记录。如果你没有在交付和消耗发生时记录它们，你就要在 12 hours 的时钟下重建它，而那是去找数据最糟糕的时刻。在进入时记录它，而不是在退出时。

订阅按你无法控制的时钟退款

自动续订订阅是多数应用赚钱的地方，而 WWDC24 的退款更新终于把它们路由到了与消耗型相同的证据窗口。自 App Store Server Notifications version 2.11 起，对自动续订订阅的退款请求也会触发一个 CONSUMPTION_REQUEST。所以那些过去完全不经你手就被裁定的订阅退款，如今到来时附带了一个 12 hours 的窗口。

关键在于消耗如何被度量。对于自动续订订阅，Apple 不希望你编造一个使用百分比。它会自行从已过去的时间计算消耗，所以一个年度计划已用满六个月的人无论你发送什么都会被读作大约消耗了一半。你的杠杆不是百分比，而是一份诚实的 refundPreference，即 GRANT_FULL、GRANT_PRORATED 或 DECLINE，并由你实际掌握的任何使用信号来支撑。发送证据所支持的偏好，让 Apple 去权衡。

非续订订阅更接近一次性解锁

非续订订阅是客户购买一次的固定期限，就退款而言，它的表现更像非消耗型商品，而不像自动续订计划。Apple 极少向它路由 CONSUMPTION_REQUEST，也没有可供比例摊算的自动续订。你的应用负责跟踪该期限并在客户的各设备上恢复它，所以退款意味着结束一个由你自己管理的访问窗口，而不是一个 Apple 在为你计时的窗口。

非消耗型商品是永久的，这一点是双刃剑

非消耗型商品是最干净利落的销售对象，也是退款时的一个隐蔽陷阱。它只买一次，永久与客户的商店账户绑定，商店可以随时按需将其恢复到任何设备。这种永久性在退款到来之前都是一项优点，因为现在你得撤销一项账户仍然记得的权益。如果你的撤销逻辑只在购买时检查、从不重新验证，那么被退款的客户可以恢复购买，径直走回付费功能。

Google Play 在这里增加了一条会绊倒新开发者的硬边界。如果你的应用没有在 72 hours 内确认一笔购买，Google 会自动退款并撤销权益。一个你的计费代码忘记确认的非消耗型商品不会悬而未决，它会自我逆转，客户会失去他们付了钱的东西的访问权，而这并非出于他们自己的任何请求。

到底谁能发放退款，会因商店和类型而变

在你规划任何退款应对之前，先弄清楚谁握着笔。在 App Store 上，只有 Apple 能发放应用内购买退款，对每种商品类型都是如此。你的 StoreKit 代码无法为一笔购买退款，你的客服台也不能。你可以在开启窗口的那两种类型上发送消耗数据来影响 Apple 的决定，而这就是你直接控制的全部。

Google Play 恰恰相反。你可以自己从 Play Console 或 Voided Purchases 和退款 API 为一次性商品或订阅订单退款，全额或部分皆可。这份自由也是一份责任：你对一个消耗型商品发放的退款，仍然必须在你自己的后端撤销该商品，因为 Google 不知道你的金币已被花掉。你所选的商品类型决定了那次撤销有多干净利落。

每种退款类型实际上让你付出什么

被退款的价格是每个人都盯着看的那一行，也是账单中最小的部分。当任何商店发放退款时，它会连同退回自己的佣金，所以你损失的是你的净收益，而不是全额标价。这是好消息，也就到此为止。商店返还的是它抽走的那一份。它永远不返还的，是你为完成这笔销售已经花掉的成本，而这个数字会因商品类型而急剧变化。

消耗型商品是昂贵的退款

被退款的消耗型商品是那种可能比其价格花费更多的商品。假设一个客户购买了 5,000 个额度，每个额度都触发一次付费推理调用，他们花掉了其中 4,000 个，然后申请退款。商店退还价格及其佣金，但算力、按 token 计费的 API 账单、你生成的图像，以及这些额度资助的任何创作者分成，全都已被花掉。非消耗型商品的退款至少能把一项权益拉回你的掌控。消耗型商品的退款拉回的，是一笔你已经付清了全部成本的销售。

拒付是同一张账单的更重版本

退款和拒付是不同的事件，而两者之间的差距现在有了一个日期。当客户不是向商店申请、而是向他们的银行争议这笔扣款时，一次完成的拒付是银行终局的。对于在 August 3 2026 当天或之后下的 Google Play 订单，一次败诉的拒付会向开发者收取购买价格减去 Play 的服务费，再加上银行的拒付手续费，这是一笔由卡组织设定的固定费用。Google Play 会通过 orders.reviewrefund 把拒付路由给你审查，附带一个 24 hours 的窗口，这是唯一向你索取证据的 Google 流程，而且它可能落在任何商品类型上。

当类型决定规则时该如何应对

你无法在销售之后改变退款落在哪种商品类型上，但你可以停止用同一种方式处理全部四种。

• 在消耗型商品的交付和消耗发生的那一刻就记录它们。那份日志是你在唯一无法恢复的类型上的全部防御，而 12 hours 的窗口远远不够从零构建它。
• 在退款之后重新验证非消耗型商品的权益，而不只是在购买时。一次恢复调用应当检查当前状态，这样被退款的客户就无法走回付费功能。
• 自动应答两个证据窗口。一个 12 hours 的消耗请求和一个 24 hours 的拒付审查，等不了某个人去读收件箱，也不会为时区而延长。
• 只在两种可争议的类型上评判你的退款防御。在从不开启窗口的类型上退款数量的上升，是一个产品或定价信号，而不是你证据的失败。

这一切都不是要战胜商店，而是要让你的应对匹配那个真正被卖出的对象。RefundHalt 会在窗口之内、用你在销售时记录的交付与使用证据，自动应答消耗型和订阅的 CONSUMPTION_REQUEST 以及 Google Play 的 orders.reviewrefund 审查，并把那些没有任何窗口曾让你争议的退款保存在它们自己的账本里，这样你用来评判自己的那个数字才保持诚实。