Ir para o conteúdo
App Store Refund Management

Reembolsos da App Store e vazamento de receita: o que desenvolvedores precisam saber

Descubra como reembolsos da App Store geram vazamento de receita e o que desenvolvedores podem fazer para monitorar, gerenciar e reduzir as perdas ligadas a reembolsos.

5 min read
Reembolsos da App Store e vazamento de receita: o que desenvolvedores precisam saber

Um cliente meu descobriu o vazamento por acaso. O banco de dados dele apontava $11,400 de receita em fevereiro. O relatório financeiro no App Store Connect dizia $10,650. Nada tinha quebrado. Nenhum alerta havia disparado. Cerca de $750 simplesmente saíram pela porta, um reembolso de cada vez, e ele só ficou sabendo mais ou menos cinco semanas depois.

A Apple decide cada reembolso da App Store. Você não tem cadeira nessa mesa. O que você tem é uma janela estreita para colocar evidências na frente deles, e ela só se abre se o seu servidor estiver de fato escutando. A maioria dos textos sobre reembolsos da Apple App Store para desenvolvedores passa por cima dessa parte, o que é uma pena, porque é a única que você controla. A janela em si ganha um detalhamento próprio aqui: Como o CONSUMPTION_REQUEST da Apple decide o seu reembolso.

Principais pontos

  • A Apple decide. Você não pode emitir um reembolso, bloquear um, nem sequer ver o nome do cliente.

  • Sua única entrada é uma resposta a um CONSUMPTION_REQUEST, e ela precisa chegar em cerca de 12 horas.

  • A perda de receita com reembolsos da App Store se acumula em camadas. O reembolso em si é só a primeira.

  • A RevenueCat coloca a taxa mediana de reembolso de assinaturas entre 3% e 5%. Os casos fora da curva chegam a 9% a 18%.

  • A solução sem graça também é a barata: escute as notificações, responda automaticamente, corte o acesso quando o dinheiro voltar.

Como um reembolso da App Store aparece do seu lado

Alguém abre reportaproblem.apple.com, faz login, escolhe uma compra dos últimos 90 dias, seleciona um motivo e envia. A Apple lê. A Apple decide.

Você não fica sabendo de nada, a menos que tenha pedido para saber. Não existe botão de reembolso no App Store Connect, nem fila de solicitações pendentes, nem e-mail do cliente para responder. Se você tiver o App Store Server Notifications V2 ativado, um CONSUMPTION_REQUEST chega ao seu endpoint no momento em que a solicitação é registrada, trazendo a transação, o produto e o motivo escolhido pelo cliente. A partir daí, você tem cerca de 12 horas para chamar o endpoint Send Consumption Information com cinco campos: se o usuário consentiu, se a compra foi entregue, se havia uma amostra, quanto foi consumido e qual resultado você prefere.

Responda com números reais de uso e alegações fracas são negadas com bastante frequência. Não responda nada e a Apple fica com a versão do cliente mais o que o histórico da conta dele sugerir. Aqui, o silêncio conta como resposta, e é a que a maioria das equipes dá.

Quando um reembolso é aprovado, você recebe uma notificação REFUND com uma data de revogação anexada. Esse é o seu sinal para desligar o acesso do usuário. O que nos leva à parte cara.

Como reembolsos da App Store causam perda de receita

Não é um número só. São quatro, e três deles nunca aparecem em um relatório de reembolsos.

O reembolso. O valor é descontado do seu próximo pagamento. O Paid Applications Agreement da Apple diz, sim, que a Apple pode reter a comissão em uma venda reembolsada, e essa cláusula assustou muita gente ao longo dos anos. Desenvolvedores que realmente vasculharam seus relatórios de pagamento dizem que a Apple desconta a parte líquida de comissão, não o preço cheio. Você perde a sua fatia. Normalmente, não a deles.

O acesso que ninguém corta. O dinheiro sair e o direito de acesso terminar são dois eventos separados do lado da Apple, e só um deles acontece sozinho. Perca aquela notificação REFUND e o usuário continua com os recursos Pro. De graça. Já vi isso durar quatro meses antes de alguém perceber, em um plano anual de $59.99. Destrinchamos essa confusão toda em retomar o acesso depois de um reembolso.

Seus relatórios. Reembolsos aparecem semanas depois da compra, às vezes depois de um ciclo de cobrança. Conte a receita na semana em que foi gerada sem nunca subtrair o que foi reembolsado depois, e o seu LTV fica silenciosamente inflado. Aí você compra tráfego a um CAC que não pode pagar e fica se perguntando por que a coorte nunca se paga.

O gasto com anúncios. Você pagou para conquistar aquele usuário. Ele pediu reembolso mesmo assim. Esse dinheiro se foi e nada no seu dashboard se mexe para avisar.

Como é uma taxa de reembolso normal

Benchmarks servem para uma coisa: saber se você tem um problema real ou só um problema normal. O State of Subscription Apps da RevenueCat cobre mais de 75 mil apps e coloca a taxa mediana de reembolso em torno de 3% a 5% das assinaturas pagas no primeiro ciclo de cobrança. Os casos fora da curva chegam a 9% a 18%.

A faixa de preço é o corte mais interessante. Planos baratos ficam perto de uma mediana de 2.7%, os caros em torno de 4.5%. Mais ou menos um ponto a cada degrau acima. Planos anuais também têm mais reembolsos do que semanais, o que faz sentido. Uma cobrança de $79 cria expectativas que uma de $4.99 não cria.

