Reembolso na App Store: o que o desenvolvedor vê
Por Mehdi Azizi
Publicado em , 8 min
Na App Store, quem decide o reembolso é a Apple. O desenvolvedor recebe CONSUMPTION_REQUEST, pode responder em até 12 h e fica sabendo da decisão pelo REFUND.
Na App Store, quem concede ou recusa um reembolso é a Apple, nunca o desenvolvedor. O cliente faz o pedido no site da Apple ou dentro do seu app. Se você configurou as notificações de servidor da Apple, recebe uma notificação CONSUMPTION_REQUEST no momento do pedido e depois REFUND ou REFUND_DECLINED quando sai a decisão. Entre uma e outra, você tem 12 horas para enviar dados de consumo e a sua preferência, desde que o cliente tenha dado consentimento.
Um reembolso concedido tira a compra dos direitos ativos do cliente e aparece como valor negativo nos seus relatórios de vendas. Este guia detalha cada etapa, o que você pode enviar para a Apple e o que você pode fazer contra pedidos abusivos. As regras vêm das páginas da Apple que reli em 3 de novembro de 2026. O caso real vem de um alerta que configurei nos meus apps em outubro.
Quem decide um reembolso na App Store?
A Apple, e só ela. A página de suporte da Apple descreve o caminho do cliente: ele entra em reportaproblem.apple.com, escolhe "Request a refund", informa um motivo e depois a compra em questão. A Apple recomenda esperar de 24 a 48 horas pela resposta.
O cliente também pode pedir reembolso dentro do seu app. O StoreKit oferece para isso uma tela de solicitação, disponível desde o iOS 15. A Apple recomenda chamá-la a partir das configurações da conta ou de um menu de ajuda. Ela mostra a compra e uma lista de motivos, e a Apple leva até 48 horas para decidir.
Nos dois casos, você não precisa aprovar nada. Você só pode fornecer informações e uma preferência, que são alguns dos critérios que a Apple considera na decisão.
O que cada um vê, etapa por etapa
| Etapa | Lado do cliente | Lado do desenvolvedor |
|---|---|---|
| Pedido | Formulário da Apple ou tela no app | Notificação CONSUMPTION_REQUEST |
| Nas 12 horas seguintes | Espera | Pode enviar os dados de consumo |
| Em até 48 horas | Resposta da Apple | Notificação REFUND ou REFUND_DECLINED |
| Depois de aprovado | Dinheiro devolvido no meio de pagamento | Compra retirada dos direitos ativos, unidades negativas |
| Depois de contestação | Reembolso cancelado pela Apple | Notificação REFUND_REVERSED, acesso a restabelecer |
O App Store Connect só mostra os reembolsos já concedidos, em Sales and Trends. O pedido em si só chega pelas notificações de servidor. Sem elas, você descobre o reembolso depois que ele já aconteceu.
As notificações de servidor de um reembolso
As App Store Server Notifications V2 enviam cinco tipos úteis aqui. Você recebe no endereço HTTPS cadastrado no App Store Connect, um para produção e outro para sandbox.
| Notificação | O que ela avisa | O que você faz |
|---|---|---|
CONSUMPTION_REQUEST | O cliente pede um reembolso | Responder em até 12 horas, se houver consentimento |
REFUND | A Apple reembolsou a transação | Retirar o conteúdo ou o acesso reembolsado |
REFUND_DECLINED | A Apple recusou o pedido | Nada, o acesso continua |
REFUND_REVERSED | A Apple cancela um reembolso após uma contestação do cliente | Restabelecer o que você tinha retirado |
REVOKE | Uma compra compartilhada no Compartilhamento Familiar não está mais disponível | Retirar o acesso do membro da família |
Seu servidor precisa responder com um código HTTP entre 200 e 206. Segundo a página sobre respostas às notificações, caso contrário a Apple tenta de novo cinco vezes, 1, 12, 24, 48 e 72 horas depois da tentativa anterior. Na sandbox, ela envia só uma vez.
A Consumption API: o que você pode dizer para a Apple
Quando o pedido chega, você pode responder com Send Consumption Information. A regra cabe numa frase da Apple: "Respond within 12 hours of receiving the CONSUMPTION_REQUEST notification." A versão 2 da API vale para todos os tipos de produto, incluindo assinaturas.
Os campos da requisição:
| Campo | Obrigatório | O que ele diz para a Apple |
|---|---|---|
customerConsented | Sim | O cliente consentiu com o compartilhamento dos dados |
deliveryStatus | Sim | A compra foi entregue e funciona, ou por que não foi |
sampleContentProvided | Sim | Um teste, uma amostra ou uma descrição foi oferecido antes da compra |
consumptionPercentage | Não | A parte consumida, de 0 a 100 000 para 0 a 100 % |
refundPreference | Não | Sua preferência: DECLINE, GRANT_FULL ou GRANT_PRORATED |
Dois detalhes importam. Se deliveryStatus não for DELIVERED, a parte consumida tem que ser zero. E para um reembolso proporcional de assinatura, você omite a parte consumida: a Apple calcula.
O consentimento é a condição de tudo. A Apple escreve: "You must obtain valid consent from the customer before sharing their personal data with Apple in the Send Consumption Information API." Sem consentimento, você não responde. A Apple também proíbe usar a janela de rastreamento publicitário para obter esse consentimento: "Don't use the AppTrackingTransparency prompt to obtain consent".
Se você usa RevenueCat
Com o RevenueCat, é ele que recebe as notificações da Apple e responde ao pedido, com o Refund Control. Você escolhe uma entre quatro políticas: preferir reembolso total, preferir recusa, enviar só os dados de consumo ou não responder.
Ativar o compartilhamento de dados equivale a confirmar que você tem o consentimento dos seus clientes. O próprio RevenueCat diz: "Enabling consumption data sharing confirms that you obtained consent from your Customers." Ele também recomenda reservar "Prefer no refund" para um grupo específico e avisa quando essa preferência atinge a maioria dos seus clientes.
Para receber as notificações também no seu próprio servidor, o RevenueCat oferece um campo "Apple Server Notification Forwarding URL" nas configurações do app. Ele está descrito na página dele sobre as notificações da Apple. É o que eu uso. A configuração de uma assinatura com RevenueCat está em RevenueCat e assinatura in-app no iOS.
O efeito na sua receita e na assinatura
No acesso. Segundo a documentação de currentEntitlements, "Products that the App Store has refunded or revoked don't appear in the current entitlements". Se o seu app verifica os direitos com currentEntitlements, o acesso reembolsado some sozinho. A transação traz a data e o motivo da revogação, em revocationDate e revocationReason.
Nos relatórios. Segundo a ajuda do relatório de vendas, um reembolso aparece com unidades e preço ao cliente negativos. Para assinaturas, a página sobre dados de assinatura conta os reembolsos totais e parciais entre os eventos e os tira das unidades diárias.
Na sua reputação. A guideline 5.6.4 cita pedidos de reembolso excessivos entre os sinais de qualidade insuficiente. Uma taxa de reembolso alta não é só perda de dinheiro: a Apple pode levar isso em conta para avaliar se você respeita o código de conduta.
Meu caso: o alerta configurado nos meus apps
Em 12 de outubro de 2026, configurei um alerta nos meus apps. O RevenueCat repassa as notificações da Apple para uma rota de devoria.fr. Ela verifica a assinatura da Apple e depois me manda um alerta, sem valor. Eu queria ver o pedido na hora em que ele chega, não só o resultado.
Em 18 de outubro, chegou o primeiro pedido de verdade no TradaZen, meu simulador de trading. Uma assinatura anual, paga no fim de um teste grátis de 7 dias. Motivo informado: compra não intencional. Três lições:
- O mesmo pedido pode chegar várias vezes. Recebi o mesmo alerta três vezes na mesma noite. Desde então, cada alerta é deduplicado pelo tipo de notificação e pelo identificador da transação.
- A decisão chegou em menos de um dia. A Apple recusou cerca de 22 horas depois do pedido. O cliente manteve o acesso.
- Uma recusa não é o fim. O mesmo cliente fez outro pedido dois dias depois, na mesma transação.
Um pedido por "compra não intencional" no fim de um teste não se ganha na resposta à Apple. Ele se evita no paywall, antes do primeiro pagamento.
Reduzir pedidos abusivos sem violar as regras
O que é permitido:
- Responder a cada pedido com dados corretos, quando o cliente consentiu.
- Expressar uma preferência direcionada, por exemplo uma recusa para uma compra já consumida, em vez de recusar para todo mundo.
- Associar cada
REFUNDa uma conta de cliente. A página da Apple sobre notificações de reembolso recomenda isso para identificar reembolsos repetidos. - Dizer claramente o que a pessoa está comprando antes da compra. A guideline 3.1.2(c) exige descrever o que o usuário recebe pelo preço antes de oferecer a assinatura.
O que é proibido:
- Enviar dados falsos para fazer um pedido ser recusado, ou responder sem consentimento.
- Obter o consentimento pela janela de rastreamento publicitário, algo que a Apple exclui com todas as letras.
- Armar uma armadilha na compra. A guideline 5.6 proíbe induzir clientes a compras indesejadas ou cobrar pelo que não foi entregue.
- Pressionar um cliente que pede reembolso. A mesma regra exige respeito no atendimento ao cliente, sem intimidação.
A melhor alavanca continua sendo antes: um paywall que mostra o preço, a data do primeiro pagamento e como cancelar. Os erros a evitar estão em os erros de paywall, e as regras do teste em o teste grátis na App Store.
Testar antes da produção
Segundo a página sobre teste de pedidos, a sandbox e os testes StoreKit do Xcode aceitam pedidos de reembolso. Na sandbox, qualquer motivo gera uma aprovação automática. Para simular uma recusa, escolha "Other" e digite DECLINE. Para um reembolso proporcional, digite GRANT_PRORATED. Na sandbox, sua resposta de consumo precisa sair em até cinco minutos.
Uma assinatura com menos reembolsos
O iOS & Android Kit parte do código dos meus apps, com onboarding, paywall e assinaturas já programados, e segue quatro etapas até a App Store, no seu ritmo. A configuração completa está detalhada na página assinatura in-app no iOS, e as regras da Apple sobre assinatura em a guideline 3.1.2.
Antes de lançar seu paywall, faça seu diagnóstico grátis: ele mostra o que realmente trava o seu projeto e te envia meu checklist anti-rejeição da Apple.
Perguntas frequentes
O desenvolvedor pode recusar um reembolso na App Store?
Não. A Apple decide sozinha. Você pode enviar dados de consumo e uma preferência, DECLINE por exemplo, que entram entre vários critérios. A palavra final é da Apple.
O desenvolvedor é avisado de um pedido de reembolso?
Sim, se tiver configurado as App Store Server Notifications V2. A Apple envia CONSUMPTION_REQUEST no momento do pedido e depois REFUND ou REFUND_DECLINED na decisão. Sem notificações, você só vê os reembolsos concedidos, nos relatórios.
Quanto tempo a Apple leva para processar um pedido de reembolso?
A Apple informa 24 a 48 horas ao cliente. A documentação do StoreKit fala em no máximo 48 horas. Do seu lado, você tem 12 horas para enviar os dados de consumo.
O que acontece com o acesso depois de um reembolso?
A compra reembolsada sai dos direitos ativos do cliente: o StoreKit 2 não a retorna mais em currentEntitlements. Se a Apple cancelar o reembolso depois, você recebe REFUND_REVERSED e precisa restabelecer o acesso.
Preciso do consentimento do cliente para responder à Apple?
Sim. A Apple exige um consentimento válido antes de qualquer compartilhamento de dados pela Consumption API. Sem ele, você não responde à notificação. A janela de rastreamento publicitário não pode ser usada para obtê-lo.
Os reembolsos contam contra o meu app?
Podem contar. A guideline 5.6.4 cita pedidos de reembolso excessivos entre os sinais de qualidade insuficiente, e a Apple pode levar isso em conta para avaliar o respeito ao código de conduta.

