Informazioni sugli abbonamenti

Questo argomento descrive come gestire gli eventi del ciclo di vita degli abbonamenti, ad esempio rinnovi e scadenze. Descrive inoltre funzionalità aggiuntive dell'abbonamento. ad esempio offrire promozioni e consentire agli utenti di gestire le proprie abbonamenti.

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

Panoramica degli abbonamenti

Un abbonamento rappresenta una serie di vantaggi a cui gli utenti possono accedere durante per un determinato periodo di tempo. Ad esempio, un abbonamento potrebbe concedere a un utente per accedere a un servizio di streaming musicale.

Puoi avere più abbonamenti all'interno della stessa app, per rappresentano una serie di vantaggi o livelli diversi di un singolo una serie di vantaggi (ad es. 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'etichetta offerta di lancio per gli utenti che non hanno mai sottoscritto un abbonamento 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 la propria 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 la versione originale acquisto. Non è necessario indicare che un acquisto è una ricarica.

Le ricariche del piano prepagato utilizzano sempre CHARGE_FULL_PRICE di sostituzione e non devi impostarla esplicitamente. All'utente viene immediatamente addebitato un importo per l'intero periodo di fatturazione e il loro diritto viene esteso per la durata specificata nella ricarica.

Dopo una ricarica, i seguenti campi nella Purchase vengono aggiornati per riflettere l'acquisto di una ricarica più recente:

  • ID ordine
  • Data/ora acquisto
  • Firma
  • Token per l'acquisto
  • Confermato

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

  • Nome pacchetto
  • Stato acquisto
  • Prodotti
  • Rinnovo automatico

Conferma acquisto prepagato

Come per gli abbonamenti con rinnovo automatico, devi confermare i piani prepagati dopo l'acquisto. Sia l'acquisto iniziale che le eventuali ricariche devono essere riconosciuto. Per ulteriori informazioni, vedi Elaborazione degli acquisti.

Considerata la potenziale durata dei piani prepagati brevi, è importante conferma l'acquisto il prima possibile.

I piani prepagati con una durata di almeno una settimana devono essere confermati entro tre giorni.

I piani prepagati con una durata inferiore a una settimana devono essere confermati a metà della durata del piano. Ad esempio, gli sviluppatori hanno 1,5 giorni di tempo sottoscrivi un piano prepagato di tre giorni.

Integrazione di abbonamenti rateali

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

Ulteriori considerazioni sugli abbonamenti a rate:

  • Paesi in cui sono disponibili: la funzionalità per gli abbonamenti a rate è disponibile soltanto in Brasile, Francia, Italia e Spagna (controlla la disponibilità della console su Console).
  • Impostazione del prezzo: quando imposti il prezzo di un abbonamento a rate sulla Console, il prezzo rappresenta l'importo del pagamento mensile. Questo, combinato con il periodo di impegno impostato, genera l'importo totale per l'abbonamento nella schermata di acquisto.
  • Periodo di impegno: la durata totale dell'abbonamento iniziale. dell'impegno, durante il quale sono richiesti pagamenti mensili. Ad esempio, se un il piano base ha un periodo di impegno di 15 mesi, l'utente effettuerà 15 mesi pagamenti in questo periodo.
  • Rinnovi: nel contesto degli abbonamenti a rate, "rinnovo" significa la conclusione di un periodo di impegno, ovvero periodo di impegno iniziale periodo di impegno successivo. Dopo la registrazione iniziale, il primo rinnovo si verifica al completamento dell'intero periodo di impegno iniziale. Successiva i rinnovi avvengono al termine di ogni successivo periodo di impegno. La i tipi di rinnovo per gli abbonamenti a rate possono essere "Rinnovo automatico mensile" o "si rinnova automaticamente per la stessa durata". Per il "rinnovo automatico mensile", non è previsto successivo e il piano si comporta come un abbonamento mensile in cui ogni addebito mensile per l'abbonamento costituisce un rinnovo.
  • Periodo di fatturazione: nel contesto degli abbonamenti a rate, si riferisce all'intervallo ricorrente durante il quale vengono effettuati i singoli pagamenti, come specificato nel piano base.
  • Variazione dei piani e comportamenti di variazione di prezzo: per le variazioni di prezzo e degli annullamenti, l'impegno è fermo. Ciò significa che se un utente vuole annullare o uno sviluppatore vuole cambiare il prezzo, la modifica viene applicata in data alla fine di un periodo di impegno. Per le modifiche al piano, l'impegno non è fisso. Ciò significa che la modifica del piano non deve attendere il termine di un periodo di impegno effettivo, avrà effetto immediato o al pagamento successivo in base alla modalità di sostituzione impostata.
  • Modifica del piano con lo stesso abbonamento: modifica del piano da un piano base a rate a un piano base senza rate per lo stesso prodotto in abbonamento non è consentito.
  • Notifiche in tempo reale per lo sviluppatore (RTDN): A SUBSCRIPTION_CANCELLATION_SCHEDULED RTDN viene inviato immediatamente annullamento avviato dall'utente quando i pagamenti rimangono per il periodo di impegno. L'annullamento è in attesa e entrerà in vigore solo alla fine del durante il 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 loro pagamenti mensili, soggetti agli stessi termini di tutti gli altri abbonamenti. Gli sviluppatori non vengono pagati in anticipo quando l'utente si registra per la rata abbonamento.

  • Riscossioni di pagamenti persi: se un utente non riesce a effettuare alcuna rata. pagamenti per gli abbonamenti, né Google né lo Sviluppatore tenteranno di raccogliere i pagamenti mancanti o insoluti da parte dell'utente, ad eccezione del fatto che Google può riprovare periodicamente a eseguire il pagamento durante il Periodo di tolleranza applicabile; Periodo di sospensione dell'account in conformità alle consuete prassi per i nuovi pagamenti. Google non sarà responsabile nei confronti dello Sviluppatore di eventuali pagamenti rimanenti pagamenti rateali.

  • Disponibilità della Libreria Fatturazione Play: il campo installmentDetails è disponibile solo disponibile per PBL 7 o versioni successive. Per PBL 5 e versioni successive, la rata abbonamento 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

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 nel aspetto e design naturale.

