Abos (About subscriptions)

In diesem Thema wird beschrieben, wie du mit Ereignissen im Abolebenszyklus wie Verlängerungen und Ablaufzeiten umgehen kannst. Außerdem werden zusätzliche Abofunktionen beschrieben, z. B. das Anbieten von Angeboten und die Möglichkeit für Nutzer, ihre eigenen Abos zu verwalten.

Wenn Sie noch keine Aboprodukte für Ihre App konfiguriert haben, lesen Sie den Hilfeartikel Produkte erstellen und konfigurieren.

Aboübersicht

Ein Abo bietet eine Reihe von Vorteilen, auf die Nutzer innerhalb eines bestimmten Zeitraums zugreifen können. Ein Abo kann einem Nutzer beispielsweise den Zugriff auf einen Musik-Streamingdienst gewähren.

Sie können mehrere Abos in einer App anbieten, entweder um verschiedene Vorteile oder verschiedene Stufen eines einzelnen Vorteils zu repräsentieren (z. B. „Silber“ und „Gold“).

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 Ihre App noch nie abonniert haben. Ebenso können Sie ein Upgrade-Angebot für Nutzer erstellen, die bereits ein Abo haben.

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

Einbindung von Prepaid-Tarifen

Prepaid-Tarife werden nach Ablauf nicht automatisch verlängert. Wenn der Nutzer seine Aboberechtigung ohne Unterbrechung verlängern möchte, muss er ein Guthaben für ein Prepaid-Abo für dasselbe Abo aufladen.

Führe für Aufladungen den Abrechnungsvorgang wie beim ursprünglichen Kauf aus. Sie müssen nicht angeben, dass es sich bei einem Kauf um ein Aufladen handelt.

Bei Aufstockungen von Prepaid-Tarifen wird immer der CHARGE_FULL_PRICE-Ersatzmodus verwendet. Sie müssen diesen Modus nicht explizit festlegen. Dem Nutzer wird sofort ein voller Abrechnungszeitraum in Rechnung gestellt und seine Berechtigung wird um die im Aufstockungsbetrag angegebene Dauer verlängert.

Nach einem Aufladen 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 beim ursprünglichen 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 Aufstockungen müssen bestätigt werden. Weitere Informationen finden Sie unter Käufe verarbeiten.

Da die Laufzeit eines Prepaid-Tarifs möglicherweise kurz ist, ist es wichtig, den Kauf so schnell wie möglich zu bestätigen.

Prepaid-Tarife mit einer Laufzeit von mindestens einer Woche müssen innerhalb von drei Tagen bestätigt werden.

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

Integration von Ratenabos

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

Weitere Hinweise zu Abos mit Ratenzahlung:

• Verfügbarkeit nach Land: Die Funktion für Ratenzahlungen ist nur in Brasilien, Frankreich, Italien und Spanien verfügbar. Aktuelle Informationen zur Verfügbarkeit finden Sie in der Console.
• Preis festlegen: Wenn Sie in der Konsole den Preis für ein Ratenabo festlegen, entspricht der Preis dem monatlichen Zahlungsbetrag. In Kombination mit der festgelegten Laufzeit ergibt sich daraus der Gesamtbetrag für das Abo auf dem Kaufbildschirm.
• Mindestlaufzeit: Die Gesamtdauer der anfänglichen Abobindung, während der monatliche Zahlungen erforderlich sind. Wenn ein Basistarif beispielsweise eine Mindestlaufzeit von 15 Monaten hat, leistet der Nutzer in diesem Zeitraum 15 monatliche Zahlungen.
• Verlängerungen: Im Zusammenhang mit Abos mit Ratenzahlung bedeutet „Verlängerung“ den Abschluss einer Bindungsfrist, entweder der ursprünglichen Bindungsfrist oder einer nachfolgenden Bindungsfrist. Nach der Erstregistrierung erfolgt die erste Verlängerung nach Ablauf der gesamten anfänglichen Mindestlaufzeit. Nachfolgende Verlängerungen erfolgen nach Ablauf jeder weiteren Verpflichtungsdauer. Die Verlängerungsarten für Abos mit Ratenzahlung können „Jeden Monat automatisch verlängern“ oder „Für dieselbe Laufzeit automatisch verlängern“ sein. Bei der Option „Automatisch jeden Monat verlängern“ gibt es keine weitere Bindung und der Tarif verhält sich wie ein Monatsabo, bei dem jede monatliche Abogebühr eine Verlängerung darstellt.
• Abrechnungszeitraum: Im Zusammenhang mit Abos mit Ratenzahlung bezieht sich dies auf das wiederkehrende Intervall, in dem die einzelnen Zahlungen erfolgen, wie im Basistarif angegeben.
• Verhalten bei Plan- und 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 also erst zum Ende der Mindestlaufzeit wirksam. Bei Tarifänderungen ist die Bindung nicht festgelegt. Das bedeutet, dass Sie nicht bis zum Ende eines Vertragszeitraums warten müssen, bis die Tarifänderung wirksam wird. Sie tritt je nach festgelegtem Ersatzmodus entweder sofort oder am nächsten Zahlungsdatum in Kraft.
• Änderung des Abos: Eine Änderung des Abos von einem Basis-Abo mit Ratenzahlung zu einem Basis-Abo ohne Ratenzahlung desselben Aboprodukts ist nicht zulässig.

