Verpasste Erstattungsbenachrichtigungen können Sie die einzigen Erstattungen kosten, gegen die Sie Einspruch erheben dürfen. Beide Stores lassen Sie sie zurückholen, wenn Sie rechtzeitig nachsehen

Verpasste Erstattungsbenachrichtigungen sind der leise Weg, auf dem ein Entwickler die beiden einzigen Erstattungsentscheidungen verliert, bei denen er mitreden darf. Apples CONSUMPTION_REQUEST und die Chargeback-Prüfung von Google Play beginnen beide mit einer Benachrichtigung, und beide laufen auf einer kurzen Uhr: 12 Stunden bei Apple, 24 Stunden bei Google. Ist Ihr Server beim Eintreffen der Nachricht ausgefallen, langsam oder falsch konfiguriert, wartet der Store nicht auf Sie. Er entscheidet mit dem, was er schon hat.

Die gute Nachricht: Kein Store wirft die Nachricht beim ersten Fehlschlag weg. Apple wiederholt die Zustellung und führt einen Verlauf über 180 Tage, den Sie abfragen können. Google veröffentlicht über Pub/Sub, das nicht bestätigte Nachrichten tagelang aufbewahrt. Die schlechte Nachricht: Die Wiederholungszeiten passen nicht zu den Antwortfenstern, und einer der beiden Abläufe hat überhaupt keine Wiederherstellungs-API.

Wie die Stores Erstattungsbenachrichtigungen zustellen

Apple sendet App Store Server Notifications direkt an eine HTTPS-URL, die Sie in App Store Connect festlegen. Google ruft Ihren Server nicht direkt auf. Es veröffentlicht Echtzeit-Entwicklerbenachrichtigungen in einem Google Cloud Pub/Sub-Topic, und Ihr Abo auf diesem Topic schickt sie entweder per Push an Ihren Endpunkt oder wartet, bis Ihr Server sie abholt.

Was Apple als Fehlschlag wertet

Apples Dokumentation ist eindeutig. Antworten Sie mit einem Status von 200 bis 206, ist die Zustellung erledigt. Antworten Sie mit 40x oder 50x, wiederholt Apple. Auch jeden anderen Code wertet Apple als erfolglos. Jeder Versuch wird mit einem sendAttemptResult protokolliert, und die Werte lesen sich wie eine Checkliste echter Ausfälle: TIMED_OUT, TLS_ISSUE, CIRCULAR_REDIRECT, NO_RESPONSE, PREMATURE_CLOSE, UNSUCCESSFUL_HTTP_RESPONSE_CODE und einige mehr. Bei TIMED_OUT rät Apple selbst zu prüfen, ob Ihr Server Nachrichten synchron verarbeitet.

Was Google als Fehlschlag wertet

Bei einem Push-Abo ist ein Erfolgscode Ihres Endpunkts die Bestätigung. Bei einem Pull-Abo muss Ihr Server jede abgeholte Nachricht bestätigen, sonst stellt Pub/Sub sie erneut zu. Die Standardfrist für die Bestätigung beträgt 10 Sekunden, das Maximum 600 Sekunden. Googles RTDN-Leitfaden nennt noch eine Regel, die man wiederholen sollte: Eine Benachrichtigung sagt nur, dass sich etwas geändert hat. Den vollständigen Kaufstatus holen Sie weiterhin über die Google Play Developer API.

Warum Apples Wiederholungsplan nicht zum 12-Stunden-Fenster passt

Apples Wiederholungsintervalle zählen ab dem vorherigen Versuch, nicht ab dem ersten. Addiert ergibt sich diese Zeitleiste für eine einzelne V2-Benachrichtigung, an der Ihr Server immer wieder scheitert.

Apple verlangt eine Antwort innerhalb von 12 Stunden nach Erhalt des CONSUMPTION_REQUEST. Ist Ihr Server bei der ersten Zustellung und beim Wiederholungsversuch eine Stunde später nicht erreichbar, kommt der nächste Versuch 13 Stunden nach dem ersten. Apple sagt nicht, ob eine Anfrage, die erst bei einer Wiederholung ankommt, neue 12 Stunden bekommt. Die vorsichtige Lesart: Die Uhr startet mit dem ersten Versuch. Wiederholungen allein retten also keine Anfrage, die Sie um mehr als eine Stunde verpasst haben.

Wiederholt Apple nach einem HTTP 400?

