Informazioni sugli abbonamenti

Questo documento descrive come gestire gli eventi del ciclo di vita degli abbonamenti, ad esempio i rinnovi e le scadenze. Descrive inoltre funzionalità aggiuntive per gli abbonamenti, come l'offerta di promozioni e la possibilità per gli utenti di gestire i propri abbonamenti.

Se non hai configurato i prodotti in abbonamento per la tua app, consulta Creare e configurare i prodotti.

Panoramica degli abbonamenti

Un abbonamento è una transazione ricorrente che concede diritti specifici agli utenti. I diritti rappresentano un insieme di vantaggi a cui gli utenti possono accedere durante un periodo di tempo specificato. Ad esempio, un abbonamento potrebbe dare diritto a un utente a un accesso premium.

Tramite i piani base e le offerte, puoi creare più configurazioni per lo stesso prodotto in abbonamento. Ad esempio, puoi creare un'offerta introduttiva per gli utenti che non si sono mai abbonati alla tua app. Allo stesso modo, puoi creare un'offerta di upgrade per gli utenti che sono già abbonati.

Per una panoramica dettagliata dei prodotti in abbonamento, dei piani base e delle offerte, consulta la documentazione nel Centro assistenza Play Console.

La libreria Play Billing supporta i seguenti tipi di abbonamento:

• Abbonamento a un singolo elemento: in questo tipo, un elemento corrisponde a un diritto. Ad esempio, l'abbonamento a un servizio di streaming musicale.

• Abbonamento con componenti aggiuntivi: in questo tipo, un acquisto può avere diversi diritti distinti raggruppati in un unico acquisto. Ad esempio, abbonamento sia a un servizio di streaming musicale sia a un abbonamento video. Per informazioni specifiche sugli abbonamenti con componenti aggiuntivi, consulta Abbonamenti con componenti aggiuntivi.

Integrazione dei piani prepagati

I piani prepagati non si rinnovano automaticamente alla scadenza. Per estendere il proprio 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 devi impostarla in modo esplicito. All'utente viene addebitato immediatamente un intero periodo di fatturazione e il suo diritto viene esteso per la durata specificata nella ricarica.

Dopo una ricarica, i seguenti campi dell'oggetto risultato Purchase vengono aggiornati per riflettere l'acquisto della ricarica più recente:

• ID ordine
• Ora dell'acquisto
• Firma
• Token per l'acquisto
• Capito

I seguenti campi Purchase contengono sempre gli stessi dati trovati nell'acquisto originale:

• Nome pacchetto
• Stato acquisto
• Prodotti
• Rinnovo automatico

Conferma dell'acquisto prepagato

Come per gli abbonamenti con rinnovo automatico, devi confermare i piani prepagati dopo l'acquisto. Devono essere confermati sia l'acquisto iniziale sia le ricariche. Per maggiori informazioni, vedi Elaborazione degli acquisti.

A causa della potenziale breve durata dei piani prepagati, è 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 riconosciuti entro metà della durata del piano. Ad esempio, gli sviluppatori hanno 1,5 giorni di tempo per confermare un piano prepagato di tre giorni.

Integrazione degli abbonamenti a rate

Un abbonamento a rate è un tipo di abbonamento in cui gli utenti pagano l'abbonamento in più rate in un determinato periodo di tempo, anziché pagare l'intera quota di abbonamento in anticipo.

Considerazioni aggiuntive per gli abbonamenti rateali:

