退款请求始于用户的一个操作。而在你这一侧，它会变成一连串事件——你的后端要么处理了，要么错过了。
Apple 可能会向你的服务器索取信息，而这是有时限的。随后，处理结果会以通知的形式送达，你的应用访问状态也需要随之变更。这条链路中只要缺了任何一环，退款照样会发生——只不过你要等到之后才会知道，可能是从结算报告里，也可能是从一位一头雾水的用户那里。
Apple 是否批准退款，不由你决定。这是 Apple 的权限，再多的开发者工具也改变不了。你能决定的，是当请求到来时，你的系统是否已经准备就绪。
本指南涵盖 Apple 退款请求发生前、处理中和结束后你该做的事。如果你想了解更全面的运营视角，我们关于 App Store 退款管理的指南介绍了相关的整体流程。
要点速览
• Apple 做出最终退款决定。开发者无法批准或拒绝退款请求。
• Apple 可能会索取消费信息。在这种情况下，开发者可以在获得用户同意的前提下、在时限内予以响应。
• 退款通知必须送达你的后端，否则这些事件对你而言等于不存在。
• 退款结果应当改变应用状态，而不仅仅是被记录下来。
• 在 Apple 设有响应时限的情况下，时效至关重要。退款请求不会等你上班。
• 自动化的主要作用是防止遗漏：遗漏通知、错过时限、漏更新权益。
用户申请 Apple 退款时会发生什么？
用户通过 Apple 提交请求。Apple 进行评估，期间可能向你索取信息，然后做出决定，并告知你的服务器结果。
步骤 | 发生了什么 | 你这一侧 |
1 | 用户向 Apple 提交退款请求 | 无需操作——但你的端点应处于可用状态 |
2 | Apple 开始评估请求 | 你无法看到这一过程 |
3 | Apple 可能发送 CONSUMPTION_REQUEST | 识别交易和用户 |
4 | 在满足要求的情况下，你予以响应 | 已核对同意状态、准备好数据、按时发送 |
5 | Apple 做出决定 | 无决定权 |
6 | 结果以通知形式送达 | REFUND、REFUND_DECLINED，或之后的 REFUND_REVERSED |
7 | 记录和访问权限需要更新 | 权益状态相应变更 |
第 3 步是有条件的。Apple 只会针对特定购买类型和特定情形发送 consumption request，而不是对每一个退款请求都自动发送。如果你的逻辑假设它一定会到来，就会产生漏洞。
为什么 Apple 退款请求会演变成收入问题
退款金额是看得见的成本，但很少是最大的那一项。一个被退款的订阅周期会冲销你已经计入的收入，通常还会终止其背后的续订流——而这些续订很可能已经写进了预测里。
然后是状态问题。如果结果通知从未送达，用户就会继续享有付费访问权限。你的数据库显示"有效"，Apple 显示"已退款"，在有人投诉之前，没有人会去核对这两者。
围绕这些的还有一些不那么显眼的成本：需要人工核对的结算报告、本不该发生的关于访问权限的客服对话、夜间到达却回复太晚的 App Store 退款请求。而且，如果没有退款历史记录，反复出现的原因就始终无法被发现。
开发者能否左右 Apple 的退款决定？
不能。Apple 做出最终退款决定。开发者能做的是在适用的情况下提供被索取的消费信息，并管理自己这一侧由此产生的应用状态。
明确这一分界，能省去大量无谓的努力。
你能控制的
• 通知是否送达并被你的后端处理
• 交易是否被存储并可在日后查找
• 交易是否能映射到具体的用户账户
• 消费数据是否准确并已提前准备好
• 你是否拥有发送这些数据的有效同意
• 你是否在 Apple 的时限内响应
• 结果出来后，权益、记录和报表是否得到更新
你无法控制的
• Apple 对任何一笔退款的最终决定
• Apple 如何权衡决定背后的各项因素
• Apple 面向用户的退款政策和资格规则
如何响应 Apple 退款请求
共八个步骤。其中大多数发生在任何退款请求出现之前。
1. 确保 App Store Server Notifications 能送达你的后端
退款事件会发送到你配置的服务器端点。如果该端点无法访问、未经验证或在悄无声息地失败，那么从你的角度看，这些事件就消失了。Apple 在 App Store Server Notifications 参考文档中说明了配置方法和签名负载格式。请验证签名、返回成功响应，并在处理之前先记录收到的内容。
2. 识别交易和用户
通知引用的是 Apple 的交易标识符，而不是你的。你需要一份已存储的交易记录用于匹配，还需要一条回溯到用户账户的路径。后者正是 appAccountToken的用途——一个在购买时附加的 UUID。它是可选的，这也是为什么许多团队后来不得不编写匹配启发式规则。
3. 检查 Apple 是否索取了消费信息
CONSUMPTION_REQUEST 通知意味着 Apple 在评估退款请求期间，正在询问用户对该产品的使用情况。它不是退款已发生的通知，也不会针对每一笔退款发送。请将其视为一种独立的事件类型，配备专门的处理程序。
4. 核对同意要求
只有在满足 Apple 的要求时才发送消费数据。Apple 的 Send Consumption Information文档对此说得很直接：在分享用户数据之前，你必须获得用户的有效同意，而获取同意是你的责任，不是 Apple 的。通知本身不携带任何同意信号——你必须从自己的记录中获知。如果用户未曾同意，Apple 的指引是不要响应。
因此，同意是一个应用层面的问题，需要在任何退款请求出现之前就收集好。事后补救是行不通的。
5. 准备准确的消费信息
该负载描述的是这笔购买实际发生了什么，所以请从你自己的记录中提取数值，而不是靠估算。Apple 记录了各字段及其有效取值，包括如何表明你不提供某个特定字段。准确性比措辞更重要：这是提供给 Apple 流程的输入，而不是你在提出论点。
6. 在 Apple 要求的时限内响应
Apple 目前的文档要求在收到通知后 12 小时内响应。请查阅该页面，而不是依赖旧的实现——Apple 已修订过这个端点，目前文档中记录了不止一个版本。12 小时是自动化这一步骤最有力的现实理由，因为请求会在深夜和周末到来。
7. 跟踪最终结果
存储结果。REFUND 表示退款已批准。REFUND_DECLINED 表示未批准。REFUND_REVERSED 表示 Apple 撤销了此前已批准的退款。团队通常会处理前两种，却忘了第三种，结果导致用户失去了本应享有的访问权限。
8. 更新权益和访问状态
你应用的访问状态应与交易状态一致。退款获批时， 在退款后撤销访问权限。退款被撤销时，恢复访问权限。请由服务器端事件驱动这一逻辑，而不是依赖客户端检查，这样即使用户再也不打开应用，状态也能保持正确。
如何处理 Apple 退款，而不损失超出必要的收入
懂得如何处理 Apple 退款，不等于试图阻止每一笔退款。
有些请求是合理的。重复扣费、内容没有解锁、用户以为已取消却仍被续订。这时有用的应对方式是修复根本问题。
其余的则靠规范：准确的交易记录、快速的事件处理、如实的消费数据、一致的权益状态，以及可查询的退款历史。最后一项能揭示反复出现的原因——某个产品的退款率远高于其他产品、某次发布后的退款激增、某个付费墙没有讲清楚会收取什么费用。这些都不能消除退款。它们能减少可避免的损失，并保持应用状态准确，而这才是现实的目标。
想要申请 Apple 退款的用户该怎么办？
用户不会向开发者申请退款。如果你想知道如何为 Apple 购买项目申请退款，或如何为 App Store 内容申请退款，途径是 Apple 自己的流程：登录 reportaproblem.apple.com，选择"申请退款"，选定原因和项目，然后提交。Apple 关于 为 App 或内容申请退款的页面对此有详细说明，并指出请求状态更新通常需要 24 到 48 小时。
这是面向用户的那一半。本文其余内容都是面向开发者的那一半，两者运行在不同的时间线上。
Apple 退款政策与开发者退款管理
这两者常被混为一谈，值得区分开来。Apple 的退款政策管辖用户这一侧：谁可以申请退款、通过什么流程、依据什么条款。Apple 说明退款资格可能因国家或地区而异，以 Apple Media Services 条款与条件为准，并且在当地法律有规定的地方适用消费者保护权利。这些都不是开发者设定的。
开发者退款管理则是分界线你这一侧的一切：接收事件、识别交易、被询问时予以响应、跟踪结果、更新访问权限，以及了解收入影响。Apple 的政策决定用户会经历什么。你的系统决定你的应用会经历什么。
开发者何时应将 Apple 退款处理自动化？
在量小、一个人就能记住全部情况时，人工处理是可行的。
它的失效原因很平常。通知在凌晨 3 点到来。编写退款处理程序的工程师调去了别的团队。交易 ID 存在一个系统里，账户存在另一个系统里。响应时限在有人读到通知之前就已过期，财务在季末结账时才发现缺口。
自动化覆盖的是确定性的部分：接收并验证通知、将交易匹配到用户、跟踪时限、更新权益、保留可搜索的历史记录。它不会影响 Apple 的决定，任何暗示可以做到这一点的工具都是在歪曲这一流程。
App Store 退款管理软件究竟应该做什么？
App Store 退款管理软件应当补上人工处理留下的那些具体漏洞。
它应该监控并验证通知，让事件不会消失在一个失效的端点里。它应该区分退款事件类型，因为 consumption request 和退款结果需要不同的处理方式。它应该将交易映射到账户，因为这一查找正是人工工作最集中的地方。它应该跟踪响应时限，因为那正是人们容易错过的截止期限。围绕这些还有：包含同意状态的消费信息工作流支持、可搜索的退款历史、权益同步，以及清晰到足以呈现规律的报表。
价值不在于功能数量，而在于这些步骤没有一个依赖于有人记得去检查。
这些规则的文档出处
上文所有关于 Apple 的具体说法均来自 Apple 自己的文档。在构建之前请直接阅读这些文档，并定期复查，因为退款相关的 API 已经变更过不止一次。
Send Consumption Information——同意要求、响应时限和请求字段。第 4 到第 6 步的权威来源。
App Store Server Notifications——端点配置、签名负载格式和通知类型，包括 CONSUMPTION_REQUEST、REFUND、REFUND_DECLINED 和 REFUND_REVERSED。
为 App 或内容申请退款——Apple 面向用户的流程，以及退款资格因国家或地区而异的说明。
结语
Apple 的退款结果不由你决定。你决定的是自己的系统对这些结果反应得有多快、有多准确。
这归结为几件事：能送达的通知、能识别的交易、Apple 索取时发送的准确信息、被记录的结果、与现实一致的权益状态，以及足以看清收入影响的可见性。
如果本周只想检查一件事，就检查端点。确认你的 App Store Server Notifications URL 处于可用状态、已通过验证，并且记录了收到的内容。本文的其他一切都依赖于这一环节正常运作。
如果退款活动已超出人工跟踪的能力
一旦退款事件频繁到无法人工盯着，专门的系统就可以监控这些事件、管理响应工作流、跟踪结果，并减少重复性的运营工作。 RefundSensor负责的正是流程的这一侧——开发者这一侧，而不是 Apple 那一侧。
常见问题
不可以。最终退款决定由 Apple 做出。开发者只能在 Apple 索取时提供消费信息。
确保通知能送达你的后端，识别对应交易，核对用户同意状态，在被索取时提供准确的消费数据，并在你的系统中更新退款结果。
这是 Apple 在退款审核期间发送的一种通知，用于询问用户对某笔购买的使用情况。它并不意味着退款已获批准。
Apple 目前的文档规定响应时限为 12 小时。自动化处理有助于避免错过截止时间。
不能。开发者无法阻止或推翻 Apple 的退款决定。消费信息只是 Apple 可能参考的一项输入。
退款获批时，撤销相关权益。如果 Apple 之后撤销了该退款，则恢复权益。
用户通过 reportaproblem.apple.com 直接向 Apple 申请退款。开发者不处理用户的退款请求。
可以。通知接收、交易匹配、时限跟踪、权益更新和退款记录都可以自动化，以减少人工工作。