É assim que eu calculo o número para um cliente novo:

  1. Puxe as transações reembolsadas dos últimos 90 dias no histórico de reembolsos.

  2. Leve cada uma de volta ao mês da compra original, não ao mês do reembolso.

  3. Divida pelas transações pagas desse mesmo mês.

  4. Separe por produto. Um paywall ruim sempre se esconde dentro de uma média saudável.

Abaixo de 2% está bom. De 2% a 5% é normal. Acima de 5%, comece a investigar. Acima de 10%, pare de culpar o marketing e vá ler o texto do seu paywall em voz alta.

Prevenção de reembolsos na App Store: como reduzir reembolsos

Não existe um interruptor único. É uma pilha de pequenas decisões, e algumas pesam muito mais do que as outras.

Responda a todo CONSUMPTION_REQUEST. A maior alavanca, e a que quase todo mundo pula. Alguém consumiu 90% de um desbloqueio vitalício e depois alegou que nunca funcionou? Conteste e mostre o uso. Um pai ou mãe cujo filho comprou um pacote de $29.99 sem querer? Deixe esse passar. As duas decisões precisam de uma resposta registrada.

Entregue algo na primeira sessão. Reembolsos se concentram no início. Se um usuário novo não consegue um resultado real antes de bater no paywall, você vendeu uma promessa.

Deixe a renovação explícita. Preço, período, data de renovação, na mesma tela do botão de compra. A maioria dos motivos de reembolso se resume a surpresa, e surpresa é uma escolha de design.

Ofereça um teste ou uma amostra. O formulário de consumo da Apple pergunta literalmente se havia um. Responder que sim ajuda o seu caso e dá aos usuários hesitantes uma porta de entrada mais barata.

Dê uma porta para o suporte. Um link de contato visível mais uma tela de solicitação de reembolso dentro do app mandam pessoas insatisfeitas para você antes de irem à Apple. Essa tela existe desde o iOS 15. Ela não concede o reembolso, só inicia a solicitação.

Corte o acesso quando o dinheiro voltar. Trate REFUND e REFUND_REVERSED, e devolva o acesso em uma reversão para que clientes honestos não sejam punidos porque a Apple mudou de ideia.

Fique de olho em reincidentes. O endpoint Get Refund History da Apple lista toda transação reembolsada vinculada a um usuário. Consulte-o antes de dar à mesma conta um segundo teste ou um desconto.

O problema das 12 horas

As notificações chegam às 3 da manhã de um sábado. Responder a uma delas direito significa validar a cadeia de assinatura JWS da Apple contra os certificados raiz deles, associar a transação a uma pessoa real no seu próprio banco de dados, calcular um percentual de consumo em miliunidades, gerar um JWT de curta duração com uma chave de In-App Purchase e enviar tudo. Antes de o tempo acabar. Toda santa vez.

O sandbox dá 5 minutos em vez de 12 horas, o que soa como uma dica bem direta do que a Apple espera de você. Um servidor. Não uma pessoa com um laptop.

Equipes que preferem não construir esse pipeline usam o Refund Sensor. Ele roda com as chaves de loja que você já tem, responde a cada solicitação com evidências da transação bem dentro da janela e mantém um placar contínuo do que você conseguiu segurar. Uns cinco minutos para configurar, sem SDK, sem mudanças de código, sem reenviar o app para revisão.

Ainda comparando opções? Como escolher um software de gestão de reembolsos da Apple para desenvolvedores mostra o que comparar.

Fontes

Perguntas frequentes

Não. A Apple é dona da relação de cobrança, então só a Apple pode devolver o dinheiro. Suas duas opções são responder a uma solicitação de reembolso com evidências ou entregar você mesmo o formulário de reembolso da Apple ao cliente por meio da tela de solicitação de reembolso do StoreKit.

Os clientes são informados de que terão uma resposta em até 48 horas. A sua janela é bem mais apertada: cerca de 12 horas a partir do CONSUMPTION_REQUEST.

O contrato diz que ela tem esse direito. Na prática, desenvolvedores que conferiram seus relatórios de pagamento no App Store Connect veem a parte líquida de comissão sendo descontada, então você perde o que ganhou, não o preço inteiro.

Nada, a menos que você faça acontecer. A Apple envia uma notificação REFUND com uma data de revogação, e o seu servidor precisa encerrar o direito de acesso. Se você deixar passar, esse usuário continua com o Pro de graça.

Entre 2% e 5% das transações pagas em apps de assinatura, segundo os dados da RevenueCat com mais de 75 mil apps. Saúde, fitness e educação ficam acima disso. Passou de 10%, olhe o preço e o texto do paywall antes de qualquer outra coisa.

Sim, quando a Apple reverte o reembolso. Você receberá uma notificação REFUND_REVERSED e deve devolver tudo o que tirou.

Normalmente, sim. Um consumível de $2.99 não vale dez minutos do dia de uma pessoa. Mas vale dois segundos de tempo de servidor, e em um app de alto volume essas pequenas somam rápido.

#Apple CONSUMPTION_REQUEST#App Store refund requests#Apple App Store refunds#Refund request response#App Store developer guide#Apple refund process
Refund SensorRefund Sensor TeamRefund defense for App Store and Google Play developers