Puoi includere un link diretto dalla tua app agli abbonamenti di Google Play per gli abbonamenti non scaduti, che puoi verificare utilizzando Campo subscriptionState della risorsa abbonamento. Sulla base di questi, esistono diversi modi per creare link diretti a Google Play Centro abbonamenti del negozio.

Utilizza il seguente URL per indirizzare gli utenti alla pagina che mostra tutti i loro degli abbonamenti, come mostrato nelle figure 1 e 2:

https://play.google.com/store/account/subscriptions
La schermata Abbonamenti del Play Store mostra lo stato di tutti gli abbonamenti fatturati su Google Play di un utente.
Figura 1. La schermata Abbonamenti del Play Store mostra lo stato di tutti gli abbonamenti fatturati su Google Play di un utente.


Tocca un abbonamento per visualizzare ulteriori dettagli.
Figura 2. Tocca un abbonamento per vedere altri i dettagli.

Questo link diretto potrebbe essere utile per aiutare un utente a ripristinare un abbonamento annullato dal centro abbonamenti del Play Store.

Per collegarti direttamente alla pagina di gestione di un abbonamento non scaduto, indica il nome del pacchetto e i productId associati all'abbonamento acquistato. A determinare in modo programmatico il valore productId per un abbonamento, una query esistente backend dell'app o chiama BillingClient.queryPurchasesAsync() per un elenco di abbonamenti associati a un determinato utente. Ogni abbonamento contiene productId corrispondente nelle informazioni sullo stato dell'abbonamento. Ogni oggetto SubscriptionPurchaseLineItem associato a un l'acquisto dell'abbonamento contiene il valore productId associato al abbonamento acquistato dall'utente nell'elemento pubblicitario.

Utilizza il seguente URL per indirizzare gli utenti a una specifica gestione degli abbonamenti schermata, sostituendo "your-sub-product-id" e "your-app-package" con productId e 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 metodi di pagamento e accedere alle funzionalità incluse l'annullamento, la nuova sottoscrizione e la messa in pausa.

Consenti agli utenti di eseguire l'upgrade, il downgrade o modificare il proprio abbonamento

Puoi offrire agli abbonati esistenti varie opzioni per modificare di abbonamento per soddisfare meglio le loro esigenze:

  • Se vendi più livelli di abbonamento, ad esempio "base" e "premium" abbonamenti, puoi consentire agli utenti di passare da un livello all'altro acquistando un'altra il piano base o l'offerta dell'abbonamento.
  • Puoi consentire agli utenti di modificare il periodo di fatturazione corrente, ad esempio cambiando passando da un piano mensile a un piano annuale.
  • Puoi anche consentire agli utenti di passare dal rinnovo automatico ai piani prepagati e viceversa.

Puoi incoraggiare queste variazioni proponendo offerte di abbonamento a Offrire uno sconto agli utenti idonei. Ad esempio, potresti creare un'offerta offrendo uno sconto del 50% sul primo anno passando da un abbonamento mensile a piano annuale e limitare questa offerta agli utenti abbonati a un piano mensile piano che non ha acquistato questa offerta. Ulteriori informazioni sull'idoneità all'offerta criteri sono disponibili nel Centro assistenza

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

Questa app offre tre livelli di abbonamento.
Figura 3. L'app prevede tre livelli di abbonamento.

La tua app potrebbe mostrare una schermata simile alla figura 3, che offre agli utenti la possibilità di apportare modifiche l'abbonamento. In ogni caso, dovrebbe essere chiaro agli utenti qual è piano di abbonamento e le opzioni a sua disposizione per modificarlo.

Quando gli utenti decidono di eseguire l'upgrade, il downgrade o modificare il proprio abbonamento, specifica una modalità di sostituzione che determini in che modo il valore proporzionale del il periodo di fatturazione corrente e quando si verifica un cambiamento del diritto.