• Disponibilità per paese: la funzionalità di abbonamenti a rate è disponibile solo in Brasile, Francia, Italia e Spagna (controlla la console per la disponibilità più recente).
• Impostazione del prezzo: quando imposti il prezzo di un abbonamento a rate su Play Console, il prezzo rappresenta l'importo del pagamento mensile. Questo valore, combinato con il periodo di impegno impostato, genera l'importo totale dell'abbonamento nella schermata di acquisto.
• Periodo di impegno: la durata totale dell'impegno iniziale dell'abbonamento, durante il quale sono richiesti pagamenti mensili. Ad esempio, se un piano base ha un periodo di impegno di 15 mesi, l'utente effettuerà 15 pagamenti mensili in questo periodo.
• Rinnovi: nel contesto degli abbonamenti a rate, il "rinnovo" indica la conclusione di un periodo di impegno, che si tratti del periodo di impegno iniziale o di un periodo di impegno successivo. Dopo la registrazione iniziale, il primo rinnovo avviene al termine dell'intero periodo di impegno iniziale. I rinnovi successivi avvengono dopo il completamento di ogni periodo di impegno successivo. I tipi di rinnovo per gli abbonamenti a rate possono essere "Rinnovo automatico mensile" o "Rinnovo automatico per la stessa durata". Per "rinnovo automatico mensile", non è previsto alcun impegno successivo e il piano si comporta come un abbonamento mensile in cui ogni addebito mensile dell'abbonamento costituisce un rinnovo.
• Periodo di fatturazione: nel contesto degli abbonamenti a rate, si riferisce all'intervallo ricorrente in cui vengono effettuati i singoli pagamenti, come specificato nel piano base.
• Comportamenti relativi al cambio di piano e alla variazione di prezzo: per le variazioni di prezzo e le cancellazioni, l'impegno è definitivo. Ciò significa che se un utente vuole annullare o uno sviluppatore vuole modificare il prezzo, la modifica diventa effettiva al termine di un periodo di impegno. Per le modifiche del piano, l'impegno non è definitivo. Ciò significa che la modifica del piano non deve attendere la fine di un periodo di impegno, ma ha effetto immediatamente o alla successiva data di pagamento in base alla modalità di sostituzione impostata.
• Modifica del piano dello stesso abbonamento: la modifica del piano da un piano base a rate a un piano base senza rate dello stesso prodotto di abbonamento non è consentita.

• Notifiche in tempo reale per lo sviluppatore (RTDN): una RTDN SUBSCRIPTION_CANCELLATION_SCHEDULED viene inviata immediatamente dopo l'annullamento avviato dall'utente quando rimangono pagamenti per il periodo di impegno. L'annullamento è in attesa e diventerà effettivo solo al termine del periodo di impegno. Poi, se non viene ripristinato dall'utente, SUBSCRIPTION_CANCELED e SUBSCRIPTION_EXPIRED RTDN vengono inviati al termine del periodo di impegno.

• Pagamenti / Realizzazione delle entrate: i pagamenti agli sviluppatori vengono effettuati man mano che gli utenti effettuano i pagamenti mensili, in base agli stessi termini di tutti gli altri abbonamenti. Gli sviluppatori non vengono pagati in anticipo quando l'utente sottoscrive l'abbonamento a rate.

• Recupero dei pagamenti mancati: se un utente non effettua i pagamenti rateali dell'abbonamento, né Google né lo Sviluppatore tenteranno di recuperare i pagamenti mancati o in sospeso dall'utente, ad eccezione del fatto che Google potrebbe riprovare periodicamente a effettuare il pagamento durante qualsiasi Periodo di tolleranza o Periodo di sospensione dell'account applicabile in conformità con le normali pratiche di riprova del pagamento. Google non sarà responsabile nei confronti dello Sviluppatore per eventuali pagamenti rateali rimanenti non pagati.

• Disponibilità della Libreria Fatturazione Play: il campo installmentDetails è disponibile solo per la Libreria Fatturazione Play 7 o versioni successive. Per PBL 5 e versioni successive, l'abbonamento a rate viene restituito utilizzando queryProductDetails(), ma l'abbonamento non includerà informazioni dettagliate sulle rate, come il conteggio dei pagamenti impegnati del piano.

Utilizzare i link diretti per consentire agli utenti di gestire un abbonamento

La tua app deve includere un link in una schermata di impostazioni o preferenze che consenta agli utenti di gestire i propri abbonamenti, che puoi incorporare nell'aspetto naturale della tua app.

Puoi includere un link diretto dalla tua app al centro abbonamenti di Google Play per gli abbonamenti non scaduti, che puoi determinare utilizzando il campo subscriptionState della risorsa abbonamento. In base a questo, esistono diversi modi per creare link diretti 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 potrebbe essere utile per aiutare un utente a ripristinare un abbonamento annullato dal Centro abbonamenti Google Play.

