Abo mit Add-ons

Mit einem Abo mit Add-ons können Sie mehrere Abo-Produkte bündeln, die zusammen gekauft, abgerechnet und verwaltet werden können. Ihre bestehenden Produktkatalog-Abos können nahtlos als Add-ons angeboten werden, ohne dass eine Vorab-Spezifikation oder zusätzliche Konfiguration erforderlich ist. Sie können einen Kaufvorgang mit mehreren bestehenden Aboprodukten starten und diese als Add-ons verkaufen.

Wissenswertes

Beachten Sie bei der Verwendung der Funktion „Abo mit Add-ons“ die folgenden Punkte:

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

  • Alle Artikel im Kauf müssen denselben Abrechnungszeitraum für die wiederkehrende Abrechnung haben. Sie können beispielsweise kein Abo mit jährlicher Abrechnung und Add-ons mit monatlicher Abrechnung haben.

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

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

Integration mit der Play Billing Library

In diesem Abschnitt wird beschrieben, wie Sie das Feature für Abos mit Add-ons in die Play Billing Library (PBL) einbinden. Es wird davon ausgegangen, dass Sie mit den ersten Schritten der PBL-Integration vertraut sind, z. B. PBL-Abhängigkeit zu Ihrer App hinzufügen, BillingClient initialisieren und Verbindung zu Google Play herstellen. In diesem Abschnitt geht es um die Aspekte der PBL-Integration, die speziell für Abos mit Add-ons gelten.

Kaufvorgang starten

So starten Sie einen Kaufvorgang für ein Abo mit Add-ons:

  1. Rufen Sie alle Ihre Abo-Artikel mit der Methode BillingClient.queryProductDetailsAsync ab.

  2. Legen Sie das ProductDetailsParams-Objekt für jedes Element fest.

    Das Element, das durch das ProductDetailsParams-Objekt dargestellt wird, gibt sowohl das ProductDetails an, das das Abo-Element angibt, als auch ein offerToken, das ein bestimmtes Abo base plan oder offer auswählt.

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

    Das folgende Beispiel zeigt, wie Sie den Abrechnungsablauf für den Kauf eines Abos mit mehreren Artikeln starten:

    Java

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

Regeln für Artikel im Kauf

  • Damit die Verlängerungsdaten von Add‑ons mit dem Basisartikel übereinstimmen, kann Google Play nach Ablauf von Probeabo- oder Einführungspreisphasen eine anteilige Gebühr einfügen.
  • Die Angebotsberechtigung wird für jeden Artikel separat geprüft.

Käufe verarbeiten

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

Abos mit Add-ons ändern

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

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

  • Rufen Sie setOldPurchaseToken immer mit dem Kauf-Token des aktuellen Abo-Kaufs auf.
  • Wenn Sie ein Upgrade, Downgrade oder Crossgrade für einen Artikel durchführen möchten, rufen Sie SubscriptionProductReplacementParams.setReplacementMode auf, um anzugeben, wie die Aboänderung zwischen dem alten und dem neuen gekauften Artikel behandelt werden soll. Andernfalls ist es nicht erforderlich, diesen Parameter festzulegen.
  • Wenn sich das Basiselement nicht ändert, können Sie trotzdem SubscriptionProductReplacementParams.setSubscriptionReplacementMode aufrufen, um ein bestimmtes Ersetzungsverhalten anzuwenden. Die in diesem Fall geltenden Regeln finden Sie unter Abo reaktivieren oder Abo innerhalb desselben Abos wechseln.
  • Neue Add-ons werden sofort angewendet. Es wird eine anteilige Gebühr berechnet, damit das nächste Verlängerungsdatum mit dem Basisartikel im Abo übereinstimmt.
  • Entfernte Add-ons laufen am Ende des aktuellen Abrechnungszeitraums ab.
  • Beim Starten des Abrechnungsablaufs müssen Sie alle aktiven Artikel im Abo mit Add-ons angeben, mit Ausnahme der zu entfernenden Artikel, sowie alle neuen Add-ons.

