Abo mit Add-ons

Mit einem Abo mit Add-ons können Sie mehrere Aboprodukte bündeln, die gemeinsam gekauft, abgerechnet und verwaltet werden können. Ihre vorhandenen Produktkatalogabos können nahtlos als Add-ons angeboten werden, ohne dass Sie sie vorab angeben oder zusätzlich konfigurieren müssen. Du kannst einen Kaufvorgang mit mehreren bestehenden Aboprodukten starten und sie als Add-ons verkaufen.

Wissenswertes

Beachten Sie bei der Verwendung des Abos mit Add-ons Folgendes:

  • Abos mit Add-ons werden nur für Basis-Abos mit automatischer Verlängerung unterstützt.

  • Alle Artikel im Kauf müssen denselben Abrechnungszeitraum haben. So ist es beispielsweise nicht möglich, ein jährlich abgerechnetes Abo mit monatlich abgerechneten Add-ons zu haben.

  • Ein Abo mit Add-ons kann maximal 50 Artikel umfassen.

  • Diese Funktion ist in Indien (IN) und Südkorea (KR) nicht verfügbar.

Play Billing Library einbinden

In diesem Abschnitt wird beschrieben, wie Sie die Funktion „Abos mit Add-ons“ in die Play Billing Library (PBL) einbinden. Es wird davon ausgegangen, dass Sie mit den ersten Schritten zur PBL-Integration vertraut sind, z. B. mit dem Hinzufügen der PBL-Abhängigkeit zu Ihrer App, dem Initialisieren des BillingClient und dem Herstellen einer Verbindung zu Google Play. In diesem Abschnitt geht es um Aspekte der PBL-Integration, die speziell für Abos mit Add-ons gelten.

Kaufvorgang starten

So startest du den Kaufvorgang für ein Abo mit Add-ons:

  1. Mit der Methode BillingClient.queryProductDetailsAsync kannst du alle deine Aboartikel abrufen.

  2. Legen Sie für jeden Artikel das ProductDetailsParams-Objekt fest.

    Das vom Objekt ProductDetailsParams dargestellte Element gibt sowohl das ProductDetails für das Aboelement als auch ein offerToken für die Auswahl eines bestimmten Abos base plan oder offer an.

  3. Geben Sie die Artikeldetails in der Methode BillingFlowParams.Builder.setProductDetailsParamsList an. Die Klasse BillingFlowParams gibt die Details eines Kaufvorgangs an.

    Im folgenden Beispiel wird gezeigt, wie der Abrechnungsvorgang für einen Abokauf mit mehreren Artikeln gestartet wird:

    Java

       BillingClient billingClient = ;
    
        // ProductDetails obtained from queryProductDetailsAsync().
        ProductDetailsParams productDetails1 = ...;
        ProductDetailsParams productDetails2 = ...;
        ArrayList productDetailsList = new ArrayList<>();
        productDetailsList.add(productDetails1);
        productDetailsList.add(productDetails2);
    
        BillingFlowParams billingFlowParams =
            BillingFlowParams.newBuilder()
               .setProductDetailsParamsList(productDetailsList)
               .build();
        billingClient.launchBillingFlow(billingFlowParams);

Für die Artikel im Kauf anwendbare Regeln

  • Damit die Verlängerungstermine für Add-ons mit denen des Hauptartikels übereinstimmen, kann Google Play nach einer Test- oder Einführungsphase eine anteilige Gebühr einfügen.
  • Die Teilnahmevoraussetzungen werden für jeden Artikel separat geprüft.

Käufe abwickeln

Die Verarbeitung von Abos mit Add-ons entspricht der Verarbeitung von Käufen einzelner Artikel, wie unter Google Play Billing Library in Ihre App integrieren beschrieben. Der einzige Unterschied besteht darin, dass der Nutzer mit einem einzigen Kauf mehrere Berechtigungen erhalten kann. Beim Kauf eines Abos mit Add-ons werden mehrere Artikel zurückgegeben, die über Purchase.getProducts() in der Google Play Billing Library und dann über die lineItems-Liste in purchases.subscriptionsv2.get der Google Play Developer API abgerufen werden können.

Abos mit Add-ons ändern

