Wenn Sie in den letzten Jahren irgendwo über CONSUMPTION_REQUEST gelesen haben, haben Sie vermutlich eine Liste mit zwölf Feldern gesehen: Kontoalter, Gesamtkaufwert in Dollar, Spielzeit, Plattform und so weiter.
Diese Liste gehört zur älteren Version des Endpoints. Apples aktueller Endpoint nimmt fünf Felder entgegen, drei davon Pflicht, und deckt mehr Produkttypen ab als das Original. Viele produktive Integrationen sind noch gegen die alte Struktur gebaut.
Dies ist also ein Rundgang durch das, was die Benachrichtigung tatsächlich ist, was Apple heute zurückhaben möchte und wie Sie einen Antwortpfad aufbauen, der Bestand hat
Das Wichtigste in Kürze
• CONSUMPTION_REQUEST ist eine Benachrichtigung, die während einer Rückerstattungsprüfung Informationen anfordert. Sie ist keine Rückerstattung und keine Entscheidung.
• Apple trifft die Rückerstattungsentscheidung. Ihre Antwort ist einer der Faktoren, die einfließen.
• Der aktuelle Endpoint nimmt fünf Felder entgegen, drei davon Pflicht, und deckt alle Produkttypen ab.
• Die Einwilligung des Kunden ist zwingend erforderlich. Apple lehnt Anfragen ab, bei denen die Einwilligung nicht bestätigt ist.
• Apple erwartet eine Antwort innerhalb von 12 Stunden nach der Benachrichtigung.
• Es gibt zwei Versionen des Endpoints. Prüfen Sie, welche Ihre Integration aufruft.
Was ist Apple CONSUMPTION_REQUEST?
Apple CONSUMPTION_REQUEST ist eine App Store Server Notification, die Ihrem Server mitteilt, dass ein Kunde eine Rückerstattung beantragt hat, und Sie einlädt, Consumption-Informationen zu diesem Kauf zu senden. Sie trifft an der von Ihnen konfigurierten Notification-URL ein, enthält die zugehörige Transaktion und gibt Ihnen ein begrenztes Zeitfenster für die Antwort.
Sie ist keine Rückerstattungsbenachrichtigung. Wenn sie eintrifft, ist noch nichts entschieden Apple befindet sich mitten in der Prüfung der Anfrage und sammelt Kontext, bevor sie abgeschlossen wird. Für Entwickler ist die praktische Bedeutung eng gefasst: Auf Ihrem Backend ist gerade eine Aufgabe gelandet, sie hat eine Frist, und sie benötigt Daten, die nur Ihre Systeme besitzen.
Warum sendet Apple eine CONSUMPTION_REQUEST?
Weil Apple nur die Hälfte der Transaktion sehen kann.
Apple weiß, was gekauft wurde, wann, von welchem Konto und wie die Historie dieses Kontos aussieht. In Ihre App hineinsehen kann Apple nicht ob die Münzen gutgeschrieben wurden, ob die Freischaltung funktioniert hat oder wie viel der Kunde genutzt hat, bevor er sein Geld zurückverlangt hat.
„Consumption“ bedeutet hier, wie weit der Kunde mit dem Gekauften gekommen ist. Ein Abonnement, das drei Wochen lang täglich genutzt wurde, und eines, das nie geöffnet wurde, sehen für Apple identisch aus. Für Sie nicht.
Die Grenzen sollten klar sein. Apple genehmigt oder lehnt nicht allein aufgrund eines Consumption-Werts ab. Die Informationen fließen in eine Entscheidung ein, die mehrere Faktoren abwägt, und ein hoher Consumption-Prozentsatz ist kein Ablehnungsknopf.
Wie funktioniert Apple CONSUMPTION_REQUEST?
Der Ablauf sieht so aus:
Der Kunde stellt eine Rückerstattungsanfrage
↓
Apple beginnt mit der Rückerstattungsprüfung
↓
CONSUMPTION_REQUEST trifft an Ihrem Notification-Endpoint ein
↓
Sie verifizieren die Benachrichtigung und identifizieren die Transaktion
↓
Sie prüfen die Einwilligung und sammeln Nutzungsdaten
↓
Sie senden Consumption-Informationen, sofern die Voraussetzungen erfüllt sind
↓
Apple wägt die Informationen ab
↓
Apple trifft die Rückerstattungsentscheidung
↓
Sie verfolgen den resultierenden Transaktionsstatus
Eine Einschränkung. Apples aktuelle Dokumentation beschreibt diese Benachrichtigung im Zusammenhang mit Rückerstattungsanfragen für alle Produkttypen, also breiter, als ältere Dokumentation nahelegte. Apple gibt jedoch keine Garantie, dass in jedem Fall eine eintrifft. Bauen Sie daher einen Handler, der antwortet, wenn eine Anfrage eintrifft, statt Logik, die davon ausgeht, dass immer eine kommt.
Welche Informationen fordert Apple von Entwicklern an?
Apples aktueller Send Consumption Information-Endpoint nimmt fünf Felder entgegen. Drei sind Pflicht, zwei optional.
Feld | Pflicht | Bedeutung |
customerConsented | Ja | Muss true sein. Andernfalls lehnt Apple die Anfrage ab. |
deliveryStatus | Ja | Ob Ihre App einen funktionierenden Kauf geliefert hat, und falls nicht, warum. |
sampleContentProvided | Ja | Ob der Kunde Inhalte vor dem Kauf ausprobieren konnte. |
consumptionPercentage | Nein | Wie viel verbraucht wurde, in Milliunits (50% sind 50000). |
refundPreference | Nein | Vollständig gewähren, ablehnen oder anteilig erstatten — Ihre Präferenz, keine Entscheidung. |
Zwei Validierungsregeln sind Stolperfallen. Wenn der Lieferstatus etwas anderes als „delivered“ ist, muss der Consumption-Prozentsatz null sein, sonst schlägt die Anfrage fehl. Und Milliunits sind keine Prozent: halb verbraucht entspricht 50000.
Die Rückerstattungspräferenz ist das neueste Element und wird am ehesten missverstanden. Sie können Apple mitteilen, dass Sie die Rückerstattung bevorzugt vollständig gewährt, abgelehnt oder anteilig erstattet sehen möchten, und Apple wägt das zusammen mit allem anderen ab. Das Ergebnis kann abweichen. Wird eine anteilige Rückerstattung genehmigt, kommt der widerrufene Anteil im Transaktions-Payload zurück, Ihre Berechtigungslogik muss also mit einem teilweisen Widerruf umgehen können.
Der Versionsunterschied, den Sie prüfen sollten
Apple dokumentiert zwei Versionen dieses Endpoints, und die Benennung ist leicht misszuverstehen. Send Consumption Information V1 ist die frühere Version mit dem Zwölf-Felder-Body, den die meisten Drittartikel noch beschreiben. Apples eigener Hinweis auf dieser Seite verweist Standard-In-App-Käufe stattdessen auf den aktuellen Endpoint und beschränkt V1 auf Käufe über die Advanced Commerce API.
| Aktueller Endpoint | V1-Endpoint |
Request-Felder | 5 (3 Pflicht) | 12 |
Produkttypen | Alle vier Typen | Verbrauchbar und automatisch verlängerbares Abonnement |
Verwendung für | Standard-In-App-Käufe | Käufe über die Advanced Commerce API |
Wenn Ihre Integration aus der Zeit vor der Änderung stammt, fangen Sie hier an.
Was sind Consumption-Informationen?
Consumption-Informationen sind die Daten, die Sie an Apple senden und die beschreiben, was nach dem Kauf mit dem Produkt passiert ist: ob es geliefert wurde, ob der Kunde es vorher ausprobieren konnte und wie viel davon er genutzt hat.
Sie sind wichtig, weil sie der einzige Teil des Bildes sind, den Apple nicht sehen kann. Bei einer Abo-App beschreiben sie, ob der Kunde den Dienst nach dem Kauf genutzt hat. Bei einem verbrauchbaren Produkt, wie viel des Guthabens ausgegeben wurde. Bei einem nicht verbrauchbaren Produkt, ob die Freischaltung funktioniert hat.
Das entscheidende Wort ist „korrekt“. Es handelt sich um Daten, für deren Weitergabe Sie eine Einwilligung eingeholt haben und die aus Ihren Aufzeichnungen stammen. Es ist kein Argument, das Sie konstruieren, und sie in Richtung eines gewünschten Ergebnisses zu verzerren, birgt ein echtes Risiko ohne verlässlichen Nutzen.
Wie sollten Entwickler auf CONSUMPTION_REQUEST reagieren?
Neun Schritte, und der Großteil der Arbeit liegt vor dem Eintreffen der ersten Anfrage.
1. Benachrichtigung empfangen
Anfragen treffen an der URL ein, die Sie für App Store Server Notifications V2 festgelegt haben. Apples Dokumentation zu App Store Server Notifications behandelt Einrichtung und Payload-Struktur. Ein falsch konfigurierter Endpoint bedeutet, dass die Anfrage Sie nie erreicht, und zwar unbemerkt.
2. Benachrichtigung validieren
Payloads sind signiert. Verifizieren Sie sie gegen Apples Zertifikatskette und bestätigen Sie die Bundle-ID, bevor Sie auf irgendetwas darin reagieren.
3. Zugehörige Transaktion identifizieren
Entnehmen Sie die Transaktionskennungen dem dekodierten Payload und gleichen Sie sie mit Ihren Kaufdatensätzen ab. Kein gespeicherter Datensatz, keine Zuordnung und keine Grundlage, um Consumption zu beschreiben.
4. Prüfen, ob die Einwilligung eine Antwort erlaubt
Apple verlangt eine gültige Einwilligung des Kunden, bevor Sie dessen Daten weitergeben, und das Einholen liegt in Ihrer Verantwortung. Die Benachrichtigung enthält kein Einwilligungs-Flag, Sie müssen es also aus Ihren eigenen Aufzeichnungen wissen. Apple stellt außerdem klar, dass der App-Tracking-Transparency-Dialog nicht der Mechanismus dafür ist es handelt sich um eine separate Einwilligung, die in Ihrer App eingeholt wird. Liegt keine Einwilligung vor, lautet Apples Vorgabe, nicht zu antworten. Unser Beitrag zu appAccountToken und der Abwehr von Apple-Rückerstattungen behandelt die Identifikationsseite, die diese Zuordnung erst möglich macht.
5. Relevante Consumption-Informationen sammeln
Lesen Sie Lieferstatus und Nutzung aus Ihren eigenen Systemen. Wenn Sie ein Guthaben für verbrauchbare Produkte verfolgen, existiert die Zahl bereits. Wenn eine Freischaltung fehlgeschlagen ist, wissen das Ihre Logs.
6. Unterstützte Antwort vorbereiten
Stellen Sie die Pflichtfelder zusammen, ergänzen Sie die optionalen dort, wo Sie echte Werte haben, und prüfen Sie zuerst die Validierungsregeln.
7. Innerhalb von Apples Zeitfenster einreichen
Senden Sie ein PUT an den Consumption-Endpoint mit der ursprünglichen Transaktionskennung aus der Benachrichtigung.
8. Antwort protokollieren
Speichern Sie, was Sie wann gesendet haben und was zurückkam. Eine Einreichung, die an der Validierung gescheitert ist, sieht genauso aus wie eine erfolgreiche, wenn Sie das Ergebnis nicht festgehalten haben.
9. Endgültiges Rückerstattungsergebnis verfolgen
Apple sendet die Entscheidung als separate Benachrichtigung. Halten Sie sie zur Transaktion und zum Kunden fest.
Wie lange haben Entwickler Zeit zu antworten?
Apples aktuelle Dokumentation verlangt eine Antwort innerhalb von 12 Stunden nach Erhalt der Benachrichtigung.
Zwölf Stunden klingen großzügig, bis Sie bedenken, wann Benachrichtigungen eintreffen. Anfragen kommen nachts, am Wochenende, an Feiertagen, und die Uhr hält nicht an. Eine Anfrage, die freitags um 23 Uhr eintrifft, ist vor Montag abgelaufen.
Apple sagt nicht, dass ein verpasstes Zeitfenster automatisch bedeutet, dass die Rückerstattung gewährt wird, und es wäre falsch, das zu behaupten. Was es bedeutet, ist einfacher: Sie haben Informationen nicht geliefert, die Apple berücksichtigt hätte, und die Entscheidung wird ohne sie getroffen.
Was passiert, nachdem ein Entwickler geantwortet hat?
Apple nimmt die Informationen in seine Prüfung auf und entscheidet. Das Ergebnis sehen Sie als Benachrichtigung: gewährt, abgelehnt oder später rückgängig gemacht, wenn Apple eine zuvor genehmigte Rückerstattung zurücknimmt.
Ab hier liegt die Arbeit bei Ihnen. Widerrufen Sie die Berechtigung bei einer gewährten Rückerstattung, stellen Sie sie bei einer Rücknahme wieder her und behandeln Sie den anteiligen Fall, bei dem nur ein Teil der Transaktion zurückkommt.
Auch der Abonnementstatus braucht Aufmerksamkeit, da ein erstatteter Zeitraum das Abonnement in der Regel beendet, statt es weiterlaufen zu lassen, und die Rückerstattung in den Umsatzaufzeichnungen für den richtigen Zeitraum landen sollte.
Die Aufteilung lässt sich klar benennen: Sie liefern Informationen, Apple entscheidet, und anschließend halten Sie Ihre Systeme mit dem Ergebnis synchron. Drei getrennte Verantwortlichkeiten, und nur die mittlere liegt bei Apple.
Warum ist die manuelle Bearbeitung von CONSUMPTION_REQUEST schwierig?
Jede Einschränkung in diesem Workflow arbeitet gegen eine Person, die ihn manuell ausführt.
Benachrichtigungen treffen rund um die Uhr ein. Das Zeitfenster beträgt 12 Stunden. Jede Anfrage erfordert eine Signaturprüfung, eine Transaktionssuche, eine Nutzerzuordnung, eine Einwilligungsprüfung, eine Nutzungsberechnung, einen authentifizierten API-Aufruf und ein protokolliertes Ergebnis. Nichts davon ist schwer. Alles davon ist zeitlich begrenzt und repetitiv, und es erzeugt nichts Sichtbares, wenn es gut läuft.
Skalierung verschlimmert es: mehrere Apps, Transaktionsdaten in einem System und Nutzungsdaten in einem anderen, lückenhafte Antwortprotokolle, ein Berechtigungsstatus, der unbemerkt vom Transaktionsstatus abdriftet. Das heißt nicht, dass manuelle Bearbeitung Sie immer Geld kostet, aber das Risiko ist real und summiert sich still.
Kann Apple CONSUMPTION_REQUEST automatisiert werden?
Ja, und die Struktur des Workflows spricht dafür, da fast jeder Schritt deterministisch ist.
Automatisierung kann Benachrichtigungen überwachen und verifizieren, Consumption-Anfragen gezielt erkennen, Transaktionen Konten zuordnen, die Antwort aus Ihren Aufzeichnungen zusammenstellen, das Zeitfenster im Blick behalten, einreichen, das Ergebnis protokollieren, den Ausgang festhalten und Berechtigungsaktualisierungen anstoßen.
Was sie nicht kann, ist Apples Entscheidung beeinflussen. Kein Tool ändert das, und jedes Produkt, das etwas anderes andeutet, beschreibt den Prozess falsch. Was Automatisierung ändert, ist, ob Ihre Seite konsistent und innerhalb des Zeitfensters erledigt wird.
Wie RefundSensor Entwicklern bei Apple-Rückerstattungsworkflows hilft
App Store-Rückerstattungsmanagement ist die Kategorie, zu der diese Arbeit gehört. RefundSensor deckt die Entwicklerseite ab: Überwachung von Apples rückerstattungsbezogenen Workflows, Abwicklung des unterstützten CONSUMPTION_REQUEST-Antwortpfads und Bündelung von Rückerstattungsereignissen und -ergebnissen an einem Ort, statt sie über Dashboards und Tabellen zu verstreuen.
In der Praxis gehen Antworten innerhalb des Zeitfensters raus, ohne dass jemand Benachrichtigungen beobachtet, und Rückerstattungsdatensätze bleiben korrekt, wenn das Volumen wächst. Es verhindert keine Rückerstattungen und kann keine bestimmte Entscheidung von Apple garantieren. Es reduziert die manuelle Überwachung und die verpassten Schritte.
Wo diese Regeln dokumentiert sind
Drei Apple-Quellen belegen alles oben Gesagte. Lesen Sie sie direkt und schauen Sie regelmäßig nach — dieser Bereich hat sich kürzlich geändert, und Sekundärquellen hinken hinterher.
Send Consumption Information — der aktuelle Endpoint. Die Einwilligungspflicht, das 12-Stunden-Fenster, der Request-Body mit fünf Feldern und die abgedeckten Produkttypen. Bauen Sie für Standard-In-App-Käufe gegen diesen.
Send Consumption Information V1 — der frühere Endpoint mit dem Zwölf-Felder-Body. Nützlich, um herauszufinden, auf welcher Version Ihre Integration läuft, und für Teams, die die Advanced Commerce API nutzen.
App Store Server Notifications — wie Benachrichtigungen Ihr Backend erreichen, das signierte Payload-Format und die Benachrichtigungstypen einschließlich CONSUMPTION_REQUEST und der Rückerstattungsergebnisse.
Falls das noch manuell erledigt wird
Ein 12-Stunden-Fenster und Benachrichtigungen, die um 3 Uhr morgens eintreffen, passen schlecht zu einem Prozess, der davon abhängt, dass jemand ein Dashboard prüft.
Wenn Ihr Team an diesem Punkt steht, übernimmt RefundSensor die Entwicklerseite dieser Workflows: Überwachung der Benachrichtigungen, Vorbereitung und Einreichung der Antworten innerhalb des Zeitfensters und Verfolgung der Ergebnisse bis in Ihre Berechtigungsdaten.
Häufig gestellte Fragen
Eine App Store Server Notification, die Ihrem Server mitteilt, dass ein Kunde eine Rückerstattung beantragt hat und dass Apple Sie einlädt, Consumption-Informationen zu diesem Kauf zu senden. Sie ist keine Rückerstattungsbenachrichtigung und keine Entscheidung. Apple entscheidet separat und nutzt Ihre Antwort als einen von mehreren Faktoren.
Weil Apple nicht in Ihre App hineinsehen kann. Apple kennt die Transaktion und die Kontohistorie, aber nicht, ob Inhalte geliefert wurden, ob sie funktioniert haben oder wie viel der Kunde genutzt hat. Dieser Kontext liegt in Ihren Systemen, und Apple fragt ihn ab, bevor die Prüfung abgeschlossen wird.
Ein Kunde beantragt eine Rückerstattung, Apple beginnt mit der Prüfung, und eine Benachrichtigung erreicht Ihren konfigurierten Endpoint. Sie verifizieren sie, identifizieren die Transaktion, bestätigen die Einwilligung, sammeln Nutzungsdaten und senden Consumption-Informationen innerhalb des Zeitfensters. Apple wägt sie ab, entscheidet und sendet das Ergebnis als separate Benachrichtigung.
Beim aktuellen Endpoint fünf Felder. Drei Pflichtfelder: Einwilligung des Kunden, Lieferstatus und ob Beispielinhalte bereitgestellt wurden. Zwei optionale: wie viel des Kaufs verbraucht wurde und Ihr bevorzugtes Rückerstattungsergebnis. Der frühere V1-Endpoint verlangte zwölf, weshalb ältere Artikel eine deutlich längere Liste beschreiben.
Apples aktuelle Dokumentation beschreibt die Benachrichtigung im Zusammenhang mit Rückerstattungsanfragen für alle Produkttypen, also breiter, als ältere Dokumentation nahelegte. Apple veröffentlicht jedoch keine Garantie für jeden Fall. Bauen Sie daher einen Handler, der antwortet, wenn eine Anfrage eintrifft, statt Logik, die davon abhängt, dass immer eine kommt.
Apples Dokumentation verlangt eine Antwort innerhalb von 12 Stunden nach der Benachrichtigung. Anfragen treffen zu jeder Tageszeit ein, auch am Wochenende, weshalb dieser Schritt bei einem manuellen Prozess am ehesten verpasst wird. Prüfen Sie die aktuelle Anforderung auf Apples Seite, statt sich auf eine ältere Integration zu verlassen.
Sie können sie informieren, nicht steuern. Korrekte Consumption-Daten geben Apple Kontext, der sonst fehlt, und der aktuelle Endpoint erlaubt es Ihnen, eine Rückerstattungspräferenz anzugeben. Apple wägt beides mit anderen Faktoren ab und kann anders entscheiden. Es gibt keinen Mechanismus, mit dem ein Entwickler eine Rückerstattung genehmigen oder ablehnen kann.
Ja. Benachrichtigungen verifizieren, Transaktionen identifizieren, den Einwilligungsstatus prüfen, Daten aus Aufzeichnungen zusammenstellen, das Zeitfenster einhalten, einreichen und Ergebnisse protokollieren sind alles deterministische Schritte. Menschlich bleibt die Gestaltung des Einwilligungsablaufs in Ihrer App und die Entscheidung, wie Ihre Richtlinie zur Rückerstattungspräferenz aussehen soll.
