Abo-Ersatz mit Google Play Billing implementieren

1. Einführung

In diesem Codelab erfahren Sie, wie Sie mit der Google Play Billing Library (PBL) Änderungen an Abos verwalten. Sie erfahren, wie sich verschiedene Ersatzmodi auf die Preise und Nutzerberechtigungen auswirken, und lernen, wie Sie Entwicklerbenachrichtigungen in Echtzeit (RTDNs) im Backend verarbeiten.

Zielgruppe

Dieses Codelab richtet sich an Entwickler von Android-Apps und bietet eine Anleitung zum Implementieren komplexer Funktionen zur Aboverwaltung. Die Anleitung hilft Ihnen, Nutzern einen reibungslosen Wechsel zwischen verschiedenen Abos zu ermöglichen.

Lerninhalte

• Abos in der Play Console erstellen
• Wie Sie die richtige ReplacementMode (z.B. WITH_TIME_PRORATION im Vergleich zu DEFERRED) auswählen, die den Upgrade- und Downgrade-Richtlinien Ihrer App entspricht.
• So konfigurieren Sie BillingFlowParams in launchBillingFlow, um den Google Play-Kaufvorgang für einen Abo-Ersatz auszulösen.
• Entwicklerbenachrichtigungen in Echtzeit (RTDN) und die purchases.subscriptionsv2 API verwenden, um alten Zugriff sicher zu widerrufen und neuen Zugriff auf Ihr Backend zu gewähren

Voraussetzungen

• Zugriff auf die Google Play Console mit einem Entwicklerkonto. Wenn Sie noch kein Entwicklerkonto haben, müssen Sie eines erstellen.
• Die Beispiel-App für dieses Codelab, die Sie von GitHub herunterladen können.
• Android Studio

2. Beispiel-App erstellen

In diesem Codelab wird anhand einer Beispiel-Android-App gezeigt, wie Sie den Ersatz von Abos in PBL implementieren. Die Beispiel-App ist als voll funktionsfähige Android-App konzipiert, deren vollständiger Quellcode die folgenden Aspekte zeigt:

• App in PBL einbinden
• Aboersetzungen implementieren

Wenn Sie bereits mit Abo-Ersatz und PBL vertraut sind, können Sie die Beispiel-App herunterladen und damit experimentieren.

Im folgenden Demovideo sehen Sie, wie die Beispiel-App nach der Bereitstellung und Ausführung aussieht und sich verhält.

Vorbereitung

Führen Sie vor dem Erstellen und Bereitstellen der Beispiel-App die folgenden Schritte aus:

• Erstellen Sie ein Google Play Console-Entwicklerkonto. Wenn Sie bereits ein Entwicklerkonto haben, überspringen Sie diesen Schritt.
• Erstellen Sie eine neue App in der Play Console mit aktivierten Monetarisierungsfunktionen. Alternativ können Sie eine vorhandene App in der Play Console verwenden. Wenn die Monetarisierungsfunktionen für Ihre App nicht aktiviert sind, folgen Sie dieser Anleitung, um sie einzurichten.
• Installiere Android Studio.

Build

So erstellen Sie die Beispiel-App, die für das Codelab erforderlich ist:

1. Laden Sie die Beispiel-App von GitHub herunter.
2. Aktualisieren Sie die applicationId in der build.gradle der Beispiel-App, damit sie der Anwendungs-ID Ihrer App in der Play Developer Console entspricht.
3. Beispiel-App erstellen.
   Hinweis: Dadurch wird die App erfolgreich für lokale Tests erstellt. Beim Ausführen der App werden jedoch keine Produkte und Preise abgerufen, da die erforderlichen Abos noch nicht in der Play Console erstellt wurden. Im nächsten Abschnitt wird beschrieben, wie Sie Abos in der Developer Console erstellen.

3. Abos in der Play Console erstellen

Mit dem Google Play-Abosystem lassen sich Abos flexibel erstellen, verwalten und verkaufen. In der Play Console können Sie Abos mit mehreren Basis-Abos konfigurieren, die jeweils mehrere Angebote enthalten. Für Aboangebote lassen sich verschiedene Preismodelle und Voraussetzungen festlegen. In diesem Codelab erstellen Sie drei Abos: Premium Plan, Basic Plan und Lite Plan. Damit simulieren Sie ein typisches Aboangebot mit verschiedenen Preisen. Jedes dieser Abos hat ein einziges monatliches Basis-Abo.

Neues Abo erstellen

So erstellen Sie ein neues Abo:

1. Öffnen Sie die Play Console und rufen Sie die Seite Abos auf (Mit Google Play monetarisieren > Produkte > Abos).
2. Klicken Sie auf Abo erstellen.
3. Geben Sie die Details zu Ihrem Abo ein:
   • ProductID : Geben Sie eine eindeutige Produkt-ID ein. Geben Sie premium_plan ein.
   • Name : Geben Sie einen Kurznamen für das Abo ein. Beispiel: Premium Plan.
4. Klicken Sie auf Erstellen.

Basis-Abo erstellen

1. Öffnen Sie die Play Console und rufen Sie die Seite Abos auf (Mit Google Play monetarisieren > Produkte > Abos).
2. Klicken Sie neben dem Abo, für das Sie ein Basis-Abo erstellen möchten, auf den Rechtspfeil, um die Abodetails aufzurufen.
3. Klicken Sie auf Basis-Abo hinzufügen.
4. Geben Sie eine ID für das Basis-Abo ein. Beispiel: monthly-auto-renewing
5. Wählen Sie als Typ Automatische Verlängerung aus.
6. Legen Sie für das Basis-Abo mit automatischer Verlängerung Folgendes fest:
   • Abrechnungszeitraum: Monatlich.
   • Kulanzzeitraum: 7 Tage.
   • Preismodell und Angebotswechsel: Am Abrechnungsdatum belasten.
   • Erneut abonnieren: Zulassen.
7. Klicken Sie im Abschnitt Preis und Verfügbarkeit auf Preise festlegen, um den Preis des Basis-Abos festzulegen.
8. Wählen Sie alle Länder und Regionen aus und klicken Sie dann auf Preis festlegen.
9. Legen Sie den Preis für dieses Basis-Abo auf 10 $ fest und klicken Sie auf Aktualisieren.
10. Wenn der Preis für das Basis-Abo festgelegt ist, klicken Sie rechts unten auf Speichern und dann auf Aktivieren.

Abos für die Beispiel-App erstellen

Erstellen Sie für dieses Codelab zwei zusätzliche Abos mit der folgenden Konfiguration:

• Basic Plan
  • Produkt-ID: basic_plan
  • Name: Basic Plan (Basis-Abo)
  • Basis-Abo-ID: monthly-auto-renewing
  • Preis: 5 $
• Lite-Abo
  • Produkt-ID: lite_plan
  • Name: Lite-Abo
  • Basis-Abo-ID: monthly-auto-renewing
  • Preis: 3 $