• Entwicklerbenachrichtigungen in Echtzeit (Real-time developer notifications, RTDNs): Eine SUBSCRIPTION_CANCELLATION_SCHEDULED-RTDN wird sofort nach einer vom Nutzer initiierten Kündigung gesendet, wenn für den Bindungszeitraum noch Zahlungen ausstehen. Die Kündigung ist ausstehend und wird erst am Ende der Bindungsfrist wirksam. Wenn die Geräte dann nicht vom Nutzer wiederhergestellt werden, werden am Ende des Bindungszeitraums 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 registriert.

• Einzug ausstehender Zahlungen: Wenn ein Nutzer keine Ratenzahlungen für ein Abo leistet, versuchen weder Google noch der Entwickler, diese ausstehenden Zahlungen vom Nutzer einzuziehen. Google kann jedoch in Übereinstimmung mit seinen üblichen Verfahren für den wiederholten Zahlungsversuch die Zahlung während einer anwendbaren Kulanzzeitraums oder Kontosperre regelmäßig noch einmal versuchen. Google haftet dem Entwickler nicht für ausstehende Ratenzahlungen.

• 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 Abo mit Ratenzahlung über queryProductDetails() zurückgegeben. Das Abo enthält jedoch keine detaillierten Informationen zu Ratenzahlungen wie die Anzahl der zugesagten Zahlungen des Tarifs.

Deeplinks verwenden, damit Nutzer ein Abo verwalten können

Ihre App sollte einen Link auf einem Einstellungsbildschirm enthalten, über den Nutzer ihre Abos verwalten können. Sie können diesen Link in das natürliche Erscheinungsbild Ihrer App einbinden.

Sie können einen Deeplink von Ihrer App zum Google Play-Abocenter für nicht abgelaufene Abos einfügen. Diese können Sie mithilfe des Felds subscriptionState der Aboressource ermitteln. Es gibt mehrere Möglichkeiten, Deeplinks zur Play Store-Aboverwaltung einzufügen.

Link zur Aboverwaltung

Über die folgende URL gelangen Nutzer zur Seite mit allen Abos, wie in Abbildung 1 und 2 dargestellt:

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

Dieser Deeplink kann Nutzern helfen, ein gekündigtes Abo über das Play Store-Abocenter wiederherzustellen.

Link zu einer bestimmten Seite zur Aboverwaltung (empfohlen)

