大多数关于如何处理退款请求的指南，都是从收到通知那一刻开始讲起：Apple 给你发通知，Google 给你发通知，接下来该回复什么。这种思路没错，但等通知到达时，真正有用的工作早已完成，或者早已错过——因为你能对一笔购买说出什么，取决于当时你记录了什么。
所以这篇文章要从更早的环节——结账——讲起：当退款请求到来时，哪些购买数据才重要，该把它们存放在哪里，以及如何把它们转化为商店会真正纳入考量的回复。如果你从未给购买记录关联过标识符，请先阅读我们关于 appAccountToken 与退款防御的文章，因为下文内容都假定你能够把交易 ID 与具体用户关联起来。
核心要点
Apple 和 Google 都会自行决定退款结果，而且双方现在都会先向你索取购买数据。Apple 给你 12 小时，Google 给你 24 小时。
商店想要的是粗略的事实，而不是日志：是否已交付、使用了多少、是否获得了试用样本，以及你的偏好是什么。
每笔购买你都需要存储四项信息：是谁、何时交付、何时使用，以及该账户之前是否已经退款过。
Apple 表示，大多数退款请求会在购买后 30 天内提出。数据至少要保留这么久，实际建议保留 90 天。
开始主动回应的应用，退款率大约会下降三分之一，但前提是你确实有记录在案的信息可以陈述。
商店实际向你索要什么
Apple 的要求很简单。当客户对一笔应用内购买申请退款时，你会收到一个 CONSUMPTION_REQUEST，然后通过 Send Consumption Information 接口回复五个字段：客户是否同意你分享数据、购买是否已交付、消耗了多少百分比（以毫分比表示，100,000 即代表全部用完）、客户此前是否获得过免费样本或试用，以及你的退款偏好。Apple 以前要求提供十几个字段，后来取消了大部分，我的理解是 Apple 认为自己对客户历史的了解已经比你更清楚。
Google 的版本是针对拒付（chargeback）的，内容更丰富一些。待处理退款审核通知会通过 Real-time Developer Notifications 携带一个 token 到达。你需要带着这个 token、同样的样本内容标记、DECLINE、APPROVE 或 NEUTRAL 之一的偏好、一个可选的消耗百分比，以及最多 1,000 条带时间戳的使用事件，提交给 orders.reviewrefund。鉴于 Google 将从 2026 年 8 月 3 日之后的订单开始向开发者收取拒付费用，这一点变得更为重要。
两家商店都不需要你的分析数据导出文件。它们想要的是交付情况、消耗情况、试用情况和偏好，你存储的其他一切数据，存在的意义就是为了能真实、快速地填上这几项。
用于退款的购买历史：该保留什么、保留多久
最低限度需要保留以下内容：
结账时的标识符。Apple 平台用 appAccountToken，Google 平台用 obfuscatedAccountId。没有它，退款请求只会给出一个交易编号，而你完全不知道这是谁的。Apple 的工程师还建议每位用户至少保留一个 originalTransactionId，因为只要有其中任意一个，你就可以调用 Get Transaction History，拉取该客户在你应用中的完整购买历史，无论他们是否仍安装着这款应用。
交付记录。你何时发放了金币或解锁了关卡，附带时间戳和结果。如果交付失败，就实话实说。这是唯一一种你应该希望退款获批的情况，若反而声称并非如此，只会消耗你日后需要用到的信誉。
消耗事件。不需要记录每一次点击，只需记录那些能证明购买已被使用的事件：花费了金币、打开了章节、执行了导出。Google 最多可接受一千条。Apple 只要一个百分比，但如果你从未记录过，就无法算出这个百分比。
每个商品的样本标记。这位客户是否获得过试用、预览或免费档位？两家商店都只需要一个是或否，但人们经常忘记记录这一点。
该账户此前的退款记录。无论如何，Apple 自己也会权衡退款历史，但你也需要它来制定自己的规则。
关于保留期限，Apple 表示大多数退款请求会在 30 天内到达，并建议据此存储消耗数据。我们保留 90 天，一方面是因为 Google 的拒付出现得可能更晚，另一方面是因为存储很便宜，而凭记忆争辩却代价不低。
购买历史如何帮助处理退款
一旦这些数据到位，处理请求就不再是凭主观判断，而变成了一次查询。
已交付、完全消耗、无试用、此前无退款记录：这种情况适合选择 DECLINE。已交付、几乎没有使用、一天内就提出请求：选择 GRANT_FULL 代价很小，不这么做反而显得小气。你这边交付失败：批准退款并修复问题。几周内部分使用：Apple 为此提供了 GRANT_PRORATED，Google 则用消耗百分比来实现同样的效果。
数据也印证了这一点。订阅制音频应用 Dipsea 在 2024 年末开始回应 Apple 的请求，约两周内退款率从 3% 降到了 1.9%。在拒付方面，Appcharge 告诉 PocketGamer，没有证据支持的争议胜率为 20% 到 30%，而有证据支持的争议胜率超过 80%。在 Refund Sensor 上的 800 多款应用中，77% 符合条件的请求都成功得到了辩护，而那些失败的案例，大多是因为没有留下任何记录。
购买历史做不到的是，让你赢得不该赢的争论。如果客户的数据显示他们只打开过一次应用，诚实的答案就是同意退款。
如何在时限内处理退款请求
两家商店的退款请求处理流程都有严格的时间限制，所以这更像是管道搭建，而不是主观判断。通知会抵达你注册好的接口。你需要验证签名、提取交易 ID、查找该用户的交付和消耗记录、计算百分比、根据你事先写好的规则选定偏好，然后发送出去。记录你发送了什么、何时发送，然后等待结果——在 Apple 平台上，结果是一条 REFUND 或 REFUND_DECLINED 通知。收到 REFUND 时，要在同一小时内撤销访问权限，因为一个已获退款却仍保留着内容的客户，往往还会再来一次。
有两件事容易让人栽跟头。一是同意：除非 customerConsented 为 true，Apple 不会接受提交，所以分享使用数据的授权必须在第一个请求到达之前就写进你的条款。二是时间：计时不会因为周末而暂停，而且出人意料的是，相当一部分请求会在深夜到达。退款请求管理，大体上就是确保始终有某个系统保持在线、随时响应。我们的 Apple 退款请求管理指南对运营层面有更深入的介绍。
面向开发者的退款处理软件，还是自己写代码
如果有后端团队，上述流程大约需要一周时间搭建，之后则是一项持续性的工作，而这项持续工作才是真正昂贵的部分。
如果你在使用 RevenueCat 或 Adapty，两者都会利用其 SDK 已经收集的使用数据来回应 Apple 的消耗请求，Adapty 还涵盖了 Google 的审核流程。如果应用里本来就集成了这些 SDK，这是一个合理的默认选择。
Refund Sensor 无需 SDK 就能完成同样的工作。你只需连接一个 App Store Connect API 密钥和一个通知 URL，它就会接收请求、在时限内发送回复，并为每个案例保留完整时间线。设置只需几分钟，定价为统一价。详情请见 Refund Sensor 官网。
无论你选择哪种方案，哪怕什么都不用，数据层始终是你自己的。没有任何面向开发者的退款处理软件，能凭空捏造出一条你从未保留过的交付记录。
结语
人们常把退款防御谈论成一个回复问题，但它其实是记录问题的下游结果。商店只问了四个范围很窄的问题，而你能否答上来，取决于你早在结账和交付环节就做出的决定——远早于有人想要退款的那一刻。
关联一个标识符，用时间戳记录交付和消耗情况，标记好样本信息，并把这些数据保留 90 天。做到这些之后，如何处理退款请求就会变成一条规则和一个 cron job，退款率也往往会随之自然改善。
常见问题
Apple 从发出 CONSUMPTION_REQUEST 起给你 12 小时；对于拒付（chargeback），Google 从发出待处理退款审核通知起给你 24 小时。如果你错过时限，两家平台都会在没有你参与的情况下自行做出决定。
五个字段：客户同意状态、交付状态、以毫分比（milliunits）表示的消耗百分比、是否提供了试用样本，以及你的退款偏好。账户年限、累计消费等旧字段已被取消。
大体相同，如果你有更多细节，Google 还会接受更多信息。Google 接受消耗百分比，以及最多 1,000 条带时间戳的使用事件，其偏好选项为 DECLINE、APPROVE 或 NEUTRAL。
在 Apple 平台上，是的。除非 customerConsented 为 true，否则提交会被拒绝，因此这项授权必须在请求到达之前就写入你的条款中。
不应该。两家商店都只把你的偏好当作其中一项参考，并且都能看到客户的完整历史记录。如果你自己的数据显示交付失败或几乎没有使用，却仍然选择拒绝，就会在真正重要的案例上损害你的可信度。
