我第一次错过的拒付发生在一个周六晚上 11:40。我知道这件事，是因为我在周一翻查 Pub/Sub 日志时，发现它一直躺在一个没人消费的主题（topic）里。
那是在 2026 年 8 月 3 日之前。当时，输掉一笔拒付的代价仅仅是失去那一笔销售额，别无其他。
如今，对于该日期之后下的订单，Google Play 会将拒付成本转嫁给开发者。你需要承担订单金额减去其服务费后的损失，外加每笔 15 至 25 美元的银行卡网络费用。不过 Google 也给了一些回报：Review Refund API，以及大约 24 小时的证据提交时间。
所以问题不在于你是否要处理拒付，而在于凌晨时分到底是什么在处理它们。相关设置可参见 Google Play 拒付防御。这里是详细版本：四种选择，其中两种我会劝大多数团队放弃。
关键要点
Google Play 拒付处理只有一个入口：在收到 Pending Refund Review Notification 后的 24 小时内调用 ReviewRefund API。
Google 只会记录你第一次调用的结果，其余调用都会被忽略，但仍会返回 OK。只有一次机会，无法修正。
只有拒付是可以申辩的。客服退款、48 小时 Play 退款以及未确认的试用，都是在你不参与的情况下自动决定的。
四种真正可行的替代方案：自行搭建、使用现有的订阅平台、购买专门软件，或直接承担损失。
这笔账从 2026 年 8 月 3 日起发生了变化。如果在一个 99 美元的年度套餐上错过一次时间窗口，损失就是订单金额外加一笔网络费用。
手动处理实际上是什么样子
公平地说，"手动"涵盖了很大的范围。一端是一个共享收件箱，有人想起来的时候就去查一下 Play Console；另一端则是排班表、Slack 频道，再加上一份记录争议订单的表格。
后一种做法确实更好，但它仍然会失败，而且原因与投入的努力无关。
首先，你看不到计时器。24 小时从 PendingRefundReviewNotification 到达你的 Pub/Sub 主题那一刻开始计算。如果你从未启用实时开发者通知呢？没有任何东西会告诉你有一个审核正在进行，Play Console 也不会为此打上标记。
其次——这一点常常出乎人们意料——Google 只会记录你第一次调用 ReviewRefund 的结果，之后的每一次调用都会被忽略，但仍会返回 OK，看起来就像是成功了。如果有人在早上 9 点，根据手动提取的数据往脚本里输入回应，很容易就会出一个填错的字段，而且无法撤销。
Google Play 拒付处理流程
值得详细说明一下，因为这个时间窗口比大多数人想象的要短。
客户向自己的银行提出扣款争议——不是向你，也不是向 Google。
Google 将该订单标记为待审核，并通过 RTDN 发送一个 PendingRefundReviewNotification，其中包含 pendingRefundToken、orderId、值为 7 的 refundReason（即 CHARGEBACK），以及你在购买时设置的 obfuscatedAccountId（如果设置过）。
你大约有 24 小时的时间，带着你的处理偏好以及能收集到的任何证据去调用 ReviewRefund。
Google 会用这些信息向银行进行申辩。
如果败诉，对于 2026 年 8 月 3 日之后下的订单，这笔成本就由你承担。
这里有一个值得注意的不对称之处。Apple 会通过 CONSUMPTION_REQUEST 就普通退款征询你的意见，而 Google Play 只会为拒付开启审核。其他所有情况都是在你不参与的情况下自行解决，你只能通过一次已撤销购买（voided purchase）得知结果。完整机制详见： Google Play 拒付机制详解。
方案一：自行搭建处理系统
一个 Pub/Sub 主题。在 Monetize 下的 Monetization setup 中开启 RTDN。一个推送端点，在信任消息之前先对其进行验证。然后解码 base64 格式的 data 字段，根据出现的五种通知对象之一进行分支处理，将订单匹配到对应用户，收集证据，再用一个有限权限范围的 OAuth 令牌调用 ReviewRefund。
搭建本身并不是昂贵的部分。如果你以前做过 webhook 相关的基础搭建，大概两周就能完成。
第二年才是昂贵的部分。Google 改动了某个字段。一个 OAuth 刷新令牌在某个周日悄悄过期了。而你的处理系统恰好就在同一个晚上、一笔 200 美元的争议到来时宕机——不知为何，事情总是这样发生。你会需要可观测性、重放处理机制，以及针对那些你从未见过的通知结构的测试。
如果你拥有自己的后端系统，并且退款确实是一条实打实的收入线，那就自己搭建吧——我也更希望你这么做。但如果你是独自开发产品的一个人，那这就是在浪费一个月的时间。
方案二：使用你已经在付费的订阅平台
在写任何代码之前，先检查这一点。RevenueCat 在其 Refund Control 功能中加入了 Google 的 Review Refund API，而 Adapty 在 Apple 一侧提供了 Refund Saver。
吸引人之处在于：你的收据、权益和客户映射本来就存放在那里，证据更容易获取，账户匹配的问题也已经解决。
局限在于：退款响应对它们来说只是一个功能，而不是核心产品本身。你能期待的是一个处理偏好加上几个标记，而不是带 IP 地址的 1,000 条使用事件。对许多应用来说这已经足够，但对欺诈占比较高的争议来说还不够。
方案三：专门的 Google Play 拒付管理软件
这个类别在 8 月 3 日之前几乎不存在，这也说明了这种激励机制有多新。
其形态大致一致：该服务订阅你的 RTDN，在时间窗口内附带交付和使用参与度证据提交拒绝建议，并逐案追踪处理结果。
Refund Sensor 就是从一个账户同时为 Google Play 和 App Store 做这件事。用 Google 账号登录，授予两项 Play Console 权限（查看财务数据、管理订单和订阅），它就会自行配置好 Pub/Sub 主题。无需 SDK，无需改动代码，也无需重新提交任何内容。
代价在于：多了一个供应商，多了一条月度费用。换来的则是你不必再是那个必须保持清醒待命的人。
方案四：直接承担损失
对某些应用来说，这是一个合理的选择，我不会假装不是这样。如果你卖的是一款 1.99 美元的消耗型商品，一年只遇到四次拒付，那投入两周的工程时间永远也无法收回成本。
不过，先算一算这笔账。在一个 99 美元的年度套餐上输掉一次拒付，损失是订单金额减去 Google 的服务费，外加 15 至 25 美元的网络费用。一个季度里遇到两次，答案就会不一样了。
如何自动化处理 Google Play 拒付
如果你选择了方案一，下面是搭建顺序。顺序的重要性比大多数人想象的要高。
在 Play Console 中启用 RTDN，创建 Pub/Sub 主题。在信任这条通道之前，先点击 Send Test Message 进行测试。
解码 data 字段，根据到达的通知对象类型进行分支处理——每条消息只会包含一种通知对象。遇到 pendingRefundReviewNotification 时，存储 pendingRefundToken 并启动一个计时器——不是发一封邮件，是启动一个计时器。
将 orderId 匹配到对应用户。obfuscatedAccountId 是最快的路径，这也足以成为你从购买环节就开始设置它的理由。
收集证据：sampleContentProvided、consumptionPercentageMilliunits（45200 表示 45.2%），以及最多 1,000 条带有时间戳和 IP 地址的 consumptionUsageEvents。
调用一次 orders.reviewrefund，refundPreference 设为 APPROVE、DECLINE 或 NEUTRAL 之一。记录这次调用、请求负载和响应结果。
另外，还要处理 voidedPurchaseNotification 以移除访问权限，并每晚运行 Voided Purchases API 进行对账。该接口每天的调用上限是 6,000 次。
最后一步正是大家都会跳过的那一步。我自己就跳过了好几个月。服务中断期间通知会被遗漏，而拉取式 API 正是你用来找出宕机期间到底发生了什么的方式。 Voided Purchases API 与实时开发者通知对比详细说明了每种信息源各自的作用。
Google Play 拒付预防
比上述任何方案都更省钱，而且对那些你根本预料不到的争议同样有效。
一个能联系到你客服的客户，就不会去联系他的银行。应用内一个清晰可见的联系方式，加上一天内的回复，就能在争议发生之前消灭相当一部分争议——比例之高令人意外。
接下来，让续订信息一目了然：价格、周期和续订日期都要和购买按钮出现在同一个页面上。在我见过的所有情况中，"意外"是引发争议最主要的原因。
还有两点常常被忽视。注意未确认的购买，因为那些在用户没察觉的情况下自动转化的试用，一个月后就会变成拒付。另外，把 voidedReason 当作一种欺诈信号来用。它共有九种取值，包括 fraud、friendly_fraud 和 chargeback，而出现这些情况的账户往往会重复出现问题。在再给一次试用机会之前，先把它们标记出来。
把你的拒付率控制在 Google 设定的阈值之下。持续存在的问题会影响账户信誉，而这比任何一次单独的退款都更糟糕。
参考资料
常见问题
退款是通过 Google 处理的，由 Google 或你在 Play Console 中决定。拒付则是客户直接找自己的银行处理，这样就纳入了银行卡网络的规则范畴。只有拒付会开启一个你可以回应的审核，而也只有拒付的费用会转嫁给你。
从收到 PendingRefundReviewNotification 起约有 24 小时。计时从通知送达时开始，而不是从你注意到时开始。
Google 会在没有你提供证据的情况下为拒付进行申辩，这是最弱的立场。对于 2026 年 8 月 3 日之后下的订单，一旦败诉，你需要承担订单金额减去服务费后的损失，外加一笔网络费用。
不可以。Google 只会记录你第一次调用 ReviewRefund 的结果，之后的调用都会被忽略，但仍会返回 OK。在正式上线前，务必先针对测试购买进行测试。
能在你不在线时自动提交回应的那一种。如果你有自己的后端系统，自己搭建是个合理的项目。如果没有，那么通过 Play Console 权限连接的 Google Play 退款管理软件，会比专门为一个边缘场景编写 Pub/Sub 消费者更划算。
不会。你是通过 Google 自己的 Play Developer API 提交建议，并以交付和消费证据作为支撑。这正是 Google 为此专门搭建的渠道。