Wenn du einen direkten Link zur Verwaltungsseite für ein Abo herstellen möchtest, das noch nicht abgelaufen ist, gib den Paketnamen und die productId an, die mit dem gekauften Abo verknüpft sind. Wenn du die productId für ein bestehendes Abo programmatisch ermitteln möchtest, kannst du das Backend deiner App abfragen oder BillingClient.queryPurchasesAsync() aufrufen, um eine Liste der Abos abzurufen, die mit einem bestimmten Nutzer verknüpft sind. Jedes Abo enthält die entsprechende productId als Teil der Informationen zum Abostatus. Jedes SubscriptionPurchaseLineItem-Objekt, das mit einem Abokauf verknüpft ist, enthält den productId-Wert, der mit dem Abo verknüpft ist, das der Nutzer in dieser Werbebuchung 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 und 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 zugreifen, z. B. Kündigung, Neuaktivierung und Pausieren.

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 Abostufen anbieten, z. B. „Basis“ und „Premium“, können Sie Nutzern erlauben, die Stufe zu wechseln, indem sie ein anderes Basis-Abo oder Angebot kaufen.
• Sie können Nutzern erlauben, ihren aktuellen Abrechnungszeitraum zu ändern, z. B. von einem Monats- zu einem Jahrestarif.
• 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 Aboangebote mit Rabatten für berechtigte Nutzer anbieten. Sie können beispielsweise ein Angebot erstellen, das einen Rabatt von 50% auf das erste Jahr beim Wechsel von einem Monatstarif zu einem Jahrestarif gewährt. Dieses Angebot können Sie dann auf Nutzer beschränken, die bereits ein Monatsabo haben, dieses Angebot aber noch nicht in Anspruch genommen haben. Weitere Informationen zu den Teilnahmevoraussetzungen für Angebote finden Sie in der YouTube-Hilfe.

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

Ihre App könnte einen Bildschirm ähnlich wie in Abbildung 3 anzeigen, auf dem Nutzer die Möglichkeit haben, ihr Abo zu ändern. In jedem Fall sollte den Nutzern klar sein, welchen aktuellen Abotarif sie haben und welche Optionen sie haben, ihn zu ändern.

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

Ersatzmodi

In der folgenden Tabelle sind die verfügbaren Ersatzmodi und Beispielnutzungen sowie die Anzahl der Zahlungen aufgeführt, die als bezahlt betrachtet werden.

Weitere Informationen zu den verschiedenen Anwendungen von Angeboten für ein Upgrade oder Downgrade zum Zwecke des Upsellings und des Kundengewinnens finden Sie im Leitfaden zu Angeboten und Werbeaktionen.

Ersatzmodus für einen Kauf festlegen

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

Abo wieder aktivieren oder innerhalb desselben Abos Tarif wechseln

Sie können in der Google Play Console einen Standardmodus für den Ersatz angeben. Mit dieser Einstellung kannst du festlegen, wann bestehenden Abonnenten der Betrag in Rechnung gestellt wird, wenn sie ein anderes Basis-Abo abschließen oder ein Angebot für dasselbe Abo in Anspruch nehmen oder nach einer Kündigung wieder ein Abo abschließen. Die verfügbaren Optionen sind Sofort abrechnen, was CHARGE_FULL_PRICE entspricht, und Zum nächsten Rechnungsdatum abrechnen, was WITHOUT_PRORATION entspricht. Dies sind die einzigen relevanten Ersatzmodi beim Wechsel des Basis-Abos innerhalb desselben Abos.

Wenn du beispielsweise ein Angebot zur Kundenrückgewinnung für denselben Tarif implementierst, nachdem der Nutzer gekündigt, aber das Abo noch nicht abgelaufen ist, kannst du den neuen Kauf als regulären Kauf verarbeiten, ohne Werte in SubscriptionUpdateParams anzugeben. Das System verwendet den im Abo konfigurierten Standard-Ersatzmodus und kümmert sich automatisch um die Umstellung des Tarifs vom alten Kauf auf den neuen Kauf.

Abos zwischen Tarifen wechseln oder Standardmodus für Ersatzgeräte überschreiben

Wenn der Nutzer Aboprodukte wechselt, also ein anderes Abo kauft, oder wenn Sie den Standard-Ersatzmodus aus irgendeinem Grund überschreiben möchten, geben Sie die Aufteilungsrate zur Laufzeit als Teil der Parameter für den Kaufvorgang an.

Beachte die folgenden Einschränkungen, damit SubscriptionUpdateParams in der Konfiguration des Kaufvorgangs in der Laufzeit korrekt angegeben wird:

