我的一位客户是偶然发现这个漏洞的。他自己的数据库显示 2 月收入为 $11,400，而 App Store Connect 里的财务报告显示 $10,650。没有任何崩溃，没有触发任何告警。大约 $750 就这样一笔退款接一笔退款地悄悄流走了，而他大概在五周之后才察觉。
每一笔 App Store 退款都由 Apple 裁定。这个决策桌上没有你的位置。你能得到的，只是一个狭窄的窗口，可以把证据摆到他们面前，而且这个窗口只有在你的服务器真正在监听时才会打开。大多数面向开发者讲解 Apple App Store 退款的文章都对这一点一笔带过，这很可惜，因为这是你唯一能掌控的环节。关于这个窗口本身的详细拆解在这里： Apple 的 CONSUMPTION_REQUEST 如何决定你的退款结果。
核心要点
Apple 说了算。你无法发起退款、无法阻止退款，甚至看不到客户的名字。
你唯一的输入是对 CONSUMPTION_REQUEST 的回复，而且必须在大约 12 小时内送达。
App Store 退款造成的收入损失是层层叠加的，退款本身只是第一层。
RevenueCat 的数据显示，订阅退款率的中位数在 3% 到 5% 之间，异常值可达 9% 到 18%。
最枯燥的解决方案也是最便宜的：监听通知、自动回复、在钱退回去时切断访问权限。
从你这一侧看，App Store 退款是什么样子
有人打开 reportaproblem.apple.com，登录，从过去 90 天的购买记录里挑一笔，选一个理由，点击提交。Apple 审阅，Apple 裁决。
除非你主动要求接收信息，否则你什么都听不到。App Store Connect 里没有退款按钮，没有待处理请求队列，也没有可以回信的客户邮箱地址。如果你开启了 App Store Server Notifications V2，那么在请求提交的那一刻，一条 CONSUMPTION_REQUEST 就会送达你的端点，附带交易信息、产品信息以及客户所选的理由。从那一刻起，你有大约 12 小时的时间调用 Send Consumption Information 端点，提交五个字段：用户是否同意、购买内容是否已交付、是否提供过试用样品、用户使用了多少，以及你希望的处理结果。
用真实的使用数据回复，站不住脚的申请就常常会被驳回。什么都不回复，Apple 就会采信客户的说法，再参考其账户历史来判断。在这里，沉默也算一种回答，而且是大多数团队给出的那种。
当退款真的通过时，你会收到一条附带撤销日期的 REFUND 通知。这就是你关闭该用户访问权限的信号。而这就引出了代价高昂的部分。
App Store 退款如何造成收入损失
这不是一个数字，而是四个，其中三个从来不会出现在退款报告里。
退款本身。这笔款项会从你的下一次结算中扣除。Apple 的 Paid Applications Agreement 确实写明 Apple 可以保留退款交易的佣金，多年来这一条款吓到了不少人。但真正翻过付款报告的开发者表示，Apple 扣除的是扣佣之后的份额，而不是全额标价。你损失的是你的那份，通常不包括他们的那份。
没人切断的访问权限。在 Apple 那边，钱退出去和权益终止是两个独立的事件，而只有其中一个会自动发生。漏掉那条 REFUND 通知，用户就会继续免费享用 Pro 功能。我见过一个 $59.99 的年度方案，这种情况持续了四个月才有人发现。我们在 退款后收回访问权限一文中把整件事从头到尾梳理了一遍。
你的报表。退款会在购买数周之后才出现，有时甚至跨过一个计费周期。如果你按收入产生的那一周计算收入，却从不扣除后来退掉的部分，你的 LTV 就在悄悄虚高。接着你以承受不起的 CAC 去买流量，然后纳闷为什么这批用户永远收不回成本。
广告支出。你花钱获取了那个用户，他们还是退款了。这笔钱已经没了，而你的 dashboard 里没有任何数字会动一下来提醒你。
正常的退款率是什么水平
基准数据只有一个用处：判断你面对的是真正的问题，还是一个普通的问题。RevenueCat 的 State of Subscription Apps 覆盖了 75,000 多款应用，数据显示付费订阅在首个计费周期内的退款率中位数约为 3% 到 5%，异常值可达 9% 到 18%。
按价格档位切分是最有意思的角度。低价方案的中位数接近 2.7%，高价方案约为 4.5%。每上一个档位大约多一个百分点。年度方案的退款率也高于周度方案，这很好理解。一笔 $79 的扣款所带来的期望，$4.99 是不会有的。
下面是我为新客户计算这个数字的方法：
从退款历史中拉取最近 90 天的退款交易。
把每一笔归回原始购买发生的那个月，而不是退款发生的那个月。
除以同一个月的付费交易数。
按产品拆分。一个糟糕的付费墙每次都会藏在一个健康的平均值里。
低于 2% 算好。2% 到 5% 属正常。高于 5%，就该开始排查。高于 10%，别再怪营销了，去把你的付费墙文案大声读一遍。
App Store 退款预防：如何减少 App Store 退款
没有一键解决的开关。这是一堆小决策的叠加，而其中一些的分量远比其他的重。
回复每一条 CONSUMPTION_REQUEST。这是最大的杠杆，也是几乎所有人都跳过的一步。有人用掉了一次性买断内容的 90%，然后声称它从来没能用？拒绝，并出示使用数据。家长的孩子误购了一个 $29.99 的礼包？放行。这两种决定都需要有回复记录在案。
在首次会话中就交付点什么。退款集中在早期。如果新用户在撞到付费墙之前没能得到哪怕一个真实的结果，你卖给他们的就只是一个承诺。
把续订说清楚。价格、周期、续订日期，和购买按钮放在同一个屏幕上。大多数退款理由归根结底都是意外，而意外是一种设计选择。
提供试用或样品。Apple 的消耗信息表单会直接问你是否提供过。回答"是"对你的申辩有帮助，也给犹豫的用户一个成本更低的入口。
给客服留一扇门。一个醒目的联系链接，加上应用内的 退款请求表单，能让不满的用户先找你，而不是直接去找 Apple。这个表单从 iOS 15 起就已存在。它无法批准退款，只能发起请求。
钱退回去时就切断访问权限。处理 REFUND 和 REFUND_REVERSED，并在撤销退款时恢复访问权限，这样诚实的客户不会因为 Apple 改变主意而受罚。
盯住惯犯。Apple 的 Get Refund History 端点会列出与某个用户关联的每一笔退款交易。在给同一个账户第二次试用或折扣之前，先查一下。
12 小时难题
通知会在周六凌晨 3 点到达。要正确回复一条，你需要根据 Apple 的根证书验证其 JWS 签名链，把交易匹配到你自己数据库里的某个真实用户，以 milliunit 为单位计算消耗百分比，用 In-App Purchase 密钥签发一个短期有效的 JWT，然后提交。在时限用完之前。每一次都如此。
沙盒环境给你的不是 12 小时而是 5 分钟，这读起来像是 Apple 对你期望的一个相当直白的暗示：一台服务器，而不是一个抱着笔记本的人。
不想自己搭建这条管线的团队会使用 Refund Sensor。它基于你已有的商店密钥运行，在窗口期内从容地用交易证据回复每一条请求，并持续记录你保住了多少收入。设置大约 5 分钟，无需 SDK，无需改代码，无需重新提交应用。
还在比较其他方案？ 开发者如何选择 Apple 退款管理软件一文介绍了应该对比哪些方面。
参考来源
常见问题
不可以。计费关系归 Apple 所有，所以只有 Apple 能把钱退回去。你能做的有两件事：附上证据回复退款请求，或者通过 StoreKit 的退款请求表单，自己把 Apple 的退款表单交到客户手上。
客户会被告知在 48 小时内收到答复。而你自己的窗口要紧得多，从 CONSUMPTION_REQUEST 算起大约只有 12 小时。
协议上说他们有权这样做。但实际上，查看过 App Store Connect 付款报告的开发者发现，扣除的是扣佣之后的份额，所以你损失的是你赚到的那部分，而不是全额售价。
什么都不会发生，除非你自己去处理。Apple 会发送一条附带撤销日期的 REFUND 通知，你的服务器必须负责终止权益。漏掉它，这个用户就会继续免费使用 Pro。
根据 RevenueCat 覆盖 75,000 多款应用的数据，订阅类应用的付费交易退款率在 2% 到 5% 之间。健康、健身和教育类应用会更高。超过 10%，先检查定价和付费墙文案，其他的都放到后面。
可以，前提是 Apple 撤销了这笔退款。你会收到一条 REFUND_REVERSED 通知，应当把之前收回的东西还给用户。
通常是值得的。一个 $2.99 的消耗型商品不值得一个人花十分钟去处理，但值得服务器花两秒钟。在高交易量的应用里，这些小额款项累积起来非常快。
