Apple kann eine bereits gewährte Rückerstattung rückgängig machen, und eine rückgängig gemachte Rückerstattung, die Ihr Server ignoriert, sperrt einen Kunden aus, der bezahlt hat

Eine Rückerstattung ist nicht immer das letzte Wort. Der App Store kann eine bereits gewährte Rückerstattung rückgängig machen, nachdem der Kunde sie angefochten hat, und wenn diese rückgängig gemachte Rückerstattung auf Ihrem Server landet, trägt sie eine einzige Anweisung: Gib den Zugriff zurück. Die meisten Teams verdrahten die einfache REFUND-Benachrichtigung, sperren den Kunden aus und hören dort auf. Sie bauen nie die andere Hälfte. Wenn also die Rücknahme eintrifft, läuft nichts, und ein Kunde, der erneut zahlt, sitzt ausgesperrt vor dem, was er gekauft hat. So funktioniert der vollständige Satz von Rückerstattungsbenachrichtigungen im App Store und bei Google Play, und was jede davon Sie kostet, wenn Sie sie ignorieren.

Der App Store sendet drei Rückerstattungsbenachrichtigungen, nicht eine

Die meiste Rückerstattungsbehandlung ist für ein einziges Ereignis gebaut: Das Geld ist zurückgegangen, sperrt den Kunden aus. Der App Store Server Notifications V2-Feed trägt tatsächlich drei separate Rückerstattungsergebnisse, und sie verlangen drei verschiedene Dinge. Zwei davon ändern, worauf ein Kunde zugreifen kann. Eines davon macht das erste rückgängig. Hier ist der vollständige Satz, in Apples eigenen Worten.

REFUND, die Benachrichtigung, die jedes Team behandelt

Wenn der App Store eine Rückerstattung verarbeitet, sendet er eine REFUND-Benachrichtigung an die von Ihnen konfigurierte URL, und Apples Definition ist schlicht: Sie „gibt an, dass der App Store eine Transaktion für einen verbrauchbaren In-App Purchase, einen nicht verbrauchbaren In-App Purchase, ein automatisch verlängerbares Abonnement oder ein nicht verlängerbares Abonnement erfolgreich erstattet hat“. Sie speichern die erstattete Transaktion, entziehen alles, was sie gekauft hat, und Apple bittet Sie, dem Kunden mit kontextbezogenen Nachrichten in der App mitzuteilen, was sich geändert hat. Das ist die Benachrichtigung, die jeder zuerst verdrahtet, und oft die einzige.

REFUND_DECLINED, die Benachrichtigung, die nichts von Ihnen verlangt

REFUND_DECLINED bedeutet genau das, was sie sagt: „der App Store hat eine Rückerstattungsanfrage abgelehnt“. Der Kunde hat gefragt, Apple hat nein gesagt, und die Transaktion bleibt bestehen. Am Zugriff des Kunden ändert sich nichts, daher tut Ihre Berechtigungslogik hier nichts. Der Wert dieser Benachrichtigung liegt in der Buchführung. Sie schließt den Kreis einer Rückerstattungsanfrage, die Sie vielleicht mit einem CONSUMPTION_REQUEST beantwortet haben, und sie bestätigt, dass der Kunde noch hat, wofür er bezahlt hat. Behandeln Sie sie als Aufzeichnung, nicht als Aktion.

REFUND_REVERSED, die Benachrichtigung, die Teams überrascht

Dies ist die Benachrichtigung, die die meisten Rückerstattungs-Pipelines nie behandeln. Apples Definition ist unmissverständlich: REFUND_REVERSED „gibt an, dass der App Store eine zuvor gewährte Rückerstattung aufgrund eines vom Kunden erhobenen Einspruchs rückgängig gemacht hat. Wenn Ihre App infolge der zugehörigen Rückerstattung Inhalte oder Dienste entzogen hat, muss sie diese wiederherstellen“. Lesen Sie das zweimal. Apple hat dem Kunden eine Rückerstattung gewährt, Sie haben den Zugriff entzogen, dann hat Apple entschieden, dass die Rückerstattung nicht bestehen sollte, und sie zurückgezogen. Die Belastung ist wieder aktiv. Der Kunde hat bezahlt, und wenn Ihr Server nur entziehen kann, bleibt er ausgesperrt. Eine rückgängig gemachte Rückerstattung ist das einzige Rückerstattungsereignis, das Zugriff zurückgibt, und es ist das, für das fast niemand baut.