Link a una pagina specifica di gestione degli abbonamenti (consigliato)

Per collegarti direttamente alla pagina di gestione di un abbonamento non scaduto, indica il nome del pacchetto e productId associato all'abbonamento acquistato. Per determinare in modo programmatico il productId per un abbonamento esistente, esegui una query sul backend della tua app o chiama BillingClient.queryPurchasesAsync() per un elenco di abbonamenti associati a un determinato utente. Ogni abbonamento contiene il productId corrispondente come parte delle informazioni sullo stato dell'abbonamento. Ogni oggetto SubscriptionPurchaseLineItem associato a un acquisto in abbonamento contiene il valore productId associato all'abbonamento che l'utente ha acquistato in quella voce di ordine.

Utilizza il seguente URL per indirizzare gli utenti a una schermata specifica di gestione degli abbonamenti, sostituendo "your-sub-product-id" e "your-app-package" con l'productId e il nome del pacchetto dell'app rispettivamente:

https://play.google.com/store/account/subscriptions?sku=your-sub-product-id&package=your-app-package

L'utente può quindi gestire i propri metodi di pagamento e accedere a funzionalità come l'annullamento, il rinnovo dell'abbonamento e la sospensione.

Consenti agli utenti di eseguire l'upgrade, il downgrade o la modifica del proprio abbonamento

Puoi offrire agli abbonati esistenti varie opzioni per modificare il proprio 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 di un altro abbonamento.
• 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 dai piani con rinnovo automatico a quelli prepagati e viceversa.

Puoi incoraggiare uno qualsiasi di questi cambiamenti fornendo offerte di abbonamento per offrire uno sconto agli utenti idonei. Ad esempio, potresti creare un'offerta che prevede uno sconto del 50% sul primo anno in caso di passaggio da un piano mensile a un piano annuale e limitare questa offerta agli utenti abbonati a un piano mensile che non l'hanno acquistata. Maggiori informazioni sui criteri di idoneità dell'offerta sono disponibili nel Centro assistenza.

La Figura 3 mostra un'app di esempio con tre piani diversi:

La tua app potrebbe mostrare una schermata simile alla figura 3, che offre agli utenti opzioni per modificare il proprio abbonamento. In tutti i casi, gli utenti devono sapere chiaramente qual è il loro piano di abbonamento attuale e quali opzioni hanno 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 qualsiasi modifica dei diritti.

Modalità di sostituzione

La tabella seguente elenca le modalità di sostituzione disponibili e un esempio di utilizzo, nonché il conteggio dei pagamenti considerati pagati.

Per saperne di più sulle diverse applicazioni di upsell e recupero delle offerte di upgrade o downgrade, consulta la guida a offerte e promozioni.

Impostare la modalità di sostituzione per un acquisto

Puoi utilizzare diverse modalità di sostituzione per diversi tipi di transizioni di abbonamento, in base alle tue preferenze e alla logica aziendale. Questa sezione spiega come impostare una modalità di sostituzione per una modifica di 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 effettuare gli addebiti agli abbonati esistenti se acquistano un piano base o un'offerta diversi per lo stesso abbonamento o se si riabbonano dopo una cancellazione. 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 cambiano i piani base all'interno dello stesso abbonamento.

Ad esempio, se implementi un'offerta di riacquisizione per lo stesso piano dopo l'annullamento dell'abbonamento da parte dell'utente, ma prima della sua scadenza, puoi elaborare il nuovo acquisto come un acquisto normale senza indicare alcun valore in SubscriptionUpdateParams. Il sistema utilizza la modalità di sostituzione predefinita che hai configurato nell'abbonamento e gestisce automaticamente la transizione dal vecchio acquisto al nuovo.

Cambiare piano per gli abbonamenti o ignorare la modalità di sostituzione predefinita

Se l'utente sta modificando i prodotti in abbonamento, acquistando un abbonamento diverso, o se vuoi ignorare la modalità di sostituzione predefinita per qualsiasi motivo, specifica il tasso di ripartizione in fase di runtime nell'ambito dei parametri del flusso di acquisto.