Die Beispiel-App ist für die Verwendung dieser Produkt-IDs und Basis-Abo-IDs konfiguriert. Sie können verschiedene Abos mit unterschiedlichen Konfigurationen erstellen. In diesem Fall müssen Sie die Beispiel-App so ändern, dass die von Ihnen erstellte Produkt-ID verwendet wird.

Video zur Aboerstellung

Im folgenden Video sehen Sie die oben beschriebenen Schritte zum Erstellen eines Abos in der Play Console.

4. Abo-Ersatz

Entwickler, die PBL integrieren, können ihren bestehenden Abonnenten verschiedene Optionen anbieten, um ihr Abo zu ändern und besser an ihre Bedürfnisse anzupassen:

• Wenn Sie mehrere Abostufen 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.

Wenn Nutzer ihr Abo upgraden, downgraden oder ändern, geben Sie einen replacement mode (Ersatzmodus) an, der bestimmt, wie der anteilige Wert des aktuellen Abrechnungszeitraums angewendet wird und wann die Berechtigungsänderung für die Nutzer erfolgt.

Die Play Billing Library bietet mehrere ReplacementMode-Optionen, um dieses Verhalten zu steuern.

Verfügbare Ersatzmodi

• WITH_TIME_PRORATION: Das Abo-Artikel wird sofort aktualisiert. Die verbleibende Zeit wird auf Grundlage der Preisdifferenz angepasst und dem neuen Abo gutgeschrieben, indem das nächste Abrechnungsdatum aktualisiert wird. Dies ist das Standardverhalten.
• CHARGE_PRORATED_PRICE: Das Abo-Artikel wird sofort aktualisiert und der Abrechnungszeitraum bleibt unverändert. Die Preisdifferenz für den verbleibenden Zeitraum wird dem Nutzer dann in Rechnung gestellt.
• CHARGE_FULL_PRICE: Das Abo-Item wird sofort aktualisiert und dem Nutzer wird der volle Preis für die neue Berechtigung in Rechnung gestellt. Der verbleibende Wert des vorherigen Abos wird entweder für dieselbe Berechtigung übertragen oder bei einem Wechsel zu einer anderen Berechtigung anteilig berechnet.
• WITHOUT_PRORATION: Das Abo-Item wird sofort aktualisiert und der neue Preis wird bei der Aboverlängerung berechnet. Der Abrechnungszeitraum bleibt unverändert.
• DEFERRED: Das Abo-Artikel wird nur beim Erneuern des Abos aktualisiert.

Wenn Sie für einen bestimmten Übergang einen ungültigen Ersatzmodus angeben (z. B. CHARGE_PRORATED_PRICE für ein Downgrade), schlägt der Abrechnungsablauf fehl und dem Nutzer wird eine Fehlermeldung angezeigt.

5. WITH_TIME_PRORATION

In diesem Ersatzmodus wird das Abo-Artikel sofort aktualisiert. Die verbleibende Zeit wird auf Grundlage der Preisdifferenz angepasst und dem neuen Abo gutgeschrieben, indem das nächste Abrechnungsdatum nach vorn verschoben wird. Das ist das Standardverhalten.

Beispielszenario

Ein Nutzer wechselt am 15. April, also in der Mitte seines monatlichen Abrechnungszeitraums, von einem Basic-Tarif (4,99 $ pro Monat) zu einem Premium-Tarif (9,99 $ pro Monat).

Für dieses Beispiel gilt:

• Der Nutzer erhält sofort Zugriff auf das Premium-Abo.
• Der anteilige Zeitraum wird automatisch von Google Play berechnet. Wenn Play beispielsweise berechnet, dass die verbleibenden 15 Tage des Basic-Abos 7 Tagen des Premium-Abos entsprechen, wird das nächste Abrechnungsdatum auf den 21. April verschoben.
• Der Nutzer muss nicht sofort bezahlen.

Code-Snippet

// ProductDetails for the plan to be switched to
ProductDetails productDetails = ...;
// The specific offer token for the toBeSwitched plan's base plan
String offerToken = "...";
// The purchase token of the user's current subscription
String oldPurchaseToken = "...";
// The productId for the user's current subscription
String oldProductId = "...";
// The replacementMode to replace the user's subscription
int replacementMode = SubscriptionProductReplacementParams.ReplacementMode.WITH_TIME_PRORATION;

SubscriptionProductReplacementParams subscriptionProductReplacementParams =
    SubscriptionProductReplacementParams.newBuilder()
        .setOldProductId(oldProductId)
        .setReplacementMode(replacementMode)
        .build();

ProductDetailsParams productDetailsParams =
    ProductDetailsParams.newBuilder()
        .setProductDetails(productDetails)
        .setSubscriptionProductReplacementParams(subscriptionProductReplacementParams)
        .setOfferToken(offerToken)
        .build();

List<ProductDetailsParams> productDetailsParamsList = ImmutableList.of(productDetailsParams);

BillingFlowParams billingFlowParams =
    BillingFlowParams.newBuilder()
        .setProductDetailsParamsList(productDetailsParamsList)
        .setSubscriptionUpdateParams(
            SubscriptionUpdateParams.newBuilder().setOldPurchaseToken(oldPurchaseToken).build())
        .build();

billingClient.launchBillingFlow(activity, billingFlowParams);

Upgrade mit WITH_TIME_PRORATION

So simulieren Sie dieses Szenario:

• Aktualisieren Sie in der MainActivity der Beispiel-App die replacementMode im Code-Snippet auf SubscriptionProductReplacementParams.ReplacementMode.WITH_TIME_PRORATION.
• Erstellen Sie die Anwendung neu und starten Sie sie.
• Kündigen Sie alle vorhandenen Abos im Google Play Store und lassen Sie sie auslaufen.
• Kaufen Sie das Basic-Abo.
• Wechseln Sie zum Premium-Abo.

Die Berechtigung des Nutzers wird sofort auf das Premium-Abo aktualisiert. Der Betrag, der vom Nutzer sofort zu zahlen ist, beträgt 0,00 $. Der Restwert des Basic-Abos wird anteilig auf das Premium-Abo angerechnet, wodurch sich das nächste Verlängerungsdatum vorverlegt. Dem Nutzer wird am neu angepassten Abrechnungsdatum der Verlängerungsbetrag von 9,99 $ in Rechnung gestellt.

Herabstufung mit WITH_TIME_PRORATION

So simulieren Sie dieses Szenario:

• Aktualisieren Sie in der MainActivity der Beispiel-App die replacementMode im Code-Snippet auf SubscriptionProductReplacementParams.ReplacementMode.WITH_TIME_PRORATION.
• Erstellen Sie die Anwendung neu und starten Sie sie.
• Kündigen Sie alle vorhandenen Abos im Google Play Store und lassen Sie sie auslaufen.
• Kaufen Sie das Basic-Abo.
• Wechseln Sie zum Lite-Abo.