Das folgende Beispiel zeigt, wie Sie die launchBillingFlow API aufrufen, wenn Sie einen bestehenden Kauf eines Abos mit Add-ons ändern:

Java

BillingClient billingClient = ;

int replacementMode =;

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

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

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

billingClient.launchBillingFlow(billingFlowParams);

Szenarien für Aboänderungen

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

Verwendung von SubscriptionProductReplacementParams

Vorhandene Artikel Geänderte Elemente Muss der Ersatzmodus in SubscriptionProductReplacementParams festgelegt werden? Verhalten
A (Basiselement), B A (Basiselement) Ja (KEEP_EXISTING verwenden)
  • Element B wird zu einem späteren Zeitpunkt entfernt.
  • Element A bleibt erhalten.
  • Nutzer behalten den aktuellen Preis für Artikel A, einschließlich aller verbleibenden Einführungszahlungen, die sie bei der Registrierung erhalten haben.
A A (Basiselement), B Ja (KEEP_EXISTING für A verwenden)
  • Artikel B wird sofort hinzugefügt und anteilig berechnet.
  • Element A bleibt erhalten.
  • Nutzer behalten den aktuellen Preis für Artikel A, einschließlich aller verbleibenden Einführungszahlungen, die sie bei der Registrierung erhalten haben.
A (Basiselement), B A (Basiselement), C Ja (KEEP_EXISTING für A verwenden)
  • B wird zu einem späteren Zeitpunkt entfernt.
  • C wird sofort hinzugefügt und anteilig berechnet.
  • Element A bleibt erhalten.
  • Nutzer behalten den aktuellen Preis für Artikel A, einschließlich aller verbleibenden Einführungszahlungen, die sie bei der Registrierung erhalten haben.
A (Basiselement), B B (Basisartikel) Nein A wird zu einem späteren Zeitpunkt entfernt.
A (Basiselement), B C (Basisartikel) Ja
  • Der Ersatz für A -> C hängt von SubscriptionProductReplacementParams replacementMode ab.
  • B wird zu einem späteren Zeitpunkt entfernt.
A (Basiselement), B C (Basiselement), B Ja
  • Der Ersatz für A -> C hängt von SubscriptionProductReplacementParams replacementMode ab.
  • Wenn Sie Element B unverändert beibehalten möchten, legen Sie den Ersetzungsmodus auf KEEP_EXISTING fest. Andernfalls ist der Standardersetzungsmodus IMMEDIATE_WITHOUT_PRORATION.
A (Basiselement), B C (Basisartikel), D Ja
  • Der Ersatz für A -> C hängt von SubscriptionProductReplacementParams replacementMode ab.
  • B wird zu einem späteren Zeitpunkt entfernt.
  • D wird sofort hinzugefügt und anteilig berechnet.
A (Basiselement), B A (Basiselement), C Ja
  • Der Ersatz für A -> A und B -> C hängt vom Ersatzmodus ab, der in SubscriptionProductReplacementParams replacementMode in jedem ProductDetailsParams angegeben ist.
  • Wenn Sie Artikel A unverändert lassen möchten, legen Sie den Ersetzungsmodus auf KEEP_EXISTING fest.
A (Basisartikel), B, C D (Basiselement), B, C Ja
  • Der Ersatz für A->D und B->B, C->C hängt vom Ersatzmodus ab, der in SubscriptionProductReplacementParams replacementMode in jedem ProductDetailsParams angegeben ist.
  • Wenn Sie die Elemente B und C unverändert lassen möchten, legen Sie ihren Ersetzungsmodus auf KEEP_EXISTING fest.

Verwendung von SubscriptionUpdateParams

Vorhandene Artikel Geänderte Elemente Müssen Sie die Ersatzinformationen festlegen? Verhalten
A (Basiselement), B A (Basiselement) Nein
  • Element B wird zu einem späteren Zeitpunkt entfernt.
  • Das Verhalten von Artikel A hängt von der Einstellung Änderungen an Basis-Abos und Angeboten des Basis-Abos ab.
  • Der Preis für Artikel A wird auf den aktuellen Preis aktualisiert und Nutzer verlieren möglicherweise alle Einführungszahlungen, die sie bei der Registrierung basierend auf den Angebotsberechtigungskriterien erhalten haben.
