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.
Integration von Ratenabonnements
Bei einem Ratenabo bezahlen Nutzer das Abo über einen bestimmten Zeitraum in mehreren Raten, anstatt die gesamte Abogebühr im Voraus zu bezahlen.
Weitere Hinweise zu Ratenzahlungen:
- Länderverfügbarkeit: Die Funktion für Ratenzahlungen ist nur in Brasilien, Frankreich, Italien und Spanien verfügbar. Die aktuelle Verfügbarkeit findest du in der Console.
- Preis festlegen: Wenn Sie den Preis für ein Ratenabo in der Console festlegen, entspricht der Preis dem monatlichen Zahlungsbetrag. Zusammen mit der festgelegten Zusicherungsdauer ergibt sich der Gesamtbetrag für das Abo, das auf dem Kaufbildschirm angezeigt wird.
- Mindestlaufzeit: Die Gesamtdauer der ersten Abozusicherung, während der monatliche Zahlungen fällig sind. Wenn ein Basis-Abo beispielsweise eine Mindestlaufzeit von 15 Monaten hat, leistet der Nutzer 15 monatliche Zahlungen über diesen Zeitraum.
- Verlängerungen: Im Kontext von Ratenabonnements bezeichnet „Verlängerung“ den Ablauf einer Zusicherungsdauer, entweder der anfänglichen Zusicherungsdauer oder der nachfolgenden Zusicherungszeit. Nach der Erstregistrierung erfolgt die erste Verlängerung nach Ablauf des gesamten anfänglichen Zusicherungszeitraums. Nachfolgende Verlängerungen erfolgen nach Erfüllung der darauffolgenden Zusicherungszeiträume. Die Verlängerungstypen für Ratenabos können „Automatische Verlängerung monatlich“ oder „Automatische Verlängerung für die gleiche Dauer“ lauten. Für die Option „Automatische Verlängerung monatlich“ 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: Im Kontext von Ratenabonnements bezieht sich dies auf das wiederkehrende Intervall, in dem einzelne Zahlungen gemäß Basis-Abo ausgeführt werden.
- Verhalten bei Tarifänderungen im Vergleich zu Preisänderungsverhalten: Bei Preisänderungen und Stornierungen ist die Zusicherung verbindlich. Wenn also ein Nutzer kündigen oder ein Entwickler den Preis ändern möchte, wird die Änderung am Ende eines Zusicherungszeitraums wirksam. Bei Tarifänderungen ist die Zusicherung nicht fest. Das bedeutet, dass die Tarifänderung nicht bis zum Ende eines Zusicherungszeitraums warten muss, sondern entweder sofort oder am nächsten Zahlungsdatum basierend auf dem festgelegten Ersatzmodus wirksam wird.
- Änderung des Basis-Abos mit Ratenzahlung: Der Wechsel des Basis-Abos mit Ratenzahlungen zu einem Basis-Abo ohne Ratenzahlungen für dasselbe Aboprodukt ist nicht zulässig.
Entwicklerbenachrichtigungen in Echtzeit: Eine
SUBSCRIPTION_CANCELLATION_SCHEDULED
-RTDN wird sofort nach einer vom Nutzer veranlassten Kündigung gesendet, wenn während des Zusicherungszeitraums Zahlungen verbleiben. Die Kündigung steht aus und wird erst am Ende des Zusicherungszeitraums wirksam. Wenn der Nutzer sie nicht wiederhergestellt hat, werdenSUBSCRIPTION_CANCELED
- undSUBSCRIPTION_EXPIRED
-RTDNs am Ende der Mindestlaufzeit gesendet.Zahlungen / Umsatzrealisierung: Die Auszahlungen an den 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 Ratenabo anmeldet.
Betrug versäumter Zahlungen: Wenn ein Nutzer eine Ratenzahlung nicht durchführt, werden weder Google noch der Entwickler versuchen, solche versäumten oder ausstehenden Zahlungen vom Nutzer einzuziehen. Dies gilt nicht, wenn Google die Zahlung während eines Kulanzzeitraums oder einer Kontosperre regelmäßig gemäß den üblichen Wiederholungspraktiken für Zahlungen wiederholen kann. Google übernimmt gegenüber dem Entwickler keine Verantwortung für ausstehende unbezahlte Ratenzahlungen.
Verfügbarkeit der Play Billing Library: Das Feld
installmentDetails
ist nur für PBL 7 oder höher verfügbar. Ab PBL 5 wird das Ratenabo mitqueryProductDetails()
zurückgegeben, enthält jedoch keine detaillierten Rateninformationen wie die Anzahl der zugesicherten Zahlungen des Tarifs.
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
![Im Play Store-Abo-Bildschirm wird der Status aller Abos eines Nutzers angezeigt, die über Google Play abgerechnet werden.](https://developer.android.com/static/images/google/play/billing/sub_center_general.png?authuser=6&hl=de)
![Tippe auf ein Abo, um weitere Details zu sehen.](https://developer.android.com/static/images/google/play/billing/sub_management_mock_general.png?authuser=6&hl=de)
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:
![Diese App hat drei Abostufen.](https://developer.android.com/static/images/google/play/billing/plan_change_inapp.png?authuser=6&hl=de)
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 Ersatzmodi, die Beispielnutzung und die Anzahl der Zahlungen aufgeführt, die als bezahlt gelten.
Ersetzungsmodus |
Beschreibung |
Anwendungsbeispiel |
Zugesicherte Zahlungen, die als bezahlt erfasst werden (als Ersatz für Ratenzahlungen) |
|
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. |
0 |
|
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. |
1 |
|
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. |
1 (Hinweis: 0, wenn für das neue Abo ein kostenloser Testzeitraum verfügbar ist.) |
|
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. |
0 |
|
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. Hinweis: Bei Ratenzahlungen erfolgt die Tarifänderung zu Beginn des nächsten Zahlungsdatums. |
Downgrade auf eine kostengünstigere Stufe ausführen. |
1 |
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:
- Wenn Sie ein Upgrade, Downgrade ausführen oder ein Abo desselben Abos von einem Prepaid-Tarif, einem Tarif mit automatischer Verlängerung oder einem Ratenplan zu einem Prepaid-Tarif wechseln, ist der einzige zulässige Ersatzmodus
CHARGE_FULL_PRICE
. Wenn Sie einen anderen Ersatzmodus 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_PRICE
undWITHOUT_PRORATION
. Wenn Sie einen anderen Zuteilungsmodus angeben, schlägt der Kauf fehl und dem Nutzer wird ein Fehler angezeigt. - Tarife innerhalb desselben Aboprodukts können nicht von einem Basis-Abo mit Raten zu einem Basis-Abo ohne Ratenzahlungen geändert werden.
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_PRORATION
ein 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.
![Abo-Abschnitt in der Google Play Store App, in dem ein gekündigtes Abo mit der Schaltfläche „Wieder abonnieren“ angezeigt wird](https://developer.android.com/static/images/google/play/billing/resubscribe.jpg?authuser=6&hl=de)
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.
![Abo-Abschnitt in der Google Play Store App mit einem gekündigten und abgelaufenen Abo sowie den Schaltflächen „Wieder abonnieren“ und „Entfernen“](https://developer.android.com/static/images/google/play/billing/resubscribe-remove.jpg?authuser=6&hl=de)
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 weiter 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.
![Snackbar, in der der Nutzer aufgefordert wird, die Zahlung zu korrigieren](https://developer.android.com/static/images/google/play/billing/subscriptions-in-app-messaging-snackbar.png?authuser=6&hl=de)
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. } } });
Ausstehende Transaktionen für Abos verarbeiten
Ausstehende Transaktionen können beim ersten Kauf, beim Aufladen, beim Upgrade oder beim Downgrade ausgeführt werden. Das Abo beginnt mit dem Status SUBSCRIPTION_STATE_PENDING
und wechselt dann zu SUBSCRIPTION_STATE_ACTIVE
. Wenn die Transaktion abgelaufen oder vom Nutzer abgebrochen wurde, wird sie an SUBSCRIPTION_STATE_PENDING_PURCHASE_EXPIRED
gesendet. Du darfst die Berechtigung des Nutzers nur nach Abschluss der Transaktion aktualisieren.
Die Änderung des Abostatus für einen Erstkauf mit ausstehenden Transaktionen ist einfach. Wenn der Nutzer eine ausstehende Transaktion initiiert, erhält die Anwendung den Status Purchase
mit PENDING
. Wenn die Transaktion abgeschlossen ist, erhält die Anwendung noch einmal das Purchase
mit dem Status PURCHASED
. Eine SubscriptionNotification
-Nachricht vom Typ SUBSCRIPTION_PURCHASED
wird an deinen RTDN-Client gesendet. Bestätige den Kauf wie gewohnt, gewähre dem Nutzer Zugriff auf die Inhalte und bestätige den Kauf. Wenn die Transaktion abläuft oder abgebrochen wird, wird eine SubscriptionNotification
-Nachricht vom Typ SUBSCRIPTION_PENDING_PURCHASE_CANCELED
an deinen RTDN-Client gesendet. In solchen Fällen hätte der Nutzer niemals Zugriff auf die Inhalte haben dürfen.
Beim Aufladen, Upgrade oder Downgrade mit ausstehenden Transaktionen werden Statusänderungen sowohl für die alten als auch die neuen Abos vorgenommen. Wenn der Nutzer eine ausstehende Aufladen-, Upgrade- oder Downgrade-Transaktion startet, erhält Ihre App eine Purchase
für das alte Abo mit einem PendingPurchaseUpdate
-Objekt. Derzeit besitzt der Nutzer noch das alte Abo und hat das neue Abo noch nicht erworben. Wenn du getProducts()
und getPurchaseToken()
im Objekt PendingPurchaseUpdate
aufrufst, werden die Produkt-IDs und das Kauftoken des neuen Abos zurückgegeben. Wenn die Transaktion abgeschlossen ist, erhält deine App ein Purchase
, wobei das Kauftoken der obersten Ebene für das neue Abo und der Status auf PURCHASED
gesetzt sind. Eine SubscriptionNotification
-Nachricht vom Typ SUBSCRIPTION_PURCHASED
wird an deinen RTDN-Client gesendet. Nur zu diesem Zeitpunkt solltest du das alte Kauftoken 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 vom Typ SUBSCRIPTION_PENDING_PURCHASE_CANCELED
an deinen RTDN-Client gesendet. In solchen Fällen sollte der Nutzer weiterhin auf den Inhalt des alten Abos zugreifen können.