Nutzen Sie Google Play RTDN für die schnelle Verarbeitung von Ereignissen. Nutzen Sie die Voided Purchases API, um stornierte Bestellungen zu prüfen und Ihre Datensätze abzugleichen. Für die meisten kostenpflichtigen Apps ist die sicherere Wahl beides.
Wenn Sie eine Google Play-Rückerstattungsabwehr für Apps planen, beginnen Sie mit dieser Aufteilung. Der eine Pfad sagt Ihnen, dass sich etwas geändert hat. Der andere lässt Ihren Server eine Liste stornierter Käufe abrufen und prüfen, was er verpasst hat.
Die Wahl besteht nicht ganz zwischen zwei Benachrichtigungssystemen. Google Play RTDN sendet Nachrichten über Cloud Pub/Sub. Die Voided Purchases API ist eine Pull-API: Ihr Backend ruft sie auf.
Keines der beiden Tools verhindert für sich allein, dass jemand eine Rückerstattung beantragt. Ihr Wert liegt darin, Änderungen zu erkennen, Bestellungen zu prüfen und sicherzustellen, dass der kostenpflichtige Zugriff dem Kaufstatus entspricht.
Die wichtigsten Punkte
Nutzen Sie RTDN, um zeitnah auf Kauf- und Abonnementereignisse zu reagieren.
Nutzen Sie die Liste stornierter Käufe als zweiten Weg, um betroffene Bestellungen zu prüfen.
Betrachten Sie ein gekündigtes Abonnement nicht als Beweis für eine Rückerstattung.
Stellen Sie sicher, dass beide Wege dieselbe sichere Logik zur Zugriffsaktualisierung verwenden.
Halten Sie die ausstehende Chargeback-Prüfung getrennt von einer abgeschlossenen Stornierung.
Was ist Google Play RTDN?
Google Play Real-Time Developer Notifications, meist RTDN genannt, sendet kaufbezogene Ereignisse an ein Cloud-Pub/Sub-Topic.
Ihr Backend empfängt eine Nachricht und leitet sie an den richtigen Worker weiter. Der Nachrichtentyp ist entscheidend. Eine Verlängerung, eine Kündigung und ein stornierter Kauf sind nicht dasselbe Ereignis.
Für die Rückerstattungsverfolgung sollten Sie besonders auf voidedPurchaseNotification achten. Sie enthält:
purchaseToken: verknüpft das Ereignis mit einem Kauf.
orderId: identifiziert die betroffene Bestellung.
productType: identifiziert ein Abonnement oder einen einmaligen Kauf.
refundType: unterscheidet eine vollständige Stornierung von einer mengenbasierten Teilrückerstattung.
Googles RTDN-Referenz und Ereignisdefinitionen erklären diese Felder und die anderen Benachrichtigungstypen.
RTDN ist nützlich, wenn Sie kurz nach einer Änderung handeln möchten. Eine Nachricht ist jedoch nicht Ihre vollständige Kaufdatenbank. Gleichen Sie sie mit gespeicherten Datensätzen ab und rufen Sie bei Bedarf den relevanten Kaufstatus ab, bevor Sie den Zugriff ändern.
Bedeutet eine Abonnementkündigung eine Rückerstattung?
Nein. Ein Kunde kann zukünftige Verlängerungen stoppen und trotzdem für den Rest der aktuellen Laufzeit kostenpflichtigen Zugriff behalten.
Erstellen Sie keine Regel, die den Zugriff entfernt, sobald SUBSCRIPTION_CANCELED eintrifft. Prüfen Sie stattdessen den Abonnementstatus und das Ablaufdatum. Widerruf und Ablauf erfordern jeweils eine eigene Behandlung.
Was ist die Voided Purchases API?
Die Google Play Voided Purchases API liefert eine Liste von Käufen, die innerhalb ihres unterstützten Bereichs storniert, zurückerstattet oder per Chargeback zurückgebucht wurden.
Sie gilt für einmalige In-App-Bestellungen und Abonnements. Ihr Server kann die Ergebnisse nutzen, um zu prüfen, welche Käufe keinen Zugriff mehr gewähren sollten.
Die Liste kann die Bestell-ID, das Kauf-Token, den Stornierungszeitpunkt, die Stornierungsquelle und den Stornierungsgrund enthalten. Bei unterstützten mengenbasierten Teilrückerstattungen kann sie zudem die erstattete Menge enthalten.
Googles Leitfaden zur Voided Purchases API dokumentiert einen Rückblickzeitraum von 30 Tagen. Es handelt sich nicht um ein permanentes Rückerstattungsarchiv. Speichern Sie verarbeitete Datensätze in Ihrem eigenen System.
Diese API ist besonders nützlich nach einem Worker-Ausfall, einem Routing-Fehler oder einer Lücke in Ihren lokalen Datensätzen. Außerdem ermöglicht sie Ihnen eine routinemäßige Prüfung gegen die von Ihnen verarbeiteten Ereignisse.
RTDN vs. Voided Purchases API: der praktische Unterschied
Frage | Google Play RTDN | Voided Purchases API |
Wie funktioniert es? | Google veröffentlicht ein Ereignis an Pub/Sub. | Ihr Server fordert eine Liste an. |
Was ist seine Hauptaufgabe? | Zeitnahe Verarbeitung von Änderungen des Kaufstatus. | Prüfung und Abgleich stornierter Bestellungen. |
Deckt es auch Ereignisse jenseits von Rückerstattungen ab? | Ja, einschließlich Verlängerungen und anderer Lifecycle-Ereignisse. | Es konzentriert sich auf stornierte Käufe. |
Kann es nach einer Verarbeitungslücke helfen? | Die Pub/Sub-Wiederherstellung hängt von Ihrer Einrichtung und Aufbewahrung ab. | Es kann verfügbare Datensätze innerhalb des 30-Tage-Fensters auflisten. |
Benötigt es einen Schutz vor Duplikaten? | Ja. | Ja, insbesondere wenn sich Scans überlappen oder Ereignisse mit RTDN teilen. |
Die entscheidende Frage ist nicht, welches Tool für sich genommen besser ist. Es geht darum, bei welchem Fehlerfall Ihnen jedes Tool hilft.
RTDN bietet Ihnen einen schnellen Weg. Die API bietet Ihnen einen Prüfweg. Ihre eigene Datenbank sollte beide zusammenführen.
Welche sollte Ihre App nutzen?
Nutzen Sie RTDN, wenn Geschwindigkeit entscheidend ist
Eine kostenpflichtige App sollte nicht auf einen geplanten Scan warten müssen, um eine Änderung des Kaufstatus zu erkennen.
Nutzen Sie RTDN, wenn Ihre App zeitnahe Aktualisierungen für Abonnements, einmalige Käufe und stornierte Bestellungen benötigt. Leiten Sie jedes Ereignis nach Typ weiter, anstatt eine einzige Rückerstattungsregel auf alle Nachrichten anzuwenden.
Nutzen Sie die API, wenn Vollständigkeit entscheidend ist
Nutzen Sie geplante API-Prüfungen, um stornierte Bestellungen zu finden, die Ihr Worker nicht auf Ihre Datensätze angewendet hat.
Zum Beispiel könnte Ihr Empfänger eine Nachricht akzeptiert haben, aber ein Fehler könnte die spätere Zugriffsaktualisierung verhindert haben. Die Zustellung allein zu reparieren, schließt diese lokale Lücke nicht.
Nutzen Sie beide für einen produktiven Rückerstattungs-Workflow
Für die meisten kostenpflichtigen Apps sollten Sie beide kombinieren. Lassen Sie beide Wege in einen gemeinsamen Handler einfließen, der die Bestellung prüft und jede Änderung sicher anwendet.
Dies verringert das Risiko, dass ein verpasstes Ereignis den Zugriff aktiv lässt. Es verringert auch das umgekehrte Risiko: den Zugriff zweimal für dieselbe Rückerstattung zu entziehen.
So erkennen Sie Google Play-Rückerstattungen Schritt für Schritt
1. Führen Sie ein Kaufregister
Speichern Sie das App-Paket, das Kauf-Token, die Bestell-ID, das Produkt, die Nutzerzuordnung und die gewährte Menge. Ein Register ist einfach eine klare Aufzeichnung darüber, was gekauft wurde und welchen Zugriff es gewährt hat.
Speichern Sie bei Abonnements auch die Bestell-IDs der Verlängerungen. Die RTDN-Referenz weist darauf hin, dass jede automatische Verlängerung eine neue Bestell-ID erhält. Ein Kauf-Token allein reicht nicht aus, um jede betroffene Verlängerung zu identifizieren.
2. Sichern und leiten Sie RTDN-Nachrichten weiter
Konfigurieren Sie den Pub/Sub-Zugriff korrekt. Überprüfen Sie bei Push-Zustellung die authentifizierte Anfrage. Beschränken Sie bei Pull-Zustellung, wer das Abonnement lesen darf.
Decodieren Sie die Nachricht, prüfen Sie den Paketnamen und speichern Sie sie, bevor Sie zeitaufwändige Arbeiten ausführen. Senden Sie Testereignisse über den gesamten Pfad, nicht nur über den empfangenden Endpunkt.
3. Führen Sie einen geplanten Scan stornierter Käufe durch
Rufen Sie die List-Methode mit geeigneten Anmeldedaten und Play Console-Berechtigungen auf. Verfolgen Sie alle Ergebnisseiten.
Zwei Abfrageeinstellungen werden leicht übersehen:
type=1 umfasst sowohl einmalige Käufe als auch Abonnements. Der Standardwert 0 umfasst nur einmalige Käufe.
includeQuantityBasedPartialRefund=true umfasst unterstützte mengenbasierte Teilrückerstattungen. Der Standardwert ist false.
Googles Referenz zur voidedpurchases.list-Methode behandelt die Anfrage- und Paginierungsfelder.
Verwenden Sie eine moderate Überlappung zwischen den Scans und deduplizieren Sie die Ergebnisse. Wählen Sie die Scan-Häufigkeit basierend auf Ihrem Volumen, Ihren Quoten und der Verzögerung, die Ihre App akzeptieren kann. Warten Sie nicht, bis das Rückblickfenster fast abgelaufen ist.
4. Wenden Sie jede Änderung nur einmal an
Beide Wege können dieselbe Stornierung melden. Entwickeln Sie eine idempotente Verarbeitung: Das erneute Ausführen derselben Änderung sollte das Ergebnis nicht verändern.
Verwenden Sie nicht allein die Bestell-ID, um jedes spätere Ereignis zu verwerfen. Ein Kauf mit mehreren Einheiten kann mehrere Teilrückerstattungen haben. Verfolgen Sie verarbeitete Anpassungen und erstattete Mengen, damit eine echte spätere Rückerstattung nicht verloren geht.
5. Überwachen Sie die Lücke, nicht nur die Nachrichtenanzahl
Verfolgen Sie den letzten erfolgreichen Scan, unvollständige Seiten, Worker-Fehler und nicht zugeordnete Bestellungen. Messen Sie, wie lange die Zugriffsaktualisierung nach einem bestätigten Ereignis dauert.
Für umfassendere Berichte lesen Sie unseren Leitfaden zu Tools für die Verfolgung von App-Rückerstattungen und Chargebacks.
Beispiel: eine Rückerstattung, zwei Erkennungswege
Dies ist ein hypothetischer Workflow, kein berichteter Kundenfall.
Ein Spieler kauft ein einmaliges Paket, das 500 Münzen gewährt. Der Kauf wird später vollständig storniert.
RTDN sendet eine Voided-Purchase-Nachricht. Ihr Worker findet die Bestellung, prüft die erfasste Gutschrift und wendet Ihre veröffentlichte Richtlinie auf die mit diesem Kauf verknüpften Münzen an.
Später liefert der geplante API-Scan dieselbe Bestellung. Der gemeinsame Handler erkennt, dass die Anpassung für die vollständige Stornierung bereits angewendet wurde. Er erfasst die Übereinstimmung und führt keinen zweiten Abzug durch.
Nehmen wir nun an, der Worker ist ausgefallen, bevor die erste Änderung angewendet wurde. Der Scan findet die Bestellung und gibt Ihrem System einen weiteren Weg, sie zu verarbeiten.
Das ist der Sinn der Nutzung beider Wege. Nicht zwei getrennte Strafen, sondern zwei Wege zu einem korrekten Ergebnis.
Wenn bereits Münzen ausgegeben wurden, entfernen Sie nicht blind Münzen aus einem unabhängigen, kostenpflichtigen Paket. Nutzen Sie eine klare Richtlinie, erläutern Sie die Maßnahme und bieten Sie einen Support-Weg an.
Die ausstehende Rückerstattungsprüfung ist ein eigener Workflow
Die aktuelle Google-Dokumentation listet zudem pendingRefundReviewNotification für eine Chargeback-Anfrage auf, die eine Prüfung durch den Entwickler erfordert.
Für dieses Ereignis empfiehlt Google, innerhalb von 24 Stunden über orders.reviewrefund einen Rückerstattungsvorschlag und Nachweise zur Kaufnutzung bereitzustellen.
Verwechseln Sie es nicht mit voidedPurchaseNotification. Das eine betrifft eine ausstehende Prüfung. Das andere meldet einen Kauf, der storniert wurde.
Die Voided Purchases API ist kein Ersatz für die Behandlung eines ausstehenden Prüfungsereignisses. Halten Sie diesen Zweig getrennt und gehen Sie nicht davon aus, dass jede Rückerstattungsanfrage es auslöst.
App Store-Rückerstattungen und Umsatzverlust: was Entwickler wissen müssen
Umsatzverlust beschränkt sich nicht darauf, ob ein Store Geld zurückgibt. Er kann auch bedeuten, dass Ihr Backend weiterhin kostenpflichtigen Zugriff gewährt, nachdem der zugehörige Kauf dies nicht mehr rechtfertigt.
Für Teams, die auf beiden Plattformen aktiv sind, ist das Ziel ähnlich: Geld, Kaufstatus und Zugriffsaufzeichnungen im Einklang zu halten. Die Store-Tools und Ereignisregeln unterscheiden sich jedoch. Übernehmen Sie keinen Apple-Workflow unverändert in Google Play.
Unser Leitfaden zum App Store-Rückerstattungs-Umsatzmanagement behandelt das umfassendere Umsatzmanagement-Problem. Konzentrieren Sie sich bei dieser Google Play-Integration zunächst auf verpasste Stornierungen, doppelte Abzüge und fehlerhafte Änderungen beim Abonnementzugriff.
Was Google Play-Betrugsprävention bei Rückerstattungen kann und nicht kann
Betrugsprävention bei Google Play-Rückerstattungen beginnt mit soliden Aufzeichnungen und fairen Regeln. Eine stornierte Bestellung ist kein Beweis dafür, dass der Kunde unehrlich gehandelt hat.
Ein Nutzer kann eine berechtigte Beschwerde haben. Eine Zahlung kann fehlschlagen. Ihre App kann den falschen Artikel geliefert haben.
Nutzen Sie diese Tools, um Fakten zu prüfen und Zugriffsänderungen anzuwenden. Prüfen Sie wiederkehrende Muster im Kontext. Vermeiden Sie automatische Kontosperrungen aufgrund einer einzigen Rückerstattung und lassen Sie Kunden Fehler anfechten.
Weder RTDN noch die List-API garantieren, dass Sie eine Rückerstattung verhindern, ablehnen oder rückgängig machen können.
Fazit
Die Entscheidung zwischen RTDN und der Voided Purchases API ist für die meisten kostenpflichtigen Apps keine Entweder-oder-Entscheidung.
Nutzen Sie RTDN, um schnell zu reagieren. Nutzen Sie geplante Prüfungen stornierter Käufe, um Datensätze abzugleichen. Leiten Sie beide durch einen einzigen sicheren Handler, und halten Sie ausstehende Prüfungen getrennt von abgeschlossenen Stornierungen.
Beginnen Sie mit einem kleinen Test: Senden Sie eine Stornierung über beide Wege und bestätigen Sie, dass sich der Zugriff nur einmal ändert. Stoppen Sie dann Ihren Worker und prüfen Sie, ob Ihr Wiederherstellungsweg die Lücke erkennt.
Häufig gestellte Fragen
RTDN ist besser für die zeitnahe Verarbeitung von Ereignissen geeignet. Die API ist besser für geplante Prüfungen stornierter Bestellungen geeignet. Die meisten kostenpflichtigen Apps profitieren von beiden.
Ja. Es enthält eine Voided-Purchase-Benachrichtigung mit Details zur Bestellung und zum Rückerstattungstyp. Behandeln Sie dieses Ereignis getrennt von einer Abonnementkündigung.
Sie können verfügbare stornierte Datensätze durch Polling erkennen, aber die Erkennung wartet auf Ihren nächsten erfolgreichen Scan. Außerdem verpassen Sie den umfassenderen Lifecycle-Ereignisstrom von RTDN.
Google dokumentiert ein Fenster von 30 Tagen. Führen Sie eigene Aufzeichnungen für langfristige Prüfungen und Supportanforderungen.
Ja. Aktivieren Sie die unterstützten Teilrückerstattungsergebnisse in Listenanfragen. Verfolgen Sie erstattete Mengen und berücksichtigen Sie, dass eine Bestellung mehr als eine Teilrückerstattung erhalten kann.
