Quem paga por um reembolso no seu app é quase sempre você, mas não pela comissão que você acha que está perdendo

Existe uma crença que não morre nos fóruns de desenvolvedores: você fica com 70 por cento de uma venda, mas um reembolso faz você devolver 100 por cento, então cada reembolso custa em silêncio a parte da loja. Está errado. Quando a Apple ou o Google reembolsa um dos seus clientes, a loja também devolve a comissão, e a sua contabilidade reverte apenas a parte que você de fato guardou. Então a resposta honesta para quem paga por um reembolso no seu app é você, mas por uma conta diferente da que a maioria das pessoas cita. Você perde a venda e tudo o que já gastou para entregá-la, não 30 por cento a mais para a loja. Aqui está para onde o dinheiro vai de verdade, linha por linha, e por que um tipo de reversão, o chargeback, quebra a regra.

Quem paga por um reembolso, dividido por loja

Comece pela reversão em si, antes de qualquer conversa sobre custos de entrega. Um reembolso na App Store e um reembolso no Google Play desfazem a venda da mesma forma no nível contábil: a loja para de cobrar a comissão e você devolve os seus ganhos líquidos. O cliente recebe o preço completo de volta de qualquer forma. Aqui está a divisão, por loja.

A Apple fica com a comissão quando um cliente é reembolsado?

Esta é a pergunta que os desenvolvedores mais fazem, nos Apple Developer Forums e no Hacker News: se a Apple reembolsa um comprador, ela fica com a parte que tirou da venda? Leia o relatório financeiro e a resposta é não. Um reembolso aparece como uma linha com Sale or Return definido como R e uma Quantity negativa, e o dinheiro revertido é o Extended Partner Share, Quantity vezes Partner Share, onde Partner Share é o preço ao cliente menos impostos e a comissão da Apple. A Apple está recuperando o que pagou a você, os seus ganhos líquidos, não o preço bruto. Desenvolvedores que puxaram os próprios relatórios detalhados encontraram a mesma coisa: a Apple descontou o valor após a comissão, não a venda completa.

Há uma pegadinha nas letras miúdas. O Paid Applications Agreement da Apple diz que a Apple tem o direito de reter a comissão em uma venda apesar de um reembolso ao usuário final. Então o comportamento de devolver é como os relatórios são fechados na prática, não uma promessa. A Apple mantém a opção contratual de reter a sua parte, e a leitura comum é que ela faz isso quando decide que um desenvolvedor está fazendo algo errado.

O que o Google devolve, e o que um chargeback depois retém

O Google é mais explícito por escrito. A ajuda de gestão de pedidos diz que quando você reembolsa um pedido, o Google devolve a taxa de serviço e você a vê no seu próximo relatório de ganhos. O momento está ligado ao seu pagamento. Reembolse um pedido antes de o Google ter pago por ele e você simplesmente nunca recebe aquele valor no seu próximo pagamento. Reembolse depois de ter sido pago e o valor é descontado de um pagamento futuro. Reembolsos parciais escalam: reembolse metade de um pedido e metade tanto do seu pagamento quanto da taxa de serviço volta ao comprador.

Esse é o caso limpo. Um chargeback não é limpo, e é o único ponto em que a loja para de devolver a parte da forma como um reembolso comum faz.

O que de fato sai da sua conta

Então, se a comissão volta, por que um reembolso ainda dói? Porque o preço de venda nunca foi o custo inteiro daquele cliente. Acompanhe o dinheiro em duas partes.

A primeira parte é a venda em si. Em um reembolso ela fica perto de zero. O cliente recebe o dinheiro de volta, a loja devolve a comissão e você reverte os seus ganhos. Você perde o lucro que tinha registrado, o que importa em escala, mas não paga uma penalidade à plataforma.

A segunda parte é a que os relatórios nunca mostram. É tudo o que você já gastou transformando aquele pagamento em um produto entregue, e nada disso reverte quando o pagamento reverte.