A A (Basiselement), B Nein
  • Artikel B wird sofort hinzugefügt und anteilig berechnet.
  • Das Verhalten von Artikel A hängt von der Einstellung Änderungen an Basis-Abos und Angeboten des Basis-Abos ab.
  • Der Preis für Artikel A wird auf den aktuellen Preis aktualisiert und Nutzer verlieren möglicherweise alle Einführungszahlungen, die sie bei der Registrierung erhalten haben, basierend auf den Angebotsberechtigungskriterien.
A (Basiselement), B A (Basiselement), C Nein
  • B wird zu einem späteren Zeitpunkt entfernt.
  • C wird sofort hinzugefügt und anteilig berechnet.
  • Das Verhalten von Artikel A hängt von der Einstellung Änderungen an Basis-Abos und Angeboten des Basis-Abos ab.
A (Basiselement), B B (Basisartikel) Nein A wird zu einem späteren Zeitpunkt entfernt.
A (Basiselement), B C (Basisartikel) Ja
A (Basiselement), B C (Basiselement), B Ja Der Ersatz für A -> C hängt von setSubscriptionReplacementMode ab (in PBL 8.1 eingestellt).
A (Basiselement), B C (Basisartikel), D Ja
  • Der Ersatz für A -> C hängt von setSubscriptionReplacementMode ab (in PBL 8.1 eingestellt).
  • B wird zu einem späteren Zeitpunkt entfernt.
  • D wird sofort hinzugefügt und anteilig berechnet.

Entwicklerbenachrichtigungen in Echtzeit

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

Preisänderungen für bestehende Abonnenten

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

Eine alte Preiskohorte beenden

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

  • Alle ausstehenden Preiserhöhungen mit Opt-in sollten dieselbe Verlängerungszeit wie der neue Preis haben. Wenn für einen Artikel in einem Abo mit Add-ons eine Opt-in-Preiserhöhung vorliegt, die noch nicht vom Nutzer bestätigt wurde, wird jede neue Opt-in-Preiserhöhung für andere Artikel im Kauf ignoriert, es sei denn, sie führt zum gleichen Erneuerungszeitpunkt der Anwendung des neuen Preises wie die bestehende Preiserhöhung im Status OUTSTANDING. Sobald der Nutzer die Preiserhöhung bestätigt hat, werden alle neueren Preisänderungen registriert. Nutzer können alle nicht bestätigten Opt-in-Preiserhöhungen nur gleichzeitig akzeptieren.

    Beispiel:

    • Angenommen, Sie haben ein Abo mit Add-ons (Artikel A und B), das sich am 7. eines jeden Monats verlängert.
    • Für Artikel A findet derzeit eine Preisänderung von 7 $auf 10 $statt. Die Preiserhöhung soll am 7. Juli in Kraft treten.
    • Eine neue Preisumstellung von 5 $auf 6 $beginnt für Artikel B am 2. Juni. Da die Preiserhöhung mit Opt-in 37 Tage nach der Migration beginnt, ist die früheste Preiserhöhung für Artikel B am 7. August möglich.

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

  • Die E-Mail von Google Play enthält eine Liste aller Artikel, bei denen am selben Tag Preisänderungen in Kraft treten.

Abo mit Add‑ons kündigen

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

Wenn ein Abokauf storniert wird, ohne dass er widerrufen wird, werden keine der Artikel im Kauf automatisch verlängert. Der Nutzer hat jedoch weiterhin Zugriff auf die berechtigten Artikel, bis die entsprechenden Abrechnungszeiträume enden.

Abos mit Add-ons widerrufen und erstatten