Per fornire correttamente SubscriptionUpdateParams nell'ambito della configurazione del flusso di acquisto in fase di runtime, tieni presente le seguenti limitazioni:

• Quando esegui l'upgrade, il downgrade o avvii il passaggio allo stesso abbonamento a un piano prepagato da un piano prepagato, con rinnovo automatico o a rate, l'unica modalità di sostituzione consentita è CHARGE_FULL_PRICE. Se specifichi un'altra modalità di sostituzione, l'acquisto non va a buon fine e all'utente viene mostrato un errore.
• Quando passi da un 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 e WITHOUT_PRORATION. Se specifichi un'altra modalità di ripartizione proporzionale, l'acquisto non va a buon fine e all'utente viene mostrato un errore.
• Il passaggio da un piano base a rate a un piano base non a rate all'interno dello stesso prodotto in abbonamento non è consentito.

Esempi e comportamenti di sostituzione

Per capire come funziona ogni modalità di ripartizione proporzionale, considera lo scenario seguente:

Samwise ha un abbonamento ai contenuti online dell'app Country Gardener. Ha un abbonamento mensile alla versione Livello 1 dei contenuti, che sono solo di testo. Questo abbonamento 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 al livello 2, che include aggiornamenti video e costa 36$all'anno.

Quando esegue 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 di Samwise al livello 1 termina immediatamente. Poiché ha pagato un mese intero (1-30 aprile), ma ha eseguito l'upgrade a metà del periodo di abbonamento, metà dell'abbonamento mensile (1 €) viene applicata al suo nuovo abbonamento. Tuttavia, poiché il nuovo abbonamento costa 36 $all'anno, il saldo del credito di 1 $copre solo 10 giorni (dal 16 al 25 aprile); quindi il 26 aprile gli vengono addebitati 36 $per un nuovo abbonamento e altri 36 $il 26 aprile di ogni anno successivo.

Devi chiamare l'PurchasesUpdatedListener della tua app nel momento in cui l'acquisto va a buon fine e puoi recuperare il nuovo acquisto nell'ambito di una chiamata queryPurchasesAsync(). Il tuo backend riceve immediatamente una notifica in tempo reale per lo sviluppatore SUBSCRIPTION_PURCHASED.

CHARGE_PRORATED_PRICE

Questa modalità può essere utilizzata perché il prezzo dell'abbonamento di livello 2 per unità di tempo (36 $/anno = 3 $/mese) è superiore al prezzo dell'abbonamento di livello 1 per unità di tempo (2 $/mese). L'abbonamento di Samwise al livello 1 termina immediatamente. Poiché ha pagato un mese intero, ma ne ha utilizzato solo la metà, alla sua nuova iscrizione viene applicata la metà dell'abbonamento (1 €). Tuttavia, poiché il nuovo abbonamento costa 36 €/anno, i 15 giorni rimanenti costano 1,50 €, quindi gli viene addebitata la differenza di 0,50 € per il nuovo abbonamento. Il 1° maggio, a Samwise vengono addebitati 36 € per il nuovo livello di abbonamento e altri 36 € il 1° maggio di ogni anno successivo.

Devi chiamare l'PurchasesUpdatedListener della tua app nel momento in cui l'acquisto va a buon fine e puoi recuperare il nuovo acquisto nell'ambito di una chiamata queryPurchasesAsync(). Il tuo backend riceve immediatamente una notifica in tempo reale per lo sviluppatore SUBSCRIPTION_PURCHASED.

WITHOUT_PRORATION

L'abbonamento di Samwise al livello 1 viene immediatamente eseguito l'upgrade al livello 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.

Devi chiamare l'PurchasesUpdatedListener della tua app nel momento in cui l'acquisto va a buon fine e puoi recuperare il nuovo acquisto nell'ambito di una chiamata queryPurchasesAsync(). Il tuo backend riceve immediatamente una notifica in tempo reale per lo sviluppatore SUBSCRIPTION_PURCHASED.

DEFERRED

L'abbonamento di Samwise al livello 1 continua fino alla scadenza del 30 aprile. Il 1° maggio entra in vigore l'abbonamento al livello 2 e a Samwise vengono addebitati 36 $per il nuovo livello di abbonamento.

