Versehen Sie jeden Google-Play-Kauf mit einer verschleierten Konto-ID, sonst trifft eine Rückbuchung ein, die sich nicht mehr zuordnen lässt

Eine Google-Play-Rückbuchungsprüfung trifft ein und nennt eine Bestellung und ein Kauf-Token. Sie sagt Ihnen nicht, wer der Kunde ist. Wenn Sie diesem Kauf nie Ihren eigenen Bezeichner aufgeprägt haben, gleichen Sie jetzt eine nackte Bestellnummer mit Ihrer Nutzertabelle ab, unter einer 24-Stunden-Uhr, und müssen mit Nutzungsbelegen antworten, die Sie womöglich gar nicht finden. Die verschleierte Konto-ID ist die Lösung. Es ist eine kurze Zeichenkette, die Sie beim Bezahlen anhängen und die Google Play mit dem Kauf speichert und Ihnen später zurückgibt, sodass sich jede Bestellung genau dem Nutzer zuordnen lässt, der sie getätigt hat. Hier ist, was das Feld ist, warum es überhaupt darüber entscheidet, ob Sie einen Streitfall beantworten können, und was es kostet, es wegzulassen, jetzt da eine verlorene Rückbuchung eine Rechnung ist.

Was die verschleierte Konto-ID tatsächlich ist

Die verschleierte Konto-ID ist eine optionale Zeichenkette, die Sie in den Google-Play-Abrechnungsablauf übergeben, wenn ein Kunde etwas kauft. Sie setzen sie mit setObfuscatedAccountId auf dem BillingFlowParams-Builder, und Google speichert sie neben dem Kauf. Es ist nicht der Name des Kunden, nicht seine E-Mail und nicht sein Google-Konto. Es ist Ihr eigener Bezeichner für Ihren eigenen Nutzer, geschrieben in einer Form, die Google aufbewahren kann, ohne zu erfahren, wer die Person ist.

Es ist eine Zeichenkette, die Sie beim Bezahlen setzen, kein Name

In Googles Worten legt setObfuscatedAccountId eine optionale verschleierte Zeichenkette fest, die eindeutig mit dem Nutzerkonto des Käufers in Ihrer App verbunden ist. Das Wort verschleiert leistet echte Arbeit. Google will nicht Ihre rohe Nutzer-ID oder irgendetwas, das die Person identifiziert. Es will ein stabiles Token, das eins zu eins auf einen Nutzer auf Ihrer Seite abbildet, und nicht mehr. Das Feld ist auf 64 Zeichen begrenzt, was einen Hash bequem fasst und nicht viel sonst.

Google liest es zuerst für seine eigene Betrugsprüfung

Bevor es Ihnen überhaupt nützt, erfüllt das Feld eine Aufgabe für Google. Die Abrechnungsdokumentation sagt, Google Play kann diesen Wert nutzen, um ungewöhnliche Aktivität zu erkennen, etwa wenn viele Geräte innerhalb kurzer Zeit über dasselbe Konto einkaufen, und dass Google diese Daten nutzt, um verdächtiges Verhalten zu erkennen und manche Arten betrügerischer Transaktionen zu blockieren, bevor sie abgeschlossen werden. Der erste Nutzen des Setzens liegt also stromaufwärts, in saubereren Käufen und weniger von jenen betrügerischen, die später zu Stornierungen und Streitfällen werden. Google nennt die verschleierte Konto-ID und die Voided Purchases API nicht ohne Grund gemeinsam als seine beiden zentralen Werkzeuge gegen Missbrauch.

Warum es zählt, wenn eine Rückbuchungsprüfung eintrifft

Eine Rückerstattung, die Sie kommen sehen, ist einfach. Der harte Fall ist die Bank-Rückbuchung, denn sie beginnt nicht damit, dass Ihr Kunde mit Ihnen spricht. Sie beginnt bei der Bank, und Google Play leitet sie an Sie als Prüfung mit angehängter Uhr weiter.

Der Streitfall nennt eine Bestellung, keine Person