Modalità di sostituzione

La tabella seguente elenca le modalità di sostituzione disponibili e l'utilizzo di esempio. e il conteggio dei pagamenti considerati pagati.

Modalità di sostituzione

Descrizione

Esempio di utilizzo

Pagamenti impegnati registrati come pagati (per la sostituzione di abbonamenti rateali)

WITH_TIME_PRORATION

L'upgrade o il downgrade dell'abbonamento viene eseguito immediatamente. L'eventuale periodo di tempo rimanente viene adeguato in base alla differenza di prezzo e viene 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.

0

CHARGE_PRORATED_PRICE

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 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

CHARGE_FULL_PRICE

L'upgrade o il downgrade dell'abbonamento viene eseguito immediatamente e l'utente può addebitato immediatamente il prezzo intero del nuovo diritto. Il valore rimanente dell'abbonamento precedente vengono trasferite per la stessa oppure proporzionale al tempo nel caso di passaggio a un altro diritto.

Nota: se il nuovo abbonamento prevede una prova senza costi o offerta di lancio, all'utente viene addebitato 0 $o il prezzo di lancio valida 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).

WITHOUT_PRORATION

L'upgrade o il downgrade dell'abbonamento viene eseguito immediatamente e il nuovo prezzo viene addebitato al momento del rinnovo dell'abbonamento. Il ciclo di fatturazione rimane invariato.

Esegui l'upgrade a un livello di abbonamento superiore mantenendo l'eventuale periodo senza costi rimanente.

0

DEFERRED

L'upgrade o il downgrade dell'abbonamento viene eseguito solo al rinnovo, 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 ripristinare il piano originale o avviare una nuova modifica del piano differito. 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 saperne di più sulle varie applicazioni di upsell e recupero eseguire l'upgrade o il downgrade delle offerte, leggi la guida su offerte e promozioni.

Impostare la modalità di sostituzione per un acquisto

Puoi utilizzare modalità di sostituzione diverse a seconda del tipo di abbonamento transizioni in base alle tue preferenze e alla tua logica di business. Questa sezione spiega come impostare una modalità sostitutiva per una modifica a 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. Questo dell'impostazione ti consente di scegliere quando addebitare l'importo agli abbonati attuali se acquistano un altro piano base o un'offerta diversa per lo stesso abbonamento oppure riabbonarti dopo un l'annullamento. Le opzioni disponibili sono Carica immediatamente, 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 cambiare piani base all'interno dello stesso abbonamento.

Ad esempio, se implementi un'offerta di rimborso per lo stesso piano dopo il l'utente annulla l'abbonamento, ma prima della scadenza 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 configurato nell'abbonamento e gestisce automaticamente la transizione del piano dal vecchio acquisto a quello nuovo.

Cambia i piani tra gli abbonamenti o sostituisci la modalità di sostituzione predefinita

Se l'utente cambia prodotti in abbonamento e acquista un altro abbonamento o se vuoi sostituire la modalità di sostituzione predefinita devi specificare il tasso proporzionale in fase di esecuzione nell'ambito del flusso di acquisto parametri.

Per fornire correttamente SubscriptionUpdateParams nell'ambito dell'acquisto del runtime configurazione del flusso, tieni presente le seguenti restrizioni:

  • Quando esegui l'upgrade, il downgrade o quando esegui il passaggio dello stesso abbonamento a una piano prepagato da un piano prepagato, un piano con rinnovo automatico o un piano di rateizzazione, l'unico la modalità di sostituzione consentita è CHARGE_FULL_PRICE. Se specifichi qualsiasi altra modalità di sostituzione, l'acquisto non va a buon fine e viene mostrato un errore all'utente.
  • Quando cambi piano all'interno dello stesso abbonamento a un piano con rinnovo automatico da un piano prepagato o con rinnovo automatico, modalità di ripartizione valide sono CHARGE_FULL_PRICE e WITHOUT_PRORATION. Se specifichi qualsiasi altra in modalità proporzionale, l'acquisto non va a buon fine e viene mostrato un errore all'utente.
  • Cambio di piano all'interno dello stesso prodotto in abbonamento da una base rateale un piano base senza rate non è consentito.

Esempi e comportamenti di sostituzione

Per comprendere come funziona ciascuna modalità di ripartizione, considera lo scenario seguente:

Samwise ha un abbonamento ai contenuti online dell'app Country Gardener. Lui dispone di 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 del mese.

Il 15 aprile Samwise ha scelto di eseguire l'upgrade alla versione annuale del Tier 2. , che include aggiornamenti video e costa 36$all'anno.

Quando esegui l'upgrade dell'abbonamento, lo sviluppatore seleziona una modalità proporzionale. La nell'elenco seguente viene descritto in che modo ciascuna modalità di ripartizione influisce sulla sottoscrizione di Samwise:

WITH_TIME_PRORATION

