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.
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.refundnão consegue reembolsar encomendas com mais de três anos. Comrevokea 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
voidedSourcedefinido como developer. Nas subscrições, recebe tantoSUBSCRIPTION_REVOKEDcomo umaVoidedPurchaseNotification. - 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:1subscrição,2produto único.refundType:1reembolso total,2reembolso 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:
startTimenão pode ser mais antigo do que isso. - Por defeito devolve apenas produtos únicos. Passe
type=1para incluir as subscrições. - Cada registo tem um
voidedReason:0Other,1Remorse,2Not_received,3Defective,4Accidental_purchase,5Fraud,6Friendly_fraud,7Chargeback,8Unacknowledged_purchase. - E um
voidedSource:0utilizador,1developer,2Google.
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:
- Recuperar os itens não usados, como moeda da app que tenha sido concedida.
- Avisos progressivos: um aviso na app num primeiro caso, medidas mais fortes nos casos repetidos.
- Desativar temporariamente as compras enquanto investiga.
- Restringir o acesso à sua app em casos extremos e repetidos.
- 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 comoSUBSCRIPTION_REVOKEDe 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.