Devi chiamare l'PurchasesUpdatedListener della tua app nel momento in cui l'acquisto va a buon fine e puoi recuperare il nuovo acquisto nell'ambito di una chiamata queryPurchasesAsync(). Il tuo backend riceve immediatamente una notifica in tempo reale per lo sviluppatore SUBSCRIPTION_PURCHASED. A questo punto, devi elaborare l'acquisto allo stesso modo in cui elaboreresti qualsiasi altro nuovo acquisto. In particolare, assicurati di confermare il nuovo acquisto. Tieni presente che la startTime del nuovo abbonamento viene compilata nel momento in cui la sostituzione diventa effettiva, ovvero alla scadenza del vecchio abbonamento. A quel punto, riceverai una notifica in tempo reale per il nuovo piano di abbonamento.SUBSCRIPTION_RENEWED Scopri di più sul comportamento di ReplacementMode.DEFERRED in Gestire la sostituzione posticipata.

CHARGE_FULL_PRICE

L'abbonamento di Samwise al livello 1 termina immediatamente. Il suo abbonamento al livello 2 inizia oggi e gli vengono addebitati 36 $. Poiché ha pagato un mese intero, ma ne ha utilizzato solo metà, metà dell'abbonamento mensile (1 €) viene applicata al suo nuovo abbonamento. Poiché il nuovo abbonamento costa 36 €/anno, riceverà 1/36° di anno aggiunto al suo periodo di abbonamento (~10 giorni). Pertanto, il prossimo addebito di Samwise sarà di 36 € dopo 1 anno e 10 giorni a partire da oggi. Dopodiché, gli verranno addebitati 36 $ogni anno successivo.

Quando scegli una modalità di ripartizione proporzionale, assicurati di esaminare i nostri consigli per la sostituzione.

Attivare le modifiche agli abbonamenti in-app

La tua app può offrire agli utenti un upgrade o un downgrade utilizzando gli stessi passaggi previsti 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 della modalità di sostituzione da utilizzare, come mostrato nell'esempio seguente:

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
   )
// ...

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 per la sostituzione

La tabella seguente mostra diversi scenari di ripartizione proporzionale, insieme a ciò che consigliamo per ciascuno scenario:

Gestire gli acquisti di modifiche agli abbonamenti

I cambi di piano sono nuovi acquisti a tutti gli effetti e devono essere elaborati e riconosciuti come tali dopo il completamento della procedura di fatturazione. Oltre a elaborare correttamente il nuovo acquisto, devi ritirare l'acquisto che viene sostituito.

Il comportamento in-app è lo stesso di qualsiasi nuovo acquisto. La tua app riceve l'esito del nuovo acquisto in PurchasesUpdatedListener e il nuovo acquisto è disponibile in queryPurchasesAsync.

L'API Google Play Developer restituisce un linkedPurchaseToken nella risorsa di abbonamento quando un acquisto sostituisce uno esistente. Assicurati di invalidare il token fornito in linkedPurchaseToken per assicurarti che il vecchio token non venga utilizzato per accedere ai tuoi servizi. Consulta la sezione Upgrade, downgrade e nuove registrazioni per informazioni sulla gestione degli acquisti di upgrade e downgrade.

Quando ricevi il nuovo token di acquisto, segui la stessa procedura di verifica prevista per la verifica di un nuovo token di acquisto. Assicurati di confermare questi acquisti con BillingClient.acknowledgePurchase() dalla 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 vecchio piano prima di iniziare con il nuovo.

Quando utilizzi ReplacementMode.DEFERRED per un nuovo acquisto, queryPurchasesAsync() restituisce un nuovo token di acquisto dopo il flusso di acquisto che rimane associato al vecchio prodotto fino a quando la sostituzione differita non avviene alla successiva data di rinnovo, dopodiché viene restituito il nuovo prodotto.

In passato era possibile ottenere questa esperienza utente con ProrationMode.DEFERRED, ma ProrationMode.DEFERRED è stato ritirato con Libreria Fatturazione Play 6. Consulta la seguente tabella per capire in cosa differisce il comportamento:

D'ora in poi deve essere utilizzato ReplacementMode.DEFERRED anziché ProrationMode.DEFERRED, in quanto presenta lo stesso comportamento in merito alle modifiche ai diritti, ma offre un modo per gestire l'acquisto più coerente con i comportamenti per gli altri nuovi acquisti.

Gestione dei clienti

Utilizzando 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 scada, puoi inviargli notifiche push o messaggi in-app per chiedergli di abbonarsi di nuovo.

Dopo che un utente ha annullato l'abbonamento, puoi provare a riconquistarlo nella tua app o tramite il Play Store. La seguente tabella descrive vari scenari di abbonamento insieme alle azioni di recupero associate e ai requisiti dell'app.

Prima della scadenza dell'abbonamento - in-app

Per gli abbonamenti annullati ma non ancora scaduti, puoi consentire agli abbonati di ripristinare il proprio abbonamento all'interno dell'app applicando lo stesso flusso di acquisto di prodotti in-app degli abbonati. Assicurati che la tua UI rifletta che l'utente ha un abbonamento esistente. Ad esempio, potresti mostrare la data di scadenza attuale e il prezzo ricorrente dell'utente con un pulsante Riattiva.

Nella maggior parte dei casi, vorrai offrire all'utente lo stesso prezzo e lo stesso SKU a cui aveva già sottoscritto l'abbonamento, come segue:

• Avvia un nuovo acquisto di 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 musicale di esempio e l'abbonamento scadrà il 1° agosto. Il 10 luglio si abbona di nuovo all'abbonamento di un mese allo stesso prezzo mensile. Il nuovo abbonamento è ripartito in proporzione al credito rimanente, è attivo immediatamente e si rinnova il 1° agosto.

Se vuoi offrire un prezzo diverso, ad esempio una nuova prova senza costi o uno sconto per il recupero di un abbonato, 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 musicale di esempio e l'abbonamento scadrà il 1° agosto. Il 10 luglio sottoscrive di nuovo un abbonamento annuale con un prezzo di lancio. Il nuovo abbonamento è attivo immediatamente e all'utente viene addebitato il prezzo promozionale il 1° agosto.
• Se decidi di includere una prova senza costi o un prezzo di lancio nel tuo SKU di riacquisizione, assicurati che l'utente sia idoneo deselezionando la casella Consenti una prova senza costi per app in Google Play Console, che limita l'utente a una sola 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 linkedPurchaseToken nella risorsa di abbonamento. Assicurati di invalidare il token fornito in linkedPurchaseToken per assicurarti che il vecchio token non venga utilizzato per ottenere l'accesso ai tuoi 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 Rinnova abbonamento (in precedenza Ripristina). In questo modo, l'abbonamento e il token di acquisto rimangono invariati.

Per maggiori informazioni sul ripristino degli abbonamenti, consulta la sezione Ripristini.

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 degli abbonati nuovi. Nota quanto segue:

• Per offrire agli utenti uno sconto, potresti voler offrire un ID prodotto con prezzi speciali per il tuo abbonamento, chiamato anche SKU di riacquisizione. Puoi fornire l'offerta nella tua app oppure puoi comunicarla all'utente al di fuori dell'app, ad esempio via email.
• Per avviare un abbonamento di riacquisizione, avvia il flusso di acquisto nella tua app per Android utilizzando la Libreria Fatturazione Google Play. La procedura è la stessa 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 nella tua SKU di riacquisizione, assicurati che l'utente sia idoneo deselezionando la casella Consenti una prova senza costi per app in Google Play Console, che limita l'utente a una sola prova senza costi per app.
• Se l'utente si abbona nuovamente allo stesso SKU, non ha più diritto a prove senza costi o prezzi di lancio. Assicurati che la tua UI lo rifletta.

Quando ricevi il token di acquisto, elabora l'acquisto come faresti con un nuovo abbonamento. Non riceverai un linkedPurchaseToken nella risorsa dell'abbonamento.

Dopo la scadenza dell'abbonamento - nel Play Store

Se abilitata, gli utenti possono riabbonarsi allo stesso SKU fino a un anno dopo la scadenza facendo clic su Riabbonati nel Centro abbonamenti Google Play. Viene generato un nuovo token di abbonamento e acquisto.

