一笔退款出现在你的后台，你却完全不清楚原因。客户使用这款应用长达两周，随后钱款被退回，而其访问权限却依然有效。你根本没有发言权。这正是大多数 iOS 团队接触苹果退款流程的方式——事后得知，且毫无来龙去脉。
了解苹果批准或拒绝退款的方式很重要，因为它直接决定了真实收入。苹果掌握最终决定权，但开发者可以为这一决定提供数据支持，而大多数团队却从未这样做。如果你想减少本可避免的损失，可以先阅读我们的 苹果退款指南，然后继续阅读了解这一决定究竟是如何做出的。
这不是一篇教你以消费者身份申请退款的指南，而是关于苹果退款审批机制如何运作，以及开发者一方能够施加哪些影响的说明。
核心要点
• 每一笔 App Store 购买的退款，最终决定权都在苹果，而非开发者。
• 苹果运行一套退款决策系统（Refund Decisioning System），综合权衡交易详情、购买历史和退款历史。
• 对于符合条件的购买，苹果会发送 CONSUMPTION_REQUEST，并给你 12 小时时间回复消费数据。
• 如果你未能及时回应，苹果通常会默认批准退款。
• App Store Server Notifications 会告知你结果：批准时发送 REFUND，拒绝时发送 REFUND_DECLINED。
• 你能掌控的是证据内容和响应速度，但无法掌控最终裁决。
• 清晰的计费说明、正常运行的功能以及快速的客服支持，能从源头上减少退款申请的数量。
用户申请苹果退款时会发生什么？
当客户申请App Store 退款时，申请会提交给苹果，而不是你。客户使用苹果自带的"报告问题"流程，苹果系统随即启动审核。除非购买类型符合开发者可提供输入的条件，否则你并不在这个流程之中。
整个受理过程完全由苹果处理。客户会选择一个原因，比如"并非有意购买"或"应用无法正常使用"。苹果系统会记录该原因，并开始结合其已掌握的账户和交易信息进行核查。
示例。一名用户购买了一个 9.99 美元的金币礼包，玩了一个小时后，以"误购"为由申请退款。苹果会首先收到这一申诉。你是否会得知此事，取决于产品类型以及苹果自身的判断信号。
苹果如何审核退款申请
苹果通过一套自动化系统来审核退款申请，综合权衡交易情况、客户的购买历史以及过往退款记录。苹果已公开将其称为退款决策系统（Refund Decisioning System）。该系统关注的是行为模式，而不仅仅是眼前这一笔申请。
对于消耗型购买项目及其他一些类型的购买，苹果在做出决定前还可能会向你征求意见。该请求会以 CONSUMPTION_REQUEST 通知的形式送达。随后你将有一个较短的时间窗口，用来发送有助于苹果判断该申诉的数据。
退款申请阶段 | 苹果的处理方式 | 开发者可采取的行动 |
客户提交申请 | 记录原因并启动审核 | 暂无动作，未收到任何信号 |
检查购买是否符合条件 | 如适用，则发送 CONSUMPTION_REQUEST | 在你的服务器上接收该通知 |
证据提交窗口期 | 最多等待 12 小时以接收你的数据 | 通过 API 发送消费信息 |
决策 | 权衡历史记录、证据和申请原因 | 无需操作，由苹果决定 |
发送结果 | 发送 REFUND 或 REFUND_DECLINED | 更新权益状态和记录 |
开发者要点 决定权在苹果，但 CONSUMPTION_REQUEST 是你施加影响的唯一机会。一旦错过 12 小时窗口期，你就等于只把客户的一面之词交给了苹果。 |
影响苹果退款审批的因素
苹果退款审批取决于申请时所述的原因、客户的历史记录、购买内容的使用程度，以及开发者是否提供了支持性数据。没有任何单一因素能决定最终结果，苹果会将这些因素综合权衡。
根据苹果自身的指引以及 CONSUMPTION_REQUEST 的设计思路，以下信号至关重要：
• 客户选择的退款原因。
• 账户的购买和退款历史，用于标记频繁申请退款的用户。
• 客户已使用的消耗型内容比例。
• 购买前是否提供了免费试用、试用期或明确的功能展示。
• 开发者在 12 小时窗口期内发送的消费数据。
分析。账户历史这一因素正是为什么首次购买者和惯常申请退款者面对相同的申诉，可能会得到不同结果的原因。这是基于对该系统的专业解读，而非官方明文规定，因此应将其视为一种规律而非保证。
App Store Server Notifications 如何帮助开发者
App Store Server Notifications是苹果向你的服务器发送的，关于购买事件（包括退款）的消息。你正是通过它们才能得知退款是否发生、是否被批准以及原因。如果没有这些通知，退款对你的后端系统来说将是不可见的。
V2 版本的通知更加简洁，因为每条通知只携带该事件对应的交易信息。就退款而言，关键的通知类型包括：苹果需要你提供意见时发送的 CONSUMPTION_REQUEST、退款获批时发送的 REFUND，以及申请被拒绝时发送的 REFUND_DECLINED。REFUND 的负载数据中还会包含 revocationReason 和 revocationDate。
标准退款还可能在 悄无声息地撤销扣款的同时，让访问权限依然保持有效，因此，正是这些通知才使你的服务器能够做出相应处理。
示例。你的服务器收到一条带有 revocationReason 的 REFUND 通知。你读取原始交易 ID，撤销相应权益，并更新记录。如果没有收到通知，上述操作都不会发生。
开发者能控制和不能控制的事项
开发者能够掌控的是响应速度与质量、计费信息的清晰度以及产品体验。开发者无法掌控的是苹果的最终决定、客户所陈述的理由，以及苹果内部的评分机制。明确这一界限，有助于保持合理的预期。
开发者的操作 | 苹果的审核方式 | 最终结果 |
及时发送消费数据 | 结合账户信号综合权衡 | 可能拒绝证据不足的申诉 |
不发送任何数据 | 仅依据自身掌握的信号 | 通常默认批准 |
清晰的试用和计费条款 | 识别出试用内容标记 | 减少"我未授权"类申诉 |
快速的应用内客服支持 | 苹果不会直接看到 | 更少的申请会提交到苹果 |
苹果可能拒绝退款的常见原因
当申诉内容与证据不符、客户存在频繁退款的行为模式，或有力的消费数据表明购买内容已按预期使用时，苹果可能会拒绝退款。对于通过 StoreKit 发起的申请，REFUND_DECLINED 通知即代表这些结果。
在以下情况下，申请更可能被拒绝：
• 客户已消耗掉大部分消耗型购买内容。
• 该账户在多次购买中都存在反复申请退款的记录。
• 开发者提供了明确证据，证明该购买被正常、合理地使用。
• 已提供试用或样品，削弱了"不知情"这一说法的可信度。
示例。一名用户在花掉大部分金币后申请退款。开发者发送了显示消费情况的消费数据。这一证据为苹果拒绝该申请提供了明确依据。
开发者最佳实践
最佳实践很简单：捕获每一个退款信号，用真实数据快速响应 CONSUMPTION_REQUEST，并从源头减少用户申请退款的理由。你无法左右最终决定，但可以塑造输入的信息。
• 配置 App Store Server Notifications V2，并处理 CONSUMPTION_REQUEST、REFUND 和 REFUND_DECLINED。
• 将消费数据响应自动化，确保能在 12 小时窗口期内从容完成。
• 使用 appAccountToken 将购买记录与用户关联，以便能够用真实活动数据作出回应。
• 在结账前清楚说明计费条款和试用细节。
• 在退款获批后主动撤销访问权限，因为苹果不会替你移除权益。
如果你的交易量很大，人工处理注定会落后。那些 将 CONSUMPTION_REQUEST 响应自动化的团队，能够保住那些沉默团队默认拱手让出的收入。
开发者要点 你无法控制苹果的裁决，但你可以决定苹果是否能听到你的一面之词。快速且有据可依的响应，加上清晰的计费说明，才是真正能左右退款结果的关键杠杆。 |
结语
每一笔 App Store 退款都由苹果决定，这一点不会改变。真正能够影响你数字的，是当苹果征求意见时，你的服务器是否能及时响应，以及在任何人申请退款之前，你的产品和计费是否足够清晰、规范。
把退款流程当作一套需要你持续输入的系统，而不是一个只能被动等待的裁决。捕获各类通知，用真实数据回应 CONSUMPTION_REQUEST，并让权益状态保持同步。做到这些的团队，能够默默守住那些其他团队根本未曾察觉已经流失的收入。
常见问题
每一笔退款都由苹果决定，而非开发者。
开发者有 12 小时的时间发送消费数据。
这是苹果针对符合条件的退款申请，要求提供消费数据的一种通知。
苹果会发送 REFUND 或 REFUND_DECLINED 服务器通知。
不能。开发者只能提供消费数据，以协助苹果做出判断。
会。购买内容的使用情况是苹果考量的因素之一。
是的。订阅退款同样由苹果决定，并会发送相应的退款通知。
你的服务器应撤销该客户的访问权限或权益。