Alle Änderungen an Ihrem Abo mit Add-ons führen zu einem Upgrade oder Downgrade. Weitere Informationen finden Sie unter Abos upgraden oder downgraden.

Wenn Sie einen bestehenden Kauf eines Abos mit Add-ons in Ihrer App ändern oder wiederherstellen möchten, müssen Sie die launchBillingFlow API mit zusätzlichen Parametern aufrufen und Folgendes beachten:

  • Rufe setOldPurchaseToken immer mit dem Kauftoken des aktuellen Abokaufs auf.
  • Wenn du das Basiselement upgraden, downgraden oder kreuzstufen möchtest, rufe setSubscriptionReplacementMode auf, um anzugeben, wie die Tarifänderung zwischen den Basiselementen des alten und dem neuen Kauf des Abos mit Add-ons erfolgen soll. Andernfalls muss dieser Parameter nicht festgelegt werden.
  • Wenn sich das Basiselement nicht ändert, kannst du trotzdem setSubscriptionReplacementMode aufrufen, um ein bestimmtes Aufteilungsverhalten anzuwenden. Die in diesem Fall geltenden Regeln findest du unter Abo wieder aktivieren oder innerhalb desselben Abos zu einem anderen Tarif wechseln.
  • Neue Add-ons werden sofort mit einer anteiligen Gebühr angewendet, damit das nächste Verlängerungsdatum mit dem Basiselement im Abo übereinstimmt.
  • Entfernte Add-ons laufen am Ende des aktuellen Abrechnungszeitraums ab.
  • Wenn du den Abrechnungsvorgang startest, musst du alle aktiven Artikel im Abo mit Add-ons angeben, mit Ausnahme der zu entfernenden, sowie alle neuen Add-ons.

Im folgenden Beispiel wird gezeigt, wie die launchBillingFlow API aufgerufen wird, wenn ein bestehender Kauf eines Abos mit Add-ons geändert werden soll:

Java

BillingClient billingClient = ;

int replacementMode =;

// ProductDetails obtained from queryProductDetailsAsync().
ProductDetailsParams productDetails1 = ...;
ProductDetailsParams productDetails2 = ...;
ProductDetailsParams productDetails3 = ...;

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

BillingFlowParams billingFlowParams =
    BillingFlowParams.newBuilder()
        .setSubscriptionUpdateParams(
          SubscriptionUpdateParams.newBuilder()
              .setOldPurchaseToken(purchaseTokenOfExistingSubscription)
              // No need to set if change does not affect the base item.
             .setSubscriptionReplacementMode(replacementMode)
             .build())
        .setProductDetailsParamsList(productDetailsList)
        .build();

billingClient.launchBillingFlow(billingFlowParams);

Szenarien für die Änderung von Abos

In der folgenden Tabelle sind die verschiedenen Änderungsszenarien für Abos mit Add-ons und das entsprechende Verhalten aufgeführt.

Vorhandene Elemente Geänderte Elemente Müssen Sie den Ersatzmodus festlegen? Verhalten
A (Basiselement), B A (Basiselement) Nein Artikel B wird verzögert entfernt.
A A (Basiselement), B Nein Artikel B wird sofort mit einer anteiligen Gebühr hinzugefügt.
A (Basiselement), B A (Basiselement), C Nein
  • B wird verzögert entfernt.
  • C wird sofort mit einer anteiligen Gebühr hinzugefügt.
A (Basiselement), B B (Basisartikel) Nein A wird verzögert entfernt.
A (Basiselement), B C (Basisartikel) Ja
A (Basiselement), B C (Basiselement), B Ja Der Ersatz für A -> C hängt von setSubscriptionReplacementMode ab.
A (Basiselement), B C (Basisartikel), D Ja
  • Der Ersatz für A -> C hängt von setSubscriptionReplacementMode ab.
  • B wird verzögert entfernt.
  • D wird sofort mit einer anteiligen Gebühr hinzugefügt.

Entwicklerbenachrichtigungen in Echtzeit

Das Feld subscriptionId ist in RTDN für den Kauf von Abos mit Add-ons, die Berechtigungen für mehrere Artikel enthalten, nicht enthalten. Stattdessen können Sie die Play Developer APIs verwenden, um den Kauf abzurufen und die zugehörigen Artikelberechtigungen aufzurufen.

