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 wie das Anbieten von Werbeaktionen und die Möglichkeit für Nutzer, ihre eigenen Abos zu verwalten, beschrieben.

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 umfassen eine Reihe von Vorteilen, auf die Nutzer innerhalb eines bestimmten Zeitraums zugreifen können. Ein Abo kann beispielsweise einem Nutzer Premiumzugriff gewähren.

Mit Basis-Abos und Angeboten können Sie mehrere Konfigurationen für dasselbe Aboprodukt 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. z. B. 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 Guthaben für ein Prepaid-Abo desselben Abos 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 Ersatzmodus CHARGE_FULL_PRICE verwendet. Sie müssen diesen Modus nicht explizit festlegen. Dem Nutzer wird sofort ein ganzer 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:

• Auftrags-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 Erstkauf als auch alle Aufladungen müssen bestätigt werden. Weitere Informationen finden Sie unter Käufe verarbeiten.

Aufgrund der potenziell kurzen Laufzeiten von Prepaid-Abos ist es wichtig, den Kauf so schnell wie möglich zu bestätigen.

Prepaid-Tarife 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 dreitägigen Prepaid-Tarif 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 Ratenabo festlegen, entspricht der Preis dem monatlichen Zahlungsbetrag. In Kombination mit dem festgelegten Zusicherungszeitraum ergibt sich so der Gesamtbetrag für das Abo auf dem Kaufbildschirm.
• 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 einer Zusicherungsfrist, entweder der ursprünglichen oder einer nachfolgenden. Nach der ersten Registrierung erfolgt die erste Verlängerung nach Ablauf der 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 nachfolgende Zusicherung und der Tarif verhält sich wie ein Monatsabo, bei dem jede monatliche Abogebühr eine Verlängerung darstellt.
• Abrechnungszeitraum: Bei Abos mit Ratenzahlung bezieht sich dieser Begriff auf das wiederkehrende Intervall, in dem einzelne Zahlungen erfolgen, wie im Basis-Tarif 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: 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 die Inhalte 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, versuchen weder Google noch der Entwickler, 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-Abocenter 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, erneutes Abo und Pausieren 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 ermöglichen, ihren aktuellen Abrechnungszeitraum zu ändern, z. B. von einem Monats- zu einem Jahresabo 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, und dieses Angebot auf Nutzer beschränken, die ein Monatsabo haben und dieses Angebot noch nicht gekauft haben. Weitere Informationen zu den Teilnahmevoraussetzungen für Angebote finden Sie in der 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 Nutzern klar 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 Ersatzmodi, Beispiele für die Verwendung 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 sich nach einer Kündigung neu anmelden. 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 von 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 Tarifwechsel automatisch vom alten zum neuen Kauf.

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, wenn Sie SubscriptionUpdateParams als Teil der Konfiguration des Kaufvorgangs für die Laufzeit angeben:

• Wenn Sie ein Upgrade oder Downgrade durchführen oder ein Abo in einen Prepaid-Tarif umwandeln, der entweder ein Prepaid-Tarif, ein sich automatisch verlängernder Tarif oder ein Ratenzahlungstarif ist, ist nur der Ersatzmodus CHARGE_FULL_PRICE zulässig. Wenn Sie einen anderen Ersatzmodus angeben, schlägt der Kauf fehl und dem Nutzer wird eine Fehlermeldung angezeigt.
• Beim Wechsel des Tarifs innerhalb desselben Abos zu einem sich automatisch verlängernden Tarif von 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.

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 der Country Gardener App. Er hat ein monatliches Abo für die Tier 1-Version der Inhalte, die nur Text enthält. Dieses Abo kostet ihn 2$pro Monat und wird am Monatsersten 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. Achte insbesondere darauf, dass du den neuen Kauf bestätigst. Die startTime des neuen Abos wird erst dann ausgefüllt, wenn das alte Abo abläuft und das neue Abo wirksam wird. Zu diesem Zeitpunkt erhalten Sie eine SUBSCRIPTION_RENEWED-RTDN für das neue Abo. ReplacementMode.DEFERRED-Verhalten in Verzögerten Ersatz bearbeiten

CHARGE_FULL_PRICE

Das Tier 1-Abo von Samwise endet sofort. Sein Tier 2-Abo 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.

Wenn Sie einen Abrechnungsmodus auswählen, sollten Sie sich unsere Empfehlungen für den Ersatz ansehen.

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, wie im folgenden Beispiel gezeigt:

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 haben, 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 Berechtigungen in ihrem alten Tarif nutzen, bevor sie mit dem neuen Tarif beginnen.

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. Mit der Play Billing Library 6 wurde ProrationMode.DEFERRED jedoch eingestellt. In der folgenden Tabelle sehen Sie, wo sich das Verhalten unterscheidet:

Ab sofort sollte „ReplacementMode.DEFERRED“ anstelle von „ProrationMode.DEFERRED“ verwendet werden, da es dasselbe Verhalten in Bezug auf Änderungen an Berechtigungen 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 neu abzuschließen.

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 sowie die 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 können 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. ein neues Probeabo oder einen Rabatt für die Rückgewinnung von Kunden, können Sie dem Nutzer stattdessen eine andere SKU 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 zum 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. Dadurch wird der Nutzer auf einen kostenlosen Testzeitraum pro App beschränkt.

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ültig machen Sie das im linkedPurchaseToken bereitgestellte Token, damit 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. Dabei bleiben das Abo- und das Kauf-Token gleich.

Weitere Informationen zum Wiederherstellen von Abos finden Sie unter Wiederherstellungen.

Nach Ablauf des Abos – In-App

Du kannst 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 Sonderpreis für Ihr Abo anbieten, auch Rückgewinnungs-Artikelnummer genannt. Sie können das Angebot in Ihrer App bereitstellen 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 du in deiner Reaktivierungs-SKU einen kostenlosen Testzeitraum oder einen Einführungspreis anbieten möchtest, musst du dafür sorgen, dass der Nutzer die Voraussetzungen erfüllt. Dazu musst du 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 das Abo mit derselben Artikelnummer reaktiviert, hat er keinen Anspruch mehr auf kostenlose Testzeiträume oder Einführungspreise. Achten Sie darauf, dass Ihre Benutzeroberfläche dies widerspiegelt.

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

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 Out-of-App-Kauf. Achten Sie daher darauf, die Best Practices für Käufe außerhalb Ihrer 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 Vorautorisierung oder Abbuchung ist vorübergehend und wird später rückgängig gemacht oder erstattet.

Nach Ablauf des Probeabos 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 dem Nutzer wird 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 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 Abonnements 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:

• Nutzern im Rahmen eines Sonderangebots kostenlosen Zugriff gewähren, z. B. eine Woche kostenlos 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. Der Verlag belohnt sie mit sechs kostenlosen Wochen, indem er die nächste Zahlung auf den 15. Mai verschiebt. Das sind sechs Wochen nach dem ursprünglich geplanten Abrechnungsdatum am 1. April. Darcy werden für April und Anfang Mai keine Kosten berechnet 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 sein 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 Kontosperrung einmal pro Tag Nachrichten in Google Play angezeigt. So haben sie die Möglichkeit, ihre Zahlung zu korrigieren, ohne die App zu verlassen.

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 nach Abschluss der Transaktion aktualisieren.

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, wobei der Status auf PURCHASED aktualisiert wurde. Eine SubscriptionNotification-Nachricht vom 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 initiiert, erhält Ihre App für das alte Abo eine 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.