Informationen zu Abos

In diesem Dokument wird beschrieben, wie Sie Ereignisse im Abo-Lebenszyklus wie Verlängerungen und Abläufe verarbeiten. Außerdem werden zusätzliche Abofunktionen beschrieben, z. B. das Anbieten von Werbeaktionen und die Möglichkeit für Nutzer, ihre Abos selbst zu verwalten.

Wenn Sie noch keine Abo-Produkte für Ihre App konfiguriert haben, lesen Sie den Abschnitt Produkte erstellen und konfigurieren.

Aboübersicht

Ein Abo ist eine wiederkehrende Transaktion, die Nutzern bestimmte Berechtigungen gewährt. Die Berechtigungen bieten eine Reihe von Vorteilen, auf die Nutzer innerhalb eines bestimmten Zeitraums zugreifen können. Ein Abo kann einem Nutzer beispielsweise Premium-Zugriff gewähren.

Mit Basis-Abos und Angeboten können Sie mehrere Konfigurationen für dasselbe Abo-Produkt erstellen. Sie können beispielsweise ein Einführungsangebot für Nutzer erstellen, die noch nie ein Abo für Ihre App abgeschlossen haben. Ebenso können Sie ein Upgrade-Angebot für Nutzer erstellen, die bereits ein Abo haben.

Eine detaillierte Übersicht über Aboprodukte, Basis-Abos und Angebote finden Sie in der Dokumentation in der Play Console-Hilfe.

Die Play Billing Library unterstützt die folgenden Abotypen:

• Abo mit einem Artikel: Bei diesem Typ entspricht ein Artikel einem Anspruch. Zum Beispiel ein Abo für einen Musik-Streamingdienst.

• Abo mit Add-ons: Bei diesem Typ können in einem Kauf mehrere unterschiedliche Berechtigungen enthalten sein. Beispiel: Sie haben ein Abo für einen Musikstreamingdienst und ein Videoabo. Informationen zu Abos mit Add-ons finden Sie unter Abos mit Add-ons.

Einbindung von Prepaid-Tarifen

Prepaid-Tarife werden nach Ablauf nicht automatisch verlängert. Um die Berechtigung für das Abo ohne Unterbrechung zu verlängern, muss der Nutzer ein Prepaid-Abo für dasselbe Abo aufladen.

Starten Sie für Aufladungen den Abrechnungsablauf wie beim ursprünglichen Kauf. Sie müssen nicht angeben, dass es sich bei einem Kauf um eine Aufladung handelt.

Beim Aufladen von Prepaid-Abos wird immer der CHARGE_FULL_PRICE-Ersatzmodus verwendet. Sie müssen diesen Modus nicht explizit festlegen. Dem Nutzer wird sofort der volle Betrag für einen Abrechnungszeitraum in Rechnung gestellt und sein Anspruch wird um die im Top-up angegebene Dauer verlängert.

Nach einer Aufladung werden die folgenden Felder im Ergebnisobjekt Purchase aktualisiert, um den letzten Aufladekauf widerzuspiegeln:

• Bestell-ID
• Kaufzeitpunkt
• Unterschrift
• Kauftoken
• Bestätigt

Die folgenden Purchase-Felder enthalten immer dieselben Daten wie der ursprüngliche Kauf:

• Paketname
• Kaufstatus
• Produkte
• Automatische Verlängerung

Bestätigung des Prepaid-Kaufs

Ähnlich wie bei Abos mit automatischer Verlängerung müssen Sie Prepaid-Tarife nach dem Kauf bestätigen. Sowohl der ursprüngliche Kauf als auch alle Aufladungen müssen bestätigt werden. Weitere Informationen finden Sie unter Käufe verarbeiten.

Da Prepaid-Abos möglicherweise nur eine kurze Laufzeit haben, ist es wichtig, den Kauf so schnell wie möglich zu bestätigen.

Prepaid-Abos mit einer Laufzeit von einer Woche oder länger müssen innerhalb von drei Tagen bestätigt werden.

Bei Prepaid-Abos mit einer Laufzeit von weniger als einer Woche muss die Bestätigung innerhalb der Hälfte der Abolaufzeit erfolgen. Entwickler haben beispielsweise 1,5 Tage Zeit, um einen Prepaid-Tarif mit einer Laufzeit von drei Tagen zu bestätigen.

Integration von Ratenabos

Bei einem Ratenabo zahlen Nutzer für das Abo in mehreren Raten über einen bestimmten Zeitraum hinweg, anstatt die gesamte Abogebühr im Voraus zu bezahlen.

Zusätzliche Überlegungen zu Ratenabos:

• Verfügbarkeit nach Land: Die Funktion für Ratenabos ist nur in Brasilien, Frankreich, Italien und Spanien verfügbar. Die aktuelle Verfügbarkeit finden Sie in der Play Console.
• Preis festlegen: Wenn Sie in der Console den Preis für ein Ratenabonnement festlegen, entspricht dieser dem monatlichen Zahlungsbetrag. In Kombination mit dem festgelegten Zeitraum für die Nutzungszusicherung wird so der Gesamtbetrag für das Abo auf dem Kaufbildschirm generiert.
• Mindestlaufzeit: Die Gesamtdauer der anfänglichen Abo-Mindestlaufzeit, während der monatliche Zahlungen erforderlich sind. Wenn ein Basis-Abo beispielsweise eine Mindestlaufzeit von 15 Monaten hat, zahlt der Nutzer in diesem Zeitraum 15 Monate lang.
• Verlängerungen: Bei Abos mit Ratenzahlung bedeutet „Verlängerung“ das Ende eines Zusicherungszeitraums, entweder des anfänglichen oder eines nachfolgenden. Nach der ersten Registrierung erfolgt die erste Verlängerung nach Ablauf des gesamten anfänglichen Mindestlaufzeit. Nachfolgende Verlängerungen erfolgen nach Ablauf jedes nachfolgenden Zusicherungszeitraums. Die Verlängerungsarten für Ratenabos können „Jeden Monat automatisch verlängern“ oder „Für dieselbe Laufzeit automatisch verlängern“ sein. Bei „auto-renews monthly“ (wird monatlich automatisch verlängert) gibt es keine anschließende Mindestlaufzeit und der Tarif verhält sich wie ein Monatsabo, bei dem jede monatliche Abogebühr eine Verlängerung darstellt.
• Abrechnungszeitraum: Bei Ratenabos bezieht sich dieser Begriff auf das wiederkehrende Intervall, in dem einzelne Zahlungen erfolgen, wie im Basis-Abo angegeben.
• Verhalten bei Tarifänderungen im Vergleich zu Preisänderungen: Bei Preisänderungen und Kündigungen ist die Verpflichtung verbindlich. Wenn ein Nutzer kündigen oder ein Entwickler den Preis ändern möchte, wird die Änderung zum Ende der Mindestlaufzeit wirksam. Bei Tarifänderungen ist die Mindestlaufzeit nicht verbindlich. Das bedeutet, dass die Tarifänderung nicht bis zum Ende eines Mindestzeitraums warten muss. Sie wird je nach festgelegtem Ersatzmodus entweder sofort oder am nächsten Zahlungsdatum wirksam.
• Änderung des Abos: Eine Änderung des Abos von einem Basis-Abo mit Ratenzahlung zu einem Basis-Abo ohne Ratenzahlung desselben Aboprodukts ist nicht zulässig.