Il riabbonamento è considerato un acquisto esterno all'app, quindi assicurati di seguire le best practice per gestire gli acquisti effettuati al di fuori della tua app.

Promuovere il tuo abbonamento

Puoi creare codici promozionali per offrire a utenti selezionati una prova senza costi estesa di un abbonamento esistente. Per saperne di più, consulta la sezione Codici promozionali.

Per le prove senza costi, Google Play verifica che l'utente disponga di un metodo di pagamento valido prima di iniziare la prova senza costi. Alcuni utenti potrebbero visualizzare questa verifica come una trattenuta o un addebito sul proprio metodo di pagamento. Questo blocco o addebito è temporaneo e viene annullato o rimborsato in un secondo momento.

Al termine del periodo di prova, all'utente viene addebitato l'intero importo dell'abbonamento tramite il metodo di pagamento scelto.

Se un utente annulla un abbonamento in qualsiasi momento durante la prova senza costi, l'abbonamento rimane attivo fino al termine della prova e non viene addebitato alcun costo al termine del periodo di prova senza costi.

Annullare o revocare

Puoi utilizzare l'API Google Play Developer per annullare 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 la possibilità di annullare l'abbonamento nella tua app o sul tuo sito web. La tua app deve gestire questi annullamenti come descritto in Annullamenti.

• Revoca: quando revochi l'abbonamento, l'utente perde immediatamente l'accesso. Può essere utilizzato 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 utilizzare il prodotto. La tua app deve gestire queste cancellazioni come descritto in Revoche.

La seguente tabella illustra le differenze tra annullamento e revoca.

Differire la fatturazione per un abbonato

Puoi anticipare la prossima data di fatturazione per un abbonato con rinnovo automatico utilizzando Purchases.subscriptions:defer dall'API Google Play Developer. Durante il periodo di differimento, l'utente è abbonato ai tuoi contenuti con accesso completo, ma non viene effettuato alcun addebito. La data di rinnovo dell'abbonamento viene aggiornata in modo da riflettere la nuova data.

Per i piani prepagati, puoi utilizzare l'API di posticipo della fatturazione per posticipare la data di scadenza.

La fatturazione differita ti consente di:

• Offri agli utenti l'accesso senza costi come offerta speciale, ad esempio una settimana senza costi per l'acquisto di un film.
• Offri l'accesso senza costi ai clienti come gesto di buona volontà.

La fatturazione può essere posticipata di un giorno o di un anno per chiamata API. Per posticipare ulteriormente la fatturazione, puoi chiamare di nuovo l'API prima della nuova data di fatturazione.

Ad esempio, Darcy ha un abbonamento mensile a contenuti online per l'app Fishing Quarterly. Di solito le vengono addebitati 1,25 £ il primo giorno di ogni mese. A marzo ha partecipato a un sondaggio online per l'editore dell'app. L'editore la premia con sei settimane senza costi posticipando il pagamento successivo al 15 maggio, ovvero sei settimane dopo la data di fatturazione precedentemente pianificata del 1° aprile. A Darcy non viene addebitato alcun costo per aprile o l'inizio di maggio e ha ancora accesso ai contenuti. Il 15 maggio le viene addebitata la normale tariffa dell'abbonamento mensile di 1, 25 £. La sua prossima data di rinnovo è ora il 15 giugno.

Quando posticipi la data, ti consigliamo di inviare una notifica all'utente via email o all'interno dell'app per informarlo che la data di fatturazione è stata modificata.

Gestione dei pagamenti rifiutati

Se si verificano problemi di pagamento con il rinnovo di un abbonamento, Google tenterà periodicamente di rinnovare l'abbonamento per un po' di tempo prima di annullarlo. Questo periodo di recupero può consistere in un periodo di tolleranza, seguito da un periodo di sospensione dell'account. Durante questo periodo, Google invia all'utente email e notifiche che lo invitano ad aggiornare il metodo di pagamento.

In caso di rifiuto del pagamento, l'abbonamento entra in un periodo di tolleranza, se configurato. Durante il periodo di tolleranza, devi assicurarti che l'utente abbia ancora accesso ai diritti di abbonamento.