Laut Dokumentation ja. Apple nennt 40x und 50x als die Codes, die eine Wiederholung auslösen. Im März 2026 berichtete ein Entwickler in Apples Foren, dass die Wiederholungen nach 400-Antworten offenbar aufhörten, und schrieb dann, dass die Zustellungen ein bis zwei Tage später wieder liefen. Apple bat um einen Bericht über Feedback Assistant. Nehmen Sie das dokumentierte Verhalten als Regel und Ihr eigenes Monitoring als Beweis.

Verpasste App Store-Benachrichtigungen mit Get Notification History wiederherstellen

Get Notification History liefert die Benachrichtigungen der Version 2, die Apple in einem von Ihnen gewählten Zeitraum an Ihren Server zu senden versucht hat. Jeder Datensatz enthält die vollständige signierte Nutzlast, Sie können ihn also an denselben Handler geben wie eine Live-Benachrichtigung. Jeder Datensatz enthält außerdem ein Array sendAttempts mit bis zu sechs Einträgen, einem für den ersten Versuch und je einem für die fünf Wiederholungen.

• startDate und endDate sind Pflicht, und startDate muss in der Produktion innerhalb der letzten 180 Tage liegen, in der Sandbox innerhalb der letzten 30 Tage.
• Setzen Sie onlyFailures auf true, um nur die Benachrichtigungen zu erhalten, die Ihren Server nicht erreicht haben, plus die, die Apple noch wiederholt.
• Filtern Sie nach einem notificationType, etwa CONSUMPTION_REQUEST oder REFUND, oder nach einer transactionId für einen einzelnen Kunden, aber nicht nach beidem in derselben Anfrage.
• Jeder Aufruf liefert bis zu 20 Datensätze. Rufen Sie mit dem paginationToken weiter auf, solange hasMore true ist, und senden Sie jedes Mal denselben Request-Body.

Ein Vorbehalt ist für Erstattungen wichtig. Laut Apple spiegeln Verlaufsdatensätze den Kaufstatus zum Zeitpunkt der ersten Sendung wider, nicht den heutigen. Ein wiederhergestellter REFUND ist also eine Tatsache aus der Vergangenheit. Bevor Sie den Zugang entziehen, prüfen Sie den aktuellen Status über die Endpunkte für Transaktionen oder Abo-Status.

V1-Benachrichtigungen lassen sich so nicht wiederherstellen

Get Notification History deckt nur Version 2 ab. Apple wiederholt V1-Benachrichtigungen dreimal, 6, 24 und 48 Stunden nach dem vorherigen Versuch. Scheitern alle, gibt es keinen Verlauf zum erneuten Abspielen. Ein Grund mehr, jede App, die noch V1 nutzt, auf V2 umzustellen.

Verpasste Erstattungsbenachrichtigungen von Google Play wiederherstellen

Googles Sicherheitsnetz ist Pub/Sub selbst. Solange Ihr Abo existiert, bleibt eine unbestätigte Nachricht für die Aufbewahrungsfrist dort liegen, standardmäßig 7 Tage und bis zu 31 Tage, wenn Sie die Frist erhöhen. Ist Ihr Endpunkt wieder erreichbar, geht die Zustellung weiter. Zwei Einstellungen können das unbemerkt aushebeln.

• Ein Dead-Letter-Topic verschiebt eine Nachricht nach einer festgelegten Zahl fehlgeschlagener Zustellversuche aus Ihrem Abo. Der Standard ist 5, und mit der Standard-Wiederholungsrichtlinie der sofortigen Neuzustellung sind fünf Versuche schnell vorbei. Nutzen Sie eines, behalten Sie das Dead-Letter-Topic im Blick wie einen zweiten Posteingang.
• Ein Abo ohne Abonnentenaktivität, also ohne offene Verbindungen, aktive Pulls oder erfolgreiche Pushes, läuft standardmäßig nach 31 Tagen ab. Ein Endpunkt, der einen Monat lang defekt bleibt, kann das Abo selbst verlieren, samt allem, was darin wartet.

Stornierte Erstattungen haben eine 30-Tage-Absicherung

Für bereits erfolgte Erstattungen ist die Voided Purchases API die Pull-basierte Absicherung. Sie listet stornierte Käufe der letzten 30 Tage auf, bis zu 1.000 pro Seite, mit einem Kontingent von 6.000 Abfragen pro Tag und 30 Abfragen in jedem 30-Sekunden-Zeitraum pro App. Übergeben Sie type 1, um neben Einmalprodukten auch Abos einzuschließen. Ein täglicher Lauf fängt jede Erstattung auf, die Ihre Benachrichtigungskette verloren hat, und hält Berechtigungen und Umsatzzahlen korrekt.