• Entwicklerbenachrichtigungen in Echtzeit (Real-Time Developer Notifications, RTDNs): Eine SUBSCRIPTION_CANCELLATION_SCHEDULED-RTDN wird sofort nach der vom Nutzer initiierten Kündigung gesendet, wenn Zahlungen für den Mindestzeitraum ausstehen. Die Kündigung steht noch aus und wird erst am Ende des Mindestzeitraums wirksam. Wenn sie nicht vom Nutzer wiederhergestellt werden, werden am Ende des Mindestzeitraums SUBSCRIPTION_CANCELED- und SUBSCRIPTION_EXPIRED-RTDNs gesendet.

• Auszahlungen / Umsatzrealisierung: Die Auszahlungen an Entwickler erfolgen, wenn Nutzer ihre monatlichen Zahlungen leisten. Dabei gelten dieselben Bedingungen wie für alle anderen Abos. Entwickler erhalten keine Vorauszahlung, wenn sich der Nutzer für das Abo mit Ratenzahlung registriert.

• Versäumte Zahlungen: Wenn ein Nutzer keine Ratenzahlungen für ein Abo leistet, werden weder Google noch der Entwickler versuchen, solche versäumten oder ausstehenden Zahlungen vom Nutzer einzuziehen. Google kann jedoch in regelmäßigen Abständen versuchen, die Zahlung während einer anwendbaren Kulanzfrist oder Kontosperrfrist gemäß seinen normalen Praktiken für Zahlungsversuche noch einmal auszuführen. Google ist dem Entwickler gegenüber nicht für verbleibende unbezahlte Ratenzahlungen verantwortlich.

• Verfügbarkeit der Play Billing Library: Das Feld installmentDetails ist nur für PBL 7 oder höher verfügbar. Bei PBL 5 und höher wird das Ratenabo mit queryProductDetails() zurückgegeben. Das Abo enthält jedoch keine detaillierten Rateninformationen wie die Anzahl der zugesicherten Zahlungen des Plans.

Deeplinks verwenden, damit Nutzer ein Abo verwalten können

Ihre App muss auf einem Einstellungs- oder Präferenzbildschirm einen Link enthalten, über den Nutzer ihre Abos verwalten können. Sie können diesen Link in das natürliche Erscheinungsbild Ihrer App einfügen.

Sie können einen Deeplink von Ihrer App zum Google Play-Abo-Center für nicht abgelaufene Abos einfügen. Ob ein Abo abgelaufen ist, können Sie anhand des Felds subscriptionState der Abo-Ressource ermitteln. Daraus ergeben sich mehrere Möglichkeiten, Deeplinks zum Google Play-Abozentrum zu erstellen.

Link zum Abocenter

Verwenden Sie die folgende URL, um Nutzer auf die Seite weiterzuleiten, auf der alle ihre Abos angezeigt werden (siehe Abbildung 1 und 2):

https://play.google.com/store/account/subscriptions

Dieser Deeplink kann hilfreich sein, wenn ein Nutzer ein gekündigtes Abo über das Play Store-Abocenter reaktivieren möchte.

Link zu einer bestimmten Seite zur Aboverwaltung (empfohlen)

Wenn Sie direkt auf die Verwaltungsseite für ein nicht abgelaufenes Abo verlinken möchten, geben Sie den Paketnamen und die productId an, die mit dem gekauften Abo verknüpft sind. Wenn Sie die productId für ein bestehendes Abo programmatisch ermitteln möchten, fragen Sie das Backend Ihrer App ab oder rufen Sie BillingClient.queryPurchasesAsync() auf, um eine Liste der Abos abzurufen, die einem bestimmten Nutzer zugeordnet sind. Jedes Abo enthält die entsprechende productId als Teil der Informationen zum Abostatus. Jedes SubscriptionPurchaseLineItem-Objekt, das mit einem Abo-Kauf verknüpft ist, enthält den productId-Wert, der mit dem Abo verknüpft ist, das der Nutzer in dieser Position gekauft hat.

Verwenden Sie die folgende URL, um Nutzer zu einem bestimmten Bildschirm für die Aboverwaltung weiterzuleiten. Ersetzen Sie dabei „your-sub-product-id“ und „your-app-package“ durch die productId bzw. den Namen des App-Pakets:

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

Der Nutzer kann dann seine Zahlungsmethoden verwalten und auf Funktionen wie Kündigung, erneute Registrierung und Pausierung zugreifen.

Nutzern erlauben, ihr Abo zu upgraden, zu downgraden oder zu ändern

Sie können bestehenden Abonnenten verschiedene Optionen anbieten, um ihr Abo an ihre Bedürfnisse anzupassen:

• Wenn Sie mehrere Abo-Stufen verkaufen, z. B. „Basic“- und „Premium“-Abos, können Sie Nutzern ermöglichen, die Stufe zu wechseln, indem sie das Basis-Abo oder Angebot eines anderen Abos kaufen.
• Sie können Nutzern erlauben, ihren aktuellen Abrechnungszeitraum zu ändern, z. B. von einem Monats- zu einem Jahrestarif zu wechseln.
• Sie können Nutzern auch erlauben, zwischen Abos mit automatischer Verlängerung und Prepaid-Tarifen zu wechseln.

Sie können diese Änderungen fördern, indem Sie Abos mit Rabatt für berechtigte Nutzer anbieten. Sie könnten beispielsweise ein Angebot erstellen, das einen Rabatt von 50% auf das erste Jahr beim Wechsel von einem Monats- zu einem Jahresabo bietet. Dieses Angebot könnte auf Nutzer mit einem Monatsabo beschränkt werden, die dieses Angebot noch nicht gekauft haben. Weitere Informationen zu den Teilnahmevoraussetzungen für Angebote findest du in der YouTube-Hilfe.

Abbildung 3 zeigt eine Beispiel-App mit drei verschiedenen Tarifen:

In Ihrer App könnte ein Bildschirm wie in Abbildung 3 angezeigt werden, auf dem Nutzer ihr Abo ändern können. In jedem Fall sollte für Nutzer klar ersichtlich sein, welchen Abo-Tarif sie derzeit haben und welche Optionen sie haben, ihn zu ändern.

