Wer zum vierten Mal eine Rückerstattung verlangt, ist kein unzufriedener Kunde. Er fährt eine Masche, und das kostet Sie den erstatteten Umsatz plus alles, was Sie für die Erfüllung der Bestellung aufgewendet haben. Apple und Google stellen jeweils ein Identitätsfeld bereit – appAccountToken auf der einen, die obfuscated account ID auf der anderen Seite –, das aus diesen einzelnen Vorfällen ein sichtbares Muster macht.
Die wichtigsten Punkte
Belege von Ihnen erreichen einen Store in genau zwei Situationen: bei Apples CONSUMPTION_REQUEST, der innerhalb von 12 Stunden beantwortbar ist, und bei Google Plays Chargeback Review über die Review Refund API, beantwortbar innerhalb von 24 Stunden. Alles andere wird ohne Sie entschieden.
Bei Apple reist eine von Ihnen erzeugte UUID als appAccountToken mit dem Kauf. StoreKit verknüpft sie fest mit der Transaktion, sodass sich jede spätere Rückerstattung einem eindeutig identifizierbaren Konto in Ihren eigenen Aufzeichnungen zuordnen lässt.
Googles Gegenstück ist eine gehashte Zeichenfolge von maximal 64 Zeichen Länge. Google selbst liest dieses Feld aus, um auffälliges Verhalten zu erkennen, etwa wenn ein einzelnes Konto in kurzer Zeit über eine unplausibel hohe Anzahl von Geräten kauft.
Unverschlüsselte personenbezogene Daten in diesem Google-Feld führen dazu, dass Käufe rundweg blockiert werden. Erforderlich ist ein verschlüsselter Wert oder ein Einweg-Hash. Eine rohe E-Mail-Adresse erfüllt diese Anforderung nicht.
Plays voidedReason unterscheidet friendly_fraud und fraud von einer gewöhnlichen Rückerstattung wegen Meinungsänderung, was Ihnen die Grundlage gibt, Wiederholungstäter in eine Prüfwarteschlange zu schicken, statt den Standardweg aus Rückerstattung und Abhaken zu gehen.
Google gibt an, 2022 betrügerische und missbräuchliche Transaktionen im Wert von mehr als 2 Milliarden US-Dollar verhindert zu haben. Diese Schutzmechanismen funktionieren über Identitätssignale, die es nur gibt, wenn Ihre Käufe sie tatsächlich mitführen.
Zugriff, der eine Rückerstattung überlebt, verbraucht weiterhin Speicher, Rechenleistung und API-Budget, für die Sie nicht mehr bezahlt werden, und wer gezielt Rückerstattungen verlangt, erzeugt genau dieses Ergebnis wiederholt mit Absicht.
Einführung
Rückerstattungen passieren, und eine einzelne davon ist schlicht ein Kostenfaktor. Was das Bild verändert, ist dasselbe Konto, das zum vierten Mal wiederkommt, nachdem es die Ware bei jeder vorherigen Gelegenheit bereits verbraucht hat. Dieses Verhalten ist für Sie nur erkennbar, wenn jede Transaktion einen von Ihnen zugewiesenen Identifikator mitbringt. Beide Plattformen stellen einen solchen bereit. Beide öffnen außerdem ein schmales Zeitfenster zur Reaktion, bevor die Entscheidung feststeht. Wer den Identifikator auslässt oder das Zeitfenster verpasst, kann jemanden, der das System ausnutzt, nicht von einem Erstkunden mit einem echten Anliegen unterscheiden. Was die beiden Fälle trennt und was diese Trennung in Geld wert ist, folgt im Weiteren.
Rückerstattungsmissbrauch ist eigentlich ein Identitätsproblem im Rückerstattungskostüm
Rückerstattungsentscheidungen liegen beim Store. Kunden fragen danach, und in den meisten Abläufen stimmt der Store zu, ohne dass Sie Einfluss nehmen können. Ihr Einfluss liegt woanders: darin festzustellen, ob dieses bestimmte Konto bereits eine Vorgeschichte damit hat, und ob das Gekaufte tatsächlich geliefert und genutzt wurde. Beide Fragen sind Identitätsfragen. Welcher Nutzer steckt hinter dieser Transaktion, und was hat er zuvor getan. Käufe ohne stabile Verknüpfung zu Ihren Nutzerdaten lassen beide Fragen unbeantwortet, sodass jede Rückerstattung ohne Kontext erfolgt.
Das ist die Lücke, die es zu schließen gilt. Die Richtlinien legen die Mechanik fest, und daran können Sie nichts ändern. Die Beweise jedoch müssen Sie selbst zusammentragen, und diese Sammlung beginnt beim Checkout, nicht bei der Rückerstattung.
Zwei Zeitfenster, in denen das, was Sie senden, wirklich zählt
Nur zwei Abläufe behandeln Ihre Eingabe tatsächlich als Eingabe. Fordert ein Kunde eine Rückerstattung für ein Verbrauchsgut oder ein automatisch verlängerndes Abonnement an, löst das Apples CONSUMPTION_REQUEST aus, und Ihre Antwort ist innerhalb von 12 Stunden fällig. Bestreitet ein Kunde eine Abbuchung bei seiner Bank, löst das Google Plays Chargeback Review aus, beantwortbar über die Review Refund API innerhalb von 24 Stunden. Außerhalb dieser beiden Fälle fällt die Entscheidung ohne Sie: Plays 48-Stunden-Selbstbedienungs-Rückerstattung, eine vom Support gewährte Rückerstattung, eine automatische Rückerstattung für einen Kauf, den Sie nie bestätigt haben.
Beide Kanäle werden erheblich schärfer, wenn die Transaktion Ihren Identifikator bereits mitführt. Die an Apple gesendeten Konsuminformationen können appAccountToken neben den Ausgaben und der Historie dieses Kontos enthalten, während Googles Prüfung auf eine obfuscated account ID zurückgreift, die seit Abschluss des Kaufs beobachtet wird. Gibt es keinen Identifikator, gibt es auch keine Historie, die Sie einreichen könnten.
Die beiden Identitätsfelder im Vergleich
Beide Unternehmen sind unter verschiedenen Namen und mit unterschiedlichen Einschränkungen zu nahezu identischen Lösungen gekommen. Beide erlauben es Ihnen, einen Kauf mit einem Wert zu kennzeichnen, der sich auf Ihre eigenen Nutzerdaten zurückführen lässt. Keines ist standardmäßig für Sie aktiviert. Beide sind nutzlos, wenn sie nicht während des laufenden Kaufs gesetzt werden.
Apple: appAccountToken
Erzeugen Sie eine UUID, übergeben Sie sie beim Start des Kaufs, und StoreKit verknüpft sie mit der daraus entstehenden Transaktion. Sie taucht anschließend in den Transaktionsdaten auf, die Ihr Server verifiziert, und erneut in den Konsuminformationen, die Sie während eines CONSUMPTION_REQUEST zurückgeben. Da der Wert von Ihnen selbst stammt, löst er eine Store-Transaktion auf eine Datenbankzeile auf, ohne dass Name oder E-Mail-Adresse beteiligt sind. Nur echte UUIDs werden akzeptiert; alles andere wird abgelehnt. Apple hat inzwischen einen Set-App-Account-Token-Endpunkt bereitgestellt, der das Token auch auf bereits erfolgte Transaktionen schreiben oder aktualisieren kann, einschließlich Angebotscode-Einlösungen und ähnlicher Käufe außerhalb der App.
Google Play: die obfuscated account ID
setObfuscatedAccountId ist Googles Variante, eine optionale Zeichenfolge, die an das kaufende Konto gebunden ist. Googles Dokumentation nennt den Zweck unverblümt: Play nutzt den Wert, um auffälliges Verhalten zu erkennen – als Beispiel wird genannt, wenn viele Geräte innerhalb kurzer Zeit über ein Konto Transaktionen durchführen – und um manche betrügerischen Käufe zu stoppen, bevor sie abgeschlossen werden. Die Obergrenze liegt bei 64 Zeichen, und unverschlüsselte personenbezogene Daten sind untersagt. Wer dort eine rohe E-Mail-Adresse einträgt, bekommt den Kauf blockiert, denn das Feld erwartet einen verschlüsselten Wert oder einen Einweg-Hash. Apps, bei denen ein einzelnes Konto mehrere Profile enthält, erhalten ein zusätzliches Feld, setObfuscatedProfileId.
appAccountToken ist Apples Feld. Es muss eine UUID sein und nichts anderes, Ihr Code setzt es während des Checkouts, und es fehlt, sofern Sie es nicht selbst hinzufügen. Apple nutzt es, um die Transaktion an Ihren Nutzer zu binden, und es taucht erneut in den Transaktions- und Konsum-Payloads auf.
obfuscatedAccountId ist das Feld von Google Play. Es nimmt eine gehashte Zeichenfolge von höchstens 64 Zeichen auf, Ihr Code setzt es während des Checkouts, und auch dieses Feld fehlt standardmäßig. Google speist es in die Erkennung auffälliger Aktivitäten ein und nutzt es, um manche betrügerischen Käufe vor ihrem Abschluss zu stoppen.
Eine Asymmetrie fällt enorm ins Gewicht. Google bietet überhaupt keine Nachträglichkeit an. Ein ohne Identifikator abgeschlossener Play-Kauf bleibt dauerhaft anonym, und das Kennzeichnen künftiger Käufe ist die einzig verfügbare Abhilfe. Apples Set-App-Account-Token-Endpunkt kann die Historie nachträglich korrigieren, was ihn zur Ausnahme und nicht zur Regel macht.
Die Kosten einer Rückerstattung bei jemandem, der es wiederholt tut
Der erstattete Umsatz ist der sichtbare Teil – und auch der kleinere. Eine Rückerstattung zu gewähren setzt den Verkaufspreis zurück, was Ihre Buchhaltung erfasst. In dieser Zeile fehlt alles, was aufgewendet wurde, um das zu produzieren, was der Kunde nun kostenlos besitzt.
Nehmen Sie ein Verbrauchsgut, das echte Arbeit in Gang setzt: generierte Bilder, eine Reihe von Aufrufen an einen Modellanbieter, ein exportiertes Video, eine an einen Creator ausgezahlte Vergütung. Diese Rechenleistung wurde im Moment der Nutzung bezahlt. Die Rückerstattung holt den Verkaufspreis zurück und lässt die Rechnung des Anbieters genau dort, wo sie war. Wer herausgefunden hat, dass die Ware die Rückerstattung überlebt, wiederholt die Sequenz einfach: kaufen, verbrauchen, erstatten – und jede Wiederholung belastet Sie erneut mit den Lieferkosten.
Hinzu kommt, dass die Plattform Kosten auf Sie verschiebt. Ab dem 3. August 2026 belastet Google Play für Bestellungen, die ab diesem Datum aufgegeben werden, sowohl den Kaufpreis als auch die Chargeback-Gebühren der Bank den Entwicklern. Streitfälle, die größtenteils Googles Kosten waren, werden zu Ihrem entgangenen Umsatz plus einer Gebühr, und wer gewohnheitsmäßig Rückbuchungen veranlasst, lässt diese Summe mit jedem Versuch weiter ansteigen. Identitätsfelder sind das, was es überhaupt erst ermöglicht, der Review Refund API innerhalb des 24-Stunden-Fensters etwas Lesenswertes zu übergeben.
Google nennt eine Zahl für das Ausmaß des Problems: mehr als 2 Milliarden US-Dollar an betrügerischen und missbräuchlichen Transaktionen, die 2022 blockiert wurden. Diese Zahl existiert, weil die zugrunde liegenden Signale, darunter die obfuscated account ID, tatsächlich befüllt waren. Käufe mit leeren Feldern auszuliefern ist eine Entscheidung, sich außerhalb dieses Schutzes zu stellen.
Serien-Rückerstatter erkennen, bevor der Store entscheidet
Versehen Sie jeden Kauf mit einer Identität, die Sie selbst kontrollieren
Keine der beiden Plattformen sollte einen Kauf ohne ein solches Merkmal sehen. StoreKit-Käufe führen appAccountToken mit, Play-Billing-Käufe führen setObfuscatedAccountId mit, und beide Werte stammen aus Ihren eigenen Nutzerdaten. Apple erwartet eine echte, diesem Konto zugeordnete UUID, Google erwartet den Kontoschlüssel gehasht, sodass nichts Persönliches im Klartext übertragen wird. Der Checkout ist für beide der entscheidende Moment, und bei Google lässt sich dieser Zeitpunkt nachträglich nicht mehr nachholen.
Führen Sie ein Register, das auf dieser Identität basiert
Protokollieren Sie die Lieferungen, die Konsumereignisse, die Käufe und die Rückerstattungen, alles unter diesem Identifikator abgelegt. Ein CONSUMPTION_REQUEST oder ein Chargeback Review bringt dann die gesamte Vergangenheit dieses Kontos, frühere Rückerstattungen eingeschlossen, auf eine einzige Abfrage entfernt. Apples Konsuminformationen stellen eigene Felder genau für dieses Material bereit: consumptionStatus, deliveryStatus, playTime, accountTenure, lifetimeDollarsPurchased und Ihre eigene refundPreference.
Behandeln Sie voidedReason als Weiterleitungsentscheidung
Für Google Play stornierte Käufe tragen einen voidedReason, der die Ursache erklärt, und friendly_fraud sowie fraud werden getrennt von gewöhnlicher Reue erfasst. Diese Fälle verdienen eine Prüfwarteschlange und eine strengere Richtlinie statt der automatischen Behandlung, die eine erste Rückerstattung erhält. Googles Leitfaden beschreibt eine Eskalation: zunächst eine Warnung, bei Wiederholung etwas Strengeres, und bei anhaltendem Verhalten die Deaktivierung von Käufen für das betreffende Konto.
Verpassen Sie das Zeitfenster nie
Zu spät eingereichte Beweise sind praktisch wertlos. Automatisieren Sie die CONSUMPTION_REQUEST-Antwort, sodass sie bequem innerhalb von 12 Stunden versendet wird, und den Chargeback Review innerhalb von 24 Stunden. Eine makellose Kontohistorie, die nach Ablauf der Frist eingereicht wird, ist eine Historie, die beim Store niemand mehr öffnet.
Um ein Konto zu erkennen, das gleichzeitig über unplausibel viele Geräte Transaktionen durchführt, verlassen Sie sich auf Google Plays Erkennung auffälliger Aktivitäten, die die obfuscated account ID auswertet.
Um eine frühere Rückerstattungshistorie dieses Kontos zu sehen, verlassen Sie sich auf Ihre eigenen Aufzeichnungen, also das Register, das Sie anhand des Identifikators der jeweiligen Plattform geführt haben.
Um zu bestätigen, dass die Ware den Käufer tatsächlich erreicht hat und genutzt wurde, verlassen Sie sich auf Apple, wo consumptionStatus und deliveryStatus Teil der Konsuminformationen sind.
Um einen Streitfall zu erkennen, bei dem der Käufer Sie in Wirklichkeit betrügt, verlassen Sie sich auf Google Play, wo voidedReason als friendly_fraud zurückgemeldet wird.
Wo die Plattformen helfen – und wo sie aufhören
Es lohnt sich, bei der Aufteilung der Verantwortung genau zu sein, denn die Annahme, die Stores würden Missbrauch von sich aus bekämpfen, liegt nahe, und sie teilen selten mit, wo ihre Zuständigkeit endet. Google liest die obfuscated account ID tatsächlich aus, um manchen Betrug schon vor dem Kauf zu blockieren, und die Systeme auf Plattformebene fangen ein erhebliches Volumen ab. Apple behält sich jede Rückerstattungsentscheidung selbst vor und behandelt Ihre Konsuminformationen als Beweismittel, nicht als Abstimmung. Was keiner der beiden Stores tut: eine Täterliste für Sie führen, ein erstattetes Verbrauchsgut Ihrem Guthaben wieder gutschreiben oder einem Serien-Rückerstatter für Sie den Kauf verweigern. In Grenzfällen liegt es am Store, anhand der Identität zu handeln. Überall sonst liegt es an Ihnen.
Refund Sensor ist aus genau diesem Grund rund um diese Identität aufgebaut. Eine Rückerstattung, ein Chargeback Review und ein Consumption Request, die zu einem Konto gehören, verschmelzen zu einer einzigen Historie, sodass ein wiederkehrendes Muster bereits beim zweiten Vorfall sichtbar wird und nicht erst, nachdem die vierte Rechnung längst bezahlt wurde.
Wo diese Regeln dokumentiert sind
Android: BillingFlowParams.Builder und setObfuscatedAccountId
Google Play Billing: Rückerstattungs- und Chargeback-Empfehlungen über die Review Refund API
Android Developers Blog: Play Commerce und die 2 Milliarden US-Dollar, die 2022 blockiert wurden
Google Play Console-Hilfe: Rückerstattungsschutz und Verantwortung für Chargeback-Kosten
Häufig gestellte Fragen
Der Begriff beschreibt einen Kunden, der wiederholt Rückerstattungen verlangt, nachdem er das Gekaufte erhalten und genutzt hat, und so den Nutzen behält, während er die Zahlung zurückerhält. Im Kontext der App-Stores zeigt sich das typischerweise so, dass ein Konto immer wieder Verbrauchsgüter oder Abonnements erstatten lässt, oder als Friendly Fraud, bei dem eine gültige Abbuchung stattdessen über die Bank angefochten wird.
Bei Apple erzeugen Sie eine UUID, übergeben sie beim Start des Kaufs als appAccountToken, und StoreKit hängt sie an die daraus entstehende Transaktion an, von wo sie sowohl in den Transaktionsdaten als auch in den Konsumdaten wieder auftaucht. Bei Google rufen Sie setObfuscatedAccountId mit einem aus diesem Konto abgeleiteten Hash-Wert auf. Beide Ansätze lösen eine Store-Transaktion auf Ihre eigenen Nutzerdaten auf, ohne irgendetwas Persönliches offenzulegen.
Keines von beiden – zumindest nicht direkt. Google liest die obfuscated account ID aus, um auffällige Aktivitäten zu erkennen und manchen Betrug schon vor dem Kauf zu stoppen, und Apple akzeptiert eine während eines Consumption Requests übermittelte Kontohistorie, aber von keinem der beiden Unternehmen kommt eine Liste von Wiederholungstätern zurück. Diese Liste zusammenzustellen liegt bei Ihnen, aufgebaut aus den Aufzeichnungen, die Sie unter diesen Identifikatoren abgelegt haben.
Unverschlüsselte personenbezogene Daten in der obfuscated account ID sind meist der Grund. Wenn Sie dort beispielsweise eine rohe E-Mail-Adresse eintragen, blockiert Play den Kauf rundweg. Verwenden Sie stattdessen einen verschlüsselten Wert oder einen Einweg-Hash und bleiben Sie innerhalb der Obergrenze von 64 Zeichen.
Sie verringert Missbrauch, stoppt ihn aber nicht vollständig. CONSUMPTION_REQUEST ist einer von nur zwei Wegen, bei denen Ihre Beweise vor der Entscheidung eintreffen, und die Kontohistorie zusammen mit Liefer- und Konsumdaten hilft Apple dabei, Rückgabemissbrauch und Friendly Fraud zu erkennen. Die Entscheidung trifft jedoch weiterhin Apple, und Missbrauch, der über Abläufe eintrifft, die Sie nicht anfechten können, bleibt davon unberührt.