Preisänderungen für bestehende Abonnenten

Das Ändern von Abopreisen für bestehende Abonnenten eines Abos mit Add-ons ähnelt dem Ändern von Abopreisen für Abos mit einzelnen Artikeln, wie unter Abopreise ändern beschrieben. Es gibt jedoch einige Einschränkungen und funktionale Unterschiede, die in diesem Abschnitt beschrieben werden.

Alte Preiskohorte beenden

Die Auflösung einer alten Kohorte wirkt sich auch auf Abos mit Add-on-Käufen aus. Es gelten die folgenden Regeln:

  • Alle ausstehenden Preiserhöhungen mit Opt-in sollten denselben Verlängerungszeitraum wie der neue Preis haben. Wenn für einen Artikel in einem Abo mit Add-ons eine Preiserhöhung unter Widerrufsvorbehalt gilt, die noch nicht vom Nutzer bestätigt wurde, wird jede neue Preiserhöhung unter Widerrufsvorbehalt für andere Artikel im Kauf ignoriert, es sei denn, sie führt zu derselben Verlängerungszeit des neuen Preises wie die vorhandene Preiserhöhung im Status AUSSTEHEND. Sobald der Nutzer die Preiserhöhung bestätigt hat, werden alle neuen Preisänderungen registriert. Außerdem können Nutzer alle nicht bestätigten Opt-in-Preiserhöhungen nur gleichzeitig akzeptieren.

    Beispiel:

    • Angenommen, Sie haben ein Abo mit Add-ons (Artikel A und B), das sich jeden 7. des Monats verlängert.
    • Für Artikel A ist eine Preismigration von 7 € auf 10 € in Bearbeitung. Die Preiserhöhung wird voraussichtlich am 7. Juli wirksam.
    • Für Artikel B beginnt am 2. Juni eine Preisumstellung von 5 € auf 6 €. Da die Preiserhöhung mit Opt-in 37 Tage nach der Migration beginnt, erfolgt die früheste Preiserhöhung für Artikel B am 7. August.

    In diesem Szenario wird die Preisänderung für Artikel B für diesen Abokauf erst registriert, wenn der Nutzer die Preisänderung für Artikel A akzeptiert hat (d. h., wenn der Status CONFIRMED ist). SubscriptionPurchaseV2 gibt dann keine Details zur Preisänderung für Artikel B zurück. Nachdem der Nutzer die Preisänderung für Artikel A bestätigt hat, beginnt die Preisänderung für Artikel B. Der Nutzer erhält die Opt-in-Preiserhöhung für Artikel B erst, nachdem er die Opt-in-Preiserhöhung für Artikel A akzeptiert hat.

  • Die E-Mail von Google Play enthält eine Liste aller Artikel, deren Preise am selben Tag steigen oder sinken.

Abo mit Add-ons kündigen

Nutzer können den gesamten Kauf eines Abos mit Add-ons im Play-Abocenter stornieren. Sie können den gesamten Kauf eines Abos mit Add-ons nur über die Google Play Developer API stornieren.

Wenn ein Abokauf gekündigt, aber nicht widerrufen wird, werden keine der im Kauf enthaltenen Artikel automatisch verlängert. Der Nutzer hat jedoch weiterhin Zugriff auf die entsprechenden Artikel, bis die entsprechenden Abrechnungszeiträume enden.

Abos mit Add-ons widerrufen und erstatten

Im Folgenden finden Sie einige Richtlinien für den Widerruf und die Erstattung von Abos:

  • Verwenden Sie die Play Console, um eine betragsbasierte Erstattung für eine bestimmte Bestellung zu veranlassen, ohne den Zugriff auf das Abo aufzuheben.

  • Rufe orders.refund an, um bestimmte Abozahlungen des Nutzers vollständig zu erstatten, ohne den Zugriff auf das Abo aufzuheben.

  • Drücke die Taste purchases.subscriptionsv2.revoke, um den Zugriff auf alle Aboelemente sofort zu widerrufen. Mit dieser API haben Sie folgende Möglichkeiten:

    • Widerrufen Sie den Zugriff auf alle Artikel und gewähren Sie eine anteilige Erstattung.

    • Wenn Sie ein Abo mit Add-ons mit anteiligen Erstattungen widerrufen, erhalten Sie für die letzte Bestellung jedes Artikels eine anteilige Erstattung, die auf der verbleibenden Zeit bis zur nächsten Verlängerung basiert.

    • Widerrufe den Zugriff für alle Artikel und gib eine FullRefund aus.

    • Widerrufe den Zugriff auf einen einzelnen Artikel und erstatte den Kaufpreis zurück.

