把应用转让给另一个开发者账号后，出售前的订单仍留在卖方那里，下面讲清楚这对退款意味着什么

Google 的帮助页面用一句话就说明了这一点：应用转让前创建的订单会保留在原账号中。所以，当你把应用转让给另一个开发者账号时，订阅用户会转到买方名下，但购买记录不会。与这些记录相关的退款、争议和支持工单不会自行了结。它们会落到商店规则所指向的那一方，而这一方并不总是收到钱的那一方。Apple 和 Google 的处理方式不同，而且 Apple 说明的内容比 Google 少。下面介绍两家商店各自的文档说了什么，转让后你的退款设置中哪些部分会悄无声息地失效，以及在任何一方签字之前应该落实到书面的内容。

转让应用时，哪些会转移，哪些会留下

两家商店都把转让视为今后所有者的变更。应用、用户和评分会转移。过去的财务记录大多不会。

在 App Store 上

Apple 的规则针对的是数据。转出方开发者保留对转让前付款和销售信息的访问权限，并失去对转让后所有信息的访问权限。接收方只会收到转让之后发生的交易的付款和销售信息。Apple 的转让指南没有涉及转让前购买的退款。对于迟来的退款从谁的收益中扣除，它也只字未提。

在 Google Play 上

Google 说得更明确。用户、统计数据、数据、评论、评分和订阅都会转移。转让前创建的订单留在原账号中，如果其中某笔需要退款，Google 表示你必须回到原账号操作，或者使用 Google Play Developer API。卖方账号并不会在出售当天就失去作用。它仍然是某些退款唯一能发起的地方。

应用转让后由谁来退款

在两家商店，大多数退款都无需开发者参与就会被决定。Apple 会自行处理退款申请。在 Google Play 上，买家可以在 48 小时内自行为许多购买退款，其他退款则由 Google 支持团队批准。转让不会改变这些。它改变的是谁能看到退款，以及谁能处理少数需要开发者介入的流程。

你想在 Google Play 上主动发起的退款

假设一位老订阅用户联系新所有者，要求退还出售前两个月的一笔扣款。新所有者无法在自己的 Play Console 中退款，因为订单不在那里。必须由卖方登录去操作，或者由拥有卖方账号 API 访问权限的人调用 Google Play Developer API。如果卖方已经关闭账号或不再回复，这笔退款就卡住了。Google 甚至表示，如果卖方在转让后关闭原账号，可以退还其 $25 注册费，这正是买方应该在那之前确保转让前退款有着落的原因。

Apple 自行批准的退款

在 App Store 上，退款的不是你，而是 Apple。当 Apple 为一笔转让前的购买退款时，这笔交易的付款和销售记录在原开发者那里。Apple 的转让文档没有说明由哪一方的收益承担这笔退款，所以双方都不应想当然。把它写进协议里。

需要提供证据的两个退款流程

只有两个退款流程会要求开发者提供信息。Apple 会发送 CONSUMPTION_REQUEST，并给你 12 小时通过 Send Consumption Information 回复消费数据。Google Play 会发送拒付审核，你需要在 24 小时内通过 orders.reviewrefund 回复。这两种回复都使用属于账号而不是属于应用的凭据签名。转让正是在这里出问题。

转让过程中会断掉的退款环节

转让后的应用可能继续销售好几周，却没有人发现退款这一侧已经失灵。

Apple 的通知 URL 和 In-App Purchase 密钥

App Store Server Notifications 的 URL 是按应用设置的，位于 App Store Connect 的 App information 中。Apple 的转让指南没有提到它，所以新所有者应在第一天就打开这个页面，把生产环境和沙盒环境都指向自己的服务器。如果那里仍然填着卖方的端点，这个应用的每一个 CONSUMPTION_REQUEST 都会发到买方并不运营的服务器上，12 小时就在无人回应中过去了。