Die Berechtigung des Nutzers wird sofort auf den Lite-Tarif herabgestuft. Der sofort zu zahlende Betrag beträgt 0,00 $. Der Restwert des Basic-Abos wird anteilig in Zeit für das Lite-Abo umgerechnet, wodurch sich das nächste Verlängerungsdatum erheblich verlängert. Dem Nutzer wird am neu angepassten Abrechnungsdatum der Verlängerungsbetrag von 2,99 $ in Rechnung gestellt.

Fazit

In diesem Abschnitt haben Sie erfahren, wie WITH_TIME_PRORATION Nutzerberechtigungen ohne sofortige Belastung ändert, indem die Zeit bis zur nächsten Verlängerung basierend auf der Preisdifferenz angepasst wird. Sie ist eine effektive Standardstrategie zum Upgraden oder Downgraden von Nutzern.

6. CHARGE_PRORATED_PRICE

In diesem Ersatzmodus wird das Abo-Artikel sofort aktualisiert und der Abrechnungszeitraum bleibt gleich. Die Preisdifferenz für den verbleibenden Zeitraum wird dem Nutzer dann in Rechnung gestellt.

Hinweis: Diese Option ist nur für ein Upgrade eines Aboartikels verfügbar, bei dem der Preis pro Zeiteinheit steigt.

Beispielszenario

Ein Nutzer mit dem Basic-Abo (4,99 $ pro Monat) entscheidet sich am 20.April für ein Upgrade auf das Premium-Abo (9,99 $ pro Monat). Bis zum Ende des monatlichen Abrechnungszeitraums sind es noch etwa 10 Tage.

Für dieses Beispiel gilt:

• Der Nutzer erhält sofort Zugriff auf das Premium-Abo.
• Dem Nutzer wird sofort die anteilige Differenz für die verbleibenden 10 Tage des aktuellen Abrechnungszeitraums in Rechnung gestellt. Das entspricht ungefähr 2,99 $, dem Preis für 10 Tage des Premium-Abos.
• Das Abrechnungsdatum für den Nutzer ändert sich nicht.

Code-Snippet

// ProductDetails for the plan to be switched to
ProductDetails productDetails = ...;
// The specific offer token for the toBeSwitched plan's base plan
String offerToken = "...";
// The purchase token of the user's current subscription
String oldPurchaseToken = "...";
// The productId for the user's current subscription
String oldProductId = "...";
// The replacementMode to replace the user's subscription
int replacementMode = SubscriptionProductReplacementParams.ReplacementMode.CHARGE_PRORATED_PRICE;

SubscriptionProductReplacementParams subscriptionProductReplacementParams =
    SubscriptionProductReplacementParams.newBuilder()
        .setOldProductId(oldProductId)
        .setReplacementMode(replacementMode)
        .build();

ProductDetailsParams productDetailsParams =
    ProductDetailsParams.newBuilder()
        .setProductDetails(productDetails)
        .setSubscriptionProductReplacementParams(subscriptionProductReplacementParams)
        .setOfferToken(offerToken)
        .build();

List<ProductDetailsParams> productDetailsParamsList = ImmutableList.of(productDetailsParams);

BillingFlowParams billingFlowParams =
    BillingFlowParams.newBuilder()
        .setProductDetailsParamsList(productDetailsParamsList)
        .setSubscriptionUpdateParams(
            SubscriptionUpdateParams.newBuilder().setOldPurchaseToken(oldPurchaseToken).build())
        .build();

billingClient.launchBillingFlow(activity, billingFlowParams);

Upgrade mit CHARGE_PRORATED_PRICE

So simulieren Sie dieses Szenario:

• Aktualisieren Sie in der MainActivity der Beispiel-App die replacementMode im Code-Snippet auf SubscriptionProductReplacementParams.ReplacementMode.CHARGE_PRORATED_PRICE.
• Erstellen Sie die Anwendung neu und starten Sie sie.
• Kündigen Sie alle vorhandenen Abos im Google Play Store und lassen Sie sie auslaufen.
• Kaufen Sie das Basic-Abo.
• Wechseln Sie zum Premium-Abo.

Der Nutzer erhält sofort ein Upgrade auf das Premium-Abo. Das ursprüngliche Verlängerungsdatum bleibt bestehen. Der sofort zu zahlende Betrag ist die anteilige Differenz zwischen den Preisen für das Premium- und das Basic-Abo für die verbleibenden Tage des aktuellen Abrechnungszeitraums. Am Verlängerungsdatum wird dem Nutzer der volle Verlängerungsbetrag von 9, 99 $ für Premium in Rechnung gestellt.

Herabstufung mit CHARGE_PRORATED_PRICE

So simulieren Sie dieses Szenario:

• Aktualisieren Sie in der MainActivity der Beispiel-App die replacementMode im Code-Snippet auf SubscriptionProductReplacementParams.ReplacementMode.CHARGE_PRORATED_PRICE.
• Erstellen Sie die Anwendung neu und starten Sie sie.
• Kündigen Sie alle vorhandenen Abos im Google Play Store und lassen Sie sie auslaufen.
• Kaufen Sie das Basic-Abo.
• Wechseln Sie zum Lite-Abo.

Dieser Ersatzmodus führt bei einem Downgrade zu einem Fehler, da er nur für Upgrades von Abo-Artikeln verfügbar ist, bei denen der Preis pro Zeiteinheit steigt. Der Abrechnungsvorgang schlägt fehl und dem Nutzer wird eine Fehlermeldung angezeigt, dass der anteilige Abrechnungsmodus für Downgrades nicht unterstützt wird.

Fazit

In diesem Abschnitt wurde erläutert, wie CHARGE_PRORATED_PRICE sofortige Upgrades ermöglicht, indem Nutzern die genaue Preisdifferenz für den verbleibenden Abrechnungszeitraum in Rechnung gestellt wird, während der Abrechnungszeitraum unverändert bleibt. Das ist nützlich, wenn der Nutzer auf ein teureres Abo upgraden möchte, ohne das Abrechnungsdatum zu ändern.

7. CHARGE_FULL_PRICE

Bei diesem Ersatzmodus wird das Abo-Artikel sofort aktualisiert und dem Nutzer wird sofort der volle Preis für die neue Berechtigung in Rechnung gestellt. Der verbleibende Wert des vorherigen Abos wird entweder für dieselbe Berechtigung übertragen oder bei einem Wechsel zu einer anderen Berechtigung anteilig berechnet.

Beispielszenario

Ein Nutzer hat den Basic-Tarif (ab 1.April 4,99 $ pro Monat). Am 20.April möchte der Nutzer zum Premium-Abo (9, 99 $ pro Monat) wechseln.

Für dieses Beispiel gilt:

