你应用上的退款主要由你买单，但你损失的并不是你以为的那笔佣金

开发者论坛里有一种说法始终不肯消失：一笔销售你拿 70%，但退款会让你退回 100%，所以每笔退款都在悄悄让你赔上应用商店的抽成。这是错的。当 Apple 或 Google 为你的某位客户退款时，应用商店也会把自己的佣金退回，你的账面只冲销你真正留下的那一份。所以关于谁为你应用上的退款买单，诚实的答案是你，但要付的是一笔和多数人所说不同的账。你损失的是这笔销售，以及你为交付它已经花掉的一切，而不是再向应用商店多付 30%。下面就逐条讲清钱到底去了哪里，以及为什么有一种冲销，也就是拒付，打破了这条规则。

谁为退款买单，按应用商店拆分

先看冲销本身，暂且不谈交付成本。在账目层面，App Store 上的退款和 Google Play 上的退款以相同的方式撤销这笔销售：应用商店不再向你收取佣金，你退回你的净收益。无论哪种方式，客户都能拿回全额。下面按应用商店分别说明。

客户获得退款时 Apple 会保留佣金吗

这是开发者在 Apple Developer Forums 和 Hacker News 上问得最多的问题：如果 Apple 为买家退款，它会保留在这笔销售中抽走的那一份吗？读一读财务报表，答案是不会。一笔退款会显示为一行，其 Sale or Return 值为 R，Quantity 为负，被冲销的金额是 Extended Partner Share，即 Quantity 乘以 Partner Share，其中 Partner Share 是客户价格减去税费和 Apple 佣金。Apple 收回的是它付给你的钱，也就是你的净收益，而不是总价。那些拉取了自己详细报表的开发者也得到相同结论：Apple 扣除的是佣金之后的金额，而不是整笔销售。

细则里有一个陷阱。Apple 的 Paid Applications Agreement 写明，即便向最终用户退款，Apple 仍有权保留其在该笔销售中的佣金。所以退还佣金只是报表在实际中的结算方式，而不是承诺。Apple 保留了不退还其抽成的合同权利，通常的理解是，当它认定某位开发者存在不当行为时便会这样做。

Google 会退还什么，以及拒付之后会留下什么

Google 在书面表述上更明确。它的订单管理帮助文档写道，当你为一笔订单退款时，Google 会把服务费退还给你，并显示在你的下一份收入报告中。这个时点与你的收款挂钩。如果在 Google 就该订单向你付款之前退款，你只是根本不会在下一次收款中收到这笔钱。如果在收到付款之后退款，这笔金额会从未来的某次收款中扣除。部分退款按比例缩放：为一笔订单退款一半，那么你的收款和服务费各有一半退还给买家。

这是干净的情形。拒付并不干净，它是唯一一个应用商店不再像普通退款那样退还抽成的场景。

实际从你账户里流走的是什么

那么如果佣金会退回，退款为什么还是让人肉疼？因为售价从来都不是那位客户的全部成本。把钱分成两个桶来看。

第一个桶是销售本身。在退款中它的净额接近于零。客户拿回他们的钱，应用商店退还佣金，你冲销自己的收益。你失去的是已经记入账的利润，这在规模化时很重要，但你并没有向平台缴纳罚金。

第二个桶是报表从不显示的那个。它是你为把这笔付款变成已交付产品而花掉的一切，当付款被冲销时，这些成本没有一分会退回。

• 你已经跑掉的算力：客户已经收到的生成图像、视频或模型响应背后的 GPU 秒数。
• 你已经付过费的 API 调用：从一次地图查询到一个 LLM token 的每一次第三方请求，在发出的那一刻就已计入你的账单。
• 你仍在为之付费的存储：客户创建、而你持续托管的文件、导出内容和历史记录。
• 你已经付出去的分成：你就一笔刚刚被冲销的销售支付给创作者、司机或卖家的份额。

把这些加起来，一位获得退款的客户在退款之后可能比一位从未购买的客户成本更高。销售被抵消了，销售背后的支出却没有。

退款如何在你的收款中流转

退款不会单独向你开账单。它们走的是与你的销售相同的月度结算，这就是为什么退款集中的月份会让你早已指望的一笔收款缩水。

在 App Store 上

Apple 为每个财月生成一份财务报表，退款会以负数的 Return 记录记入其结算所在的月份。某个财月的报表会在下一个财月的第一个星期五之前发布。本月发起的退款会减少本月的收益。没有单独的账单，只是数字变小了。

在 Google Play 上

Google 会把每一笔资金变动都作为独立的一行放进你的收入报告：一行是扣款，一行是费用，一行是退款。如果退款在你就该订单收款之前发生，这笔订单的收入就永远不会到账。如果发生在之后，退款会从后续的某次收款中扣除。无论哪种情况，它都从收入中扣除，而不是一张要你缴付的账单。

你报表里代表退款的那一行

在 Apple 这边，筛选 Sale or Return 等于 R 的记录。这些行每一条都是流出的钱。在 Google 这边，在收入报告上查找退款交易类型，以及与之对应的退还服务费那一行。把这些和你自己的退款事件核对，就是你如何发现一位已被退款却从未失去访问权限的客户，而这正是把一笔廉价退款变成昂贵退款的疏漏。

为什么拒付比退款代价更高

把两者并排一比，差别就在银行。在一笔普通的 Google Play 退款中，服务费会退回，你只损失一笔被冲销销售中属于你的份额。在 2026 年 8 月 3 日政策下的一笔拒付中，你损失的是购买价减去服务费，再加上金融机构的拒付费用。同样是损失了这笔销售，却多了一笔只因由银行而非应用商店办理冲销才产生的费用。

Apple 那边也有自己的锋利之处。一笔拒付，或 Apple 在你迟迟才回应 CONSUMPTION_REQUEST 之后批准的退款，同样会冲销你的收益，而且如果 Apple 认定这种模式看起来像滥用，它保留保留佣金的合同权利。那套应用商店退还抽成的普通退款算法，只有在这笔交易看起来一切正常时才成立。

你真正能控制的是什么

你无法决定退款是否发生。这两家应用商店都保留了这项权利。你能决定的是每一笔退款发生之后要付出多大代价。

• 在冲销发生的那一刻切断访问权限。一位获得退款或拒付的客户如果仍在不断生成结果、调用你的 API、占满你的存储，就会把一笔本来打平的冲销变成一张不断增长的账单。
• 在两个举证窗口内准时回应。Apple 的 CONSUMPTION_REQUEST 给你 12 小时来发送消费数据。Google 的 orders.reviewrefund 给你 24 小时来对拒付提出异议。这是你这一方的说法唯一能起作用的时刻。
• 每个月把退款和你自己的记录核对，这样一笔没有撤销访问权限的冲销就会显示为一条你可以处理的记录，而不是一处缓慢的漏损。

这些都不会改变谁为退款买单。它们改变的是，当你付完之后这张账单到底有多大。