L'abbonamento Tier 1 di Samwise scade immediatamente. Perché ha pagato l'intero importo mese (1-30 aprile), con upgrade a metà del periodo di abbonamento, metà del un abbonamento di un mese ($1) viene applicato al nuovo abbonamento. Tuttavia, poiché il nuovo abbonamento costa 36 $all'anno, il saldo del credito di 1 $paga solo 10 giorni (16-25 aprile); perciò il 26 aprile gli vengono addebitati 36 € per un nuovo abbonamento altri 36 $il 26 aprile di ogni anno successivo.

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

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 per volta dell'abbonamento Livello 1. unità ($2/mese). L'abbonamento Tier 1 di Samwise scade immediatamente. Perché lui pagato per un mese intero, ma ne ha utilizzato solo metà e metà dell'abbonamento di un mese ($1) viene applicato al suo nuovo abbonamento. Tuttavia, poiché il nuovo abbonamento costa 36 $/anno, i restanti 15 giorni costa 1,50 $; quindi gli viene addebitato differenza di 0,50 $per il suo 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'icona PurchasesUpdatedListener dell'app nel momento in cui l'acquisto va a buon fine e puoi recuperare il nuovo acquisto come parte una chiamata queryPurchasesAsync(). Il tuo backend riceve immediatamente SUBSCRIPTION_PURCHASED Notifica in tempo reale per lo sviluppatore.

WITHOUT_PRORATION

L'abbonamento Tier 1 di Samwise viene immediatamente aggiornato al Tier 2 senza e il 1° maggio gli vengono addebitati 36 $per il nuovo livello di abbonamento. altri 36 $il 1° maggio di ogni anno successivo.

Devi chiamare l'icona PurchasesUpdatedListener dell'app nel momento in cui l'acquisto va a buon fine e puoi recuperare il nuovo acquisto come parte una chiamata queryPurchasesAsync(). Il tuo backend riceve immediatamente SUBSCRIPTION_PURCHASED Notifica in tempo reale per lo sviluppatore.

DEFERRED

L'abbonamento Tier 1 di Samwise sarà valido fino alla scadenza del 30 aprile. Il mese di maggio In primo luogo, entra in vigore l'abbonamento Tier 2 e a Samwise viene addebitato l'importo di 36 $ il nuovo livello di abbonamento.

Devi chiamare l'icona PurchasesUpdatedListener dell'app nel momento in cui l'acquisto va a buon fine e puoi recuperare il nuovo acquisto come parte una chiamata queryPurchasesAsync(). Il tuo backend riceve immediatamente SUBSCRIPTION_PURCHASED Notifica in tempo reale per lo sviluppatore. Dovresti elabora l'acquisto nello stesso modo in cui elaboreresti qualsiasi altro nuovo acquisto a quel punto. In particolare, assicurati di confermare il nuovo acquisto. Nota che il valore startTime del nuovo abbonamento è compilato nel momento in cui entra in vigore la sostituzione, ovvero quando il vecchio scade l'abbonamento. A quel punto, riceverai un SUBSCRIPTION_RENEWED RTDN per il nuovo piano di abbonamento. Scopri di più sulle Comportamento di ReplacementMode.DEFERRED in Gestire la sostituzione differita.

CHARGE_FULL_PRICE

L'abbonamento Tier 1 di Samwise scade immediatamente. Il suo abbonamento al Tier 2 inizia oggi e gli vengono addebitati 36 $. Perché ha pagato per un mese intero, ma ha utilizzato ne viene applicata solo la metà, metà dell'abbonamento di un mese ($1) viene applicata al nuovo abbonamento. Poiché il nuovo abbonamento costa 36 $all'anno, otterrebbe 1/36 di un anno in più al periodo di abbonamento (circa 10 giorni). Pertanto, il prossimo addebito è di 1 anno e 10 giorni a partire da oggi per 36 $. Dopodiché, addebitato $36 l'anno successivo.

Quando scegli una modalità di ripartizione, assicurati di consultare le nostre consigli sulla sostituzione.

Attiva modifiche all'abbonamento in-app

L'app può offrire agli utenti un upgrade o un downgrade seguendo la stessa procedura utilizzata per l'avvio di un flusso di acquisto. Tuttavia, quando esegui l'upgrade o il downgrade, devono fornire i dettagli dell'abbonamento attuale, del futuro (upgrade downgrade) e la modalità di sostituzione da utilizzare, come illustrato in 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 scenari di proporzionalità diversi insieme agli elementi su cui consigliati per ogni scenario:

Scenario Modalità di sostituzione consigliata Risultato
Upgrade a un livello più costoso CHARGE_PRORATED_PRICE L'utente riceve immediatamente l'accesso, mantenendo la stessa fatturazione punto.
Downgrade a un livello meno costoso DEFERRED L'utente ha già pagato per il livello più costoso, quindi può fino alla successiva data di fatturazione.
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 resto della prova.
Upgrade durante il periodo di prova senza costi; accesso alla prova senza costi terminato CHARGE_PRORATED_PRICE L'utente riceve immediatamente l'accesso al nuovo livello, ma non più offre una prova senza costi.

Gestire gli acquisti di modifica dell'abbonamento

