2026年Google Play退款与拒付指南：8月3日起的费用共担、Review Refund API与Voided Purchases逐步操作

2026 年 8 月 3 日，Google Play 改了对开发者生效的退款规则——不是用户看到的那部分，而是「一笔购买变成争议时由谁付钱」的那部分。拒付（chargeback）成本现在由双方共担，同时上线了一个新 API，让你在拒付被裁定之前先把证据交上去。如果你的应用卖订阅或一次性解锁，而你从没看过自己的 voided purchases 管道，这个季度就该补上。

下面是可执行的顺序：费用共担到底怎么算、怎么在 Play Console 里区分「退款」与「拒付」、唯一能看到支付机构拒付的订单数据源，以及决定你承担多少的那 24 小时窗口。

三个数字决定风险敞口： 2026 年 8 月 3 日——此日期之后产生的订单适用新的拒付费用共担。24 小时——收到 PendingRefundReviewNotification 后，通过 Review Refund API 应答的时限。30 天——Voided Purchases API 的最长回溯窗口，也是唯一包含「支付机构拒付」的订单数据源。

1. 8 月 3 日到底改了什么

Play Console 帮助页 Updates to refund protection and chargeback cost responsibility 把这次变化写得很直白：Google Play 在 2025 年阻止了 34 亿美元的欺诈与滥用；2026 年将增加更强的护栏与欺诈检测以减少退款滥用；并且——为对齐行业标准——对 2026 年 8 月 3 日之后产生的订单，Google Play 与开发者开始共担拒付成本。

分摊方式很具体。拒付是用户直接向自己的银行或发卡机构发起的争议，不是向 Play 发起。一旦发生：

开发者承担：商品价款（扣除 Play 服务费后的部分）＋金融机构收取的拒付手续费。
Google Play 承担：继续承担该笔交易的服务费。

也就是说，一笔被争议的销售对你不再中性：你退回已收到的钱，并且承担每笔争议的银行手续费，而 Google 让掉自己的佣金。退回去多少取决于你的服务费档位，Google 在 Service fees 中有说明——这份文件本身也变了：对 EEA、英国或美国用户、自 2026 年 6 月 30 日起发生的交易，费率取决于该用户的安装被判定为「新安装」还是「既有安装」（自动续订订阅单独计算，年收入首个 100 万美元落在最低档）。在测算一波拒付的成本之前，先确认你的账号实际属于哪一档。

2. 四类不同事件在你的收入报表里长得一模一样

Voided Purchases API 文档列出了会让购买作废的情形，而这些根本不是同一件事：

用户为自己的订单申请退款；
用户取消自己的订单；
订单被拒付（chargeback）；
开发者取消或退款该订单；
Google 取消或退款该订单。

该 API 覆盖一次性应用内订单与 App 订阅，并且带有一条需要读两遍的提示：与其他订单数据源不同，它包含被支付机构拒付的购买，因此你本来就应该预期这个 API 与其他订单数据之间存在不一致。财务系统与权益系统在这里「对不上」是正常的——提前知道这点，才不会把正常差异当故障。

同一页还给出两个机制。第一，只有已撤销（revoked）的订单会被返回：如果你退款时没有勾选 revoke 选项，该订单根本不会出现在 API 结果里。第二，有些退款的理由是「购买从未被开发者确认（acknowledge）」，也就是说这笔被退的订单在你的记录里可能压根不存在。

3. 第一步——先在 Play Console 里给订单分类

Manage your app's orders and issue refunds 是资金事件出现的地方，其中的状态标签正好携带了现在要花钱的那个区别：

Pending refund——已申请但尚未处理的退款。
Refunded——有两个必须区分的变体：This refund was paid by Google 与 This refund was a chargeback。
Pending partial refund / Partially refunded——部分金额的退款。

带 chargeback 字样的那个才是贵的：钱是被用户找银行要走的，不是你批准退的。同一页也确认，你可以自己对应用内购买与付费应用发起全额或部分退款——当用户还不满但还联系得上时，这是更便宜的路径。

4. 第二步——把 Voided Purchases API 接起来

这是让你「有反应能力」的管道，它的限制在文档里写得很精确：

接口：GET https://www.googleapis.com/androidpublisher/v3/applications/your_package_name/purchases/voidedpurchases，用具备 View financial reports 权限的 OAuth 客户端或服务账号鉴权。
回溯窗口：最多最近 30 天。更早的作废购买无论你传什么 startTime 都不会返回；默认值为 30 天前。
分页：maxResults 默认 1000，上限也是 1000；用 nextPageToken 续取。请用续传令牌翻页，而不是把每页条数调大。
订阅：type=0 只返回应用内购买；type=1 会加上订阅购买，且一旦请求订阅，就必须改用响应中的 orderId，因为订阅视图会返回多个共用同一个 purchaseToken 的订单。
部分退款：includeQuantityBasedPartialRefund=true 会补上带 voidedQuantity 的数量型部分退款。当剩余数量最终被全部退掉时，那条记录没有 voidedQuantity——这个「缺失」正是文档定义的「已全额退款」信号。

