Ao transferir um app para outra conta de desenvolvedor, os pedidos feitos antes da venda ficam com o vendedor, e veja o que isso significa para os reembolsos

A página de ajuda do Google diz isso em uma linha: os pedidos criados antes de um app ser transferido continuam na conta original. Ou seja, quando você transfere um app para outra conta de desenvolvedor, os assinantes vão para o comprador, mas o histórico de compras não. Os reembolsos, as disputas e os chamados de suporte ligados a esse histórico não se resolvem sozinhos. Eles caem em quem as regras da loja apontam, e nem sempre é a parte que recebeu o dinheiro. Apple e Google tratam isso de formas diferentes, e a Apple diz menos que o Google. Veja o que cada loja documenta, que partes do seu esquema de reembolsos param de funcionar sem aviso depois de uma transferência e o que colocar no papel antes que qualquer um dos lados assine.

O que vai e o que fica quando você transfere um app

As duas lojas tratam a transferência como uma troca de dono daqui para frente. O app, os usuários e as notas vão junto. O registro financeiro do passado, na maior parte, não.

Na App Store

A regra da Apple é sobre dados. O desenvolvedor que transfere mantém acesso às informações de pagamento e vendas de antes da transferência e perde acesso a tudo o que vem depois. O destinatário só recebe as informações de pagamento e vendas das transações que acontecem depois da transferência. O guia de transferência da Apple não trata dos reembolsos de compras feitas antes da transferência. Não diz nada sobre de qual receita sai um reembolso tardio.

No Google Play

O Google é mais explícito. Usuários, estatísticas, dados, comentários, notas e assinaturas são transferidos. Os pedidos criados antes da transferência ficam na conta original, e se algum deles precisar de reembolso, o Google diz que você tem que voltar à conta original ou usar a Google Play Developer API. A conta do vendedor não deixa de importar no dia da venda. Ela continua sendo o único lugar de onde alguns reembolsos podem ser emitidos.

Quem emite um reembolso depois da transferência de um app

Nas duas lojas, a maioria dos reembolsos é decidida sem nenhum desenvolvedor. A Apple cuida sozinha dos pedidos de reembolso. No Google Play, os compradores podem reembolsar muitas compras por conta própria em até 48 horas, e o suporte do Google concede outros. Uma transferência não muda nada disso. O que muda é quem consegue ver o reembolso e quem pode agir nos raros fluxos que pedem algo ao desenvolvedor.

Um reembolso que você quer dar no Google Play

Imagine que um assinante antigo escreve para o novo dono pedindo o dinheiro de volta de uma cobrança de dois meses antes da venda. O novo dono não consegue reembolsar pela própria Play Console, porque o pedido não está lá. O vendedor tem que entrar e fazer isso, ou alguém com acesso à API da conta do vendedor tem que chamar a Google Play Developer API. Se o vendedor fechou a conta ou parou de responder, esse reembolso fica travado. O Google até oferece devolver ao vendedor a taxa de registro de $25 se ele fechar a conta original depois de uma transferência, e é justamente por isso que o comprador deve garantir que os reembolsos anteriores à transferência estejam resolvidos antes que isso aconteça.

Um reembolso que a Apple concede por conta própria

Na App Store, quem emite os reembolsos não é você, é a Apple. Quando a Apple reembolsa uma compra anterior à transferência, o registro de pagamento e venda dela fica com o desenvolvedor original. A documentação de transferência da Apple não diz de qual receita sai esse reembolso, então nenhum dos lados deve presumir nada. Coloque isso no acordo.

Os dois fluxos de reembolso que pedem evidências

Só dois fluxos de reembolso pedem alguma coisa ao desenvolvedor. A Apple envia um CONSUMPTION_REQUEST e dá 12 horas para você responder com dados de consumo via Send Consumption Information. O Google Play envia uma revisão de chargeback, e você tem 24 horas para responder via orders.reviewrefund. As duas respostas são assinadas com credenciais que pertencem a uma conta, não ao app. É aí que as transferências quebram.

O fluxo de reembolsos que quebra numa transferência

Um app transferido pode continuar vendendo por semanas sem que ninguém perceba que o lado dos reembolsos apagou.

A URL de notificações e a chave de In-App Purchase da Apple

A URL de App Store Server Notifications é configurada por app, em App information no App Store Connect. O guia de transferência da Apple não fala dela, então o novo dono deve abrir essa tela no primeiro dia e apontar produção e sandbox para o próprio servidor. Se ela ainda indicar o endpoint do vendedor, cada CONSUMPTION_REQUEST do app cai num servidor que o comprador não controla, e as 12 horas passam em silêncio.