Le modifiche di 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 correttamente. Oltre a elaborare il nuovo acquisto in modo appropriato, ritirare l'acquisto che sta per essere sostituito.

Il comportamento in-app è lo stesso utilizzato per qualsiasi nuovo acquisto. La tua app riceve il risultato del nuovo acquisto nel tuo PurchasesUpdatedListener e i nuovo acquisto è disponibile in queryPurchasesAsync.

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

Quando ricevi il nuovo token di acquisto, segui la stessa procedura di verifica utilizzata con la verifica di un nuovo token di acquisto. Assicurati di accettare questi acquisti con BillingClient.acknowledgePurchase() da Google Play Libreria Fatturazione o Purchases.subscriptions:acknowledge da l'API Google Play Developer.

Gestire la sostituzione differita

La modalità di sostituzione differita ti consente di consentire a un utente di utilizzare nel piano precedente prima di iniziare a usare quello nuovo.

Quando utilizzi SostituzioneMode.DEFERRED per un nuovo acquisto, queryPurchasesAsync() restituisce un nuovo token di acquisto dopo l'acquisto che rimane associato al vecchio prodotto fino alla sostituzione differita avrà luogo alla data di rinnovo successiva, dopodiché il nuovo prodotto verrà restituito.

In passato potevi ottenere questa esperienza utente con la versione obsoleta ProrationMode.DEFERRED, ma ProrationMode.DEFERRED è deprecato con Play Libreria Fatturazione 6. Consulta la tabella seguente per capire dove si verifica il comportamento differisce:

Tempo

ProrationMode.DEFERRED (deprecato)

SostituzioneMode.DEFERRED

Subito dopo la riuscita del flusso di acquisto (app)

PurchasesUpdatedListener viene richiamato dopo l'acquisto con lo stato che indica se l'upgrade o il downgrade è andato a buon fine.

Il diritto al piano precedente continuerà fino alla data di rinnovo successiva. Per garantire che l'app conceda il diritto giusto, queryPurchasesAsync() restituisce un oggetto Purchase con il token di acquisto originale e il diritto originale fino a quando non viene eseguita la sostituzione.

Il nuovo token di acquisto non viene visualizzato, quindi a questo punto non può essere elaborato.

PurchasesUpdatedListener viene richiamato dopo l'acquisto con uno stato che indica se l'upgrade o il downgrade è andato a buon fine.

queryPurchasesAsync() restituisce subito l'acquisto con il nuovo token di acquisto, insieme al diritto originale associato.

Poiché viene visualizzato il nuovo token di acquisto, a questo punto deve essere elaborato e tenere conto del momento in cui verrà effettuata la sostituzione.

Subito dopo la riuscita del flusso di acquisto (backend)

L'RTDN SUBSCRIPTION_PURCHASED non viene inviato dopo il flusso di acquisto. Il backend non è ancora stato informato del nuovo acquisto.

L' ancora SUBSCRIPTION_PURCHASED RTDN con il valore product_id precedente 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 valore "startTime" che indica il tempo di acquisto con due elementi pubblicitari:

  • Una che rappresenta il vecchio diritto e ha un valore "expiryTime" in futuro. Il precedente diritto non verrà rinnovato e avrà un DeferredItemSostituzione contenente il prodotto del nuovo diritto. Questo indica una sostituzione in attesa del vecchio diritto alla scadenza.
  • Una che rappresenta il diritto appena acquistato. Non è impostato alcun valore per "expiryTime".

SUBSCRIPTION_EXPIRED è stato inviato per il token di acquisto precedente. Quando chiami il metodo purchases.subscriptionsv2.get con il token di acquisto precedente, questo risulta scaduto (il diritto per il piano precedente viene trasferito al nuovo acquisto per il tempo rimanente).

Al momento della sostituzione - primo rinnovo dopo il flusso di acquisto (app)

queryPurchasesAsync() restituisce un nuovo oggetto Purchase con il token e il diritto di acquisto nuovo.

Il nuovo token di acquisto viene visualizzato, quindi dovrebbe essere elaborato.

queryPurchasesAsync() restituisce subito l'acquisto con il nuovo token di acquisto, insieme al nuovo diritto associato.

Il nuovo acquisto dovrebbe essere già stato elaborato una volta completato il flusso di acquisto, quindi l'app non deve intraprendere alcuna azione speciale oltre ad assicurarsi che sia stato concesso il diritto corretto.

Al momento della sostituzione: primo rinnovo dopo il flusso di acquisto (backend)

Il nuovo acquisto può ora essere elaborato e confermato all'invio del primo RTDN SUBSCRIPTION_RENEWED.

linkedPurchaseToken nella risorsa di abbonamento può essere utilizzato per determinare quale utente nel backend del tuo abbonamento, se applicabile, deve essere aggiornato con il nuovo diritto.

