Não confirme uma compra do Google Play em três dias e o Google a reembolsa, veja o que isso custa a você

Um cliente compra seu produto, a cobrança é aprovada e três dias depois o Google Play a reembolsa silenciosamente e retira o que você entregou. Ninguém pediu esse reembolso. O cliente não o solicitou e nenhum agente de suporte o concedeu. Ele disparou porque seu servidor nunca disse ao Google que a compra foi tratada. Se você não confirmar uma compra do Google Play em três dias, o Google reembolsa o comprador e revoga a compra, sempre. É um dos poucos reembolsos em qualquer uma das lojas que depende inteiramente da sua integração para ser evitado, e uma das maneiras mais silenciosas de perder receita.

Isso não é um problema de fraude nem uma disputa de política. É um callback perdido. A correção é pequena e o custo de pulá-la é dinheiro real, então vale a pena conhecer a regra com exatidão, por que as compras ficam sem confirmação e o que cada venda perdida realmente leva consigo.

O que a regra dos três dias realmente diz

A documentação do Play Billing do Google é direta sobre isso. Depois que seu app concede o direito e diz ao usuário que a compra foi bem-sucedida, ele precisa notificar o Google de que a compra foi processada. Nas palavras do Google, isso "deve ser feito dentro de três dias para que a compra não seja reembolsada automaticamente e o direito revogado". A página do produto único repete isso sem suavizar: "Se você não confirmar uma compra em três dias, o usuário recebe automaticamente um reembolso e o Google Play revoga a compra". As assinaturas seguem a regra idêntica para a compra inicial.

A confirmação é um sinal, não uma formalidade. Ela diz ao Google que o direito chegou ao usuário. O Google trata a ausência desse sinal como uma entrega que nunca aconteceu, e desfaz a transação em nome do cliente. Do lado do comprador parece um reembolso gratuito que ele nunca pediu. Do seu lado parece uma venda que evaporou.

O relógio começa em PURCHASED, não no checkout

A janela de três dias não começa quando o usuário toca em comprar. Ela começa quando o estado da compra passa para PURCHASED. Uma compra pode ficar primeiro em PENDING, o que acontece com pagamentos em dinheiro, transferências bancárias lentas ou um pai aprovando o pedido de um filho. O Google é explícito: "A janela de confirmação de três dias começa somente quando o estado da compra passa de PENDING para PURCHASED".

Isso tem duas consequências. Conceda o direito apenas quando o estado for PURCHASED, nunca em PENDING, ou você entregará o produto por um pagamento que pode nunca se concretizar. E também não confirme uma compra em PENDING. Você chama enablePendingPurchases() quando constrói o BillingClient, espera a transição e só então começa a contar o relógio de confirmação na sua cabeça.

Confirmar ou consumir, e qual você deve

Há duas formas de cumprir o requisito, e qual você usa depende do produto. Ambas cumprem o prazo de três dias. A diferença é o que mais elas fazem.

Para um consumível, você o consome. Em um backend seguro isso é purchases.products.consume, ou no lado do cliente consumeAsync() na Play Billing Library. Consumir confirma a compra e ao mesmo tempo torna o produto comprável novamente, que é exatamente o que você quer para moedas, créditos ou uma geração única. Para um não consumível ou uma assinatura, você o confirma: purchases.products.acknowledge ou purchases.subscriptions.acknowledge no backend, ou acknowledgePurchase() no lado do cliente. Confirmar cumpre o prazo sem liberar o produto para uma nova compra.

As renovações já estão tratadas, as compras iniciais não

Você só deve confirmar a primeira compra de uma assinatura. O Google afirma claramente que "você não precisa confirmar as renovações de assinatura", e carimba as renovações como ACKNOWLEDGEMENT_STATE_ACKNOWLEDGED por conta própria. Uma nova compra chega como ACKNOWLEDGEMENT_STATE_PENDING e continua sendo sua responsabilidade até você resolvê-la. Antes de confirmar, verifique acknowledgementState no backend ou isAcknowledged() no lado do cliente para não confirmar duas vezes.

Planos pré-pagos têm um pavio mais curto

Planos de assinatura pré-pagos apertam a janela. A regra do Google: planos pré-pagos que duram uma semana ou mais devem ser confirmados em três dias, mas "planos pré-pagos com duração menor que uma semana devem ser confirmados dentro da metade da duração do plano". Um plano pré-pago de três dias lhe dá um dia e meio, não três dias. Se você vende recargas pré-pagas curtas, seu caminho de confirmação tem que ser rápido e conduzido pelo servidor, não depender de o usuário reabrir o app.

Por que as compras ficam sem confirmação em primeiro lugar

Ninguém se propõe a pular a confirmação. Ela escapa porque o código que confirma está no lugar errado. O antipadrão comum é um cliente que confirma apenas quando o fluxo de compra retorna em primeiro plano. Isso funciona para um usuário que termina de comprar e continua usando o app. Falha com todos os outros.