Wenn Nutzer ein Upgrade, Downgrade oder eine Änderung ihres Abos vornehmen, geben Sie einen replacement mode (Ersatzmodus) an, der bestimmt, wie der anteilige Wert des aktuellen bezahlten Abrechnungszeitraums angewendet wird und wann eine Berechtigungsänderung erfolgt.

Ersetzungsmodi

In der folgenden Tabelle sind die verfügbaren Ersetzungsmodi, die Beispielnutzung und die Anzahl der als bezahlt geltenden Zahlungen aufgeführt.

Weitere Informationen zu verschiedenen Upselling- und Reaktivierungsanwendungen von Upgrade- oder Downgrade-Angeboten finden Sie im Leitfaden zu Angeboten und Werbeaktionen.

Ersatzmodus für einen Kauf festlegen

Je nach Ihren Einstellungen und Ihrer Geschäftslogik können Sie für verschiedene Arten von Aboübergängen unterschiedliche Ersetzungsmodi verwenden. In diesem Abschnitt wird beschrieben, wie Sie einen Ersatzmodus für eine Änderung an einem Abo festlegen und welche Einschränkungen gelten.

Abo reaktivieren oder Abo innerhalb desselben Abos wechseln

Sie können in der Google Play Console einen Standardersetzungsmodus festlegen. Mit dieser Einstellung können Sie auswählen, wann bestehenden Abonnenten der Betrag in Rechnung gestellt wird, wenn sie ein anderes Basis-Abo abschließen oder ein Angebot für dasselbe Abo in Anspruch nehmen oder nach einer Kündigung ein Abo noch einmal abschließen. Die verfügbaren Optionen sind Sofort belasten (entspricht CHARGE_FULL_PRICE) und Zum nächsten Rechnungsdatum belasten (entspricht WITHOUT_PRORATION). Dies sind die einzigen relevanten Ersetzungsmodi beim Wechsel des Basis-Abos innerhalb desselben Abos.

Wenn Sie beispielsweise ein Rückgewinnungsangebot für denselben Tarif implementieren, nachdem der Nutzer das Abo gekündigt hat, aber bevor es endet, können Sie den neuen Kauf als regulären Kauf verarbeiten, ohne Werte in SubscriptionUpdateParams anzugeben. Das System verwendet den Standardersetzungsmodus, den Sie im Abo konfiguriert haben, und verarbeitet den Aboübergang vom alten zum neuen Kauf automatisch.

Zwischen Abos wechseln oder den Standardersetzungsmodus überschreiben

Wenn der Nutzer Abo-Produkte ändert, indem er ein anderes Abo kauft, oder wenn Sie den Standardersetzungsmodus aus irgendeinem Grund überschreiben möchten, geben Sie die anteilige Berechnung zur Laufzeit als Teil der Parameter des Kaufvorgangs an.

Beachten Sie die folgenden Einschränkungen, um ReplacementMode in SubscriptionProductReplacementParams oder SubscriptionUpdateParams im Rahmen der Konfiguration des Kaufvorgangs für die Laufzeit korrekt anzugeben:

• Wenn Sie ein Upgrade oder Downgrade durchführen oder ein Abo desselben Typs in einen Prepaid-Tarif ändern, ist als Ersatzmodus nur CHARGE_FULL_PRICE zulässig. Dies gilt unabhängig davon, ob das ursprüngliche Abo ein Prepaid-Tarif, ein Tarif mit automatischer Verlängerung oder ein Ratenzahlungstarif war. Wenn Sie einen anderen Ersatzmodus angeben, schlägt der Kauf fehl und dem Nutzer wird eine Fehlermeldung angezeigt.
• Wenn Sie innerhalb desselben Abos zu einem sich automatisch verlängernden Tarif wechseln, aus einem Prepaid-Tarif oder einem sich automatisch verlängernden Tarif, sind die gültigen Abrechnungsarten CHARGE_FULL_PRICE und WITHOUT_PRORATION. Wenn Sie einen anderen Abrechnungsmodus angeben, schlägt der Kauf fehl und dem Nutzer wird eine Fehlermeldung angezeigt.
• Es ist nicht zulässig, innerhalb desselben Aboprodukts von einem Basis-Abo mit Ratenzahlung zu einem Basis-Abo ohne Ratenzahlung zu wechseln.
• Wenn Sie den KEEP_EXISTING-Ersetzungsmodus in SubscriptionProductReplacementParams verwenden, um die Zahlung eines Artikels während des Ersatzes unverändert zu lassen, sollte die alte Produkt-ID mit der Produkt-ID des neuen Produkts übereinstimmen. Der Modus KEEP_EXISTING wird in SubscriptionUpdateParams nicht unterstützt.

Beispiele für Ersetzungen und Verhalten

Sehen Sie sich das folgende Szenario an, um die Funktionsweise der einzelnen Abrechnungsmodi zu verstehen:

Samwise hat ein Abo für Onlineinhalte aus der Country Gardener App. Er hat ein monatliches Abo für die Tier 1-Version der Inhalte, die nur aus Text besteht. Dieses Abo kostet ihn 2$pro Monat und wird am Ersten des Monats verlängert.

Am 15. April hat Samwise ein Upgrade auf die Jahresversion des Tier 2-Abos durchgeführt, das Video-Updates umfasst und 36$pro Jahr kostet.

Beim Upgrade des Abos wählt der Entwickler einen Abrechnungsmodus aus. In der folgenden Liste wird beschrieben, wie sich die einzelnen Abrechnungsarten auf das Abo von Samwise auswirken:

WITH_TIME_PRORATION

Das Tier 1-Abo von Samwise endet sofort. Er hat für einen ganzen Monat (1. bis 30. April) bezahlt, aber nach der Hälfte des Abozeitraums ein Upgrade durchgeführt. Daher wird die Hälfte des Monatsabos (1 $) auf sein neues Abo angerechnet. Da das neue Abo jedoch 36 $pro Jahr kostet, reicht das Guthaben von 1 $nur für 10 Tage (16. bis 25. April). Am 26. April werden ihm also 36 $für ein neues Abo und am 26. April jedes folgenden Jahres weitere 36 $in Rechnung gestellt.

Sie sollten die PurchasesUpdatedListener Ihrer App aufrufen, sobald der Kauf erfolgreich war und Sie den neuen Kauf im Rahmen eines queryPurchasesAsync()-Aufrufs abrufen können. Ihr Backend erhält sofort eine SUBSCRIPTION_PURCHASED-Entwicklerbenachrichtigung in Echtzeit.

CHARGE_PRORATED_PRICE

