CHARGEBACKSGOOGLE PLAY

Reembolsos e compras anuladas no Google Play: o que fazer com eles

Reembolsos, revogações e chargebacks nas subscrições do Google Play: notificações de compras anuladas, a Voided Purchases API e revisões de reembolso.

Publicado a 6 min de leitura

No Google Play, o dinheiro pode voltar para um subscritor de várias formas: o utilizador recebe um reembolso, o comerciante reembolsa-o a partir da Play Console ou da API, uma compra nunca é confirmada (acknowledged) ou o pagamento é alvo de chargeback. A Google agrupa todos estes casos num só termo: uma compra anulada (voided purchase). Se concede acesso ou créditos a partir do seu próprio backend, precisa de saber de cada uma delas.

Este guia explica onde aparecem as compras anuladas, o que a Google lhe diz sobre cada uma, a revisão de reembolso mais recente para os chargebacks e como responder. Baseia-se apenas na documentação da Google: a referência das notificações de developer em tempo real, as boas práticas de segurança sobre compras anuladas, o tratamento de compras rejeitadas, o ciclo de vida das subscrições e a referência da Google Play Developer API para compras anuladas, orders.refund e orders.reviewrefund (todos consultados em novembro de 2026).

O que conta como compra anulada

A página de segurança da Google define as compras anuladas como “compras que foram canceladas, revogadas ou alvo de chargeback”, e lista as principais causas:

  • A compra é cancelada pelo utilizador, pelo developer ou pela Google, incluindo compras canceladas automaticamente por nunca terem sido confirmadas. Nas subscrições, isto significa cancelar a própria compra, e não apenas desativar a renovação.
  • A compra é alvo de chargeback.
  • O developer cancela ou reembolsa uma encomenda e assinala a opção “revoke”.

Um cancelamento normal de subscrição (o utilizador para a renovação) não é uma compra anulada. É um evento SUBSCRIPTION_CANCELED, e o utilizador mantém o acesso até ao fim do período.

Reembolsar, revogar ou ambos

Tem três ações, e fazem coisas diferentes:

Ação API Dinheiro Acesso
Só reembolsar orders.refund sem revoke Reembolsado Mantido
Reembolsar e revogar orders.refund com revoke=true, ou purchases.subscriptionsv2.revoke com reembolso total Reembolsado Terminado de imediato
Cancelar purchases.subscriptionsv2.cancel Não reembolsado Mantido até ao fim do período

Pontos da documentação da Google que vale a pena conhecer:

  • orders.refund não consegue reembolsar encomendas com mais de três anos. Com revoke a true, o acesso termina de imediato e, numa subscrição recorrente, todos os pagamentos futuros param.
  • O guia de integração da Google diz que as revogações pelo developer e os reembolsos com revogação desencadeiam notificações e aparecem na Voided Purchases API com voidedSource definido como developer. Nas subscrições, recebe tanto SUBSCRIPTION_REVOKED como uma VoidedPurchaseNotification.
  • Um reembolso sem revogação “não desencadeia uma notificação de revogação nem de compra anulada.” Se o usar, registe-o por si.
  • Se não confirmar uma nova subscrição no prazo de três dias, o utilizador é reembolsado automaticamente e a compra é revogada. A Google pede que não conte com isto para rejeitar compras: revogue e reembolse explicitamente.

Onde aparecem as compras anuladas

Em tempo real: VoidedPurchaseNotification

Se a sua app no Play tiver as notificações de developer em tempo real ativadas, uma compra anulada chega como uma voidedPurchaseNotification com:

  • purchaseToken: a compra que foi anulada.
  • orderId: a encomenda exata. Nas subscrições, cada renovação tem o seu próprio ID de encomenda, por isso isto diz-lhe que pagamento foi anulado.
  • productType: 1 subscrição, 2 produto único.
  • refundType: 1 reembolso total, 2 reembolso parcial por quantidade (só compras com várias unidades).

A Google nota que isto chega para “localizar a compra e a encomenda certas para ajustar os direitos de acesso.” Nas subscrições, uma revogação envia também uma notificação de subscrição SUBSCRIPTION_REVOKED; o guia do ciclo de vida diz para revogar imediatamente o direito de acesso do utilizador nesse caso.

Em lote: a Voided Purchases API

purchases.voidedpurchases.list é uma API de consulta. Segundo a referência da API:

  • Cobre os últimos 30 dias: startTime não pode ser mais antigo do que isso.
  • Por defeito devolve apenas produtos únicos. Passe type=1 para incluir as subscrições.
  • Cada registo tem um voidedReason: 0 Other, 1 Remorse, 2 Not_received, 3 Defective, 4 Accidental_purchase, 5 Fraud, 6 Friendly_fraud, 7 Chargeback, 8 Unacknowledged_purchase.
  • E um voidedSource: 0 utilizador, 1 developer, 2 Google.

