App Store 退款管理：如何减少退款带来的收入损失

是否批准退款由 Apple 决定。而这笔退款最终让你付出多大代价，则由你的系统决定。

RefundSensor · 开发者指南 · 已依据 Apple 官方文档核实

大多数退款问题并不是从财务环节开始的。财务只是它们被发现的地方。

等到退款出现在结算报告里时，这笔购买早已被撤销。客户可能仍然拥有访问权限。Apple 索要信息时没有人回应，因为没有人在盯着接收请求的那台服务器。团队里也没有人能说清这位客户当初为什么要申请退款。

面向开发者的 App Store 退款管理，重点并不在于阻止退款。你阻止不了，这由 Apple 说了算。

你能决定的是：你的服务器能否及时收到退款请求；Apple 索要信息时，你能否提供准确的数据；退款之后应用访问权限是否与实际情况一致；以及你能否看清足够多的规律，从而解决根源问题。可避免的损失就藏在这些环节里。如果你想先了解整体的运营全貌，我们的 App Store 退款管理指南完整介绍了端到端的工作流程。

要点速览

• 退款的最终决定权在 Apple。开发者无法批准或拒绝 App Store 退款。

• 当 Apple 索要消费信息时，开发者可以在获得客户同意的前提下，在 Apple 规定的响应时限内作出回应。

• 退款事件必须能到达你的后端。如果通知没有在服务器端处理，你只能通过报告或客服工单才得知。

• 退款的影响不止于退款金额。访问权限、订阅收入、预测数据和客服负担都会随之变化。

• 在退款事件到达时实时监控，胜过月底再做对账。

• 自动化主要减少两件事：错过响应时限，以及重复的人工查询。

为什么 App Store 退款会成为开发者的收入难题

退款金额只是成本中最小的一部分。

一次性购买被退款，意味着你已经计入的收入被撤销。订阅周期被退款也是如此，而且通常还会终止订阅关系，未来的续订也随之消失。而这些续订很可能已经写进了你的预测。

然后是状态问题。如果退款事件从未到达你的后端，客户就会继续保留他们付费购买的一切。高级功能依然解锁，金币依然留在余额里。你的数据库说这是付费客户，Apple 说已经退款，在有人发现之前，这两种说法会一直同时成立。

App Store 退款造成的收入损失，还会出现在一些看起来不像收入的地方。每个月有人要花一整天把结算报告和内部记录逐条对上。客服要回答本不该出现的访问权限问题。群组分析和回本周期的数字会漂移，因为它们建立在毛收入之上。而没有退款历史记录，就没人能判断是不是同一个产品、同一个价位或同一个获客渠道在持续产生退款。

这些都算不上惊天动地。它们只是在不断累积。

在 Apple 退款过程中，开发者究竟能控制什么？

开发者无法控制 Apple 的退款决定。Apple 会评估每一个退款请求并决定结果。开发者能控制的是流程中属于自己的那一半：接收请求、在 Apple 索要时提供准确信息，以及在事后保持自身系统的正确性。

这个区别很重要，因为很多精力都花在了试图影响错误的那一半上。

你能控制的

• App Store Server Notifications 是否已配置并真正得到处理

• 交易是否已存储，并且之后能够识别

• 交易能否映射回某个具体的用户账户

• 消费数据是否已准备好并且准确

• 你是否已获得客户的有效同意来共享这些数据

• 你是否在 Apple 的时限内作出回应

• 退款事件发生后权益是否会更新

• 退款历史是否得到保存和审查

你无法控制的

Apple 对退款的最终决定。Apple 会权衡多种因素，消费信息只是这一过程中的一项输入——既不是否决权，也不能保证任何特定结果。

App Store 退款流程是如何运作的

客户可以通过 Apple 支持、通过 Apple 的退款申请流程，或者在你已实现 StoreKit 退款请求 API 的情况下直接在你的应用内申请退款。无论他们走哪条路，你这一侧的流程都是一样的。

关于这张表，有几点值得说清楚。CONSUMPTION_REQUEST 是一个索要信息的请求，而不是退款已经发生的通知。REFUND 表示退款已被批准。REFUND_DECLINED 表示未获批准。而 REFUND_REVERSED 是团队最容易忘记的一种：Apple 可以撤销先前已批准的退款，如果你因为那次退款而收回了内容，就应该把它还回去。

把这四种当作同一个事件来处理，是导致状态错误的常见原因。

如何减少 App Store 退款损失

下面这些步骤都无法阻止退款。它们的作用是减少可避免的损失、提高可见性，并保持应用状态准确。这才是现实的目标。

1. 跟踪每一笔交易

在购买发生的那一刻，就存储 Apple 提供给你的交易标识符，包括原始交易 ID。退款通知到达时会引用这些标识符。如果你查不到某一笔，就无法对它采取行动，更别提三周后回答关于它的客服问题了。

2. 将购买与用户关联

Apple 的交易标识符不是你的用户 ID。弥合这一鸿沟正是 appAccountToken 的用途所在——它是一个在购买时附加的 UUID，可以把交易关联回你系统中的账户。它是可选的，很多团队跳过了它，之后却要花费大量工程时间去编写模糊匹配逻辑。尽早设置好。

3. 配置 App Store Server Notifications

退款事件会发送到你配置的服务器端点。如果这个端点不存在、未经验证或者静默失败，那么从你的角度看，这些事件就直接消失了。Apple 在 App Store Server Notifications 参考文档中记录了设置方法和完整的通知载荷。正确处理签名载荷、进行验证，并返回成功响应，这样 Apple 才会停止重试。