Im Folgenden finden Sie einige Richtlinien zum Widerrufen und Erstatten von Abos:

  • In der Play Console können Sie eine Erstattung für einen bestimmten Betrag für eine bestimmte Bestellung veranlassen, ohne den Zugriff auf das Abo zu widerrufen.

  • Rufen Sie orders.refund auf, um bestimmte Abozahlungen des Nutzers vollständig zu erstatten, ohne den Zugriff auf das Abo zu widerrufen.

  • Rufen Sie purchases.subscriptionsv2.revoke auf, um den Zugriff auf alle Abo-Artikel sofort zu widerrufen. Mit dieser API haben Sie folgende Möglichkeiten:

    • Den Zugriff auf alle Artikel widerrufen und eine anteilige Erstattung leisten.

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

    • Widerrufen Sie den Zugriff für alle Artikel und gewähren Sie eine FullRefund (volle Erstattung).

    • Zugriff auf einzelne Artikel widerrufen und volle Erstattung für den Artikel erhalten.

Einzelne Artikel in einem Abo mit Add-ons widerrufen

Wenn Sie einzelne Abo-Artikel in einem Abo mit Add-ons widerrufen möchten, ohne den gesamten Kauf zu widerrufen, rufen Sie purchases.subscriptionsv2.revoke auf und legen Sie das Feld ItemBasedRefund in RevocationContext fest. Die productId des Artikels, der widerrufen und erstattet werden soll, kann im Feld ItemBasedRefund festgelegt werden.

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

  • Wenn nach dem Widerruf des in ItemBasedRefund angegebenen Artikels noch aktive Artikel im Abo-Kauf vorhanden sind, wird nur der Artikel widerrufen und vollständig erstattet, ohne dass der Abo-Status unterbrochen wird.
  • Wenn nach dem Widerruf des in ItemBasedRefund angegebenen Artikels keine aktiven Artikel mehr im Abo-Kauf vorhanden sind, wird der Artikel widerrufen, vollständig erstattet und das Abo wird gekündigt.

Wissenswertes

  • Wenn Sie die ItemBasedRefund verwenden, kann jeweils nur ein Element widerrufen werden. Der Aufruf kann mehrmals erfolgen, wenn verschiedene Artikel widerrufen werden müssen.
  • Wenn der Abo-Kauf in einem der Zustände ist, in denen die Zahlung abgelehnt wurde, oder wenn der in ItemBasedRefund angegebene Artikel nicht im Besitz des Nutzers ist oder abgelaufen ist, wird die Ablehnung des Artikels blockiert.
  • Die Deaktivierung von Artikeln wird bei Prepaid-Abos nicht unterstützt.

Ablauf von Artikeln bei abgelehnter Zahlung

Bei einem Kauf eines Abos mit Add-ons müssen bei bestimmten Verlängerungen möglicherweise nur die Berechtigungen für eine Teilmenge von Artikeln verlängert werden, ohne dass sich dies auf Artikel mit einem zukünftigen Ablaufdatum auswirkt.

Unabhängig davon, welche Artikel an einer Verlängerung beteiligt sind, tritt der gesamte Abo-Kauf in den Kulanzzeitraum ein und das Konto wird gesperrt, wenn die Verlängerungszahlung abgelehnt wird. Weitere Informationen finden Sie in der folgenden Dokumentation.

Wiederherstellungszeitraum auswählen

Da der Nutzer während des Kulanzzeitraums weiterhin Anspruch auf das Abo hat, wird bei einem Kauf eines Abos mit Add-ons, bei dem die Verlängerungszahlung abgelehnt wird, der Artikel mit dem kürzesten Kulanzzeitraum unter allen aktiven Artikeln ausgewählt und sein Kulanzzeitraum und seine Kontosperre als Wiederherstellungszeitraum für diese Verlängerung angewendet.

Aktive Artikel umfassen Artikel, die beim Kauf eines Abos mit Add-ons kurz vor dem Verlängerungsversuch aktiv waren. Ausgenommen sind alle neu hinzugefügten Artikel (die erst nach der Wiederherstellung berechtigt sind) und alle Artikel, die aufgrund von Entfernung oder Deaktivierung nicht mehr aktiv sind.