• Wenn du ein Upgrade oder Downgrade ausführst oder einen Wechsel desselben Abos zu einem Prepaid-Tarif von einem Prepaid-Tarif, einem Tarif mit automatischer Verlängerung oder einem Ratenkauftarif ausführst, ist CHARGE_FULL_PRICE der einzige zulässige Ersatzmodus. Wenn Sie einen anderen Ersatzmodus angeben, schlägt der Kauf fehl und dem Nutzer wird eine Fehlermeldung angezeigt.
• Wenn Sie innerhalb desselben Abos von einem Prepaid-Tarif oder einem Tarif mit automatischer Verlängerung zu einem Tarif mit automatischer Verlängerung wechseln, sind CHARGE_FULL_PRICE und WITHOUT_PRORATION gültige Modus für die Aufteilung. Wenn Sie einen anderen Stufenmodellmodus angeben, schlägt der Kauf fehl und dem Nutzer wird eine Fehlermeldung angezeigt.
• Ein Wechsel innerhalb desselben Aboprodukts von einem Basis-Abo mit Ratenzahlung zu einem Basis-Abo ohne Ratenzahlung ist nicht zulässig.

Beispiele und Verhaltensweisen für Ersatz

Sehen Sie sich das folgende Szenario an, um die Funktionsweise der einzelnen Aufteilungsmodi 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 aus Text besteht. Dieses Abo kostet ihn 2$pro Monat und wird am Ersten des Monats verlängert.

Am 15. April entschied sich Samwise für ein Upgrade auf die Jahresmitgliedschaft des Tier 2-Abos, das Videoupdates enthält und 36$pro Jahr kostet.

Beim Upgrade des Abos wählt der Entwickler einen Modus für die anteilige Abrechnung aus. In der folgenden Liste wird beschrieben, wie sich die einzelnen Aufteilungsmodi auf das Abo von Samwise auswirken:

WITH_TIME_PRORATION

Das Tier 1-Abo von Samwise endet sofort. Da er für einen ganzen Monat (1. bis 30. April) bezahlt hat, aber nach der Hälfte des Abozeitraums ein Upgrade durchgeführt hat, wird ihm für sein neues Abo der halbe Monatspreis (1 €) in Rechnung gestellt. 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 Folgejahres weitere 36 $in Rechnung gestellt.

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

CHARGE_PRORATED_PRICE

Dieser Modus kann verwendet werden, da der Abopreis pro Zeiteinheit für Stufe 2 (36 €/Jahr = 3 €/Monat) höher ist als der Abopreis 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 davon genutzt hat, wird auf sein neues Abo der halbe Monatspreis (1 €) angewendet. Da das neue Abo jedoch 36 $pro Jahr kostet, betragen die Kosten für die verbleibenden 15 Tage 1,50 $. Daher wird ihm die Differenz von 0,50 $für sein neues Abo in Rechnung gestellt. Am 1. Mai werden Samwise 36 $für sein neues Abo in Rechnung gestellt und am 1. Mai jedes Folgejahres weitere 36 $.

Sie sollten PurchasesUpdatedListener Ihrer App aufrufen, sobald der Kauf erfolgreich war. Sie können den neuen Kauf dann im Rahmen eines queryPurchasesAsync()-Aufrufs abrufen. 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 umgestellt. Am 1. Mai werden ihm 36 $für sein neues Abo in Rechnung gestellt und am 1. Mai jedes Folgejahres weitere 36 $.

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

DEFERRED

Samwise' Tier 1-Abo läuft weiter, bis es am 30. April abläuft. Am 1. Mai tritt das Abo der Stufe 2 in Kraft und Samwise werden 36 $für sein neues Abo in Rechnung gestellt.

Sie sollten PurchasesUpdatedListener Ihrer App aufrufen, sobald der Kauf erfolgreich war. Sie können den neuen Kauf dann im Rahmen eines queryPurchasesAsync()-Aufrufs abrufen. Ihr Backend erhält sofort eine SUBSCRIPTION_PURCHASED Entwicklerbenachrichtigung in Echtzeit. Verarbeite den Kauf wie jeden anderen neuen Kauf. Achten Sie insbesondere darauf, den neuen Kauf zu bestätigen. Hinweis: Die startTime des neuen Abos wird zum Zeitpunkt der Wirksamkeit des Ersatzes ausgefüllt, also wenn das alte Abo abläuft. Sie erhalten dann eine SUBSCRIPTION_RENEWED RTDN für das neue Abo. Weitere Informationen zum Verhalten von ReplacementMode.DEFERRED finden Sie unter Verzögerten Austausch 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 davon genutzt hat, wird auf sein neues Abo der halbe Monatspreis (1 €) angewendet. Da dieses neue Abo 36 $pro Jahr kostet, wird sein Abozeitraum um 1/36 Jahr verlängert (ca. 10 Tage). Die nächste Abbuchung in Höhe von 36 € erfolgt also in einem Jahr und 10 Tagen. Danach werden ihm jedes Jahr 36 $in Rechnung gestellt.