Os desenvolvedores esbarram nisso constantemente. As threads na própria comunidade de desenvolvedores do Google se leem da mesma forma toda vez, alguma variante de "um usuário foi reembolsado automaticamente depois de comprar no meu app após três dias" e "por que os pagamentos são reembolsados automaticamente após três dias". A resposta é quase sempre a mesma: a chamada de confirmação nunca disparou porque o app nunca esteve em um estado para dispará-la.

O teste gratuito e o usuário que nunca volta

A pior versão é o teste gratuito ou uma compra logo antes de o usuário fechar o app de vez. Se sua confirmação depende da próxima abertura do app, e não há próxima abertura, a compra vence. No terceiro dia o Google a reembolsa e a revoga. Para um teste que teria se convertido em uma assinatura paga, você perde a primeira cobrança que nunca chegou a coletar, além de um direito de cliente que desapareceu silenciosamente. Nenhum dos dois aparece como um ticket de suporte. Aparece como uma compra anulada que você tem que ir procurar.

O que um reembolso sem confirmação realmente custa

A linha do reembolso subestima a perda. Quando o Google reverte a venda, você devolve o preço, e esse é o número visível. Não é a conta inteira.

Pense em um consumível que dispara trabalho real no momento em que é comprado. Um lote de gerações de imagens, uma sequência de chamadas à API de um provedor de modelos, uma exportação de vídeo, um pagamento a um criador. Você pagou por esse processamento, essas chamadas de API, esse armazenamento e esses pagamentos no momento do uso. O reembolso devolve o preço de venda ao cliente. Ele não devolve a fatura do provedor a você. Você entregou um custo real e não recebeu nada em troca.

Para assinaturas e testes, a perda é a primeira cobrança que você nunca coleta e a relação com o cliente que terminou antes de começar. E a partir de 3 de agosto de 2026, o Google Play transfere para os desenvolvedores o preço de compra dos estornos e as taxas bancárias em pedidos feitos após essa data, o que torna qualquer vazamento de receita evitável algo que vale a pena fechar agora, em vez de depois. Um reembolso sem confirmação não é um estorno, mas é a mesma lição: o dinheiro que você já gastou não é automaticamente dinheiro que você mantém.

Como confirmar uma compra do Google Play no lado do servidor

O padrão confiável tira o app do caminho crítico. Faça isso no seu backend, conduzido por notificações, não por o usuário reabrir a tela.

• Escute as Real-time developer notifications. Um evento de compra ONE_TIME_PRODUCT ou SUBSCRIPTION_PURCHASED diz ao seu servidor que uma compra existe no instante em que o Google sabe, esteja o app aberto ou não.
• Verifique o token de compra contra a Play Developer API e confirme que o estado é PURCHASED, não PENDING.
• Conceda o direito nos seus próprios registros, vinculado ao usuário.
• Confirme ou consuma imediatamente. Consuma os consumíveis, confirme os não consumíveis e as assinaturas iniciais. Verifique acknowledgementState primeiro para nunca confirmar duas vezes.
• Complemente também no cliente. Chame queryPurchasesAsync() em onResume() para que qualquer compra concluída enquanto o app estava fechado ainda seja processada. Isso é uma rede de segurança, não o caminho principal.

O ponto é que a confirmação dispara a partir de um evento que o Google envia a você, não de uma ação do usuário com a qual você não pode contar. Um usuário que compra e nunca volta fica totalmente coberto porque seu servidor agiu no momento em que a compra chegou.

Uma rede de reconciliação para as que escapam

Até um pipeline limpo se beneficia de uma verificação. A Voided Purchases API lista as compras que foram reembolsadas, revogadas ou estornadas, e nomeia o caso em que o motivo é que a compra "nunca foi confirmada pelo desenvolvedor e, portanto, pode não existir nos registros do desenvolvedor". Consulte-a e você pode revogar o direito que concedeu para qualquer coisa que o Google já tenha desfeito. Observe o limite: a API só retorna compras anuladas dos últimos 30 dias, então a reconciliação tem que rodar em um cronograma, não uma vez por trimestre.

A Apple não tem um equivalente, e isso importa

Este é um problema específico do Google Play. O StoreKit da Apple também tem um passo de finalização, finalizar uma transação, mas ele faz o oposto em caso de falha. Se você nunca finalizar uma transação do StoreKit, a Apple a mantém na fila e a reentrega toda vez que seu app é iniciado ou o observer se conecta, então você ganha outra chance de conceder o direito. A Apple não reembolsa uma transação não finalizada. Não há reembolso automático de três dias na App Store.

Então o modelo mental tem que continuar sendo específico de cada plataforma. No Google Play, uma compra não tratada é um reembolso prestes a acontecer e um prazo contra o qual você está correndo. Na App Store, uma compra não tratada é uma reentrega prestes a acontecer e nenhum relógio. Transferir a suposição da Apple para o Android é como as equipes acabam com uma parede de reembolsos sem confirmação que não conseguem explicar.

É por isso que o RefundHalt confirma as compras do Google Play automaticamente no momento em que a notificação da loja chega, e as reconcilia contra a Voided Purchases API para que um direito concedido por uma compra que o Google depois desfez não permaneça ativo. A regra dos três dias deixa de ser uma corrida que você pode perder e se torna um passo que já aconteceu.