快速解答：Google Play 为你提供了两种方式来了解购买是否被退款或撤销。Real-time Developer Notifications（RTDN）会在事件发生的瞬间，通过 Google Cloud Pub/Sub 将其推送到你的服务器。Voided Purchases API 则允许你按需拉取已失效购买的列表。它们并非互为替代方案——RTDN 提供速度，Voided Purchases API 提供安全网，而可靠的方案会同时使用两者，确保不会有任何遗漏。
为什么 Google 提供两种机制
在 Google Play 上，大多数退款的发生并不会事先询问你——Google 会直接发起退款、撤销相应权益，而你的任务是及时了解这一情况，从而让你的应用和分析数据保持准确。（关于哪些可以提出异议、哪些不能，请参阅 Google Play Refunds & Chargebacks。）
Google 提供了两种不同的工具来帮助你了解这些情况，它们从相反的方向解决问题。一种会在事件发生时主动推送给你；另一种则允许你随时查询列表。两者结合使用可以互补彼此的短板；单独使用任何一种，都会留下漏洞。
对于专注于 android 退款追踪的开发者来说，理解这一差异十分重要，因为实时事件流和历史对账机制解决的是退款监控问题中的不同部分。
Real-time Developer Notifications（推送）
Real-time Developer Notifications（RTDN）是推送机制。当订阅或购买发生任何变化时（包括退款和失效购买），Google 会将事件发布到你后端所订阅的 Google Cloud Pub/Sub 主题中。其核心在于及时性：你几乎可以在事件发生的同一时间就了解到它，而不是几个小时后才发现。
对于正在搜索 RTDN Google Play 集成方案的开发者来说，这正是将 Google Play 计费事件与你的后端连接起来的机制。对于像拒付审核这类时间敏感的事项（你大约只有 24 小时的响应时间），这种及时性就是关键所在。如果你依赖的是定期检查，那么你已经浪费了本就不多的时间。
问题在于：RTDN 运行在 Pub/Sub 之上，这意味着需要搭建 Google Cloud 项目、创建主题、为 Google Play 配置正确的发布权限，并在你这端设置订阅者。相比单一的 webhook，这涉及更多环节，也是许多开发者容易卡住的地方。
Voided Purchases API（拉取）
Google Play Voided Purchases API 是拉取机制。它会返回一份已失效、已退款、已拒付或已撤销的订单列表，你可以按需查询。你不必等待事件发生，而是直接向 Google 询问：有哪些订单已经失效？
它的优势在于完整性和可恢复性。如果某个推送通知被延迟、遗漏或从未被处理，针对 Google Play Voided Purchases API 的一次拉取查询仍然能够找出这笔失效购买。这正是你进行对账、确保你的记录与 Google 保持一致的方式。
相应的代价是，它本质上并非即时的——你需要主动查询，因此单独使用时它更像是一张安全网，而不是触发器。
为什么你需要同时使用两者，而不是只选其一
容易让人混淆的一点是：这不是一个“二选一”的问题。
单独使用 RTDN 可以给你速度，但无法保证完整性——一旦错过或未能正确处理某个通知，该事件就会从你的视野中彻底消失。
单独使用 Voided Purchases API 可以给你完整性，但没有速度——你只能在下次恰好查询时才知道某笔退款。
RTDN Google Play 为你的后端提供实时信号，而 Google Play Voided Purchases API 则为被遗漏或延迟的事件提供对账层。
可靠的方案会将 RTDN 用作实时触发器，并将 Voided Purchases API 用作对账层，用来捕获推送路径遗漏的任何内容。速度加上安全网——两者缺一，都会留下一个你最终会掉进去的漏洞。
复杂之处在哪里
正确搭建这套方案比听起来要复杂得多，而且这份投入是持续性的，而不是一次性的：
Pub/Sub 配置。创建主题、授予 Google Play 发布权限、订阅你的后端，并将权限设置得完全正确——这一步往往会花掉你三五个下午。随着你的计费基础设施不断扩展，这套 Pub/Sub Play Billing 配置也需要持续保持可靠。
需要保持同步的两套系统。你现在需要同时运行一个推送消费者和一个定时的拉取对账任务，并确保两者结果一致。
去重与排序。同一事件可能会多次到达，或以错误的顺序到达；你的处理逻辑必须是幂等的。
保持更新。Google 会不断修订计费 API 和事件类型，你的集成方案必须跟上节奏，否则就会在不知不觉中过时。
Google Play 退款通知。你的系统需要正确处理每一条相关的 Google Play 退款通知，并将其与正确的购买记录、权益和客户信息关联起来。
单独来看，这些都算不上什么稀奇的难题。但综合起来，这就是一套需要构建和维护的真实基础设施——而你为此付出这些努力，换来的仅仅是准确追踪那些你大多数情况下根本无法提出异议的退款。
这与退款处理的关系
把这些拼图拼在一起，Google Play 的退款处理可以分为两部分：在窗口期内捕获唯一可以提出异议的事项（拒付审核），并准确记录所有你无法提出异议的内容，从而让你的权益和分析数据保持真实可信。这两部分都依赖于 RTDN + Voided Purchases 这一坚实的基础。
对于那些想知道如何使用 RTDN 和 Voided Purchases API 追踪 Google Play 退款的团队来说，答案是：用 RTDN 实现快速的事件检测，用 Voided Purchases API 进行对账与恢复。这样可以让你的后端获得关于退款、失效购买和拒付的更完整视图。
而这正是 RefundSensor 为你管理的那一层。它会自动配置 Pub/Sub 主题，让你只需在 Play Console 中粘贴一个主题名称；它会实时消费 RTDN 事件，并与失效购买进行对账以确保无一遗漏；在窗口期内针对拒付审核提交拒绝建议；并在同一个 dashboard 中记录其他所有退款，与你的 Apple 退款一并展示。你无需构建或维护任何一种机制，却能获得两种机制正确配合所带来的结果。
官方资料 {#official-sources}
Google 的计费 API 会不断变化，因此请以其官方文档为最终依据：
一套方案，两种机制，零维护成本。RefundSensor 会自动配置 Pub/Sub，实时消费 RTDN，对失效购买进行对账，并在同一个 dashboard 中处理 Google Play 和 Apple 的拒付审核。 免费开始 →
发布后需添加的内部链接：Google Play 退款基石文章 · Apple 退款自动化基石文章 · 12 小时窗口期。
常见问题
RTDN 通过 Pub/Sub 实时将事件推送到你的服务器；而 Voided Purchases API 则允许你按需拉取已失效订单的列表。RTDN 提供速度，Voided Purchases API 提供完整性。
要构建可靠的方案，是的。RTDN 是你的实时触发器，而 Voided Purchases API 则是对推送路径遗漏内容进行对账的安全网。只用其中一种都会留下漏洞。
指不再有效的订单，通常是由于退款、拒付（chargeback）或撤销（revocation）造成的。追踪失效购买可以让你的权益（entitlements）和分析数据保持准确。
RTDN 运行在 Google Cloud Pub/Sub 之上，这意味着需要创建主题（topic）、为 Google Play 配置发布权限，以及在你这端设置订阅者——比粘贴一个 URL 要复杂得多。RefundSensor 会自动配置 Pub/Sub 主题，从而消除这一障碍。
大多数情况下不能。普通退款和撤销由 Google 决定。唯一可以提出异议的情况是处于审核中的拒付（chargeback），你应该通过 RTDN 捕获它，并在约 24 小时的窗口期内作出响应。