Beachten Sie bei der Auswahl eines Modus für die Aufteilung die Empfehlungen für Ersatzgeräte.

Aboänderungen in der App auslösen

Sie können Nutzern in Ihrer App ein Upgrade oder Downgrade anbieten. Dazu gehen Sie genauso vor wie beim Starten eines Kaufvorgangs. Wenn Sie jedoch ein Upgrade oder Downgrade durchführen, müssen Sie Details zum aktuellen Abo, zum zukünftigen Abo (Upgrade oder Downgrade) 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 Aufteilung aufgeführt. Außerdem wird für jedes Szenario empfohlen, was Sie tun sollten:

Käufe von Aboänderungen verarbeiten

Aboänderungen sind in jeder Hinsicht Neukäufe und sollten nach Abschluss des Abrechnungsvorgangs so verarbeitet und bestätigt werden. Sie müssen nicht nur den neuen Kauf ordnungsgemäß verarbeiten, sondern auch den ersetzten Kauf zurückziehen.

Das In-App-Verhalten entspricht dem bei jedem neuen Kauf. Ihre App erhält das Ergebnis des neuen Kaufs in Ihrem PurchasesUpdatedListener und der neue Kauf ist in queryPurchasesAsync verfügbar.

Die Google Play Developer API gibt eine linkedPurchaseToken in der Aboressource zurück, wenn ein Kauf ein vorhandenes Abo ersetzt. Achten Sie darauf, das in der linkedPurchaseToken angegebene Token ungültig zu machen, damit das alte Token nicht zum Zugriff auf Ihre Dienste verwendet wird. Informationen zum Umgang mit Upgrades und Downgrades findest du unter Upgrades, Downgrades und Neuregistrierungen.

Wenn Sie das neue Kauftoken erhalten, gehen Sie wie bei der Bestätigung eines neuen Kauftokens vor. Bestätige diese Käufe mit BillingClient.acknowledgePurchase() über die Google Play Billing Library oder mit Purchases.subscriptions:acknowledge über die Google Play Developer API.

Verschobenen Ersatz bearbeiten

Im Modus „Verzögerter Austausch“ kann ein Nutzer die verbleibende Berechtigung in seinem alten Tarif aufbrauchen, bevor er mit dem neuen Tarif beginnt.

Wenn du ReplacementMode.DEFERRED für einen Neukauf verwendest, gibt queryPurchasesAsync() nach dem Kaufvorgang ein neues Kauftoken zurück, das mit dem alten Produkt verknüpft bleibt, bis der verzögerte Austausch am nächsten Verlängerungsdatum erfolgt. Danach wird das neue Produkt zurückgegeben.

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

ReplacementMode.DEFERRED sollte ab sofort anstelle des eingestellten ProrationMode.DEFERRED verwendet werden, da es dasselbe Verhalten bei Berechtigungsänderungen aufweist, aber eine Möglichkeit bietet, den Kauf so zu verwalten, dass er mit dem Verhalten bei anderen neuen Käufen übereinstimmt.

Kundenverwaltung

Mit Entwicklerbenachrichtigungen in Echtzeit kannst du in Echtzeit erkennen, wenn ein Nutzer sein Abo kündigen möchte. Wenn ein Nutzer kündigt, sein Abo aber noch nicht abgelaufen ist, können Sie ihm Push-Benachrichtigungen oder In-App-Nachrichten senden, um ihn zu bitten, sich wieder zu registrieren.

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 mit den zugehörigen Aktionsvorschlägen und App-Anforderungen beschrieben.

Vor Ablauf des Abos – In-App

Bei Abos, die gekündigt, 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. Deine Benutzeroberfläche muss erkennen lassen, dass der Nutzer bereits ein Abo hat. So können Sie beispielsweise das aktuelle Ablaufdatum und den wiederkehrenden Preis des Nutzers mit einer Schaltfläche Wieder aktivieren anzeigen.

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