Il nuovo acquisto è stato elaborato e confermato quando è stato inviato il RTDN SUBSCRIPTION_PURCHASED per il nuovo token di acquisto e registrato come "startTime".

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 chiami il metodo purchases.subscriptionsv2.get con il nuovo token di acquisto restituisce un acquisto con due voci:

  • Una che rappresenta il diritto precedente, con un valore "expiryTime" nel passato e nessun valore impostato per DeferredItemSostituzione.
  • Una che rappresenta il diritto new, con un valore "expiryTime" nel futuro e il flag auto_renewing_enabled attivato.

D'ora in poi deve essere utilizzato il metodo SostituzioneMode.DEFERRED al posto del modello deprecato ProrationMode.DEFERRED, in quanto presenta lo stesso comportamento riguardo al diritto cambia, ma offre un modo per gestire l'acquisto in modo più coerente comportamenti per altri nuovi acquisti.

Gestione clienti

Grazie alle notifiche in tempo reale per lo sviluppatore, puoi rilevare in tempo reale quando un l'utente decide di annullare l'operazione. Quando un utente annulla l'abbonamento, ma prima dell'abbonamento è scaduta, puoi inviargli notifiche push o messaggi in-app per chiedere a riabbonarsi.

Dopo che un utente ha annullato l'abbonamento, puoi provare a riconquistarlo nella tua app o tramite il Play Store. La tabella seguente descrive vari scenari di abbonamento, oltre alle azioni di rivincita associate e 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 ripresa Abbonamento in-app Ripristina Abbonamento in-app Riabbonati
L'utente esegue il flusso di pagamento No
L'abbonamento utente rimane associato allo stesso SKU L'utente può registrarsi per uno SKU uguale o diverso L'utente può registrarsi per uno SKU uguale o diverso
Crea un nuovo token di acquisto No
Abilitata 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 o versioni successive: Sì. Gli sviluppatori possono ritirare il consenso nella console.

Quando viene addebitato un costo all'utente

Se utilizzi lo stesso SKU: fine del periodo di fatturazione corrente.

Se utilizzi SKU diversi, questo dipende dalla modalità di ripartizione.

Fine del periodo di fatturazione corrente Immediatamente Immediatamente
Implementazione richiesta Fornire Una UI per la nuova registrazione nell'app

Rileva il cambiamento dello stato dell'abbonamento

Link diretto al Play Store

Fornire un'interfaccia utente per la nuova registrazione nell'app Gestire gli acquisti fuori dall'app

Prima della scadenza dell'abbonamento - in-app

Per gli abbonamenti annullati ma non ancora scaduti, puoi: consentire agli abbonati di ripristinare il loro abbonamento all'interno della tua app applicando il lo stesso flusso di acquisto dei prodotti in-app a quello dei nuovi abbonati. Assicurati che la UI indica che l'utente ha un abbonamento esistente. Ad esempio, potresti vuoi mostrare la data di scadenza e il prezzo ricorrente correnti dell'utente con un pulsante Riattiva.

Nella maggior parte dei casi, vorrai offrire all'utente lo stesso prezzo e lo stesso SKU che preferisce erano già sottoscritti, come segue:

  • Avvia l'acquisto di un nuovo abbonamento con lo stesso SKU.
  • Il nuovo abbonamento sostituisce quello precedente e si rinnova con la stessa scadenza data. L'abbonamento precedente viene contrassegnato immediatamente come scaduto.
  • Ad esempio, Achille ha un abbonamento all'app Musica di esempio e scade il 1° agosto. Il 10 luglio si abbona di nuovo a l'abbonamento di un mese allo stesso prezzo mensile. Il nuovo abbonamento viene ripartito proporzionalmente con il credito residuo, diventa immediatamente attivo e continua si rinnova il 1° agosto.

Se vuoi offrire un prezzo diverso, ad esempio una nuova prova senza costi o uno sconto per riconquisti, puoi offrire uno SKU diverso all'utente:

  • Avvia un upgrade o un downgrade con uno SKU diverso. utilizzando la modalità di sostituzione WITHOUT_PRORATION.
  • Il nuovo abbonamento sostituisce quello precedente e si rinnova con la stessa scadenza data. All'utente viene addebitato il prezzo del nuovo SKU, inclusi eventuali prezzi di lancio, alla data di scadenza originale. Se l'abbonamento precedente creato utilizzando un ID account offuscato, lo stesso ID dovrebbe essere passato in BillingFlowParams per upgrade e downgrade.
  • Ad esempio, Achille ha un abbonamento all'app Musica di esempio e scade 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 1° agosto
  • Se decidi di includere una prova senza costi o un prezzo di lancio nello SKU di rimborso, assicurati che l'utente sia idoneo deselezionando il Consenti una prova senza costi per app in Google Play Console, che limita l'utente a usufruire di una prova senza costi per app.

Quando ricevi il token di acquisto, elaborare l'acquisto esattamente come con un nuovo abbonamento. Inoltre, l'API Google Play Developer restituisce un 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 tuoi servizi.

Prima della scadenza dell'abbonamento: nel Play Store

Mentre l'abbonamento è stato annullato ma è ancora attivo, gli utenti possono ripristinare l'abbonamento nel centro abbonamenti di Google Play facendo clic su Riabbonati (in precedenza Ripristina). Questa operazione mantiene lo stesso abbonamento e il token di acquisto.

