Apples Send Consumption Information fragt jetzt fünf Felder ab, nicht zwölf, und hier ist jedes einzelne

Die Liste der Fakten, die Apple von Ihnen abfragt, wenn ein Kunde eine Rückerstattung möchte, ist deutlich kürzer geworden. Die Send Consumption Information-Nutzlast, die eine Antwort, die ein Entwickler in eine App Store-Rückerstattungsentscheidung einspeisen darf, hatte früher zwölf Felder. Jetzt hat sie fünf. Apple hat sie rund um die WWDC24 gekürzt und die meisten der alten Fragen zur Kontoprofilierung in zwei einfache Fragen und eine Zahl überführt. Weniger Felder ist keine kleine Änderung. Es verändert, welche Belege Apple gewichtet, und es verändert, bei welchen Feldern Sie sich keinen Fehler leisten können.

Hier ist, warum das Ihre Aufmerksamkeit verdient und nicht bloß eine Schema-Notiz ist. Diese Nutzlast ist der einzige Moment in einer Apple-Rückerstattung, in dem Ihre Version der Geschichte die Entscheidung erreicht. Eine Rückerstattung für Verbrauchsgüter macht Umsätze rückgängig, für deren Lieferung Sie bereits echtes Geld ausgegeben haben, und die fünf Felder sind die Art, wie Sie Apple mitteilen, dass das Produkt geliefert und genutzt wurde. Verpassen Sie das 12-Stunden-Fenster oder füllen Sie ein Feld falsch aus, entscheidet Apple allein auf Grundlage der Kundenreklamation.

Was Send Consumption Information ist

Send Consumption Information ist der App Store Server API-Endpunkt, den Sie aufrufen, nachdem Apple Ihrem Server eine CONSUMPTION_REQUEST-Benachrichtigung gesendet hat. Diese Benachrichtigung bedeutet, dass ein Kunde Apple um eine Rückerstattung für einen In-App-Kauf gebeten hat und Apple Ihre Eingabe möchte, bevor es entscheidet. Sie antworten, indem Sie einen kleinen JSON-Body, den ConsumptionRequest, per PUT an den Endpunkt senden. Apple liest ihn, wägt ihn gegen die Historie des Kunden ab und trifft die Entscheidung. Sie entscheiden nie über die Rückerstattung. Sie liefern Fakten.

Der Body ist die gesamte Schnittstelle. Es gibt kein separates Formular, keinen Einspruch und keine zweite Übermittlung, die zählt. Was auch immer Sie in dieser einen Nutzlast senden, ist Ihr gesamter Fall, sodass die Bedeutung jedes Feldes mehr zählt, als die Feldanzahl vermuten lässt.

Die fünf Felder, die Apple jetzt abfragt

Der aktuelle ConsumptionRequest hat fünf Mitglieder. Drei sind erforderlich und zwei sind optional. Alles, was Apple früher über das Konto des Kunden abfragte, seine Kontodauer, seine gesamten Ausgaben, seine gesamten Rückerstattungen, seine Spielzeit, wurde aus dem entfernt, was Sie senden.

customerConsented ist die Schranke

customerConsented ist ein Boolean, und es ist das Feld, das entscheidet, ob Sie überhaupt etwas senden. Es hält fest, ob der Kunde zugestimmt hat, dass Sie Verbrauchsdaten mit Apple teilen. Apples Vorgabe ist eindeutig: Wenn der Kunde nicht zugestimmt hat, senden Sie die Verbrauchsinformationen nicht. Das ist also kein Feld, das Sie auf true setzen, um Ihren Fall zu stärken. Es spiegelt ein echtes Ja oder Nein wider, das Ihnen bereits vorliegen muss, und ein false hier bedeutet, dass der Rest der Nutzlast nicht gesendet werden sollte.

deliveryStatus ist das Feld, das Rückerstattungen bewegt

