App Store 退款政策详解：移动应用开发者须知

是否批准退款由 Apple 决定。政策留给你的，是围绕这个决定发生的所有事情，而大部分本可避免的损失正出在这里。

这样的故事我们听过很多版本。用户在 3 月向 Apple 申请退款，Apple 批准了，但开发者的服务器从未得知此事。到了 6 月，这位用户仍在使用应用的付费版本。直到季度末财务做核对时才有人察觉，而即便到那时，也要花上一阵子才能弄清发生了什么。退款记录躺在结算报告里，访问权限记录躺在应用自己的数据库里，两者从未互通。

大多数开发者就是这样了解 App Store 退款政策的：不是通过阅读政策本身，而是在几个月后才发现政策从未覆盖的那部分内容。

政策里没有明说的是这一点：Apple 撤销一笔付款，和你的应用收回访问权限，是两件不同的事。前者由 Apple 负责，后者由你负责。这两者之间的空隙，正是开发者月复一月悄然损失收入的地方。本文的大部分内容，都是关于如何弥合这个空隙。

因此，本文将从开发者的角度审视这项政策：Apple 掌控什么，哪些落在你身上，以及退款通过后你的系统需要做些什么。如果你更想看实操而非政策本身，我们的指南 如何在不损失移动应用收入的前提下管理 App Store 退款正好涵盖了这部分内容。

要点速览

● 每一项退款决定都由 Apple 做出。App Store Connect 里没有批准或拒绝退款的按钮，因为这个选择从来就不属于开发者。

● 客户所在地可能改变结果。根据 Apple 的 媒体服务条款与条件，退款资格和流程因国家或地区而异。

● Apple 可以向你的服务器发送与退款相关的通知，并可能在审核请求期间要求你提供购买内容的使用情况信息。

● 你有 12 小时的回复时间，而且只有在客户已授权共享这些信息的情况下才可回复。

● Apple 批准的退款和你数据库记录的退款是两个独立的事件。两者之间的空隙，就是资金流失的地方。

● 自动化可以让你这一侧的流程更快、更一致，但对 Apple 的决定没有任何影响。

什么是 App Store 退款政策？

简而言之，它是一套规定 Apple 如何处理客户退款请求的规则，外加一份落到开发者头上的技术任务清单。

是否批准退款由 Apple 决定，你没有发言权。你不能批准请求，也不能阻止请求。App Store Connect 没有任何界面让开发者对此投票。你最多能做的，是在流程中的几个节点向 Apple 提供一些信息，这一点我们稍后会讲到。如果你想了解客户实际上是如何提交请求的，Apple 的 为 App 或内容申请退款指南有详细说明。

我们通常把这项政策拆成四个部分讲给团队听，因为其中只有两个部分真正是你的问题。

第一部分是退款资格。请求直接发给 Apple，从不经过你。资格可能因客户所在的国家或地区而不同，相关规则载于 Apple 媒体服务条款与条件。所以，如果有用户问为什么自己的退款通过了而朋友的没有，这没有简单的答案，取决于他们各自身处何地。

第二部分是决定本身。这完全由 Apple 说了算，你只有在决定做出之后才会知道。

第三部分是你的责任，这些责任是技术性的，而非法律性的，几乎每次都让人措手不及。运行一台能接收通知的服务器；在 Apple 要求时提供信息；保持记录清晰。这就是全部工作。

第四部分是决定之后权益（entitlement）会发生什么，这才是真正花钱的环节。Apple 撤销一笔付款，本身不会改变你数据库里的任何内容。客户拿到退款却永久保留付费访问权限，这不是 Apple 政策的失败，而是你的系统构建方式存在漏洞。

你大概能猜到我们最看重哪一部分。

对开发者而言，Apple App Store 退款流程是如何运作的？

客户发起，Apple 收尾，你处在中间某个位置。

客户通过 Apple 申请退款

↓

Apple 审核请求

↓

你的服务器可能会收到与退款相关的通知

↓

如适用，你提供支持信息

↓

Apple 做出决定

↓

你以通知的形式收到结果

↓

权益和访问权限得到更新

这里有两点值得注意。Apple 告诉客户大约 24 到 48 小时内会得到答复，而这个时间线与你的毫无关系，所以在请求待处理期间，你的支持团队在做出承诺时要谨慎。另外，上述每一步都只有在你的服务器真正配置好且可访问的情况下才有效。不少团队发现自己的服务器并非如此。如果你的端点宕机了，退款照样会发生，只是你永远不会知道。

