Ho appena pagato la quota di 25 $ di Google Play. E adesso? (2026)

Pagare la quota di 25 $ di Google sembra il traguardo. È più vicino alla partenza. Un account personale appena creato entra in Play Console, apre la pagina della versione e trova un pulsante grigio e un testo su «12 tester» e «14 giorni». Questo post mappa l’intero percorso dal pagamento all’app live, nell’ordine in cui incontri davvero ogni passo, aggiornato al 2 luglio 2026. Dove il testo di Google conta, lo citiamo direttamente invece di parafrasarlo.

La quota di 25 $ di Google Play è ricorrente?

No, ed è la prima cosa di cui puoi stare tranquillo. Il testo ufficiale di Google dice che è prevista una quota di registrazione forfettaria di 25 $. Paghi una volta e l’account sviluppatore resta tuo a tempo indeterminato, senza rinnovo annuale. È addebitata per account sviluppatore, non per app, quindi puoi pubblicare più app con quel solo pagamento.

Alcuni dettagli di pagamento prendono di sorpresa. Le carte prepagate non sono accettate, devi avere almeno 18 anni per registrarti, e la quota non è rimborsabile anche se la verifica dell’identità fallisce dopo. Se conosci già l’ecosistema Apple, il contrasto è netto:

Quindi la buona notizia è chiara: non ti verrà addebitato di nuovo. La notizia meno ovvia è tutto ciò che la quota non fa.

Cosa sbloccano davvero i 25 $?

Sbloccano l’accesso a Play Console. Non sbloccano da soli un lancio pubblico sul Play Store. Prima di inviare qualsiasi cosa, Google richiede che verifichi l’account sviluppatore, e il percorso di onboarding dipende dal tipo di account scelto alla registrazione.

Cosa include la quota e cosa no

Google offre due tipi di account, personale e dell’organizzazione, con accesso alle stesse funzionalità principali. La differenza è l’informazione di identità che Google raccoglie e mostra. Un account personale serve a pubblicazioni individuali, hobby o da studente. Un account dell’organizzazione è per azienda o istituzione e richiede un numero D-U-N-S più i dati dell’organizzazione.

Quali sono i passi reali dal pagamento all’app live?

Il modello mentale più pulito: i 25 $ ti mettono alla porta, ma devi ancora attraversare l’edificio. Ecco la sequenza reale che Google impone a uno sviluppatore nuovo: i primi tre passi li hai già lasciati alle spalle.

I 10 passi, in ordine

1. Accedi con un account Google

   Devi avere 18 anni o più per registrare un account sviluppatore.

2. Accetta il Developer Distribution Agreement

   Rivedi e accetta i termini di Google alla registrazione.

3. Paga la quota una tantum di 25 $

   Con una carta valida e non prepagata. È il passo che hai appena concluso.

4. Scegli personale o dell’organizzazione

   È difficile cambiare dopo, quindi scegli il tipo giusto fin dall’inizio.

5. Verifica la tua identità

   Google può chiedere un documento ufficiale e una carta a tuo nome legale.

6. Crea la scheda dell’app in Play Console

   Dai il nome, imposta la lingua e scegli app o gioco, gratuita o a pagamento.

7. Completa le attività di setup obbligatorie

   Scheda dello store, contenuto dell’app e dichiarazioni di policy devono essere pronte.

8. Esegui un test interno e poi il test chiuso obbligatorio Il muro

   Il test chiuso richiede almeno 12 tester attivati per 14 giorni consecutivi. È il passo in cui la maggior parte di chi inizia si blocca.

9. Richiedi l’accesso in produzione e supera la revisione

   Rispondi al modulo in tre sezioni; la revisione di Google in genere richiede al massimo 7 giorni.

10. Lancia la versione di produzione

    Dopo l’approvazione, la tua app va live su Google Play.

Se vuoi la versione condensata di questo flusso in linguaggio semplice, come funziona descrive lo stesso percorso passo dopo passo. La verifica dell’identità su account personale di solito è rapida, a volte lo stesso giorno, anche se Google non promette un termine fisso. Gli account dell’organizzazione impiegano di più perché il passo del D-U-N-S, nelle parole di Google, «può richiedere fino a 28 giorni», quindi un’azienda deve iniziare presto.