Was eine rückgängig gemachte Rückerstattung Sie tatsächlich kostet

Eine verpasste Rücknahme ist kein Rundungsfehler. Verfolgen Sie das Geld in beide Richtungen, denn wenn Sie eine der beiden Hälften falsch machen, hat das einen Preis.

Verpassen Sie die Rücknahme, und Sie halten einen zahlenden Kunden ausgesperrt. Apple hat die Belastung wiederhergestellt, der Kunde ist also erneut aus eigener Tasche belastet, und Ihre App verweigert ihm das, was er gekauft hat. Die unmittelbaren Kosten sind Support-Zeit und eine Kulanz-Rückerstattung, die Sie nun vielleicht selbst ausstellen, diesmal ohne zurückkommende Store-Provision, die sie abmildert. Die langsameren Kosten sind die Bewertung und die Abwanderung, und bei Google Play ist genau dieser Frust über die Aussperrung das, was sich in eine Rückbuchung verwandelt.

Verpassen Sie die ursprüngliche Rückerstattung, und Sie bedienen weiterhin einen Kunden, der nichts bezahlt hat. Der Spiegelfehler besteht darin, überhaupt nie zu entziehen. Ein erstatteter Kunde, der weiterhin Bilder generiert, Ihre APIs aufruft und Ihren Speicher füllt, verursacht echte Kosten gegen einen Verkauf, der rückgängig gemacht wurde. Die Rechenleistung, die Drittanbieteraufrufe und der Speicher sind Geld, das Sie bereits ausgegeben haben, und nichts davon kommt mit der Rückerstattung zurück.

• Support-Kosten: ein Mensch, der ein Ticket über einen Zugriff beantwortet, den Ihr eigener Code entfernt und nie wiederhergestellt hat.
• Kulanz-Rückerstattungen: erneutes Ausstellen von Geld an einen Kunden, den Sie zu Unrecht ausgesperrt haben, ohne zurückkommende Store-Provision bei einer manuellen Geste.
• Verschwendete Ausgaben: Rechenleistung, API-Aufrufe und Speicher, die von einem erstatteten Konto verbraucht werden, das Sie nie gesperrt haben.
• Rückbuchungsrisiko: Bei Google Play kann ein Kunde, der sich doppelt belastet fühlt, Einspruch erheben, und ein verlorener Einspruch landet nun bei Ihnen.

Die rückgängig gemachte Rückerstattung und die einfache Rückerstattung sind derselbe Webhook-Feed, der in entgegengesetzte Richtungen zeigt. Behandeln Sie die eine und überspringen Sie die andere, und Sie zahlen an beiden Enden.

Warum Apple eine Rückerstattung rückgängig macht, und wie man revocationReason liest

Eine Rücknahme ist nicht zufällig. Apple knüpft sie an „einen vom Kunden erhobenen Einspruch“, also den Kunden, der die Rückerstattungsentscheidung im Nachhinein anficht. Als die Rückerstattung zum ersten Mal gewährt wurde, trug die Transaktion ein revocationDate und ein revocationReason, und dieser Grund ist es wert, gelesen zu werden, bevor irgendetwas nachgelagert darauf reagiert.

• revocationReason 1: der App Store hat „aufgrund eines tatsächlichen oder vermeintlichen Problems in Ihrer App“ erstattet. Das ist ein Signal über Ihr Produkt, nicht nur über diesen Kunden.
• revocationReason 0: der App Store hat „aus anderen Gründen erstattet, zum Beispiel einem versehentlichen Kauf“. Kein Signal zur App-Qualität angehängt.

Wenn für diese Transaktion ein REFUND_REVERSED eintrifft, wird der Entzug rückgängig gemacht. Ihre Wiederherstellungslogik sollte die ursprüngliche Transaktions-id nachschlagen, bestätigen, dass Sie sie entzogen haben, und die Berechtigung genau so wieder einsetzen, wie sie war.

Google Play sendet keine Rücknahme, daher gleichen Sie stattdessen ab

