Es gibt einen Endpunkt, der die komplette App Store refund history eines Kunden zurückgibt, und hier steht, was er liefert

Apple führt für jedes Konto eines Kunden zu Ihrer App eine abfragbare Aufzeichnung jedes gewährten Refunds, und ein Aufruf gibt sie zurück. Der Endpunkt heißt Get Refund History, Teil der App Store Server API, und er liefert Ihnen die vollständige App Store refund history dieses Kunden als Liste signierter Transaktionen. Sie übergeben eine Transaktions-ID, Sie erhalten zurück, was Apple erstattet hat, und Sie gleichen es mit dem ab, was Sie noch aktiviert haben.

Hier ist der Grund, warum sich das lohnt. Ein Refund, den Sie nie sehen, ist ein Refund, für den Sie weiter zahlen. Das Geld ist schon weg, aber das Konto bleibt aktiv, und jede Stunde, in der es das tut, geben Sie weiter für Rechenleistung, Modell-API-Aufrufe, Speicher und jede Auszahlung aus, die an diesen Kunden gebunden ist. Ihre Refund-Benachrichtigungen sollen dies in dem Moment abfangen, in dem es passiert. Get Refund History ist die Rückfallebene für die Fälle, in denen sie es nicht tun, nach einem Ausfall, einem Deploy, der einen Webhook verloren hat, oder einem Support-Fall, bei dem Sie das ganze Bild in einem Aufruf brauchen.

Was der App Store refund history Endpunkt zurückgibt

Sie rufen GET /inApps/v2/refund/lookup/{transactionId} gegen die App Store Server API auf, signiert mit demselben JWT, das Sie für jeden anderen Aufruf verwenden. Die Transaktions-ID im Pfad kann jede beliebige Transaktion des Kunden sein. Apple liest sie als Identität, nicht als Filter, und gibt die erstatteten Käufe dieses Kunden über Ihre gesamte App zurück: Verbrauchsgüter, nicht verbrauchbare Güter, automatisch verlängerbare und nicht verlängernde Abonnements gleichermaßen. Das ältere V1 dieses Endpunkts gab bis zu 50 Refunds in einer einzigen Antwort zurück und ist veraltet. Die aktuelle Version paginiert, sodass Sie Kunden mit langer Historie ohne riesige Nutzlast verarbeiten.

Die Antwort besteht aus drei Feldern

Was eine erstattete Transaktion Ihnen sagt

Jeder Eintrag in signedTransactions ist ein JWS. Verifizieren Sie es gegen Apples Zertifikatskette, dekodieren Sie es, und Sie haben eine gewöhnliche Transaktions-Nutzlast mit ausgefüllten Refund-Feldern. Diese hier sind die, die zählen.

Das revision-Token verhindert, dass Sie die ganze Liste erneut lesen

Der naive Weg, diesen Endpunkt zu nutzen, ist, einen Kunden nachzuschlagen und jedes Mal jede Seite durchzugehen. Das funktioniert, und bei einem Kunden mit fünfzig Refunds sind das fünfzig Zeilen, die Sie bereits kannten, plus die eine neue. Das revision-Token existiert, um diese Verschwendung zu beenden. Jede Antwort trägt ein revision. Wenn hasMore true ist, geben Sie es zurück, um die nächste Seite zu erhalten. Wenn Sie das Ende erreichen, behalten Sie das letzte revision, das Sie gesehen haben.

Was dieser Endpunkt nicht leisten wird

Es gibt eine Erwartung, die Sie fallen lassen sollten, bevor Sie darauf aufbauen. Get Refund History gilt pro Kunde, nicht pro App. Sie können ihn nicht nach jedem Refund fragen, den Ihre App letzte Woche verzeichnet hat. Er beantwortet eine Frage, nämlich welche Refunds dieses Konto hat, und Sie müssen mit einer Transaktions-ID für dieses Konto ankommen, um sie zu stellen. Entwickler stoßen ständig an diese Wand und suchen nach einem app-weiten Refund-Endpunkt, den es nicht gibt.

Die app-weite Sicht liegt woanders. Ihr App Store Server Notifications Strom sendet eine REFUND-Benachrichtigung in dem Moment, in dem Apple jede einzelne gewährt, und Get Notification History lässt Sie diesen Strom, gefiltert auf Refund-Typen, über einen Datumsbereich erneut abspielen. Die Aufteilung ist also klar. Benachrichtigungen und ihre Historie geben Ihnen den app-weiten Strom. Get Refund History gibt Ihnen die maßgebliche Liste eines Kontos, auf Abruf, was genau das ist, was Sie an einem Support-Desk oder nach einem Ausfall brauchen.

Was Sie ein übersehener Refund in Geld kostet