• Starte einen neuen Abokauf mit derselben SKU.
• Das neue Abo ersetzt das alte und wird am selben Ablaufdatum verlängert. Das alte Abo wird sofort als abgelaufen markiert.
• Angenommen, Achilles hat ein Abo für die Beispiel-Musik-App und das Abo läuft am 1. August ab. Am 10. Juli schließt er wieder ein Monatsabo zum gleichen Preis ab. Das neue Abo wird anteilig mit dem verbleibenden Guthaben berechnet, ist sofort aktiv und wird am 1. August verlängert.

Wenn Sie einen anderen Preis anbieten möchten, z. B. ein neues Probeabo oder einen Rabatt für ehemalige Kunden, können Sie dem Nutzer stattdessen eine andere SKU anbieten:

• Starte ein Upgrade oder Downgrade mit der anderen SKU im Ersatzmodus WITHOUT_PRORATION.
• 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 einschließlich aller Einführungspreise in Rechnung gestellt. Wenn das alte Abo mit einer verschleierten Konto-ID erstellt wurde, muss dieselbe ID für Upgrades und Downgrades an die BillingFlowParams übergeben werden.
• Angenommen, Achilles hat ein Abo für die Beispiel-Musik-App und das Abo läuft am 1. August ab. Am 10. Juli schließt er wieder 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 einen kostenlosen Testzeitraum oder einen Einführungspreis in Ihre SKU für die Kundenrückgewinnung aufnehmen möchten, prüfen Sie, ob der Nutzer die Voraussetzungen erfüllt. Entfernen Sie dazu in der Google Play Console das Häkchen aus dem Kästchen Eine kostenlose Testversion pro App zulassen.

Wenn du das Kauftoken erhältst, verarbeite den Kauf wie bei einem neuen Abo. Außerdem gibt die Google Play Developer API in der Aboressource eine linkedPurchaseToken zurück. Ungültig machen Sie das in der linkedPurchaseToken angegebene Token, damit das alte Token nicht zum Zugriff auf Ihre Dienste verwendet wird.

Vor Ablauf des Abos – im Play Store

Wenn das Abo gekündigt, aber noch aktiv ist, können Nutzer es im Google Play-Abocenter reaktivieren, indem sie auf Abo wieder aktivieren (früher Reaktivieren) klicken. So bleiben dasselbe Abo- und Kauftoken erhalten.

Weitere Informationen zum Wiederherstellen von Abos finden Sie unter Wiederherstellungen.

Nach Ablauf des Abos – In-App

Sie können Nutzern, deren Abo abgelaufen ist, ermöglichen, es in Ihrer App noch einmal abzuschließen. Verwenden Sie dazu denselben In-App-Produktkaufprozess wie für neue Abonnenten. Beachten Sie dabei Folgendes:

• Wenn Sie Nutzern einen Rabatt anbieten möchten, können Sie eine Produkt-ID mit Sonderpreisen für Ihr Abo angeben. Diese wird auch als Winback-SKU bezeichnet. Sie können das Angebot in Ihrer App anbieten oder Nutzer außerhalb der App über das Angebot informieren, z. B. per E-Mail.
• Wenn Sie ein Abo für die Kundenrückgewinnung starten möchten, starten Sie den Kaufvorgang in Ihrer Android-App mit der Google Play Billing Library. Das ist derselbe Vorgang wie bei einem neuen Abo, aber du kannst die Artikelnummer festlegen, die für den Nutzer verfügbar ist.
• Wenn Sie einen kostenlosen Testzeitraum oder einen Einführungspreis in Ihre SKU für die Kundenrückgewinnung aufnehmen möchten, prüfen Sie, ob der Nutzer die Voraussetzungen erfüllt. Entfernen Sie dazu in der Google Play Console das Häkchen aus dem Kästchen Eine kostenlose Testversion pro App zulassen. Andernfalls kann der Nutzer nur eine kostenlose Testversion pro App nutzen.
• Wenn der Nutzer wieder ein Abo für dieselbe Artikelnummer abschließt, hat er keinen Anspruch mehr auf einen kostenlosen Testzeitraum oder einen Einführungspreis. Achten Sie darauf, dass dies in Ihrer Benutzeroberfläche zum Ausdruck kommt.