App Store 退款规则对开发者意味着什么？

剥去政策措辞，这些规则就变成了一份给工程团队的简短、不太起眼的清单。

● 真正可以检索的交易记录。退款通知引用的是 Apple 的交易标识符。如果你在购买时没有保存这些标识符，通知几乎毫无用处。你还需要在每笔交易和用户账户之间建立可靠的关联，因为 Apple 的 payload 标识的是购买行为，而不是购买者。

● 一个正常工作且会校验签名的通知端点。退款事件通过 App Store Server Notifications送达，payload 是带签名的。每次都要校验这些签名。一个对任何发来的内容都照单全收的端点，就是一个附带 URL 的安全隐患。

● 提前搭建好的授权同意流程。如果 Apple 索要消费信息，你只能在客户已同意共享这些数据的情况下回复。这项责任在你。Apple 的 Send Consumption Information 文档对此说得很直接，任何未经同意发送的回复都会被拒绝。你也不能在请求已经到达之后再回头收集同意。要么在购买时就已获得同意，要么这一单你只能放弃。

● 双向可用的权益逻辑。退款有时会被撤销。Apple 也允许部分退款，即只退还购买金额的一部分。全额、部分或撤销，你的代码需要处理这三种情况。

● 一个财务真正能用的结果落地之处。只存在于应用数据库里的退款，永远无法与结算报告对上。大多数团队是在季度结账时发现这一点的，那一天通常不好过。

Apple 退款政策如何影响开发者？

所有人都盯着退款金额，但它通常是整个故事里最小的数字。

被退款的订阅周期会收回你已经计入的收入，而且在大多数情况下，客户关系也到此为止。你原本期待的续订悄无声息地不再出现。一次性购买相对简单，但退款同样发生在销售之后，所以任何基于毛收入的报表在扣除退款之前都会虚高。

整篇文章里最值得记住的区别在这里：Apple 批准的退款和你的系统实际记录的退款，是两个独立的事件。Apple 那一半按它自己的节奏发生，无论有没有人在看。而你这一半只有在通知处理程序触发、交易匹配成功、账户找到、访问权限更新之后才算完成。这个链条中任何一环缺失，工作就只做了一半，而从外部看，没人能分辨是哪一半。

这个空隙有个名字：退款漏损（refund leakage）。这些客户拿回了钱，同时保留了他们付费购买的一切。他们不会上报，因为在他们看来一切正常。这个问题要到几个月后做对账时才会浮现，如果它真会浮现的话。

其他一切问题都源于同一个空隙。支持人员处理工单时没有退款记录可查。分析数据高估了客户生命周期价值，因为退款撤销从未进入统计。没有可回溯的退款历史，所以当某个产品的退款量远高于其他产品时，没有人会注意到。

收到 Apple 退款请求时，开发者应该做什么？

七个步骤。大部分工作在任何请求出现之前就已经完成了。

1. 接收并校验通知

退款事件以带签名的 JWS payload 形式到达你的端点。用 Apple 的证书链校验签名，确认 bundle ID，然后才根据内容采取行动。这是基本功，但仍有团队跳过。一个来者不拒的端点，就是别人可以利用的端点。

2. 找到交易和账户

从 payload 中提取交易标识符，与你的购买记录进行匹配。如果你在购买时附加了稳定的账户令牌，这只需一次查询。如果没有，你就是在时间压力下靠猜。

3. 核查你对这笔购买已有的了解

在弄清自己的系统记录了什么之前，你无法向 Apple 提供任何有用的信息。内容交付了吗？是否按预期正常运行？客户实际使用了多少？如果你无法从自己的记录中回答这些问题，那才是你的第一个真正的问题，而不是退款本身。

4. 在 Apple 要求且已获同意时发送消费信息

收到 Apple 的 CONSUMPTION_REQUEST 通知，意味着你可以回复有关购买内容使用情况的信息，但前提是两个条件同时成立：客户已给出有效同意，且你仍处于 Apple 设定的 12 小时窗口内。Apple 当前的文档将这种通知与所有产品类型的退款请求关联在一起，因此在构建处理程序时，不要假设它一定会出现。无论你发送什么，都应直接来自你的记录，而不是粗略的猜测。