Come creare l’app senza un errore permanente?

Quando crei la scheda dell’app, Google chiede il nome dell’app, la lingua predefinita, se è app o gioco, se è gratuita o a pagamento, un’email di contatto per gli utenti, e l’accettazione di Play App Signing e dei termini di policy. Due delle scelte che fai qui sono, di fatto, permanenti, quindi prendile con calma.

Le due decisioni permanenti

Mentre configuri la scheda dello store, tieni presenti i limiti di campo di Google per non riscrivere i testi all’ultimo minuto. La scheda dello store è anche condivisa tra i canali, quindi i tuoi tester vedono, in sostanza, la stessa struttura di scheda che vedranno poi gli utenti pubblici.

Quale documentazione richiede Google prima del lancio?

Più di quanto la maggior parte di chi inizia si aspetti, e di solito è da qui che arriva il ritardo, non dal codice. Prima del lancio, Google si aspetta che un set di attività di contenuto dell’app e di setup dello store sia completo e corretto. Risposte incomplete o imprecise sono tra i motivi più comuni per cui un lancio si blocca.

Le dichiarazioni che devi completare

Sul lato tecnico, Google Play distribuisce le app come Android App Bundles: invii un pacchetto firmato e Play consegna versioni ottimizzate a ogni dispositivo. Devi anche rispettare la regola attuale di API di destinazione. Le app nuove e gli aggiornamenti devono avere come target Android 16 (API level 36) entro il 31 agosto 2026, con Wear OS e Android TV che possono mirare almeno all’API 35. Se stai costruendo ora, punta all’API 36 fin dall’inizio per non essere costretto a un aggiornamento frettoloso.

Perché Play Console non mi lascia pubblicare l’app?

Perché hai un account personale nuovo, e Google subordina l’accesso in produzione a un requisito di test chiuso. Ecco il testo esatto di Google:

Si applica agli account personali creati dopo il 13 novembre 2023. Gli account creati prima di quella data e gli account dell’organizzazione sono esenti. L’esenzione è reale, ma ricorda: gli account dell’organizzazione richiedono il numero D-U-N-S che la maggior parte degli sviluppatori solo non ha.

play-console-production-access Clic per ingrandire

Un’altra cosa da chiarire: il requisito è partito da 20 tester quando Google lo ha lanciato. Google l’ha ridotto a 12 tester a dicembre 2024, modifica che ora compare direttamente nell’interfaccia di Play Console. Se trovi un tutorial vecchio che chiede 20 tester, quel numero è obsoleto: ti servono 12. Ne parliamo di più in perché Google è passato da 20 a 12 tester (in inglese).

Cosa conta come tester valido e cosa azzera l’orologio dei 14 giorni?

È qui che chi inizia perde settimane in silenzio, quindi leggi questa sezione due volte. Prova qualsiasi scenario di cui non sei sicuro qui sotto e poi leggi le regole sotto.

Ecco le regole dietro quei verdetti:

• I 14 giorni devono essere consecutivi. Google non conta i tester che hanno attivato il test, hanno testato per meno di 14 giorni e poi sono usciti. Se il conteggio degli attivati scende sotto 12, rischi di riavviare la finestra. C’è un’analisi completa in i 14 giorni devono essere consecutivi?.
• Uscire dal test non è lo stesso che disinstallare. Un tester esce in modo formale solo visitando il link del test e scegliendo di uscire. Disinstallare l’app da sola non lo rimuove, ma i tester che installano una volta e spariscono sembrano inattivi, e un engagement debole è un motivo comune di rifiuto.
• Gli emulatori non contano. Google vuole engagement reale su dispositivi reali. Se vuoi la spiegazione completa, vedi perché gli emulatori non contano nel test chiuso.
• Aggiornare la build non azzera l’orologio. Pubblicare una correzione nei 14 giorni è anzi incoraggiato: ecco esattamente cosa azzera e cosa non azzera l’orologio dei 14 giorni.
• Il requisito è per app, non per account. Lo soddisfi una volta per nome di pacchetto unico. Gli aggiornamenti di routine di un’app approvata non lo ripetono, ma un’app totalmente nuova ricomincia da zero.