• Dem Nutzer wird sofort der volle Preis für das Premium-Abo (9,99 $) in Rechnung gestellt.
• Der verbleibende Wert des Basic-Abos (z.B. 10 Tage) wird in die entsprechende Zeit für das Premium-Abo umgewandelt. In diesem Beispiel entsprechen 10 Tage mit Basic 5 Tagen mit Premium.
• Das nächste Verlängerungsdatum des Nutzers wird angepasst, um diesen anteiligen Zeitraum zu berücksichtigen. Das Verlängerungsdatum ist also der 25. Mai (20. April + 1 Monat + 5 Tage).
• Die Verlängerungen erfolgen ab dem 25. Mai monatlich.

Code-Snippet

// ProductDetails for the plan to be switched to
ProductDetails productDetails = ...;
// The specific offer token for the toBeSwitched plan's base plan
String offerToken = "...";
// The purchase token of the user's current subscription
String oldPurchaseToken = "...";
// The productId for the user's current subscription
String oldProductId = "...";
// The replacementMode to replace the user's subscription
int replacementMode = SubscriptionProductReplacementParams.ReplacementMode.CHARGE_FULL_PRICE;

SubscriptionProductReplacementParams subscriptionProductReplacementParams =
    SubscriptionProductReplacementParams.newBuilder()
        .setOldProductId(oldProductId)
        .setReplacementMode(replacementMode)
        .build();

ProductDetailsParams productDetailsParams =
    ProductDetailsParams.newBuilder()
        .setProductDetails(productDetails)
        .setSubscriptionProductReplacementParams(subscriptionProductReplacementParams)
        .setOfferToken(offerToken)
        .build();

List<ProductDetailsParams> productDetailsParamsList = ImmutableList.of(productDetailsParams);

BillingFlowParams billingFlowParams =
    BillingFlowParams.newBuilder()
        .setProductDetailsParamsList(productDetailsParamsList)
        .setSubscriptionUpdateParams(
            SubscriptionUpdateParams.newBuilder().setOldPurchaseToken(oldPurchaseToken).build())
        .build();

billingClient.launchBillingFlow(activity, billingFlowParams);

Upgrade mit CHARGE_FULL_PRICE

So simulieren Sie dieses Szenario:

• Aktualisieren Sie in der MainActivity der Beispiel-App die replacementMode im Code-Snippet auf SubscriptionProductReplacementParams.ReplacementMode.CHARGE_FULL_PRICE.
• Erstellen Sie die Anwendung neu und starten Sie sie.
• Kündigen Sie alle vorhandenen Abos im Google Play Store und lassen Sie sie auslaufen.
• Kaufen Sie das Basic-Abo.
• Wechseln Sie zum Premium-Abo.

Der Nutzer wird sofort auf das Premium-Abo umgestellt. Der sofort zu zahlende Betrag entspricht dem vollen Preis des Premium-Abos in Höhe von 9,99 $. Alle verbleibenden Werte aus dem Basic-Abo werden in Zeit für das neue Premium-Abo umgewandelt, wodurch sich das erste Verlängerungsdatum geringfügig verschiebt. Danach beträgt der Verlängerungsbetrag 9, 99 $ pro Abrechnungszeitraum.

Downgrade mit CHARGE_FULL_PRICE

So simulieren Sie dieses Szenario:

• Aktualisieren Sie in der MainActivity der Beispiel-App die replacementMode im Code-Snippet auf SubscriptionProductReplacementParams.ReplacementMode.CHARGE_FULL_PRICE.
• Erstellen Sie die Anwendung neu und starten Sie sie.
• Kündigen Sie alle vorhandenen Abos im Google Play Store und lassen Sie sie auslaufen.
• Kaufen Sie das Basic-Abo.
• Wechseln Sie zum Lite-Abo.

Der Nutzer wird sofort auf das Lite-Abo herabgestuft und ein neuer Abrechnungszeitraum beginnt. Der sofort zu zahlende Betrag entspricht dem vollen Zielpreis von 2,99 $. Der nicht genutzte Teil des Basic-Abos wird anteilig in Zeit für das neue Lite-Abo umgerechnet, wodurch sich das erste Verlängerungsdatum verschiebt. Danach beträgt der Verlängerungsbetrag 2, 99 € pro Zyklus.

Fazit

In diesem Abschnitt haben wir beschrieben, wie CHARGE_FULL_PRICE dem Nutzer am Tag des Wechsels den vollen Betrag in Rechnung stellt und sofort einen neuen Abrechnungszeitraum beginnt. Alle verbleibenden Guthaben aus dem vorherigen Abo werden linear auf das nächste Verlängerungsdatum angewendet.

8. WITHOUT_PRORATION

In diesem Ersatzmodus wird der Aboartikel sofort aktualisiert und der neue Preis wird bei der Verlängerung des Abos berechnet.

Beispielszenario

Ein Nutzer hat den Basic-Tarif (ab 1.April 4,99 $ pro Monat). Am 20.April möchte der Nutzer zum Premium-Abo (9, 99 $ pro Monat) wechseln.

Für dieses Beispiel gilt:

• Der Nutzer erhält sofort Zugriff auf das Premium-Abo.
• Der Nutzer muss den höheren Preis von 9,99 $ erst am nächsten Verlängerungsdatum des Abos (1.Mai) bezahlen.

Code-Snippet

// ProductDetails for the plan to be switched to
ProductDetails productDetails = ...;
// The specific offer token for the toBeSwitched plan's base plan
String offerToken = "...";
// The purchase token of the user's current subscription
String oldPurchaseToken = "...";
// The productId for the user's current subscription
String oldProductId = "...";
// The replacementMode to replace the user's subscription
int replacementMode = SubscriptionProductReplacementParams.ReplacementMode.WITHOUT_PRORATION;

SubscriptionProductReplacementParams subscriptionProductReplacementParams =
    SubscriptionProductReplacementParams.newBuilder()
        .setOldProductId(oldProductId)
        .setReplacementMode(replacementMode)
        .build();

ProductDetailsParams productDetailsParams =
    ProductDetailsParams.newBuilder()
        .setProductDetails(productDetails)
        .setSubscriptionProductReplacementParams(subscriptionProductReplacementParams)
        .setOfferToken(offerToken)
        .build();

List<ProductDetailsParams> productDetailsParamsList = ImmutableList.of(productDetailsParams);

BillingFlowParams billingFlowParams =
    BillingFlowParams.newBuilder()
        .setProductDetailsParamsList(productDetailsParamsList)
        .setSubscriptionUpdateParams(
            SubscriptionUpdateParams.newBuilder().setOldPurchaseToken(oldPurchaseToken).build())
        .build();

billingClient.launchBillingFlow(activity, billingFlowParams);

Upgrade mit WITHOUT_PRORATION

So simulieren Sie dieses Szenario:

• Aktualisieren Sie in der MainActivity der Beispiel-App die replacementMode im Code-Snippet auf SubscriptionProductReplacementParams.ReplacementMode.WITHOUT_PRORATION.
• Erstellen Sie die Anwendung neu und starten Sie sie.
• Kündigen Sie alle vorhandenen Abos im Google Play Store und lassen Sie sie auslaufen.
• Kaufen Sie das Basic-Abo.
• Wechseln Sie zum Premium-Abo.