Os códigos de motivo são a parte mais útil, porque a notificação não os inclui. Uma ressalva da página de segurança: as compras anuladas “sem qualquer conteúdo de recuperação associado não são expostas pela Voided Purchases API.”

Use as duas: a notificação para agir em segundos, e uma consulta diária à API para obter os motivos e apanhar o que lhe tenha escapado.

Chargebacks: a revisão de reembolso

A Google acrescentou uma forma de os developers darem a sua opinião sobre alguns chargebacks. Quando um utilizador pede um chargeback que precisa de revisão do developer, recebe uma pendingRefundReviewNotification. Segundo a referência das RTDN, deve avaliar o pedido e enviar “uma sugestão de reembolso e provas de utilização da compra no prazo de 24 horas” chamando orders.reviewrefund. As revisões pendentes suportam atualmente apenas CHARGEBACK como motivo.

O corpo do pedido, segundo a referência da API:

Campo Significado
pendingRefundToken Vem da notificação; obrigatório
refundPreference APPROVE, DECLINE ou NEUTRAL; obrigatório
sampleContentProvided Se ofereceu uma amostra gratuita, um teste ou uma descrição antes da compra; obrigatório
consumptionPercentageMilliunits Opcional, de 0 a 100 000 (45 200 significa 45,2%)
consumptionUsageEvents Lista opcional de eventos de utilização (hora, descrição do item, endereço IP, localização, ID de conta ou de perfil ofuscado); listas com mais de 1000 itens são rejeitadas

A notificação inclui o obfuscatedAccountId e o obfuscatedProfileId se os tiver definido na compra. Sem eles, vai ter dificuldade em encontrar a utilização do utilizador em 24 horas.

Seja verdadeiro. Se o utilizador não conseguiu usar o que pagou, APPROVE é a resposta certa. Se usou a subscrição durante todo o período, um DECLINE com eventos de utilização concretos é exatamente para o que o campo serve.

O que fazer com cada compra anulada

O guia de segurança da Google recomenda, consoante o motivo e o histórico do utilizador:

  1. Recuperar os itens não usados, como moeda da app que tenha sido concedida.
  2. Avisos progressivos: um aviso na app num primeiro caso, medidas mais fortes nos casos repetidos.
  3. Desativar temporariamente as compras enquanto investiga.
  4. Restringir o acesso à sua app em casos extremos e repetidos.
  5. Consultar a Voided Purchases API com mais frequência depois de detetar compras anuladas.

Para uma app de subscrição, uma política prática é esta:

Motivo Resposta sugerida
Compra acidental, arrependimento Terminar o acesso para o período reembolsado; sem aviso. Talvez pedir feedback
Não recebido, defeituoso Tratar como um bug do produto; investigar a conta do utilizador
Compra não confirmada Corrigir o seu processamento de compras; o bug é seu, não do utilizador
Fraude, friendly fraud, chargeback Terminar o acesso, assinalar a conta, bloquear novas compras até à revisão

Erros comuns

  • Tratar apenas SUBSCRIPTION_CANCELED. Significa “parar a renovação”, não “reembolsado”. As revogações chegam como SUBSCRIPTION_REVOKED e notificações de compra anulada.
  • Reembolsar sem revogar e esquecer-se. Nenhuma notificação o vai lembrar.
  • Consultar a API menos do que uma vez por mês. Tudo o que tem mais de 30 dias desaparece da API.
  • Nenhum ID de conta ofuscado. Não consegue responder a tempo a uma revisão de reembolso se não conseguir encontrar o utilizador.
  • Castigar os reembolsos por arrependimento como se fossem fraude. Os códigos de motivo existem para os poder distinguir.

Fazer isto com o NoChurn

O NoChurn lê as suas notificações de developer em tempo real do Google Play e a Voided Purchases API, para que os reembolsos, as revogações e os chargebacks apareçam na cronologia de cada cliente com o respetivo motivo e alimentem a pontuação de churn. No Google Play, os reembolsos são só de leitura no NoChurn: as decisões de reembolso e as revisões de reembolso ficam consigo e com a Google, e os pagamentos e as novas tentativas ficam com a Google. Para associar as compras aos clientes, defina um ID de conta ofuscado na compra. Veja NoChurn + Google Play.

PROMPT

Read https://www.nochurn.sh/llms.txt,
then follow https://www.nochurn.sh/docs/quickstart/
to add NoChurn to this app. Use a test key
(nc_test_…) until I say we go live.

Pare de perder receita.

  • Grátis até $300 de MRR
  • Sem cartão
  • Pronto em 10 minutos
  • Nunca uma comissão sobre o que recuperamos