你可以暂停订阅或把续订日期往后推，而不是退款，这样能留住大部分收入

你可以暂停订阅、把下一次扣费推到未来，或者送给订阅者一些免费天数，这几种做法都能把客户留在你的账面上，而不退回你已经收到的一分钱。退款正好相反。它退回上一次扣费，有时是整整一年的费用，而且客户通常反正也走了。所以当有人说想退出或要求退款时，退款很少是你唯一的选择，而且它几乎总是最贵的那一个。

这里是全貌。Google Play 允许用户暂停一个自动续订的订阅，也允许你把下一次扣费往后推，从一天到一年不等。Apple 没有暂停按钮，但它允许你每年延长续订日期两次，每次最多 90 days，客户不用付费。接下来讲的是每个手段在各个商店里如何运作，与退款相比它们让你花多少，以及有一种情况下它们全都帮不上忙。

当订阅者想离开时，你真正拥有的选择

取消和退款不是同一件事，把每一个不满意的订阅者都当成退款来处理，正是各家工作室退回本不必退回的钱的原因。取消会停止下一次续订，把已经付的钱留在原处。退款则伸回去，把你已经入账的一笔扣费拿走。在这两者之间，有一套正是为这一刻而设的商店工具：留住这个人的订阅，或者在不逆转付款的情况下把关系维系好。

先暂停、推迟、延长，最后才退款

顺序很重要。暂停会把订阅停放起来，让客户能离开一阵子再回来。推迟或延长会赠送免费时间，把一个本来要退款的请求变成一次善意的表示，让你花的是几天，而不是钱。退款是最后手段，因为在这四种里，它是唯一一个把钱从你账户里拿回去的。当其他三种都不合适时再动用它，而不是一上来就用。

如何在 Google Play 上暂停订阅

在这两个商店里，只有 Google Play 有真正的暂停。用户在 Play Store 里打开自己的订阅，选择暂停它，商店会处理其余的事。你不需要审批，但你可以围绕它来做设计。

暂停能持续多久

用户可以暂停一段时间，时长在 one week 到 three months 之间，可选项取决于套餐的计费周期。暂停总是只在当前计费周期结束后才生效，所以客户保留了已经付费的那部分，暂停在下一次续订时干净利落地开始。

暂停对访问权限、计费和你的查询有什么影响

在订阅被暂停期间，用户没有访问权限，也不支付续订价格。没有钱离开你的账户，也没有钱进入。有一个集成细节常常让团队栽跟头：除非你把 includeSuspendedSubscriptions 设为 true，否则一个被暂停的订阅不会被 Play Billing Library 的 queryPurchasesAsync() 方法返回。忽略这一点，你的应用就可能把一个只差一次点击就能回来的暂停订阅者，当成彻底流失的用户。

暂停结束时会发生什么

在暂停期结束时，订阅恢复，Google 会尝试为其续订。用户也可以在暂停期间随时手动恢复，一旦手动恢复，计费日期就移到手动恢复的那一天。如果续订尝试失败，这个订阅会走和其他任何订阅一样的续订失败路径，经过计费宽限期和账户保留，所以暂停不会去掉你的挽回步骤，它只是把这些步骤往后延。

Apple 没有暂停，所以你改为延长续订日期

Apple 不给用户一个暂停开关。它给开发者的，是把订阅者的续订日期往未来移的能力，这会赠送免费的服务时间，并把下一次扣费往后推。这是一个服务器端的动作，而不是客户去点的东西。

每年两次，每次最多 90 days

使用 App Store Server API，你可以为一位客户的订阅移动续订日期，每个日历年 twice per calendar year，每次往未来移 up to 90 days，客户不会因这段增加的时间被扣费。你会附上一个 extendReasonCode 来记录原因，比如客户满意度或某个服务问题。这是 Apple 最接近暂停的做法：不是把套餐停放，而是延长它，让这个人保留访问权限，而你本来要收的那笔费用只是往后移了。

一次调用就能覆盖一场故障

还有第二个端点，能一次性为所有活跃订阅者延长续订日期。在一场影响了你整个用户群的故障之后动用它，此时给所有人赠送几天免费时间，比应付一波又一波单独的退款请求更便宜也更从容。它是同一个想法的批量版本：用免费时间来支付，而不是用逆转的扣费。

推迟扣费，在不退款的情况下赠送免费时间的手段