Der Nutzer wird sofort auf den Premium-Tarif umgestellt, wobei das bestehende Verlängerungsdatum beibehalten wird. Der sofort zu zahlende Betrag beträgt 0,00 $. Der Nutzer hat für die verbleibende Zeit im angegebenen Zeitraum Zugriff auf das Premium-Abo, bevor er am nächsten Abrechnungsdatum zum neuen Verlängerungsbetrag von 9,99 $ wechselt.

Downgrade mit WITHOUT_PRORATION

So simulieren Sie dieses Szenario:

• Aktualisieren Sie in der MainActivity der Beispiel-App die replacementMode im Code-Snippet auf SubscriptionProductReplacementParams.ReplacementMode.WITHOUT_PRORATION.
• Erstellen Sie die Anwendung neu und starten Sie sie.
• Kündigen Sie alle vorhandenen Abos im Google Play Store und lassen Sie sie auslaufen.
• Kaufen Sie das Basic-Abo.
• Wechseln Sie zum Lite-Abo.

Der Nutzer wird sofort auf das Lite-Abo herabgestuft und verliert die Basic-Funktionen, für die er bezahlt hat. Der sofort zu zahlende Betrag beträgt 0,00 $. Der Abrechnungszeitraum wird nicht geändert und der Nutzer zahlt bei der nächsten geplanten Verlängerung den neuen, niedrigeren Preis von 2, 99 $.

Fazit

In diesem Abschnitt wurde gezeigt, wie WITHOUT_PRORATION die Berechtigungen des Nutzers sofort und ohne Belastung des Kontos ändert, ohne den Abrechnungszeitraum zu ändern.

9. AUSGESETZT

In diesem Ersatzmodus wird das Abo-Artikel nur bei der Aboverlängerung aktualisiert, der neue Kauf wird jedoch sofort ausgestellt. Das vorhandene Element wird auf „nicht verlängerbar“ gesetzt und läuft am Ende des aktuellen Abrechnungszeitraums ab. Die neu angeforderte Berechtigung beginnt direkt danach.

Beispielszenario

Ein Nutzer hat den Basic-Tarif (ab 1.April 4,99 $ pro Monat). Am 20.April möchte der Nutzer zum Premium-Abo (9, 99 $ pro Monat) wechseln.

Für dieses Beispiel gilt:

• Dem Nutzer werden keine Kosten in Rechnung gestellt.
• Der Nutzer kann die Basic-Funktionen bis zum Ende des aktuellen Abrechnungszeitraums (30. April) weiterhin nutzen.
• Das Abo wird am nächsten Verlängerungsdatum (1. Mai) automatisch auf Premium aktualisiert.

Code-Snippet

// ProductDetails for the plan to be switched to
ProductDetails productDetails = ...;
// The specific offer token for the toBeSwitched plan's base plan
String offerToken = "...";
// The purchase token of the user's current subscription
String oldPurchaseToken = "...";
// The productId for the user's current subscription
String oldProductId = "...";
// The replacementMode to replace the user's subscription
int replacementMode = SubscriptionProductReplacementParams.ReplacementMode.DEFERRED;

SubscriptionProductReplacementParams subscriptionProductReplacementParams =
    SubscriptionProductReplacementParams.newBuilder()
        .setOldProductId(oldProductId)
        .setReplacementMode(replacementMode)
        .build();

ProductDetailsParams productDetailsParams =
    ProductDetailsParams.newBuilder()
        .setProductDetails(productDetails)
        .setSubscriptionProductReplacementParams(subscriptionProductReplacementParams)
        .setOfferToken(offerToken)
        .build();

List<ProductDetailsParams> productDetailsParamsList = ImmutableList.of(productDetailsParams);

BillingFlowParams billingFlowParams =
    BillingFlowParams.newBuilder()
        .setProductDetailsParamsList(productDetailsParamsList)
        .setSubscriptionUpdateParams(
            SubscriptionUpdateParams.newBuilder().setOldPurchaseToken(oldPurchaseToken).build())
        .build();

billingClient.launchBillingFlow(activity, billingFlowParams);

Upgrade mit DEFERRED

So simulieren Sie dieses Szenario:

• Aktualisieren Sie in der MainActivity der Beispiel-App die replacementMode im Code-Snippet auf SubscriptionProductReplacementParams.ReplacementMode.DEFERRED.
• Erstellen Sie die Anwendung neu und starten Sie sie.
• Kündigen Sie alle vorhandenen Abos im Google Play Store und lassen Sie sie auslaufen.
• Kaufen Sie das Basic-Abo.
• Wechseln Sie zum Premium-Abo.

Der Nutzer behält das Basic-Abo bis zum Ende des aktuellen Abrechnungszeitraums. Der sofort zu zahlende Betrag beträgt 0,00 $. Am Verlängerungsdatum wird ihr Anspruch auf das Premium-Abo aktualisiert und ihnen wird der neue Verlängerungsbetrag von 9, 99 $ in Rechnung gestellt.

Downgrade mit DEFERRED

So simulieren Sie dieses Szenario:

• Aktualisieren Sie in der MainActivity der Beispiel-App die replacementMode im Code-Snippet auf SubscriptionProductReplacementParams.ReplacementMode.DEFERRED.
• Erstellen Sie die Anwendung neu und starten Sie sie.
• Kündigen Sie alle vorhandenen Abos im Google Play Store und lassen Sie sie auslaufen.
• Kaufen Sie das Basic-Abo.
• Wechseln Sie zum Lite-Abo.

Der Nutzer behält das Basic-Abo bis zum Ende des aktuellen Abrechnungszeitraums. Der sofort zu zahlende Betrag beträgt 0,00 $. Am Verlängerungsdatum wird ihr Anspruch auf das Lite-Abo aktualisiert und ihnen wird der neue Verlängerungsbetrag von 2, 99 $ in Rechnung gestellt.

Fazit

In diesem Abschnitt wurde erläutert, wie der DEFERRED-Ersatzmodus ein Upgrade oder Downgrade bis zum Ende der bezahlten Zeit eines aktiven Nutzers verschiebt. Das ist besonders ideal für Downgrades, um den Verlust bereits gekaufter Funktionen zu verhindern.

10. Backend- und clientseitige Verarbeitung

Nachdem ein Nutzer ein Abo erfolgreich ersetzt hat, müssen sowohl Ihre App als auch Ihr Backend die Änderung korrekt verarbeiten, um Probleme wie Dienstunterbrechungen oder Doppelabrechnungen zu vermeiden.

Beispielszenario

