Resposta rápida: O Google Play oferece duas formas de você saber que uma compra foi reembolsada ou revogada. As Real-time Developer Notifications (RTDN) enviam eventos para o seu servidor no momento em que acontecem, via Google Cloud Pub/Sub. A Voided Purchases API permite que você obtenha uma lista de compras anuladas sob demanda. Elas não são alternativas entre si: a RTDN oferece velocidade, a Voided Purchases API oferece uma rede de segurança, e uma configuração confiável usa as duas para que nada passe despercebido.
Por que o Google oferece dois mecanismos
No Google Play, a maioria dos reembolsos acontece sem que você seja consultado: o Google os emite, revoga o direito de uso, e seu trabalho é descobrir isso para que seu app e suas análises permaneçam precisos. (Para saber o que você pode e não pode contestar, veja Google Play Refunds & Chargebacks.)
O Google oferece duas ferramentas diferentes para descobrir isso, e elas resolvem o problema a partir de direções opostas. Uma envia eventos para você no momento em que acontecem. A outra permite que você solicite uma lista sempre que quiser. Usadas juntas, elas cobrem as fraquezas uma da outra; usadas isoladamente, cada uma tem uma lacuna.
Para desenvolvedores focados no rastreamento de reembolso no Android, entender essa diferença é importante porque um fluxo de eventos em tempo real e um mecanismo de reconciliação histórica resolvem partes diferentes do problema de monitoramento de reembolsos.
Real-time Developer Notifications (push)
As Real-time Developer Notifications (RTDN) são o mecanismo push. Quando algo acontece com uma assinatura ou compra, incluindo reembolsos e compras anuladas, o Google publica um evento em um tópico do Google Cloud Pub/Sub ao qual seu backend está inscrito. O objetivo é a imediatez: você fica sabendo do evento próximo ao momento em que ele ocorre, em vez de descobri-lo horas depois.
Para desenvolvedores em busca de integração de RTDN no Google Play, esse é o mecanismo que conecta os eventos de cobrança do Google Play ao seu backend. Para qualquer coisa sensível ao tempo, como uma revisão de chargeback, em que você tem aproximadamente 24 horas para responder, essa imediatez é tudo. Se você depende de verificações periódicas, já perdeu um tempo que não tinha.
O detalhe: a RTDN funciona sobre o Pub/Sub, o que significa configuração de projeto no Google Cloud, um tópico, as permissões corretas de publicação para o Google Play e um subscriber do seu lado. São mais peças em movimento do que um único webhook, e é aí que muitos desenvolvedores travam.
A Voided Purchases API (pull)
A Google Play Voided Purchases API é o mecanismo pull. Ela retorna uma lista de pedidos que foram anulados, reembolsados, contestados via chargeback ou revogados, que você pode consultar sob demanda. Em vez de esperar por um evento, você pergunta diretamente ao Google: o que foi anulado?
Seu ponto forte é a completude e a recuperação. Se uma notificação push foi atrasada, perdida ou nunca processada, uma consulta à Google Play Voided Purchases API revela a compra anulada mesmo assim. É assim que você reconcilia e garante que seu registro corresponda ao do Google.
A contrapartida é que, por natureza, ela não é instantânea: é algo que você consulta, então, por si só, funciona como uma rede de segurança, e não como um gatilho.
Por que você precisa das duas, não de apenas uma
Aqui está a distinção que confunde as pessoas: isso não é uma decisão de "escolher a melhor".
A RTDN isoladamente oferece velocidade, mas nenhuma garantia de completude: perca ou trate mal uma notificação e esse evento simplesmente desaparece do seu campo de visão.
A Voided Purchases API isoladamente oferece completude, mas não velocidade: você só saberia de um reembolso na próxima vez que fizesse uma consulta.
A RTDN no Google Play dá ao seu backend um sinal em tempo real, enquanto a Google Play Voided Purchases API fornece a camada de reconciliação para eventos perdidos ou atrasados.
Uma configuração confiável usa a RTDN como gatilho em tempo real e a Voided Purchases API como a camada de reconciliação que captura qualquer coisa que o caminho push tenha perdido. Velocidade mais uma rede de segurança. Qualquer uma delas isoladamente deixa uma brecha pela qual você acabará caindo.
Onde isso se complica
Configurar isso corretamente é mais trabalhoso do que parece, e o esforço é contínuo, não pontual:
Provisionamento do Pub/Sub. Criar o tópico, conceder ao Google Play o direito de publicar, inscrever seu backend e acertar exatamente as permissões é a etapa com mais chances de consumir uma tarde ou três. Essa configuração de Pub/Sub Play Billing também precisa continuar confiável à medida que sua infraestrutura de cobrança cresce.
Dois sistemas para manter sincronizados. Agora você está operando um consumidor push e um job agendado de pull e reconciliação, e precisa garantir que eles concordem entre si.
Deduplicação e ordenação. O mesmo evento pode chegar até você mais de uma vez, ou fora de ordem; seu tratamento precisa ser idempotente.
Manter-se atualizado. O Google revisa APIs de cobrança e tipos de eventos, e sua integração precisa acompanhar o ritmo ou ficará desatualizada silenciosamente.
Notificações de reembolso do Google Play. Seu sistema precisa processar corretamente cada notificação relevante de reembolso do Google Play e conectá-la à compra, ao direito de uso e ao registro de cliente corretos.
Individualmente, nada disso é exótico. Juntos, formam uma peça real de infraestrutura para construir e manter, pelo privilégio de rastrear com precisão reembolsos que, na maioria das vezes, você nem pode contestar.
Como isso se encaixa no tratamento de reembolsos
Juntando as peças, o tratamento de reembolsos do Google Play tem duas partes: capturar a única coisa que você pode contestar (a revisão de chargeback) dentro do prazo, e registrar com precisão tudo o que você não pode, para que seus direitos de uso e suas análises permaneçam corretos. As duas partes dependem de uma base sólida de RTDN + Voided Purchases.
Para equipes que se perguntam como rastrear reembolsos do Google Play com RTDN e Voided Purchases API, a resposta é usar a RTDN para detecção rápida de eventos e a Voided Purchases API para reconciliação e recuperação. Isso dá ao seu backend uma visão mais completa de reembolsos, compras anuladas e chargebacks.
É exatamente essa camada que o RefundSensor gerencia para você. Ele provisiona automaticamente o tópico Pub/Sub para que você só precise colar um nome de tópico no Play Console, consome a RTDN em tempo real, reconcilia com as compras anuladas para que nada seja perdido, envia uma recomendação de recusa em revisões de chargeback dentro do prazo e registra todos os outros reembolsos, tudo em um único dashboard, junto com seus reembolsos da Apple. Você obtém o resultado de uma configuração correta com dois mecanismos sem precisar construir ou manter nenhum dos dois.
Fontes oficiais {#official-sources}
As APIs de cobrança do Google mudam, então trate sua documentação como a autoridade final:
Uma configuração, dois mecanismos, manutenção zero. O RefundSensor provisiona automaticamente o Pub/Sub, consome a RTDN em tempo real, reconcilia com as compras anuladas e cuida das revisões de chargeback para Google Play e Apple, em um único dashboard. Comece gratuitamente →
Links internos a adicionar após a publicação: Google Play refunds cornerstone · Apple refund automation cornerstone · a janela de 12 horas.
Perguntas frequentes
A RTDN envia eventos para o seu servidor em tempo real via Pub/Sub; a Voided Purchases API permite que você obtenha uma lista de pedidos anulados sob demanda. A RTDN oferece velocidade, a Voided Purchases API oferece completude.
Para uma configuração confiável, sim. A RTDN é seu gatilho em tempo real, e a Voided Purchases API é sua rede de segurança de reconciliação para tudo o que o caminho push deixou passar. Cada uma isoladamente deixa uma lacuna.
Um pedido que não é mais válido, geralmente devido a um reembolso, chargeback ou revogação. Rastrear compras anuladas mantém seus direitos de uso e suas análises precisos.
A RTDN funciona sobre o Google Cloud Pub/Sub, então envolve um tópico, permissões de publicação para o Google Play e um subscriber do seu lado, ou seja, mais peças em movimento do que simplesmente colar uma única URL. O RefundSensor provisiona automaticamente o tópico Pub/Sub para eliminar esse atrito.
Na maioria das vezes, não. Reembolsos e revogações comuns são decididos pelo Google. O único caso contestável é um chargeback em revisão, que você deve capturar via RTDN e responder dentro da janela de aproximadamente 24 horas.
