Jemand öffnet „Problem melden“, wählt Ihre App aus und bittet Apple um sein Geld zurück. Apple entscheidet nicht einfach. Es pingt zuerst Ihren Server an, fragt, was Sie über den Kauf wissen, und wartet etwa 12 Stunden auf eine Antwort.
Dieser Ping ist der Apple CONSUMPTION_REQUEST. Viele Teams mit echten IAP-Umsätzen haben noch nie davon gehört. Viele andere haben ihn einmal in ihren Logs gesehen und dort liegen lassen. Wenn das auf Sie zutrifft: Unser
Erklärartikel zum Apple CONSUMPTION_REQUEST behandelt das Was und das Warum. Dieser Beitrag ist der Teil mit dem Antworten. Was Sie senden sollten, was nicht, und was Teams passiert ist, die es versucht haben.
Das Wichtigste in Kürze
Apple sendet einen CONSUMPTION_REQUEST, wenn ein Kunde eine Rückerstattung beantragt. Sie haben etwa 12 Stunden. Danach entscheidet Apple ohne Sie.
Die Antwort besteht aus fünf Feldern. Nicht fünfzig. Fünf.
Ihre Refund-Präferenz ist genau das: eine Präferenz. Apple hat sie schon übergangen und wird es wieder tun.
Keine Einwilligung des Kunden, keine Antwort. Apples Worte, nicht unsere.
Eine App senkte ihre Refund-Rate in etwa zwei Wochen von 3% auf 1.9%, nur indem sie anfing zu antworten. Sie hat Apple nie gebeten, etwas abzulehnen.
Niemand macht das lange von Hand. Das Zeitfenster ist zu kurz, und die Anfragen kommen zu ungünstigen Zeiten.
Was ist ein Apple CONSUMPTION_REQUEST also genau?
Es ist eine Server-Benachrichtigung, eine von vielen, die Apple über App Store Server Notifications V2 verschickt. Diese wird ausgelöst, wenn jemand eine Rückerstattung für einen In-App-Kauf beantragt. Früher galt das nur für Consumables. Seit der WWDC24 deckt sie auch Auto-Renewable Subscriptions ab, und dort steckt das meiste Geld.
Im Payload: die signierte Transaktion, die Produkt-ID und der Grund, den der Kunde ausgewählt hat. Apples
Doku zu consumptionRequestReason listet fünf auf: UNINTENDED_PURCHASE, FULFILLMENT_ISSUE, UNSATISFIED_WITH_PURCHASE, LEGAL, OTHER.
Was Sie nicht finden werden: einen Namen oder eine Apple ID. Nur eine Transaktions-ID. Daraus „das ist Nutzerin 48213, und sie hat die App seit dem Kauf 40 Mal geöffnet“ zu machen, ist Ihre Aufgabe, und das funktioniert nur, wenn Sie beim Checkout einen appAccountToken mitgegeben haben. Wir haben einen
ganzen Beitrag zum appAccountToken geschrieben, weil so viele Teams ihn auslassen.
Apple fragt, Sie antworten, Apple entscheidet. So sehen Apple-Rückerstattungsanfragen für Entwickler aus.
So antworten Sie auf einen Apple CONSUMPTION_REQUEST
Sie senden per PUT einen kleinen JSON-Body an Apples Send Consumption Information Endpoint, mit der Transaktions-ID im Pfad. Dieser Body ist die Apple Consumption Information, die das Refund-System liest.
Customer Consented kommt zuerst. True oder false. Wenn false: Stopp. Senden Sie nichts. Apples Doku sagt, dass Sie ohne Einwilligung überhaupt nicht antworten sollen. Seltsam, aber so lautet die Regel.
Dann der Delivery Status. DELIVERED, wenn es geklappt hat. Wenn nicht, gibt es UNDELIVERED-Varianten für Qualitätsproblem, falscher Artikel, Serverausfall und Sonstiges.
Sample Content Provided ist ein Ja oder Nein dazu, ob der Kunde vor dem Kauf testen konnte. Kostenlose Testphase: ja. Content-Vorschau: ja. Eine Paywall mit drei Stichpunkten: eher nein.
Consumption Percentage bringt viele ins Stolpern. Der Wert wird in Milliunits angegeben, 100000 bedeutet also vollständig verbraucht und 50000 die Hälfte. Bei Auto-Renewable Subscriptions lassen Sie das Feld weg. Apple leitet das aus dem Abrechnungszeitraum ab.
Und zum Schluss Refund Preference. DECLINE, GRANT_FULL oder GRANT_PRORATED. Optional. Und die einzige Stelle, an der Sie sagen dürfen, was Sie möchten.
Eine Antwort für ein Münzpaket, das bereits ausgegeben wurde:
Apple antwortet mit einem 202 und sonst nichts. Kein Urteil. Ein Apple-Engineer schrieb 2021 in den Developer Forums: Ein 202 bedeutet, Ihre Daten „werden berücksichtigt“. Das ist das ganze Versprechen.
Senden Sie nicht auf alles DECLINE
Ich weiß, es ist verlockend. Widerstehen Sie.
Lesen Sie zuerst den Grund. FULFILLMENT_ISSUE heißt: Prüfen Sie Ihre Delivery-Logs. Wenn der Kauf wirklich nicht angekommen ist, senden Sie den passenden UNDELIVERED-Status mit GRANT_FULL und machen weiter. Diesen Fall gewinnen Sie nicht, und der Versuch lässt Ihre späteren DECLINEs schwächer aussehen.
Bei UNINTENDED_PURCHASE geht es um die Nutzung. Gekauft um 9:02, Rückerstattung um 9:05 beantragt, null Sessions dazwischen? Wahrscheinlich ein Fehltipp. Lassen Sie es durchgehen. Eine Woche lang täglich genutzt? DECLINE, mit Ihrer echten Consumption-Zahl dazu.
Bei UNSATISFIED_WITH_PURCHASE zahlt sich Sample Content Provided aus. Testphase gehabt und 80% genutzt? Ablehnen. Kaum geöffnet? GRANT_PRORATED ist ein fairer Mittelweg.
Bei LEGAL und OTHER senden Sie korrekte Daten und lassen die Präferenz weg, es sei denn, Ihre Aufzeichnungen machen die Entscheidung offensichtlich.
Ein DECLINE auf Basis von 95% Consumption und einer kostenlosen Testphase ist eine starke Antwort. Ein DECLINE bei etwas, das neunzig Sekunden lang genutzt wurde, wirkt reflexhaft.
Was Teams, die das gemacht haben, tatsächlich erlebt haben
Dipsea ist eine Audio-App, die RevenueCat im September 2024 gekauft und zum Testen des eigenen Refund-Handlers genutzt hat. Am 23. Oktober begannen sie, Consumption Requests zu beantworten, mit der Präferenz „Apple entscheiden lassen“. Kein DECLINE. Nur Daten. In etwa 15 Tagen sank die Refund-Rate von konstant 3% auf 1.9%.
Sie haben das Diagramm veröffentlicht.Für mich ist das der nützlichste Datenpunkt zu diesem Thema. Die Daten allein haben die Zahl bewegt.
Dann die andere Seite. Im März 2024 schrieb ein Spielestudio in den Apple Developer Forums, dass sie Consumption Info senden und Apple trotzdem „fast alle“ Rückerstattungen für Münzen genehmigt, die Spieler bereits ausgegeben hatten. Consumables sind der schwierige Fall. Sind die Münzen weg, kann Apple sie nicht zurückholen. Wenn Sie das Guthaben nach der REFUND-Benachrichtigung nicht selbst entziehen, verlieren Sie das Geld und die Münzen.
Und im Mai 2025 füllte sich ein Thread auf r/iOSProgramming mit RevenueCat-Nutzern, die „always prefer declining“ eingestellt hatten und plötzlich sahen, dass jede Rückerstattung genehmigt wurde. RevenueCat sprach von einer Richtlinienänderung auf Apples Seite. Was auch immer die Ursache war, es beendete eine alte Debatte. Refund Preference ist kein Schalter. Pauschales DECLINE ist ein Muster, und Apple kann es ausblenden.
So fangen Sie sich einen 400 ein
Apple ist streng, was den Body angeht. Diese Fehler sehen wir immer wieder.
Die Sache mit den Milliunits. Jemand liest „Percentage“, sendet 100 und hat Apple damit mitgeteilt, dass der Kunde ein Zehntel Prozent genutzt hat. Der Bereich geht von 0 bis 100000.
Ein Prozentwert ungleich null bei einem nicht gelieferten Artikel. Wenn Delivery Status nicht DELIVERED ist, muss Consumption Percentage 0 sein, sonst wird die Anfrage abgewiesen.
Irgendein Prozentwert bei einer Auto-Renewable Subscription. Apple hat dafür einen eigenen Fehler. Lassen Sie das Feld weg.
Der falsche Key. Dieser Aufruf braucht einen In-App Purchase Key, erstellt in App Store Connect unter „Users and Access“, dann „Integrations“. Nicht den App Store Connect API Key, auch wenn beide identisch aussehen. Mit dem falschen bekommen Sie einen 401 und eine Stunde Zweifel an Ihrem JWT.
Einwilligung überspringen. Kein HTTP-Fehler, sondern ein Compliance-Fehler. Bringen Sie die Formulierung in Ihre Nutzungsbedingungen, bevor das live geht.
Testen Sie zuerst in der Sandbox. Ein Haken: Apples Testing-Doku gibt Ihnen dort fünf Minuten, nicht zwölf Stunden. Braucht Ihr Server sechs, ignoriert der Test Ihre Daten. Um eine Ablehnung zu erzwingen, wählen Sie im Refund-Sheet „Other“ und tippen DECLINE ein.
Wie Entwickler App Store Refund-Anfragen bearbeiten, wenn es viele sind
Meistens, indem sie sie nicht bearbeiten, wenn wir ehrlich sind. Die Anfrage kommt um 3 Uhr nachts. Oder am Samstag. Oder an einem Feiertag, wenn die eine Person, die die Pipeline versteht, offline ist. Zwölf Stunden vergehen. Apple entscheidet nach den Angaben des Kunden.
Wie Sie als Entwickler mit Apple-Rückerstattungsanfragen umgehen, läuft auf eine Entscheidung hinaus. Die Kette selbst bauen (JWS verifizieren, Nutzer nachschlagen, Nutzung abrufen, Prozentwert berechnen, JWT erzeugen, Endpoint aufrufen, loggen, wiederholen) und sie für immer am Laufen halten. Oder eine Apple Refund-Management-Software anschließen, die das bereits erledigt.
Refund Sensor ist eine Option aus der zweiten Gruppe. Sie fügen unsere Notification-URL in App Store Connect ein, verbinden den Key, und die Antworten gehen innerhalb von Sekunden raus. Über alle Apps hinweg, die aktuell darauf laufen, wurden 77% der infrage kommenden Anfragen verteidigt, bei rund $33 geschütztem Umsatz pro Fall. Nichts Raffiniertes passiert dabei. Eine Antwort mit echten Daten geht jedes Mal raus, vor der Deadline. Wenn Sie sich lieber umsehen möchten, erklärt unser Leitfaden zu Apple Refund-Management-Tools
, welche Fragen Sie stellen sollten.
Deshalb kommt Apple Refund-Automatisierung für Entwickler immer wieder zur Sprache. Zwölf Stunden, jede Anfrage, jede Woche, das ist keine Aufgabe für Menschen. Was auch immer Sie wählen, wählen Sie etwas. Schweigen bedeutet, dass Apple nur eine Seite hört.
Häufig gestellte Fragen
Zwölf Stunden in Production, fünf Minuten in der Sandbox. Beides steht in Apples Doku.
Nein. Apple nennt Ihre Consumption Information „einen von mehreren Faktoren“. Sie verbessert Ihre Chancen. Sie entscheidet nichts.
Auf jede, bei der der Kunde eingewilligt hat, ja. Auch auf die, bei denen Sie GRANT_FULL senden, weil Ihr Server down war. Ehrliche Antworten in den einfachen Fällen sind der Grund, warum Apple Ihren DECLINEs später vertraut.
deliveryStatus und sampleContentProvided, korrekt ausgefüllt. Den Prozentwert lassen Sie weg. Und dann reparieren Sie Ihr Tracking.
Ja. DECLINE und GRANTFULL funktionieren bei jedem Produkttyp. GRANTPRORATED auch, Apple übernimmt bei Auto-Renewable-Abos nur die anteilige Berechnung selbst.