• Der Nutzer hat ein monatliches Basic-Abo (product_id basic_plan und purchase_token basic_purchase_token_123).
• Der Nutzer wechselt zu einem Premium-Abo mit einem sofortigen Ersatzmodus (WITHOUT_PRORATION, WITH_TIME_PRORATION, CHARGE_PRORATED_PRICE oder CHARGE_FULL_PRICE).
• Nachdem das Abo erfolgreich umgestellt wurde, behandelt Google es als NEUES Abo und erstellt ein neues, anderes Kauf-Token für das Premium-Abo (product_id premium_plan und purchase_token premium_purchase_token_123).

Clientseitige Verarbeitung

onPurchasesUpdated

Wenn der Ersatzkauf abgeschlossen ist, wird PurchasesUpdatedListener ausgelöst. Auch wenn es sich um einen Wechsel handelte, wird das Premium-Abo bei Google Play als völlig neuer Kauf behandelt.

Die App erhält ein Purchase-Objekt mit dem Kauf-Token premium_purchase_token_123 und der Produkt-ID premium_plan. Sie müssen diesen Nutzer genau wie einen neuen Abonnenten behandeln: Verifizieren Sie das Token und bereiten Sie den Zugriff vor.

@Override
public void onPurchasesUpdated(BillingResult billingResult, List<Purchase> purchases) {
    if (billingResult.getResponseCode() == BillingResponseCode.OK && purchases != null) {
        for (Purchase purchase : purchases) {
            // purchase.getPurchaseToken() = premium_purchase_token_123
            // purchase.getProducts() will contain premium_plan
            // Verify the purchase and grant entitlement
            handleNewPurchase(purchase);
        }
    }
}

queryPurchasesAsync

queryPurchasesAsync gibt nur aktive Abos zurück, die über Ihre App gekauft wurden. Sie sollten sich auf diese Methode verlassen, um zu bestimmen, welche Berechtigung dem Nutzer angezeigt werden soll. Bei sofortigen Ersatzkäufen gibt queryPurchasesAsync() den alten BASIC-Kauf-Token nicht mehr zurück, sondern nur noch den neuen PREMIUM-Kauf-Token.

Rufen Sie diese Methode immer auf, wenn Ihre App fortgesetzt wird oder ein Kauf abgeschlossen ist. Wenn das Premium-Token vorhanden ist, gewähren Sie sofort Premium-Funktionen und entfernen Sie die Basic-Funktionen.

Back-End-Verarbeitung (RTDN)

Wenn ein Ersatz erfolgt, sendet Google Play eine Entwicklerbenachrichtigung in Echtzeit (Real-time Developer Notification, RTDN) an das von Ihnen konfigurierte Pub/Sub-Thema.

• Im Falle eines sofortigen Ersatzes sendet Google eine SUBSCRIPTION_PURCHASED-RTDN mit dem neuen Kauf-Token.Beispiel für eine RTDN-Nutzlast

  {
    "version":"1.0",
    "packageName":"com.google.play.billing.samples.subscriptions",
    "eventTimeMillis":"...",
    "subscriptionNotification":
    {
      "version":"1.0",
      "notificationType":4, // SUBSCRIPTION_PURCHASED
      "purchaseToken":"premium_purchase_token_123" //purchase token for the new subscription
    }
  }
  

• Wenn Ihr Server das neue Kauf-Token vom RTDN empfängt, rufen Sie die purchases.subscriptionsV2 API mit dem neuen Kauf-Token auf, um die Kaufdetails abzurufen. Die API-Antwort enthält das Feld linkedPurchaseToken, mit dem ermittelt wird, ob sich das Kauf-Token auf einen neuen Abo-Kauf oder einen Abo-Ersatz bezieht.
• Bei einem Abo-Ersatz bezieht sich linkedPurchaseToken auf das Kauf-Token des alten Abos. In diesem Szenario wäre das basic_purchase_token_123.Beispiel für eine GET purchases.subscriptionsV2-Antwort

  curl \
  'https://androidpublisher.googleapis.com/androidpublisher/v3/applications/<application_id>/purchases/subscriptionsv2/tokens/premium_purchase_token_123' \
  --header 'Authorization: Bearer [YOUR_ACCESS_TOKEN]' \
  --header 'Accept: application/json'
  
  {
    "kind": "androidpublisher#subscriptionPurchaseV2",
    "startTime": "...",
    "subscriptionState": "SUBSCRIPTION_STATE_ACTIVE",
    "latestOrderId": "GPA.<order_id>",
    "linkedPurchaseToken": "basic_purchase_token_123", // The purchase token of the subscription that was replaced (Basic Plan in this case)
    "acknowledgementState": "ACKNOWLEDGEMENT_STATE_ACKNOWLEDGED",
    "lineItems": [
      {
        "productId": "premium_plan", // productID of the new subscription (Premium Plan in this case)
        "expiryTime": "....",
        "autoRenewingPlan": {...},
        "offerDetails": {
          "basePlanId": "monthly-auto-renewing" // base plan ID of the new subscription
        },
        "itemReplacement": { // Details about the subscription replacement
          "productId": "subscription_basic", // productID of the old subscription (Basic Plan in this case)
          "replacementMode": "CHARGE_PRORATED_PRICE", // Replacement strategy used for this subscription change
          "basePlanId": "monthly-auto-renewing" // base plan ID of the old subscription 
        },
        "offerPhase": {...}
      }
    ],
    "etag": "<etag_value>"
  }
  

• Sie müssen den neuen Premium-Kauf bestätigen. Dies kann entweder in Ihrer App oder in Ihrem Backend erfolgen. Wenn Sie den Kauf nicht innerhalb von drei Tagen bestätigen, wird er erstattet und die Berechtigung wird widerrufen. Weitere Informationen zum Verarbeiten und Bestätigen von Käufen finden Sie in der Entwicklerdokumentation.

Prüfen Sie immer das Feld linkedPurchaseToken in Ihrem Backend und widerrufen Sie sofort den Zugriff, der mit diesem alten Token verknüpft ist, damit der Nutzer keine doppelten Berechtigungen behält.

Fazit

In diesem Abschnitt wurden die Schritte zum Verarbeiten sofortiger Abo-Ersetzungen sowohl auf dem Client als auch in Ihrem Backend behandelt. Sie haben erfahren, dass das neue Abo bei Google Play als neuer Kauf behandelt wird und ein neues Kauf-Token ausgestellt wird. Auf dem Client musst du diesen neuen Kauf mit PurchasesUpdatedListener verarbeiten und Berechtigungen basierend auf der Antwort von queryPurchasesAsync aktualisieren. Im Backend sollten Sie auf SUBSCRIPTION_PURCHASED-RTDNs für das neue Token warten, die purchases.subscriptionsv2 API verwenden, um die linkedPurchaseToken des alten Abos zu ermitteln, und den Zugriff, der mit dem alten Token verknüpft ist, umgehend widerrufen, während Sie die neue Berechtigung gewähren. Denke daran, den neuen Kauf immer zu bestätigen.

11. DEFERRED-Ersatzgeräte bearbeiten

