Questo argomento descrive come gestire gli eventi del ciclo di vita degli abbonamenti, come i rinnovi e le scadenze. Vengono inoltre descritte funzionalità aggiuntive degli abbonamenti, come l'offerta di promozioni e la possibilità per gli utenti di gestire i propri abbonamenti.
Se non hai configurato prodotti in abbonamento per la tua app, consulta Creare e configurare i prodotti.
Panoramica degli abbonamenti
Un abbonamento rappresenta un insieme di vantaggi a cui gli utenti possono accedere durante un periodo di tempo specificato. Ad esempio, un abbonamento potrebbe concedere all'utente il diritto di accedere a un servizio di streaming musicale.
Puoi avere più abbonamenti all'interno della stessa app, per rappresentare una serie di vantaggi diversi, oppure diversi livelli di un singolo insieme di vantaggi (ad esempio, i livelli "Argento" e "Oro").
Tramite i piani base e le offerte, puoi creare più configurazioni per lo stesso prodotto in abbonamento. Ad esempio, puoi creare un'offerta di lancio per gli utenti che non si sono mai abbonati alla tua app. Analogamente, puoi creare un'offerta di upgrade per gli utenti già abbonati.
Per una panoramica dettagliata dei prodotti in abbonamento, dei piani base e delle offerte, consulta la documentazione nel Centro assistenza Play Console.
Integrazione di piani prepagati
I piani prepagati non si rinnovano automaticamente alla scadenza. Per estendere il diritto di abbonamento senza interruzioni, l'utente deve ricaricare un piano prepagato per lo stesso abbonamento.
Per le ricariche, avvia il flusso di fatturazione come faresti con l'acquisto originale. Non è necessario indicare che un acquisto è una ricarica.
Le ricariche dei piani prepagati utilizzano sempre la modalità di sostituzione CHARGE_FULL_PRICE
e non è necessario impostarla esplicitamente.
All'utente viene immediatamente addebitato un importo per un periodo di fatturazione completo e il suo diritto viene esteso per la durata specificata nella ricarica.
Dopo una ricarica, i seguenti campi nell'oggetto risultato Purchase
vengono aggiornati per riflettere l'acquisto di ricarica più recente:
- ID ordine
- Data/ora acquisto
- Firma
- Token per l'acquisto
- Riconosciuti
I seguenti campi Purchase
contengono sempre gli stessi dati dell'acquisto originale:
- Nome pacchetto
- Stato acquisto
- Prodotti
- Rinnovo automatico
Conferma dell'acquisto prepagato
Analogamente agli abbonamenti con rinnovo automatico, devi confermare i piani prepagati dopo l'acquisto. Devono essere confermati sia l'acquisto iniziale che le eventuali ricariche. Per ulteriori informazioni, consulta la sezione Elaborazione degli acquisti.
Data la possibilità che i piani prepagati di breve durata siano di breve durata, è importante confermare l'acquisto il prima possibile.
I piani prepagati con una durata di una settimana o più devono essere confermati entro tre giorni.
I piani prepagati con una durata inferiore a una settimana devono essere confermati entro metà della durata del piano. Ad esempio, gli sviluppatori hanno 1,5 giorni di tempo per accettare un piano prepagato di tre giorni.
Utilizza i link diretti per consentire agli utenti di gestire un abbonamento
L'app deve includere un link in una schermata delle impostazioni o delle preferenze che consenta agli utenti di gestire i loro abbonamenti, che puoi incorporare nell'aspetto e al design naturali della tua app.
Per gli abbonamenti non scaduti, puoi includere un link diretto dalla tua app al Centro abbonamenti Google Play, che puoi determinare utilizzando il campo subscriptionState
della risorsa dell'abbonamento.
Sulla base di questi dati, esistono diversi modi per creare un link diretto al
Centro abbonamenti del Play Store.
Link al Centro abbonamenti
Utilizza il seguente URL per indirizzare gli utenti alla pagina che mostra tutti i loro abbonamenti, come mostrato nelle figure 1 e 2:
https://play.google.com/store/account/subscriptions