Dieser Modus kann verwendet werden, da der Abo-Preis pro Zeiteinheit für Stufe 2 (36 $/Jahr = 3 $/Monat) höher ist als der Abo-Preis pro Zeiteinheit für Stufe 1 (2 $/Monat). Das Tier 1-Abo von Samwise endet sofort. Da er für einen ganzen Monat bezahlt, aber nur die Hälfte des Monats genutzt hat, wird die Hälfte des Monatsabos (1 $) auf sein neues Abo angerechnet. Da das neue Abo jedoch 36 $pro Jahr kostet, kosten die verbleibenden 15 Tage 1,50 $. Ihm wird also die Differenz von 0,50 $für sein neues Abo in Rechnung gestellt. Am 1. Mai werden Samwise 36 $für sein neues Abo berechnet und am 1. Mai jedes folgenden Jahres weitere 36 $.

Sie sollten die PurchasesUpdatedListener Ihrer App aufrufen, sobald der Kauf erfolgreich war und Sie den neuen Kauf im Rahmen eines queryPurchasesAsync()-Aufrufs abrufen können. Ihr Backend erhält sofort eine SUBSCRIPTION_PURCHASED-Entwicklerbenachrichtigung in Echtzeit.

WITHOUT_PRORATION

Samwise‘ Tier 1-Abo wird sofort und ohne Aufpreis auf Tier 2 aktualisiert. Am 1. Mai werden ihm 36 $für sein neues Abo berechnet und am 1. Mai jedes folgenden Jahres weitere 36 $.

Sie sollten die PurchasesUpdatedListener Ihrer App aufrufen, sobald der Kauf erfolgreich war und Sie den neuen Kauf im Rahmen eines queryPurchasesAsync()-Aufrufs abrufen können. Ihr Backend erhält sofort eine SUBSCRIPTION_PURCHASED-Entwicklerbenachrichtigung in Echtzeit.

DEFERRED

Das Tier 1-Abo von Samwise läuft bis zum 30. April. Am 1. Mai tritt das Abo der 2. Stufe in Kraft und Samwise werden 36 $für seine neue Abostufe in Rechnung gestellt.

Sie sollten die PurchasesUpdatedListener Ihrer App aufrufen, sobald der Kauf erfolgreich war und Sie den neuen Kauf im Rahmen eines queryPurchasesAsync()-Aufrufs abrufen können. Ihr Backend erhält sofort eine SUBSCRIPTION_PURCHASED-Entwicklerbenachrichtigung in Echtzeit. Sie sollten den Kauf auf dieselbe Weise verarbeiten wie jeden anderen neuen Kauf zu diesem Zeitpunkt. Bestätigen Sie insbesondere den neuen Kauf. Die startTime des neuen Abos wird erst dann ausgefüllt, wenn das alte Abo abläuft und das neue Abo in Kraft tritt. Zu diesem Zeitpunkt erhalten Sie eine SUBSCRIPTION_RENEWED-RTDN für das neue Abo. Weitere Informationen zum Verhalten von ReplacementMode.DEFERRED finden Sie unter Verzögerte Ersetzung verarbeiten.

CHARGE_FULL_PRICE

Das Tier 1-Abo von Samwise endet sofort. Sein Abo der Stufe 2 beginnt heute und ihm werden 36 $in Rechnung gestellt. Da er für einen ganzen Monat bezahlt, aber nur die Hälfte des Monats genutzt hat, wird die Hälfte des Monatsabos (1 $) auf sein neues Abo angerechnet. Da das neue Abo 36 $pro Jahr kostet, würde er etwa 10 Tage zusätzlich zu seinem Abozeitraum erhalten. Die nächste Abbuchung für Samwise erfolgt also in einem Jahr und zehn Tagen und beträgt 36 $. Danach werden ihm jedes Jahr 36 $in Rechnung gestellt.

Sehen Sie sich bei der Auswahl eines Abrechnungsmodus unsere Empfehlungen für den Ersatz an.

KEEP_EXISTING

Samwise hat ein Abo für Onlineinhalte der Country Gardener App. Er hat ein monatliches Abo für Plan 1 für grundlegende Inhalte. Dieses Abo kostet 3 Monate lang einen Einführungspreis von 2 $pro Monat und danach 4 $pro Monat. Samwise hat das am 1. April gekauft. Die Country Gardener App bietet Plan 2 als Add-on-Spezialinhalte für 3 $pro Monat an. Am 15. April hat Samwise seinem Abo der Country Gardener App den Tarif 2 hinzugefügt, während er den bestehenden Tarif 1 beibehalten hat. Der Zahlungsplan von Samwise sieht so aus:

• Ein anteilig berechneter Preis von 1,50 $für Tarif 2, fällig am 15.April.
• Ein Preis von 5,00 $pro Monat für die folgenden zwei Monate, der sowohl den Einführungspreis für Plan 1 als auch den regulären Preis für Plan 2 abdeckt.
• Danach wird ein monatlicher Betrag von 7, 00 $abgebucht.

Aboänderungen in der App auslösen

In Ihrer App können Sie Nutzern ein Upgrade oder Downgrade anbieten. Die Schritte sind dabei dieselben wie beim Starten eines Kaufvorgangs. Beim Upgraden oder Downgraden müssen Sie jedoch Details zum aktuellen Abo, zum zukünftigen (upgegradeten oder downgradeten) Abo und zum zu verwendenden Ersatzmodus angeben.

„SubscriptionProductReplacementParams“ für Ersatz verwenden (bevorzugt)

Im folgenden Beispiel wird gezeigt, wie ein Abo mit SubscriptionProductReplacementParams aktualisiert wird.

• Das BillingFlowParams.ProductDetailsParams-Objekt hat jetzt eine setSubscriptionProductReplacementParams()-Methode, mit der Ersatzinformationen auf Produktebene angegeben werden können.

• SubscriptionProductReplacementParams hat zwei Setter-Methoden:

  • setOldProductId:Dies ist das alte Produkt, das durch das Produkt in der aktuellen ProductDetails. ersetzt werden soll.setOldProductId:
  • setReplacementMode:Dies ist der Ersatzmodus auf Artikelebene. Die Modi sind im Wesentlichen dieselben wie SubscriptionUpdateParams, aber die Wertzuordnung wurde aktualisiert.

• Die vorhandenen Parameter für die Aktualisierung der Kaufstufe BillingFlowParams.setSubscriptionUpdateParams() sollten mit setOldPurchaseToken() erstellt werden.

• Sobald setSubscriptionProductReplacementParams() für eine der ProductDetailsParams aufgerufen wird, hat SubscriptionUpdateParams.setSubscriptionReplacementMode() keine Auswirkungen mehr.

Im folgenden Codebeispiel wird veranschaulicht, wie Sie ein Abo von (old_product_1, old_product_2) zu (product_1, product_2, product_3) ändern. In diesem Szenario ersetzt product_1 old_product_1, product_2 ersetzt old_product_2 und product_3 wird dem Abo sofort hinzugefügt.

val billingClient: BillingClient = ...
val replacementModeForBasePlan: Int = ...
val replacementModeForAddon: Int = ...

val purchaseTokenOfExistingSubscription: String = "your_old_purchase_token"

// ProductDetails instances obtained from queryProductDetailsAsync();