Wenn du das Kauftoken erhältst, verarbeite den Kauf wie bei einem neuen Abo. Sie erhalten kein linkedPurchaseToken in der Aboressource.

Nach Ablauf des Abos – im Play Store

Wenn diese Option aktiviert ist, können Nutzer die gleiche Artikelnummer nach Ablauf bis zu ein Jahr lang wieder abonnieren, indem sie im Google Play Abocenter auf Noch einmal abonnieren klicken. Dadurch werden ein neues Abo und ein Kauftoken generiert.

Das erneute Abonnieren gilt als Out-of-App-Kauf. Beachten Sie daher die Best Practices für die Verarbeitung von Käufen, die außerhalb Ihrer App getätigt wurden.

Ihr Abo bewerben

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

Bei kostenlosen Testzeiträumen prüft Google Play vor Beginn des Testzeitraums, ob der Nutzer eine gültige Zahlungsmethode hat. Einigen Nutzern wird diese Bestätigung möglicherweise als Vorautorisierung oder Belastung ihrer Zahlungsmethode angezeigt. Diese Vorautorisierung oder Abbuchung ist vorübergehend und wird später rückgängig gemacht oder erstattet.

Nach Ablauf des Testzeitraums wird der volle Abopreis über die Zahlungsmethode des Nutzers abgerechnet.

Kündigt der Nutzer das Probeabo vor Ablauf des Testzeitraums, bleibt es dennoch bis zum Ende des eigentlichen Testzeitraums aktiv und dem Nutzer wird nichts berechnet.

Stornieren, erstatten oder widerrufen

Mit der Google Play Developer API können Sie ein Abo stornieren, erstatten 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 geben, in Ihrer App oder auf Ihrer Website zu kündigen. Ihre App sollte diese Stornierungen wie unter Stornierungen beschrieben verarbeiten.
• Erstattung: Wenn Sie eine Erstattung vornehmen, kann der Nutzer das Abo weiter nutzen. Erstattungen können beispielsweise in Anspruch genommen werden, wenn ein technischer Fehler den Nutzer daran gehindert hat, auf Ihr Produkt zuzugreifen, der Fehler aber behoben wurde. Wenn Sie mehr als die letzte Zahlung erstatten oder eine teilweise Erstattung veranlassen möchten, müssen Sie die Google Play Console verwenden.
• Stornieren: Wenn du das Abo stornierst, verliert der Nutzer sofort den Zugriff darauf. Dies kann beispielsweise verwendet werden, wenn ein technischer Fehler den Nutzer daran gehindert hat, auf Ihr Produkt zuzugreifen, und er 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 Stornieren, Erstattung und Widerruf veranschaulicht.

Abrechnung für einen Abonnenten verschieben

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

Bei Prepaid-Tarifen können Sie mit der Defer Billing API den Ablaufzeitpunkt verschieben.

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

• Biete Nutzern als Sonderangebot kostenlosen Zugriff, z. B. eine Woche lang kostenlos, wenn sie einen Film kaufen.
• Sie können Kunden aus Kulanz kostenlosen Zugriff gewähren.

Die Abrechnung kann pro API-Aufruf um mindestens einen Tag und maximal ein Jahr verschoben werden. Wenn Sie die Abrechnung noch weiter verschieben möchten, können Sie die API noch einmal aufrufen, bevor das neue Abrechnungsdatum erreicht wird.

Darcy hat beispielsweise ein monatliches Abo für Onlineinhalte der App „Fishing Quarterly“. Normalerweise werden ihr am Ersten eines jeden Monats 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, also sechs Wochen nach dem zuvor geplanten Abrechnungsdatum, dem 1. April. Darcy wird der April und der Anfang Mai nicht in Rechnung gestellt und sie hat weiterhin Zugriff auf die Inhalte. Am 15.Mai wird ihr die normale Abogebühr von 1, 25 £ für den Monat in Rechnung gestellt. Ihr nächstes Verlängerungsdatum ist jetzt der 15. Juni.

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

Umgang mit abgelehnten Zahlungen