Wenn ein Kunde eine Belastung bei seiner Bank anficht und Google Ihre Eingabe braucht, sendet Google Play eine PendingRefundReviewNotification. Diese Nachricht identifiziert die Bestellung. Sie trägt nicht Ihre Nutzer-ID, weil Google Ihre Nutzer-ID nie hatte. Es hatte nur, was auch immer Sie dem Kauf aufgeprägt haben. War das nichts, durchsuchen Sie jetzt rückwärts eine nackte Bestellnummer und ein Kauf-Token gegen Ihre eigenen Datensätze, in der Hoffnung, das Token zum Kaufzeitpunkt protokolliert zu haben, und in der Hoffnung, dass die Übereinstimmung eindeutig ist. Wenn Sie eine verschleierte Konto-ID gesetzt haben, trägt der Kauf Ihren eigenen Hash, Sie schlagen den Nutzer in einer Abfrage nach und gehen zum Zusammenstellen der Belege über, statt nach der Identität zu jagen.

Was orders.reviewrefund tatsächlich von Ihnen verlangt

Den Streitfall zu beantworten bedeutet, die Methode orders.reviewrefund innerhalb von 24 Stunden aufzurufen. Google erfasst Ihren ersten Aufruf und ignoriert den Rest, die erste Antwort ist also die einzige Antwort. Dies sind die Felder, die es will, und jedes einzelne der Belegfelder setzt voraus, dass Sie bereits wissen, zu welchem Nutzer die Bestellung gehört.

Was es tatsächlich kostet, es wegzulassen

Den größten Teil der Geschichte von Google Play hindurch war eine Rückbuchung, die Sie nicht verteidigen konnten, ein verlorener Verkauf und ein Achselzucken. Das hat sich geändert. Für Bestellungen, die am oder nach dem 3. August 2026 aufgegeben werden, stellt eine verlorene Rückbuchung dem Entwickler den Kaufpreis abzüglich der Google-Servicegebühr plus die Rückbuchungsgebühr der Bank in Rechnung. Der Streitfall, den Sie nicht beantworten können, ist jetzt ein Posten auf der Rechnung.

Gehen wir eine Bestellung durch. Ein Kunde ficht einen Kauf von $9.99 bei seiner Bank an. Google Play sendet die Prüfung, und Sie haben 24 Stunden. Wenn Sie den Kauf gekennzeichnet haben, finden Sie den Nutzer, sehen, dass er das meiste des Gekauften verbraucht hat, und beantworten reviewrefund mit einer DECLINE-Präferenz und den Verbrauchsbelegen, was Google einen echten Fall gibt, um einen unrechtmäßigen Streitfall anzufechten. Wenn Sie ihn nicht gekennzeichnet haben, können Sie die Bestellung entweder nicht rechtzeitig identifizieren oder Sie antworten mit nichts, der Streitfall wird ohne Ihre Seite entschieden, und bei einer Bestellung nach dem 3. August zahlen Sie die $9.99 abzüglich der Google-Gebühr zurück, plus eine pauschale Bank-Rückbuchungsgebühr, die oft bei etwa $20 landet. Bei einem kleinen Verkauf kann diese Pauschalgebühr allein größer sein als das, was Sie netto verdient haben.

• Die verlorenen Einnahmen: Ihr Nettoanteil am Verkauf, umgekehrt.
• Die Rückbuchungsgebühr der Bank: eine Pauschalkosten, die das Kartennetzwerk festlegt, obendrauf berechnet bei Bestellungen, die nach dem 3. August 2026 aufgegeben werden, die eine bloße Rückerstattung nie trägt.
• Die verschwendeten Ausgaben: die Rechenleistung, die Drittanbieter-API-Aufrufe und der Speicher, die das Konto bereits genutzt hat, verloren, ob Sie antworten konnten oder nicht.
• Das Muster, das Sie nicht sehen können: ohne eine stabile Konto-ID können Sie auch nicht erkennen, dass derselbe Nutzer immer wieder anficht, sodass sich serieller Missbrauch als unzusammenhängende Einzelverluste liest.

Wie Sie es setzen, ohne dass Käufe blockiert werden