• Computação que você já rodou: os segundos de GPU por trás de uma imagem, um vídeo ou uma resposta de modelo gerada que o cliente já recebeu.
• Chamadas de API que você já pagou: cada requisição de terceiros, de uma consulta de mapas a um token de LLM, cobrada de você no momento em que disparou.
• Armazenamento que você ainda paga: os arquivos, as exportações e o histórico que o cliente criou e que você continua hospedando.
• Pagamentos que você já enviou: a parte do criador, do motorista ou do vendedor que você desembolsou por uma venda que acabou de reverter.

Some tudo isso e um cliente reembolsado pode custar mais depois do reembolso do que um cliente que nunca comprou. A venda se anula. O gasto por trás dela não.

Como um reembolso passa pelo seu pagamento

Reembolsos não são cobrados de você separadamente. Eles passam pela mesma liquidação mensal que as suas vendas, e é por isso que um mês pesado de reembolsos pode encolher um pagamento com o qual você já contava.

Na App Store

A Apple gera um relatório financeiro para cada mês fiscal, e os reembolsos são registrados no mês em que são liquidados, como linhas de Return negativas. O relatório de um mês fiscal fica disponível até a primeira sexta-feira do mês seguinte. Um reembolso emitido neste mês reduz os ganhos deste mês. Não há uma fatura separada, apenas um número menor.

No Google Play

O Google coloca cada movimento no seu relatório de ganhos como uma linha própria, uma para uma cobrança, uma para uma taxa, uma para um reembolso. Se o reembolso cai antes do seu pagamento por aquele pedido, a receita do pedido nunca chega. Se cai depois, o reembolso é subtraído de um pagamento posterior. De qualquer forma sai dos ganhos, não de uma fatura que você paga.

A única linha do seu relatório que é o reembolso

Na Apple, filtre por Sale or Return igual a R. Cada uma dessas linhas é dinheiro saindo. No Google, procure o tipo de transação de reembolso no relatório de ganhos e a linha correspondente de taxa de serviço devolvida. Conciliar isso com os seus próprios eventos de reembolso é como você pega um cliente que foi reembolsado mas nunca perdeu o acesso, que é a falha que transforma um reembolso barato em um caro.

Por que um chargeback custa mais do que um reembolso

Coloque os dois lado a lado e a diferença é o banco. Em um reembolso normal do Google Play, a taxa de serviço volta e você perde apenas a sua parte de uma venda que reverteu. Em um chargeback sob a política de 3 de agosto de 2026, você perde o preço de compra menos a taxa de serviço, e ainda a taxa de chargeback da instituição financeira por cima. A mesma venda perdida, mais uma taxa que existe só porque um banco, não uma loja, processou a reversão.

O lado da Apple tem a própria aresta. Um chargeback, ou um reembolso que a Apple concede depois de um CONSUMPTION_REQUEST que você respondeu tarde, ainda reverte os seus ganhos, e a Apple mantém o direito contratual de reter a comissão se decidir que o padrão parece abuso. As contas do reembolso comum, em que a loja devolve a parte, valem apenas enquanto nada na transação parece errado.

O que você de fato pode controlar

Você não pode decidir se um reembolso acontece. As duas lojas reservam isso. Você pode decidir quanto cada um custa depois que dispara.

• Corte o acesso no momento em que a reversão chega. Um cliente reembolsado ou com chargeback que continua gerando resultados, chamando as suas APIs e enchendo o seu armazenamento transforma uma reversão que ficava no zero a zero em uma conta que cresce.
• Responda às duas janelas de evidência no prazo. O CONSUMPTION_REQUEST da Apple dá 12 horas para enviar os dados de consumo. O orders.reviewrefund do Google dá 24 horas para contestar um chargeback. Esses são os únicos momentos em que a sua versão da história conta.
• Concilie os reembolsos com os seus próprios registros todo mês, para que uma reversão que não revogou o acesso apareça como uma linha na qual você pode agir, não como um vazamento lento.

Nada disso muda quem paga por um reembolso. Muda o tamanho da conta na hora em que você termina de pagá-la.