deliveryStatus ist ein String-Enum, und es ist der stärkste Hebel, den Sie haben. Es teilt Apple mit, ob Ihre App tatsächlich einen funktionierenden In-App-Kauf geliefert hat. Ein Wert sagt ja. Die anderen vier sagen nein, jeder aus einem anderen Grund, und jeder teilt Apple mit, dass der Kunde eine berechtigte Beschwerde hat.

sampleContentProvided beantwortet eine Fairnessfrage

sampleContentProvided ist ein Boolean. Es hält fest, ob Sie dem Kunden eine kostenlose Probe, eine Testversion oder klare Informationen darüber gegeben haben, was der Kauf bewirkt, bevor er gekauft hat. Ein true hier ist ein kleines Fairnesssignal: Der Kunde hatte die Chance zu wissen, was er kaufte. Es entscheidet nichts für sich allein, aber es ist eines von nur drei erforderlichen Feldern, sodass Apple es eindeutig in jeder Antwort haben möchte.

consumptionPercentage ist jetzt eine Zahl, kein Status

Das ist das Feld, das sich am meisten verändert hat. Die alte Nutzlast hatte consumptionStatus, ein vierstufiges Enum: UNDECLARED, NOT_CONSUMED, PARTIALLY_CONSUMED, FULLY_CONSUMED. Die neue Nutzlast ersetzt es durch consumptionPercentage, eine ganze Zahl gemessen in milliunits. 100,000 milliunits bedeutet, dass der Artikel vollständig verbraucht wurde, also sind 50,000 die Hälfte und 0 unberührt. Eine präzise Zahl schlägt einen Vier-Wege-Eimer, denn sie erlaubt Ihnen zu sagen, dass ein Kunde 90 Prozent eines Guthabenpakets verbraucht hat, statt auf teilweise verbraucht abzurunden.

Ein Vorbehalt, über den viele stolpern. Bei automatisch verlängerbaren Abonnements ermittelt Apple den Verbrauch selbst aus der verstrichenen Zeit, sodass consumptionPercentage für Verbrauchsgüter und nicht verlängerbare Käufe gedacht ist. Senden Sie es, wo es zutrifft, und lassen Sie Apple es ableiten, wo es das nicht tut.

refundPreference benennt eine Präferenz, kein Urteil

refundPreference ist eine optionale Zeichenkette, und hier teilen Sie Apple mit, welches Ergebnis Sie bevorzugen würden. Auch dieses Feld hat seine Form geändert. Das alte Feld war eine Zahl mit Werten wie prefer-grant, prefer-decline und no-preference. Das neue ist eine benannte Zeichenkette mit drei Werten.

Was Apple gestrichen hat und warum es zählt

Der alte ConsumptionRequest hatte zwölf Felder. Sieben davon sind aus dem, was Sie senden, verschwunden. accountTenure, lifetimeDollarsPurchased, lifetimeDollarsRefunded, playTime, userStatus, platform und appAccountToken waren die kontoprofilierende Hälfte der Nutzlast, die Felder, die Sie baten, einen Kunden danach einzuordnen, wie lange er ein Konto hatte, wie viel er ausgegeben hatte, wie viel ihm rückerstattet worden war und wie lange er die App genutzt hatte.

Apple hat sie aus einem beachtenswerten Grund gestrichen. Diese Felder verlangten von Entwicklern, ein Profil des Kunden herauszugeben, und die meisten Entwickler ließen sie entweder undeklariert oder rieten. Die fünf, die bleiben, betreffen den Kauf und die Lieferung, Fakten, die Sie aus Ihren eigenen Systemen tatsächlich überprüfen können. Die Verschiebung geht davon weg, wer der Kunde ist, hin zu dem, was mit diesem konkreten Kauf geschah.

Der Endpunkt und die Uhr

Sie senden die Nutzlast per HTTP PUT an den Send Consumption Information-Endpunkt, adressiert über die Transaktions-ID des strittigen Kaufs: PUT /inApps/v1/transactions/consumption/{transactionId}. Ein Erfolg gibt 202 Accepted zurück, und der Antwort-Body ist leer. Diese leere Antwort ist zu erwarten, kein Fehler. Sie bestätigt, dass Apple Ihre Daten in die Warteschlange gestellt hat, und sagt Ihnen nichts über das schließliche Ergebnis, das später als REFUND- oder REFUND_DECLINED-Benachrichtigung eintrifft.

