Apple und Google lassen dich nach einem Ausfall das Verlängerungsdatum eines Abos verschieben, und ihre Grenzen könnten unterschiedlicher nicht sein

Ein Ausfall liefert jedem Abonnenten die sauberste Begründung für eine Erstattung, die es gibt, und du kannst niemanden davon abhalten, sie zu nutzen. Was du tun kannst: die verlorenen Tage zurückgeben, bevor jemand fragt. Beide Stores lassen dich das Verlängerungsdatum eines Abos verschieben, sodass der Kunde Gratiszeit statt Geld bekommt. Apple begrenzt jede Verschiebung auf 90 Tage und erlaubt zwei pro Jahr. Google lässt dich die Abrechnung um bis zu ein Jahr pro Aufruf aufschieben. Der Aufwand, die Benachrichtigungen und die Rechnung darunter unterscheiden sich so stark, dass ein einziger Ausfallplan nicht für beide reicht.

Was ein Ausfall mit deinem Erstattungsrisiko macht

Über Erstattungen entscheiden die Stores, nicht du. Im App Store fragt der Kunde bei Apple an und Apple entscheidet. Du bekommst unter Umständen eine CONSUMPTION_REQUEST-Benachrichtigung und hast 12 Stunden Zeit, über Send Consumption Information Nutzungsdaten zu senden. Mehr Mitspracherecht hast du nicht.

Bei Google Play kann ein Käufer innerhalb von 48 Stunden nach dem Kauf eine Erstattung bekommen, ohne dass du gefragt wirst. Danach landen Anfragen bei dir. Der einzige Google-Ablauf, der deine Nachweise anfordert, ist eine zur Prüfung durch den Entwickler markierte Rückbuchung, auf die du innerhalb von 24 Stunden über orders.reviewrefund antwortest. Die Entscheidung der Bank über eine Rückbuchung ist endgültig.

Keiner der beiden Stores gibt dir also eine Möglichkeit, eine Erstattung zu blockieren. Was du in der Hand hast, ist, ob sich ein Abonnent noch übervorteilt fühlt, wenn der Dienst wieder läuft. Zusätzliche Abo-Zeit, schnell gewährt und klar angekündigt, ist genau das Werkzeug, das beide Stores dafür gebaut haben.

So verschiebst du das Verlängerungsdatum eines Abos im App Store

Die App Store Server API hat dafür zwei Endpoints. Extend a Subscription Renewal Date wirkt auf ein einzelnes Abo, das du über seine originalTransactionId identifizierst. Extend Subscription Renewal Dates for All Active Subscribers wirkt auf alle berechtigten Abonnenten einer productId, und du kannst es mit storefrontCountryCodes eingrenzen, wenn der Ausfall nur einige Regionen getroffen hat.

Jede Anfrage enthält drei Dinge: extendByDays, eine Zahl von 1 bis 90; einen extendReasonCode; und einen requestIdentifier, den du erzeugst. Grundcode 3 steht für ein Dienstproblem oder einen Ausfall. Code 1 steht für Kundenzufriedenheit, Code 2 für sonstige Gründe und Code 0 für nicht angegeben.

Welche Abos Apple verschiebt

Infrage kommen nur aktive, automatisch verlängerbare Abos mit mindestens einem bereits bezahlten Zeitraum. Diese überspringt Apple:

• Abos in einem kostenlosen Angebotszeitraum, etwa einem Gratis-Test.
• Inaktive Abos in einem erneuten Abbuchungsversuch.
• Abos in einer Kulanzfrist für die Abrechnung, deren Ablaufdatum in der Vergangenheit liegt.
• Abos, deren Verlängerungsdatum in den letzten 365 Tagen schon zweimal verschoben wurde.
• Abgelaufene Abos.

Die Familienfreigabe gibt es gratis dazu. Wenn Apple ein gekauftes Abo verschiebt, das die Familienfreigabe unterstützt, werden die Abos der Familienmitglieder ebenfalls verschoben. Das Abo eines Familienmitglieds kannst du nicht direkt ansteuern.

