Resposta rápida: Quando um cliente solicita à Apple um reembolso de uma compra no app ou assinatura, a App Store envia ao seu servidor uma notificação CONSUMPTION_REQUEST e dá a você aproximadamente 12 horas para responder com dados de consumo por meio do endpoint Send Consumption Information. A Apple pondera esses dados na sua decisão. Se você não responder a tempo, a Apple decide sem a sua participação, e reembolsos injustificados costumam ser concedidos por padrão. Automatizar essa resposta significa que toda solicitação é respondida dentro da janela, sempre.
A versão resumida
A Apple é dona dos trilhos de pagamento. Quando alguém compra uma assinatura ou uma compra no app, a Apple recebe o dinheiro, fica com a 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 informações de consumo, evidências estruturadas sobre como o cliente usou o que comprou, e as considera na decisão de reembolso. Você não aprova ou nega o reembolso diretamente; a Apple continua tomando a decisão final. Mas o silêncio não dá à Apple nada para trabalhar, e uma resposta bem formada oferece contexto.
O problema é o tempo de resposta e a consistência. A janela de reembolso é curta, o tempo de resposta para reembolso da Apple é limitado, ela abre em horários imprevisíveis, e fazer isso manualmente em qualquer volume real é impossível. Esse é o problema que a automação resolve.
Como o fluxo de reembolso da Apple realmente funciona
Aqui está a sequência, do início ao fim:
O cliente solicita um reembolso. Ele acessa reportaproblem.apple.com, escolhe a compra, seleciona um motivo e envia.
A Apple notifica o seu servidor. Para compras elegíveis, a App Store envia uma notificação CONSUMPTION_REQUEST por meio do App Store Server Notifications V2. O payload contém dados de transação assinados que identificam a compra.
Você responde com dados de consumo. Você chama o 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.
A Apple decide. O sistema de decisão de reembolso dela 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 pela API StoreKit) 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:
Aqui está a tabela reconstruída a partir da sua imagem:
Campo | O que informa à Apple |
customerConsented | Se o cliente concordou em compartilhar esses dados. Deve 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 app foi realmente entregue. |
accountTenure | Há quanto tempo o cliente tem uma conta com você. |
playTime | Quanto tempo o cliente passou no app. |
lifetimeDollarsPurchased | Total que o cliente já gastou em todos os seus apps. |
lifetimeDollarsRefunded | Total já reembolsado ao cliente anteriormente. |
sampleContentProvided | Se o cliente pôde testar 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. |
Sua recomendação à Apple: undeclared, prefer grant ou prefer decline.
Cada campo é um sinal. Se deixado em branco, é contexto que a Apple nunca recebe. Detalhamos cada campo e seus valores aceitos em What Is a CONSUMPTION_REQUEST Notification? A Field-by-Field Breakdown.
A janela de 12 horas
Você tem cerca de 12 horas para responder a um CONSUMPTION_REQUEST em produção. Esse prazo do consumption_request é crítico, porque perdê-lo significa abrir mão da chance de dar sua contribuição; a Apple decide com o que já tem.
O problema não é a duração da janela de resposta de reembolso da Apple, é o momento em que ela abre. As solicitações de reembolso não esperam o horário comercial. A janela de reembolso pode abrir durante a madrugada, em um fim de semana ou em 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 os desenvolvedores perdem reembolsos que poderiam ter contestado: não é uma resposta ruim, é a falta de resposta. Vamos a fundo nesse tema em The 12-Hour Window: Why Most Developers Lose Refunds by Default.
O requisito de consentimento, não pule esta parte
Esta é a parte que confunde 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 app, e não o seu servidor, colete e confirme o consentimento antes do envio de qualquer dado de consumo. 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 compartilha os dados coletados do usuário.
Se você errar nisso, não corre apenas o risco de ter o envio rejeitado, mas também o risco de um problema de conformidade com a GDPR ou a DPDP. Trate o consentimento corretamente nos termos do seu app e no fluxo de compra antes de automatizar qualquer coisa. Cobrimos exatamente onde e como em Customer Consent & the Consumption API: What Apple Actually Requires.
O que automatizar isso realmente exige
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 faz a diferença entre "vamos construir isso" e "vamos deixar passar".
Um respondente interno confiável precisa receber e verificar as notificações assinadas da Apple, buscar dados de uso e cobrança precisos e atualizados na hora para cada cliente no instante em que a solicitação chega, mapear esses dados para os valores exatos do ConsumptionRequest da Apple, e enviá-los dentro da janela de resposta de reembolso da Apple de ~12 horas, a qualquer hora, sem ninguém de olho. Além disso, precisa de novas tentativas seguras dentro do prazo, tratamento de falhas, registros que você possa auditar, monitoramento para saber se algo quebra, e manutenção contínua sempre que a Apple revisar 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 app faz. (Vamos a fundo na camada de notificações em Setting Up App Store Server Notifications V2.)
Essa é a conta que a maioria das equipes acaba fazendo: a mecânica é conhecível, mas construir e vigiar um respondente compatível e seguro em relação ao prazo é um custo permanente sem nenhum benefício para o app em si. É exatamente o tipo de "tubulação" indiferenciada para a 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 mudanças no código, sem necessidade de reenviar o app, e então responde a todo CONSUMPTION_REQUEST automaticamente dentro da janela de reembolso da Apple, mapeia os campos a partir dos seus dados, gerencia novas tentativas e monitoramento, se mantém atualizado com as mudanças da Apple e registra cada resultado em um único dashboard. Para equipes em busca de um software de automação de reembolso da Apple, isso elimina a necessidade de construir e manter toda a infraestrutura de resposta a reembolsos por conta própria.
Responder realmente reduz os reembolsos?
Sim, embora os resultados variem e a Apple sempre decida. Enviar dados de consumo precisos dá mais contexto ao sistema da Apple, 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 uma informação que a Apple considera.
Responder dentro do tempo de resposta para reembolso da Apple pode, portanto, ajudar a garantir que a Apple receba suas informações antes do prazo do consumption_request. Isso não garante um resultado, mas evita que uma resposta perdida seja o motivo pelo qual suas informações não foram consideradas.
O que a automação pode e não pode fazer
Seja honesto consigo mesmo sobre o limite:
Não pode garantir que um reembolso específico seja negado. A Apple toma a decisão final, sempre.
Não pode contestar reembolsos que nunca geram um CONSUMPTION_REQUEST, nem todo reembolso gera um.
Pode garantir que toda solicitação elegível seja respondida dentro da janela de resposta de reembolso da Apple, com dados consistentes e precisos, para que você nunca perca um reembolso simplesmente porque ninguém viu a notificação.
Pode automatizar como responder às solicitações de reembolso da Apple em até 12 horas, reduzindo o risco de perder o prazo do consumption_request.
É nesse último ponto que está o verdadeiro valor. Você não está substituindo a Apple, está garantindo que sempre terá a sua vez de falar.
Por que o tratamento manual não consegue fechar essa lacuna
Equipes que tentam lidar com isso manualmente geralmente acabam em uma de três situações:
A abordagem "vamos checar de manhã" — que perde todas as solicitações noturnas e de fim de semana, ou seja, uma grande parte delas.
O esquema de plantão — alguém tecnicamente responsável por uma tarefa de janela de 12 horas 24 horas por dia, o que é um trabalho exaustivo e ainda assim sujeito a erro humano.
A abordagem "desistimos" — a maioria silenciosa, que parou de responder porque acompanhar o ritmo era impossível.
O ponto em comum: o prazo tem a velocidade de uma máquina, e a resposta tem a velocidade humana. Você não consegue ter mais disciplina do que um relógio que continua correndo enquanto você dorme. Toda abordagem manual é, na verdade, apenas escolher quais solicitações vai perder.
Isso é um problema de tempo de resposta, não um problema de produto
A mudança de perspectiva que importa: perder esses reembolsos não diz nada sobre o seu app.
Você pode ter um ótimo produto, usuários satisfeitos e uma taxa real de reembolso baixa, e ainda assim perder receita por causa dessa janela, porque as perdas não têm a ver com se o reembolso era merecido. Elas têm a ver com se havia alguém ali para responder. Essa é, de certa forma, uma boa notícia. Um problema de produto é difícil de resolver. Um problema de tempo de resposta tem uma solução simples: garantir que haja sempre algo pronto para responder, instantaneamente, independentemente do horário.
O que realmente resolve isso
A única coisa que consegue fechar uma janela na velocidade de uma máquina é uma resposta na velocidade de uma máquina. A automação responde a todo CONSUMPTION_REQUEST no momento em que ele chega, com dados de consumo precisos e a sua preferência de reembolso, dentro da janela da Apple, às 3h de um domingo com exatamente a mesma confiabilidade de às 15h de uma terça-feira.
É isso que o RefundSensor faz. Ele monitora todas as solicitações de reembolso, responde automaticamente dentro da janela e acompanha o resultado, para que você nunca mais perca um reembolso simplesmente porque ninguém viu a notificação. A configuração leva cerca de 30 minutos, sem mudanças no código, e também cobre a janela de revisão de chargeback do Google Play, que tem o mesmo problema de "abre quando quer, fecha rápido". (Para o panorama completo, veja How to Automate Apple Refund Requests e Google Play Refunds & Chargebacks.)
[PLACEHOLDER DE DADOS DO PRODUTO insira aqui uma estatística real do RefundSensor quando o Refund Index estiver disponível, por exemplo, a porcentagem de solicitações que chegam fora do horário comercial, ou o valor em dinheiro defendido. NÃO invente um número.]
Você não está burlando a Apple. Você só está garantindo que sempre terá a sua vez de falar, a vez que a maioria dos desenvolvedores perde sem nem perceber.
Fontes oficiais {#official-sources}
O tempo e o processo da Apple podem mudar, então trate a documentação dela como a autoridade final:
A janela abre sempre que seus clientes quiserem. Esteja presente de qualquer forma. O RefundSensor responde a toda solicitação de reembolso da Apple automaticamente, dentro da janela de 12 horas, às 3h, fins de semana e feriados inclusive, e acompanha cada resultado. Cerca de 30 minutos para configurar, sem mudanças no código. Comece gratuitamente →
Links internos a adicionar após a publicação: Apple refund automation cornerstone · CONSUMPTION_REQUEST field-by-field · Google Play refunds cornerstone.
Perguntas frequentes
Cerca de 12 horas em produção, a contar do momento em que o cliente envia a solicitação. Se você perder esse prazo, a Apple decide sem a sua participação.
A Apple segue com as informações que tem, que são a solicitação do cliente e nada vindo de você. Solicitações sem resposta, incluindo as injustificadas, costumam ser concedidas por padrão.
Não. A janela é definida pela Apple. A única forma confiável de sempre cumprir o prazo é responder automaticamente, no momento em que a solicitação chega.
Geralmente não é por causa do mérito, mas do tempo de resposta. As solicitações chegam fora do horário comercial e um processo manual não consegue responder a todas a tempo, então reembolsos contestáveis são perdidos por padrão.
Não. A Apple sempre toma a decisão final. A automação garante que você responda sempre; ela não substitui a decisão da Apple.
