Resposta rápida: Quando um cliente pede à Apple um reembolso de uma compra no aplicativo ou assinatura, a App Store envia ao seu servidor uma notificação CONSUMPTION_REQUEST e concede aproximadamente 12 horas para você responder com dados de consumo pelo endpoint Send Consumption Information. A Apple pondera esses dados em sua decisão. Se você não responder a tempo, a Apple decide sem sua contribuição e reembolsos injustificados costumam ser concedidos por padrão. Automatizar essa resposta significa que toda solicitação é respondida dentro do prazo, sempre.
A versão resumida
A Apple controla os trilhos de pagamento. Quando alguém compra uma assinatura ou faz uma compra no aplicativo, a Apple recebe o dinheiro, fica com sua parte e cuida dos reembolsos. Por anos, os desenvolvedores não tiveram voz alguma nas decisões de reembolso.
Isso mudou. Agora a Apple permite que você envie consumption information evidências estruturadas sobre como o cliente usou o que comprou e considera isso na decisão de reembolso. Você não pode aprovar ou negar o reembolso sozinho; a Apple ainda toma a decisão final. Mas o silêncio não dá à Apple nada para trabalhar, e uma resposta bem estruturada fornece contexto.
A pegadinha está no tempo e na consistência. O prazo é curto, abre em horários imprevisíveis, e fazer isso manualmente em qualquer volume real é impossível. É esse o problema que a automação de reembolso da Apple resolve.
Como o fluxo de reembolso da Apple realmente funciona
Aqui está a sequência completa, de ponta a ponta:
O cliente solicita um reembolso. Ele acessa reportaproblem.apple.com, seleciona a compra, escolhe um motivo e envia a solicitação.
A Apple notifica seu servidor. Para compras elegíveis, a App Store envia uma notificação CONSUMPTION_REQUEST por meio das App Store Server Notifications V2. O payload contém dados de transação assinados que identificam a compra. Essas app store server notifications são o que disparam o fluxo de trabalho automatizado.
Você responde com dados de consumo. Você chama o endpoint Send Consumption Information com o ID da transação original e um corpo ConsumptionRequest estruturado descrevendo entrega, uso, consentimento e sua preferência de reembolso. O endpoint send consumption information é a etapa principal da API nesse processo.
A Apple decide. Seu sistema de decisão de reembolso pondera seus dados junto com o histórico do cliente e outros fatores, e então emite uma decisão.
Você é notificado do resultado. Uma notificação REFUND significa que o reembolso foi concedido; uma notificação REFUND_DECLINED (para solicitações iniciadas via StoreKit API) significa que não foi.
O que um CONSUMPTION_REQUEST contém e o que você envia de volta
A própria notificação carrega informações de transação assinadas e o motivo declarado pelo cliente (consumptionRequestReason). Sua resposta é onde o trabalho real acontece. A Apple define um ConsumptionRequest estruturado com campos que incluem:
Campo | O que isso informa à Apple |
customerConsented | Se o cliente concordou em compartilhar esses dados. Precisa ser true, ou a Apple rejeita o envio. |
consumptionStatus | Se o conteúdo comprado não foi consumido, foi parcialmente consumido ou totalmente consumido. |
deliveryStatus | Se o valor ou serviço do aplicativo foi realmente entregue. |
accountTenure | Há quanto tempo o cliente tem uma conta com você. |
playTime | Quanto tempo o cliente passou no aplicativo. |
lifetimeDollarsPurchased | Total que o cliente gastou em todos os seus aplicativos. |
lifetimeDollarsRefunded | Total já reembolsado ao cliente. |
sampleContentProvided | Se o cliente pôde experimentar o conteúdo antes de comprar. |
userStatus | O status atual da conta do cliente (ativa, suspensa, etc.). |
refundPreference | Sua recomendação à Apple: undeclared, prefer grant ou prefer decline. |
Cada campo é um sinal. Deixado em branco, é um contexto que a Apple nunca recebe. Detalhamos cada campo e seus valores aceitos em O Que É uma Notificação CONSUMPTION_REQUEST? Um Detalhamento Campo a Campo. Desenvolvedores que estão avaliando uma api de reembolso da Apple também devem entender como esses campos se encaixam no fluxo completo de reembolso.
A janela de 12 horas
Você tem cerca de 12 horas para responder a um CONSUMPTION_REQUEST em produção. Se perder esse prazo, você renuncia à chance de fornecer informações; a Apple decide com o que já tem.
O problema não é a duração da janela é quando ela se abre. Solicitações de reembolso não esperam o horário comercial. A janela pode abrir de madrugada, em um fim de semana ou durante um feriado, e uma fila de revisão manual não consegue cobrir isso sem alguém de prontidão o tempo todo. Esse é o motivo mais comum pelo qual desenvolvedores perdem reembolsos que poderiam ter contestado: não uma resposta ruim, mas nenhuma resposta. Vamos a fundo nisso em A Janela de 12 Horas: Por Que a Maioria dos Desenvolvedores Perde Reembolsos por Padrão.
O requisito de consentimento não pule esta etapa
Essa é a parte que trava quase todo mundo, e é uma questão legal, não apenas técnica.
O CONSUMPTION_REQUEST da Apple não informa se o cliente consentiu em compartilhar seus dados. Isso é intencional a Apple espera que o seu aplicativo, não seu servidor, colete e confirme o consentimento antes que qualquer dado de consumo seja enviado. Você precisa definir customerConsented como true na sua chamada de API, e você, o desenvolvedor, é o único responsável por ter obtido um consentimento válido, porque é você quem está compartilhando dados coletados do usuário.
Erre nisso e você não corre apenas o risco de ter o envio rejeitado você corre o risco de um problema de conformidade com a GDPR ou a DPDP. Trate o consentimento corretamente nos termos do seu aplicativo e no fluxo de compra antes de automatizar qualquer coisa. Mostramos exatamente onde e como em Consentimento do Cliente e a Consumption API: O Que a Apple Realmente Exige.
O que realmente é preciso para automatizar isso
No papel, automatizar a resposta parece um projeto de fim de semana: capturar a notificação, preencher os campos, chamar o endpoint. Na prática, é uma peça permanente de infraestrutura e entender o que realmente está envolvido é a diferença entre "vamos construir isso" e "vamos pular isso."
Um respondente interno confiável precisa receber e verificar as notificações assinadas da Apple, extrair dados de uso e cobrança precisos e atualizados no momento para cada cliente no instante em que a solicitação chega, mapear esses dados para os valores exatos do ConsumptionRequest da Apple, e enviar tudo dentro da janela de ~12 horas, a qualquer hora, sem ninguém de vigia. Além disso, precisa de tentativas automáticas seguras quanto ao prazo, tratamento de falhas, registros (logs) que possam ser auditados, monitoramento para você saber se algo quebra, e manutenção contínua a cada vez que a Apple revisa seus payloads ou campos. Nada disso é o seu produto. Tudo isso é infraestrutura que você teria que manter indefinidamente para um fluxo de trabalho que não tem nada a ver com o que o seu aplicativo faz. (Vamos a fundo na camada de notificações em Configurando as App Store Server Notifications V2.)
É esse o cálculo que a maioria das equipes acaba fazendo: a mecânica é conhecível, mas construir e cuidar de um respondente compatível e seguro quanto ao prazo é um custo permanente sem nenhum benefício para o aplicativo em si. É exatamente o tipo de trabalho repetitivo e indiferenciado para o qual existe um serviço gerenciado.
É isso que o RefundSensor faz. Ele se conecta à sua configuração do App Store Connect com uma única URL de webhook sem SDK, sem alterações de código, sem reenvio do aplicativo para avaliação então responde automaticamente a todo CONSUMPTION_REQUEST dentro do prazo da Apple, mapeia os campos a partir dos seus dados, lida com tentativas automáticas e monitoramento, se mantém atualizado com as mudanças da Apple e registra cada resultado em um único dashboard. Você obtém o resultado de um respondente bem construído sem precisar construí-lo ou mantê-lo. Para equipes em busca de um software de automação de reembolso da Apple, isso oferece uma alternativa gerenciada à manutenção do fluxo de trabalho internamente.
Responder realmente reduz os reembolsos?
Sim, embora os resultados variem e a Apple sempre decida. Enviar dados de consumo precisos dá ao sistema da Apple mais contexto, e desenvolvedores que respondem de forma consistente geralmente veem menos reembolsos concedidos do que desenvolvedores que deixam solicitações sem resposta. Escolher uma recomendação "prefer decline", quando suas evidências realmente a sustentam, é mais um fator que a Apple considera. Isso pode ser especialmente relevante ao gerenciar um fluxo de reembolso de assinatura em grande escala.
O que a automação pode e não pode fazer
Seja honesto consigo mesmo sobre o limite:
Ela não pode garantir que um reembolso específico seja negado. A Apple sempre toma a decisão final.
Ela não pode contestar reembolsos que nunca geram um CONSUMPTION_REQUEST — nem todo reembolso gera um.
Ela pode garantir que toda solicitação elegível seja respondida dentro do prazo, com dados consistentes e precisos, para que você nunca perca um reembolso simplesmente porque ninguém viu a notificação.
É nesse último ponto que está o verdadeiro valor. Você não está anulando a Apple você está garantindo que sempre terá sua vez de falar.
Para detalhes específicos, trate os próprios materiais da Apple como a autoridade final:
O setor levou 15 anos para conquistar aos desenvolvedores uma voz nos reembolsos. Use-a sempre. O RefundSensor responde automaticamente às notificações CONSUMPTION_REQUEST da Apple dentro do prazo e acompanha cada resultado, para Apple e Google Play.Comece gratuitamente
Perguntas frequentes
É uma App Store Server Notification que a Apple envia ao seu servidor quando um cliente solicita um reembolso em uma compra no aplicativo ou assinatura elegível. É o sinal para você responder com dados de consumo que a Apple vai considerar em sua decisão de reembolso.
Cerca de 12 horas em produção. Se você não responder a tempo, a Apple decide sem sua contribuição, e solicitações não respondidas costumam ser aprovadas por padrão.
Não. Você pode enviar um refundPreference recomendando a recusa, mas a Apple sempre toma a decisão final. A automação melhora suas chances ao garantir que dados precisos sejam enviados sempre, mas não te dá poder de veto.
Sim. Você precisa obter o consentimento válido dentro do seu aplicativo e definir customerConsented como true. A Apple não coleta isso por você, e enviar dados sem consentimento cria um risco de conformidade com privacidade pelo qual você é responsável.
Não. A resposta ao CONSUMPTION_REQUEST acontece no lado do servidor, por meio das App Store Server Notifications e da Consumption API. Com o RefundSensor, você cola uma URL de webhook no App Store Connect, sem SDK, sem alterações de código, sem reenvio para avaliação.
A Apple segue adiante sem seus dados. Você perde a única chance de fornecer contexto, e reembolsos, incluindo os injustificados, ficam mais propensos a serem concedidos.