Die Massenanfrage ist langsam, also behalte die Benachrichtigungen im Blick

Laut Apple kann eine Anfrage, alle aktiven Abonnenten zu verschieben, Stunden oder sogar Tage dauern, je nachdem, wie viele Abonnenten du hast. Eine 200-Antwort bedeutet nur, dass Apple sie bearbeitet. App Store Server Notifications V2 sagt dir, wie es gelaufen ist:

Nimm bei jedem FAILURE die originalTransactionId aus der signierten Transaktion im Payload und versuche es erneut mit dem Endpoint für einzelne Abos. Wenn du lieber abfragst, meldet Get Status of Subscription Renewal Date Extensions, ob die Anfrage abgeschlossen ist und wie viele Verschiebungen gelungen oder fehlgeschlagen sind.

So funktioniert der Abrechnungsaufschub bei Google Play

Googles Variante ist purchases.subscriptionsv2.defer, einmal pro Kauf-Token aufgerufen. Der Request-Body enthält einen deferralContext mit drei Feldern. Das etag kommt von purchases.subscriptionsv2.get, und der Aufruf schlägt fehl, wenn es nicht mit dem aktuellen etag des Abos übereinstimmt. Die deferDuration gibt an, wie weit das Datum verschoben wird. Und validateOnly führt die Anfrage bei true als Probelauf aus, ohne das Abo anzufassen.

Googles Billing-Leitfaden legt die Spanne auf einen Tag bis ein Jahr pro API-Aufruf fest. Für mehr rufst du erneut auf, bevor das neue Ablaufdatum erreicht ist. Bei einem automatisch verlängerten Abo verschiebt der Aufschub das nächste Verlängerungsdatum. Bei einem Prepaid-Tarif verschiebt er den Ablaufzeitpunkt. Bei einem Abo mit Add-ons wird jedes Element um dieselbe Dauer aufgeschoben. Die Antwort listet die neue expiryTime jedes Elements auf.

Während des Aufschubs bleibt der Nutzer mit vollem Zugriff abonniert und zahlt nichts für die zusätzliche Zeit. Google sendet eine SUBSCRIPTION_DEFERRED-Benachrichtigung in Echtzeit für Entwickler. Das ältere purchases.subscriptions.defer ist veraltet, neuer Code sollte also die v2-Methode nutzen.

Google informiert deinen Kunden nicht, also musst du es tun

Apple schickt dem Kunden nach jeder erfolgreichen Verschiebung eine E-Mail. Googles Billing-Leitfaden beschreibt überhaupt keine Nachricht an den Nutzer. Wenn es darum geht, Erstattungsanfragen zuvorzukommen, muss der Abonnent wissen, dass es die zusätzliche Zeit gibt. Sag es ihm selbst, in der App und per E-Mail, und nenne die Anzahl der Tage und den Grund.

Apple und Google im Vergleich

Was eine Verschiebung im Vergleich zu einer Erstattung kostet

Eine Erstattung und eine Verschiebung nehmen Geld von unterschiedlichen Stellen. Eine Erstattung gibt zurück, was der Kunde für den Zeitraum bezahlt hat. Alles, was du schon ausgegeben hast, um diesen Kunden zu bedienen, bleibt ausgegeben: Rechenleistung für jede Sitzung, Aufrufe an die Modell-API, Speicher und jede Auszahlung an einen Creator, dessen Inhalte er genutzt hat.

Eine Verschiebung behält die Zahlung. Sie kostet dich den Dienst, den du ohne bezahlende Verlängerung lieferst. An jedem zusätzlichen Tag verursacht ein aktiver Abonnent weiter dieselben Kosten. Bei einem leichten Nutzer ist das fast nichts. Bei einem Vielnutzer einer KI-Funktion können 30 zusätzliche Tage 30 Tage Modellaufrufe ohne Umsatz bedeuten. Bemiss die Verschiebung am Ausfall, nicht an der Entschuldigung, die du gern aussprechen würdest.