Un ordine intelligente delle operazioni è eseguire un test interno prima e poi passare al test chiuso. Il test interno supporta fino a 100 tester e li raggiunge in minuti, il che lo rende il posto ideale per intercettare problemi di installazione, firma e crash prima ancora che l’orologio dei 14 giorni corra. Nota che dopo la prima pubblicazione, il link del test stesso può impiegare alcune ore per comparire. Nel test chiuso puoi gestire i tester con elenco email o Google Group, e se il link di partecipazione del Google Group non funziona e i tester vedono «app non disponibile», quasi sempre è un problema di associazione o account sbagliato, non del link in sé.

Tutto il resto dei requisiti di questo post è qualcosa che controlli direttamente. Questo ha bisogno di 12 persone reali su dispositivi Android reali, attivate e attive per 14 giorni di fila: esattamente dove gli sviluppatori solo si bloccano.

Come richiedere l’accesso in produzione dopo i 14 giorni?

Quando soddisfi i criteri, l’opzione di richiedere l’accesso in produzione compare nella Dashboard di Play Console. Apre un modulo in tre sezioni.

Cosa chiede ogni sezione

Quando superi, è il momento che cercavi: Google invia un’email che conferma che l’accesso in produzione è stato concesso:

production-access-approved.eml Clic per ingrandire

Quanto tempo finché l’app non è davvero live?

Pianifica al minimo da 2 a 4 settimane, e più vicino a 3-5 settimane se stai facendo tutto per la prima volta. La finestra di 14 giorni è fissa e non si può accorciare: ciò che puoi comprimere è reclutare i tester e, soprattutto, evitare cicli che falliscono.

Ecco una tempistica realistica per chi inizia, con le sovrapposizioni che gli sviluppatori esperti sfruttano:

Ogni giro che fallisce costa altri 14 giorni. Se parti con esattamente 12 tester e due si allontanano, scendi sotto la soglia e perdi l’intera finestra: è per questo che gli sviluppatori esperti reclutano più di 12. Usa lo stimatore qui sotto per vedere come appare un lancio realistico nella tua situazione:

Cos’altro è cambiato per i nuovi sviluppatori nel 2026?

Alcune novità del 2026 vale la pena conoscerle prima di pubblicare.

Le novità del 2026 che ti riguardano

In cosa sbagliano di più gli sviluppatori alla prima volta?

Quasi tutti questi errori si evitano quando sai che esistono.

Le sbavature che costano settimane a chi inizia

È permesso pagare per i tester di Google Play?

Sì. Google richiede almeno 12 tester attivati per 14 giorni consecutivi, ma non limita chi sono i tuoi tester né come li trovi. Ciò che viola le regole sono installazioni false o incentivate che non riflettono un uso genuino.

Persone reali e attivate, che eseguono la tua app su dispositivi reali, sono esattamente ciò che il requisito è fatto per catturare, e ciò che emulatori e bot non riescono a fingere. È precisamente il modello di un servizio legittimo di test chiuso: tester reali che puoi vedere attivare il test dentro la tua stessa Play Console, facendo ciò che la regola di Google è stata costruita per misurare. La linea è semplice: l’engagement reale va bene; l’engagement falsificato no.

Dove entra PrimeTestLab in tutto questo

Guarda di nuovo il percorso a partire dal pagamento di 25 $. Quasi ogni tappa è scartoffie e ingegneria che controlli tu: l’account, l’identità, la build, la scheda, le dichiarazioni e il modulo. Una è fondamentalmente diversa: servono 12 persone reali su dispositivi Android reali, attivate e davvero attive per 14 giorni di fila. È in quell’unico passo che la maggior parte degli sviluppatori solo si blocca, ed è esattamente ciò di cui si occupa PrimeTestLab.

Condividi il link di invito del test chiuso. Noi ci occupiamo dell’invito, della verifica di attivazione, del monitoraggio quotidiano dell’engagement e della copertura completa di 14 giorni, così un tester che esce non interrompe mai la sequenza né azzera l’orologio. 7.400+ app e oltre, con un tasso di successo del 99,9% al primo tentativo in 120+ paesi, su dispositivi reali con Android da 7 a 17.

Fare il test chiuso da soli vs un giro gestito

Pacchetti attuali

Domande frequenti

L’essenziale