Bei Zahlungsproblemen bei der Verlängerung eines Abos versucht Google, das Abo einige Zeit lang regelmäßig zu verlängern, bevor es gekündigt wird. Dieser Wiederherstellungszeitraum kann aus einem Kulanzzeitraum, gefolgt von einer Kontosperre, bestehen. In dieser Zeit sendet Google dem Nutzer E-Mails und Benachrichtigungen, in denen er aufgefordert wird, seine Zahlungsmethode zu aktualisieren.

Nach der Ablehnung der Zahlung beginnt für das Abo ein Kulanzzeitraum, sofern einer konfiguriert ist. Achten Sie während des Kulanzzeitraums darauf, dass der Nutzer weiterhin Zugriff auf die Aboberechtigungen hat.

Nach Ablauf eines Kulanzzeitraums wird für das Abo eine Kontosperre angewendet. Solange die Kontosperre aktiv ist, sollte der Nutzer keinen Zugriff auf die Aboberechtigungen haben.

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 Abowiederherstellung bei einer Zahlungsablehnung zu maximieren, können Sie den Nutzer über ein Zahlungsproblem informieren und ihn bitten, es zu beheben.

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

In-App-Messaging

Wenn Sie In-App-Messaging mit InAppMessageCategoryId.TRANSACTIONAL aktiviert haben, werden Nutzern während des Kulanzzeitraums und der Kontosperre einmal täglich Nachrichten von Google Play angezeigt. Sie haben dann die Möglichkeit, die Zahlung zu korrigieren, ohne die App zu verlassen.

Wir empfehlen, diese API jedes Mal aufzurufen, wenn der Nutzer die App öffnet, um zu ermitteln, ob die Mitteilung angezeigt werden soll.

Wenn der Nutzer sein Abo wiederhergestellt hat, erhältst du den Antwortcode SUBSCRIPTION_STATUS_UPDATED und ein Kauftoken. Sie sollten dann dieses Kauftoken verwenden, um die Google Play Developer API aufzurufen und den Abostatus in Ihrer App zu aktualisieren.

In-App-Messaging einbinden

Wenn Sie Nutzern In-App-Mitteilungen anzeigen möchten, verwenden Sie BillingClient.showInAppMessages().

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

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 Transaktionen für Abos verarbeiten

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

Die Änderung des Abostatus bei einem ersten Kauf mit ausstehenden Transaktionen ist ganz einfach. Ihre App erhält eine Purchase mit dem Status PENDING, wenn der Nutzer eine ausstehende Transaktion initiiert. Wenn die Transaktion abgeschlossen ist, erhält Ihre App die Purchase noch einmal mit dem aktualisierten Status PURCHASED. 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 abgebrochen wird, wird eine SubscriptionNotification-Nachricht vom Typ SUBSCRIPTION_PENDING_PURCHASE_CANCELED an Ihren RTDN-Client gesendet. In solchen Fällen sollte der Nutzer niemals Zugriff auf die Inhalte erhalten haben.

Bei Aufstockungen, Upgrades oder Downgrades mit ausstehenden Transaktionen kommt es sowohl beim alten als auch beim neuen Abo zu Statusänderungen. Wenn der Nutzer eine ausstehende Aufstockungs-, Upgrade- oder Downgrade-Transaktion initiiert, erhält Ihre App eine Purchase für das alte Abo mit einem PendingPurchaseUpdate-Objekt. Der Nutzer hat derzeit noch das alte Abo und hat das neue noch nicht erhalten. Wenn du getProducts() und getPurchaseToken() für das PendingPurchaseUpdate-Objekt aufrufst, werden die Produkt-IDs und das Kauftoken des neuen Abos zurückgegeben. Sobald die Transaktion abgeschlossen ist, erhält Ihre App eine Purchase mit dem Kauftoken der obersten Ebene, das für das neue Abo festgelegt ist, und dem Status PURCHASED. Eine SubscriptionNotification-Nachricht vom Typ SUBSCRIPTION_PURCHASED wird an Ihren RTDN-Client gesendet. Erst jetzt solltest du das alte Kauftoken durch das neue Kauftoken ersetzen und den Zugriff des Nutzers auf die Inhalte aktualisieren. Wenn die Transaktion abläuft oder abgebrochen wird, wird eine SubscriptionNotification-Nachricht vom 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.