val productDetailsParams1 =
    ProductDetailsParams.newBuilder()
        .setProductDetails(productDetails1_obj) // Required: Set the ProductDetails object
        .setSubscriptionProductReplacementParams(
            SubscriptionProductReplacementParams.newBuilder()
                .setOldProductId("old_product_id_1")
                .setReplacementMode(replacementModeForBasePlan)
                .build()
        )
        .build()

val productDetailsParams2 =
    ProductDetailsParams.newBuilder()
        .setProductDetails(productDetails2_obj) // Required: Set the ProductDetails object
        .setSubscriptionProductReplacementParams(
            SubscriptionProductReplacementParams.newBuilder()
                .setOldProductId("old_product_id_2")
                .setReplacementMode(replacementModeForAddon)
                .build()
        )
        .build()

// Example for a third item without replacement params
val productDetailsParams3 =
    ProductDetailsParams.newBuilder()
        .setProductDetails(productDetails3_obj) // Required: Set the ProductDetails object
        .build()

val newProductDetailsList = listOf(
    productDetailsParams1,
    productDetailsParams2,
    productDetailsParams3
)

val billingFlowParams =
    BillingFlowParams.newBuilder()
        .setSubscriptionUpdateParams(
            SubscriptionUpdateParams.newBuilder()
                .setOldPurchaseToken(purchaseTokenOfExistingSubscription)
                .build()
        )
        .setProductDetailsParamsList(newProductDetailsList)
        .build()

// To launch the billing flow:
// billingClient.launchBillingFlow(activity, billingFlowParams)

BillingClient billingClient = …;

int replacementModeForBasePlan =…;
int replacementModeForAddon =…;
// ProductDetails obtained from queryProductDetailsAsync().
ProductDetailsParams productDetails1 =
  ProductDetailsParams.newBuilder()
      .setSubscriptionProductReplacementParams(
           SubscriptionProductReplacementParams.newBuilder()
               .setOldProductId("old_product_id_1")
               .setReplacementMode(replacementModeForBasePlan))
               .build();
ProductDetailsParams productDetails2 =
  ProductDetailsParams.newBuilder()
      .setSubscriptionProductReplacementParams(
           SubscriptionProductReplacementParams.newBuilder()
               .setOldProductId("old_product_id_2")
               .setReplacementMode(replacementModeForAddon))
               .build();
ProductDetailsParams productDetails3 = ...;

ArrayList newProductDetailsList = new ArrayList<>();
newProductDetailsList.add(productDetails1);
newProductDetailsList.add(productDetails2);
newProductDetailsList.add(productDetails3);

BillingFlowParams billingFlowParams =
    BillingFlowParams.newBuilder()
        .setSubscriptionUpdateParams(
          SubscriptionUpdateParams.newBuilder()
              .setOldPurchaseToken(purchaseTokenOfExistingSubscription)
             .build())
        .setProductDetailsParamsList(productDetailsList)
        .build();

billingClient.launchBillingFlow(billingFlowParams);

SubscriptionUpdateParams für Ersatz festlegen (veraltet)

Im folgenden Beispiel wird gezeigt, wie ein Abo mit SubscriptionUpdateParams aktualisiert wird.

val offerToken = productDetails
        .getSubscriptionOfferDetails(selectedOfferIndex)
        .getOfferToken()

val billingParams = BillingFlowParams.newBuilder().setProductDetailsParamsList(
       listOf(
           BillingFlowParams.ProductDetailsParams.newBuilder()
               .setProductDetails(productDetails)
               .setOfferToken(offerToken)
               .build()
       )
       ).setSubscriptionUpdateParams(
           BillingFlowParams.SubscriptionUpdateParams.newBuilder()
               .setOldPurchaseToken("old_purchase_token")
               .setSubscriptionReplacementMode(
                 BillingFlowParams.ReplacementMode.CHARGE_FULL_PRICE
               )
               .build()
       ).build()

billingClient.launchBillingFlow(
    activity,
    billingParams
   )
// ...

String offerToken = productDetails
    .getSubscriptionOfferDetails(selectedOfferIndex)
    .getOfferToken();

BillingFlowParams billingFlowParams = BillingFlowParams.newBuilder()
    .setProductDetailsParamsList(
        ImmuableList.of(
            ProductDetailsParams.newBuilder()
                // fetched via queryProductDetailsAsync
                .setProductDetails(productDetails)
                // offerToken can be found in
                // ProductDetails=>SubscriptionOfferDetails
                .setOfferToken(offerToken)
                .build()))
    .setSubscriptionUpdateParams(
        SubscriptionUpdateParams.newBuilder()
            // purchaseToken can be found in Purchase#getPurchaseToken
            .setOldPurchaseToken("old_purchase_token")
            .setSubscriptionReplacementMode(ReplacementMode.CHARGE_FULL_PRICE)
            .build())
    .build();

BillingResult billingResult = billingClient.launchBillingFlow(activity, billingFlowParams);
// ...

Empfehlungen für Ersatzgeräte

In der folgenden Tabelle sind verschiedene Szenarien für die anteilige Berechnung sowie unsere Empfehlungen für jedes Szenario aufgeführt:

Käufe von Aboänderungen verarbeiten

Aboänderungen sind für alle Zwecke neue Käufe und sollten nach Abschluss des Abrechnungsvorgangs entsprechend verarbeitet und bestätigt werden. Neben der ordnungsgemäßen Verarbeitung des neuen Kaufs müssen Sie den Kauf, der ersetzt wird, einstellen.

Das In-App-Verhalten ist dasselbe wie bei jedem neuen Kauf. Das Ergebnis des neuen Kaufs wird in Ihrer PurchasesUpdatedListener angezeigt und der neue Kauf ist in queryPurchasesAsync verfügbar.

Die Google Play Developer API gibt in der Aboressource eine linkedPurchaseToken zurück, wenn ein Kauf einen bestehenden Kauf ersetzt. Achten Sie darauf, das im linkedPurchaseToken bereitgestellte Token zu invalidieren, damit das alte Token nicht für den Zugriff auf Ihre Dienste verwendet wird. Informationen zum Verarbeiten von Upgrade- und Downgradekäufen finden Sie unter Upgrades, Downgrades und erneute Registrierungen.

Wenn Sie das neue Kauf-Token erhalten, folgen Sie demselben Bestätigungsprozess wie beim Bestätigen eines neuen Kauf-Tokens. Bestätigen Sie diese Käufe mit BillingClient.acknowledgePurchase() aus der Google Play Billing Library oder Purchases.subscriptions:acknowledge aus der Google Play Developer API.

Umgang mit verzögertem Ersatz

Im Modus für verzögerten Ersatz können Nutzer die verbleibenden Ansprüche in ihrem alten Tarif nutzen, bevor der neue Tarif beginnt.

