Non confermi un acquisto Google Play entro tre giorni e Google lo rimborsa, ecco cosa ti costa

Un cliente compra il tuo prodotto, l'addebito va a buon fine, e tre giorni dopo Google Play lo rimborsa in silenzio e ritira ciò che hai consegnato. Nessuno ha chiesto quel rimborso. Il cliente non lo ha richiesto e nessun agente di supporto lo ha concesso. È scattato perché il tuo server non ha mai detto a Google che l'acquisto era stato gestito. Se non confermi un acquisto Google Play entro tre giorni, Google rimborsa l'acquirente e revoca l'acquisto, ogni volta. È uno dei pochi rimborsi su entrambi gli store che dipende interamente dalla tua integrazione per essere evitato, e uno dei modi più silenziosi per perdere ricavi.

Non è un problema di frode né una disputa sulle policy. È una callback mancata. La correzione è piccola e il costo di saltarla è denaro reale, quindi vale la pena conoscere la regola con esattezza, capire perché gli acquisti restano senza conferma e cosa si porta via davvero ogni vendita persa.

Cosa dice davvero la regola dei tre giorni

La documentazione Play Billing di Google è netta al riguardo. Dopo che la tua app concede il diritto e dice all'utente che l'acquisto è riuscito, deve notificare a Google che l'acquisto è stato elaborato. Nelle parole di Google, questo "deve essere fatto entro tre giorni affinché l'acquisto non venga rimborsato automaticamente e il diritto revocato". La pagina del prodotto una tantum lo ripete senza addolcirlo: "Se non confermi un acquisto entro tre giorni, l'utente riceve automaticamente un rimborso e Google Play revoca l'acquisto". Gli abbonamenti seguono la regola identica per l'acquisto iniziale.

La conferma è un segnale, non una formalità. Dice a Google che il diritto ha raggiunto l'utente. Google tratta l'assenza di quel segnale come una consegna che non è mai avvenuta, e annulla la transazione per conto del cliente. Dal lato dell'acquirente sembra un rimborso gratuito che non ha mai chiesto. Dal tuo lato sembra una vendita evaporata.

Il conto alla rovescia parte a PURCHASED, non al pagamento

La finestra di tre giorni non inizia quando l'utente tocca compra. Inizia quando lo stato dell'acquisto passa a PURCHASED. Un acquisto può prima restare in PENDING, cosa che accade con i pagamenti in contanti, i bonifici bancari lenti o un genitore che approva la richiesta di un figlio. Google è esplicito: "La finestra di conferma di tre giorni inizia solo quando lo stato dell'acquisto passa da PENDING a PURCHASED".

Questo ha due conseguenze. Concedi il diritto solo quando lo stato è PURCHASED, mai in PENDING, altrimenti consegni il prodotto per un pagamento che potrebbe non completarsi mai. E non confermare nemmeno un acquisto in PENDING. Chiami enablePendingPurchases() quando costruisci il BillingClient, aspetti la transizione, e solo allora il conto alla rovescia della conferma inizia a scorrere nella tua testa.

Confermare o consumare, e quale ti spetta

Ci sono due modi per soddisfare il requisito, e quale usi dipende dal prodotto. Entrambi rispettano la scadenza dei tre giorni. La differenza è cosa fanno d'altro.

Per un consumabile, lo consumi. Su un backend sicuro è purchases.products.consume, o lato client consumeAsync() nella Play Billing Library. Consumare conferma l'acquisto e allo stesso tempo rende il prodotto di nuovo acquistabile, che è esattamente ciò che vuoi per monete, crediti o una generazione una tantum. Per un non consumabile o un abbonamento, lo confermi: purchases.products.acknowledge o purchases.subscriptions.acknowledge sul backend, o acknowledgePurchase() lato client. Confermare rispetta la scadenza senza liberare il prodotto per un nuovo acquisto.

I rinnovi sono già gestiti, gli acquisti iniziali no

Devi confermare solo il primo acquisto di un abbonamento. Google afferma chiaramente che "non è necessario confermare i rinnovi dell'abbonamento", e marchia i rinnovi come ACKNOWLEDGEMENT_STATE_ACKNOWLEDGED da solo. Un nuovo acquisto arriva come ACKNOWLEDGEMENT_STATE_PENDING e resta tua responsabilità finché non lo risolvi. Prima di confermare, controlla acknowledgementState sul backend o isAcknowledged() lato client per non confermare due volte.

I piani prepagati hanno una miccia più corta

I piani di abbonamento prepagati stringono la finestra. La regola di Google: i piani prepagati che durano una settimana o più devono essere confermati entro tre giorni, ma "i piani prepagati con una durata inferiore a una settimana devono essere confermati entro metà della durata del piano". Un piano prepagato di tre giorni ti dà un giorno e mezzo, non tre giorni. Se vendi ricariche prepagate brevi, il tuo percorso di conferma deve essere veloce e guidato dal server, non dipendere dal fatto che l'utente riapra l'app.

Perché gli acquisti restano senza conferma in primo luogo

Nessuno si propone di saltare la conferma. Sfugge perché il codice che conferma si trova nel posto sbagliato. L'anti-pattern comune è un client che conferma solo quando il flusso di acquisto torna in primo piano. Funziona per un utente che finisce di comprare e continua a usare l'app. Fallisce con tutti gli altri.