Der Endpunkt ist die Verrohrung. Die Rechnung ist der Grund, warum Sie die Rohre verlegen. Jeder Refund in dieser Liste ist bereits zurückgegebenes Geld, und die einzige Variable, die noch in Ihrer Kontrolle liegt, ist, wie lange Sie weiter für ein Konto zahlen, das nicht mehr zahlt.

Sie zahlen weiter, um ein erstattetes Konto zu bedienen

Der Kaufpreis ist in dem Moment weg, in dem Apple den Refund gewährt. Was weiterläuft, sind die Kosten der Bereitstellung. Für eine App, die pro Nutzer echte Arbeit leistet, sind das Rechenleistung, Modell-API-Aufrufe, Speicher und jede Creator- oder Partnerauszahlung, die an deren Nutzung gebunden ist. Ein erstatteter Kunde, dessen Zugriff Sie nie gekappt haben, ist ein Abonnement, das Sie aus eigener Tasche finanzieren. Der Abgleich gegen Get Refund History und das Entziehen anhand dessen, was Sie finden, ist der Weg, diesen Zähler abzuschalten, wenn eine Benachrichtigung durchgerutscht ist.

Ein Refund-Grund von 1 ist ein getarnter Fehlerbericht

revocationReason kostet Sie doppelt, wenn Sie ihn ignorieren. Die erste Kosten ist der Refund selbst. Die zweite ist jeder künftige Refund aus derselben Ursache. Wenn ein Produkt immer wieder mit revocationReason 1 zurückkommt, einem tatsächlichen oder empfundenen Problem in Ihrer App, reicht Apple Ihnen eine gekennzeichnete Stichprobe dessen, was Kunden dazu bringt, ihr Geld zurückzuverlangen. Werten Sie das nach Produkt aus, und Sie können das Leck stopfen, statt es einen Refund nach dem anderen auszuzahlen.

Es spät zu erwischen schlägt immer noch, es nicht zu erwischen

Ein Chargeback ist bei der Bank endgültig und trägt im anderen Store inzwischen eine Gebühr, die der Entwickler schluckt. Ein App Store Refund ist das nicht. Er ist abgeschlossen, aber die Berechtigung ist Ihre, um sie in dem Moment zu entziehen, in dem Sie es wissen. Selbst ein Refund, den Sie Tage zu spät über diesen Endpunkt finden, ist also wert, gefunden zu werden. Sie können das Geld nicht zurückholen, aber Sie können die Ausgabe stoppen, die noch dahinter lief.

Wie sich das mit Benachrichtigungen und mit Google einfügt

Betrachten Sie die Teile als ein System. Die REFUND-Benachrichtigung ist das Live-Signal, an Ihren Server geschoben, während Apple entscheidet. Get Refund History ist die pull-basierte Quelle der Wahrheit für einen einzelnen Kunden, der Aufruf, den Sie tätigen, wenn der Push fehlgeschlagen ist oder wenn ein Mensch das vollständige Konto vor sich braucht. Auf der Google Play Seite ist die Form dieselbe Idee mit anderen Namen: eine VoidedPurchaseNotification wird in Echtzeit geschoben, und die Voided Purchases API ist die Liste, die Sie ziehen. Beide Stores geben Ihnen einen Strom und ein Buch. Der Fehler ist, nur dem Strom zu vertrauen, denn Ströme brechen ab.

Die Einrichtung auf die RefundHalt Art

Die Schleife ist klein, sobald jedes Teil an seinem Platz ist. Nehmen Sie eine REFUND-Benachrichtigung als Auslöser. Gleichen Sie gegen Get Refund History ab, damit ein verlorener Webhook nie ein erstattetes Konto aktiv lässt. Dekodieren Sie jede Transaktion, verschlüsseln Sie sie über appAccountToken oder transactionId zurück zu Ihrem Nutzer, lesen Sie revocationReason, damit ein Defekt-Refund markiert und nicht nur abgelegt wird, und entziehen Sie die exakte Berechtigung statt des ganzen Kontos. Paginieren Sie mit dem revision-Token, damit Sie neue Refunds lesen, nicht alte.

Das ist der Teil, den RefundHalt für Sie übernimmt. Es lauscht auf die Refund-Benachrichtigungen, greift auf Get Refund History zurück, wenn es die maßgebliche Liste braucht, verifiziert jede signierte Transaktion, entzieht den präzisen Kauf und behält das revision, damit jeder Durchlauf nur liest, was sich geändert hat. Sie bekommen den Zugriff in Sekunden gekappt und eine saubere Aufzeichnung darüber, wer erstattet wurde, wofür und warum, ohne das Polling und die JWS-Verifizierung selbst aufzubauen.