Die Einstellung für die Kontosperre des Artikels mit dem ausgewählten Mindestkulanzzeitraum wird angewendet. Wenn es mehrere Artikel mit dem Mindestkulanzzeitraum, aber unterschiedlichen Kontosperren gibt, wird die längste Kontosperre angewendet.

Kulanzzeitraum

Wenn eine Verlängerungszahlung für ein Abo abgelehnt wird, wechselt der Abokauf in den Kulanzzeitraum. Während des Kulanzzeitraums hat der Nutzer weiterhin Zugriff auf alle aktiven Artikel aus dem vorherigen Verlängerungszeitraum. Wenn die Zahlungsmethode nach Ablauf des Kulanzzeitraums nicht korrigiert wurde, wird für den gesamten Abokauf eine Kontosperre aktiviert. Wenn andere Artikel während des Kulanzzeitraums das Verlängerungsdatum erreichen, wird ein neuer Abbuchungsversuch für diese Artikel gestartet, sobald das Abo nach der Zahlungsablehnung wieder aktiv ist.

Kontosperre

Während des Konto-Hold-Status ist der Zugriff auf alle Abo-Artikel ausgesetzt, bis die Zahlung wiederhergestellt ist.

Wenn das Abo, für das eine Kontosperre vorliegt, reaktiviert wird, bleibt der Abokauf unverändert bestehen. Wenn das Abo nicht reaktiviert wird, laufen die Artikel mit Zahlungsablehnung ab und der Zugriff auf die anderen Artikel wird für den Rest des Abrechnungszeitraums wieder aufgenommen.

Beispiel:

  • Ein Nutzer hat ein Abo für Mein Basis-Abo, das sich am 1. eines jeden Monats verlängert. Am 15. August fügt er ein Add-on-Abo für 10 $pro Monat mit einem siebentägigen Probeabo hinzu. Für beide Artikel ist kein Kulanzzeitraum festgelegt und beide haben eine 30‑tägige Kontosperre.

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

Wenn das Abo aufgrund einer abgelehnten Zahlung in den Status „Kontosperre“ wechselt, hat der Nutzer keinen Zugriff auf die Artikel im Abo mit Add-ons. Die verbleibende Zeit für die Artikel, die nicht verlängert werden, wird den Nutzern zurückerstattet, wenn das Abo nicht mehr gesperrt ist, entweder weil die Zahlung eingegangen ist oder das Abo gekündigt wurde.

Im vorherigen Beispiel wird ein Abo am 22. August auf „Kontosperrung“ gesetzt.

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

  • Wenn das Konto nicht innerhalb von 30 Tagen wiederhergestellt wird, wird das Abo am 21. September gekündigt und der Nutzer verliert den Zugriff auf das Add-on-Abo. Bis zum 30. September hat er jedoch weiterhin Zugriff auf sein Basis-Abo.

In diesem Beispiel müssen Sie die aktualisierte expiryTime für ALLE Artikel im Abo mit Add-ons abrufen, da einige Artikel nach der Kulanzfrist und der Kontosperrung möglicherweise wieder berechtigt sind.

Finanzberichterstattung und Abgleich

Mithilfe des Berichts zu Einnahmen können Sie Ihre aktiven Abos mit Transaktionen bei Google Play abgleichen. Jede Transaktionsposition hat eine Auftrags-ID. Wenn ein Kauf mehrere Artikel umfasst, enthalten die Berichte zu Einnahmen und geschätzten Verkäufen für jeden Artikel separate Zeilen für jede Transaktion, z. B. Belastung, Gebühr, Steuer und Erstattung.

Für Dashboards in der Play Console:

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

  • Die Bestellverwaltung spiegelt den Kauf eines Abos mit Add-ons wider und zeigt detaillierte Listen der gekauften Artikel. In der Bestellverwaltung können Sie den Kauf eines Nutzers widerrufen, stornieren oder vollständig erstatten.