当开发者打开App Store的收款结算，发现金额比销售Dashboard承诺的少了几个百分点时，会有一种特别的寂静感。没有人发邮件通知，也没有出现任何故障，Apple只是代你退了一些钱，然后就这么过去了。
这个差距比大多数人想象的要大，我们在 App Store退款与收入流失一文中探讨了它如何变成实实在在的金钱损失。本文则是更偏实操的版本：Apple退款请求如何在系统中流转、收入去了哪里，以及开发者实际能做些什么——比你想象的要多，也比供应商宣传的要少。
核心要点
每一笔App Store退款都由Apple决定。你没有否决权，但自2021年起，Apple会征询你的意见，你大约有12小时的时间来回应。
书面的App Store退款政策篇幅很短。真正起作用的是Apple的判定系统，它会权衡客户的历史记录以及你所提交的信息。
退款会撤销整笔交易，如果你不撤销访问权限，客户还会继续保留内容。
退款滥用只占请求中的少数，但它多集中在消耗型商品和重复出现的账户上，而这正是你可以应对的部分。
Dipsea仅仅通过开始回应Apple的请求，就将其退款率削减了约三分之一。
Apple退款流程的实际运作方式
客户不会直接找你。他们会前往reportaproblem.apple.com，选择“Request a refund”，选定原因后提交。 Apple的支持页面告知他们需等待24到48小时，并注明退款资格“可能因国家或地区而异”——这是Apple承认，像欧盟和澳大利亚这样的地区，消费者法在条款之外还赋予了人们额外的权利。条款本身声明交易是终局性的，但实际上仍有大量退款照样发生。
在这48小时中的某个时刻，如果你已设置了App Store Server Notifications，Apple会向你的服务器发送一个CONSUMPTION_REQUEST，询问客户是否使用了所购买的内容。你有12小时的时间来响应。Apple的工程师在一场 关于处理退款的Tech Talk中表示，判定系统会结合你提交的信息，查看“客户的购买和退款历史”，随后你会收到REFUND或REFUND_DECLINED通知。我们的 CONSUMPTION_REQUEST详解一文提供了逐字段的说明。
有两点常常令人意外。Apple从不会告诉你客户是谁，只会给你一个交易ID。而如果你没有在12小时内做出回应，Apple就会在你这一方信息空白的情况下自行判定——RevenueCat的一篇文章将此总结为Apple“通常会默认批准退款”。
Apple退款请求如何影响应用收入
直接成本很简单：Apple撤销交易，你的分成会从下一次结算中扣除。以4%的退款率计算，一款每月净收入$50,000的应用，要退回约$2,000——而这还是在没有人核实这些退款是否合理的前提下。
真正累积起来的是间接成本。金币被花掉之后才被退款的消耗型商品，意味着你交付了商品却分文未得。订阅被退款却没有处理REFUND通知，意味着客户在剩余周期内仍可继续使用，相当于你付出了双重代价。在Refund Sensor平台上的各应用中，平均每个案例价值$33.31——听起来不多，但乘以2,870个案例，就接近十万美元了。这大致就是身处其中的真实感受：大量无人认领的小额损失。
App Store退款滥用出现在哪里
大多数退款请求都很正常：孩子买了宝石、有人忘记取消试用、应用在旧款iPad上崩溃。把这些当作客户服务问题来处理，因为Apple就是这么做的。
滥用行为只占一小部分，但有着可识别的模式：消耗型商品在一天之内被购买、使用并申请退款；同一账户在多个应用中反复如此操作；订阅每月都在周期最后一天被退款。Apple对此的了解远超任何开发者。其 2026年欺诈报告显示，Apple在2025年阻止了$2.2 billion的潜在欺诈交易，并因欺诈和滥用行为关闭了40.4 million个客户账户。退款滥用是其中较小的一部分，也是会渗透到你身上的那部分。
你能做的事情比人们期望的要有限。你无法阻止客户提出申请。你可以告诉Apple金币已经被消费——这正是消费请求的作用所在——你还可以确保退款一旦获批，就真正撤销相应内容，因为如果滥用者保留了宝石，他们还会再来一次。相当多的应用从未做好这一环。
开发者在这12小时内能做什么
大部分工作其实就是回应。Dipsea是一款订阅制音频应用，在2024年底开始回应消费请求，大约两周内退款率就从3%降到了1.9%。他们没有要求Apple拒绝任何请求，只是不再把表单留空而已。
在观察大量应用的过程中，有几点值得注意。购买时要附加appAccountToken，否则你将无法把Apple所指的交易与你数据库中的用户关联起来。在条款中加入关于共享使用数据的同意条款，因为Apple要求未获同意不得发送任何数据。如实发送退款偏好，因为Apple将其视为一种“偏好”，遇到明显的敷衍推诿会予以推翻。同时为每一个请求记录时间戳，因为你错过的那些请求，往往是在周六凌晨3点到达的。
再往上游看一看。Apple自身的原因列表中包括UNINTENDED_PURCHASE和UNSATISFIED_WITH_PURCHASE，这两者在成为退款问题之前，首先是产品问题。在试用转化前一天发送提醒、让付费墙上的价格与权益展示同等大小、在儿童游戏的消耗型商品购买中加入确认步骤——这些举措都能在请求产生之前就将其消除，这比事后争取胜利更有效。
App Store退款管理软件，以及你是否需要它
你完全可以自己搭建这套系统：一个用于接收通知的端点、一个从交易ID查找用户的功能、一个向Apple消费端点发起的PUT请求，以及一个在任何请求停滞超过8小时时会发出警报的任务。一位称职的后端开发者一周内就能完成，但之后要永久维护它——这才是真正的成本所在。
如果你已经在使用RevenueCat或Adapty，这两者都会利用其SDK所收集的使用数据来回应消费请求，如果你的应用中原本就已集成了这些SDK，这是一个合理的默认选择。
Refund Sensor是一个独立的选项。它通过一个App Store Connect API密钥和一个通知URL即可接入，无需SDK，并可在同一处覆盖Apple和Google两端。在800多款应用中，它已成功抵御了77%的合格请求。定价为固定收费，有免费套餐，之后是每月$39.99或$79.99，不会从挽回的金额中抽成。具体设置细节请参见 Apple退款防御页面。
有一点需要提醒，这适用于所有这类工具，包括我们自己的产品在内：被宣传为App Store收入保护软件的产品，并不能阻止退款发生，也不能让Apple按你的意愿做决定。它能做到的是，确保Apple每一次都能在窗口期内收到你提交的准确数据。事实证明，这一点极具价值，而这也正是这类工具的全部作用所在。
结语
Apple退款请求不会消失，你也没有否决权。2021年发生变化的是，Apple开始征询开发者的意见，而如今大多数开发者依然没有回应。Apple退款流程依据的是12小时内送达Apple的一切信息，空白的表单在客户的陈述面前注定处于下风。
所以，按照这个顺序来保护你的收入：回应请求，在退款发生时撤销权限，让滥用行为无利可图，然后再去修复那些最初就催生了这些请求的付费墙和试用流程。至于回应机制是你自己搭建、借助订阅平台，还是交给专门工具来完成，这都不如“确实去做”这件事本身重要。
常见问题
不可以。决定权在Apple。你可以在12小时内发送消费数据和退款偏好，Apple会将其纳入考量，但Apple可以且确实会推翻开发者的意见。
Apple告知客户需等待24到48小时。而你的响应窗口是从收到CONSUMPTION_REQUEST起的12小时内，该请求通常在这段时间的早期就会到达。
几乎不会。REFUND通知中包含一个revocationReason字段，取值仅为“app issue”（应用问题）或“other”（其他）。而请求本身携带客户所选择的原因，这一信息更有参考价值。
故意购买、消费后再申请退款，通常涉及消耗型商品，且常常在多个应用中重复出现。Apple的判定机制已经会考量退款历史，因此你的任务是确认消费情况，并在退款生效时撤销访问权限。
只有当你无法在12小时内可靠地手动回应消费请求时才需要。如果每周请求量只有几个，用清单流程可能就够了。超过这个量，就应该实现自动化，无论是自己编写代码、使用订阅管理平台，还是借助专门的工具。