回复要通过 App Store Server API 发送，这需要 In-App Purchase 密钥。这些密钥由 Account Holder 或 Admin 在 Users and Access 中生成，而且 Apple 每个密钥只允许下载一次。卖方的密钥在卖方的账号里。买方应该生成自己的密钥，卖方则应在交接完成后吊销自己的密钥。

Apple 的共享密钥和 Webhook

对于有自动续期订阅的应用，Apple 要求卖方在转让前生成一个 App 专用共享密钥并分享给接收方，接收方用它来验证订阅。转让完成后，接收方应生成一个新的共享密钥，这样其组织以外的人就不再持有它。App Store Connect 的 Webhook 也会转移给接收方，Apple 建议卖方如果不希望之后还有事件发送到自己的服务器，就先把它们删除。

Google 的权限和 Cloud 项目

Google 表示，集成服务的权限和关联设置不会转移。它要求卖方把目标账号添加为应用所用的所有 Google Developers Console 项目的 Owner。在 Play 上，你的实时开发者通知主题和用于调用 Developer API 的服务账号通常就在这里。如果服务账号没有在买方的 Play Console 中获得访问权限，作废购买检查就会失败，orders.reviewrefund 的回复也无法在 24 小时内发出。

转让在退款和拒付上的代价

上面这些机制会在三个地方变成真金白银。

你在服务那些付钱给卖方的用户

以一位在出售前一个月购买了 $59.99 年度方案的订阅用户为例。在 Google Play 上，这笔订单在卖方账号中。在 App Store 上，它的付款记录留在卖方那里。买方拿不到这笔钱，却仍要承担这位订阅用户在这一年剩余时间里使用的计算资源、第三方 API 调用和存储。如果这位订阅用户之后向买方要求退款，买方在 Google Play 上没有卖方就无法退款。签约时就要清点这些预付订阅，因为它们是买方承担却没有收入对应的成本。

买方从未卖出的订单遭遇拒付

对于 2026年8月3日之后下的 Google Play 订单，开发者需要承担拒付的购买价格减去 Play 服务费后的金额，外加银行的拒付手续费。拒付一旦判定，在银行层面就是最终结果。Google 的转让页面没有说明，对于留在卖方账号中的订单，这项成本如何处理。在 Google 给出说明之前，出售合同应写明转让前订单的拒付由谁承担，以及由谁回复其拒付审核。

15% 档位会把同一笔收入计算两次

Google Play 的 15% 服务费适用于开发者每年收入中的首个 $1 million。当应用在分属不同 Account Group 的开发者账号之间转移时，该应用在这一日历年的全部收入都会同时计入两个组的总额。Google 自己举的例子是：一个应用在 Account Group A 赚了 $100,000，然后转到 Account Group B。这 $100,000 会同时计入两个组的首个 $1 million。接近门槛的买方可能会比按自身销售额预计的更早触及标准费率。

转让应用前要谈妥的事

对于卖方

• 下载你需要的报告。Google 的批量导出、预估销售报告和收入报告不会转移，Apple 的接收方也看不到你的历史记录。
• 在转让前的退款和争议全部处理完毕之前，保持原账号开启并能联系到。
• 在 App Store 转让前生成并分享 App 专用共享密钥，之后吊销你的 In-App Purchase 密钥，并删除不希望之后继续触发的 Webhook。

对于买方

• 第一天就设置你自己的 App Store Server Notifications URL，并生成你自己的 In-App Purchase 密钥。
• 在你的 Play Console 中为服务账号授予访问权限，并确认实时开发者通知能送达你的端点。
• 拿到一份预付订阅和近期大额购买的清单，这样你就知道哪些服务是在没有收入的情况下提供的。
• 把转让前的退款、拒付和拒付审核写进出售协议，并指定卖方一侧的具体联系人。

RefundHalt 使用拥有该应用的账号的凭据连接每个应用。转让后，请从新所有者的账号重新连接应用，此后消费请求和拒付审核都会转给新所有者。