一个会让朴素的时间窗口 join 出错的细节：记录是按 API 认为该订单何时被作废 来过滤的，而不是按响应里的 voidedTimeMillis。一个按月跑、漏跑一次的任务会静默丢数据，因为窗口不会延长。让调度频率高于窗口长度，按 orderId 或 purchaseToken 去重，并把它当作「该撤销」的信号，而不是完整的账务台账。

5. 第三步——在 24 小时内应答拒付

Google 的指南 Help Google dispute chargebacks 描述了这个新流程，而且它是有硬时限的：

盯住通知。当用户发起需要开发者复核的拒付时，Play 会发送 PendingRefundReviewNotification 实时开发者通知。RTDN 参考把它列为 DeveloperNotification 的一等字段，并与 voidedPurchaseNotification、一次性商品、订阅和测试通知互斥。
收集证据，在收到通知后 24 小时内应答，方式是调用 Review Refund API。你需要给出退款偏好，以及购买使用情况的证据——订单的交付状态、商品是否已被消耗。
记住「只认第一次」。Play 会记录你针对某条通知所做的第一次 API 调用，并忽略之后的调用，同时仍然返回 OK 状态。也就是说，重复触发不会被第二次纠正，字段映射错了事后也补不回来。

官方把 Review Refund API 定性为可选——Google 并不强制你应答。但当你要自己承担商品价款＋银行手续费之后，沉默就变成最贵的选择；而 24 小时的时限意味着，这套集成必须在第一条通知到达之前就存在。这与实时开发者通知的整体规律一致：一个已接好、已测过的 webhook 或 Pub/Sub 订阅是前提，不是后续待办。

6. 第四步——在真的需要之前先测通拒付路径

Google 在 Play Billing 测试指南中记录了「用户发起拒付」的测试流程，这是唯一能可靠确认三件事的办法：你的 RTDN 订阅端确实收到 PendingRefundReviewNotification；你的处理逻辑把它映射到正确的订单与购买令牌；你的 Review Refund 调用对测试购买能成功。处理逻辑要幂等，并记录下第一次响应——因为只有第一次算数。通知链路必须端到端验过：建好却从未跑过的订阅不构成任何控制。

7. 第五步——搞清楚退款对收款的影响

同一个订单管理页面也把资金机制写清楚了，而它比看上去更麻烦：

放款前退款 → 该金额不计入下一次收款。
放款后退款 → 该金额从未来的收款中扣除。
如果账户余额 变成负数并持续至少 48 小时，Google 将依据服务条款向你追缴，并从平时接收你收款的那张银行账户扣款，扣款金额等于发起扣款当日的负余额。

实务结论：在收入偏低的月份集中出现拒付，不只是「这次少收点」——它可能直接从你的银行账户里把钱划走。收入波动大、有季节性峰谷的账号，应当主动盯住这个数字，而不是等一条扣款通知来发现它。

8. 第六步——别忽略面向用户的那 48 小时

Google 面向用户的文档解释了争议为什么会升级到银行。Learn about Google Play refund policies 指出：退款政策因商品、支付方式与地区而异；Play 商店上大多数应用由第三方开发者制作；开发者可以按自己的政策与适用法律处理退款——并直接建议，联系开发者往往是解决问题最快的途径。Request a refund on Google Play 则告诉用户：想退款且距离购买已经超过 48 小时时，请联系开发者。EEA 与英国用户对 2018 年 3 月 28 日及之后的购买另有路径。

结论并不光鲜：你的退款政策页与一个能联系上的支持邮箱，本身就是拒付预防基础设施。头两天联系不上你的用户，下一步就是他的银行；而自 2026 年 8 月 3 日起，那条路径正是要你付出「价款＋手续费」的那一条。

9. 不要做的事

不要拿到第一个信号就批量撤销。Voided Purchases API 被明确描述为「何时采取进一步行动的指示」；Google 自己的指引要求一套公平、透明的撤销政策：撤销用户对应用内商品的访问权限时要告知用户，政策变更生效前要给用户足够时间理解，并允许用户对决定提出异议。
不要用「不勾 revoke」的方式退款，还指望管道能发现它。只有已撤销的订单会出现在 API 里。
不要把该 API 当账本。它包含其他订单来源遗漏的支付机构拒付，同时又不包含那些从未被确认的退款。
不要让调度周期等于窗口长度。30 天的窗口配一个按月任务，等于对单次失败零容错。

来源

正在规模化运营开发者账号？运维这一块交给我们。

✔ 已提交

我们已收到你的信息，会在 24 小时内回复。

也可发邮件给 expert@kapps.store
← 返回修改