Google Play 对应 Apple 延长做法的是推迟扣费，而且在时长上更慷慨。你调用 purchases.subscriptionsv2.defer，把一个比当前更晚的新到期时间设进去。每次 API 调用最少可以推迟 one day、最多推 up to a year，想推得更远，就在新日期到来之前再调用一次。

客户什么都保留，且什么都不付

在推迟期间，用户仍然订阅着你的内容并拥有完整访问权限，但不会为这多出来的时间付费，续订日期也更新为新的日期。Google 自己的例子就是一份微型的留存操作手册：因为填写一份反馈问卷而赠送一周免费，或者在一场持续的故障导致人们无法使用你的服务后补偿访问权限。这里面的每一个，都是一笔你没有开出的退款。

接好通知

推迟一笔扣费会触发一个 SUBSCRIPTION_DEFERRED 实时开发者通知，这样你的后端就能记录新的续订日期，并让权益保持同步。预付套餐的运作方式相同：defer 调用延长的是到期时间，而不是续订日期。

每个选项在钱上让你花多少

这一部分应该决定你尝试各种做法的顺序。这四种做法在价格上相差甚远，而差距最大的地方，恰恰是退款最伤人的地方，也就是一个时间长、价值高的套餐上。

退款是唯一一个把钱拿回去的做法

退款把上一次扣费退给客户。在月度套餐上那是一个月。在年度套餐上，它按那最后一次扣费计算，也就是整整一年，在一个事件里被逆转。除了退回去的金额之外，还压着你为服务这个订阅已经花掉的成本：算力、第三方 API 调用、存储，以及你付给某位创作者的任何分成，这些都收不回来。暂停、推迟或延长都不碰这些。它们唯一让你花的，是你推迟的未来收入，或你补偿的少数几天。

拒付会让这笔账更难看

当替代方案甚至不是一次干净的退款，而是一场银行争议时，这笔钱的账就更清楚了。对于 August 3, 2026 之后下的 Google Play 订单，一场败诉的拒付让开发者付出的是购买价格减去 Play 的服务费，再加上银行的拒付费用。一次暂停或几天补偿，如果能让一个沮丧的客户不去找他的银行，那它不只是比退款便宜，它还挡掉了一笔更大的成本。

什么时候暂停或推迟是错误的工具

一旦客户不再跟你说话，转而去跟他的银行说话，这一切就都不管用了。暂停、推迟和延长，都是你提供给一个还在你应用里的订阅者的东西。对于一场已经提交的争议，它们无能为力。

一场已提交的争议有它自己的短暂时钟

一旦一笔扣费被争议，你唯一的输入就是一个狭窄的窗口。Apple 会给你的服务器发一个 CONSUMPTION_REQUEST，并等待 up to 12 hours 以获取消费数据。Google Play 会启动一个 24 hours 的时钟，并通过 orders.reviewrefund API 处理你的证据。错过任何一个窗口，决定都会在没有你的情况下作出。所以这些留存手段是用在退款请求之前那一刻的，而不是用在一场银行争议之后。

退款有时才是对的答案

对于一个确实受了委屈、并且想要回自己的钱而不是你更多产品的客户，给他免费时间可能会被读作一种搪塞。当公平的做法是退回那笔扣费时，就退回它。重点不是永远不退款，而是当一次暂停或一周的补偿本可以既留住钱又留住客户时，不要条件反射式地退款。

留存清单

这一切都不深奥。它是订阅者发出想退出信号那一刻的一套简短例行流程。

• 把退款当成四个做法里的最后一个，排在暂停、推迟和延长之后，而不是第一个。
• 在 Google Play 上，为暂停做好设计：设置 includeSuspendedSubscriptions，这样你的应用就不会把一个被暂停的订阅者误当成已流失的。
• 像对待一次新购买那样处理暂停结束时的续订，因为那正是一个被暂停的订阅者被留住或失去的地方。
• 在 Google Play 上使用推迟扣费，在 App Store 上使用续订日期延长，用补偿天数来代替开出退款。
• 记录 SUBSCRIPTION_DEFERRED 通知和这次延长，让你的收入数字反映出被移动的续订日期。
• 把退款留给那个确实受了委屈并想要回自己钱的客户，而不是给每一个请求。
• 记住这些手段在一场银行争议提交后就不再管用，当有争议时，回应那 12 hours 和 24 hours 的窗口。