Questo link diretto può essere utile per aiutare un utente a ripristinare un abbonamento annullato dal Centro abbonamenti del Play Store.
Link a una pagina di gestione degli abbonamenti specifica (consigliato)
Per collegarti direttamente alla pagina di gestione di un abbonamento non scaduto, indica il nome del pacchetto e i productId
associati all'abbonamento acquistato. Per determinare in modo programmatico il productId
per un abbonamento esistente, esegui una query al backend dell'app o chiama BillingClient.queryPurchasesAsync()
per ricevere un elenco degli abbonamenti associati a un determinato utente. Ogni abbonamento contiene
il productId
corrispondente come parte delle informazioni sullo stato dell'abbonamento.
Ogni oggetto SubscriptionPurchaseLineItem
associato all'acquisto di un abbonamento contiene il valore productId
associato all'abbonamento acquistato dall'utente nell'elemento pubblicitario in questione.
Utilizza il seguente URL per indirizzare gli utenti a una specifica schermata di gestione dell'abbonamento, sostituendo "your-sub-product-id" e "your-app-package" rispettivamente con
productId
e il nome del pacchetto dell'app:
https://play.google.com/store/account/subscriptions?sku=your-sub-product-id&package=your-app-package
L'utente è quindi in grado di gestire i propri metodi di pagamento e di accedere a funzionalità tra cui annullamento, riabbonamento e pausa.
Puoi trovare un codice di esempio per i link per la gestione degli abbonamenti nell'app di esempio Classy Taxi.
Consentire agli utenti di eseguire l'upgrade, il downgrade o la modifica dell'abbonamento
Puoi offrire agli abbonati esistenti varie opzioni per modificare il piano di abbonamento in modo da soddisfare meglio le loro esigenze:
- Se vendi più livelli di abbonamento, ad esempio abbonamenti "base" e "premium", puoi consentire agli utenti di cambiare livello acquistando un piano base o un'offerta diversi.
- Puoi consentire agli utenti di modificare il periodo di fatturazione corrente, ad esempio passando da un piano mensile a un piano annuale.
- Puoi anche consentire agli utenti di passare dal piano con rinnovo automatico a quello prepagato e viceversa.
Puoi incoraggiare qualsiasi di queste modifiche fornendo offerte di abbonamento per offrire uno sconto agli utenti idonei. Ad esempio, puoi creare un'offerta con uno sconto del 50% per il primo anno quando passi da un piano mensile a un piano annuale e limitarla agli utenti abbonati a un piano mensile che non hanno acquistato questa offerta. Ulteriori informazioni sui criteri di idoneità delle offerte sono disponibili nel Centro assistenza
La Figura 3 mostra un'app di esempio con tre diversi piani:

L'app potrebbe mostrare una schermata simile alla figura 3, che offre agli utenti la possibilità di cambiare l'abbonamento. In tutti i casi, dovrebbe essere chiaro agli utenti qual è il loro piano di abbonamento attuale e quali opzioni hanno a disposizione per modificarlo.
Quando gli utenti decidono di eseguire l'upgrade, il downgrade o modificare l'abbonamento, devi specificare una modalità di sostituzione che determina come viene applicato il valore proporzionale del periodo di fatturazione a pagamento corrente e quando si verifica un cambiamento del diritto.
Modalità di sostituzione
La seguente tabella elenca le modalità di sostituzione disponibili e l'utilizzo di esempio.
Modalità sostituzione |
Descrizione |
Esempio di utilizzo |
|
L'upgrade o il downgrade dell'abbonamento viene eseguito immediatamente. Il tempo rimanente viene adeguato in base alla differenza di prezzo e accreditato sul nuovo abbonamento posticipando la data di fatturazione successiva. Questo è il comportamento predefinito. |
Esegui l'upgrade a un livello più costoso, senza alcun pagamento aggiuntivo immediato. |
|
L'upgrade dell'abbonamento viene eseguito immediatamente e il ciclo di fatturazione rimane invariato. La differenza di prezzo per il periodo rimanente viene quindi addebitata all'utente. Nota: questa opzione è disponibile solo per l'upgrade di un abbonamento, in cui il prezzo per unità di tempo aumenta. |
Esegui l'upgrade a un livello più costoso, senza modificare la data di fatturazione. |
|
L'upgrade o il downgrade dell'abbonamento viene eseguito immediatamente e all'utente viene addebitato immediatamente il prezzo intero per il nuovo diritto. Il valore rimanente dell'abbonamento precedente viene riportato per lo stesso diritto o ripartito proporzionalmente nel tempo se passi a un diritto diverso. Nota: se il nuovo abbonamento prevede una prova senza costi o un'offerta di lancio, al momento dell'upgrade o del downgrade all'utente vengono addebitati 0 $o il prezzo dell'offerta di lancio, a seconda di quale delle due opzioni si trovi. |
Esegui l'upgrade da un periodo di fatturazione più breve a uno più lungo. |
|
L'upgrade o il downgrade dell'abbonamento viene eseguito immediatamente e il nuovo prezzo viene addebitato al momento del rinnovo. Il ciclo di fatturazione rimane invariato. |
Esegui l'upgrade a un livello di abbonamento superiore mantenendo l'eventuale periodo senza costi rimanente. |
|
L'upgrade o il downgrade dell'abbonamento viene eseguito solo al rinnovo dell'abbonamento, ma il nuovo acquisto viene emesso immediatamente con una data di inizio futura per il nuovo diritto, in modo che lo sviluppatore possa consentire agli utenti di apportare ulteriori modifiche, se lo desiderano. Ad esempio, possono tornare al piano originale o avviare una nuova modifica del piano differito. |
Esegui il downgrade a un livello meno costoso. |
Per saperne di più sulle diverse applicazioni di upsell e vincite di offerte di upgrade o downgrade, leggi la guida alle offerte e alle promozioni.
Impostare la modalità sostitutiva per un acquisto
Puoi utilizzare modalità di sostituzione diverse per tipi diversi di transizioni di abbonamenti, in base alle tue preferenze e alla logica di business. Questa sezione spiega come impostare una modalità di sostituzione per una modifica in un abbonamento e le limitazioni che si applicano.
Riabbonarsi o cambiare piano all'interno dello stesso abbonamento
Puoi specificare una modalità di sostituzione predefinita in Google Play Console. Questa impostazione ti consente di scegliere quando addebitare gli importi dovuti agli abbonati attuali se acquistano un piano base o un'offerta diversi per lo stesso abbonamento o se si abbonano dopo un annullamento. Le opzioni disponibili sono Addebito immediato, equivalente a CHARGE_FULL_PRICE
, e Addebito alla data di fatturazione successiva, equivalente a WITHOUT_PRORATION
. Queste sono le uniche modalità di sostituzione pertinenti quando si cambia piano base all'interno dello stesso abbonamento.
Ad esempio, se implementi un'offerta di riattivazione per lo stesso piano dopo l'annullamento da parte dell'utente, ma prima della fine dell'abbonamento, puoi elaborare il nuovo acquisto come un normale acquisto senza indicare alcun valore in SubscriptionUpdateParams
. Il sistema utilizza la modalità di sostituzione predefinita che hai
configurato nell'abbonamento e gestisce automaticamente la transizione del piano
dall'acquisto precedente a quello nuovo.
Cambia piano tra abbonamenti o esegui l'override della modalità di sostituzione predefinita
Se l'utente cambia prodotti di abbonamento, acquistando un abbonamento diverso, o se vuoi sostituire la modalità di sostituzione predefinita per qualsiasi motivo, devi specificare la percentuale di ripartizione in fase di runtime come parte dei parametri del flusso di acquisto.
Per fornire correttamente SubscriptionUpdateParams
nell'ambito della configurazione del flusso di acquisto di runtime, tieni presente le seguenti limitazioni:
- Quando esegui l'upgrade, il downgrade o il passaggio da uno stesso abbonamento a un piano prepagato da un piano prepagato o con rinnovo automatico, l'unica modalità di ripartizione consentita è
CHARGE_FULL_PRICE
. Se specifichi qualsiasi altra modalità di ripartizione, l'acquisto non va a buon fine e all'utente viene mostrato un errore. - Quando cambi piano all'interno dello stesso abbonamento a un piano con rinnovo automatico da un piano prepagato o un piano con rinnovo automatico, le modalità di ripartizione proporzionale valide sono
CHARGE_FULL_PRICE
eWITHOUT_PRORATION
. Se specifichi qualsiasi altra modalità di ripartizione, l'acquisto non va a buon fine e all'utente viene mostrato un errore.
Esempi e comportamenti di sostituzione
Per capire come funziona ciascuna modalità di ripartizione proporzionale, considera il seguente scenario:
Samwise ha un abbonamento ai contenuti online dall'app Country Gardener e ha un abbonamento mensile alla versione Tier 1 dei contenuti, che è di solo testo. Questo abbonamento gli costa 2$al mese e si rinnova il primo giorno del mese.
Il 15 aprile, Samwise ha scelto di eseguire l'upgrade alla versione annuale dell'abbonamento Tier 2, che include aggiornamenti video e costa 36$all'anno.
Quando esegui l'upgrade dell'abbonamento, lo sviluppatore seleziona una modalità di ripartizione proporzionale. Il seguente elenco descrive in che modo ogni modalità di ripartizione proporzionale influisce sull'abbonamento di Samwise:
WITH_TIME_PRORATION
L'abbonamento Tier 1 di Samwise termina immediatamente. Poiché ha pagato per un mese intero (1-30 aprile), ma ha eseguito l'upgrade a metà del periodo di abbonamento, al suo nuovo abbonamento viene applicata metà dell'abbonamento di un mese (1 $). Tuttavia, poiché il nuovo abbonamento costa 36 $all'anno, il saldo del credito di 1 $verrà pagato solo per 10 giorni (16-25 aprile); quindi, il 26 aprile, gli verranno addebitati 36 $per un nuovo abbonamento e altri 36 $il 26 aprile di ogni anno successivo.
Dovresti chiamare PurchasesUpdatedListener
dell'app nel momento in cui l'acquisto va a buon fine e potrai recuperare il nuovo acquisto nell'ambito di una chiamata queryPurchasesAsync()
. Il backend riceve immediatamente una SUBSCRIPTION_PURCHASED
Real Time Developer Notification.
CHARGE_PRORATED_PRICE
Questa modalità può essere utilizzata perché il prezzo dell'abbonamento Tier 2 per unità di tempo (36 $/anno = 3 $/mese) è superiore al prezzo dell'abbonamento Tier 1 per unità di tempo ($2/mese). L'abbonamento Tier 1 di Samwise termina immediatamente. Poiché ha pagato per un mese intero, ma ne ha utilizzato solo la metà, metà dell'abbonamento del mese ($1) viene applicata al suo nuovo abbonamento. Tuttavia, poiché il nuovo abbonamento costa 36 $all'anno, i 15 giorni rimanenti costano 1,50 $, quindi gli viene addebitata la differenza di 0,50 $per il nuovo abbonamento. Il 1° maggio, Samwise riceve 36 $per il suo nuovo livello di abbonamento e altri 36 $il 1° maggio di ogni anno successivo.
Dovresti chiamare PurchasesUpdatedListener
dell'app nel momento in cui l'acquisto va a buon fine e potrai recuperare il nuovo acquisto nell'ambito di una chiamata a queryPurchasesAsync()
. Il backend riceve immediatamente una SUBSCRIPTION_PURCHASED
Real Time Developer Notification.
WITHOUT_PRORATION
Per l'abbonamento Tier 1 di Samwise viene subito eseguito l'upgrade al Tier 2 senza costi aggiuntivi e il 1° maggio gli vengono addebitati 36 $per il nuovo livello di abbonamento e altri 36 $il 1° maggio di ogni anno successivo.
Dovresti chiamare PurchasesUpdatedListener
dell'app nel momento in cui l'acquisto va a buon fine e potrai recuperare il nuovo acquisto nell'ambito di una chiamata a queryPurchasesAsync()
. Il backend riceve immediatamente una SUBSCRIPTION_PURCHASED
Real Time Developer Notification.
DEFERRED
L'abbonamento Tier 1 di Samwise rimane valido fino alla scadenza del 30 aprile. Il 1° maggio entra in vigore l'abbonamento Tier 2 e a Samwise vengono addebitati 36 $per il suo nuovo livello di abbonamento.
Dovresti chiamare PurchasesUpdatedListener
dell'app nel momento in cui l'acquisto va a buon fine e potrai recuperare il nuovo acquisto nell'ambito di una chiamata a queryPurchasesAsync()
. Il backend riceve immediatamente una SUBSCRIPTION_PURCHASED
Real Time Developer Notification. Dovresti
elaborare l'acquisto come faresti per qualsiasi altro nuovo acquisto
a quel punto. In particolare, assicurati di confermare il nuovo acquisto. Tieni presente che il valore startTime
del nuovo abbonamento viene compilato nel momento in cui la sostituzione entra in vigore, che si verifica alla scadenza dell'abbonamento precedente. A quel punto, riceverai un SUBSCRIPTION_RENEWED
RTDN per il nuovo piano di abbonamento. Scopri di più sul comportamento di ReplacementMode.DEFERRED
in Gestire la sostituzione differita.
CHARGE_FULL_PRICE
L'abbonamento Tier 1 di Samwise termina immediatamente. Il suo abbonamento Tier 2 inizia oggi e gli viene addebitato l'importo di 36 $. Poiché ha pagato per un mese intero, ma ne ha utilizzato solo la metà, metà dell'abbonamento del mese ($1) viene applicata al suo nuovo abbonamento. Poiché il nuovo abbonamento costa 36 $all'anno, otterrebbe 1/36 dell'anno in aggiunta al periodo di abbonamento (circa 10 giorni). Pertanto, il prossimo addebito di Samwise a partire da oggi sarà di 1 anno e 10 giorni per 36 $. Successivamente, gli verranno addebitati 36 $all'anno successivo.
Quando scegli una modalità di ripartizione proporzionale, assicurati di esaminare i nostri consigli per la sostituzione.
Attivare modifiche all'abbonamento in-app
L'app può offrire agli utenti un upgrade o un downgrade seguendo la stessa procedura prevista per l'avvio di un flusso di acquisto. Tuttavia, quando esegui l'upgrade o il downgrade, devi fornire i dettagli dell'abbonamento attuale, dell'abbonamento futuro (con upgrade o downgrade) e la modalità sostitutiva da utilizzare, come mostrato nell'esempio seguente:
Kotlin
val offerToken = productDetails .getSubscriptionOfferDetails(selectedOfferIndex) .getOfferToken() val billingParams = BillingFlowParams.newBuilder().setProductDetailsParamsList( listOf( BillingFlowParams.ProductDetailsParams.newBuilder() .setProductDetails(productDetails) .setOfferToken(offerToken) .build() ) ).setSubscriptionUpdateParams( BillingFlowParams.SubscriptionUpdateParams.newBuilder() .setOldPurchaseToken("old_purchase_token") .setSubscriptionReplacementMode( BillingFlowParams.ReplacementMode.CHARGE_FULL_PRICE ) .build() ).build() billingClient.launchBillingFlow( activity, billingParams ) // ...
Java
String offerToken = productDetails .getSubscriptionOfferDetails(selectedOfferIndex) .getOfferToken(); BillingFlowParams billingFlowParams = BillingFlowParams.newBuilder() .setProductDetailsParamsList( ImmuableList.of( ProductDetailsParams.newBuilder() // fetched via queryProductDetailsAsync .setProductDetails(productDetails) // offerToken can be found in // ProductDetails=>SubscriptionOfferDetails .setOfferToken(offerToken) .build())) .setSubscriptionUpdateParams( SubscriptionUpdateParams.newBuilder() // purchaseToken can be found in Purchase#getPurchaseToken .setOldPurchaseToken("old_purchase_token") .setSubscriptionReplacementMode(ReplacementMode.CHARGE_FULL_PRICE) .build()) .build(); BillingResult billingResult = billingClient.launchBillingFlow(activity, billingFlowParams); // ...
Consigli sulla sostituzione
La seguente tabella mostra diversi scenari di ripartizione proporzionale e i suggerimenti per ciascuno scenario:
Scenario | Modalità sostituzione consigliata | Risultato |
---|---|---|
Upgrade a un livello più costoso | CHARGE_PRORATED_PRICE |
L'utente riceve l'accesso immediatamente, mantenendo lo stesso periodo di fatturazione. |
Downgrade a un livello meno costoso | DEFERRED |
L'utente ha già pagato per il livello più costoso, quindi manterrà l'accesso fino alla data di fatturazione successiva. |
Eseguire l'upgrade durante il periodo di prova senza costi e mantenere la prova | WITHOUT_PRORATION |
L'utente mantiene l'accesso alla prova senza costi, ma esegue l'upgrade a un livello superiore per il resto della prova. |
Eseguire l'upgrade durante il periodo di prova senza costi: fine dell'accesso alla prova senza costi | CHARGE_PRORATED_PRICE |
L'utente riceve immediatamente l'accesso al nuovo livello, ma non ha più una prova senza costi. |
Gestire gli acquisti relativi al cambio di abbonamento
Le modifiche al piano sono nuovi acquisti per tutti i termini e gli scopi e devono essere elaborati e confermati come tali al termine del flusso di fatturazione. Oltre a elaborare correttamente il nuovo acquisto, devi ritirare l'acquisto che viene sostituito.
Il comportamento in-app è lo stesso di tutti i nuovi acquisti. La tua app riceve il risultato del nuovo acquisto nel tuo PurchasesUpdatedListener
e il nuovo acquisto è disponibile in queryPurchasesAsync
.
L'API Google Play Developer restituisce un linkedPurchaseToken
nella risorsa di abbonamento quando un acquisto sostituisce un acquisto esistente. Assicurati di invalidare il token fornito nell'linkedPurchaseToken
per assicurarti che quello precedente non venga utilizzato per accedere ai tuoi servizi. Per informazioni sulla gestione degli acquisti di upgrade e downgrade, consulta Upgrade, downgrade e nuove registrazioni.
Quando ricevi il nuovo token di acquisto, segui la stessa procedura di verifica di un nuovo token di acquisto. Assicurati di confermare questi acquisti con BillingClient.acknowledgePurchase()
della Libreria Fatturazione Google Play o con Purchases.subscriptions:acknowledge
dall'API Google Play Developer.
Gestire la sostituzione differita
La modalità di sostituzione differita consente a un utente di utilizzare il diritto rimanente nel piano precedente prima di iniziare a utilizzare il nuovo piano.
Quando utilizzi SostituzioneMode.DEFERRED per un nuovo acquisto, queryPurchasesAsync()
restituisce un nuovo token di acquisto dopo il flusso di acquisto che rimane associato al prodotto precedente fino a quando la sostituzione differita non avviene alla data di rinnovo successiva, dopodiché il nuovo prodotto viene restituito.
In passato potevi ottenere questa esperienza utente con la versione deprecata
ProrationMode.DEFERRED
, mentre ProrationMode.DEFERRED
è deprecata con la
Libreria Fatturazione Play 6. Consulta la seguente tabella per capire dove varia il comportamento:
Tempo |
ProrationMode.DEFERRED (deprecato) |
SostituzioneMode.DEFERRED |
Subito dopo il completamento del flusso di acquisto (app) |
Il diritto al piano precedente continuerà fino alla data di rinnovo successiva. Per garantire che l'app conceda il diritto corretto, Il nuovo token di acquisto non viene visualizzato, quindi non può essere elaborato in questo momento. |
Il nuovo token di acquisto viene visualizzato, quindi a questo punto dovrebbe essere elaborato in base alla data prevista per la sostituzione. |
Subito dopo il completamento del flusso di acquisto (backend) |
L'RTDN SUBSCRIPTION_PURCHASED non viene inviato dopo il flusso di acquisto. Il backend non è ancora a conoscenza del nuovo acquisto. |
L'RTDN SUBSCRIPTION_PURCHASED viene inviato immediatamente dopo il flusso di acquisto per il nuovo token di acquisto. La chiamata al metodo purchases.subscriptionsv2.get con il nuovo token di acquisto restituisce un acquisto con due elementi pubblicitari:
SUBSCRIPTION_EXPIRED inviata per il token di acquisto precedente. Quando chiami il metodo purchases.subscriptionsv2.get con il token di acquisto vecchio, questo risulta scaduto (il diritto per il vecchio piano viene trasferito al nuovo acquisto per il tempo rimanente). |
In caso di sostituzione: primo rinnovo dopo il flusso di acquisto (app) |
Il nuovo token di acquisto viene visualizzato, quindi dovrebbe essere elaborato. |
Il nuovo acquisto dovrebbe essere già stato elaborato una volta che il flusso di acquisto è andato a buon fine, quindi l'app non dovrebbe intraprendere alcuna azione speciale, a parte assicurarsi che venga concesso il diritto corretto. |
Al momento della sostituzione: primo rinnovo dopo il flusso di acquisto (backend) |
Ora il nuovo acquisto può essere elaborato e confermato quando viene inviato il primo RTDN SUBSCRIPTION_RENEWED. L'elemento |
Il nuovo acquisto è stato elaborato e confermato quando è stato inviato l'RTDN SUBSCRIPTION_PURCHASED per il nuovo token di acquisto. Con SostituzioneMode.DEFERRED, i primi rinnovi seguono il comportamento standard di qualsiasi altro rinnovo e non è necessario gestire una logica speciale per le sostituzioni quando si verifica questo evento. Quando la chiamata al metodo purchases.subscriptionsv2.get con il nuovo token di acquisto restituisce un acquisto con due elementi pubblicitari:
|
D'ora in poi dovrebbe essere utilizzato SostituzioneMode.DEFERRED anziché ProrationMode.DEFERRED, in quanto presenta lo stesso comportamento relativo alle modifiche dei diritti, ma consente di gestire l'acquisto in modo più coerente con i comportamenti degli altri nuovi acquisti.
Gestione clienti
Con le Notifiche in tempo reale per lo sviluppatore, puoi rilevare in tempo reale quando un utente decide di annullare l'abbonamento. Quando un utente annulla l'abbonamento, ma prima che il suo abbonamento sia scaduto, puoi inviargli notifiche push o messaggi in-app per chiedergli di riabbonarsi.
Dopo che un utente ha annullato il suo abbonamento, puoi provare a riconquistarlo nella tua app o tramite il Play Store. La seguente tabella descrive vari scenari di abbonamento con le azioni di callback associate e i requisiti dell'app.
Prima della scadenza dell'abbonamento | Dopo la scadenza dell'abbonamento | |||
In-app | Nel Play Store | In-app | Nel Play Store | |
Funzionalità Winback | Abbonamento in-app | Ripristina | Abbonamento in-app | Riabbonati |
L'utente esegue il flusso di pagamento | Sì | No | Sì | Sì |
L'abbonamento dell'utente rimane associato allo stesso SKU | L'utente può registrarsi per uno SKU uguale o diverso | Sì | L'utente può registrarsi per uno SKU uguale o diverso | Sì |
Crea un nuovo token di acquisto | Sì | No | Sì | Sì |
Attivata per impostazione predefinita | No | Sì, è richiesto il supporto per tutti gli sviluppatori | No |
App senza Libreria Fatturazione 2.0 e versioni successive: no App con Libreria Fatturazione 2.0 e versioni successive: sì. Gli sviluppatori possono disattivare questa opzione nella console. |
Quando il costo viene addebitato all'utente |
Se utilizzi lo stesso SKU: fine del periodo di fatturazione corrente. Se utilizzi uno SKU diverso: dipende dalla modalità di ripartizione proporzionale. |
Fine del periodo di fatturazione corrente | Immediatamente | Immediatamente |
Implementazione richiesta | Fornisci un'UI per la nuova registrazione nell'app |
Rileva la modifica dello stato dell'abbonamento Link diretto al Play Store |
Fornire un'interfaccia utente per la nuova registrazione nell'app | Gestire gli acquisti fuori app |
Prima della scadenza dell'abbonamento - in-app
Per gli abbonamenti annullati, ma non ancora scaduti, puoi consentire agli abbonati di ripristinarli all'interno della tua app applicando lo stesso flusso di acquisto di prodotti in-app per i nuovi abbonati. Assicurati che la UI rifletta che l'utente ha un abbonamento esistente. Ad esempio, potresti voler visualizzare la data di scadenza corrente e il prezzo ricorrente dell'utente con un pulsante Riattiva.
La maggior parte delle volte vorrai offrire all'utente lo stesso prezzo e SKU a cui era già abbonato, come indicato di seguito:
- Avvia un nuovo abbonamento con lo stesso SKU.
- Il nuovo abbonamento sostituisce quello precedente e si rinnova alla stessa data di scadenza. Il vecchio abbonamento viene immediatamente contrassegnato come scaduto.
- Ad esempio, Achille ha un abbonamento all'app Musica di esempio e scadrà il 1° agosto. Il 10 luglio si abbona di nuovo all'abbonamento di un mese allo stesso prezzo mensile. Il nuovo abbonamento viene ripartito proporzionalmente con il credito residuo, è immediatamente attivo e viene ancora rinnovato il 1° agosto.
Se vuoi offrire un prezzo diverso, ad esempio una nuova prova senza costi o uno sconto per una vittoria, puoi offrire all'utente uno SKU diverso:
- Avvia un upgrade o un downgrade con lo SKU diverso utilizzando la modalità di sostituzione
WITHOUT_PRORATION
. - Il nuovo abbonamento sostituisce quello precedente e si rinnova alla stessa data di scadenza. All'utente viene addebitato il prezzo del nuovo SKU, inclusi eventuali prezzi di lancio, alla data di scadenza originale. Se il vecchio abbonamento è stato creato utilizzando un ID account offuscato, lo stesso ID deve essere trasmesso a
BillingFlowParams
per gli upgrade e i downgrade. - Ad esempio, Achille ha un abbonamento all'app Musica di esempio e scadrà il 1° agosto. Il 10 luglio si abbona di nuovo a un abbonamento annuale a un prezzo di lancio. Il nuovo abbonamento è immediatamente attivo e all'utente viene addebitato il prezzo di lancio il 1° agosto.
- Se decidi di includere una prova senza costi o un prezzo di lancio nello SKU di riattivazione, assicurati che l'utente sia idoneo deselezionando la casella Consenti una prova senza costi per app in Google Play Console, in modo da limitare l'utente a usufruire di una prova senza costi per app.
Quando ricevi il token di acquisto, elabora l'acquisto come faresti con un nuovo abbonamento. Inoltre, l'API Google Play Developer
restituisce un valore linkedPurchaseToken
nella risorsa di abbonamento. Assicurati di annullare la validità del token fornito in linkedPurchaseToken
per assicurarti che il token precedente non venga utilizzato per accedere ai servizi.
Prima della scadenza dell'abbonamento - nel Play Store
Mentre l'abbonamento è annullato, ma è ancora attivo, gli utenti possono ripristinarlo nel Centro abbonamenti Google Play facendo clic su Riabbonati (in precedenza Ripristina). In questo modo viene mantenuto lo stesso token di abbonamento e di acquisto.

Per maggiori informazioni sul ripristino degli abbonamenti, consulta Ripristino.
Dopo la scadenza dell'abbonamento - in-app
Puoi consentire agli abbonati scaduti di riabbonarsi all'interno della tua app applicando lo stesso flusso di acquisto di prodotti in-app valido per i nuovi abbonati. Tieni presente quanto segue:
- Per offrire agli utenti uno sconto, potresti offrire un ID prodotto con prezzo speciale per il tuo abbonamento, chiamato anche SKU di vincita. Puoi fornire l'offerta nella tua app oppure avvisare l'utente al di fuori dell'app, ad esempio via email.
- Per avviare un abbonamento Wi-Fi, avvia il flusso di acquisto nella tua app Android utilizzando Libreria Fatturazione Google Play. Si tratta della stessa procedura di un nuovo abbonamento, ma puoi determinare lo SKU disponibile per l'utente.
- Se decidi di includere una prova senza costi o un prezzo di lancio nello SKU winback, assicurati che l'utente sia idoneo deselezionando la casella Consenti una prova senza costi per app in Google Play Console, in modo da limitare l'utente a usufruire di una prova senza costi per app.
- Se l'utente si abbona di nuovo allo stesso SKU, non sarà più idoneo per le prove senza costi o il prezzo di lancio. Assicurati che l'UI rifletta questa impostazione.
Quando ricevi il token di acquisto, elabora l'acquisto come faresti con un nuovo abbonamento. Non riceverai un linkedPurchaseToken
nella risorsa di abbonamento.
Dopo la scadenza dell'abbonamento - nel Play Store
Se l'opzione è attiva, gli utenti possono riabbonarsi allo stesso SKU fino a un anno dopo la scadenza facendo clic su Riabbonati nel Centro abbonamenti Google Play. In questo modo vengono generati un nuovo token di abbonamento e di acquisto.

La riabbonamento è considerata un acquisto fuori app, quindi assicurati di seguire le best practice per la gestione degli acquisti effettuati all'esterno dell'app.
Promuovi il tuo abbonamento
Puoi creare codici promozionali per offrire a utenti selezionati una prova senza costi estesa di un abbonamento esistente. Per scoprire di più, consulta la pagina Codici promozionali.
Per le prove senza costi, Google Play verifica che l'utente abbia un metodo di pagamento valido prima di iniziare la prova senza costi. Alcuni utenti potrebbero vedere questa verifica come una sospensione o un addebito sul loro metodo di pagamento. Questa preautorizzazione o addebito è temporaneo e successivamente stornato o rimborsato.
Al termine del periodo di prova, l'intero importo dell'abbonamento viene addebitato sul metodo di pagamento dell'utente.
Se un utente annulla un abbonamento in qualsiasi momento durante il periodo di prova senza costi, l'abbonamento rimane attivo fino al termine della prova e non gli viene addebitato alcun importo al termine del periodo di prova senza costi.
Annullare, rimborsare o revocare
Puoi utilizzare l'API Google Play Developer per annullare, rimborsare o revocare un abbonamento. Questa funzionalità è disponibile anche in Google Play Console.
- Annulla: gli utenti possono annullare un abbonamento su Google Play. Puoi anche offrire agli utenti un'opzione per annullare l'abbonamento nella tua app o sul tuo sito web. L'app deve gestire questi annullamenti come descritto nella sezione Revoche.
- Rimborso: quando rimborsi, l'utente può continuare a utilizzare l'abbonamento. I rimborsi possono essere utilizzati se, ad esempio, si è verificato un errore tecnico che ha impedito all'utente di accedere al tuo prodotto, ma l'errore è stato risolto. Tieni presente che per rimborsare un importo superiore al pagamento più recente o se vuoi emettere un rimborso parziale, devi utilizzare Google Play Console.
- Revoca: se revochi l'abbonamento, l'utente perde immediatamente l'accesso all'abbonamento. Questa opzione può essere utilizzata se, ad esempio, si è verificato un errore tecnico che ha impedito all'utente di accedere al tuo prodotto e l'utente non vuole continuare a utilizzarlo. L'app deve gestire questi annullamenti come descritto in Revoche.
La tabella seguente illustra le differenze tra annullamento, rimborso e revoca.
Interrompe il rinnovo | Rimborsare denaro | Revocare l'accesso | |
Annulla | Sì | No | No |
Rimborso | No | Sì | No |
Revoca | Sì | Sì | Sì |
Rimanda la fatturazione di un abbonato
Puoi posticipare la data di fatturazione successiva per un abbonato con rinnovo automatico utilizzando Purchases.subscriptions:defer
dell'API Google Play Developer. Durante il periodo di differimento, l'utente si abbona ai tuoi contenuti con accesso completo, ma non riceve addebiti. La
data di rinnovo dell'abbonamento viene aggiornata in base alla nuova data.
Per i piani prepagati, puoi utilizzare l'API Differisci fatturazione per posticipare la scadenza.
La fatturazione differita ti consente di:
- Offri agli utenti l'accesso senza costi sotto forma di offerta speciale, ad esempio una settimana senza costi per l'acquisto di un film.
- Concedi l'accesso senza costi ai clienti come gesto di avviamento.
La fatturazione può essere differita di un solo giorno e di un anno per chiamata API. Per posticipare ulteriormente la fatturazione, puoi chiamare di nuovo l'API prima dell'arrivo della nuova data di fatturazione.
Ad esempio, Dario ha un abbonamento mensile ai contenuti online per l'app Fishshing Quarterly. Di solito, le vengono addebitate 1,25 £ il primo giorno di ogni mese. A marzo, ha partecipato a un sondaggio online per il publisher dell'app. L'editore le premia con sei settimane senza costi rinviando il pagamento successivo fino al 15 maggio, ossia sei settimane dopo la data di fatturazione precedentemente programmata per il 1° aprile. Darcy non riceve alcun addebito per aprile o inizio maggio e ha comunque accesso ai contenuti. Il 15 maggio le viene addebitata la normale tariffa di abbonamento mensile di 1, 25 £. La prossima data di rinnovo è il 15 giugno.
Quando si rinvia, è consigliabile informare l'utente via email o all'interno dell'app per informarlo che la data di fatturazione è cambiata.
Gestione dei rifiuti dei pagamenti
In caso di problemi con il pagamento alla fine di un ciclo di fatturazione, Google tenterà periodicamente di rinnovare l'abbonamento per un certo periodo di tempo prima di annullarlo. Questo periodo di nuovo tentativo può durare fino a 30 giorni oltre all'eventuale durata del periodo di tolleranza specificata. Durante questo periodo, Google invia all'utente anche email e notifiche per chiedergli di aggiornare il metodo di pagamento.
Quando il pagamento viene rifiutato, per l'abbonamento viene innanzitutto inserito un periodo di tolleranza, se abilitato. Durante il periodo di tolleranza, l'utente dovrebbe avere ancora accesso all'abbonamento.
Al termine del periodo di tolleranza, l'abbonamento viene sospeso dall'account per un massimo di 30 giorni. Durante la sospensione dell'account, puoi bloccare l'accesso all'abbonamento.
Per massimizzare le probabilità di recupero dell'abbonamento durante il rifiuto di un pagamento, puoi informare l'utente di un problema di pagamento e chiedergli di risolverlo.
Puoi eseguire questa operazione autonomamente, come descritto nelle sezioni relative al periodo di tolleranza e alla sospensione dell'account, oppure puoi implementare l'API di messaggistica in-app, in cui Google mostra un messaggio agli utenti nella tua app.
Messaggistica in-app
Se hai attivato la messaggistica in-app con
InAppMessageCategoryId.TRANSACTIONAL
,
Google Play mostrerà agli utenti i messaggi durante il periodo di tolleranza e la sospensione dell'account una volta al giorno
per offrire loro la possibilità di risolvere i problemi di pagamento senza uscire dall'app.

Ti consigliamo di chiamare questa API ogni volta che l'utente apre l'app per determinare se il messaggio deve essere mostrato.
Se l'utente ha recuperato correttamente l'abbonamento, riceverai un codice di risposta di SUBSCRIPTION_STATUS_UPDATED
insieme a un token di acquisto. Dovresti poi utilizzare questo token di acquisto per chiamare
l'API Google Play Developer e aggiornare lo stato dell'abbonamento nell'app.
Integra la messaggistica in-app
Per mostrare i messaggi in-app agli utenti, utilizza
BillingClient.showInAppMessages()
.
Ecco un esempio di attivazione del flusso di messaggi in-app:
Kotlin
val inAppMessageParams = InAppMessageParams.newBuilder() .addInAppMessageCategoryToShow(InAppMessageCategoryId.TRANSACTIONAL) .build() billingClient.showInAppMessages(activity, inAppMessageParams, object : InAppMessageResponseListener() { override fun onInAppMessageResponse(inAppMessageResult: InAppMessageResult) { if (inAppMessageResult.responseCode == InAppMessageResponseCode.NO_ACTION_NEEDED) { // The flow has finished and there is no action needed from developers. } else if (inAppMessageResult.responseCode == InAppMessageResponseCode.SUBSCRIPTION_STATUS_UPDATED) { // The subscription status changed. For example, a subscription // has been recovered from a suspend state. Developers should // expect the purchase token to be returned with this response // code and use the purchase token with the Google Play // Developer API. } } })
Java
InAppMessageParams inAppMessageParams = InAppMessageParams.newBuilder() .addInAppMessageCategoryToShow(InAppMessageCategoryId.TRANSACTIONAL) .build(); billingClient.showInAppMessages(activity, inAppMessageParams, new InAppMessageResponseListener() { @Override public void onInAppMessageResponse(InAppMessageResult inAppMessageResult) { if (inAppMessageResult.responseCode == InAppMessageResponseCode.NO_ACTION_NEEDED) { // The flow has finished and there is no action needed from developers. } else if (inAppMessageResult.responseCode == InAppMessageResponseCode.SUBSCRIPTION_STATUS_UPDATED) { // The subscription status changed. For example, a subscription // has been recovered from a suspend state. Developers should // expect the purchase token to be returned with this response // code and use the purchase token with the Google Play // Developer API. } } });