Einzelnes Element in einem Abo mit Add-ons widerrufen

Wenn du einzelne Aboartikel in einem Abo mit Add-ons widerrufen möchtest, ohne den gesamten Kauf zu widerrufen, ruf purchases.subscriptionsv2.revoke mit dem Feld ItemBasedRefund in RevocationContext auf. Die productId des Artikels, der widerrufen und erstattet werden soll, kann im Feld ItemBasedRefund festgelegt werden.

Das Feld ItemBasedRefund kann für Käufe mit einem oder mehreren automatisch verlängerbaren Aboelementen festgelegt werden.

  • Wenn nach dem Widerruf des in ItemBasedRefund angegebenen Artikels noch aktive Artikel im Abokauf vorhanden sind, wird nur der Artikel widerrufen und vollständig erstattet, ohne den Abostatus zu unterbrechen.
  • Wenn nach dem Widerruf des in ItemBasedRefund angegebenen Artikels keine aktiven Artikel mehr im Abokauf vorhanden sind, wird der Artikel widerrufen, vollständig erstattet und das Abo gekündigt.

Wissenswertes

  • Bei Verwendung des ItemBasedRefund kann jeweils nur ein Element widerrufen werden. Die Anfrage kann mehrmals aufgerufen werden, wenn verschiedene Elemente widerrufen werden müssen.
  • Wenn der Kauf des Abos einen der Status „Zahlung abgelehnt“ hat oder der in ItemBasedRefund angegebene Artikel nicht zum Nutzer gehört oder abgelaufen ist, wird die Ablehnung des Artikels blockiert.
  • Die Ablehnung von Artikeln wird bei Prepaid-Abos nicht unterstützt.

Ablauf des Artikels bei Zahlungsablehnung

Bei einem Kauf eines Abos mit Add-ons müssen bei bestimmten Verlängerungen möglicherweise nur einige Artikelberechtigungen verlängert werden, ohne dass sich dies auf Artikel mit einem zukünftigen Ablaufdatum auswirkt.

Unabhängig davon, welche Artikel bei einer Verlängerung beteiligt sind, tritt bei Ablehnung der Verlängerungszahlung ein Kulanzzeitraum und eine Kontosperre in Kraft, wie in der folgenden Dokumentation beschrieben.

Auswahl des Wiederherstellungszeitraums

Da der Kulanzzeitraum dem Nutzer weiterhin die Berechtigung gewährt, wird beim Kauf eines Abos mit Add-ons die Verlängerungszahlung abgelehnt. Das Element mit dem kürzesten Kulanzzeitraum aller aktiven Elemente wird ausgewählt und sein Kulanzzeitraum und die Kontosperre werden als Wiederherstellungszeitraum für diese Verlängerung angewendet.

Zu den aktiven Artikeln gehören Artikel, die beim Kauf eines Abos mit Add-ons kurz vor dem Verlängerungsversuch aktiv waren. Neu hinzugefügte Artikel (für die erst nach der Wiederherstellung ein Anspruch besteht) und Artikel, die aufgrund von Entfernung oder Ablehnung nicht mehr aktiv sind, sind davon ausgenommen.

Die Einstellung für die Kontosperre des Artikels mit der ausgewählten Mindestkulanzzeit wird angewendet. Wenn es mehrere Elemente mit der Mindestkulanzzeit, aber unterschiedlichen Kontosperrungszeiten gibt, wird die längste Kontosperrungszeit angewendet.

Kulanzzeitraum