Die Uhr ist der Teil, den Sie nicht dehnen können. Apple gibt Ihnen 12 Stunden ab dem CONSUMPTION_REQUEST zum Antworten. Nur Ihre erste Antwort wird verwendet, sodass die erste Nutzlast die vollständige und korrekte sein muss. Apple kann den CONSUMPTION_REQUEST für denselben Kauf mehr als einmal senden, aber die Frist ist bei jedem fest, und eine manuelle Prüfung passt über Zeitzonen und Wochenenden hinweg selten in 12 Stunden.

Was ein falsch behandeltes Feld Sie kostet

Das Geld hat das Haus verlassen, bevor es die Rückerstattung tat

Eine Rückerstattung für Verbrauchsgüter ist keine saubere Umkehrung. Bis ein Kunde sein Geld für ein Paket Guthaben oder eine Charge KI-Generierungen zurückverlangt, haben Sie bereits für die Lieferung ausgegeben: GPU-Inferenz bei jeder Anfrage, Modell-API-Aufrufe von Drittanbietern, die pro Token abgerechnet werden, Speicher für alles, was Sie produziert haben, und jede an diese Nutzung gebundene Ersteller- oder Partnerauszahlung. Der Store-Preis geht an den Kunden zurück. Ihre Lieferkosten kommen nicht zu Ihnen zurück. Eine Rückerstattung, die Sie hätten anfechten können, ist also kein Nullsummenereignis, sie ist ein Nettoverlust von allem, was Sie zur Bedienung des Kontos bezahlt haben.

Die fünf Felder sind die Art, wie Sie vermeiden, zweimal zu zahlen

deliveryStatus auf DELIVERED gesetzt und ein hoher consumptionPercentage sind die beiden Fakten, die Apple mitteilen, dass der Kunde das Produkt erhalten und genutzt hat. Sie sind Ihr Beleg, dass die Rechenleistung, die API-Aufrufe und der Speicher alle ihre Arbeit getan haben. Lassen Sie die Nutzlast ungesendet, und Apple erfährt das nie. Es entscheidet auf Grundlage der Kundenreklamation, die Rückerstattung geht eher durch, und Sie tragen sowohl den rückgängig gemachten Umsatz als auch die dahinterstehenden Lieferkosten.

Rückbuchungen sind die schlimmere Tür, und Schweigen weist auf sie hin

Ein Kunde, der über Apples Rückerstattungsablauf keine Zufriedenheit erlangt, kann die Belastung immer noch bei seiner Bank anfechten. Eine Karten-Rückbuchung ist endgültig, sie bringt eine pauschale Streitfallgebühr mit sich, und sie nimmt die Entscheidung aus Apples Händen und Ihren. Den CONSUMPTION_REQUEST gut zu beantworten hält den Streitfall innerhalb von Apples System, wo Sie ein Mitspracherecht haben. Ihn zu ignorieren schiebt Grenzfälle in den einen Kanal, in dem Sie keines haben.

Wie RefundHalt damit umgeht

Die fünf Felder sehen einfach aus, bis Sie sie korrekt ausfüllen müssen, innerhalb von 12 Stunden, bei jedem CONSUMPTION_REQUEST, adressiert an die richtige Transaktion. RefundHalt fängt die Benachrichtigung ab, liest Ihre eigenen Liefer- und Nutzungsaufzeichnungen für diesen Kauf und sendet die Nutzlast automatisch, bevor das Fenster schließt. deliveryStatus spiegelt wider, was Ihre Logs tatsächlich zeigen, consumptionPercentage stammt aus tatsächlicher Nutzung statt aus einer Schätzung, und refundPreference folgt der Richtlinie, die Sie einmal festgelegt haben. Sie erhalten die anfechtbare Rückerstattung mit Belegen geprüft, nicht eine verpasste Frist und eine ohne Sie getroffene Entscheidung.