Chargeback-Prüfungen haben keine

Eine PendingRefundReviewNotification ist anders. Sie enthält das pendingRefundToken, das Sie an orders.reviewrefund übergeben müssen, und Sie haben ab Erhalt 24 Stunden, um Ihre Erstattungspräferenz und Nutzungsnachweise zu senden. Google speichert Ihren ersten Aufruf und ignoriert alle weiteren. Googles Dokumentation beschreibt keinen Endpunkt, der offene Prüfungen auflistet. Geht diese Pub/Sub-Nachricht verloren, gehen Ihre Nachweise für diesen Chargeback mit ihr verloren.

Was eine verpasste Erstattungsbenachrichtigung in Geld kostet

Eine verpasste Benachrichtigung zu einer bereits endgültigen Erstattung kostet Sie Buchhaltung. Sie finden sie später in der Voided Purchases API oder in Get Notification History, entziehen den Zugang, wenn Ihre Richtlinie das vorsieht, und Ihre Berichte holen auf. Lästig, aber billig.

Eine verpasste Benachrichtigung in einem der beiden anfechtbaren Abläufe kostet echtes Geld, weil der Store ohne Ihre Nachweise entscheidet. Bei Apple fällt die Erstattungsentscheidung dann ohne Ihre Verbrauchsdaten. Bei Google Play kostet Sie ein verlorener Chargeback für Bestellungen ab dem 3. August 2026 den Kaufpreis abzüglich der Servicegebühr von Play, plus die Chargeback-Gebühr der Bank des Käufers. Google übernimmt nur die eigene Servicegebühr.

Und das Geld, das Sie für die Bereitstellung des Kaufs ausgegeben haben, war schon weg, bevor der Streit begann.

• Rechenleistung: GPU- und Serverzeit hinter jeder Generierung, jedem Rendering und jeder Modellantwort, die der Käufer bereits genutzt hat.
• API-Aufrufe: Anfragen an Drittanbieter, die beim Absenden abgerechnet wurden, oft pro Aufruf.
• Speicher: Dateien und Medien, die der Käufer erstellt hat und die weiter auf Ihrer Hosting-Rechnung stehen.
• Auszahlungen: Umsatzanteile, die für diesen Verkauf bereits an Creator, Affiliates oder Partner geflossen sind.

Nichts davon kommt zurück, wenn eine Erstattung durchgeht. Die Nachweise, die Sie in diesen 12 oder 24 Stunden senden, sind Ihr einziger Hebel, und eine verpasste Benachrichtigung nimmt ihn Ihnen.

Eine Wiederherstellungsroutine, die hält

• Zuerst bestätigen. Speichern Sie die rohe Nutzlast, geben Sie einen Erfolgscode zurück und verarbeiten Sie sie danach in einer Warteschlange.
• Fragen Sie Apples Get Notification History alle paar Minuten mit onlyFailures nach CONSUMPTION_REQUEST ab, damit ein Ausfall nur Minuten des 12-Stunden-Fensters kostet.
• Lassen Sie täglich einen Durchlauf von Get Notification History mit onlyFailures über die letzten Tage für alle Typen laufen und spielen Sie die Funde erneut ab.
• Rufen Sie täglich die Voided Purchases API mit type 1 für jede Google Play-App auf und gleichen Sie das Ergebnis mit den bereits erfassten Erstattungen ab.
• Halten Sie bei Pub/Sub die Nachrichtenaufbewahrung bei 7 Tagen oder mehr, alarmieren Sie beim Dead-Letter-Topic, falls Sie eines haben, und alarmieren Sie, wenn sich nicht zugestellte Nachrichten stauen.
• Testen Sie den gesamten Weg auch in der Produktion. Apples Sandbox sendet jede Benachrichtigung einmal ohne Wiederholungen, und Request a Test Notification zusammen mit Get Test Notification Status zeigt genau, wie Ihr Server geantwortet hat.

RefundHalt empfängt die Benachrichtigungen beider Stores für Sie und beantwortet CONSUMPTION_REQUEST und Chargeback-Prüfungen automatisch innerhalb ihrer Fristen. So müssen nicht Sie die Uhr im Blick behalten.