Uma compra é efetivada, o cliente recebe o produto e, três dias depois, ele desaparece. O Google Play reverte a cobrança e retira o direito de acesso, sem o cliente pedir e sem que ninguém da sua equipe de suporte toque em um botão. A compra falhou silenciosamente porque seu servidor nunca avisou o Google de que ela havia sido processada.
Essa é a regra completa: confirme uma compra do Google Play dentro de três dias ou o Google a reembolsa automaticamente e a revoga. Sempre, sem exceções. Entre todas as formas pelas quais uma venda pode ser revertida em qualquer uma das lojas, essa é uma das raras que depende inteiramente da sua própria integração, o que também a torna uma das formas mais silenciosas de perder receita.
Não é uma verificação antifraude, nem uma decisão de política. É um callback que nunca foi disparado. A correção é pequena, mas o dinheiro que você perde ao ignorá-la não é, por isso vale a pena saber exatamente o que a regra diz, por que compras escapam dela e o que cada venda perdida leva consigo.
O que a documentação do Google realmente exige
O Play Billing exige que seu app notifique o Google depois de conceder o direito de acesso e informar ao usuário que a compra foi concluída. A documentação do Google estabelece um número exato para isso: essa notificação "precisa ser feita dentro de três dias para que a compra não seja reembolsada automaticamente e o direito de acesso, revogado." A documentação de produtos avulsos repete a mesma afirmação sem ressalvas. Pule a confirmação e "o usuário recebe automaticamente um reembolso, e o Google Play revoga a compra." A compra inicial de uma assinatura segue exatamente a mesma regra.
A confirmação não é burocracia. É o único sinal que o Google tem de que a entrega realmente aconteceu. Sem esse sinal, o Google assume que nada foi entregue e reverte toda a transação em favor do comprador sem consultar você. O comprador vê um reembolso inesperado. Você vê uma venda que desapareceu dos seus registros.
Principais pontos
Deixe uma venda sem confirmação por 72 horas e a reversão acontece sozinha: o comprador é reembolsado, o direito de acesso é retirado, e ninguém é consultado. Nenhum cliente provocou isso. Foi o seu backend, ao não dizer nada, e seu backend também é capaz de evitar isso.
Atingir o estado PURCHASED é o que dispara a contagem regressiva, o que torna o momento do checkout irrelevante para o seu prazo. Qualquer coisa que esteja em PENDING não tem nenhum temporizador associado e ainda não merece uma chamada de confirmação.
Qualquer uma das duas chamadas cumpre a obrigação. Execute purchases.products.consume em um item consumível, ou use purchases.products.acknowledge e purchases.subscriptions.acknowledge em qualquer item que não seja consumível. O Google trata cada uma dessas chamadas como prova de que o produto foi entregue.
As assinaturas exigem isso de você exatamente uma vez, no momento da assinatura. Todos os ciclos de cobrança seguintes são resolvidos pelo próprio Google, marcados como confirmados sem que seu código precise fazer nada.
Está vendendo um plano pré-pago com duração inferior a sete dias? Seu prazo cai para cinquenta por cento da duração do plano, qualquer que seja ela. Produto mais curto, prazo mais curto.
Só o valor da compra volta para o comprador. Tempo de computação, gastos com API de modelos, contas de armazenamento, pagamentos a criadores: esse dinheiro saiu da sua conta durante o cumprimento do pedido e nada dele retorna. O dano real é maior do que o que aparece na linha do reembolso.
No iOS, nada funciona assim. O StoreKit apresenta novamente uma transação não finalizada a cada abertura do app e espera pacientemente, sem nunca reverter a cobrança. Essa exposição específica existe apenas no Google Play.
O prazo não começa no checkout
Tocar em "comprar" não inicia o temporizador. O estado da compra precisa primeiro passar para PURCHASED, e algumas compras ficam em PENDING antes disso. Formas de pagamento em dinheiro fazem isso, assim como transferências bancárias lentas e solicitações de aprovação dos pais. O Google afirma isso diretamente: "A janela de confirmação de três dias só começa quando o estado da compra passa de PENDING para PURCHASED."
Isso significa duas coisas para como você constrói o fluxo. Conceda o direito de acesso somente quando o estado for PURCHASED, nunca em PENDING, ou você vai entregar o produto por um dinheiro que talvez nunca chegue. E também não confirme uma compra em PENDING, porque ainda não há nada a confirmar. Chame enablePendingPurchases() ao configurar o BillingClient, espere a transição de estado e só comece a contar o prazo quando ele chegar a PURCHASED.
Interprete PENDING como "ainda não vendido." Nada é devido: sem direito de acesso, sem confirmação, nada registrado como receita. No instante em que passa para PURCHASED, tanto o direito de acesso quanto a contagem regressiva de três dias se tornam problema seu.
Escolhendo a chamada de API certa para o que você vendeu
Dois caminhos de API cumprem o prazo, e qual deles se aplica depende do que você vendeu. Ambos satisfazem a exigência igualmente. O que os diferencia é o que cada um faz com o produto depois.
Itens consumíveis são consumidos. Isso é feito com purchases.products.consume em um backend seguro, ou consumeAsync() da Play Billing Library no cliente. Consumir cumpre uma função dupla, já que satisfaz a exigência de confirmação e torna o item disponível para compra novamente. É isso que você quer para moedas, créditos ou qualquer geração avulsa que um cliente possa comprar repetidamente.
Itens não consumíveis e assinaturas, em vez disso, são confirmados, por meio de purchases.products.acknowledge, purchases.subscriptions.acknowledge, ou acknowledgePurchase() no cliente. Isso cumpre o prazo, mas não reabre o item para compra.
Veja como cada tipo de produto corresponde a uma chamada e a um prazo:
Para um item consumível, chame purchases.products.consume ou consumeAsync(). Isso também torna o item disponível para compra novamente, e seu prazo é de três dias a partir de PURCHASED.
Para um item não consumível, chame purchases.products.acknowledge ou acknowledgePurchase(). O direito de acesso é confirmado sem possibilidade de recompra, e seu prazo é de três dias a partir de PURCHASED.
Para a compra inicial de uma assinatura, chame purchases.subscriptions.acknowledge ou acknowledgePurchase(). Isso confirma a nova assinatura, e seu prazo é de três dias a partir de PURCHASED.
Para uma renovação de assinatura, você não precisa fazer nenhuma chamada. O Google a marca como confirmada automaticamente, portanto não há prazo.
Para um plano pré-pago com menos de uma semana, use as mesmas chamadas de confirmação, mas seu prazo cai para a metade da duração do plano.
A obrigação termina no primeiro pagamento
Renovações de assinatura não precisam de confirmação alguma. O Google afirma isso diretamente: "você não precisa confirmar renovações de assinatura," e marca cada uma como confirmada automaticamente. É apenas a primeira compra de uma assinatura que chega em um estado de confirmação pendente e permanece sob sua responsabilidade até que você a resolva. Verifique o estado de confirmação no servidor, ou use isAcknowledged() no cliente, antes de agir. Assim, você nunca envia uma chamada de confirmação duplicada.
Um prazo mais curto para planos pré-pagos de curta duração
Planos pré-pagos de uma semana ou mais seguem a regra padrão de três dias. Os mais curtos, não. A documentação do Google afirma que planos "com duração inferior a uma semana devem ser confirmados dentro da metade da duração do plano." Um plano pré-pago de três dias dá a você um dia e meio, não a janela completa. Se recargas pré-pagas curtas fazem parte do seu catálogo, o caminho de confirmação precisa ser rápido e orientado pelo servidor, nunca dependente de o cliente reabrir o app.
Onde a chamada de confirmação costuma se perder
Ninguém pula essa etapa de propósito. Ela se perde porque a lógica de confirmação fica vinculada ao gatilho errado. O antipadrão comum é um cliente que só confirma quando o fluxo de compra volta para o primeiro plano. Isso cobre um cliente que termina a compra e continua usando o app logo depois. Não cobre mais ninguém.
Desenvolvedores se deparam com isso constantemente. Discussões na própria comunidade de desenvolvedores do Google seguem sempre o mesmo roteiro, alguma variação de um usuário sendo reembolsado automaticamente três dias após a compra, ou um pedido de ajuda para entender por que os pagamentos continuam se revertendo sozinhos no terceiro dia. O diagnóstico raramente muda: a chamada de confirmação estava vinculada a uma ação do usuário que nunca aconteceu, e por isso simplesmente nunca foi disparada.
Testes gratuitos e o cliente que nunca mais abre o app
A versão mais cruel disso é um teste gratuito, ou uma compra feita nos últimos instantes antes de alguém fechar seu app pela última vez. Quando a confirmação depende da próxima abertura do app e essa próxima abertura nunca acontece, a compra simplesmente expira. O Google a reembolsa e revoga no terceiro dia. Para um teste que estava no caminho de se converter, você perde a primeira cobrança que nunca chegou a fazer, e o direito de acesso do cliente evapora silenciosamente junto com ela. Nenhum dos dois aparece na sua fila de suporte. Ambos aparecem como uma compra anulada, caso você vá procurar.
Uma confirmação que depende da próxima abertura do app é uma venda que você perde toda vez que um cliente fica ausente por três dias. Testes gratuitos e compras com um toque são exatamente os momentos em que os clientes ficam ausentes.
A conta real por trás de um reembolso não confirmado
A linha de reembolso subestima o que você realmente perdeu. O Google reverte a venda, você devolve o valor, e esse é o número que todo mundo vê. Mas não é a conta completa.
Pense em um item consumível que dispara trabalho real no instante em que alguém o compra. Um lote de gerações de imagem, uma série de chamadas à API de um provedor de modelo, uma exportação de vídeo, um pagamento devido a um criador. Você pagou por aquele processamento, por aquelas chamadas de API, por aquele armazenamento e por aqueles pagamentos no momento do uso. O reembolso devolve o preço de venda ao cliente. Ele não devolve a fatura do provedor para você. O custo real saiu da sua conta e nada voltou em troca.
Para assinaturas e testes gratuitos, a perda é a primeira cobrança que você nunca recebe, somada a um relacionamento com o cliente que terminou antes de começar. E a aposta está prestes a aumentar. A partir de 3 de agosto de 2026, o Google Play transfere o preço de compra de chargebacks e as taxas bancárias para os desenvolvedores em pedidos feitos após essa data, o que torna qualquer vazamento evitável algo que vale a pena resolver agora, em vez de depois. Um reembolso não confirmado não é um chargeback, mas ensina a mesma lição. Dinheiro que você já gastou não é automaticamente dinheiro que você mantém.
Construindo a etapa de confirmação para que ela nunca seja perdida
O padrão confiável remove completamente seu app do caminho crítico. Execute-o no seu backend, orientado por notificações, não pelo fato de alguém reabrir uma tela.
Inscreva-se para receber notificações em tempo real para desenvolvedores. Um evento de compra de produto avulso, ou um evento de compra de assinatura, chega ao seu servidor no instante em que o Google registra a venda, esteja o app em execução ou não.
Valide o token de compra por meio da Play Developer API e confirme que o estado é PURCHASED, e não PENDING.
Registre o direito de acesso no seu próprio sistema, vinculado à conta daquele cliente.
Consuma ou confirme sem demora. Itens consumíveis são consumidos; itens não consumíveis e assinaturas iniciais são confirmados. Verifique o estado de confirmação antes, para que a chamada nunca seja enviada duas vezes.
Mantenha um mecanismo de reforço no lado do cliente. Chamar queryPurchasesAsync() em onResume() captura qualquer coisa que tenha se resolvido enquanto o app estava fechado. Trate isso como um seguro, não como a rota principal.
O ponto central é que a confirmação é disparada por um evento que o Google entrega a você, e não por uma ação do usuário que você não tem como garantir. Alguém que compra uma vez e nunca mais volta continua totalmente protegido, porque seu servidor já fez o trabalho no instante em que a compra foi registrada.
Uma rede de segurança para o que ainda passar
Não importa quão bem construído seja o pipeline, ele ainda merece uma rede de segurança por baixo. A Voided Purchases API do Google lista pedidos que terminaram em reembolso, revogação ou chargeback, e destaca especificamente o cenário em que a causa foi uma compra que "nunca foi confirmada pelo desenvolvedor e, portanto, pode não existir nos registros do desenvolvedor." Consulte-a com regularidade e você poderá remover o acesso de qualquer pessoa cujo pedido o Google tenha desfeito silenciosamente nos bastidores. Fique atento ao limite, porém: apenas os últimos 30 dias podem ser recuperados, o que torna isso uma tarefa agendada, e não algo que você resolve de vez em quando a cada trimestre.
O iOS nunca foi feito para fazer isso com você
Ao passar para a App Store, nada disso se aplica. A Apple criou sua própria etapa de encerramento, finalizar uma transação, só que a penalidade por pulá-la funciona no sentido contrário. Uma transação não finalizada permanece parada na fila da Apple. Ela reaparece a cada abertura do app, e novamente sempre que o observer é anexado, dando a você chances repetidas de entregar o que o cliente pagou. A Apple não emite nenhuma reversão por isso. Nada parecido com um gatilho de reembolso de 72 horas existe nessa plataforma.
É exatamente por isso que um único modelo mental não se aplica às duas lojas. O Android dá a você uma contagem regressiva e uma venda que evapora se você a perder. O iOS dá a você um lembrete persistente e tempo ilimitado para responder a ele. Traga hábitos do iOS para uma base de código Android e, mais tarde ou mais cedo, você vai se ver diante de uma pilha de pedidos revertidos que ninguém na equipe sabe explicar.
Fechar essa brecha é exatamente a função do Refund Sensor. A confirmação é disparada diretamente a partir da notificação da loja, em poucos instantes após ela chegar, enquanto uma passagem contínua de reconciliação contra a Voided Purchases API retira o acesso onde o Google já tenha desfeito um pedido pelas suas costas. Uma contagem regressiva que você poderia perder se torna uma caixa que já foi marcada antes mesmo de você pensar em verificar.
Onde essas regras estão documentadas
Perguntas frequentes
Seu servidor nunca enviou a chamada de confirmação a tempo. Quando uma compra permanece sem confirmação além da marca de três dias a partir do momento em que atinge o estado PURCHASED, o Google reverte a venda e retira o direito de acesso automaticamente. Não é algo que o cliente fez, nem uma penalidade imposta pelo Google. É uma chamada de confirmação ausente, e confirmar no servidor a partir da notificação da loja elimina o problema por completo.
Ambas interrompem a contagem de três dias, mas deixam o produto em estados diferentes. Consumir, por meio de purchases.products.consume ou consumeAsync(), é para itens consumíveis. Isso cumpre o prazo e coloca o item novamente disponível para venda. Confirmar, por meio de purchases.products.acknowledge, purchases.subscriptions.acknowledge, ou acknowledgePurchase(), é para itens não consumíveis e assinaturas. Isso confirma o direito de acesso sem liberar o produto para recompra.
Não, apenas a primeira compra. O Google não exige que as renovações sejam confirmadas e as marca como confirmadas automaticamente. É apenas a compra inicial da assinatura, que chega em um estado de confirmação pendente, que permanece sob sua responsabilidade até que você a resolva.
Não, espere pelo estado PURCHASED. Uma compra em PENDING, como um pagamento em dinheiro ou uma solicitação de aprovação dos pais, ainda nem iniciou a contagem de três dias. Conceda o direito de acesso e envie a confirmação somente depois que o estado realmente passar de PENDING para PURCHASED.
Não, e vale a pena saber isso antes de supor que Android e iOS se comportam da mesma forma. Uma transação não finalizada do StoreKit simplesmente é entregue novamente a cada abertura do app até que você a finalize. A Apple nunca a reembolsa automaticamente. O reembolso automático de três dias é exclusivo do Google Play, por isso as duas plataformas exigem tratamentos diferentes.
O reembolso em si não pode ser revertido. O que você pode fazer é reconciliar. A Voided Purchases API mostra compras reembolsadas e revogadas dos últimos 30 dias e sinaliza especificamente aquelas anuladas por nunca terem sido confirmadas, permitindo que você revogue o direito de acesso que concedeu. Daqui para frente, confirmar a partir da notificação da loja é o que impede que a próxima escape.