As respostas passam pela App Store Server API, que exige uma chave de In-App Purchase. Essas chaves são geradas em Users and Access por um Account Holder ou Admin, e a Apple só deixa baixar cada uma uma única vez. A chave do vendedor fica na conta do vendedor. O comprador deve gerar a própria, e o vendedor deve revogar a dele assim que a passagem de bastão terminar.

O segredo compartilhado e os webhooks da Apple

Para apps com assinaturas de renovação automática, a Apple orienta o vendedor a gerar um segredo compartilhado específico do app antes da transferência e compartilhá-lo com o destinatário, que o usa para verificar as assinaturas. Depois que a transferência termina, o destinatário deve gerar um novo para que pessoas de fora da organização dele não o tenham mais. Os webhooks do App Store Connect também passam para o destinatário, e a Apple sugere que o vendedor os apague antes se não quiser que eventos continuem chegando ao servidor dele depois.

As permissões e o projeto do Cloud no Google

O Google diz que as permissões e as configurações de vinculação dos serviços integrados não são transferidas. Ele orienta o vendedor a adicionar a conta de destino como Owner de todos os projetos do Google Developers Console que o app usa. No Play, é ali que costumam ficar o seu tópico de notificações do desenvolvedor em tempo real e a conta de serviço por trás das suas chamadas à Developer API. Se a conta de serviço não receber acesso na Play Console do comprador, as verificações de compras anuladas falham e uma resposta de orders.reviewrefund não pode ser enviada dentro das 24 horas.

Quanto uma transferência custa em reembolsos e chargebacks

A mecânica acima vira dinheiro em três pontos.

Você atende usuários que pagaram ao vendedor

Pense num assinante que comprou um plano anual de $59,99 um mês antes da venda. No Google Play, esse pedido fica na conta do vendedor. Na App Store, o registro de pagamento fica com o vendedor. O comprador não recebe nada por ele e ainda assim arca com o processamento, as chamadas a APIs de terceiros e o armazenamento que esse assinante usa pelo resto do ano. Se esse assinante pedir um reembolso ao comprador mais tarde, o comprador não consegue emiti-lo no Google Play sem o vendedor. Conte essas assinaturas pré-pagas ao fechar o contrato, porque elas são um custo que o comprador assume sem receita nenhuma.

Chargebacks de pedidos que o comprador nunca vendeu

Para pedidos do Google Play feitos depois de 3 de agosto de 2026, o desenvolvedor responde pelo preço de compra do chargeback, menos a taxa de serviço do Play, mais a taxa de chargeback do banco. Um chargeback é definitivo para o banco depois de decidido. A página de transferência do Google não diz como esse custo é tratado para um pedido que ficou na conta do vendedor. Até o Google esclarecer, o contrato de venda deve dizer quem paga um chargeback de um pedido anterior à transferência e quem responde à revisão de chargeback.

A faixa de 15% conta os mesmos ganhos duas vezes

A taxa de serviço de 15% do Google Play vale para o primeiro $1 milhão de ganhos de um desenvolvedor a cada ano. Quando um app passa entre contas de desenvolvedor em Account Groups diferentes, todos os ganhos do app naquele ano civil entram no total dos dois grupos. O próprio exemplo do Google é um app que ganhou $100.000 no Account Group A e passa para o Account Group B. Esses $100.000 contam para o primeiro $1 milhão dos dois grupos. Um comprador perto do limite pode chegar à taxa padrão antes do que as próprias vendas indicariam.

O que acertar antes de transferir um app

Para o vendedor

• Baixe os relatórios de que você vai precisar. A exportação em massa, as vendas estimadas e os relatórios de ganhos do Google não são transferidos, e o destinatário na Apple não vai ver o seu histórico.
• Mantenha a conta original aberta e acessível até que os reembolsos e as disputas anteriores à transferência tenham seguido o seu curso.
• Gere e compartilhe o segredo compartilhado específico do app antes de uma transferência na App Store, depois revogue a sua chave de In-App Purchase e apague os webhooks que você não quer que continuem disparando.

Para o comprador

• Configure a sua própria URL de App Store Server Notifications e gere a sua própria chave de In-App Purchase no primeiro dia.
• Dê acesso à sua conta de serviço na sua Play Console e confirme que as notificações do desenvolvedor em tempo real chegam ao seu endpoint.
• Peça uma lista das assinaturas pré-pagas e das compras grandes recentes, para saber quem você vai atender sem receita.
• Coloque no contrato de venda os reembolsos, os chargebacks e as revisões de chargeback anteriores à transferência, com um contato nomeado do lado do vendedor.

O RefundHalt se conecta a cada app com credenciais da conta que é dona dele. Depois de uma transferência, conecte o app pela conta do novo dono, e a partir daí as solicitações de consumo e as revisões de chargeback passam a chegar ao novo dono.