Zwei Regeln decken fast jeden Fehler ab, den Teams mit diesem Feld machen. Hashen Sie die ID, und setzen Sie sie überall.

Hashen Sie Ihre Nutzer-ID, senden Sie nie PII

Setzen Sie keine E-Mail, keine Telefonnummer und kein rohes persönliches Detail in dieses Feld. Google ist eindeutig, dass das Speichern von PII wie E-Mail-Adressen im Klartext dazu führt, dass Käufe blockiert werden, und es empfiehlt einen Einweg-Hash oder Verschlüsselung, um den Wert zu erzeugen. Das saubere Muster ist ein Einweg-Hash Ihrer internen Nutzer-ID, jedes Mal auf dieselbe Weise berechnet, sodass derselbe Nutzer immer dieselbe 64-Zeichen-Zeichenkette erzeugt. Verwenden Sie auch nicht die Google-Konto-ID der Person oder Ihre Entwickler-ID. Der Wert sollte nur für Ihr System etwas bedeuten.

Setzen Sie es bei jedem Kauf und lesen Sie es auf Ihrem Server zurück

Hängen Sie die ID an jeden Abrechnungsablauf an, an Einmalprodukte und Abonnements gleichermaßen, sodass kein Kauf je unbeschriftet bleibt. Nach dem Kauf lesen Sie sie an zwei Stellen zurück. Auf dem Client gibt Purchase.getAccountIdentifiers ein Objekt zurück, dessen getObfuscatedAccountId Ihnen die gesetzte Zeichenkette liefert. In Ihrem Backend trägt der serverseitige Kaufdatensatz sie als Feld obfuscatedExternalAccountId, und der Server-Kopie ist zu vertrauen, denn ein Streitfall trifft auf Ihrem Server ein, nicht auf dem Gerät.

Verwenden Sie setObfuscatedProfileId, wenn ein Konto viele Profile hat

Wenn Ihre App zulässt, dass ein Konto mehrere Profile hält, ein Streaming-Haushalt oder ein Spiel mit mehreren Charakteren, setzen Sie auch setObfuscatedProfileId. Es ist dieselbe Art gehashter, 64-Zeichen-, PII-freier Zeichenkette, auf das Profil bezogen, das den Kauf getätigt hat. Google merkt an, dass das Setzen einer Profil-ID auch verlangt, die Konto-ID zu übergeben, senden Sie also beide. Das Ergebnis ist, dass sich ein Streitfall nicht nur dem Konto zuordnet, sondern genau dem Profil, das das Geld ausgegeben hat.

Die iOS-Entsprechung, in einer Zeile

Der App Store hat dieselbe Idee unter einem anderen Namen. Auf iOS hängen Sie einem Kauf ein appAccountToken an, eine UUID, und es kommt bei der Transaktion und bei der CONSUMPTION_REQUEST zurück, die Apple sendet, wenn ein Kunde eine Rückerstattung verlangt. Die Gestalt des Problems ist auf beiden Stores identisch. Der Streit- oder Rückerstattungsablauf verweist auf eine Transaktion, und Ihr eigener Bezeichner ist das, was sie zu einem Nutzer zurückbindet, dessen Nutzung Sie melden können.

Nichts davon ist schwer zu bauen. Es ist leicht zu überspringen, denn der Tag, an dem Sie den Checkout-Code schreiben, ist nicht der Tag, an dem eine Rückbuchung eintrifft, und die Kosten des Überspringens sind bis dahin unsichtbar. RefundHalt setzt und verfolgt den Konto-Bezeichner auf beiden Stores, hält die Verbindung von Kauf zu Nutzer, sodass ein Streitfall stets zu einem echten Kunden auflöst, und beantwortet Google Plays orders.reviewrefund und Apples CONSUMPTION_REQUEST innerhalb ihrer Fenster mit den zum Verkaufszeitpunkt erfassten Verbrauchsbelegen. Die 24-Stunden-Uhr ist nicht der Moment, um zu entdecken, dass Sie nicht sagen können, wer die Sache gekauft hat.