5. 跟踪最终结果

结果以通知形式到达。REFUND 表示退款已批准，REFUND_DECLINED 表示未批准，REFUND_REVERSED 表示 Apple 撤销了此前已批准的退款。三种结果都要保存。撤销这种情况是团队最常遗漏的，漏掉一次撤销，可能会把一位付费客户挡在他们合法拥有的内容之外。

6. 更新权益和访问权限

退款批准时收回访问权限，退款撤销时恢复访问权限，并处理只退还一定比例的部分退款情况。这些操作要基于服务端事件来执行，这样无论客户是否再次打开应用，其访问权限都能保持正确。

7. 与收入和订阅报表对账

将退款匹配到正确的周期和正确的产品。跳过这一步，财务和工程最终看到的将是同一个月的两个不同版本。凡是参加过那种会议的人都知道，这值得避免。

为什么手动管理 App Store 退款会变得困难

这与粗心无关。只是这些约束条件，天生不适合一个依赖有人全天候保持清醒并时刻留意的流程。

退款请求在客户提交的任何时候都会出现。周日早上、凌晨两点、节假日。回复窗口不会为任何人的日程暂停。每个请求都需要查询交易、匹配账户、检查授权同意、获取使用数据、更新权益。顺利的话，这大约是五分钟的工作。但它有时效性、重复性，而且做对了完全没人看得见。没有人会因为凌晨四点正确处理了一笔退款而被感谢。

请求量越大越难。同时运营多个应用也是如此，交易数据在一个系统里，账户数据在另一个系统里。然后，理解处理程序的那位工程师换了团队。跟踪用的电子表格被命名为 refunds_OLD_final_v2 之类的名字，然后悄然无人再打开。财务在季度结账时发现了这个空隙，此时距离还能采取补救措施的时间点已经过去了大约三个月。

开发者如何更可靠地管理 App Store 退款？

手动监控大致是这样的：有人打开 dashboard，查一笔交易，更新一条记录，然后继续。在低量时这很好用，而这正是陷阱所在，因为它不会轰然崩溃，而是慢慢失效。没有哪个明确的时刻它停止了工作，所以没有人能及时发现。

自动化把机械性的步骤从人手中接过：接收并验证通知、将交易匹配到账户、整理回复数据、跟踪回复窗口、记录结果、保持权益同步。

它做不到的是改变 Apple 的想法。自动化不会降低退款的可能性，也无法影响决定，无论某些工具怎么暗示。它改变的只是你这一侧的流程能否持续、按时地完成，而这本身就是一个值得解决的实质问题。

这类工作归属于 App Store 退款管理这个类别，值得直说这个领域的工具应该覆盖哪些内容：通知处理、将交易匹配到用户、遵守授权同意和时限的回复工作流、日后可查的退款历史，以及能处理全额、部分和撤销退款的权益更新。

RefundSensor 负责的正是这部分工作。它将 App Store 和 Google Play 的退款事件接入自动化工作流，让回复在商店窗口期内发出，无需任何人手动盯着通知，退款记录也能随着量的增长保持准确。它不会改变 Apple 的决定，因为没有什么能改变。它改变的是每笔退款之后留给你团队的工作量。

这些规则的文档出处

上述所有内容背后是三份 Apple 资料。在构建任何东西之前请亲自阅读，并不时回头查看，因为这个领域已经变动过不止一次。

为 App 或内容申请退款 — 客户看到的政策。涵盖请求如何提交、24 到 48 小时的更新窗口，以及 Apple 关于地区资格的说明。

Send Consumption Information — 面向开发者的回复工作流。涵盖授权同意要求、12 小时窗口和请求字段。在动手处理消费信息之前，值得通读全文。

App Store Server Notifications — 退款事件如何到达你的后端。涵盖签名 payload 格式和通知类型，包括 CONSUMPTION_REQUEST、REFUND、REFUND_DECLINED 和 REFUND_REVERSED。

如果退款事件仍在靠人工检查

手动监控一直好用，直到它不再好用，而且失效通常是无声的。一条没人看到的通知。一个在凌晨三点关闭的窗口。一位保留访问权限整整一个季度的已退款客户。

如果这听起来很熟悉，RefundSensor 可以让退款工作流脱离手动跟踪：商店事件、回复窗口，以及确保结果同时进入你的记录和权益逻辑。