4. 在 Apple 索要消费信息时作出回应

当客户发起退款请求时，Apple 可能会发送 CONSUMPTION_REQUEST 通知，询问该客户对产品的使用情况。Apple 的 Send Consumption Information 文档列出了两个让团队栽跟头的条件。

第一是同意。在向 Apple 共享客户数据之前，你必须获得客户的有效同意，而且 Apple 明确指出，获取同意是你的责任，而不是 Apple 的。通知本身不会告诉你是否已获得同意——你必须从自己的应用中掌握这一点。如果客户没有同意，Apple 的指导是不要回应。

第二是时效。Apple 要求在通知发出后 12 小时内作出回应。退款请求可不管什么工作时间，这正是这一步不适合由人工流程处理的原因。

Apple 还修订过这个端点，所以请核实哪个版本适用于你的集成，而不是想当然地认为旧的实现仍然有效。

5. 在退款事件后更新权益

已退款的客户不应无限期地保留付费访问权限。把退款通知当作状态变更而不是报告来处理，正是 退款后撤销访问权限的全部意义所在。同时也要构建反向路径——退款被撤销时，应该恢复你收回的东西，而靠人工来做这件事，正是客服工单产生的方式。

6. 保留退款历史

单笔退款几乎说明不了什么。但几百笔退款，连同产品、价格、日期和原因一起存下来，就能告诉你某个 SKU 的退款率是其他 SKU 的好几倍，或者退款在某个特定版本发布后的一周内激增。这是产品层面的发现，而只有保留了数据，你才能得到它。

开发者如何在不逐笔争辩的情况下减少 Apple 退款损失

好的退款管理，不是每次都要努力赢下的一场争论。

有些退款请求是合理的。一笔付款被扣了两次，内容没有解锁，或者有人以为已经取消了订阅但它又自动续订了。这些客户遇到的是真实的问题，有用的回应是解决问题，而不是给 Apple 发送一份精心措辞的消费信息载荷。

另一些请求涉及的产品已被完全消费。在这种情况下，提供准确的消费信息是合适的。注意这个词：准确。你发送的数据描述的是实际发生的情况。对数据加以粉饰不是策略，而是风险。

更持久的工作在上游。如果退款集中在某个付费墙上，那么这个付费墙很可能没有说清楚收费内容。如果退款集中在某次更新之后，那就是有什么东西坏了。如果某个消耗型礼包持续产生退款，那么这个价位的价值可能没有打动用户。退款数据会指向这些问题，但只有把它们当作一个整体而不是逐张工单去看的团队才能发现。

为什么人工管理 App Store 退款会失灵

在退款量低的时候，人工方式没有问题。有人查看一下 dashboard，更新一条记录，然后继续干别的。

它失灵的原因都很平淡。通知在凌晨 3 点到达。懂退款处理程序的那位工程师换了团队。交易 ID 在一个系统里，用户账户在另一个系统里。电子表格已经三周没更新了。财务在季度结账时才发现差距，而那时早已来不及做任何补救。而 12 小时的响应时限，也不是人工流程能够稳定达成的。

失败的原因不是粗心。而是这项工作随着收入一起增长，却没有任何人的职责随之增长。

App Store 退款管理软件到底应该做什么

当退款量高到需要有人手动盯着通知时，就值得考虑 App Store 退款管理软件了。一款有用的工具应该能够：

• 接收并验证 App Store Server Notifications

• 识别与退款相关的事件类型，并区别处理

• 将交易关联到用户账户

• 跟踪响应截止时间，避免错过时限

• 支持消费信息工作流，包括同意状态

• 维护可搜索的退款历史

• 帮助权益与退款结果保持同步

• 清晰展示退款活动，便于发现规律

它不应该声称的是能够影响 Apple。没有任何工具能控制退款决定。目标更窄，也更诚实：确保流程中属于你的那一部分不被遗漏。

这些规则的文档出处

本文中每一条与 Apple 相关的说法都来自 Apple 的官方文档。如果你正在构建或审查退款工作流，请直接阅读这些文档，并定期重读——退款相关的 API 已经不止一次发生变化。

Send Consumption Information —— 介绍什么是消费信息、同意要求、响应时限，以及这些数据如何影响 Apple 的退款决定。

App Store Server Notifications —— 介绍通知设置、签名载荷格式，以及包括 CONSUMPTION_REQUEST、REFUND、REFUND_DECLINED 和 REFUND_REVERSED 在内的通知类型。

为 App 或内容申请退款 —— Apple 面向客户的流程。有助于了解你的客户实际看到的内容以及请求从何而来。

结语

Apple 是否批准退款，不由你决定。这一点已经定了。

你能决定的是围绕它的一切：你的服务器是否准备好接收请求，你能否识别交易背后的客户，Apple 索要信息时你能否准确、及时地回应，事后访问权限是否反映实际情况，以及你是否足够了解收入影响并据此采取行动。

退款是在 App Store 上销售的永久性成本。可避免的部分，是请求到达之后发生的事情。

如果退款量已经超出人工跟踪的能力

一旦退款活动难以靠人工盯守，一套专门的工作流就可以处理通知、响应时限、退款记录和权益更新，而无需有人整天监控这个过程。 RefundSensor 正是为这部分工作而构建的——让退款流程中开发者这一侧保持可见、保持一致。