Wenn Sie ReplacementMode.DEFERRED für einen Neukauf verwenden, gibt queryPurchasesAsync() nach dem Kaufvorgang ein neues Kauf-Token zurück, das bis zum nächsten Verlängerungsdatum mit dem alten Produkt verknüpft bleibt. Danach wird das neue Produkt zurückgegeben.

Bisher war dies mit dem eingestellten ProrationMode.DEFERRED möglich. ProrationMode.DEFERRED wird jedoch mit der Play Billing Library 6 eingestellt. In der folgenden Tabelle sehen Sie, wo sich das Verhalten unterscheidet:

ReplacementMode.DEFERRED sollte ab sofort anstelle des eingestellten ProrationMode.DEFERRED verwendet werden, da es dasselbe Verhalten in Bezug auf Berechtigungsänderungen aufweist, aber eine Möglichkeit bietet, den Kauf zu verwalten, die mit dem Verhalten bei anderen neuen Käufen konsistenter ist.

Kundenverwaltung

Mit Entwicklerbenachrichtigungen in Echtzeit können Sie in Echtzeit erkennen, wenn ein Nutzer sein Abo kündigt. Wenn ein Nutzer kündigt, aber sein Abo noch nicht abgelaufen ist, können Sie ihm Push-Benachrichtigungen oder In-App-Nachrichten senden, in denen Sie ihn bitten, das Abo zu reaktivieren.

Nachdem ein Nutzer sein Abo gekündigt hat, können Sie versuchen, ihn entweder in Ihrer App oder über den Play Store zurückzugewinnen. In der folgenden Tabelle werden verschiedene Aboszenarien zusammen mit den zugehörigen Rückgewinnungsaktionen und App-Anforderungen beschrieben.

Vor Ablauf des Abos – In-App

Bei Abos, die gekündigt wurden, aber noch nicht abgelaufen sind, können Sie Abonnenten ermöglichen, ihr Abo in Ihrer App wiederherzustellen. Verwenden Sie dazu denselben In-App-Produktkaufprozess wie für neue Abonnenten. Achten Sie darauf, dass in Ihrer Benutzeroberfläche angezeigt wird, dass der Nutzer ein bestehendes Abo hat. Sie möchten beispielsweise das aktuelle Ablaufdatum und den wiederkehrenden Preis des Nutzers mit der Schaltfläche Reaktivieren anzeigen.

In den meisten Fällen sollten Sie dem Nutzer denselben Preis und dieselbe Artikelnummer anbieten, die er bereits abonniert hat:

• Ein neues Abo mit derselben Artikelnummer abschließen.
• Das neue Abo ersetzt das alte und wird am selben Ablaufdatum verlängert. Das alte Abo wird sofort als abgelaufen markiert.
• Beispiel: Achilles hat ein Abo für die Beispiel-Musik-App, das am 1. August ausläuft. Am 10. Juli schließt er das Monatsabo zum gleichen Preis pro Monat wieder ab. Das neue Abo wird anteilig mit dem verbleibenden Guthaben abgerechnet, ist sofort aktiv und wird weiterhin am 1. August verlängert.

Wenn Sie einen anderen Preis anbieten möchten, z. B. einen neuen kostenlosen Testzeitraum oder einen Rabatt zur Rückgewinnung ehemaliger Abonnenten, können Sie dem Nutzer stattdessen eine andere Artikelnummer anbieten:

• Leiten Sie ein Upgrade oder Downgrade mit der anderen SKU im Ersatzmodus WITHOUT_PRORATION ein.
• Das neue Abo ersetzt das alte und wird am selben Ablaufdatum verlängert. Dem Nutzer wird am ursprünglichen Ablaufdatum der Preis der neuen SKU in Rechnung gestellt, einschließlich aller Einführungspreise. Wenn das alte Abo mit einer verschleierten Konto-ID erstellt wurde, sollte dieselbe ID für Upgrades und Downgrades an BillingFlowParams übergeben werden.
• Beispiel: Achilles hat ein Abo für die Beispiel-Musik-App, das am 1. August ausläuft. Am 10. Juli schließt er ein Jahresabo mit einem Einführungspreis ab. Das neue Abo ist sofort aktiv und dem Nutzer wird am 1. August der Einführungspreis in Rechnung gestellt.
• Wenn Sie in Ihrer Reaktivierungs-Artikelnummer einen kostenlosen Testzeitraum oder einen Einführungspreis anbieten möchten, müssen Sie dafür sorgen, dass der Nutzer die Voraussetzungen erfüllt. Dazu müssen Sie in der Google Play Console das Kästchen Einen kostenlosen Testzeitraum pro App zulassen deaktivieren, da der Nutzer sonst nur einen kostenlosen Testzeitraum pro App erhalten kann.

Wenn Sie das Kauf-Token erhalten, verarbeiten Sie den Kauf wie bei einem neuen Abo. Außerdem gibt die Google Play Developer API ein linkedPurchaseToken in der Aboressource zurück. Ungültigmachen des Tokens, das in linkedPurchaseToken bereitgestellt wird, um sicherzustellen, dass das alte Token nicht für den Zugriff auf Ihre Dienste verwendet wird.

Vor Ablauf des Abos – im Play Store

Solange das Abo gekündigt, aber noch aktiv ist, können Nutzer es im Google Play-Abocenter reaktivieren, indem sie auf Abo reaktivieren (früher Reaktivieren) klicken. Das Abo und das Kauf-Token bleiben dabei gleich.

Weitere Informationen zum Wiederherstellen von Abos finden Sie unter Wiederherstellungen.

Nach Ablauf des Abos – In-App

Sie können abgelaufenen Abonnenten ermöglichen, das Abo über den gleichen In-App-Produktkaufprozess wie für neue Abonnenten noch einmal abzuschließen. Beachten Sie Folgendes:

• Wenn Sie Nutzern einen Rabatt anbieten möchten, können Sie eine Produkt-ID mit einem speziellen Preis für Ihr Abo anbieten, auch Rückgewinnungs-Artikelnummer genannt. Sie können das Angebot in Ihrer App präsentieren oder den Nutzer außerhalb der App, z. B. per E-Mail, darüber informieren.
• Um ein Reaktivierungsabo zu starten, müssen Sie den Kaufvorgang in Ihrer Android-App mit der Google Play Billing Library starten. Das ist derselbe Vorgang wie bei einem neuen Abo, aber Sie können die Artikelnummer festlegen, die dem Nutzer zur Verfügung steht.
• Wenn Sie in Ihrer Reaktivierungs-Artikelnummer einen kostenlosen Testzeitraum oder einen Einführungspreis anbieten möchten, müssen Sie dafür sorgen, dass der Nutzer die Voraussetzungen erfüllt. Dazu müssen Sie in der Google Play Console das Kästchen Einen kostenlosen Testzeitraum pro App zulassen deaktivieren. Dadurch wird der Nutzer auf einen kostenlosen Testzeitraum pro App beschränkt.
• Wenn der Nutzer dasselbe Abo noch einmal abschließt, hat er keinen Anspruch mehr auf kostenlose Testzeiträume oder Einführungspreise. Achten Sie darauf, dass dies in Ihrer Benutzeroberfläche berücksichtigt wird.