Abbonamenti dell'app Google Play Store in cui è visualizzata una
            abbonamento annullato con un pulsante Riabbonati
Figura 8. Account > Abbonamenti di l'app Google Play Store che mostra un abbonamento annullato con Pulsante Riabbonati.

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 richiedendo lo stesso flusso di acquisto dei prodotti in-app per i nuovi abbonati. Tieni presente seguenti:

  • Per offrire agli utenti uno sconto, potresti offrire un ID prodotto con a un prezzo speciale per il tuo abbonamento, chiamato anche SKU callback. Puoi presentare l'offerta nella tua app o informare l'utente di l'offerta al di fuori dell'app, ad esempio via email.
  • Per attivare un abbonamento con riattivazione, avvia il flusso di acquisto nel tuo App per Android che utilizza Libreria Fatturazione Google Play. È lo stesso come nel caso di un nuovo abbonamento, ma puoi determinare lo SKU a disposizione dell'utente.
  • Se decidi di includere una prova senza costi o un prezzo di lancio nel tuo rimborso SKU, assicurati che l'utente sia idoneo deselezionando il Consenti una prova senza costi per app in Google Play Console, che limita 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 prove senza costi o prezzo di lancio. Assicurati che la tua UI rispecchi questo aspetto.

Quando ricevi il token di acquisto, elaborare l'acquisto esattamente come con un nuovo abbonamento. Non riceverai un linkedPurchaseToken nella risorsa di sottoscrizione.

Dopo la scadenza dell'abbonamento: nel Play Store

.

Se l'opzione viene attivata, gli utenti possono abbonarsi nuovamente allo stesso SKU per un massimo di un anno in seguito. scadenza facendo clic su Riabbonati negli abbonamenti Google Play. Google Cloud. Verrà generato un nuovo token di abbonamento e acquisto.

Abbonamenti dell'app Google Play Store in cui è visualizzata una
            abbonamento annullato e scaduto con riabbonati e rimuovi
            pulsanti
Figura 9. Account > Abbonamenti nell'app Google Play Store che mostra un stato annullato e scaduto abbonamento con Riabbonati e Rimuovi pulsanti.

La sottoscrizione di un nuovo abbonamento è considerata un acquisto esterno all'app, quindi assicurati di segui le best practice gestire acquisti effettuati al di fuori della tua app.

Promuovi il tuo abbonamento

Puoi creare codici promozionali per offrire a utenti selezionati una prova senza costi estesa. a un abbonamento esistente. Per saperne di più, vedi 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 vedere questa verifica una trattenuta o un addebito sul proprio metodo di pagamento. Questa preautorizzazione o addebito è temporaneo e successivamente verrà annullato o rimborsato.

Al termine del periodo di prova, l'importo verrà addebitato sul metodo di pagamento dell'utente l'intero importo dell'abbonamento.

Se un utente annulla un abbonamento in qualsiasi momento durante il periodo di prova senza costi, l'abbonamento rimane attivo fino al termine del periodo di prova e non vengono l'addebito avviene al termine del periodo di prova senza costi.

Annullare, rimborsare o revocare

Puoi utilizzare lo API Google Play Developer a annulla, rimborso, o revoca 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. Il tuo deve gestire gli annullamenti 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 prodotto, ma l'errore è stato risolto. Tieni presente che per rimborsare un pagamento maggiore rispetto al pagamento più recente o se vuoi emettere un rimborso parziale, devi usare Google Play Console.
  • Revoca: quando revochi, l'utente perde immediatamente l'accesso ai abbonamento. Questa funzione può essere utilizzata, ad esempio, se c'è stato un errore che ha impedito all'utente di accedere al tuo prodotto e l'utente non vuole continuare a utilizzare il prodotto. La tua app dovrebbe gestire questi aspetti cancellazioni come descritto Revocazioni.

La seguente tabella illustra le differenze tra annullamento, rimborso e revocarlo.

Interrompi il rinnovo Rimborsare denaro Revocare l'accesso
Annulla No No
Rimborso No No
Revoca

Rimanda la fatturazione di un sottoscrittore

Puoi far avanzare la data di fatturazione successiva per un abbonato con rinnovo automatico utilizzando Purchases.subscriptions:defer dall'API Google Play Developer. Durante il periodo di differimento, l'utente viene si abbona ai tuoi contenuti con accesso completo, ma non ti viene addebitato alcun costo. La la data di rinnovo dell'abbonamento viene aggiornata alla nuova data.

Per i piani prepagati, puoi utilizzare l'API Defer billing per posticipare la scadenza nel tempo.

La fatturazione differita ti consente di:

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

La fatturazione può essere differita di un solo giorno e fino a un anno per chiamata API. Per differire ulteriormente la fatturazione, puoi chiamare di nuovo l'API prima dell'arrivo della nuova data di fatturazione.

