Google Play 的拒付审查给你 24 小时反击，下面是你该发送的内容

当客户的银行撤销一笔 Google Play 扣款时，Google Play 不会只是退款然后就此了事。它会向你的服务器发送一条 PendingRefundReviewNotification，并启动一个 24 小时的倒计时。通过 ReviewRefund API 回应这条通知，附上退款倾向以及客户实际使用情况的证据，Google Play 就会把你的意见纳入它对这笔拒付的抗辩。保持沉默，这场争议就会在唯一知道产品如何被消费的一方一言不发的情况下被裁定。

Google Play 的拒付审查是 Android 上唯一一个向你索取证据的退款流程，是 Apple 的 CONSUMPTION_REQUEST 的直接对应物。它如今比过去更重要。从 2026 年 8 月 3 日起，Google Play 把拒付的成本转移到开发者身上，所以一场你未能回应的争议将从你的账户里扣除，而不是 Google 的。下面就是这条通知携带了什么、你要回传什么、构成你证据的各个字段，以及沉默在哪里变成了金钱。

Google Play 拒付审查究竟是什么

拒付并不是一次退款请求。客户找到他们的银行或卡组织并对这笔扣款提出异议，然后银行把资金撤回。Google Play 大多数情况下会自行处理这些。对于其中一部分，它会开启一次审查并先询问你，因为你掌握着 Google 没有的信息：订单是否已交付，以及客户消费了其中的多少。那次审查就是 ReviewRefund API 背后的流程。

这是 Android 退款系统中唯一一个你的证据能改变结果的地方。其他每一条 Google Play 退款路径都在没有你的情况下运行。客户可以在购买后 48 小时内自助退款，客服可以给予退款，未确认的购买会被自动退款，全部由 Google 裁定。拒付审查是例外，值得把它当作你实际能参与的唯一一次退款对话来对待。

它是 Apple 证据窗口的 Android 版本

两家商店，两个向开发者索取证据的流程，全部就这些。Apple 发送一条 CONSUMPTION_REQUEST，给你 12 小时用 Send Consumption Information 来回应。Google Play 发送一条 PendingRefundReviewNotification，给你 24 小时用 orders.reviewrefund 来回应。机制不同，但道理完全一致：当商店问客户使用了什么时，一个精确的回答就是留住这笔销售和把它交回去之间的区别。

有一个差别在实践中很重要。Apple 的消费载荷是五个数字字段，别无其他。Google Play 的证据更丰富。你可以发送一个消费百分比，外加一份逐条的使用事件列表，每条都带有时间戳、一个账户标识符，甚至一个 IP 地址和粗略位置。Google Play 给了你更多空间来描述交付，也就意味着更多让人信服的空间。

24 小时倒计时以及通知如何到达你

这次审查作为一条 Real Time Developer Notification 到达你的 Cloud Pub/Sub 主题，与投递你的订阅和购买事件的是同一条通道。消息是一段 base64 编码的载荷，里面有一个 pendingRefundReviewNotification 对象。倒计时在那条通知被发布时开始，而不是在你恰好读到它时，所以一个每天只轮询一次的消费者就是一个会错过争议的消费者。

PendingRefundReviewNotification，逐个字段来看

这条通知很小。它告诉你哪个订单正在被审查，把你必须回传的令牌交给你，并写明原因。下面是它携带的每一个字段。

只有拒付才会开启一次待处理审查

待处理审查上的 refundReason 始终是 CHARGEBACK，以整数 7 的形式送达。Google Play 的世界里还存在其他退款原因，但它们不会通过这个流程到达你，因为你对它们没有发言权。如果你看到一条 PendingRefundReviewNotification，说明一家银行已撤销了一笔扣款，而 Google Play 正在决定是否对它提出抗辩。那是唯一的触发条件。

你通过 ReviewRefund API 回传什么

你用一次向 orders.reviewrefund 的 POST 来回应。完整路径是 POST https://androidpublisher.googleapis.com/androidpublisher/v3/applications/{packageName}/orders/{orderId}:reviewrefund，用 https://www.googleapis.com/auth/androidpublisher 范围授权，就是你的 Play Developer API 集成已经在用的那个 OAuth 范围。成功会返回一个空正文，附带 HTTP 200。

正文才是你的案情所在。你回传通知里的 pendingRefundToken，声明一个退款倾向，并附上消费证据。

你的退款倾向是一个建议，不是一个裁决

refundPreference 字段取三个值之一，它是给 Google Play 的建议，而不是一个最终决定。结果仍由 Google 掌控。但它是有 Google 自己看不到的数据支撑的建议，所以它有分量。