Wenn Sie das Kauf-Token erhalten, verarbeiten Sie den Kauf wie bei einem neuen Abo. Sie erhalten kein linkedPurchaseToken in der Aboressource.

Nach Ablauf des Abos – im Play Store

Wenn diese Option aktiviert ist, können Nutzer bis zu einem Jahr nach Ablauf des Abos dieselbe Artikelnummer noch einmal abonnieren. Dazu müssen sie im Abocenter von Google Play auf Erneut abonnieren klicken. Dadurch wird ein neues Abo- und Kauf-Token generiert.

Das erneute Abonnieren gilt als Kauf außerhalb der App. Achten Sie daher darauf, die Best Practices für Käufe außerhalb der App zu befolgen.

Abo bewerben

Sie können Gutscheincodes erstellen, um ausgewählten Nutzern einen verlängerten kostenlosen Testzeitraum für ein bestehendes Abo zu gewähren. Weitere Informationen zu Gutscheincodes

Bei kostenlosen Testabos prüft Google Play, ob der Nutzer eine gültige Zahlungsmethode hat, bevor das kostenlose Testabo gestartet wird. Einige Nutzer sehen diese Bestätigung möglicherweise als Vorautorisierung oder Belastung ihrer Zahlungsmethode. Diese Reservierung oder Belastung ist vorübergehend und wird später rückgängig gemacht oder erstattet.

Nach Ablauf des Testzeitraums wird die Zahlungsmethode des Nutzers mit dem vollen Abopreis belastet.

Wenn ein Nutzer ein Abo während des kostenlosen Testzeitraums kündigt, bleibt das Abo bis zum Ende des Testzeitraums aktiv und ihm wird nach Ablauf des kostenlosen Testzeitraums nichts berechnet.

Kündigen oder widerrufen

Sie können die Google Play Developer API verwenden, um ein Abo zu kündigen oder widerrufen. Diese Funktion ist auch in der Google Play Console verfügbar.

• Kündigen: Nutzer können ein Abo bei Google Play kündigen. Sie können Nutzern auch die Möglichkeit bieten, das Abo in Ihrer App oder auf Ihrer Website zu kündigen. Ihre App sollte diese Stornierungen wie unter Stornierungen beschrieben verarbeiten.

• Widerrufen: Wenn Sie das Abo widerrufen, verliert der Nutzer sofort den Zugriff darauf. Das kann beispielsweise verwendet werden, wenn ein technischer Fehler aufgetreten ist, der den Nutzer daran gehindert hat, auf Ihr Produkt zuzugreifen, und der Nutzer das Produkt nicht mehr verwenden möchte. Ihre App sollte diese Kündigungen wie unter Widerruf beschrieben verarbeiten.

In der folgenden Tabelle werden die Unterschiede zwischen „Kündigen“ und „Widerrufen“ veranschaulicht.

Abrechnung für einen Abonnenten verzögern

Sie können das nächste Abrechnungsdatum für einen Abonnenten mit automatischer Verlängerung mit Purchases.subscriptions:defer aus der Google Play Developer API vorziehen. Während des Aufschubzeitraums hat der Nutzer ein Abo für Ihre Inhalte mit vollem Zugriff, ihm wird jedoch nichts in Rechnung gestellt. Das Verlängerungsdatum des Abos wird aktualisiert, sodass es dem neuen Datum entspricht.

Bei Prepaid-Tarifen können Sie die API zum Aufschieben der Abrechnung verwenden, um das Ablaufdatum aufzuschieben.

Mit der verzögerten Abrechnung haben Sie folgende Möglichkeiten:

• Du kannst Nutzern im Rahmen eines Sonderangebots kostenlosen Zugriff gewähren, z. B. eine Woche lang kostenlosen Zugriff beim Kauf eines Films.
• Kunden aus Kulanz kostenlosen Zugriff gewähren

Die Abrechnung kann pro API-Aufruf um einen Tag bis zu einem Jahr aufgeschoben werden. Wenn Sie die Abrechnung noch weiter aufschieben möchten, können Sie die API vor dem neuen Abrechnungsdatum noch einmal aufrufen.

Darcy hat beispielsweise ein monatliches Abo für Onlineinhalte in der App „Fishing Quarterly“. Normalerweise wird ihr am ersten Tag jedes Monats ein Betrag von 1, 25 £ in Rechnung gestellt. Im März hat sie an einer Onlineumfrage für den App-Publisher teilgenommen. Die Verlegerin belohnt sie mit sechs kostenlosen Wochen, indem sie die nächste Zahlung auf den 15. Mai verschiebt. Das sind sechs Wochen nach dem ursprünglich geplanten Abrechnungsdatum am

1. Darcy werden für April und Anfang Mai keine Kosten in Rechnung gestellt und sie hat weiterhin Zugriff auf die Inhalte. Am 15.Mai wird ihr die normale Abogebühr von 1, 25 £ für den Monat in Rechnung gestellt. Ihr nächstes Verlängerungsdatum ist jetzt der 15. Juni.

Wenn Sie die Abrechnung verschieben, sollten Sie den Nutzer per E-Mail oder in der App darüber informieren, dass sich das Abrechnungsdatum geändert hat.

Umgang mit Zahlungsablehnungen

Wenn es Zahlungsprobleme bei der Verlängerung eines Abos gibt, versucht Google in regelmäßigen Abständen, das Abo zu verlängern, bevor es gekündigt wird. Dieser Wiederherstellungszeitraum kann aus einem Kulanzzeitraum, gefolgt von einer Kontosperre, bestehen. Während dieser Zeit sendet Google dem Nutzer E‑Mails und Benachrichtigungen, in denen er aufgefordert wird, seine Zahlungsmethode zu aktualisieren.

Wenn eine Zahlung abgelehnt wird, beginnt für das Abo ein Kulanzzeitraum, sofern ein solcher konfiguriert ist. Während des Kulanzzeitraums solltest du dafür sorgen, dass der Nutzer weiterhin Zugriff auf die Aboberechtigungen hat.

Nach Ablauf eines Kulanzzeitraums wird für das Abo eine Kontosperre angewendet. Während der Kontosperre sollten Sie dafür sorgen, dass der Nutzer keinen Zugriff auf die Aboberechtigungen hat.

Sie können die Dauer des Kulanzzeitraums und der Kontosperre für jedes Basis-Abo mit automatischer Verlängerung in der Google Play Console festlegen. Wenn Sie eine Zeitspanne festlegen, die unter den Standardwerten liegt, kann sich die Anzahl der Abos verringern, die nach abgelehnten Zahlungen wiederhergestellt werden.