Im Gegensatz zu Modi für den sofortigen Ersatz wird bei ReplacementMode.DEFERRED die Aboänderung und die Aktualisierung der Berechtigung bis zum Ende des aktuellen Abrechnungszeitraums aufgeschoben. Für die Bearbeitung von verzögerten Ersatzleistungen ist eine spezielle Logik erforderlich, damit Nutzer zum richtigen Zeitpunkt die richtige Berechtigung erhalten.

Beispielszenario

• Der Nutzer hat ein Basic-Monatsabo (product_id basic_plan und purchase_token basic_purchase_token_123), das am 15. April verlängert wird.
• Am 1. April entscheidet sich der Nutzer, über ReplacementMode.DEFERRED zu einem Premium-Abo zu wechseln.
• Google erstellt sofort ein NEUES Kauf-Token für das Premium-Abo (product_id premium_plan und purchase_token premium_purchase_123), der Betrag, der dem Nutzer in Rechnung gestellt wird, und die Berechtigung werden jedoch erst am 15. April ausgeführt.

Aufgeschobenen Austausch bearbeiten

1. Unmittelbar nach Abschluss des Kaufvorgangs (App)

• PurchasesUpdatedListener wird nach Abschluss des Kaufvorgangs aufgerufen. Die App erhält ein Purchase-Objekt mit dem neuen Kauf-Token premium_purchase_token_123. Die product_id verweist jedoch weiterhin auf das alte basic_plan, da der Nutzer nur Anspruch auf den Basistarif hat. Sie müssen dies genau wie einen neuen Kauf behandeln und das Token bestätigen.

  @Override
  public void onPurchasesUpdated(BillingResult billingResult, List<Purchase> purchases) {
      if (billingResult.getResponseCode() == BillingResponseCode.OK && purchases != null) {
          for (Purchase purchase : purchases) {
              // purchase.getPurchaseToken() = premium_purchase_token_123
              // purchase.getProducts() will contain basic_plan
              // Verify and acknowledge the purchase
              handleNewPurchase(purchase);
          }
      }
  }
  

• queryPurchasesAsync gibt den Kauf mit dem neuen Kauf-Token (premium_purchase_token_123) und die zugehörige ursprüngliche Berechtigung (basic_plan) sofort zurück. Sie können sich darauf verlassen, dass dem Nutzer weiterhin die Berechtigung für das Basic-Abo gewährt wird.

2. Unmittelbar nach dem erfolgreichen Kaufvorgang (Backend)

• Die RTDN SUBSCRIPTION_PURCHASED wird sofort nach dem Kaufvorgang für das neue Kauf-Token (premium_purchase_token_123) gesendet.Beispiel für RTDN-Payload

  {
    "version":"1.0",
    "packageName":"com.google.play.billing.samples.subscriptions",
    "eventTimeMillis":"...",
    "subscriptionNotification":
    {
      "version":"1.0",
      "notificationType":4, // SUBSCRIPTION_PURCHASED
      "purchaseToken":"premium_purchase_token_123" //purchase token for the new subscription
    }
  }
  

• Rufen Sie GET purchases.subscriptionsv2 mit dem neuen Kauf-Token auf, um die Kaufdetails abzurufen. Die Antwort enthält zwei Positionen.
  • Eines für das alte Abo (Basis-Abo) mit einem expiryTime in der Zukunft. Das alte Abo wird nicht verlängert und hat eine deferredItemReplacement mit dem neuen Abo (Premium-Abo). Dies weist auf einen bevorstehenden Ersatz des alten Anspruchs nach Ablauf hin.
  • Eines für das neu gekaufte Abo. Für „expiryTime“ ist kein Wert festgelegt.
  Beispiel für eine API-Antwort

  {
    "kind": "androidpublisher#subscriptionPurchaseV2",
    "startTime": "2026-05-07T15:50:11.383Z",
    "subscriptionState": "SUBSCRIPTION_STATE_ACTIVE",
    "latestOrderId": "GPA.<order_id>",
    "linkedPurchaseToken": "basic_purchase_token_123",
    "acknowledgementState": "ACKNOWLEDGEMENT_STATE_ACKNOWLEDGED",
    "lineItems": [
      {
        "productId": "premium_plan", // Premium Plan has no expiry time
        "autoRenewingPlan": {...},
        "offerDetails": {...},
        "itemReplacement": {. // Subscription replacement details
          "productId": "basic_plan",
          "replacementMode": "DEFERRED",
          "basePlanId": "monthly-auto-renewing"
        },
        "offerPhase": {}
      },
      {
        "productId": "basic_plan", // Subscription to be replaced
        "expiryTime": "2026-05-07T15:54:34.768Z", // Expiry time in the future
        "autoRenewingPlan": {},
        "offerDetails": {...},
        "deferredItemReplacement": { // identifier indicating this subscription will be replaced upon renewal
          "productId": "subscription_premium"
        },
        "latestSuccessfulOrderId": "GPA.<order_id>",
        "itemReplacement": {...},
      }
    ],
    "etag": "<etag>"
  }
  

• Sie müssen das neue Kauf-Token bestätigen. Dies kann entweder in Ihrer App oder in Ihrem Backend erfolgen. Weitere Informationen zum Verarbeiten und Bestätigen von Käufen finden Sie in der Entwicklerdokumentation.
• SUBSCRIPTION_EXPIRED-RTDN wird für das alte Kauf-Token (basic_purchase_token_123) gesendet.Beispiel für eine RTDN-Nutzlast

  {
    "version":"1.0",
    "packageName":"com.google.play.billing.samples.subscriptions",
    "eventTimeMillis":"...",
    "subscriptionNotification":
    {
      "version":"1.0",
      "notificationType":13, // SUBSCRIPTION_EXPIRED
      "purchaseToken":"basic_purchase_token_123" //purchase token for the old subscription
    }
  }
  

• Wenn Sie die GET purchases.subscriptionsv2 API mit dem alten Kauf-Token aufrufen, wird sie als abgelaufen (SUBSCRIPTION_STATE_EXPIRED) angezeigt. Die Berechtigung für das alte Abo wird für die verbleibende Zeit auf den neuen Kauf übertragen.

3. Am Ersatzdatum – erste Verlängerung nach dem Kaufvorgang (App)

• queryPurchasesAsync gibt den Kauf mit dem neuen Kauf-Token (premium_purchase_token_123) und das zugehörige neue Abo (premium_plan) zurück.
• Der neue Kauf sollte bereits verarbeitet worden sein, als der Kaufvorgang erfolgreich abgeschlossen wurde. Sie müssen keine besonderen Maßnahmen ergreifen, außer dafür zu sorgen, dass der Nutzer Zugriff auf das richtige Abo erhält.

4. Am Ersatzdatum – erste Verlängerung nach dem Kaufvorgang (Backend)