Wenn die Zahlung für die Verlängerung eines Abos abgelehnt wird, wird der Kauf des Abos in den Kulanzzeitraum versetzt. Während des Kulanzzeitraums hat der Nutzer weiterhin Zugriff auf alle aktiven Elemente aus dem vorherigen Verlängerungszeitraum. Wenn die Zahlungsmethode nach Ablauf des Kulanzzeitraums nicht korrigiert wurde, wird der gesamte Abokauf auf Kontosperre gesetzt. Wenn andere Artikel während des Kulanzzeitraums ihr Verlängerungsdatum erreichen, wird für diese Artikel ein neuer Abbuchungsversuch gestartet, sobald das Abo wieder aktiviert wurde.

Kontosperre

Solange der Kauf des Abos aufgrund einer Kontosperre ausgesetzt ist, ist der Zugriff auf alle Aboartikel gesperrt, bis die Zahlung wiederhergestellt ist.

Wenn das Abo in der Kontosperre reaktiviert wird, bleibt der Abokauf unverändert bestehen. Wenn das Abo nicht reaktiviert wird, laufen die Artikel mit abgelehnter Zahlung ab und der Zugriff auf die anderen Artikel wird für den Rest der Abrechnungszeiträume wiederhergestellt.

Beispiel:

  • Ein Nutzer hat ein Abo Mein Basistarif, das jeden Monat am 1. des Monats verlängert wird. Am 15. August fügt er ein Add-on-Abo mit einer siebentägigen kostenlosen Testversion hinzu, das 10 $/Monat kostet. Für keines der Elemente ist ein Kulanzzeitraum festgelegt. Beide Elemente haben eine Kontosperre von 30 Tagen.

  • Am 22. August werden dem Nutzer 2,90 $ (10*9 ÷ 31) für die anteilige Abrechnung bis zum 31. August in Rechnung gestellt. Die Zahlungsmethode des Nutzers läuft jedoch vorher ab und das Abo wird am 22. August wegen Zahlungsausfall storniert.

Wenn das Abo aufgrund einer abgelehnten Zahlung in eine Kontosperre gerät, hat der Nutzer keinen Zugriff auf die Elemente im Abo mit Add-ons. Die verbleibende Zeit für die nicht verlängerten Artikel wird den Nutzern zurückgegeben, sobald die Kontosperre für das Abo aufgehoben wird, entweder weil die Zahlung wiederhergestellt oder storniert wurde.

Im vorherigen Beispiel wird ein Abo am 22. August in den Konto-Hold versetzt.

  • Wenn das Konto am 25. August wiederhergestellt wird, also vor dem allgemeinen Verlängerungsdatum am 1. September, erhält der Nutzer noch am selben Tag wieder Zugriff auf Mein Base Plan und Add-on-Plan. Das nächste Abrechnungsdatum wurde auf den 4. September geändert.

  • Wenn das Konto nach 30 Tagen nicht wiederhergestellt wurde, wird das Abo am 21. September gekündigt. Der Nutzer verliert den Zugriff auf das Add-on-Abo und hat bis zum 30. September wieder Zugriff auf sein Basisabo.

In diesem Beispiel musst du die aktualisierte expiryTime für ALLE Artikel im Abo mit Add-ons abrufen, da die Berechtigung für einige Artikel nach Ablauf der Kulanzzeitraums und der Kontosperre wiederhergestellt werden kann.

Finanzberichte und Abgleich

Im Bericht zu Einnahmen können Sie Ihre aktiven Abos mit Transaktionen bei Google Play abgleichen. Jede Transaktionsbuchung hat eine Auftrags-ID. Bei Käufen, die mehrere Artikel umfassen, enthalten die Berichte „Einnahmen“ und „Geschätzte Verkäufe“ separate Zeilen für jede Transaktion, z. B. für Belastungen, Gebühren, Steuern und Erstattungen für jeden beteiligten Artikel.

Für Dashboards in der Play Console:

  • Die Umsatzstatistiken im Bereich Finanzberichte der Play Console sind nach Artikeln aufgeschlüsselt.

  • In der Bestellverwaltung wird der Kauf eines Abos mit Add-ons berücksichtigt und es werden detaillierte Listen der gekauften Artikel angezeigt. Über die Bestellverwaltung können Sie den Kauf eines Nutzers widerrufen, stornieren oder vollständig erstatten.