Das Modell von Google Play ist anders, und der Unterschied ist wichtig, wenn Sie beide Stores über einen einzigen Webhook-Handler laufen lassen. Es gibt kein Google-Äquivalent zu REFUND_REVERSED. Googles Echtzeit-Entwicklerbenachrichtigungen teilen Rückerstattungsereignisse in zwei Nachrichten auf, und Rücknahmen werden durch Abgleich behandelt, nicht durch ein Push.

Die Benachrichtigung über stornierte Käufe

Wenn ein Google-Play-Kauf storniert wird, erhält Ihr Server eine VoidedPurchaseNotification. Sie nennt den purchaseToken und die orderId, einen productType von Abonnement oder Einmalkauf und einen refundType, der entweder eine vollständige Stornierung oder eine mengenbasierte Teilrückerstattung bei Käufen mit mehreren Einheiten ist. Google sagt, dass diese Daten ausreichen, um den richtigen Kauf zu finden und die Berechtigung anzupassen. Für alles Weitere verweist es Sie auf die Voided Purchases API, ein Pull-Modell, das stornierte Bestellungen innerhalb eines von Ihnen abgefragten Zeitstempelbereichs auflistet.

Die Rückbuchungsprüfung und ihre 24-Stunden-Uhr

Rückbuchungen kommen über eine andere Nachricht, die PendingRefundReviewNotification. Wenn ein Kunde eine Belastung bei seiner Bank anficht, sendet Google Play diese Benachrichtigung und startet eine Uhr. Sie haben 24 Stunden, um orders.reviewrefund mit einer Rückerstattungspräferenz und etwaigen Nutzungsnachweisen aufzurufen, damit Google eine unrechtmäßige Rückbuchung in Ihrem Namen anfechten kann. Google erfasst Ihren ersten Aufruf und ignoriert den Rest. Das ist Googles Gegenstück zu Apples CONSUMPTION_REQUEST, das eine Fenster, in dem Ihre Seite eines Einspruchs zählt.

Da es kein Rücknahme-Push gibt, kommt eine Rückbuchung, die Google anficht und gewinnt, nicht als sauberes Wiederherstellungsereignis an. Sie gleichen sie mit der Voided Purchases API und Ihren eigenen Aufzeichnungen ab. Die Lehre ist dieselbe wie im App Store: Eine stornierte Bestellung ist nicht immer endgültig, und Ihr Berechtigungszustand muss sich zurückbewegen können, nicht nur vorwärts.

Wie Sie jede Rückerstattungsbenachrichtigung behandeln, ohne jemanden auszusperren

Sie brauchen keine separaten Pipelines pro Store. Sie brauchen einen Handler, der eine Berechtigung in beide Richtungen bewegen kann und jede Nachricht als möglicherweise dupliziert behandelt.

• Bauen Sie Wiederherstellung, nicht nur Entzug. Schreiben Sie für jeden Pfad, der bei einem REFUND den Zugriff entfernt, die Umkehrung, die ihn bei einem REFUND_REVERSED wiederherstellt, verknüpft mit derselben Transaktions-id.
• Machen Sie es idempotent. Beide Stores können dieselbe Benachrichtigung mehr als einmal zustellen, daher verknüpfen Sie jeden Entzug und jede Wiederherstellung mit der Transaktions- oder orderId und machen Sie eine Wiederholung zu einer Operation ohne Wirkung.
• Lesen Sie den Grund, bevor Sie handeln. Verwenden Sie revocationReason, um eine Rückerstattung wegen App-Qualität von einer versehentlichen zu unterscheiden, und leiten Sie die App-Qualitäts-Fälle an denjenigen weiter, der für die Produktqualität verantwortlich ist.
• Beantworten Sie die Nachweisfenster rechtzeitig. Senden Sie Apples Verbrauchsdaten innerhalb von 12 Stunden nach einem CONSUMPTION_REQUEST und rufen Sie orders.reviewrefund innerhalb von 24 Stunden nach einer PendingRefundReviewNotification auf.
• Speichern Sie jedes Ereignis. Behalten Sie REFUND_DECLINED und die rohen Benachrichtigungen, damit eine später eintreffende Rücknahme der Rückerstattung zugeordnet werden kann, die sie aufhebt.

Nichts davon ändert, ob eine Rückerstattung stattfindet. Es ändert, ob der Kunde auf der anderen Seite einer rückgängig gemachten Rückerstattung jemals bemerkt, dass Ihr Server es falsch gemacht hat.