Questo argomento descrive come gestire gli eventi del ciclo di vita dell'abbonamento, ad esempio rinnovi ed estinzioni. Inoltre, descrive funzionalità aggiuntive degli 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 rappresenta un insieme di vantaggi a cui gli utenti possono accedere durante un determinato periodo di tempo. Ad esempio, un abbonamento potrebbe dare a un utente il diritto di accedere a un servizio di streaming musicale.
Puoi avere più abbonamenti all'interno della stessa app per rappresentare diversi insiemi di vantaggi o diversi livelli di un singolo insieme di vantaggi (ad esempio, i livelli "Silver" e "Gold").
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 hanno mai effettuato l'abbonamento alla tua app. Analogamente, puoi creare un'offerta di upgrade per gli utenti che hanno già un abbonamento.
Per una panoramica dettagliata dei prodotti in abbonamento, dei piani di base e delle offerte, consulta la documentazione nel Centro assistenza Play Console.
Integrazione dei piani prepagati
I piani prepagati non si rinnovano automaticamente alla scadenza. Per estendere il diritto all'abbonamento senza interruzioni, l'utente deve ricaricare un pianoprepagato per lo stesso abbonamento.
Per le ricariche, avvia il flusso di fatturazione come faresti con l'acquisto originale. Non è necessario indicare che un acquisto è un ricarica.
I ricariche del piano prepagato utilizzano sempre la modalità di sostituzione CHARGE_FULL_PRICE
e non è necessario impostarla esplicitamente.
All'utente viene addebitato immediatamente un periodo di fatturazione completo e il suo diritto viene esteso per la durata specificata nel ricaricamento.
Dopo un ricarica, i seguenti campi nell'oggetto risultato
Purchase
vengono aggiornati in base all'acquisto di ricarica più recente:
- ID ordine
- Ora di acquisto
- Firma
- Token per l'acquisto
- Confermato
I seguenti campi Purchase contengono sempre gli stessi dati trovati nell'acquisto originale:
- Nome pacchetto
- Stato dell'acquisto
- Prodotti
- Rinnovo automatico
Conferma dell'acquisto prepagato
Come per gli abbonamenti con rinnovo automatico, devi confermare i piani prepagati dopo l'acquisto. Sia l'acquisto iniziale sia eventuali ricariche devono essere confermati. Per ulteriori informazioni, consulta Elaborazione degli acquisti.
A causa della potenziale durata breve 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 confermati entro la 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 nell'arco di un periodo di tempo, anziché pagare l'intera quota dell'abbonamento in anticipo.
Considerazioni aggiuntive per gli abbonamenti a rate:
- Disponibilità nei paesi: la funzionalità degli abbonamenti a rate è disponibile solo in Brasile, Francia, Italia e Spagna (controlla la Console per verificare l'ultima disponibilità).
- Impostazione del prezzo: quando imposti il prezzo di un abbonamento con rate su Console, il prezzo rappresenta l'importo della rata mensile. Questo, insieme al 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 mensilmente durante questo periodo.
- Rinnovi: nel contesto degli abbonamenti a rate, "rinnovo" indica la conclusione di un periodo di impegno, sia iniziale che 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 "si rinnova automaticamente ogni mese", 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 di modifica del piano e variazione di prezzo: per le variazioni di prezzo e i cancellamenti, 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 al piano, l'impegno non è vincolante. Ciò significa che la modifica del piano non deve attendere la fine di un periodo di impegno, ma avrà effetto immediatamente o alla data di pagamento successiva in base alla modalità di sostituzione impostata.
- Modifica del piano dello stesso abbonamento: non è consentita la modifica del piano da un piano base con rate a un piano base senza rate dello stesso prodotto in abbonamento.
Notifiche in tempo reale per lo sviluppatore (RTDN): viene inviata una RTDN
SUBSCRIPTION_CANCELLATION_SCHEDULEDimmediatamente dopo l'annullamento avviato dall'utente quando rimangono pagamenti per il periodo di impegno. L'annullamento è in attesa e verrà applicato solo al termine del periodo di impegno. Se non vengono ripristinati dall'utente, alla fine del periodo di impegno vengono inviati i RTDNSUBSCRIPTION_CANCELEDeSUBSCRIPTION_EXPIRED.Pagamenti / Realizzazione delle entrate: i pagamenti agli sviluppatori vengono effettuati man mano che gli utenti effettuano i pagamenti mensili, secondo gli stessi termini di tutti gli altri abbonamenti. Gli sviluppatori non vengono pagati in anticipo quando l'utente sottoscrive l'abbonamento con rateizzazione.
Riscossione dei pagamenti mancati: se un utente non paga alcuna rata dell'abbonamento, né Google né lo Sviluppatore tenteranno di riscuotere gli eventuali pagamenti mancati o insoluti dall'utente, salvo che Google possa ritentare periodicamente il pagamento durante il Periodo di tolleranza o il periodo di Sospensione dell'account applicabili in conformità con le normali prassi di ripetizione dei pagamenti. Google non sarà responsabile nei confronti dello Sviluppatore per eventuali pagamenti rateizzati rimanenti non corrisposti.
Disponibilità della Libreria Fatturazione Play: il campo
installmentDetailsè disponibile solo per PBL 7 o versioni successive. Per PBL 5 e versioni successive, l'abbonamento con rateizzazione viene restituito utilizzandoqueryProductDetails(), ma l'abbonamento non includerà informazioni dettagliate sulle rate, come il numero di pagamenti previsti del piano.
Utilizzare i link diretti per consentire agli utenti di gestire un abbonamento
La tua app deve includere un link in una schermata delle impostazioni o delle preferenze che consenta agli utenti di gestire i propri abbonamenti, che puoi incorporare nel look and feel 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 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 iscrizioni, 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 del Play Store.
Link a una pagina di gestione degli abbonamenti specifica (opzione consigliata)
Per collegarti direttamente alla pagina di gestione di un abbonamento non scaduto, indica il nome del pacchetto e productId associati all'abbonamento acquistato. Per
determinare in modo programmatico il productId di 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
productId corrispondente come parte delle informazioni sullo stato dell'abbonamento.
Ogni oggetto SubscriptionPurchaseLineItem associato a un
acquisto di abbonamento contiene il valore productId associato all' abbonamento
che l'utente ha acquistato nell'elemento pubblicitario.
Utilizza il seguente URL per indirizzare gli utenti a una schermata specifica per la gestione degli abbonamenti, sostituendo "your-sub-product-id" e "your-app-package" con 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 alle funzionalità, tra cui annullamento, abbonamento di nuovo e sospensione.
Consentire agli utenti di eseguire l'upgrade, il downgrade o la modifica dell'abbonamento
Puoi offrire agli abbonati esistenti varie opzioni per modificare il loro piano di abbonamento in modo da soddisfare meglio le loro esigenze:
- Se vendi più livelli di abbonamento, ad esempio "base" e "premium", puoi consentire agli utenti di cambiare livello acquistando un piano base o un'offerta di un abbonamento diverso.
- Puoi consentire agli utenti di modificare il periodo di fatturazione corrente, ad esempio passare da un piano mensile a un piano annuale.
- Puoi anche consentire agli utenti di passare da un piano con rinnovo automatico a un piano prepagato e viceversa.
Puoi incoraggiare una di queste modifiche proponendo offerte di abbonamento con uno sconto per gli utenti idonei. Ad esempio, puoi creare un'offerta che offre uno sconto del 50% sul primo anno quando passi da un piano mensile a un piano annuale e limitarla agli utenti che hanno sottoscritto un piano mensile e 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:
La tua app potrebbe mostrare una schermata simile alla figura 3, offrendo agli utenti le opzioni per modificare il loro abbonamento. In ogni caso, gli utenti devono essere consapevoli del loro piano di abbonamento attuale e delle opzioni a loro disposizione per modificarlo.
Quando gli utenti decidono di eseguire l'upgrade, il downgrade o la modifica dell'abbonamento, devi specificare una modalità di sostituzione che determina in che modo viene applicato il valore proporzionale del periodo di fatturazione pagato corrente e quando si verifica una modifica del diritto.
Modalità di sostituzione
La tabella seguente elenca le modalità di sostituzione disponibili, un esempio di utilizzo e il numero di pagamenti considerati pagati.
Modalità di sostituzione |
Descrizione |
Esempio di utilizzo |
Pagamenti previsti registrati come pagati (per la sostituzione dell'abbonamento a rate) |
|
L'upgrade o il downgrade dell'abbonamento viene eseguito immediatamente. Il tempo rimanente viene modificato in base alla differenza di prezzo e accreditato sul nuovo abbonamento anticipando la data di fatturazione successiva. Questo è il comportamento predefinito. |
Eseguire l'upgrade a un livello più costoso senza alcun pagamento aggiuntivo immediato. |
0 |
|
L'upgrade dell'abbonamento viene eseguito immediatamente e il ciclo di fatturazione rimane invariato. La differenza di prezzo per il periodo rimanente viene addebitata all'utente. Nota:questa opzione è disponibile solo per un upgrade dell'abbonamento, in cui il prezzo per unità di tempo aumenta. |
Esegui l'upgrade a un livello più costoso, senza modificare la data di fatturazione. |
1 |
|
L'upgrade o il downgrade dell'abbonamento viene eseguito immediatamente e all'utente viene addebitato immediatamente il prezzo intero del nuovo diritto. Il valore rimanente dell'abbonamento precedente viene trasferito per lo stesso diritto o ripartito proporzionalmente in base al tempo in caso di passaggio a un diritto diverso. Nota: se il nuovo abbonamento prevede una prova senza costi o un'offerta di lancio, all'utente non viene addebitato alcun importo o viene addebitato il prezzo dell'offerta di lancio, a seconda dei casi, al momento dell'upgrade o del downgrade. |
Esegui l'upgrade da un periodo di fatturazione più breve a uno più lungo. |
1 (nota: 0 se il nuovo abbonamento prevede una prova senza costi). |
|
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. |
Eseguire l'upgrade a un livello di abbonamento superiore mantenendo il periodo di prova senza costi rimanente. |
0 |
|
L'upgrade o il downgrade dell'abbonamento viene eseguito solo al momento del rinnovo, ma il nuovo acquisto viene emesso immediatamente con i seguenti due elementi:
Nota:per gli abbonamenti a rate, la modifica del piano avviene all'inizio della data di pagamento successiva. |
Esegui il downgrade a un livello meno costoso. |
1 |
Per scoprire di più sulle diverse applicazioni di upsell e fidelizzazione delle offerte di upgrade o downgrade, consulta la guida relativa a offerte e promozioni.
Impostare la modalità di sostituzione per un acquisto
Puoi utilizzare modalità di sostituzione diverse 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 applicabili.
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 abbonati esistenti se acquistano
un piano base o un'offerta diversi per lo stesso abbonamento o se si abbonano nuovamente dopo un
annullamento. Le opzioni disponibili sono Addebita subito, equivalente a
CHARGE_FULL_PRICE, e Addebita 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 stai implementando un'offerta di recupero per lo stesso piano dopo l'annullamento da parte dell'utente, ma prima della fine dell'abbonamento, puoi elaborare il nuovo acquisto come un acquisto normale senza indicare alcun valore in SubscriptionUpdateParams. Il sistema utilizza la modalità di sostituzione predefinita configurata nell'abbonamento e gestisce automaticamente la transizione dal piano del vecchio acquisto a quello del nuovo acquisto.
Passare da un piano all'altro tra gli abbonamenti o ignorare la modalità di sostituzione predefinita
Se l'utente sta cambiando i prodotti dell'abbonamento, acquistando un altro abbonamento o se vuoi ignorare la modalità di sostituzione predefinita per qualsiasi motivo, specifica il tasso di proporzionamento in fase di esecuzione come parte dei parametri del flusso di acquisto.
Per fornire correttamente SubscriptionUpdateParams nell'ambito della configurazione del flusso di acquisto in fase di esecuzione, tieni presente le seguenti limitazioni:
- Quando esegui l'upgrade, il downgrade o avvii il passaggio a un piano prepagato da un piano prepagato, un piano con rinnovo automatico o un piano 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 viene mostrato un errore all'utente. - Quando passi da un piano prepagato o con rinnovo automatico a un piano con rinnovo automatico all'interno dello stesso abbonamento, le modalità di ripartizione valide sono
CHARGE_FULL_PRICEeWITHOUT_PRORATION. Se specifichi un'altra modalità di proporzionamento, l'acquisto non va a buon fine e viene mostrato un errore all'utente. - Non è consentito passare da un piano base con rate a un piano base senza rate all'interno dello stesso prodotto in abbonamento.
Esempi e comportamenti di sostituzione
Per capire come funziona ogni modalità di ripartizione, considera lo scenario seguente:
Samwise ha un abbonamento ai contenuti online dell'app Country Gardener. Ha un abbonamento mensile alla versione Tier 1 dei contenuti, che è 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 Livello 2, che include gli aggiornamenti dei video e costa 36$all'anno.
Durante l'upgrade dell'abbonamento, lo sviluppatore seleziona una modalità di ripartizione proporzionale. Il seguente elenco descrive l'impatto di ogni modalità di ripartizione proporzionale sull'abbonamento di Samwise:
WITH_TIME_PRORATION
L'abbonamento di Samwise al livello 1 termina immediatamente. Poiché ha pagato per un mese intero (1-30 aprile), ma ha eseguito l'upgrade a metà del periodo di abbonamento, la metà dell'abbonamento di un mese (1 $) viene applicata al nuovo abbonamento. Tuttavia, poiché il nuovo abbonamento costa 36 $all'anno, il saldo del credito di 1 $viene pagato solo per 10 giorni (dal 16 al 25 aprile); pertanto, il 26 aprile gli vengono addebitati 36 $per un nuovo abbonamento e altri 36 $il 26 aprile di ogni anno successivo.
Devi chiamare 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
SUBSCRIPTION_PURCHASED notifica in tempo reale per lo sviluppatore.
CHARGE_PRORATED_PRICE
Questa modalità può essere utilizzata perché il prezzo dell'abbonamento al livello 2 per unità di tempo ($36/anno = 3 $/mese) è superiore al prezzo dell'abbonamento al livello 1 per unità di tempo ($2/mese). L'abbonamento di Samwise al livello 1 termina immediatamente. Poiché ha pagato per un mese intero, ma ne ha utilizzato solo la metà, al nuovo abbonamento viene applicata la metà dell'abbonamento di un mese (1 $). 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 a Samwise vengono addebitati 36 $per il nuovo livello di abbonamento e altri 36 $il 1° maggio di ogni anno successivo.
Devi chiamare 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
SUBSCRIPTION_PURCHASED notifica in tempo reale per lo sviluppatore.
WITHOUT_PRORATION
A Samwise viene eseguito immediatamente l'upgrade dell'abbonamento di livello 1 al livello 2 senza costi aggiuntivi. 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 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
SUBSCRIPTION_PURCHASED notifica in tempo reale per lo sviluppatore.
DEFERRED
L'abbonamento di Samwise al livello 1 continuerà fino alla scadenza del 30 aprile. Il 1° maggio, l'abbonamento al livello 2 entra in vigore e a Samwise vengono addebitati 36 $per il suo nuovo livello di abbonamento.
Devi chiamare 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
SUBSCRIPTION_PURCHASED notifica in tempo reale per lo sviluppatore. A quel punto, dovresti elaborare l'acquisto come faresti con qualsiasi altro nuovo acquisto. In particolare, assicurati di confermare il nuovo acquisto. Tieni presente che il campo startTime del nuovo abbonamento viene compilato nel momento in cui la sostituzione diventa effettiva, ovvero 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 di Samwise al livello 1 termina immediatamente. Il suo abbonamento Livello 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à, al nuovo abbonamento viene applicata la metà dell'abbonamento di un mese (1 $). Poiché il nuovo abbonamento costa 36 $all'anno, al suo periodo di abbonamento verrà aggiunto 1/36 di anno (~10 giorni). Pertanto, il prossimo addebito di Samwise sarà tra 1 anno e 10 giorni da oggi per 36 $. Dopodiché, gli verranno addebitati 36 $ogni anno successivo.
Quando scegli una modalità di ripartizione proporzionale, assicurati di consultare i nostri consigli per la sostituzione.
Attivare le modifiche dell'abbonamento in-app
La tua app può offrire agli utenti un upgrade o un downgrade seguendo gli stessi passaggi utilizzati per il lancio 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:
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 per la sostituzione
La tabella seguente mostra diversi scenari di ripartizione proporzionale, oltre a ciò che consigliamo per ciascun caso:
| Scenario | Modalità di sostituzione consigliata | Risultato |
|---|---|---|
| Upgrade a un livello più costoso | CHARGE_PRORATED_PRICE |
L'utente riceve immediatamente l'accesso mantenendo lo stesso periodo di fatturazione. |
| Downgrade a un livello meno costoso | DEFERRED |
L'utente ha già pagato per il livello più costoso, quindi mantiene l'accesso fino alla data di fatturazione successiva. |
| Eseguire l'upgrade durante una prova senza costi, mantenendo la prova | WITHOUT_PRORATION |
L'utente mantiene l'accesso alla prova senza costi, ma esegue l'upgrade a un livello superiore per il rimanente periodo di prova. |
| Eseguire l'upgrade durante una prova senza costi: interruzione dell'accesso alla prova senza costi | CHARGE_PRORATED_PRICE |
L'utente riceve immediatamente l'accesso al nuovo livello, ma non ha più accesso alla prova senza costi. |
Gestire gli acquisti per la modifica dell'abbonamento
Le modifiche del piano sono nuovi acquisti per tutti i termini e scopi e devono essere elaborate e confermate come tali al termine del flusso di fatturazione. Oltre a elaborare il nuovo acquisto in modo appropriato, devi ritirare l'acquisto che verrà sostituito.
Il comportamento in-app è lo stesso di qualsiasi nuovo acquisto. 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 valore linkedPurchaseToken nella
risorsa subscription quando un acquisto sostituisce un altro
esistente. Assicurati di invalidare il token fornito in linkedPurchaseToken per assicurarti che il vecchio token non venga utilizzato per accedere ai tuoi servizi. Per informazioni su come gestire gli acquisti di upgrade e downgrade, consulta Upgrade, downgrade e riregistrazioni.
Quando ricevi il nuovo token di acquisto, segui la stessa procedura di verifica utilizzata 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 i diritti rimanenti nel vecchio piano prima di iniziare a utilizzare il nuovo piano.
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 avviene alla data di rinnovo successiva, dopodiché il nuovo prodotto viene restituito.
In passato, era possibile ottenere questa esperienza utente con ProrationMode.DEFERRED, ora deprecato, ma ProrationMode.DEFERRED è deprecato con Libreria Fatturazione Play 6. Consulta la tabella seguente per capire dove il comportamento è diverso:
Tempo |
ProrationMode.DEFERRED (deprecato) |
ReplacementMode.DEFERRED |
Subito dopo il completamento del flusso di acquisto (app) |
Il diritto al vecchio piano rimane valido fino alla successiva data di rinnovo. Per assicurarsi che l'app fornisca il diritto corretto, Il nuovo token di acquisto non viene visualizzato, pertanto non può essere elaborato in questo momento. |
Il nuovo token di acquisto viene visualizzato, quindi a questo punto dovrebbe essere elaborato tenendo conto della data in cui deve avvenire la sostituzione. |
Subito dopo il completamento del flusso di acquisto (backend) |
Il parametro RTDN SUBSCRIPTION_PURCHASED non viene inviato dopo il flusso di acquisto. Il backend non è ancora a conoscenza del nuovo acquisto. |
L'RTND SUBSCRIPTION_PURCHASED con il vecchio product_id 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 un valore "startTime" che indica la data e l'ora dell'acquisto con due elementi pubblicitari:
SUBSCRIPTION_EXPIRED inviato per il token di acquisto vecchio. Quando viene chiamato il metodo purchases.subscriptionsv2.get con il token di acquisto vecchio, viene visualizzato come 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 è ora visualizzato, quindi dovrebbe essere elaborato. |
Il nuovo acquisto dovrebbe essere già stato elaborato quando il flusso di acquisto è andato a buon fine, quindi l'app non dovrebbe intraprendere alcuna azione speciale, oltre a garantire che venga concesso il diritto corretto. |
In caso di sostituzione: primo rinnovo dopo il flusso di acquisto (backend) |
Il nuovo acquisto ora può essere elaborato e confermato quando viene inviato il primo RTDN SUBSCRIPTION_RENEWED. Il valore |
Il nuovo acquisto è stato elaborato e confermato quando è stato inviato l'RTND SUBSCRIPTION_PURCHASED per il nuovo token di acquisto e registrato come "startTime". Con ReplacementMode.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 chiami il metodo purchases.subscriptionsv2.get con il nuovo token di acquisto, viene restituito un acquisto con due elementi pubblicitari:
|
D'ora in poi, al posto del valore deprecated ProrationMode.DEFERRED, deve essere utilizzato ReplacementMode.DEFERRED, in quanto presenta lo stesso comportamento per quanto riguarda le modifiche dei diritti, ma offre un modo per gestire l'acquisto più coerente con i comportamenti per altri nuovi acquisti.
Gestione dei clienti
Con le notifiche in tempo reale per lo sviluppatore, puoi rilevare in tempo reale quando un utente decide di annullare. Quando un utente annulla l'abbonamento, ma prima che questo 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 tabella seguente descrive diversi scenari di abbonamento, nonché le azioni di recupero 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à di recupero | Abbonamento in-app | Ripristina | Abbonamento in-app | Riabbonati |
| L'utente completa il flusso di pagamento | Sì | No | Sì | Sì |
| L'abbonamento dell'utente rimane associato allo stesso SKU | L'utente può registrarsi per lo stesso SKU o per uno diverso | Sì | L'utente può registrarsi per lo stesso SKU o per uno diverso | Sì |
| Crea un nuovo token di acquisto | Sì | No | Sì | Sì |
| Attivata per impostazione predefinita | No | Sì, è richiesta l'assistenza per tutti gli sviluppatori | No |
App senza Libreria fatturazione 2.0 o versioni successive: no App con Libreria fatturazione 2.0 e versioni successive: sì. Gli sviluppatori possono disattivare la funzionalità nella console. |
| Quando viene addebitato l'importo all'utente |
Se utilizzi lo stesso SKU: fine del periodo di fatturazione corrente. Se utilizzi un SKU diverso: dipende dalla modalità di ripartizione. |
Fine del periodo di fatturazione corrente | Immediatamente | Immediatamente |
| Implementazione richiesta | Fornisci un'interfaccia utente per la registrazione di nuovo nella tua app |
Rilevare la modifica dello stato dell'abbonamento Link diretto al Play Store |
Fornisci un'interfaccia utente per la registrazione di nuovo nella tua app | Gestire gli acquisti esterni all'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 previsto per i nuovi abbonati. Assicurati che l'interfaccia utente rifletta il fatto che l'utente ha già un abbonamento. Ad esempio, potresti voler mostrare la data di scadenza e il prezzo ricorrente correnti dell'utente con un pulsante Riattiva.
Nella maggior parte dei casi, ti consigliamo di offrire all'utente lo stesso prezzo e lo stesso SKU per cui ha già sottoscritto un abbonamento, come segue:
- Avvia un nuovo acquisto di abbonamento con lo stesso SKU.
- Il nuovo abbonamento sostituisce quello precedente e si rinnova nella stessa data di scadenza. Il vecchio abbonamento viene contrassegnato immediatamente come scaduto.
- Ad esempio, Achille ha un abbonamento all'app Example Music, che scade il 1° agosto. Il 10 luglio, si abbona di nuovo all'abbonamento mensile allo stesso prezzo mensile. Il nuovo abbonamento viene proporzionato con il credito rimanente, è attivo immediatamente e si rinnova comunque il 1° agosto.
Se vuoi offrire un prezzo diverso, ad esempio una nuova prova senza costi o un sconto per il ricoinvolgimento, puoi offrire all'utente un 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 nella stessa data di scadenza. All'utente viene addebitato il prezzo del nuovo SKU, inclusi eventuali prezzi di introduzione, alla data di scadenza originale. Se il vecchio abbonamento è stato creato utilizzando un ID account offuscato, lo stesso ID deve essere passato a
BillingFlowParamsper gli upgrade e i downgrade. - Ad esempio, Achille ha un abbonamento all'app di musica di esempio, che scade il 1° agosto. Il 10 luglio si abbona nuovamente a un abbonamento annuale a prezzo di lancio. Il nuovo abbonamento viene attivato 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 nello SKU per il ricoinvolgimento, 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 prova senza costi per app.
Quando ricevi il token di acquisto,
esegui l'acquisto come faresti con un nuovo abbonamento. Inoltre, l'API Google Play Developer
restituisce un linkedPurchaseToken nella risorsa dell'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
Se 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, rimangono invariati lo stesso abbonamento e lo stesso token di acquisto.
Per ulteriori informazioni sul ripristino degli abbonamenti, consulta la sezione Ripristini.
Dopo la scadenza dell'abbonamento - in-app
Puoi consentire agli abbonati scaduti di abbonarsi di nuovo all'interno della tua app applicando lo stesso flusso di acquisto di prodotti in-app previsto per i nuovi abbonati. Tieni presente quanto segue:
- Per offrire agli utenti uno sconto, ti consigliamo di offrire un ID prodotto con prezzi speciali per il tuo abbonamento, chiamato anche SKU per il recupero. Puoi fornire l'offerta nella tua app oppure puoi informare l'utente dell'offerta al di fuori dell'app, ad esempio via email.
- Per avviare un abbonamento per il ricoinvolgimento, avvia il flusso di acquisto nella tua app per Android utilizzando la 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 per il ricoinvolgimento, 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 prova senza costi per app.
- Se l'utente si abbona di nuovo allo stesso SKU, non è più idoneo per le prove senza costi o il prezzo di lancio. Assicurati che la tua UI rifletta questo aspetto.
Quando ricevi il token di acquisto,
esegui 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 questa opzione è attivata, gli utenti possono riabbonarsi allo stesso SKU fino a un anno dopo la scadenza facendo clic su Riabbonati nel Centro abbonamenti Google Play. Verrà generato un nuovo token di abbonamento e acquisto.
La sottoscrizione di un nuovo abbonamento è considerata un acquisto esterno all'app, quindi assicurati di seguire le best practice per la gestione degli acquisti effettuati al di fuori della tua app.
Promuovere l'abbonamento
Puoi creare codici promozionali per offrire agli utenti selezionati una prova senza costi estesa a un abbonamento esistente. Per scoprire di più, consulta Codici promozionali.
Per le prove senza costi, Google Play verifica che l'utente abbia un metodo di pagamento valido prima di avviare la prova. Alcuni utenti potrebbero visualizzare questa verifica come una preautorizzazione o un addebito sul loro metodo di pagamento. Questa preautorizzazione o questo addebito è temporaneo e viene successivamente stornato o rimborsato.
Al termine del periodo di prova, all'utente viene addebitato il prezzo intero dell'abbonamento tramite il metodo di pagamento scelto.
Se un utente annulla un abbonamento in qualsiasi momento durante il periodo di prova senza costi, l'abbonamento rimane attivo fino alla fine del periodo di prova e non gli viene addebitato alcun costo 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 la possibilità di annullare l'abbonamento nella tua app o sul tuo sito web. La tua app deve gestire queste cancellazioni come descritto in Annullamenti.
- Rimborso: quando effettui il rimborso, 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 più del pagamento più recente o se vuoi emettere un rimborso parziale, devi utilizzare Google Play Console.
- Revoca: quando esegui la revoca, l'utente perde immediatamente l'accesso all'abbonamento. Questo valore 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 utilizzarlo. L'app deve gestire queste cancellazioni come descritto in Revoche.
La seguente tabella illustra le differenze tra annullamento, rimborso e revoca.
| Interrompe il rinnovo | Rimborso del denaro | Revoca l'accesso | |
| Annulla | Sì | No | No |
| Rimborso | No | Sì | No |
| Rimuovi | Sì | Sì | Sì |
Posticipare 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 ha un abbonamento ai tuoi contenuti con accesso completo, ma non gli viene addebitato alcun importo. La data di rinnovo dell'abbonamento viene aggiornata alla nuova data.
Per i piani prepagati, puoi utilizzare l'API di posticipazione della fatturazione per posticipare la data di scadenza.
La fatturazione differita ti consente di:
- Offrire agli utenti l'accesso senza costi come offerta speciale, ad esempio una settimana senza costi per l'acquisto di un film.
- Offrire l'accesso senza costi ai clienti come gesto di buona volontà.
La fatturazione può essere differita per un periodo minimo di un giorno e massimo 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 ai contenuti online dell'app Fishing Quarterly. Di solito le viene addebitato 1,25 £ il primo giorno di ogni mese. A marzo ha partecipato a un sondaggio online per il publisher di 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 programmata del 1° aprile. A Darcy non viene addebitato alcun importo per aprile o l'inizio di maggio e ha ancora accesso ai contenuti. Il 15 maggio le viene addebitata la normale tariffa di abbonamento di 1, 25 £ per il mese. La prossima data di rinnovo è il 15 giugno.
Quando posticipi la fatturazione, ti consigliamo di informare l'utente via email o all'interno dell'app per comunicargli che la data di fatturazione è cambiata.
Gestione dei rifiuti di pagamento
In caso di problemi di pagamento con il rinnovo di un abbonamento, Google tenterà di rinnovarlo periodicamente 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 invitandolo ad aggiornare il metodo di pagamento.
In caso di rifiuto del pagamento, l'abbonamento entra in un periodo di tolleranza, se abilitato. 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 le probabilità di recupero dell'abbonamento in caso di rifiuto del pagamento, puoi informare l'utente di un problema di pagamento e chiedergli di risolverlo.
Puoi farlo 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 e offrirà loro l'opportunità di correggere il 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 visualizzato.
Se l'utente ha recuperato correttamente 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 all'utente la messaggistica in-app, utilizza
BillingClient.showInAppMessages().
Ecco un esempio di attivazione del flusso di messaggistica 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. } } });
Gestire le transazioni in attesa relative agli abbonamenti
Le transazioni in attesa possono verificarsi durante l'acquisto iniziale, il ricaricamento, l'upgrade o il downgrade. L'acquisto dell'abbonamento inizia con lo stato
SUBSCRIPTION_STATE_PENDING prima di passare allo stato
SUBSCRIPTION_STATE_ACTIVE. Se la transazione è scaduta o annullata dall'utente, viene trasferita a SUBSCRIPTION_STATE_PENDING_PURCHASE_EXPIRED. Devi
e devi aggiornare il diritto dell'utente solo al termine 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. Al client RTDN viene inviato un messaggio SubscriptionNotification di tipo SUBSCRIPTION_PURCHASED. 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 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.
Il ricaricamento, l'upgrade o il downgrade con transazioni in attesa comporta modifiche dello stato sia per l'abbonamento precedente sia per quello nuovo. Quando l'utente avvia una transazione in attesa di caricamento, upgrade o downgrade, la tua app riceve un Purchase per il vecchio abbonamento con un oggetto PendingPurchaseUpdate. Al momento, l'utente possiede ancora il vecchio abbonamento e non ha ancora ottenuto il nuovo abbonamento. La chiamata a 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 messaggio Purchase con il token di acquisto di primo livello impostato per il nuovo abbonamento e lo stato impostato su PURCHASED. Al client RTDN viene inviato un messaggio SubscriptionNotification di tipo
SUBSCRIPTION_PURCHASED. Solo in questo momento, devi sostituire il vecchio token di acquisto con il nuovo e aggiornare l'accesso dell'utente ai contenuti. Se la transazione scade o viene annullata, al client RTDN viene inviato un messaggioSubscriptionNotification con tipoSUBSCRIPTION_PENDING_PURCHASE_CANCELED. In questi
casi, l'utente dovrebbe comunque avere accesso ai contenuti del vecchio abbonamento.