Um die Wahrscheinlichkeit einer Abo-Reaktivierung bei einer abgelehnten Zahlung zu maximieren, können Sie den Nutzer über das Zahlungsproblem informieren und ihn bitten, es zu beheben.

Sie können dies entweder selbst tun, wie in den Abschnitten Kulanzzeitraum und Kontosperrung beschrieben, oder die In-App-Messaging-API implementieren, über die Google Nutzern in Ihrer App eine Nachricht anzeigt.

In-App-Messaging

Wenn Sie In-App-Nachrichten mit InAppMessageCategoryId.TRANSACTIONAL aktiviert haben, werden Nutzern während des Kulanzzeitraums und der Kontosperre einmal täglich Nachrichten in Google Play angezeigt. So haben sie die Möglichkeit, ihre Zahlung zu korrigieren, ohne die App verlassen zu müssen.

Wir empfehlen, diese API immer dann aufzurufen, wenn der Nutzer die App öffnet, um festzustellen, ob die Mitteilung angezeigt werden soll.

Wenn der Nutzer sein Abo erfolgreich wiederhergestellt hat, erhalten Sie den Antwortcode SUBSCRIPTION_STATUS_UPDATED zusammen mit einem Kauf-Token. Anschließend sollten Sie dieses Kauf-Token verwenden, um die Google Play Developer API aufzurufen und den Abostatus in Ihrer App zu aktualisieren.

In-App-Messaging einbinden

Verwenden Sie BillingClient.showInAppMessages(), um Nutzern In-App-Nachrichten anzuzeigen.

Hier ein Beispiel für das Auslösen des In-App-Messaging-Ablaufs:

val inAppMessageParams = InAppMessageParams.newBuilder()
        .addInAppMessageCategoryToShow(InAppMessageCategoryId.TRANSACTIONAL)
        .build()

billingClient.showInAppMessages(activity,
        inAppMessageParams,
        object : InAppMessageResponseListener() {
            override fun onInAppMessageResponse(inAppMessageResult: InAppMessageResult) {
                if (inAppMessageResult.responseCode == InAppMessageResponseCode.NO_ACTION_NEEDED) {
                    // The flow has finished and there is no action needed from developers.
                } else if (inAppMessageResult.responseCode
                        == InAppMessageResponseCode.SUBSCRIPTION_STATUS_UPDATED) {
                    // The subscription status changed. For example, a subscription
                    // has been recovered from a suspend state. Developers should
                    // expect the purchase token to be returned with this response
                    // code and use the purchase token with the Google Play
                    // Developer API.
                }
            }
        })

InAppMessageParams inAppMessageParams = InAppMessageParams.newBuilder()
        .addInAppMessageCategoryToShow(InAppMessageCategoryId.TRANSACTIONAL)
        .build();

billingClient.showInAppMessages(activity,
        inAppMessageParams,
        new InAppMessageResponseListener() {
            @Override
            public void onInAppMessageResponse(InAppMessageResult inAppMessageResult) {
                if (inAppMessageResult.responseCode
                        == InAppMessageResponseCode.NO_ACTION_NEEDED) {
                    // The flow has finished and there is no action needed from developers.
                } else if (inAppMessageResult.responseCode
                        == InAppMessageResponseCode.SUBSCRIPTION_STATUS_UPDATED) {
                    // The subscription status changed. For example, a subscription
                    // has been recovered from a suspend state. Developers should
                    // expect the purchase token to be returned with this response
                    // code and use the purchase token with the Google Play
                    // Developer API.
                }
            }
        });

Ausstehende Abotransaktionen verarbeiten

Ausstehende Transaktionen können beim ersten Kauf, beim Aufladen, beim Upgrade oder beim Downgrade auftreten. Der Kauf des Abos beginnt mit dem Status SUBSCRIPTION_STATE_PENDING, bevor er zu SUBSCRIPTION_STATE_ACTIVE wechselt. Wenn die Transaktion abgelaufen ist oder vom Nutzer abgebrochen wurde, wird sie in SUBSCRIPTION_STATE_PENDING_PURCHASE_EXPIRED verschoben. Sie müssen und sollten die Berechtigung des Nutzers erst aktualisieren, nachdem die Transaktion abgeschlossen ist.

Die Änderung des Abostatus für den Erstkauf mit ausstehenden Transaktionen ist unkompliziert. Ihre App erhält ein Purchase mit dem Status PENDING, wenn der Nutzer eine ausstehende Transaktion initiiert. Wenn die Transaktion abgeschlossen ist, empfängt Ihre App die Purchase noch einmal mit dem aktualisierten Status PURCHASED. Eine SubscriptionNotification-Nachricht mit dem Typ SUBSCRIPTION_PURCHASED wird an Ihren RTDN-Client gesendet. Gehen Sie wie gewohnt vor, um den Kauf zu bestätigen, dem Nutzer Zugriff auf die Inhalte zu gewähren und den Kauf zu bestätigen. Wenn die Transaktion abläuft oder storniert wird, wird eine SubscriptionNotification-Nachricht mit dem Typ SUBSCRIPTION_PENDING_PURCHASE_CANCELED an Ihren RTDN-Client gesendet. In solchen Fällen sollte der Nutzer nie Zugriff auf die Inhalte erhalten haben.

Wenn Sie ein Guthaben aufladen oder ein Upgrade oder Downgrade mit ausstehenden Transaktionen durchführen, ändert sich der Status sowohl für das alte als auch für das neue Abo. Wenn der Nutzer eine ausstehende Transaktion zum Aufladen, Upgraden oder Downgraden startet, erhält Ihre App für das alte Abo ein Purchase mit einem PendingPurchaseUpdate-Objekt. Zu diesem Zeitpunkt hat der Nutzer noch das alte Abo und noch nicht das neue. Wenn Sie getProducts() und getPurchaseToken() für das PendingPurchaseUpdate-Objekt aufrufen, werden die Produkt-IDs und das Kauf-Token des neuen Abos zurückgegeben. Wenn die Transaktion abgeschlossen ist, erhält Ihre App ein Purchase mit dem auf oberster Ebene festgelegten Kauf-Token für das neue Abo und dem Status PURCHASED. Eine SubscriptionNotification-Nachricht mit dem Typ SUBSCRIPTION_PURCHASED wird an Ihren RTDN-Client gesendet. Erst dann sollten Sie das alte Kauf-Token durch das neue ersetzen und den Zugriff des Nutzers auf die Inhalte aktualisieren. Wenn die Transaktion abläuft oder abgebrochen wird, wird eine SubscriptionNotification-Nachricht mit dem Typ SUBSCRIPTION_PENDING_PURCHASE_CANCELED an Ihren RTDN-Client gesendet. In solchen Fällen sollte der Nutzer weiterhin Zugriff auf die Inhalte des alten Abos haben.