Alguém abre o Relatar um Problema, escolhe o seu app e pede o dinheiro de volta à Apple. A Apple não decide de imediato. Antes, ela envia um ping ao seu servidor perguntando o que você sabe sobre a compra, e espera cerca de 12 horas por uma resposta.
Esse ping é o Apple CONSUMPTION_REQUEST. Muitas equipes com receita real de IAP nunca ouviram falar dele. Muitas outras viram uma vez nos logs e deixaram por lá. Se esse é o seu caso, nosso
guia sobre o Apple CONSUMPTION_REQUEST cobre o quê e o porquê. Este post é sobre a parte de responder. O que enviar, o que não enviar e o que aconteceu com quem tentou.
Principais pontos
A Apple envia um CONSUMPTION_REQUEST quando um cliente pede reembolso. Você tem cerca de 12 horas. Depois disso, ela decide sem você.
A resposta tem cinco campos. Não cinquenta. Cinco.
Sua preferência de reembolso é exatamente isso, uma preferência. A Apple já passou por cima dela antes e vai fazer isso de novo.
Sem consentimento do cliente, sem resposta. Palavras da Apple, não nossas.
Um app passou de uma taxa de reembolso de 3% para 1.9% em cerca de duas semanas só por começar a responder. Nunca pediu à Apple para recusar nada.
Ninguém faz isso manualmente por muito tempo. A janela é curta demais e os pedidos chegam em horários ruins.
Afinal, o que é exatamente um Apple CONSUMPTION_REQUEST?
É uma notificação de servidor, uma das muitas que a Apple envia por meio das App Store Server Notifications V2. Esta dispara quando alguém pede reembolso de uma compra dentro do app. Antes valia só para consumíveis. Desde a WWDC24 também cobre assinaturas auto-renováveis, que é onde está a maior parte do dinheiro.
Dentro do payload: a transação assinada, o ID do produto e o motivo que o cliente escolheu. A documentação
consumption Request Reason da Apple lista cinco: UNINTENDED_PURCHASE, FULFILLMENT_ISSUE, UNSATISFIED_WITH_PURCHASE, LEGAL, OTHER.
O que você não vai encontrar é um nome ou um Apple ID. Só um identificador de transação. Transformar isso em "esta é a usuária 48213 e ela abriu o app 40 vezes desde a compra" é trabalho seu, e só funciona se você anexou um appAccountToken no checkout. Escrevemos um
post inteiro sobre o appAccountToken porque muita gente pula essa etapa.
A Apple pergunta, você responde, a Apple decide. Esse é o formato dos pedidos de reembolso da Apple para desenvolvedores.
Como responder ao Apple CONSUMPTION_REQUEST
Você faz um PUT com um pequeno corpo JSON no endpoint Send Consumption Information da Apple, com o ID da transação no path. Esse corpo são as informações de consumo que o sistema de reembolso da Apple lê.
Customer Consented vem primeiro. True ou false. Se for false, pare. Não envie nada. A documentação da Apple diz que, sem consentimento, você não deve responder de jeito nenhum. Estranho, mas essa é a regra.
Depois, o delivery status. DELIVERED se funcionou. Se não, há variantes de UNDELIVERED para problema de qualidade, item errado, queda de servidor e outros.
Sample Content Provided é um sim ou não sobre se o cliente pôde experimentar antes de comprar. Teste grátis, sim. Prévia do conteúdo, sim. Um paywall com três bullet points, provavelmente não.
Consumption Percentage confunde muita gente. Está em miliunidades, então 100000 significa totalmente consumido e 50000 significa metade. Deixe de fora em assinaturas auto-renováveis. A Apple calcula isso a partir do período de cobrança.
E, por fim, refund Preference. DECLINE, GRANT_FULL ou GRANT_PRORATED. Opcional. Também é o único lugar onde você pode dizer o que quer.
Uma resposta para um pacote de moedas que já foi gasto:
A Apple responde com um 202 e nada mais. Nenhum veredito. Um engenheiro da Apple disse nos fóruns de desenvolvedores, lá em 2021: um 202 significa que seus dados "serão levados em consideração". Essa é toda a promessa.
Não envie DECLINE em tudo
Eu sei que é tentador. Resista.
Leia o motivo primeiro. FULFILLMENT_ISSUE significa checar seus logs de entrega. Se a compra realmente não chegou, envie o status UNDELIVERED correspondente com GRANT_FULL e siga em frente. Você não vai ganhar essa, e tentar faz seus DECLINEs futuros parecerem mais fracos.
UNINTENDED_PURCHASE é sobre uso. Comprou às 9:02, pediu reembolso às 9:05, zero sessões no meio? Provavelmente foi um toque acidental. Deixe passar. Usou todo dia por uma semana? DECLINE, com seu número real de consumo anexado.
UNSATISFIED_WITH_PURCHASE é onde Sample Content Provided se paga. Teve um teste e usou 80%? Recuse. Mal abriu? GRANT_PRORATED é um meio-termo justo.
Para LEGAL e OTHER, envie dados precisos e pule a preferência, a menos que seus registros tornem a decisão óbvia.
Um DECLINE em cima de 95% de consumo e um teste grátis é uma resposta forte. Um DECLINE em algo usado por noventa segundos parece reflexo automático.
O que aconteceu de verdade com quem fez isso
O Dipsea é um app de áudio que a RevenueCat comprou em setembro de 2024 e usou para testar seu próprio gerenciador de reembolsos. Em 23 de outubro, eles começaram a responder aos consumption requests com a preferência definida como "deixar a Apple decidir". Sem DECLINE. Só dados. Em cerca de 15 dias, a taxa de reembolso caiu de 3% cravados para 1.9%.
Eles publicaram o gráfico.Para mim, esse é o dado mais útil sobre o assunto. Os dados sozinhos moveram o número.
Agora o outro lado. Em março de 2024, um estúdio de games postou nos Apple Developer Forums que estava enviando consumption info e a Apple continuava aprovando "quase todos" os reembolsos de moedas que os jogadores já tinham gasto. Consumíveis são o caso difícil. Depois que as moedas se foram, a Apple não consegue recuperá-las. Se você mesmo não revogar o saldo após a notificação REFUND, perde o dinheiro e as moedas.
E em maio de 2025, uma thread no r/iOSProgramming se encheu de usuários da RevenueCat que tinham configurado "sempre preferir recusar" e, de repente, viram todos os reembolsos serem aprovados. A RevenueCat disse que foi uma mudança de política do lado da Apple. Seja qual for a causa, isso encerrou uma discussão antiga. Refund Preference não é um interruptor. DECLINE em massa é um padrão, e a Apple pode simplesmente ignorá-lo.
Jeitos de receber um 400 de volta
A Apple é rigorosa com o corpo da requisição. Estes são os erros que vemos repetidamente.
A questão das miliunidades. Alguém lê "percentage", envia 100 e acabou de dizer à Apple que o cliente usou um décimo de um por cento. O intervalo vai de 0 a 100000.
Uma porcentagem diferente de zero em um item não entregue. Se delivery Status não for DELIVERED, Consumption Percentage precisa ser 0 ou a requisição é rejeitada.
Qualquer porcentagem em uma assinatura auto-renovável. A Apple tem um erro dedicado para isso. Deixe de fora.
A chave errada. Essa chamada exige uma chave de In-App Purchase, gerada no App Store Connect em Usuários e Acesso, depois Integrações. Não a chave da App Store Connect API, mesmo que pareçam idênticas. A errada rende um 401 e uma hora duvidando do seu JWT.
Pular o consentimento. Não é um erro de HTTP, é um de compliance. Coloque a linguagem nos seus termos antes de isso entrar em produção.
Teste no sandbox primeiro. Um detalhe: a documentação de testes da Apple dá cinco minutos lá, não doze horas. Se seu servidor levar seis, o teste ignora seus dados. Para forçar uma recusa, escolha Other na tela de reembolso e digite DECLINE.
Como desenvolvedores lidam com pedidos de reembolso da App Store quando há muitos
Na maioria das vezes, não lidando, para ser franco. O pedido aparece às 3 da manhã. Ou no sábado. Ou num feriado, quando a única pessoa que entende o pipeline está offline. Doze horas passam. A Apple decide com base na palavra do cliente.
Como lidar com pedidos de reembolso da Apple como desenvolvedor se resume a uma decisão. Construir a cadeia você mesmo (verificar o JWS, localizar o usuário, puxar o uso, calcular a porcentagem, gerar um JWT, chamar o endpoint, registrar em log, tentar de novo) e mantê-la rodando para sempre. Ou plugar um software de gestão de reembolsos da Apple que já faz isso.
O Refund Sensor é uma opção desse segundo grupo. Você cola nossa URL de notificação no App Store Connect, conecta a chave e as respostas saem em segundos. Entre os apps que estão nele agora, 77% dos pedidos elegíveis foram defendidos, com cerca de $33 protegidos por caso. Não há nada de mágico acontecendo. Uma resposta com dados reais sai toda vez, antes do prazo. Se preferir comparar opções, nosso guia de ferramentas de gestão de reembolsos da Apple
mostra o que perguntar.
É por isso que a automação de reembolsos da Apple para desenvolvedores continua aparecendo na conversa. Doze horas, todo pedido, toda semana, não é tarefa para humanos. Seja o que for que você escolher, escolha algo. Silêncio significa que a Apple só ouve um lado.
Perguntas frequentes
Doze horas em produção, cinco minutos no sandbox. Os dois estão na documentação da Apple.
Não. A Apple chama suas informações de consumo de "um entre vários fatores". Isso melhora suas chances. Não decide nada.
Todos em que o cliente consentiu, sim. Até aqueles em que você envia GRANT_FULL porque seu servidor estava fora do ar. Respostas honestas nos casos fáceis são o motivo de a Apple confiar nos seus DECLINEs depois
deliveryStatus e sampleContentProvided, com precisão. Pule a porcentagem. Depois vá corrigir seu tracking.
Sim. DECLINE e GRANTFULL funcionam para todos os tipos de produto. GRANTPRORATED também, só que a Apple faz o cálculo proporcional por conta própria em planos auto-renováveis.