支撑 DECLINE 的证据字段

一个光秃秃的 DECLINE 是没有证明的主张。消费字段就是那份证明。consumptionPercentageMilliunits 是一个以毫单位计的整数，所以 100000 表示客户消费了他们所购买的 100%，而 50000 表示一半。consumptionUsageEvents 是一个可选数组，其中每个事件可以携带一个 obfuscatedAccountId、一个 obfuscatedProfileId、一个 consumptionTime、一个 ipAddress、一个 consumptionItemDescription，以及一个粗略的 location。sampleContentProvided 是一个布尔值，用于你给了客户付费内容免费样本的情形。它们合在一起，用 Google Play 自己的架构说明，产品已经交付并被使用。

你的第一次调用就是你唯一的调用

Google Play 会记录你针对一条通知发出的第一次 ReviewRefund 调用，并忽略它之后的每一次调用，同时仍然返回一个 OK 状态。没有草稿，也没有修订。如果你的第一次回应是一个匆忙的、没有证据的 NEUTRAL，因为你的流水线还没准备好，那就是记录在案的回应，而后面那次带着完整消费历史的调用会被悄悄丢弃。在你发送任何东西之前，先构建好完整的答案。

这次审查在金钱上让你付出什么

多年来，一场输掉的 Google Play 拒付只让开发者损失这笔销售，别无其他，因为 Google Play 吸收了下游的费用。这在 2026 年 8 月 3 日结束。对于在那个日期之后下的订单，Google Play 与开发者分担拒付成本，而开发者那一份是购买价格减去 Play 的服务费，再加上金融机构收取的相关拒付费。Google Play 继续承担服务费那一部分。银行费用是压在你这一侧账本上的新重量。

退款从来不是真正的数字

这场争议退回了客户的付款，但那笔付款从来不是你唯一的成本。一段生成的视频、一批模型 API 调用、一笔创作者分成、你预置的存储，所有这些钱都在订单交付的那一刻离开了你的账户，而其中没有一分钱会随着拒付回来。现在再加上银行的拒付费。你在支付供应商的账单、退还销售款，并承担争议费，为一个你本有证据可以辩护的订单支付三重成本。

Google 正在对抗的规模

Google Play 表示它在 2025 年拦截了 US$3.4B 的欺诈和滥用，并将在整个 2026 年增加欺诈检测。这项成本分担的变化是同一推动的一部分：给开发者一个把证据喂进系统的理由，系统就会对更多不正当的争议提出抗辩。ReviewRefund API 就是你的证据进入系统的途径。一个空白的回应，就是投票让一场善意欺诈的拒付用你的钱站住脚。

如何在通知落地之前就做好准备

24 小时的窗口不是问题。问题在于你需要的证据必须在争议之前就已存在，在购买和消费时捕获，而不是在令牌出现之后再重建。一个在通知到达时才开始收集数据的团队已经输了。

在购买时附上身份

在每一笔购买上用 setObfuscatedAccountId 设置一个 obfuscatedAccountId，这样通知里的账户 id 就能直接映射到你系统里的一个用户。把它保持为一个哈希值，64 个字符或更少，绝不能是明文邮箱或其他个人数据，因为明文标识符会导致购买被拦截。没有那条链接，你就无法把 pendingRefundToken 连到一段真实的使用历史，你的 DECLINE 背后也就一无所有。

在消费发生时就记录它

记录一笔付费订单交付了什么、何时、给了谁，以一种你能按需转换成 consumptionPercentageMilliunits 和 consumptionUsageEvents 的形式。

• 给每一个消费单位打上时间戳，这样每个事件上的 consumptionTime 是真实的，而不是估算的。
• 对照购买来追踪交付，这样你就能有信心地陈述一个消费百分比，而不是猜测。
• 把账户和档案标识符保存在使用记录旁边，这样当令牌到达时，一个事件就能在一次查询里组装出来。
• 如果你有的话，捕获请求 IP 和粗略位置，因为 Google Play 接受这两者作为事件字段。

在窗口内自动回应

24 小时的窗口对一台机器来说很从容，对一个必须清醒并保持专注的人来说却很残酷。回应应该是自动的：通知进来，账户被查出，消费被组装，一次 ReviewRefund 调用发出，全程没有人参与。那正是 RefundHalt 为你运行的部分。我们监听 PendingRefundReviewNotification，把订单匹配到我们已经为那个账户追踪的使用数据，并在窗口内用一个退款倾向和真实的消费证据回应 orders.reviewrefund。令牌是那根线，证据是那件案子。把两者都准备好，你能参与的这一次退款对话就是一次你能赢的对话。