Al termine del periodo di tolleranza, l'abbonamento entra in un periodo di sospensione dell'account. Durante la sospensione dell'account, devi assicurarti che l'utente non abbia accesso ai diritti di abbonamento.

Puoi specificare la durata del periodo di tolleranza e della sospensione dell'account di ogni piano base con rinnovo automatico in Google Play Console. Specificare durate inferiori ai valori predefiniti potrebbe ridurre il numero di abbonamenti recuperati dopo i pagamenti rifiutati.

Per massimizzare la probabilità di recupero dell'abbonamento durante un rifiuto del pagamento, puoi informare l'utente di un problema di pagamento e chiedergli di risolverlo.

Puoi farlo autonomamente, come descritto nelle sezioni periodo di tolleranza e 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 e offrirà loro l'opportunità di risolvere il problema 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 l'abbonamento, riceverai un codice di risposta SUBSCRIPTION_STATUS_UPDATED insieme a un token di acquisto. Dovresti quindi utilizzare questo token di acquisto per chiamare l'API Google Play Developer e aggiornare lo stato dell'abbonamento nella tua app.

Integrare la messaggistica in-app

Per mostrare la messaggistica in-app all'utente, utilizza BillingClient.showInAppMessages().

Ecco un esempio di attivazione del flusso di messaggistica in-app:

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.
                }
            }
        })

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.
                }
            }
        });

Gestire le transazioni in sospeso degli abbonamenti

Le transazioni in attesa possono verificarsi in caso di acquisto iniziale, ricarica, upgrade o downgrade. L'acquisto dell'abbonamento inizia con lo stato SUBSCRIPTION_STATE_PENDING prima di passare a SUBSCRIPTION_STATE_ACTIVE. Se la transazione è scaduta o annullata dall'utente, viene inviata a SUBSCRIPTION_STATE_PENDING_PURCHASE_EXPIRED. Devi e dovresti aggiornare il diritto dell'utente solo dopo il completamento della transazione.

La modifica dello stato dell'abbonamento per l'acquisto iniziale con transazioni in attesa è semplice. La tua app riceve un Purchase con stato PENDING quando l'utente avvia una transazione in attesa. Al termine della transazione, la tua app riceve di nuovo Purchase con lo stato aggiornato a PURCHASED. Un messaggio SubscriptionNotification di tipo SUBSCRIPTION_PURCHASED viene inviato al tuo client RTDN. Segui la procedura normale per verificare l'acquisto, concedere all'utente l'accesso ai contenuti e confermare l'acquisto. Se la transazione scade o viene annullata, al tuo client RTDN viene inviato un messaggio SubscriptionNotification di tipo SUBSCRIPTION_PENDING_PURCHASE_CANCELED. In questi casi, l'utente non avrebbe mai dovuto ottenere l'accesso ai contenuti.

La ricarica, l'upgrade o il downgrade con transazioni in attesa comporta modifiche dello stato sia per l'abbonamento precedente che per quello nuovo. Quando l'utente avvia una transazione di ricarica, upgrade o downgrade in attesa, la tua app riceve un Purchase per il vecchio abbonamento con un oggetto PendingPurchaseUpdate. In questo momento, l'utente possiede ancora il vecchio abbonamento e non ha ancora ottenuto il nuovo. La chiamata di getProducts() e getPurchaseToken() sull'oggetto PendingPurchaseUpdate restituisce gli ID prodotto e il token di acquisto del nuovo abbonamento. Al termine della transazione, la tua app riceve un Purchase con il token di acquisto di primo livello impostato per il nuovo abbonamento e lo stato impostato su PURCHASED. Un messaggio SubscriptionNotification di tipo SUBSCRIPTION_PURCHASED viene inviato al tuo client RTDN. Solo in questo momento devi sostituire il vecchio token di acquisto con quello nuovo e aggiornare l'accesso dell'utente ai contenuti. Se la transazione scade o viene annullata, al tuo client RTDN viene inviato un messaggio SubscriptionNotification di tipo SUBSCRIPTION_PENDING_PURCHASE_CANCELED. In questi casi, l'utente dovrebbe comunque avere accesso ai contenuti del vecchio abbonamento.