Perder notificações de reembolso pode custar os únicos reembolsos que você pode contestar, e as duas lojas permitem recuperá-las se você olhar a tempo

Perder notificações de reembolso é o jeito silencioso de um desenvolvedor perder as duas únicas decisões de reembolso em que ele tem voz. O CONSUMPTION_REQUEST da Apple e a revisão de chargeback do Google Play começam com uma notificação, e os dois se encerram em prazo curto: 12 horas na Apple, 24 horas no Google. Se o seu servidor estiver fora do ar, lento ou mal configurado quando a mensagem chegar, a loja não espera por você. Ela decide com o que já tem.

A boa notícia é que nenhuma das lojas descarta a mensagem na primeira falha. A Apple tenta de novo e mantém um histórico de 180 dias que você pode consultar. O Google publica pelo Pub/Sub, que guarda mensagens não confirmadas por dias. A má notícia é que o tempo das novas tentativas não se alinha com as janelas de resposta, e um dos dois fluxos não tem API de recuperação nenhuma.

Como cada loja entrega as notificações de reembolso

A Apple envia as App Store Server Notifications direto para uma URL HTTPS que você define no App Store Connect. O Google não chama seu servidor diretamente. Ele publica as notificações do desenvolvedor em tempo real (Real-time developer notifications) em um tópico do Google Cloud Pub/Sub, e sua assinatura nesse tópico envia as mensagens para o seu endpoint ou espera o seu servidor buscá-las.

O que a Apple considera falha

A documentação da Apple é específica. Retorne qualquer status de 200 a 206 e a entrega está concluída. Retorne um 40x ou 50x e a Apple tenta de novo. A Apple também considera malsucedido qualquer outro código. Cada tentativa é registrada com um sendAttemptResult, e os valores parecem uma lista de quedas reais: TIMED_OUT, TLS_ISSUE, CIRCULAR_REDIRECT, NO_RESPONSE, PREMATURE_CLOSE, UNSUCCESSFUL_HTTP_RESPONSE_CODE e alguns outros. Para TIMED_OUT, o próprio conselho da Apple é verificar se o seu servidor não está processando as mensagens de forma síncrona.

O que o Google considera falha

Em uma assinatura push, um código de resposta de sucesso do seu endpoint é a confirmação. Em uma assinatura pull, seu servidor precisa confirmar cada mensagem que busca, ou o Pub/Sub a entrega de novo. O prazo de confirmação padrão é de 10 segundos e o máximo é de 600 segundos. O guia de RTDN do Google acrescenta uma regra que vale repetir: uma notificação só diz que algo mudou, então você ainda precisa chamar a Google Play Developer API para obter o estado completo da compra.

Por que o calendário de novas tentativas da Apple não cabe na janela de 12 horas

Os intervalos de nova tentativa da Apple são contados a partir da tentativa anterior, não da primeira. Somando tudo, você tem esta linha do tempo para uma única notificação V2 que o seu servidor continua sem receber.

A Apple pede que você responda em até 12 horas após receber o CONSUMPTION_REQUEST. Se o seu servidor estiver fora do ar na primeira entrega e na nova tentativa uma hora depois, a tentativa seguinte chega 13 horas após a primeira. A Apple não diz se uma solicitação recebida pela primeira vez em uma nova tentativa ganha 12 horas novas. A leitura cautelosa é tratar a primeira tentativa como o início do prazo, o que significa que as novas tentativas sozinhas não salvam uma solicitação que você perdeu por mais de uma hora.

A Apple tenta de novo depois de um HTTP 400?

Sim, segundo a documentação. A Apple lista 40x e 50x como os códigos que disparam uma nova tentativa. Em março de 2026, um desenvolvedor relatou nos fóruns da Apple que as novas tentativas após respostas 400 pareciam ter parado, depois disse que as entregas voltaram um ou dois dias mais tarde, e a Apple pediu um relato pelo Feedback Assistant. Trate o comportamento documentado como a regra e o seu próprio monitoramento como a prova.

Recupere notificações perdidas da App Store com o Get Notification History

O Get Notification History retorna as notificações da versão 2 que a Apple tentou enviar ao seu servidor no intervalo que você escolher. Cada registro traz o payload assinado completo, então você pode passá-lo para o mesmo handler de uma notificação ao vivo. Cada registro também inclui um array sendAttempts com até seis entradas, uma para a primeira tentativa e uma para cada uma das cinco novas tentativas.

• startDate e endDate são obrigatórios, e o startDate precisa estar dentro dos últimos 180 dias em produção ou dos últimos 30 dias no sandbox.
• Defina onlyFailures como true para obter só as notificações que não chegaram ao seu servidor, mais as que a Apple ainda está tentando de novo.
• Filtre por um notificationType, como CONSUMPTION_REQUEST ou REFUND, ou por um transactionId de um único cliente, mas não pelos dois na mesma solicitação.
• Cada chamada retorna até 20 registros. Continue chamando com o paginationToken enquanto hasMore for true, e envie o mesmo corpo de solicitação toda vez.

Uma ressalva importa para reembolsos. A Apple diz que os registros do histórico refletem o estado de uma compra quando a notificação foi enviada pela primeira vez, não agora. Então um REFUND recuperado é um fato sobre o passado. Antes de revogar o acesso, confira o estado atual com os endpoints de transação ou de status de assinatura.

