Todo reembolso da App Store é uma decisão da Apple, mas a Apple prefere não tomá-la sem informação. Uma solicitação de reembolso pausa o processo, envia uma pergunta ao seu servidor e abre um período fixo para você responder com fatos sobre a compra. Responda de forma substancial e reivindicações infundadas são recusadas. Fique em silêncio e a versão do cliente é a única que a Apple ouve.
Principais pontos
Solicitações de reembolso na App Store fazem a Apple enviar ao seu servidor uma notificação CONSUMPTION_REQUEST e, depois, aguardar até 12 horas por evidências antes de decidir.
Responder significa chamar o endpoint Send Consumption Information com um payload compacto: consentimento, status da entrega, se havia uma amostra disponível, quanto foi consumido e o resultado que você deseja.
Não enviar nada já é, em si, uma resposta. A Apple segue em frente usando apenas o que o cliente alegou, junto com o histórico da conta dele.
O consentimento funciona como uma barreira intransponível. A documentação da Apple é explícita ao afirmar que você não deve responder de forma alguma quando o cliente não concordou com o compartilhamento dos dados de consumo dele.
Nas assinaturas de renovação automática, o percentual de consumo é calculado pela Apple a partir do tempo decorrido, e fornecer seu próprio valor gera um erro.
Nenhum processo manual cabe dentro dessa janela. Os desenvolvedores que saem ganhando são aqueles cuja resposta é montada e enviada automaticamente.
Todo reembolso na App Store começa da mesma forma: alguém acessa reportaproblem.apple.com, seleciona uma compra e escolhe um motivo.
A notificação que, na maioria das vezes, fica sem resposta
Apps configurados para App Store Server Notifications V2 recebem uma notificação CONSUMPTION_REQUEST assim que o reembolso é solicitado. Dentro desse payload estão a transação, o produto e, desde 2024, o motivo escolhido pelo cliente: UNINTENDED_PURCHASE, FULFILLMENT_ISSUE, UNSATISFIED_WITH_PURCHASE, LEGAL ou OTHER.
A partir daí, começam a contar 12 horas, durante as quais você pode chamar o endpoint Send Consumption Information e registrar oficialmente a sua versão. O que esse endpoint pede é intencionalmente mínimo: cinco campos que carregam apenas flags e números.
customerConsented informa à Apple se o cliente concordou com o compartilhamento dos dados de uso dele. Um valor típico é true.
deliveryStatus informa à Apple se a compra chegou e funcionou. Um valor típico é DELIVERED.
sampleContentProvided informa à Apple se uma amostra gratuita ou teste estava disponível antes da compra. Um valor típico é true.
consumptionPercentage informa à Apple a parcela consumida, expressa em miliunidades, em que 100000 significa 100 por cento. Um valor típico é 67500.
refundPreference informa à Apple o resultado que você prefere, seja conceder, recusar ou não ter preferência. Um valor típico é DECLINE.
consumptionPercentage tem um escopo limitado: consumíveis, compras únicas e assinaturas não renováveis. Nas assinaturas de renovação automática, esse valor é calculado pela Apple com base no tempo decorrido dentro do período de cobrança, e qualquer valor que você informar é rejeitado.
O que a Apple faz com o que você envia
As informações de consumo são usadas pela Apple, de forma explícita, como um dado de entrada para a decisão sobre o reembolso. Se você não enviar nada, a decisão vem puramente do que o cliente afirmou mais o histórico da conta dele. Se você enviar evidências, reembolsos contestados são recusados com uma frequência real.
Construindo você mesmo o caminho de resposta, de ponta a ponta
Nada nessa sequência é segredo. Tudo isso, porém, precisa funcionar sem supervisão às três da manhã.
1. Faça as notificações chegarem
No App Store Connect, abra a página App Information do seu app e configure uma Production Server URL em App Store Server Notifications, escolhendo a Version 2. As solicitações de consumo não trafegam pela V1. A partir daí, toda notificação, incluindo reembolsos, chega a essa URL via POST como um payload JWS assinado.
2. Gere a chave correta
A autenticação das respostas usa uma In-App Purchase key, criada em Users and Access, na seção Integrations. É um tipo de chave distinto, e a App Store Connect API key que fica ao lado dela não autentica essas chamadas. O arquivo .p8 é baixado exatamente uma vez, e depois disso você gera um JWT ES256 de curta duração para cada requisição.
3. Verifique, associe e depois decida
As notificações CONSUMPTION_REQUEST que chegam precisam ter sua cadeia de assinatura JWS validada em relação aos certificados raiz da Apple antes que você confie em qualquer parte do conteúdo. Em seguida, associe a transação a um usuário, idealmente por meio do appAccountToken UUID que você anexou durante a compra, e recupere o uso real desse usuário. Depois, defina uma preferência: ceda nas situações de boa vontade, conteste aquelas em que o produto foi claramente consumido.
4. Envie antes que a janela se feche
Faça um PUT desses cinco campos para o endpoint Send Consumption Information, referente ao id dessa transação, dentro das 12 horas. Dois erros pegam quase todo mundo. As miliunidades regem o percentual, então 100% significa 100000, e não um milhão. E o consentimento é a porta de entrada de tudo, porque a própria documentação da Apple afirma que você não deve responder de forma alguma na ausência do consentimento do cliente. Coloque essa cláusula de consentimento nos seus termos de serviço antes de colocar qualquer parte disso no ar.
Por que tantos desenvolvedores desistem
Meio dia é um prazo punitivo para qualquer coisa operada por humanos. As notificações chegam às 3 da manhã de sábado. O que elas exigem é um servidor capaz de validar a cadeia de assinatura JWS da Apple, associar a transação a um usuário, calcular um percentual de consumo em miliunidades e chamar uma API autenticada por JWT. Para cada solicitação. Indefinidamente.
Na prática, o checklist é este:
Configure o App Store Server Notifications V2, sem o qual a solicitação nunca chega até você.
Valide o payload assinado em relação à cadeia de certificados da Apple antes de depositar qualquer confiança nele.
Associe a transação a um usuário no seu próprio sistema, normalmente via o appAccountToken anexado no momento da compra.
Calcule um percentual de consumo a partir do uso real registrado, em vez de uma estimativa.
Chame o Send Consumption Information usando uma In-App Purchase key enquanto a janela ainda estiver aberta.
O Refund Sensor existe para carregar esse peso, enviando uma resposta completa e embasada em evidências bem dentro da janela, sem que ninguém precise ser acordado.
Onde essas regras estão documentadas
Perguntas frequentes
O reembolso ainda é decidido, só que agora exclusivamente com base na alegação do cliente e no histórico da conta dele. Você perde a única chance disponível de demonstrar que a compra chegou e foi amplamente utilizada. Na prática, solicitações sem resposta são aprovadas com uma frequência consideravelmente maior.
É sim. customerConsented precisa ser true, e o acordo por trás dessa flag precisa ser genuíno, normalmente registrado em qualquer um dos seus documentos legais que trate do compartilhamento de dados. A própria orientação da Apple diz aos desenvolvedores para deixar a notificação completamente sem resposta quando esse consentimento não existir.
Somente para as do tipo não renovável. Nas assinaturas de renovação automática, o consumo é calculado pela Apple a partir do tempo decorrido dentro do período de cobrança atual, e a API rejeita qualquer percentual que você informar. Mesmo assim, sua preferência de reembolso continua tendo peso.
Uma In-App Purchase key, gerada no App Store Connect em Users and Access, na seção Integrations. Ela é diferente da App Store Connect API key, e seu arquivo .p8 só pode ser baixado uma única vez, no momento da criação.
Em produção, você tem 12 horas a partir da notificação. No sandbox, são apenas 5 minutos, o que funciona como um sinal bastante direto do que a Apple espera: automação, e não uma pessoa.
