2026年8月3日之后的 Play 购买订单，拒付责任将发生变化。原本由 Google 承担的损失，现在将转嫁给你：购买价格减去 Google 的服务费，再加上银行收取的手续费。与这笔费用一同到来的，是开发者此前从未拥有过的东西——一个真正可以提交证据的24小时窗口。
要点速览
拒付失败的损失将从开发者收入中扣除，计算方式为购买价格减去 Play 的服务费，再加上银行收取的拒付手续费。
PendingRefundReviewNotification 会通过 RTDN 发送给你，倒计时为24小时。
你可以附加的内容包括已消耗比例，以及一批使用记录（最多1,000条），每条都标注了时间、来源IP和位置。
你第一次提交的内容才是最终有效的，之后发送的任何内容都会被静默丢弃。
银行手续费并不会随价格变化而调整，因此对于低价商品，手续费本身就可能超过客户的实付金额，这使得保持沉默的代价变得高昂。
为期恰好一天的发言权
在此之前，申诉拒付根本是不可能的。如今填补这一空白的机制，在很大程度上借鉴了 Apple 的消费请求设计。需要复核的争议会生成一条通知，从通知到达起，你有且只有24小时的时间，可以通过 orders.reviewrefund API 提交判定结果（批准、拒绝或中立），以及支持该判定的任何证据。随后 Google 会用这些材料代表你向银行申诉。
由谁承担拒付损失，以前是 Google。2026年8月3日之后，主要变成了开发者。
你的直接成本，以前是零。变更之后，是购买价格减去服务费，再加上银行手续费。
Google 仍承担的部分，以前是全部。变更之后，仅限于其自身服务费这部分的成本。
你能否提出申诉，以前不能。变更之后，可以，但只能在24小时的证据提交窗口内。
回复实际需要什么
每次回复都必须原样返回 pendingRefundToken。能否把一笔拒付与具体用户对应起来，取决于购买时是否设置了混淆账户ID（obfuscated account ID），如果没有，把争议与你记录中的某个人对应起来就只能靠猜测。
你可以附加的证据包括：
你的判定结果，以及是否提供过样本内容
以千分之一为单位表示的消耗百分比，例如45200代表45.2%
最多1,000条使用事件，每条都带有时间戳、IP地址、大致位置，以及最长5,000字符的描述
在你开始构建这套流程之前，有一点值得了解：系统只会记录你最初的那次回复。之后的调用会被静默丢弃，但仍会返回 OK，因此第一次提交如果不完整，就会永久保持不完整。
算一算保持沉默的代价
银行收取的拒付手续费是固定的，与商品价格本身毫无关系。因此，低价消耗品所产生的手续费可能超过销售金额本身。再加上为该笔购买已经消耗的计算和存储成本，亏损就会进一步放大。使用这个 API 在技术上仍是可选的，但既然损失无论如何都会落在你身上，选择不用就意味着毫无申诉地默默承受。
在8月到来之前做好准备
为所有通知类型启用 RTDN，因为复核请求会通过你订阅事件已经使用的同一个 topic 到达。
确保每一笔购买都附带混淆账户ID，不留例外。
弄清楚你的使用证据实际存放在哪里，也就是你需要引用的时间戳和IP地址。
在截止日期之前，而不是之后，把整条回复路径（包括回退行为）自动化。
Refund Sensor 可以端到端地处理整条流程，在窗口期内提交带证据的回复，不需要任何人盯着队列。
这些规则的文档出处
常见问题
2026年8月3日，且仅适用于该日期之后的订单。之前购买的任何内容仍适用旧规则，因此财务影响是逐步显现的，而不是一次性发生。
购买价格减去 Play 的服务费，再加上银行收取的拒付手续费。Google 仅承担其收取的服务费部分的风险。
你的判定结果（批准、拒绝或中立）；一个标记，说明是否存在样本内容；以千分之一为单位表示的已消耗比例；以及一批使用记录，最多1,000条，每条记录会标注发生时间、来源账户和IP、大致位置，以及一段自由文本描述。
不可以。系统只会保存你第一次的回复，之后的所有提交都会被忽略，尽管 API 仍会返回 OK。
不是强制性的，但无论你是否使用，拒付失败的费用都会计入你的账户，因此放弃这一唯一的申诉机制，就等于默默接受这些损失。