• Bei ReplacementMode.DEFERRED folgen erste Verlängerungen dem Standardverhalten jeder anderen Verlängerung, bei der SUBSCRIPTION_RENEWED RTDNs verarbeitet werden. In diesem Fall ist keine spezielle Logik für Ersatz erforderlich.
• Rufen Sie GET purchases.subscriptionsv2 mit dem neuen Kauf-Token auf, um die Kaufdetails abzurufen. Die Antwort enthält zwei Positionen.
  • Eines für das alte Abo (Basis-Abo) mit einem expiryTime in der Vergangenheit. Für das alte Abo ist kein Wert mehr für das Feld deferredItemReplacement festgelegt.
  • Eines für das neue Abo mit einem expiryTime in der Zukunft und dem Feld autoRenewEnabled auf true gesetzt.
  Beispiel für eine API-Antwort

  {
    "kind": "androidpublisher#subscriptionPurchaseV2",
    "subscriptionState": "SUBSCRIPTION_STATE_ACTIVE",
    "latestOrderId": "GPA.<order_id>..0",
    "linkedPurchaseToken": "basic_purchase_token_123", // purchase token of the old subscription
    "acknowledgementState": "ACKNOWLEDGEMENT_STATE_ACKNOWLEDGED",
    "lineItems": [
      {
        "productId": "premium_plan", // New subscription
        "expiryTime": "2026-05-07T16:00:09.437Z", // Expiry time set in the future
        "autoRenewingPlan": {
          "autoRenewEnabled": true, // Auto Renewing Flag set to True
          "recurringPrice": {...}
        },
        "offerDetails": {...},
        "latestSuccessfulOrderId": "GPA.<order_id>..0",
        "itemReplacement": {. // Details of the subscription replacement
          "productId": "basic_plan",
          "replacementMode": "DEFERRED",
          "basePlanId": "monthly-auto-renewing"
        },
        "offerPhase": {...}
      },
      {
        "productId": "basic_plan", // Old subscription, Does not contains the deferredItemReplacement field
        "expiryTime": "2026-05-07T15:54:34.768Z", // Expiry time set in the past
        "autoRenewingPlan": {},
        "offerDetails": {...},
        "latestSuccessfulOrderId": "GPA.<order_id>..0",
        "itemReplacement": {...},
      }
    ],
    "etag": "<etag>"
  }
  

Fazit

In diesem Abschnitt wird die spezielle Verarbeitung beschrieben, die für ReplacementMode.DEFERRED erforderlich ist. Im Gegensatz zu sofortigen Modi erfolgt die Berechtigungsänderung erst am Ende des aktuellen Abrechnungszeitraums. In diesem Abschnitt wurden die erforderlichen Schritte für Ihre App und Ihr Backend beschrieben, um den Erstkauf korrekt zu verarbeiten, das neue Token zu bestätigen und den Berechtigungswechsel zu verwalten, wenn das alte Abo abläuft und das neue aktiviert wird.

12. Playground für Aboersatz

Mit der Funktion Replacement Playground in der Beispiel-App können Sie Abo-Upgrades und ‑Downgrades für die Aboprodukte testen, die in Ihrem Google Play Console-Konto konfiguriert sind. In diesem Abschnitt wird beschrieben, wie Sie das Replacement Playground-Feature verwenden.

Einrichtung

Damit Sie die Funktion Replacement Playground nutzen können, müssen folgende Voraussetzungen erfüllt sein:

• Die packageId in Ihrer build.gradle-Datei stimmt mit der in der Google Play Console konfigurierten Anwendung überein.
• Ihr Testnutzerkonto ist in der Google Play Console als Lizenztester registriert. Weitere Informationen zu Lizenztests finden Sie unter Abrechnungsimplementierung Ihrer App testen.

Playground für Aboersatz

Die Beispiel-App enthält den Tab Replacement Playground (Ersatz-Playground), auf dem Sie Aboänderungen simulieren können. Sie können Abos abfragen, die in Ihrer Play Console definiert sind, und das Wechseln zwischen ihnen mit verschiedenen Ersatzmodi testen. In dieser Playground-Umgebung können Sie nachvollziehen, wie sich verschiedene Modi auf Abrechnungszeiträume und Berechtigungen für Ihre Abos auswirken. So können Sie die Optionen auswählen, die am besten zu Ihren Geschäftsanforderungen passen.

So simulieren Sie Ersetzungen mit dem Playground:

1. Rufen Sie den Tab Playground auf.
2. Wenn Sie ein aktives Abo haben, wird es hervorgehoben. Dieses Abo wird ersetzt.

3. Wenn Sie kein aktives Abo haben, müssen Sie zuerst eines kaufen.
   • Im Playground werden standardmäßig die Abos Basic, Premium und Lite aufgeführt, die für dieses Codelab erstellt wurden.
   • Wenn Sie andere in der Play Console konfigurierte Pläne testen möchten, klicken Sie auf Benutzerdefinierten Plan hinzufügen und suchen Sie nach productId und basePlanId.
   • Kaufen Sie das ausgewählte Abo.
   • Das neu gekaufte aktive Abo des Nutzers sollte jetzt angezeigt werden.
4. Wählen Sie das Zielabo aus, zu dem der Nutzer wechseln möchte.
5. Wählen Sie einen Replacement Mode (Ersetzungsmodus) für den Übergang aus.

6. Klicken Sie auf den Button Ersatz testen, um den Abo-Ersatz zu simulieren.
7. Die Google Play Billing-Ansicht am unteren Rand mit den berechneten Details zum Abo-Ersatz (z. B. sofortige Gebühren und Anpassungen des Abrechnungszeitraums) wird angezeigt.

8. Schließe die Transaktion ab.
9. Rufen Sie in der Google Play Store App die Seite Abos verwalten auf, um die Änderungen am aktiven Abo sowie die aktualisierten Verlängerungsdaten und Preise zu sehen.

13. Nächste Schritte

• Weitere Informationen
• Denken Sie daran, die Best Practices für die Bestätigung und Verarbeitung von Käufen in Ihrem sicheren Backend zu befolgen, sobald Nutzer diese Produkte kaufen.

Referenzdokumente

• Referenz zum Lebenszyklus von Abos
• Referenz für die Modi zum Ersetzen von Abos
• BillingClient API-Referenz
• Entwicklerbenachrichtigungen in Echtzeit (Real-Time Developer Notifications, RTDN)

14. Glückwunsch

Glückwunsch! Sie haben Abo-Ersetzungen mit verschiedenen Abrechnungsmodi erfolgreich implementiert und die Backend-Verarbeitung für Planwechsel konfiguriert.

Das haben Sie gelernt

• SubscriptionProductReplacementParams mit bestimmten Ersetzungsmodi konfigurieren
• Der Unterschied zwischen sofortigen Upgrades und verzögerten Downgrades.
• So werden alte Abo-Tokens mit linkedPurchaseToken mithilfe von RTDNs eingestellt.

Umfrage

Ihr Feedback zu diesem Codelab ist uns sehr wichtig. Nehmen Sie sich einige Minuten Zeit, um an unserer Umfrage teilzunehmen.

AN UMFRAGE TEILNEHMEN