Ein Kunde bittet Apple um eine Rückerstattung. Zwölf Stunden später schließt sich auf Ihrem Server ein Zeitfenster – und die meisten Teams haben nie erfahren, dass es offen war.
Dieses Zeitfenster gehört zu Apple CONSUMPTION_REQUEST – einer Benachrichtigung, die der App Store sendet, wenn er während der Prüfung einer Rückerstattungsanfrage Informationen von Ihnen möchte. Es ist keine Rückerstattung. Es ist keine Entscheidung. Die endgültige Entscheidung über die Rückerstattung trifft in jedem Fall Apple. Die Benachrichtigung gibt Ihnen lediglich eine begrenzte Gelegenheit zu beschreiben, was mit dem Kauf tatsächlich passiert ist.
Sie richtig zu behandeln ist ein Backend-Problem, kein Support-Problem. Die Benachrichtigung muss ankommen, die Transaktion muss identifizierbar sein, der Einwilligungsstatus muss bekannt sein, und eine Antwort muss rechtzeitig rausgehen.
Dieser Artikel erklärt, was die Benachrichtigung bedeutet, was Apple heute abfragt (die Feldliste ist deutlich kürzer als früher) und wie Sie einen Workflow darum herum aufbauen. Den größeren Zusammenhang liefert unser Leitfaden zur Verwaltung von App Store-Rückerstattungen.
Das Wichtigste in Kürze
• CONSUMPTION_REQUEST bedeutet, dass Apple während der Prüfung einer Rückerstattung Informationen anfordert. Es ist keine Rückerstattungsbenachrichtigung.
• Die endgültige Entscheidung über die Rückerstattung trifft Apple. Ihre Antwort ist nur einer von mehreren Faktoren.
• Der aktuelle Endpoint erwartet fünf Felder, drei davon Pflicht – statt zwölf in der älteren Version.
• Die Einwilligung ist Pflicht. Apple lehnt Anfragen ab, bei denen customerConsented nicht true ist.
• Apple erwartet eine Antwort innerhalb von 12 Stunden nach der Benachrichtigung.
• Weil das Zeitfenster kurz ist und die Benachrichtigungen zu jeder Tageszeit eintreffen, eignet sich dieser Schritt besser für Automatisierung als für einen manuellen Prozess.
Was ist Apple CONSUMPTION_REQUEST?
CONSUMPTION_REQUEST ist eine App Store Server Notification, die Ihnen mitteilt, dass ein Kunde Apple um eine Rückerstattung gebeten hat und dass der App Store Sie einlädt, Verbrauchsinformationen (Consumption Information) zu diesem Kauf zu senden.
Der Apple Consumption Request für Entwickler existiert wegen einer Informationslücke. Apple sieht die Transaktion, das Konto und die Kaufhistorie. Was in Ihrer App passiert ist, sieht Apple nicht – ob der Inhalt geliefert wurde, ob er funktioniert hat, wie intensiv der Kunde ihn tatsächlich genutzt hat. Sie schon.
Eines ist sie nicht: ein Veto. Eine Antwort blockiert keine Rückerstattung, und Apple sagt ausdrücklich, dass eine Reihe von Faktoren abgewogen wird.
Wie funktioniert Apple CONSUMPTION_REQUEST?
Der Ablauf sieht so aus:
Kunde beantragt eine Rückerstattung
↓
Apple beginnt mit der Prüfung der Anfrage
↓
CONSUMPTION_REQUEST trifft an Ihrem Notifications-Endpoint ein
↓
Sie verifizieren die Benachrichtigung und identifizieren die Transaktion
↓
Sie prüfen die Einwilligung und sammeln echte Nutzungsdaten
↓
Sie senden Verbrauchsinformationen, sofern die Voraussetzungen erfüllt sind
↓
Apple entscheidet über die Rückerstattung
↓
REFUND oder REFUND_DECLINED trifft ein; Sie aktualisieren den Status
Wichtig: Beim aktuellen Endpoint von Apple kann eine Rückerstattungsanfrage für jeden Produkttyp diese Benachrichtigung auslösen – Consumable, Non-Consumable, nicht verlängerbares Abo oder automatisch verlängerbares Abo. Ältere Dokumentation und die meisten Drittanbieter-Artikel beschreiben sie noch als auf Consumables und automatisch verlängerbare Abos beschränkt. Wenn Ihr Handler auf dieser Basis nach Produkttyp filtert, verwirft er Anfragen.
Welche Informationen fordert Apple von Entwicklern an?
Weniger als früher. Genau hier liegen die meisten bestehenden Anleitungen falsch, deshalb lohnt sich Präzision. Apples aktueller Endpoint Send Consumption Information erwartet fünf Felder – drei Pflichtfelder, zwei optionale.
Feld | Erforderlich | Was das für Sie bedeutet |
customerConsented | Ja | Muss true sein. Andernfalls lehnt Apple die Anfrage ab. |
deliveryStatus | Ja | Ob Ihre App einen funktionierenden Kauf erfolgreich ausgeliefert hat. |
sampleContentProvided | Ja | Ob der Kunde vor dem Kauf Beispielinhalte erhalten hat. |
consumptionPercentage | Nein | Wie viel vom Kauf verbraucht wurde, in Milliunits. |
refundPreference | Nein | Ihr bevorzugtes Ergebnis: vollständig gewähren, ablehnen oder anteilig erstatten. |
Über zwei Einschränkungen stolpern viele. Wenn deliveryStatus etwas anderes als delivered ist, muss consumptionPercentage null sein, sonst schlägt die Anfrage fehl. Und Milliunits sind keine Prozent – halb verbraucht heißt 50000, nicht 50.
Die optionale Rückerstattungspräferenz ist neuer, und es lohnt sich, sie zu verstehen. Sie können angeben, ob Sie die Rückerstattung lieber vollständig gewährt, abgelehnt oder anteilig erstattet hätten. Es ist eine Präferenz, keine Anweisung – Apple wägt sie mit allem anderen ab, und das Ergebnis kann von Ihrem Wunsch abweichen.
Wenn Apple eine anteilige Rückerstattung genehmigt, kommt der widerrufene Anteil im Transaktions-Payload zurück. Ihre Entitlement-Logik muss also möglicherweise einen teilweisen Widerruf verarbeiten können, statt jede Rückerstattung als Alles-oder-nichts zu behandeln.
Warum braucht Apple Verbrauchsinformationen?
Weil Apple über etwas entscheidet, das es nur teilweise sehen kann.
Apple weiß, was gekauft wurde, wann, von welchem Konto und wie die Historie dieses Kontos aussieht. Apple weiß nicht, ob Ihr Server die Coins ausgeliefert hat, ob das freigeschaltete Feature funktioniert hat oder ob der Kunde das Produkt intensiv genutzt hat, bevor er sein Geld zurückverlangte. Dieser Kontext liegt in Ihren Systemen.
Der CONSUMPTION_REQUEST-Ablauf bei Apple-Rückerstattungen ist Apples Weg, diesen Kontext vor der Entscheidung einzuholen. Und genau deshalb zählt Genauigkeit mehr als Überzeugungsarbeit. Die Daten beschreiben, was passiert ist. Sie sind kein Plädoyer, und sie so zu behandeln birgt ein reales Risiko ohne verlässlichen Nutzen.
So antworten Entwickler auf CONSUMPTION_REQUEST
Acht Schritte. Der größte Teil der Arbeit passiert, bevor überhaupt eine Anfrage eintrifft.
1. Benachrichtigung empfangen
App Store CONSUMPTION_REQUEST-Benachrichtigungen treffen an der Server-URL ein, die Sie für App Store Server Notifications V2 konfiguriert haben. Fehlt dieser Endpoint, ist er nicht verifiziert oder fällt er unbemerkt aus, erreicht Sie die Anfrage nie. Apples Dokumentation zu App Store Server Notifications beschreibt die Einrichtung und das Payload-Format.
2. Benachrichtigung verifizieren
Benachrichtigungen kommen als signierte JWS-Payloads an. Verifizieren Sie die Signatur gegen Apples Zertifikatskette, bevor Sie auf irgendetwas darin reagieren, und prüfen Sie, ob die Bundle-ID zu Ihrer App passt. Ein unverifizierter Endpoint, der alles akzeptiert, was ihm geschickt wird, ist eine Einladung für Dritte, Ihre Refund-Logik zu steuern.
3. Transaktion identifizieren
Der dekodierte Payload enthält die Transaktions-IDs. Sie brauchen einen gespeicherten Kaufdatensatz, mit dem Sie sie abgleichen können. Kein Datensatz, kein Lookup – und keine Möglichkeit, etwas Sinnvolles zum Verbrauch zu sagen.
4. Transaktion dem richtigen Nutzer zuordnen
Sie können die Nutzung eines Kunden erst beschreiben, wenn Sie wissen, um welchen Kunden es geht. Genau für diese Zuordnung gibt es appAccountToken: eine UUID, die Ihre App beim Kauf anhängt und die im Notification-Payload zurückkommt. Ohne sie landen Teams beim Abgleich über Zeitstempel und Heuristiken – langsam und unzuverlässig, genau dann, wenn Geschwindigkeit zählt.
5. Geltende Einwilligungsanforderungen prüfen
Apple ist hier eindeutig: Sie müssen eine gültige Einwilligung einholen, bevor Sie Daten eines Kunden weitergeben, und das Einholen ist Ihre Verantwortung, nicht Apples. Die Benachrichtigung enthält kein Einwilligungs-Flag, Sie müssen es also aus Ihren eigenen Daten wissen.
Hat der Kunde nicht eingewilligt, lautet Apples Vorgabe: gar nicht antworten. Die Anfrage mit consent auf false zu senden funktioniert nicht – der App Store lehnt sie ab. Apple stellt außerdem klar, dass der App Tracking Transparency-Prompt nicht der Mechanismus dafür ist; es handelt sich um eine separate Einwilligung, die Sie in Ihrer App einholen.
6. Echte Nutzungsdaten sammeln
Ziehen Sie Lieferstatus und Verbrauch aus Ihren tatsächlichen Datensätzen. Wenn Ihr Server ein Consumable-Guthaben führt, wissen Sie bereits, wie viel ausgegeben wurde. Wenn eine Feature-Freischaltung fehlgeschlagen ist, wissen das Ihre Logs ebenfalls. Schätzen Sie nicht – ein erfundener Verbrauchswert ist eine falsche Angabe an Apple, gesendet unter einer Einwilligung, die Sie für korrekte Daten eingeholt haben.
7. Die passenden Informationen senden
Antworten Sie mit einem PUT an den Consumption-Endpoint und verwenden Sie dabei die ursprüngliche Transaktions-ID aus der Benachrichtigung. Werten Sie die Fehlerantworten aus, statt nach dem Prinzip „Fire and Forget“ vorzugehen: Validierungsfehler liefern HTTP 400 mit spezifischen Fehlertypen, und ein still fehlgeschlagener Aufruf sieht genauso aus wie ein erfolgreicher, wenn niemand nachsieht.
8. Ergebnis protokollieren
Protokollieren Sie die Anfrage, die Transaktion, was Sie gesendet haben, wann Sie es gesendet haben und wie Apple am Ende entschieden hat. Dieser Datensatz erlaubt es Ihnen, Wochen später eine Support-Frage zu beantworten, Muster über Rückerstattungen hinweg zu erkennen und zu bestätigen, dass Ihr Entitlement-Status stimmt. Wenn eine Rückerstattung eintrifft, entziehen Sie den Zugriff nach der Rückerstattung – und seien Sie bereit, ihn wiederherzustellen, falls Apple die Entscheidung später revidiert.
Was passiert, wenn Entwickler den CONSUMPTION_REQUEST verpassen?
Nichts Dramatisches, und genau das ist Teil des Problems.
Die Antwort zu verpassen bedeutet, dass Sie die zusätzlichen Informationen nicht liefern, die Apple Ihnen in diesem Workflow zu übermitteln erlaubt hat. Apple entscheidet trotzdem. Die Rückerstattung kann weiterhin genehmigt oder abgelehnt werden, auf Basis der Informationen, die Apple bereits hat. Es gibt keinen Fehler, keinen Alarm und kein erkennbares Signal, dass etwas übersprungen wurde.
Die Gründe fürs Verpassen sind ganz gewöhnlich. Die Benachrichtigung kommt um 2 Uhr nachts. Der Entwickler, der den Handler betreut, ist nicht da. Der Transaktions-Lookup zieht sich, weil die ID in einem System liegt und die Nutzungsdaten in einem anderen. Jemand sieht es am Montag, lange nachdem das Zeitfenster geschlossen ist.
Warum manuelle CONSUMPTION_REQUEST-Bearbeitung schwierig ist
Jede Einschränkung in diesem Workflow spricht gegen manuelle Bearbeitung.
Benachrichtigungen kommen rund um die Uhr. Das Zeitfenster beträgt 12 Stunden. Jede Anfrage braucht einen Transaktions-Lookup, eine Nutzerzuordnung, eine Einwilligungsprüfung, eine Verbrauchsberechnung, einen signierten API-Aufruf und ein protokolliertes Ergebnis – sieben Schritte, keiner davon interessant, alle mit Zeitlimit.
Bei einer Anfrage pro Woche ist das lästig. Bei dreißig pro Tag ist es ein Vollzeitjob – einer, der bei guter Ausführung nichts produziert und bei verspäteter Ausführung stille Verluste.
Wie Automatisierung den Refund-Workflow verändert
Automatisierung verschafft Ihnen keinen Einfluss auf Apple. Das lohnt sich zu wiederholen, weil viel Marketing das Gegenteil suggeriert. Apples Entscheidung bleibt Apples Entscheidung.
Was Automatisierung leistet: Sie macht Ihre Seite konsistent. Benachrichtigungen werden überwacht und verifiziert. Relevante Anfragen werden vom Rest des Streams getrennt. Transaktionen werden Konten zugeordnet. Antwortdaten werden aus echten Datensätzen zusammengestellt, Fristen werden verfolgt, Antworten werden übermittelt und protokolliert, und Ergebnisse fließen in Entitlement-Updates ein.
Keiner dieser Schritte erfordert Urteilsvermögen. Alle erfordern Aufmerksamkeit im richtigen Moment – und das kann Software besser als Menschen.
Was sollte Software für App Store Refund Management leisten?
Wenn Sie Software für das App Store Refund Management bewerten, lautet die entscheidende Frage, ob sie genau die oben genannten Lücken schließt.
Sie sollte App Store Server Notifications überwachen und verifizieren, damit Events nicht in einem ausgefallenen Endpoint verschwinden. Sie sollte CONSUMPTION_REQUEST-Events separat verfolgen, da sie anders behandelt werden müssen als Rückerstattungsergebnisse. Sie sollte Transaktionen Konten zuordnen, denn dort geht die manuelle Zeit verloren. Sie sollte Antwortfenster verfolgen, denn das ist die Frist, die verpasst wird.
Darüber hinaus: Workflows für Verbrauchsdaten, die den Einwilligungsstatus respektieren, eine durchsuchbare Rückerstattungshistorie, Ergebnisverfolgung, Entitlement-Synchronisation inklusive teilweisem Widerruf und Reporting, das klar genug ist, um Muster zu zeigen. Entscheidend ist die Abdeckung des Workflows, nicht die Länge der Feature-Liste.
Wo diese Regeln dokumentiert sind
Drei Apple-Quellen decken alles Obige ab. Lesen Sie sie direkt – dieser Bereich hat sich kürzlich geändert, und viele Sekundärinhalte beschreiben eine ältere Version der API.
Send Consumption Information – der aktuelle Endpoint. Behandelt die Einwilligungspflicht, das 12-Stunden-Fenster, den Request-Body mit fünf Feldern und die Tatsache, dass Verbrauchsinformationen für alle Produkttypen gelten. Gegen diesen Endpoint sollten Sie für Standard-In-App-Käufe bauen.
App Store Server Notifications – wie Benachrichtigungen Ihr Backend erreichen, das signierte Payload-Format und die Benachrichtigungstypen, darunter CONSUMPTION_REQUEST, REFUND und REFUND_DECLINED.
Send Consumption Information V1 – der frühere Endpoint mit dem Request-Body aus zwölf Feldern, den manche Teams noch angebunden haben. Apples eigener Hinweis auf dieser Seite verweist Standard-In-App-Käufe auf den aktuellen Endpoint und beschränkt V1 auf Käufe über die Advanced Commerce API. Nützlich, um herauszufinden, welchen Endpoint Ihre Integration nutzt – nicht als Ziel für neue Implementierungen.
Fazit
CONSUMPTION_REQUEST ist nicht Apples Rückerstattungsentscheidung. Es ist eine kurze, zeitlich begrenzte Gelegenheit, Apple mitzuteilen, was Ihre Systeme wissen und Apples nicht.
Ein Workflow, der das zuverlässig bewältigt, braucht einen verifizierten Notifications-Endpoint, identifizierbare Transaktionen, zuordenbare Kunden, eine tatsächlich eingeholte Einwilligung, echte Nutzungsdaten, eine Antwort innerhalb des Zeitfensters und Ergebnisse, die gut genug protokolliert sind, um anschließend Entitlements zu aktualisieren.
Wenn Sie nach dem Lesen nur eines tun: Prüfen Sie, welchen Endpoint Ihre Integration aufruft. Wenn sie für Standard-In-App-Käufe noch zwölf Felder an den V1-Pfad sendet, ist das die Lücke, die Sie zuerst schließen sollten.
Wenn das Refund-Volumen die manuelle Bearbeitung übersteigt
Sobald Rückerstattungen so häufig werden, dass das manuelle Beobachten von Benachrichtigungen nicht mehr realistisch ist, kann ein dediziertes System die Events überwachen, Antworten innerhalb des Zeitfensters vorbereiten und übermitteln, Ergebnisse verfolgen und Entitlements synchron halten. RefundSensor automatisiert die Entwicklerseite dieses Workflows – nicht Apples Entscheidung, nur den Teil, für den Sie verantwortlich sind.
Häufig gestellte Fragen
Es ist eine App Store Server Notification, die Ihrem Server mitteilt, dass ein Kunde eine Rückerstattung beantragt hat und Apple möglicherweise Verbrauchsinformationen wünscht. Es ist keine Rückerstattungsentscheidung.
Apple sendet ihn, nachdem ein Kunde eine Rückerstattung beantragt hat und während Apple die Anfrage prüft. Er kann für verschiedene App Store-Produkttypen gelten.
Ihr Server empfängt und verifiziert die Benachrichtigung, identifiziert Transaktion und Kunde, prüft die Einwilligung und sendet die erforderlichen Verbrauchsinformationen innerhalb des Antwortfensters an Apple.
Verifizieren Sie die Benachrichtigung, prüfen Sie die Einwilligung des Kunden, liefern Sie korrekte Nutzungs- und Lieferdaten, übermitteln Sie diese an Apple und dokumentieren Sie Antwort und endgültiges Ergebnis.
Apples aktuelle Dokumentation nennt ein Antwortfenster von 12 Stunden. Entwickler sollten vor der Implementierung die neuesten Anforderungen von Apple prüfen.
Es sind Informationen darüber, wie der Kunde den Kauf genutzt hat. Je nach aktuellem Endpoint können sie Einwilligung, Lieferstatus, Beispielinhalte, Verbrauchsdaten und ein bevorzugtes Rückerstattungsergebnis umfassen.
Nein. Apple trifft die endgültige Entscheidung. Entwickler können Verbrauchsinformationen liefern und eine Rückerstattungspräferenz angeben, aber die endgültige Entscheidung liegt bei Apple.
Ja. Entwickler können die Verifizierung von Benachrichtigungen, den Transaktionsabgleich, Einwilligungsprüfungen, die Datenaufbereitung, die Fristenverfolgung und die Protokollierung von Antworten automatisieren.
