In diesem Thema wird beschrieben, wie Sie mit Ereignissen im Abolebenszyklus umgehen, z. B. Verlängerungen und Ablaufen. Außerdem werden zusätzliche Abofunktionen beschrieben, z. B. das Anbieten von Werbeaktionen und die Möglichkeit, dass Nutzer ihre Abos selbst verwalten.
Wenn du keine Aboprodukte für deine Anwendung konfiguriert hast, findest du weitere Informationen unter Produkte erstellen und konfigurieren.
Aboübersicht
Ein Abo umfasst eine Reihe von Vorteilen, die Nutzer während eines bestimmten Zeitraums in Anspruch nehmen können. Ein Abo kann einen Nutzer beispielsweise berechtigt, auf einen Musik-Streamingdienst zuzugreifen.
Sie können in derselben Anwendung mehrere Abos haben, um verschiedene Vorteile darzustellen, oder verschiedene Stufen einer einzelnen Gruppe von Vorteilen (z. B. die Stufen „Silber“ und „Gold“).
Mit Basis-Abos und Angeboten kannst du 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 haben Sie die Möglichkeit, ein Upgrade-Angebot für Nutzer zu erstellen, die Ihre App bereits abonniert haben.
Eine ausführliche Übersicht über Aboprodukte, Basis-Abos und Angebote findest du in der Dokumentation in der Play Console-Hilfe.
Integration von Prepaid-Tarifen
Prepaid-Tarife werden nach Ablauf nicht automatisch verlängert. Um seine Aboberechtigung ohne Unterbrechung zu verlängern, muss der Nutzer für dasselbe Abo einen Prepaid-Tarif abschließen.
Starte zum Aufladen beim Aufladen 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-Tarifen wird immer der Ersatzmodus CHARGE_FULL_PRICE verwendet. Dieser Modus muss nicht explizit festgelegt werden.
Dem Nutzer wird sofort der volle Abrechnungszeitraum in Rechnung gestellt und seine Berechtigung wird um den bei der Aufladung angegebenen Zeitraum verlängert.
Nach einer Aufladung werden die folgenden Felder im Ergebnisobjekt Purchase entsprechend dem letzten Aufladekauf aktualisiert:
- 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 für Prepaid-Kauf
Ähnlich wie bei Abos mit automatischer Verlängerung müssen Sie Prepaid-Tarife nach dem Kauf bestätigen. Sowohl der Erstkauf als auch etwaige Aufladungen müssen bestätigt werden. Weitere Informationen findest du 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 einer Woche oder länger müssen innerhalb von drei Tagen bestätigt werden.
Prepaid-Tarife mit einer Laufzeit von weniger als einer Woche müssen innerhalb der Hälfte der Abodauer bestätigt werden. Entwickler haben beispielsweise 1,5 Tage Zeit, um einen dreitägigen Prepaid-Tarif zu bestätigen.
Nutzern mit Deeplinks ermöglichen, ein Abo zu verwalten
Deine App sollte auf einem Einstellungsbildschirm einen Link enthalten, über den Nutzer ihre Abos verwalten können. Diesen Link kannst du in das natürliche Erscheinungsbild deiner App integrieren.
Bei nicht abgelaufenen Abos kannst du einen Deeplink von deiner App zum Google Play-Abocenter hinzufügen. Diesen findest du im Feld subscriptionState der Aboressource.
Es gibt mehrere Möglichkeiten, wie du das Abocenter im Play Store per Deeplink verknüpfen kannst.
Link zum Abocenter
Mit der folgenden URL kannst du Nutzer zu der Seite weiterleiten, auf der alle ihre Abos angezeigt werden (siehe Abbildung 1 und 2):
https://play.google.com/store/account/subscriptions
Dieser Deeplink kann nützlich sein, um einem Nutzer dabei zu helfen, ein gekündigtes Abo aus dem Abocenter im Play Store wiederherzustellen.
Link zu einer bestimmten Seite zur Aboverwaltung (empfohlen)
Wenn Sie einen direkten Link zur Verwaltungsseite für ein nicht abgelaufenes Abo erstellen möchten, geben Sie den Paketnamen und productId für das erworbene Abo an. Wenn du die productId für ein bestehendes Abo programmatisch ermitteln möchtest, frag das Back-End deiner App ab oder rufe BillingClient.queryPurchasesAsync() auf, 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 Wert productId für das Abo, das der Nutzer in dieser Werbebuchung erworben hat.
Verwende die folgende URL, um Nutzer zu einem bestimmten Bildschirm zur Aboverwaltung weiterzuleiten. Ersetzen Sie dabei „your-sub-product-id“ und „your-app-package“ durch den productId bzw. den App-Paketnamen:
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, ein Upgrade, Downgrade oder eine Änderung ihres Abos durchzuführen
Du kannst bestehenden Abonnenten verschiedene Möglichkeiten bieten, ihr Abo an ihre Anforderungen anzupassen:
- Wenn Sie mehrere Abostufen anbieten, z. B. „Basic“ und „Premium“, 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 die Möglichkeit geben, ihren aktuellen Abrechnungszeitraum zu ändern, z. B. von einem Monats- zu einem Jahrestarif.
- Sie können Nutzern auch erlauben, zwischen Tarifen mit automatischer Verlängerung und Prepaid-Tarifen zu wechseln.
Du kannst diese Änderungen durch Aboangebote mit Rabatten für berechtigte Nutzer fördern. Sie können beispielsweise ein Angebot mit 50% Rabatt im ersten Jahr erstellen, wenn Sie von einem Monats- zu einem Jahrestarif wechseln, und dieses Angebot auf Nutzer beschränken, die einen Monatstarif abonniert und dieses Angebot noch nicht erworben haben. Weitere Informationen zu den Teilnahmevoraussetzungen für das Angebot finden Sie in der Hilfe.
Abbildung 3 zeigt eine Beispielanwendung mit drei verschiedenen Plänen:
In deiner App könnte ein Bildschirm wie Abbildung 3 angezeigt werden, auf dem Nutzer ihr Abo ändern können. Es sollte in allen Fällen für Nutzer klar erkennbar sein, welches ihr aktuelles Abo hat und welche Möglichkeiten sie haben, es zu ändern.
Wenn Nutzer ein Upgrade, Downgrade oder eine Änderung ihres Abos ausführen möchten, gibst du einen Ersatzmodus an. Dieser bestimmt, wie der anteilige Wert des aktuellen bezahlten Abrechnungszeitraums angewendet wird und wann eine Berechtigungsänderung erfolgt.
Ersatzmodi
In der folgenden Tabelle sind die verfügbaren Ersetzungsmodi und die Verwendungsbeispiele aufgeführt.
Ersetzungsmodus |
Beschreibung |
Anwendungsbeispiel |
|
Für das Abo wird sofort ein Upgrade oder Downgrade ausgeführt. Die verbleibende Zeit wird anhand der Preisdifferenz angepasst und dem neuen Abonnement gutgeschrieben, indem das nächste Abrechnungsdatum verschoben wird. Das ist die Standardeinstellung. |
Führen Sie ein Upgrade auf eine teurere Stufe ohne sofortige zusätzliche Zahlung durch. |
|
Das Abo wird sofort umgestellt und der Abrechnungszeitraum bleibt gleich. Die Preisdifferenz für den verbleibenden Zeitraum wird dann dem Nutzer in Rechnung gestellt. Hinweis: Diese Option ist nur für ein Abo-Upgrade verfügbar, bei dem sich der Preis pro Zeiteinheit erhöht. |
Sie können ein Upgrade auf eine teurere Stufe durchführen, ohne das Abrechnungsdatum zu ändern. |
|
Das Abo wird sofort aktualisiert oder herabgestuft und dem Nutzer wird sofort der volle Preis für die neue Berechtigung in Rechnung gestellt. Der verbleibende Wert des vorherigen Abos wird entweder für dieselbe Berechtigung übernommen oder anteilig für die Zeit berechnet, wenn zu einer anderen Berechtigung gewechselt wird. Hinweis: Wenn das neue Abo ein kostenloses Probeabo oder ein Einführungsangebot umfasst, werden dem Nutzer zum Zeitpunkt des Upgrades oder Downgrades 0 $oder der Preis des Einführungsangebots in Rechnung gestellt, je nachdem, was zutrifft. |
Führen Sie ein Upgrade von einem kürzeren auf einen längeren Abrechnungszeitraum aus. |
|
Für das Abo wird sofort ein Upgrade oder Downgrade durchgeführt und der neue Preis wird bei der Verlängerung des Abos in Rechnung gestellt. Der Abrechnungszeitraum bleibt gleich. |
Mit einem Upgrade auf eine höhere Abo-Stufe können Sie den verbleibenden kostenlosen Zeitraum beibehalten. |
|
Das Upgrade oder Downgrade des Abos erfolgt nur bei Verlängerung des Abos. Der neue Kauf wird jedoch sofort mit einem Startdatum in der Zukunft für die neue Berechtigung ausgestellt, sodass der Entwickler Nutzern die Möglichkeit geben kann, bei Bedarf weitere Änderungen vorzunehmen. Sie können beispielsweise zum ursprünglichen Plan zurückkehren oder eine neue nachträgliche Planänderung initiieren. |
Downgrade auf eine kostengünstigere Stufe ausführen. |
Weitere Informationen zu den verschiedenen Upselling- und Rückgewinnungsanwendungen von Upgrade- oder Downgrade-Angeboten finden Sie im Leitfaden zu Angeboten und Werbeaktionen.
Ersatzmodus für einen Kauf festlegen
Je nach Präferenzen und Geschäftslogik können Sie für verschiedene Arten von Aboumstellungen verschiedene Ersatzmodi verwenden. In diesem Abschnitt wird erläutert, wie Sie einen Ersatzmodus für eine Änderung in einem Abo festlegen und welche Einschränkungen gelten.
Innerhalb desselben Abos wieder abonnieren oder zu einem anderen Tarif wechseln
Sie können in der Google Play Console einen Standardersatzmodus festlegen. Mit dieser Einstellung können Sie auswählen, wann aktuellen Abonnenten Kosten in Rechnung gestellt werden sollen, wenn sie ein anderes Basis-Abo oder Angebot für dasselbe Abo kaufen oder nach einer Kündigung ein neues Abo abschließen. Die verfügbaren Optionen sind Sofort in Rechnung stellen, entspricht CHARGE_FULL_PRICE, und Zum nächsten Abrechnungsdatum abrechnen, entsprechend WITHOUT_PRORATION. Dies sind die einzigen relevanten Ersatzmodi, wenn innerhalb desselben Abos die Basis-Abos gewechselt werden.
Wenn Sie beispielsweise ein Rückgewinnungsangebot für denselben Tarif implementieren, nachdem der Nutzer gekündigt hat, aber bevor das Abo endet, können Sie den neuen Kauf als regulären Kauf verarbeiten, ohne Werte in SubscriptionUpdateParams anzugeben. Das System verwendet den im Abo konfigurierten Standardersatzmodus und übernimmt automatisch den Tarifwechsel vom alten zum neuen Kauf.
Tarif wechseln oder standardmäßigen Ersatzmodus überschreiben
Wenn der Nutzer Aboprodukte ändert und ein anderes Abo kauft oder wenn Sie den Standardersatzmodus aus irgendeinem Grund überschreiben möchten, geben Sie die anteilige Rate zur Laufzeit als Teil der Kaufvorgang-Parameter an.
Beachten Sie die folgenden Einschränkungen, damit SubscriptionUpdateParams im Rahmen der Konfiguration des Laufzeitkaufvorgangs korrekt angegeben werden kann:
- Beim Upgrade, Downgrade oder beim Wechsel eines Abos zu einem Prepaid-Tarif von einem Prepaid-Tarif oder einem Tarif mit automatischer Verlängerung ist der einzige zulässige Zuteilungsmodus
CHARGE_FULL_PRICE. Wenn Sie einen anderen Zuteilungsmodus angeben, schlägt der Kauf fehl und dem Nutzer wird ein Fehler angezeigt. - Wenn Sie Tarife innerhalb desselben Abos zu einem sich automatisch verlängernden Tarif
von entweder von einem Prepaid- oder einem automatisch verlängernden Tarif
wechseln, sind die gültigen Anteilsmodi
CHARGE_FULL_PRICEundWITHOUT_PRORATION. Wenn Sie einen anderen Zuteilungsmodus angeben, schlägt der Kauf fehl und dem Nutzer wird ein Fehler angezeigt.
Ersatzbeispiele und -verhalten
Betrachten Sie das folgende Szenario, um zu verstehen, wie die einzelnen Zuteilungsmodi funktionieren:
Samwise hat ein Abo für Online-Inhalte von der Country Gardener App. Er hat ein Monatsabo für die Tier 1-Version der Inhalte, die nur Text enthält. Dieses Abo kostet 2$pro Monat und wird am Ersten des Monats verlängert.
Am 15. April entschied sich Samwise für ein Upgrade auf die jährliche Version des Tier 2-Abos, das Videoupdates enthält und 36$pro Jahr kostet.
Beim Upgrade des Abos wählt der Entwickler einen Zuteilungsmodus aus. In der folgenden Liste wird beschrieben, wie sich die einzelnen Zuteilungsmodi auf Samwises Abo auswirken:
WITH_TIME_PRORATION
Samwises Tier 1-Abo endet sofort. Da er für einen ganzen Monat (1. bis 30. April) bezahlt, aber nach der Hälfte der Laufzeit ein Upgrade durchgeführt hat, wird die Hälfte des Abonnements eines Monats (1 $) auf sein neues Abonnement angerechnet. Da das neue Abo jedoch 36 $pro Jahr kostet, wird das Guthaben von 1 $nur für 10 Tage (16.–25. April) bezahlt. Am 26. April werden ihm also am 26. April 36 $für ein neues Abo und am 26. des darauffolgenden Jahres weitere 36 $in Rechnung gestellt.
Du solltest das PurchasesUpdatedListener deiner App in dem Moment aufrufen, in dem der Kauf erfolgreich ist. Du kannst den neuen Kauf dann im Rahmen eines queryPurchasesAsync()-Aufrufs abrufen. Ihr Backend erhält sofort eine Entwicklerbenachrichtigung in Echtzeit vom Typ SUBSCRIPTION_PURCHASED.
CHARGE_PRORATED_PRICE
Dieser Modus kann verwendet werden, da der Abopreis von Tier 2 pro Zeiteinheit (36 $/Jahr = 3 $/Monat) höher ist als der Abopreis von Tier 1 pro Zeiteinheit (2 $/Monat). Samwises Tier 1-Abo endet sofort. Da er für einen ganzen Monat bezahlt, aber nur die Hälfte davon genutzt hat, wird für sein neues Abo ein halber Monat des Abos (1 $) berechnet. 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 für seine neue Abostufe 36 $und am 1. Mai des Folgejahres weitere 36 $berechnet.
Du solltest das PurchasesUpdatedListener deiner App in dem Moment aufrufen, in dem der Kauf erfolgreich ist. Du kannst den neuen Kauf dann im Rahmen eines queryPurchasesAsync()-Aufrufs abrufen. Ihr Backend erhält sofort eine Entwicklerbenachrichtigung in Echtzeit vom Typ SUBSCRIPTION_PURCHASED.
WITHOUT_PRORATION
Samwises Tier 1-Abo wird sofort und ohne zusätzliche Kosten auf Tier 2 hochgestuft. Am 1. Mai werden ihm 36 $für seine neue Abostufe und am 1. Mai des Folgejahres weitere 36 $in Rechnung gestellt.
Du solltest das PurchasesUpdatedListener deiner App in dem Moment aufrufen, in dem der Kauf erfolgreich ist. Du kannst den neuen Kauf dann im Rahmen eines queryPurchasesAsync()-Aufrufs abrufen. Ihr Backend erhält sofort eine Entwicklerbenachrichtigung in Echtzeit vom Typ SUBSCRIPTION_PURCHASED.
DEFERRED
Samwises Tier 1-Abo läuft bis zum 30. April weiter. Am 1. Mai tritt das Tier 2-Abo in Kraft und Samwise wird 36 $für seine neue Abostufe berechnet.
Du solltest das PurchasesUpdatedListener deiner App in dem Moment aufrufen, in dem der Kauf erfolgreich ist. Du kannst den neuen Kauf dann im Rahmen eines queryPurchasesAsync()-Aufrufs abrufen. Ihr Backend erhält sofort eine Entwicklerbenachrichtigung in Echtzeit vom Typ SUBSCRIPTION_PURCHASED. Du solltest den Kauf zu diesem Zeitpunkt genauso verarbeiten wie jeden anderen neuen Kauf. Achten Sie insbesondere darauf, den neuen Kauf zu bestätigen. Hinweis: Die startTime des neuen Abos wird ausgefüllt, sobald der Ersatz in Kraft tritt und das geschieht, wenn das alte Abo abläuft. Du erhältst dann eine Echtzeitbenachrichtigung von SUBSCRIPTION_RENEWED für das neue Abo. Weitere Informationen zum Verhalten von ReplacementMode.DEFERRED finden Sie unter Verzögerte Ersetzung verarbeiten.
CHARGE_FULL_PRICE
Samwises Tier 1-Abo 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 für sein neues Abo ein halber Monatsabo (1 $) berechnet. Da das neue Abo 36 $pro Jahr kostet, wird dem Abozeitraum (ca. 10 Tage) der 36. eines Jahres hinzugefügt. Daher beträgt die nächste Abrechnung von Samwise 1 Jahr und 10 Tage ab heute 36 $. Danach werden ihm jedes Jahr 36 $in Rechnung gestellt.
Lesen Sie bei der Auswahl eines Zuteilungsmodus unsere Empfehlungen für das Ersetzen.
Aboänderungen in der App auslösen
Deine App kann Nutzern ein Upgrade oder Downgrade auf die gleiche Weise anbieten wie beim Starten eines Kaufvorgangs. Wenn Sie jedoch ein Upgrade oder Downgrade ausführen, müssen Sie Details zum aktuellen Abo, zum zukünftigen Abo (Upgrade oder Downgrade) und zum Ersetzungsmodus angeben, wie im folgenden Beispiel gezeigt:
Kotlin
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
)
// ...
Java
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 einen Ersatz
Die folgende Tabelle zeigt verschiedene Szenarien für die anteiligen Verteilung zusammen mit den Empfehlungen für jedes Szenario:
| Szenario | Empfohlener Ersatzmodus | Ergebnis |
|---|---|---|
| Upgrade auf eine teurere Stufe | CHARGE_PRORATED_PRICE |
Der Nutzer erhält sofort Zugriff, der Abrechnungszeitraum bleibt jedoch gleich. |
| Downgrade auf eine kostengünstigere Stufe | DEFERRED |
Der Nutzer hat bereits für die teurere Stufe bezahlt, sodass er bis zum nächsten Abrechnungsdatum Zugriff hat. |
| Upgrade während eines kostenlosen Testzeitraums durchführen und den Testzeitraum beibehalten | WITHOUT_PRORATION |
Der Nutzer behält den kostenlosen Testzugriff, führt aber für den Rest des Testzeitraums ein Upgrade auf eine höhere Stufe durch. |
| Upgrade während eines kostenlosen Testzeitraums – Ende des Zugriffs auf die kostenlose Testversion | CHARGE_PRORATED_PRICE |
Der Nutzer erhält sofort Zugriff auf die neue Stufe, hat aber keinen kostenlosen Testzeitraum mehr. |
Käufe von Aboänderungen verarbeiten
Tarifänderungen sind neue Käufe für alle Bedingungen und Zwecke und sollten nach erfolgreichem Abschluss des Abrechnungsablaufs verarbeitet und als solche bestätigt werden. Du musst den neuen Kauf nicht nur korrekt verarbeiten, sondern auch den zu ersetzenden Kauf entfernen.
Das In-App-Verhalten ist dasselbe wie bei jedem Neukauf. Das Ergebnis des neuen Kaufs wird in PurchasesUpdatedListener für Ihre App erfasst. Der neu erworbene Kauf ist in queryPurchasesAsync verfügbar.
Die Google Play Developer API gibt ein linkedPurchaseToken in der Aboressource zurück, wenn ein Kauf ein vorhandenes ersetzt. Entwerten Sie das in linkedPurchaseToken angegebene Token, damit das alte Token nicht für den Zugriff auf Ihre Dienste verwendet wird. Weitere Informationen zur Verwaltung von Upgrades und Downgrades finden Sie unter Upgrades, Downgrades und Neuregistrierungen.
Wenn du das neue Kauftoken erhältst, folge demselben Überprüfungsverfahren wie bei der Bestätigung eines neuen Kauftokens. Du musst diese Käufe mit BillingClient.acknowledgePurchase() aus der Google Play Billing Library oder mit Purchases.subscriptions:acknowledge aus der Google Play Developer API bestätigen.
Verzögerte Ersetzung behandeln
Mit dem Modus für den nachträglichen Ersatz können Sie einem Nutzer die Möglichkeit geben, die verbleibende Berechtigung im alten Tarif aufzubrauchen, bevor er mit dem neuen Tarif beginnt.
Wenn Sie ReplacementMode.DEFERRED für einen neuen Kauf verwenden, gibt queryPurchasesAsync() nach dem Kaufvorgang ein neues Kauftoken zurück, das dem alten Produkt zugeordnet bleibt, bis der nachträgliche Austausch am nächsten Verlängerungsdatum erfolgt. Danach wird das neue Produkt zurückgegeben.
In der Vergangenheit war dies mit dem verworfenen ProrationMode.DEFERRED möglich, aber ProrationMode.DEFERRED wird mit der Play Billing Library 6 eingestellt. In der folgenden Tabelle sehen Sie, wo sich das Verhalten unterscheidet:
Uhrzeit |
ProrationMode.DEFERRED (verworfen) |
Ersatzmodus.DEFERRED |
Direkt nach erfolgreichem Kaufvorgang (App) |
Der Anspruch auf das alte Abo bleibt bis zum nächsten Verlängerungsdatum bestehen. Damit sichergestellt ist, dass die App die richtige Berechtigung gewährt, gibt Das neue Kauftoken wird nicht angezeigt und kann daher zu diesem Zeitpunkt nicht verarbeitet werden. |
Das neue Kauftoken wird angezeigt und sollte an dieser Stelle verarbeitet werden, um zu berücksichtigen, wann der Austausch stattfinden soll. |
Direkt nach erfolgreichem Kaufvorgang (Backend) |
Die Umsatzbeteiligung für SUBSCRIPTION_PURCHASED wird nicht nach dem Kaufvorgang gesendet. Das Backend wird noch nicht auf den neuen Kauf aufmerksam gemacht. |
SUBSCRIPTION_PURCHASED RTDN mit der alten product_id wird unmittelbar nach dem Kaufvorgang für das neue Kauftoken gesendet. Wenn Sie die Methode purchases.subscriptionsv2.get mit dem neuen Kauftoken aufrufen, wird ein Kauf mit einer Startzeit (startTime) zurückgegeben, die den Kaufzeitpunkt mit zwei Werbebuchungen angibt:
ABONNEMENT_ABGESCHLOSSEN für das alte Kauftoken gesendet. Wenn Sie die Methode purchases.subscriptionsv2.get mit dem alten Kauftoken aufrufen, wird es als abgelaufen angezeigt. Die Berechtigung für das alte Abo wird für die verbleibende Zeit auf den neuen Kauf übertragen. |
Bei Ersatz – erste Verlängerung nach dem Kaufvorgang (App) |
Das neue Kauftoken wird jetzt angezeigt und sollte verarbeitet werden. |
In Der neue Kauf sollte bereits verarbeitet worden sein, als der Kaufvorgang erfolgreich war. Die App sollte also keine besonderen Maßnahmen ergreifen, abgesehen davon, dass die richtige Berechtigung gewährt wurde. |
Bei Ersatz – erste Verlängerung nach dem Kaufvorgang (Backend) |
Der neue Kauf kann jetzt verarbeitet und bestätigt werden, wenn die erste SUBSCRIPTION_RENEWED RTDN gesendet wird. Mit der |
Der neue Kauf wurde verarbeitet und bestätigt, als die SUBSCRIPTION_PURCHASED RTDN für das neue Kauftoken gesendet und als "startTime" aufgezeichnet wurde. Mit „ReplacementMode.DEFERRED“ wird das Standardverhalten aller anderen Verlängerungen angewendet. Sie müssen also keine spezielle Logik für den Austausch von Ersatzvorgängen ausführen, wenn dieses Ereignis eintritt. Wenn die Methode purchases.subscriptionsv2.get mit dem neuen Kauftoken aufgerufen wird, wird ein Kauf mit zwei Werbebuchungen zurückgegeben:
|
Von nun an sollte „ReplacementMode.DEFERRED“ anstelle des veralteten ProrationMode.DEFERRED verwendet werden, da es das gleiche Verhalten bei Berechtigungsänderungen bietet, aber eine Möglichkeit bietet, Käufe zu verwalten, die dem Verhalten anderer neuer Käufe besser entsprechen.
Kundenverwaltung
Mit Entwicklerbenachrichtigungen in Echtzeit kannst du in Echtzeit erkennen, wenn ein Nutzer sich entschließt, den Dienst zu kündigen. Wenn ein Nutzer sein Abo kündigt, aber sein Abo noch nicht abgelaufen ist, kannst du ihm Push-Benachrichtigungen oder In-App-Nachrichten senden und ihn bitten, ein neues Abo abzuschließen.
Nachdem ein Nutzer sein Abo gekündigt hat, kannst du versuchen, ihn entweder in deiner App oder über den Play Store zurückzugewinnen. In der folgenden Tabelle werden verschiedene Aboszenarien zusammen mit den zugehörigen Rückgewinnungsaktionen und Anforderungen an Apps beschrieben.
| Vor Ablauf des Abos | Nach Ablauf des Abos | |||
| In-App | Im Play Store | In-App | Im Play Store | |
| Winback-Funktion | In-App-Abo | Wiederherstellen | In-App-Abo | Erneut abonnieren |
| Nutzer durchläuft den Bezahlvorgang | Ja | Nein | Ja | Ja |
| Das Nutzerabo bleibt mit derselben Artikelnummer verknüpft | Nutzer können sich für dieselbe oder eine andere Artikelnummer registrieren | Ja | Nutzer können sich für dieselbe oder eine andere Artikelnummer registrieren | Ja |
| Neues Kauftoken erstellt | Ja | Nein | Ja | Ja |
| Standardmäßig aktiviert | Nein | Ja, Support für alle Entwickler erforderlich | Nein |
Apps ohne Billing Library 2.0 oder höher: Nein Apps mit Billing Library 2.0 oder höher: Ja. Entwickler können diese Option in der Console deaktivieren. |
| Wann fallen Kosten an? |
Bei Verwendung derselben SKU: Ende des aktuellen Abrechnungszeitraums. Bei Verwendung einer anderen Artikelnummer: hängt vom Zuteilungsmodus ab. |
Ende des aktuellen Abrechnungszeitraums | Sofort | Sofort |
| Implementierung erforderlich | In Ihrer App eine Benutzeroberfläche für die Neuregistrierung bereitstellen |
Änderungen des Abostatus erkennen Deeplink zum Play Store |
Benutzeroberfläche für die Neuregistrierung in Ihrer App bereitstellen | Out-of-App-Käufe verarbeiten |
Vor Ablauf des Abos – In-App
Bei Abos, die gekündigt wurden, aber noch nicht abgelaufen sind, kannst du Abonnenten erlauben, ihr Abo in deiner App wiederherzustellen. Dazu führst du denselben Kaufvorgang für In-App-Produkte aus wie bei neuen Abonnenten. Achte darauf, dass auf der Benutzeroberfläche erkennbar ist, dass der Nutzer bereits ein Abo hat. Beispielsweise können Sie das aktuelle Ablaufdatum und den wiederkehrenden Preis des Nutzers mit der Schaltfläche Wieder aktivieren anzeigen lassen.
In den meisten Fällen bietet es sich an, Nutzern denselben Preis und dieselbe Artikelnummer anzubieten, die sie bereits abonniert hatten. Das geht so:
- Du kannst 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 gekennzeichnet.
- Achilles hat beispielsweise ein Abo für die Beispiel-Musik-App, das am 1. August abläuft. Am 10. Juli schließt er das einmonatige Abo zum monatlichen Preis noch einmal ab. Das neue Abo wird mit dem verbleibenden Guthaben anteilig berechnet, ist sofort aktiv und wird noch am 1. August verlängert.
Wenn Sie einen anderen Preis anbieten möchten, z. B. einen neuen kostenlosen Testzeitraum oder einen Winback-Rabatt, können Sie dem Nutzer stattdessen eine andere Artikelnummer anbieten:
- Führe mit dem Ersatzmodus
WITHOUT_PRORATIONein Upgrade oder Downgrade mit der anderen Artikelnummer aus. - Das neue Abo ersetzt das alte und wird am selben Ablaufdatum verlängert. Dem Nutzer wird der Preis für die neue Artikelnummer, einschließlich aller Einführungspreise, am ursprünglichen Ablaufdatum in Rechnung gestellt. Wenn das alte Abo mit einer verschleierten Konto-ID erstellt wurde, sollte dieselbe ID für Upgrades und Downgrades an
BillingFlowParamsübergeben werden. - Achilles hat beispielsweise ein Abo für die Beispiel-Musik-App, das am 1. August abläuft. Am 10. Juli abonniert er wieder ein Jahresabo zum Einführungspreis. Das neue Abo ist sofort aktiv und dem Nutzer wird der Einführungspreis am 1. August in Rechnung gestellt.
- Wenn du ein kostenloses Probeabo oder einen Einführungspreis in deine Rücksende-Artikelnummer aufnehmen möchtest, achte darauf, dass der Nutzer berechtigt ist, indem du in der Google Play Console das Häkchen bei Kostenlose Testversion pro App erlauben entfernst. In diesem Fall kann der Nutzer nur eine kostenlose Testversion pro App erhalten.
Wenn du das Kauftoken erhältst, verarbeite den Kauf wie bei einem neuen Abo. Außerdem gibt die Google Play Developer API ein linkedPurchaseToken in der Aboressource zurück. Entwerten Sie das Token im linkedPurchaseToken, damit das alte Token nicht für den Zugriff auf Ihre Dienste verwendet wird.
Vor Ablauf des Abos – im Play Store
Während das Abo gekündigt wurde, aber noch aktiv ist, können Nutzer es im Google Play-Abocenter wiederherstellen, indem sie auf Wieder abonnieren (früher Wiederherstellen) klicken. Dadurch bleiben das Abo und das Kauftoken unverändert.
Weitere Informationen zum Wiederherstellen von Abos finden Sie unter Wiederherstellungen.
Nach Ablauf des Abos – In-App
Du kannst abgelaufenen Abonnenten in deiner App ermöglichen, ein neues Abo abzuschließen, indem du denselben Kaufvorgang für In-App-Produkte wie bei neuen Abonnenten anwendest. Beachten Sie Folgendes:
- Wenn Sie Nutzern einen Rabatt anbieten möchten, können Sie eine Produkt-ID mit Sonderpreisen für Ihr Abo anbieten, die auch als Winback-SKU bezeichnet wird. Du kannst das Angebot in deiner App zur Verfügung stellen oder den Nutzer außerhalb der App, z. B. per E-Mail, über das Angebot informieren.
- Wenn du ein Abo zur Kundenrückgewinnung starten möchtest, starte den Kaufvorgang in deiner Android-App über die Google Play Billing Library. Dies ist derselbe Vorgang wie bei einem neuen Abo, aber Sie können die SKU bestimmen, die dem Nutzer zur Verfügung steht.
- Wenn du in deiner Callback-SKU ein kostenloses Probeabo oder einen Einführungspreis aufnehmen möchtest, achte darauf, dass der Nutzer berechtigt ist, indem du in der Google Play Console das Häkchen bei 1 kostenlosen Testzeitraum pro App erlauben entfernst. In diesem Fall kann der Nutzer nur ein kostenloses Probeabo pro App erhalten.
- Wenn der Nutzer dieselbe Artikelnummer noch einmal abonniert, hat er keinen Anspruch mehr auf kostenlose Probeabos oder Einführungspreise. Achten Sie darauf, dass Ihre Benutzeroberfläche dies widerspiegelt.
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 bis zu ein Jahr nach Ablauf des Abos noch einmal abonnieren. Dazu klicken sie im Google Play-Abocenter auf Wieder abonnieren. Dadurch werden ein neues Abo und ein Kauftoken generiert.
Ein Abo gilt als Käufe außerhalb der App. Beachten Sie deshalb die Best Practices für die Handhabung von Käufen außerhalb Ihrer App.
Ihr Abo bewerben
Sie können Gutscheincodes erstellen, um ausgewählten Nutzern einen verlängerten kostenlosen Testzeitraum für ein bestehendes Abo zu bieten. Weitere Informationen
Bei kostenlosen Testversionen überprüft Google Play vor Beginn des kostenlosen Testzeitraums, ob der Nutzer eine gültige Zahlungsmethode hat. Bei einigen Nutzern wird diese Bestätigung möglicherweise als Vorautorisierung oder Belastung angezeigt. Diese Vorautorisierung ist vorübergehend und wird später rückgängig gemacht oder erstattet.
Nach Ablauf des Testzeitraums wird die Zahlungsmethode des Nutzers mit dem vollen Abobetrag belastet.
Kündigt ein Nutzer das Abo während des kostenlosen Testzeitraums, bleibt das Abo bis zum Ende des Testzeitraums aktiv. Nach Ablauf des Testzeitraums wird ihm nichts in Rechnung gestellt.
Abbrechen, erstatten oder widerrufen
Mit der Google Play Developer API können Sie ein Abo kündigen, 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. Du kannst Nutzern auch eine Option zum Kündigen in deiner App oder auf deiner Website anbieten. Die App sollte diese Stornierungen wie unter Kündigungen beschrieben verarbeiten können.
- Erstatten: Wenn Sie eine Erstattung vornehmen, kann der Nutzer das Abo weiterhin nutzen. Erstattungen können beispielsweise dann verwendet werden, wenn ein technischer Fehler aufgetreten ist, durch den der Nutzer nicht auf Ihr Produkt zugreifen konnte, der Fehler jedoch behoben wurde. Wenn Sie einen höheren Betrag als die letzte Zahlung erstatten möchten oder eine teilweise Erstattung veranlassen möchten, müssen Sie die Google Play Console verwenden.
- Widerrufen: Wenn Sie das Abo widerrufen, verliert der Nutzer sofort den Zugriff auf das Abo. Sie können diese Option verwenden, wenn beispielsweise ein technischer Fehler aufgetreten ist, der den Nutzer am Zugriff auf Ihr Produkt gehindert hat, und er das Produkt nicht weiter verwenden möchte. Die Anwendung sollte diese Kündigungen wie unter Widerruf beschrieben verarbeiten.
In der folgenden Tabelle sind die Unterschiede zwischen „Abbrechen“, „Erstattung“ und „Widerruf“ dargestellt.
| Verlängerung wird gestoppt | Geld zurückerstatten | Zugriff widerrufen | |
| Abbrechen | Ja | Nein | Nein |
| Erstattung | Nein | Ja | Nein |
| Widerrufen | Ja | Ja | Ja |
Abrechnung für einen Abonnenten aufschieben
Mit Purchases.subscriptions:defer aus der Google Play Developer API kannst du das nächste Abrechnungsdatum für ein Abo mit automatischer Verlängerung voraussetzen. Während des Aufschubzeitraums abonniert der Nutzer Ihre Inhalte mit uneingeschränktem Zugriff, es werden ihm aber keine Kosten in Rechnung gestellt. Das Verlängerungsdatum des Abos wird entsprechend aktualisiert.
Bei Prepaid-Tarifen können Sie die Defer Billing API verwenden, um die Ablaufzeit zu verschieben.
Mit der nachträglichen Abrechnung haben Sie folgende Möglichkeiten:
- Biete Nutzern im Rahmen eines Sonderangebots kostenlosen Zugang, z. B. eine Woche lang kostenlos für den Kauf eines Films.
- Biete deinen Kunden als Zeichen des Wohlwollens kostenlosen Zugang an.
Die Abrechnung kann pro API-Aufruf um einen Tag und ein Jahr verschoben werden. Wenn Sie die Abrechnung noch weiter aufschieben möchten, können Sie die API noch einmal aufrufen, bevor das neue Abrechnungsdatum erreicht wird.
Beispiel: Darcy hat ein Monatsabo für Onlineinhalte für die Fishing Quarterly-App. Normalerweise wird ihr am ersten Tag jedes Monats 1, 25 £ in Rechnung gestellt. Im März hat sie an einer Onlineumfrage für den App-Publisher teilgenommen. Der Publisher belohnt sie mit sechs kostenlosen Wochen, indem er die nächste Zahlung bis zum 15. Mai verzögert, also sechs Wochen nach dem zuvor geplanten Abrechnungsdatum am 1. April. Darcy ist für April oder Anfang Mai kostenlos und hat weiterhin Zugriff auf die Inhalte. Am 15.Mai wird ihr die normale Abogebühr von 1, 25 £ für den Monat berechnet. Ihr nächstes Verlängerungsdatum ist nun der 15. Juni.
Beim Verschieben kannst du den Nutzer per E-Mail oder in der App benachrichtigen, dass sich sein Abrechnungsdatum geändert hat.
Umgang mit abgelehnten Zahlungen
Wenn bei einer Aboverlängerung Zahlungsprobleme auftreten, versucht Google regelmäßig, das Abo vor der Kündigung zu verlängern. Dieser Wiederherstellungszeitraum kann aus einem Kulanzzeitraum gefolgt von einer Kontosperre bestehen. Während dieser Zeit sendet Google E-Mails und Benachrichtigungen an den Nutzer, in denen er aufgefordert wird, seine Zahlungsmethode zu aktualisieren.
Wird die Zahlung abgelehnt, beginnt für das Abo ein Kulanzzeitraum, sofern eine 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 wirksam. Während der Kontosperre solltest du darauf achten, dass der Nutzer keinen Zugriff auf die Aboberechtigungen hat.
Du kannst die Länge des Kulanzzeitraums für jedes Basis-Abo mit automatischer Verlängerung und die Kontosperre in der Google Play Console festlegen. Wenn Sie Längen unter den Standardwerten angeben, kann sich die Anzahl der Abos verringern, die nach Zahlungsablehnungen wiederhergestellt werden.
Um die Wahrscheinlichkeit zu erhöhen, dass das Abo wiederhergestellt wird, wenn die Zahlung abgelehnt wird, kannst du den Nutzer über ein Zahlungsproblem informieren und ihn bitten, es zu beheben.
Sie können dies entweder selbst tun, wie in den Abschnitten Kulanzzeitraum und Kontosperre beschrieben, oder Sie können die In-App Messaging API implementieren, über die Google Nutzern in Ihrer App eine Nachricht anzeigt.
In-App-Messaging
Wenn du In-App-Benachrichtigungen mit InAppMessageCategoryId.TRANSACTIONAL aktiviert hast, zeigt Google Play den Nutzern während des Kulanzzeitraums und der Kontosperre einmal pro Tag Nachrichten an und bietet ihnen 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 zu bestimmen, ob die Mitteilung angezeigt werden soll.
Wenn der Nutzer sein Abo erfolgreich wiederhergestellt hat, erhältst du den Antwortcode SUBSCRIPTION_STATUS_UPDATED zusammen mit einem Kauftoken. Du solltest dieses Kauftoken dann verwenden, um die Google Play Developer API aufzurufen und den Abostatus in deiner App zu aktualisieren.
In-App-Messaging einbinden
Verwenden Sie BillingClient.showInAppMessages(), um dem Nutzer In-App-Benachrichtigungen anzuzeigen.
Hier ein Beispiel für das Auslösen des In-App-Messaging-Ablaufs:
Kotlin
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.
}
}
})
Java
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.
}
}
});