快速解答:在 Google Play 上,大多数退款都无需你参与——Google 直接发起退款、撤销权益(entitlement),并在事后通过作废购买(voided purchase)通知你。你唯一能真正申诉的退款是处于审核中的拒付,Google 会给你大约 24 小时的时间提交处理建议。其他所有情况你只能追踪记录,而无法申诉。分清这两者的区别,决定了你是能挽回收入,还是眼睁睁看着收入悄然流失。
为什么 Google Play 与 Apple 不同
如果你是从 Apple 退款那边过来的,请先调整预期——这两个应用商店的运作方式截然不同。
在 Apple 平台上,开发者可以收到 CONSUMPTION_REQUEST 通知,并为 Apple 的退款决策流程提供消费信息(consumption information)。这正是 apple 退款自动化 所涉及的工作流程。
Google Play 采用的是另一种模式。Google 可能会依据自身政策处理退款,而特定的拒付则可能进入开发者审核流程。当某笔拒付需要开发者审核时,Google 现在会发送 PendingRefundReviewNotification 通知。随后,开发者可以使用 ReviewRefund API,在 24 小时内提交退款处理偏好(refund preference)以及相关的购买使用证据。
在构建 google play 退款处理流程时,搞清楚这一区别至关重要。
Play 上会发生的三种情况
把 Google Play 上实际发生的事情拆分成三种不同的事件会很有帮助,因为开发者常常把它们混为一谈,然后又纳闷自己为什么“无法申诉退款”。
事件 | 由谁决定 | 你能申诉吗? | 你如何得知 |
用户/Google 发起的退款 | 否 | 事后通过作废购买通知得知 | |
作废购买 | 否 | 实时开发者通知 | |
处于审核中的拒付 | 由 Google 告知后,交由卡组织决定 | 是——大约有 24 小时的响应时间 | 实时开发者通知 |
前两种情况你只需记录下来,以保持权益和分析数据的准确性。第三种情况则是唯一一个你能够施加影响的决策窗口。
拒付审核:唯一可以申诉的情形
Google Play 拒付是指客户通过其金融机构对一笔款项提出异议,而不是简单地申请一次普通的 Google Play 退款。
当某笔拒付需要开发者审核时,Google 会发送 PendingRefundReviewNotification 通知。开发者随后可以评估该笔交易,并提交诸如 APPROVE(同意)、DECLINE(拒绝)或 NEUTRAL(中立)等退款处理偏好,以及相关的购买使用证据。目前,Google 为该审核流程提供 24 小时的响应窗口。
在 Google Play 退款流程中,正是这一环节,时间把控至关重要。
实际可行的做法是实时捕捉每一个待处理的审核,并在 24 小时窗口关闭之前提交相应的处理建议。
作废购买:只记录,不申诉
除拒付审核之外的其他所有情况,都需要用不同的方式来处理。
借助 voided purchases api(作废购买 API)工作流程,开发者可以识别出已取消或作废的购买,从而让应用保持权益状态和财务报告的准确性。
你不能把每一次作废购买都当作一次申诉机会。相反,你需要记录该事件,并确保用户的访问权限如实反映实际的购买状态。
这一点之所以重要,原因有三:
权益准确性:如果某次购买已被退款或撤销,你的应用应当反映这一变化。不再拥有有效权益的用户,不应继续获得高级权限。
数据分析的准确性:如果退款和拒付没有被正确计入,会影响收入报告、LTV(用户生命周期价值)以及其他订阅指标。
模式识别:即使你无法撤销单笔交易,来自同一地区、同一 SKU 或同一获客渠道的一批作废购买,仍可能揭示出产品、计费或获客方面的问题。
因此,正确的做法是:记录每一个相关事件,保持权益和报告数据的准确性,并把真正的申诉精力花在那些进入开发者审核流程的拒付上。
要实现实时可见性,实际需要什么
如果没有实时可见性,以上这些都无从谈起。
Google Play 通过 Google Cloud Pub/Sub 使用实时开发者通知,将相关的计费事件告知你的后端。其中 PendingRefundReviewNotification 尤为重要,因为它会告诉你的系统:某笔拒付需要开发者审核,且有一个 24 小时的响应窗口。
正是在这里,实时开发者通知不再只是一项监控功能,它们可以成为自动化退款工作流程的触发器。
你的后端需要接收该通知、识别受影响的订单、评估可用的交易和消费信息,并通过 Google Play Developer API 提交相应的响应。
你还需要将通知数据与 Google 的 API 进行核对,以免遗漏事件,从而悄无声息地错过某次退款或权益更新。
对于处理大量交易的团队来说,手动维护这套基础设施在运营上可能会非常昂贵。
一个托管的 Google Play 退款管理软件平台,可以通过集中管理通知、退款事件、拒付审核和分析数据,大幅减轻监控和工作流程方面的负担。
可申诉部分是如何处理的
一旦通知开始流转,就有两项工作需要全天候、不间断地完成:
处理拒付审核:接收 PendingRefundReviewNotification 通知,评估该笔交易,并在 24 小时窗口内通过 ReviewRefund API 提交相应的处理建议和购买使用证据。
处理其他所有情况:记录退款或作废购买,更新权益,并将数据输入你的分析系统,这样即使是无法申诉的事件,也能为你留下准确的数据和可见的模式。
Play Console 退款流程在手动查看订单、发放符合条件的退款时依然很有用。Google 的文档说明了如何通过 Play Console 执行退款以及订阅退款/撤销操作,同时 Google Play Developer API 也可用于支持的退款操作。
RefundSensor 可以在一个 dashboard 中同时完成这两项工作,并与你的 Apple 退款一并管理,这样你就不必为每个应用商店分别运行和维护独立的系统。
这能做到什么,又做不到什么
它做不到把每一笔 Google Play 退款都变成一次申诉。Google 可能会依据其退款政策发起退款,而这类事件与进入开发者审核流程的拒付是不同的。
它也无法保证任何一笔具体的拒付都会朝着对你有利的方向解决。审核流程由 Google 决定,开发者提交的处理建议并不保证最终结果。
但它能够确保你的系统检测到待处理的拒付审核,在可用窗口内做出响应,并追踪其他退款和作废购买事件,从而使你的权益和分析数据始终保持准确。
对前两点保持务实的认识,正是第三点有价值的原因所在:你不再因为时间问题而错过审核机会,也不再对其余的 Google Play 退款活动一无所知。
官方资料来源 {#official-sources}
Google 的政策和 API 会不断变化,因此请以 Google 的官方文档作为最终依据:
一个 dashboard,覆盖两大应用商店。RefundSensor 能够实时捕捉 Google Play 拒付审核,并在窗口期内提交拒绝处理建议,同时追踪其他所有退款和作废购买,并在同一个地方为 Apple 完成同样的工作。通知自动配置,无需修改代码。 免费开始 →
发布后需添加的内部链接:Apple 退款自动化核心文章 · voided purchases API 与 RTDN 对比 · 退款滥用模式。
常见问题
只有一种情况可以:处于审核中的拒付(chargeback),Google 会给你大约 24 小时的时间提交处理建议。普通退款和由 Google 发起的撤销都由 Google 自行决定,开发者无法参与决策,你只能追踪记录,无法提出申诉。
当客户向其银行或卡组织对一笔款项提出异议时,争议便会进入审核窗口期。Google 会允许你提交处理建议,通常你有大约 24 小时的时间。
退款是指款项被退回。作废购买是 Google 发出的通知,表示某次购买已不再有效,通常是退款或撤销的结果。你可以利用作废购买事件来保持权益(entitlement)和分析数据的准确性。
创建一个 Google Cloud Pub/Sub 主题,授予 Google Play 发布权限,在 Play Console 中进行配置,并让你的后端订阅该主题。同时要与 Voided Purchases API 进行核对,以免遗漏通知造成数据缺口。RefundSensor 会自动配置 Pub/Sub 主题,你只需粘贴一个主题名称即可。
不需要。退款和拒付的处理都在服务器端完成,通过 Real-time Developer Notifications 和 Google Play Developer API 实现,无需 SDK,也无需重新提交应用。