Ad esempio, Darcy ha un abbonamento mensile ai contenuti online per App Fishing Quarterly Di solito le vengono addebitate 1,25 £ il primo giorno di mese. A marzo, ha partecipato a un sondaggio online per il publisher dell'app. Il publisher la ricompensa con sei settimane senza costi posticipando il pagamento successivo fino al 15 maggio, sei settimane dopo la precedente data di fatturazione programmata del 1° aprile. A Darcy non viene addebitato alcun costo per aprile o l'inizio di maggio e comunque ha accesso ai contenuti. Il 15 maggio le viene addebitata la normale tariffa di 1, 25 £ di abbonamento mensile. La prossima data di rinnovo è il 15 giugno.

Quando differisca, potresti voler informare l'utente via email o all'interno dell'app per informarlo che la data di fatturazione è cambiata.

Gestione dei rifiuti di pagamento

In caso di problemi di pagamento con il rinnovo di un abbonamento, Google tentare periodicamente di rinnovare l'abbonamento per un po' di tempo prima di annullarlo. Questo periodo di recupero può essere composto da un periodo di tolleranza, seguito da una sospensione dell'account punto. Durante questo periodo, Google invia all'utente email e notifiche che chiede di aggiornare il metodo di pagamento.

Al momento del rifiuto del pagamento, l'abbonamento entra in un periodo di tolleranza punto, se uno è 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 account di Google. Durante sospensione dell'account, devi assicurarti che l'utente non abbia accesso diritti di abbonamento.

Puoi specificare la durata del periodo di tolleranza per ciascun piano base con rinnovo automatico. in Google Play Console. Specificare lunghezze inferiori a I valori predefiniti potrebbero ridurre il numero di abbonamenti recuperati dopo il pagamento rifiuta.

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

Puoi farlo autonomamente, come descritto nella sezione punto e sospensione dell'account oppure puoi implementare l'API In-App Messaging, in cui Google mostra un messaggio per gli utenti della 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 offrire loro l'opportunità di sistemare il pagamento senza uscire dall'app.

Snackbar che comunica all'utente la correzione del pagamento
Figura 20. Snackbar che avvisa l'utente di risolvere il problema relativo al pagamento.

Ti consigliamo di chiamare questa API ogni volta che l'utente apre l'app per determinare se il messaggio deve essere mostrato o meno.

Se l'utente ha recuperato correttamente l'abbonamento, riceverai un codice di risposta SUBSCRIPTION_STATUS_UPDATED insieme a un token per l'acquisto. Devi quindi utilizzare questo token di acquisto per chiamare il l'API Google Play Developer e aggiorna lo stato dell'abbonamento nell'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:

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 sospeso degli abbonamenti

Le transazioni in attesa possono verificarsi durante l'acquisto iniziale, la ricarica, l'upgrade o eseguire il downgrade. L'acquisto dell'abbonamento inizia con SUBSCRIPTION_STATE_PENDING prima della transizione a SUBSCRIPTION_STATE_ACTIVE. Se la transazione è scaduta o annullata entro il utente, va all'indirizzo SUBSCRIPTION_STATE_PENDING_PURCHASE_EXPIRED. Devi e deve aggiornare il diritto dell'utente solo dopo che la transazione completata.

La modifica dello stato dell'abbonamento per l'acquisto iniziale con transazioni in attesa è in modo diretto. La tua app riceve uno stato Purchase con PENDING quando un utente avvia una transazione in sospeso. Al termine della transazione, l'app riceve nuovamente Purchase con lo stato aggiornato a PURCHASED. R È stato inviato SubscriptionNotification messaggio di tipo SUBSCRIPTION_PURCHASED al client RTDN. Segui la normale procedura per verificare l'acquisto, l'utente accede ai contenuti e conferma l'acquisto. Se la transazione scade o viene annullato, un messaggio SubscriptionNotification di tipo SUBSCRIPTION_PENDING_PURCHASE_CANCELED viene inviato al client RTDN. In tale casi, l'utente non dovrebbe mai aver avuto accesso ai contenuti.

La ricarica, l'upgrade o il downgrade con transazioni in sospeso implicano modifiche di stato sia per la vecchia che per quella nuova. Quando l'utente avvia un'istanza una transazione di ricarica, upgrade o downgrade, la tua app riceve un Purchase per la sottoscrizione precedente con un oggetto PendingPurchaseUpdate. Al momento, l'utente possiede ancora il vecchio abbonamento e non ha ottenuto il nuovo abbonamento. Chiamata a getProducts() e getPurchaseToken() sul L'oggetto PendingPurchaseUpdate restituisce gli ID prodotto e il token di acquisto il 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 con tipo SUBSCRIPTION_PURCHASED viene inviato al client RTDN. Solo al momento, devi sostituire il token di acquisto precedente con il nuovo token di acquisto e aggiornare l'accesso dell'utente ai contenuti. Se la transazione scade o viene annullata, SubscriptionNotification messaggio con tipo SUBSCRIPTION_PENDING_PURCHASE_CANCELED viene inviato al client RTDN. In tale casi, l'utente deve avere ancora accesso ai contenuti dell'abbonamento precedente.