Gli sviluppatori ci sbattono contro di continuo. I thread nella stessa community di sviluppatori di Google si leggono allo stesso modo ogni volta, una variante di "a un utente è stato rimborsato automaticamente dopo aver acquistato dalla mia app dopo tre giorni" e "perché i pagamenti vengono rimborsati automaticamente dopo tre giorni". La risposta è quasi sempre la stessa: la chiamata di conferma non è mai scattata perché l'app non è mai stata in uno stato per farla scattare.

La prova gratuita e l'utente che non torna mai

La versione peggiore è la prova gratuita o un acquisto proprio prima che l'utente chiuda l'app per sempre. Se la tua conferma dipende dalla prossima apertura dell'app, e non c'è una prossima apertura, l'acquisto scade. Al terzo giorno Google lo rimborsa e lo revoca. Per una prova che si sarebbe convertita in un abbonamento a pagamento, perdi la prima fatturazione che non sei mai riuscito a incassare, più un diritto del cliente scomparso in silenzio. Nessuno dei due appare come un ticket di supporto. Appare come un acquisto annullato che devi andare a cercare.

Quanto costa davvero un rimborso senza conferma

La voce del rimborso sottostima la perdita. Quando Google annulla la vendita, restituisci il prezzo, e quello è il numero visibile. Non è l'intera fattura.

Pensa a un consumabile che innesca lavoro reale nel momento in cui viene acquistato. Un lotto di generazioni di immagini, una serie di chiamate all'API di un fornitore di modelli, un'esportazione video, un pagamento a un creator. Hai pagato per quel calcolo, quelle chiamate API, quell'archiviazione e quei pagamenti al momento dell'uso. Il rimborso restituisce il prezzo di vendita al cliente. Non ti restituisce la fattura del fornitore. Hai consegnato un costo reale e non hai ricevuto nulla in cambio.

Per gli abbonamenti e le prove, la perdita è la prima fatturazione che non incassi mai e la relazione con il cliente che è finita prima di iniziare. E a partire dal 3 agosto 2026, Google Play sposta sugli sviluppatori il prezzo di acquisto degli storni e le commissioni bancarie per gli ordini effettuati dopo quella data, il che rende qualsiasi perdita di ricavi evitabile qualcosa che conviene chiudere ora invece che dopo. Un rimborso senza conferma non è uno storno, ma è la stessa lezione: il denaro che hai già speso non è automaticamente denaro che trattieni.

Come confermare un acquisto Google Play lato server

Il pattern affidabile toglie l'app dal percorso critico. Fallo sul tuo backend, guidato dalle notifiche, non dal fatto che l'utente riapra la schermata.

• Ascolta le Real-time developer notifications. Un evento di acquisto ONE_TIME_PRODUCT o SUBSCRIPTION_PURCHASED dice al tuo server che un acquisto esiste nell'istante in cui Google lo sa, che l'app sia aperta o no.
• Verifica il token di acquisto contro la Play Developer API e conferma che lo stato è PURCHASED, non PENDING.
• Concedi il diritto nei tuoi registri, associato all'utente.
• Conferma o consuma immediatamente. Consuma i consumabili, conferma i non consumabili e gli abbonamenti iniziali. Controlla prima acknowledgementState per non confermare mai due volte.
• Integra anche sul client. Chiama queryPurchasesAsync() in onResume() così che qualsiasi acquisto completato mentre l'app era chiusa venga comunque elaborato. Questa è una rete di sicurezza, non il percorso principale.

Il punto è che la conferma scatta da un evento che Google ti invia, non da un'azione dell'utente su cui non puoi contare. Un utente che compra e non torna mai è completamente coperto perché il tuo server ha agito nel momento in cui l'acquisto è arrivato.

Una rete di riconciliazione per quelli che sfuggono

Anche una pipeline pulita beneficia di un controllo. La Voided Purchases API elenca gli acquisti che sono stati rimborsati, revocati o stornati, e nomina il caso in cui il motivo è che l'acquisto "non è mai stato confermato dallo sviluppatore, e quindi potrebbe non esistere nei registri dello sviluppatore". Interrogala e potrai revocare il diritto che hai concesso per qualsiasi cosa che Google abbia già annullato. Nota il limite: l'API restituisce solo gli acquisti annullati degli ultimi 30 giorni, quindi la riconciliazione deve girare secondo una pianificazione, non una volta a trimestre.

Apple non ha un equivalente, e questo conta

Questo è un problema specifico di Google Play. Lo StoreKit di Apple ha anch'esso un passo di finalizzazione, finalizzare una transazione, ma fa l'opposto in caso di errore. Se non finalizzi mai una transazione StoreKit, Apple la tiene in coda e la riconsegna ogni volta che la tua app si avvia o l'observer si collega, così hai un'altra possibilità di concedere il diritto. Apple non rimborsa una transazione non finalizzata. Non c'è un rimborso automatico di tre giorni sull'App Store.

Quindi il modello mentale deve restare specifico per ogni piattaforma. Su Google Play, un acquisto non gestito è un rimborso in procinto di verificarsi e una scadenza contro cui stai correndo. Sull'App Store, un acquisto non gestito è una riconsegna in procinto di verificarsi e nessun conto alla rovescia. Portare l'assunto di Apple su Android è il modo in cui i team finiscono con un muro di rimborsi senza conferma che non riescono a spiegare.

Ecco perché RefundHalt conferma gli acquisti Google Play automaticamente nel momento in cui arriva la notifica dello store, e li riconcilia contro la Voided Purchases API così che un diritto concesso per un acquisto che Google ha poi annullato non resti attivo. La regola dei tre giorni smette di essere una corsa che puoi perdere e diventa un passo già avvenuto.