大多数"最佳退款工具"榜单都是由从未真正接入过这些工具的人写出来的。这里是我自己希望能看到的版本,基于每个平台实际向 Google 发送的内容,以及它悄悄遗漏的部分。
这里先快速说明一个容易让人混淆的点:Google Play 订阅退款事件和拒付(chargeback)遵循两套不同的规则,大多数平台只能妥善处理其中一种,另一种只能部分应对。你只能对拒付提出申诉。其他所有情况,你都只能检测。
如果你想跳过对比, Google Play 拒付防御 是我们自己的产品页面,也是这篇文章的精简版。
要点总结
Google 只允许你通过 Review Refund API 对拒付提出申诉,时间窗口约为 24 小时。本文提到的每个平台都是在这一限制条件下运作的。
Google 接受三种偏好设置:APPROVE、DECLINE、NEUTRAL。任何平台都无法通过该 API 实现部分退款。
真正的区别在于证据。有些工具会发送使用数据,有些只发送一个偏好设置和一个布尔值。
Google 从不告知你最终结果。各平台只能通过轮询获取结果,因此胜诉率的统计数据普遍存在延迟。
检测才是更大的缺口。不撤销权限的退款、部分退款以及未确认的购买,对大多数技术栈来说都是不可见的。
真正需要比较的内容
就四件事。其他的都只是定价页面上的噪音信息。
它发送的是消费证据,还是只是一个偏好设置?这正是 Review Refund API 的核心所在。Google 要求提供交付状态和商品消耗情况,以便能够代你向银行申诉。一个只提交 APPROVE 或 DECLINE 的工具,可能只用到了这条通道大约三分之一的能力。
它是否需要 SDK?如果需要,就意味着你要把退款防御和订阅基础设施绑定在一起。这是一个需要认真权衡的决定,但并不总是坏事。
它能检测到什么?申诉只是 Google Play 退款管理的一半。知道退款已经发生并及时切断访问权限,是另一半。
它是否也支持 Apple?大多数团队同时运营两个应用商店。为同一项工作使用两家供应商,正是事情容易出岔子的原因。
RevenueCat Refund Control
如果你的订阅已经跑在 RevenueCat 上(很多应用确实如此),这是最强的选择。
Refund Control 使用项目级策略,按从上到下的顺序进行评估,第一条匹配的策略生效。你可以选择 Prefer full refund(倾向全额退款)、Prefer no refund(倾向不退款)、Send consumption data only(仅发送消耗数据)或 Do not respond(不响应)。它会代你调用 Google 的 orders.reviewrefund 接口。
这部分值得多读一遍。根据 RevenueCat 自己的文档,他们发送给 Google 的请求体中包含三个字段:pendingRefundToken、设为 true 的 sampleContentProvided,以及你设置的 refundPreference。他们明确说明目前尚未发送消耗百分比或使用事件数据。也就是说,你拿到的是偏好设置通道,而不是证据通道。
他们对检测方面的局限也很坦诚。在 Play Console 中发起退款时如果未勾选撤销权限的选项,系统就无法检测到。部分退款不会被同步,未确认购买产生的退款也不会被捕获。任何由 Google 而非由你本人批准的退款,最多可能需要 24 小时才能显示出来。
RevenueCat 真正胜出的地方,是这里没有任何其他平台能做到的一点:你可以直接从仪表盘或通过一个 REST 接口自行发起 Google Play 订阅退款,并在同一次调用中撤销访问权限。如果你的客服团队是直接处理退款的,这一点就很重要。
Adapty Refund Saver
Refund Saver 现在不仅支持 Apple,也覆盖了 Google Play,如果你此前已在 iOS 上使用它,该功能会默认开启。
它确实会在拒付审核时发送使用证据,这一点让它在真正影响结果的环节上领先于 RevenueCat。对 Google Play 的支持是在 8 月 3 日那次让拒付成本大幅上升的变更之后才上线的。
有两个坦诚说明的局限,均来自 Adapty 自己的文档。Google 只接受 decline(拒绝)、approve(同意)或 no preference(无偏好)这三种设置,因此 Apple 端的 Grant prorated(按比例授予)在 Google 端没有对应选项,Adapty 会改为发送 No preference。另外,Google 在审核结果出来时不会通知任何人,所以 Adapty 需要持续轮询订单状态,直到结果落定。Google Play 的结果出现时间会比 Apple 的更晚。
真正的门槛在于 SDK。Refund Saver 是一个平台功能,而不是独立产品。如果你的订阅没有跑在 Adapty 上,为了用上它就得整体换平台。对一些团队来说这是划算的取舍,但对大多数团队而言并不划算。
Refund Sensor
这是我们自己的产品,请自行权衡判断。
无需 SDK。只需使用 Google 账号登录,授予两项 Play Console 权限(查看财务数据、管理订单和订阅),它就会在你自己的 Google Cloud 项目中配置好 Pub/Sub 主题和推送订阅。无需在 Play Console 中粘贴任何内容,也不需要发布新版本应用。
它会在 24 小时的时间窗口内,通过 orders.reviewrefund 提交带有交付和使用情况证据的拒绝建议,同时单独追踪那些你无法申诉的退款——这正是大多数团队完全没有可见性的部分。两个应用商店的数据都集中在同一个仪表盘中。
坦白说存在一些差距:它比 RevenueCat 或 Adapty 更新、更年轻,也没有付费墙、A/B 测试或订阅分析功能,因为那不是这款产品的定位。如果你需要订阅基础设施,还需要搭配使用前面提到的其他平台之一。
RefundHalt
如果你想要的是按个案设定规则,而不是统一的偏好设置,这个工具值得一看。无需 SDK,同时支持两个应用商店,并会从你服务器上的某个接口拉取使用证据,因此这些证据是你自己提供的,而不是靠推断得出的。
有一点需要提醒:他们发布的部分对比内容早于 Refund Saver 支持 Google Play 之前,因此请查阅最新文档,而不要只参考对比页面。
自己动手搭建
这是一个合理的选择,如果你已经有后端系统在运行,实际成本也比看起来要低。
你需要在 Monetize 下的 Monetization setup 中启用 RTDN。一个 Pub/Sub 主题。一个能解码 base64 的 data 字段、并根据五种通知对象中到底收到了哪一种进行分支处理的消费者程序。当收到 pendingRefundReviewNotification 时,保存 pendingRefundToken 并与 24 小时的时间限制赛跑。最后调用一次 orders.reviewrefund。
真正不是一个周末就能搞定的部分是:为七周前购买的某笔订阅准备出真实的消耗数据,再加上幂等性处理(因为 Google 会重试),还要每晚跑一遍 Voided Purchases 的排查,以捕获通知遗漏的情况。 Voided Purchases API 与实时开发者通知对比详细介绍了这两条数据通道各自负责什么。
这也是对"开发者在不想依赖第三方供应商的情况下如何自动化处理 Google Play 退款"这一问题最诚实的答案:本质上就是一个 webhook 消费者、一个计时器,以及一个数据问题。
那么该选哪一个
已经在用 RevenueCat,主要需要检测功能加一个偏好设置?选 Refund Control,今天就可以开启。
已经在用 Adapty,想要在不额外投入工作量的情况下发送证据?选 Refund Saver,它可能已经默认开启了。
两者都没在用,也不想为了防御退款而整体换平台?选 Refund Sensor 或 RefundHalt。
你遇到的争议大多偏向欺诈类型,需要按个案处理的逻辑?选 RefundHalt,或者自己动手搭建。
以上都不适用,退款量也微乎其微?暂时什么都不用做,但还是建议接入 RTDN。它是免费的,等退款量上来时,你会需要这些历史数据。
每个平台页面都会跳过不提的部分
"如何自动化处理 Google Play 订阅退款"对大多数应用来说都是一个问错了的首要问题。开发者面对的 Google Play 退款可以分为两类:你能够影响的,和你只能被动应对的,而后一类清单往往更长。
你能做的只有对拒付审核提出申诉,仅此而已。客服退款、48 小时 Play 退款以及未确认的试用转化退款,都是在没有你参与的情况下决定的。在这些情况下,唯一能自动化的,就是快速检测并及时切断访问权限。
这意味着所谓的 Google Play 退款自动化,实际上是披着一件外套的两款产品:一个是用于应对拒付的响应引擎,另一个是用于处理其他一切情况的检测引擎。大多数供应商只擅长其中一种。在做出选择之前,先弄清楚你买的是哪一种。在挑选之前,也值得读一读 Google 官方发布的 退款保护与拒付成本公告,它解释了为什么响应这一侧突然变得如此重要。
参考来源
常见问题
只能自动化处理拒付这一子类别。当客户向银行提出争议时,Google 会开启一次审核,你大约有 24 小时的时间可以通过 Review Refund API 做出回应。其他所有类型的退款都是在没有你参与的情况下决定的,你只能对它们进行检测。
这取决于你现在用的是什么。如果你的订阅跑在 RevenueCat 上,就选 RevenueCat。如果你用的是 Adapty 的 SDK,并想自动发送使用证据,就选 Adapty。如果你想在不换平台的情况下实现退款防御,就选 Refund Sensor 或 RefundHalt。
不允许。Google 通过该 API 只接受 APPROVE、DECLINE 或 NEUTRAL 这三种设置。按比例退款这一选项存在于 Apple 一侧,但在 Google 这边没有对应选项,因此提供该选项的平台在 Play 上会改为发送 No preference(无偏好)。
可以自己基于 RTDN 和 orders.reviewrefund 搭建方案,也可以使用通过 Play Console 权限和 Google Cloud 项目连接的服务。这两种方式都不需要改动应用的二进制文件。
答案是:要慢慢判断。Google 在审核结果出来时不会通知任何人,所以各平台只能轮询订单状态。结果数据注定会有延迟,因此评判一个工具时,应该看它是否在时间窗口内成功提交,而不是看当天的胜诉率。
自 2026 年 8 月 3 日起,一次申诉失败的拒付成本等于购买金额减去 Google 的服务费,再加上一笔银行手续费。对于低价商品来说,光是这笔手续费就可能超过销售额本身。在做决定之前,先根据你自己的订单金额算一算这笔账。