Notificações V1 não podem ser recuperadas assim

O Get Notification History só cobre a versão 2. A Apple tenta de novo as notificações V1 três vezes, 6, 24 e 48 horas após a tentativa anterior, e se todas falharem não há histórico para reprocessar. É mais um motivo para migrar para a V2 qualquer app que ainda esteja na V1.

Recupere notificações de reembolso perdidas do Google Play

A rede de segurança do Google é o próprio Pub/Sub. Enquanto sua assinatura existir, uma mensagem que ninguém confirmou fica lá durante o período de retenção, 7 dias por padrão e até 31 dias se você aumentar. Quando o seu endpoint volta, a entrega é retomada. Duas configurações podem anular isso sem alarde.

• Um tópico de mensagens mortas (dead-letter) tira uma mensagem da sua assinatura após um número definido de tentativas de entrega com falha. O padrão é 5, e com a política de nova tentativa padrão de reenvio imediato, cinco tentativas podem passar rápido. Se você usa um, vigie esse tópico como uma segunda caixa de entrada.
• Uma assinatura sem atividade de assinantes, como conexões abertas, pulls ativos ou pushes bem-sucedidos, expira após 31 dias por padrão. Um endpoint que fica quebrado por um mês pode perder a própria assinatura, junto com tudo o que estava esperando nela.

Reembolsos anulados têm um backup de 30 dias

Para reembolsos que já aconteceram, a Voided Purchases API é o backup por pull. Ela lista as compras anuladas dos últimos 30 dias, até 1.000 por página, com cota de 6.000 consultas por dia e 30 consultas em qualquer período de 30 segundos por app. Passe type 1 para incluir assinaturas junto com produtos de compra única. Rodar a consulta todo dia pega qualquer reembolso que o seu pipeline de notificações deixou cair, o que mantém corretos os direitos de acesso e os números de receita.

Revisões de chargeback não têm

Uma PendingRefundReviewNotification é diferente. Ela traz o pendingRefundToken que você precisa passar para orders.reviewrefund, e você tem 24 horas a partir do recebimento para enviar sua preferência de reembolso e suas evidências de uso. O Google registra a sua primeira chamada e ignora as demais. A documentação do Google não descreve nenhum endpoint que liste revisões pendentes, então, se essa mensagem do Pub/Sub se perder, suas evidências para aquele chargeback se perdem junto.

Quanto custa em dinheiro uma notificação de reembolso perdida

Uma notificação perdida de um reembolso que já é definitivo custa trabalho contábil. Você a encontra depois na Voided Purchases API ou no Get Notification History, revoga o acesso se a sua política pedir, e os seus relatórios se atualizam. Chato, mas barato.

Uma notificação perdida em um dos dois fluxos contestáveis custa dinheiro de verdade, porque a loja decide sem as suas evidências. Na Apple, isso significa que a decisão de reembolso é tomada sem os seus dados de consumo. No Google Play, para pedidos feitos após 3 de agosto de 2026, um chargeback perdido custa o preço da compra menos a taxa de serviço do Play, mais a taxa de chargeback cobrada pelo banco do comprador. O Google cobre só a própria taxa de serviço.

E o dinheiro que você gastou para entregar a compra já tinha ido embora antes de a disputa começar.

• Computação: tempo de GPU e de servidor por trás de cada geração, renderização ou resposta de modelo que o comprador já usou.
• Chamadas de API: requisições a terceiros cobradas no momento em que foram feitas, muitas vezes por chamada.
• Armazenamento: arquivos e mídias que o comprador criou, ainda na sua conta de hospedagem.
• Repasses: participações na receita já pagas a criadores, afiliados ou parceiros por aquela venda.

Nada disso volta quando um reembolso é aprovado. As evidências que você envia nessas 12 ou 24 horas são a única alavanca que você tem, e uma notificação perdida tira isso de você.

Uma rotina de recuperação que se sustenta

• Confirme primeiro. Guarde o payload bruto, retorne um código de sucesso e só depois processe em uma fila.
• Consulte o Get Notification History da Apple com onlyFailures a cada poucos minutos para CONSUMPTION_REQUEST, para que uma queda custe minutos da janela de 12 horas.
• Rode diariamente uma varredura do Get Notification History com onlyFailures cobrindo os últimos dias para todos os tipos, e reprocesse o que encontrar.
• Rode diariamente uma chamada à Voided Purchases API com type 1 para cada app do Google Play, e concilie com os reembolsos que você já registrou.
• No Pub/Sub, mantenha a retenção de mensagens em 7 dias ou mais, crie alertas para o tópico de mensagens mortas se tiver um, e alerte quando mensagens não entregues se acumularem.
• Teste o caminho inteiro em produção também. O sandbox da Apple envia cada notificação uma única vez, sem novas tentativas, e Request a Test Notification com Get Test Notification Status mostram exatamente como o seu servidor respondeu.

O RefundHalt recebe as notificações das duas lojas por você e responde automaticamente ao CONSUMPTION_REQUEST e às revisões de chargeback dentro dos prazos, para que não seja você quem fica de olho no relógio.