Die Provisionskosten bei Apple

Apple zahlt im ersten Jahr bezahlten Dienstes eines Abonnenten 70 % jeder Verlängerung aus, danach 85 %. Laut Apples Abo-Seite werden Tage aus Verlängerungsverschiebungen nicht zu den Tagen bezahlten Dienstes gezählt. Eine Verschiebung um 30 Tage schiebt den Wechsel dieses Abonnenten auf 85 % also um 30 Tage hinaus. Wenn du im App Store Small Business Program bist, bekommst du ohnehin schon 85 %, und diese Kosten fallen nicht an.

Die Rückbuchungskosten bei Google Play

Bei Bestellungen nach dem 3. August 2026 kostet eine Rückbuchung, die der Karteninhaber gewinnt, einen Entwickler bei Google Play den Kaufpreis abzüglich der Servicegebühr von Play, zuzüglich der Bankgebühren. Ein Ausfall ist genau die Art von Ereignis, die einen verärgerten Kunden zu seiner Bank treibt. Ein Aufschub, der ihn vorher erreicht, ist günstiger als ein Streitfall, den du nicht kippen kannst.

Wann eine Verschiebung nicht das richtige Werkzeug ist

Der Kauf war kein Abo

Verschiebungen des Verlängerungsdatums gelten nur für Abos. Wenn ein Ausfall ein Verbrauchsgut oder eine einmalige Freischaltung beschädigt hat, liefere den Artikel erneut aus. Wenn Apple dazu einen CONSUMPTION_REQUEST sendet, melde, was passiert ist. Apples Feld deliveryStatus hat dafür einen eigenen Wert, UNDELIVERED_SERVER_OUTAGE, und laut Apple muss jeder Status außer DELIVERED mit consumptionPercentage gleich 0 gesendet werden.

Der Kunde hat beide Apple-Verschiebungen schon verbraucht

Apples Obergrenze liegt bei zwei Verschiebungen pro Kunde in 365 Tagen. Zwei Ausfälle in einem Jahr brauchen beide auf, und beim dritten hast du über den Store nichts mehr anzubieten. Halte fest, wie viele Verschiebungen jede originalTransactionId schon genutzt hat, damit dich die FAILURE-Benachrichtigungen der Massenanfrage nicht überraschen.

Der Kunde ist im Gratis-Test

Apple verschiebt kein Abo in einem kostenlosen Angebotszeitraum. Ein Testnutzer hat kostenlose Tage verloren, keine bezahlten, das Erstattungsrisiko ist also gering. Wenn du es wiedergutmachen willst, kostet eine In-App-Nachricht weniger als jeder API-Aufruf.

Eine Checkliste für den nächsten Ausfall

• Protokolliere, wann der Ausfall begann und endete und welche Produkte und Regionen er betraf.
• Wähle eine Anzahl Tage, die die verlorene Zeit abdeckt. Nutze bei Apple Grundcode 3 und bleib zwischen 1 und 90.
• Sende bei Apple eine Massenanfrage pro productId, eingegrenzt mit storefrontCountryCodes, wenn nur einige Regionen betroffen waren.
• Achte auf RENEWAL_EXTENSION FAILURE und versuche jede einzelne erneut mit dem Endpoint für einzelne Abos.
• Geh bei Google Play die aktiven Kauf-Tokens durch, lies jedes etag, lass zuerst mit validateOnly laufen und schiebe dann wirklich auf.
• Informiere Abonnenten bei Google Play selbst über die zusätzliche Zeit, denn Google tut es nicht.
• Aktualisiere das Ablaufdatum der Berechtigungen anhand von RENEWAL_EXTENDED und SUBSCRIPTION_DEFERRED, nicht anhand deiner eigenen Datumsrechnung.
• Führe Nutzungslogs pro Konto, damit deine Nachweise bereitliegen, falls trotzdem eine Erstattungsanfrage oder Rückbuchung kommt, und zwar innerhalb von 12 Stunden für Apple und 24 Stunden für Google.