Ein Kauf wird abgeschlossen, der Kunde erhält sein Produkt, und drei Tage später ist es wieder weg. Google Play macht die Zahlung rückgängig und entzieht die Berechtigung, ohne dass der Kunde danach verlangt und ohne dass jemand aus Ihrem Support-Team einen Knopf drückt. Der Kauf ist lautlos gescheitert, weil Ihr Server Google nie mitgeteilt hat, dass er bearbeitet wurde.
Das ist die gesamte Regel: Bestätigen Sie einen Google Play-Kauf innerhalb von drei Tagen, oder Google erstattet und widerruft ihn automatisch. Jedes Mal, ohne Ausnahme. Von allen Arten, wie sich ein Verkauf bei beiden Stores rückgängig machen lässt, liegt diese als eine der wenigen vollständig in Ihrer eigenen Integration – was sie auch zu einer der leisesten Arten macht, Umsatz zu verlieren.
Es ist keine Betrugsprüfung und keine Grundsatzentscheidung. Es ist ein Callback, der nie ausgelöst wurde. Die Behebung ist klein, das Geld, das Sie durch das Auslassen verlieren, ist es nicht – daher lohnt es sich, genau zu wissen, was die Regel besagt, warum Käufe ihr entgehen und was jeder verschwundene Verkauf mit sich zieht.
Was Googles Dokumentation tatsächlich verlangt
Play Billing verlangt, dass Ihre App Google benachrichtigt, sobald sie die Berechtigung gewährt und dem Nutzer mitgeteilt hat, dass der Kauf erfolgreich war. Googles Dokumentation nennt dafür eine feste Zahl: Diese Benachrichtigung „muss innerhalb von drei Tagen erfolgen, damit der Kauf nicht automatisch erstattet und die Berechtigung widerrufen wird". Die Dokumentation zu einmaligen Produkten wiederholt denselben Satz ohne Einschränkung. Lassen Sie die Bestätigung aus, „erhält der Nutzer automatisch eine Rückerstattung, und Google Play widerruft den Kauf". Der erste Kauf eines Abonnements folgt derselben Regel.
Die Bestätigung ist kein Papierkram. Sie ist das einzige Signal, das Google hat, dass die Lieferung tatsächlich stattgefunden hat. Kein Signal bedeutet, Google geht davon aus, dass nichts geliefert wurde, und macht den gesamten Vorgang für den Käufer rückgängig, ohne Sie zu konsultieren. Der Käufer sieht eine unerwartete Rückerstattung. Sie sehen einen Verkauf, der aus Ihren Büchern verschwunden ist.
Das Wichtigste in Kürze
Bleibt ein Verkauf 72 Stunden unbestätigt, geschieht die Rückabwicklung von selbst: Käufer erhält sein Geld zurück, Berechtigung wird entzogen, niemand wird gefragt. Kein Kunde hat das ausgelöst. Ihr Backend hat es getan, indem es nichts gesagt hat – und Ihr Backend kann es genauso gut verhindern.
Erst das Erreichen des Status PURCHASED setzt den Countdown in Gang, weshalb der Checkout-Moment für Ihre Frist irrelevant ist. Alles, was in PENDING verbleibt, hat keinen Timer und verdient noch keinen Bestätigungs-Call.
Einer von zwei Calls erfüllt die Pflicht. Rufen Sie purchases.products.consume für einen Verbrauchsartikel auf, oder greifen Sie bei allem anderen zu purchases.products.acknowledge und purchases.subscriptions.acknowledge. Google behandelt beides als Nachweis, dass die Ware angekommen ist.
Bei Abonnements verlangt dies genau einmal, beim Signup. Jeder weitere Abrechnungszyklus wird von Google selbst abgewickelt und als bestätigt markiert, ohne dass Ihr Code auch nur einen Finger krümmen muss.
Sie verkaufen einen Prepaid-Plan mit einer Laufzeit unter sieben Tagen? Dann schrumpft Ihr Zeitfenster auf fünfzig Prozent der Plan-Laufzeit. Kürzeres Produkt, kürzere Zündschnur.
Nur der Verkaufspreis wandert zurück zum Käufer. Rechenzeit, Ausgaben für Modell-APIs, Speicherkosten, Auszahlungen an Creator: Dieses Geld hat Ihr Konto bei der Erfüllung bereits verlassen, und nichts davon kommt zurück. Der tatsächliche Schaden übersteigt alles, was die Rückerstattungszeile ausweist.
Auf iOS funktioniert nichts davon so. StoreKit präsentiert eine unabgeschlossene Transaktion bei jedem Start erneut und wartet geduldig, ohne die Zahlung je rückgängig zu machen. Dieses besondere Risiko gibt es nur bei Google Play und sonst nirgends.
Der Checkout ist nicht der Startpunkt der Frist
Das Tippen auf „Kaufen" startet den Timer nicht. Der Kaufstatus muss zunächst zu PURCHASED wechseln, und manche Käufe verbleiben davor in PENDING. Barzahlungsmethoden tun das, ebenso langsame Banküberweisungen und Freigabeanfragen durch Eltern. Google sagt das direkt: „Das Drei-Tage-Fenster für die Bestätigung beginnt erst, wenn der Kaufstatus von PENDING zu PURCHASED wechselt."
Das bedeutet zweierlei für den Aufbau Ihres Flows. Gewähren Sie die Berechtigung erst, wenn der Status PURCHASED lautet, niemals bei PENDING – sonst geben Sie Produkte für Geld heraus, das möglicherweise gar nicht ankommt. Und bestätigen Sie auch keinen Kauf im Status PENDING, denn es gibt noch nichts zu bestätigen. Rufen Sie enablePendingPurchases() beim Einrichten des BillingClient auf, warten Sie auf den Statuswechsel und beginnen Sie erst zu zählen, wenn er bei PURCHASED angekommen ist.
Lesen Sie PENDING als „noch nicht verkauft". Nichts ist geschuldet: keine Berechtigung, keine Bestätigung, nichts als Umsatz verbucht. In dem Moment, in dem es zu PURCHASED wechselt, werden sowohl die Berechtigung als auch der Drei-Tage-Countdown zu Ihrem Problem.
Den richtigen API-Call für das Verkaufte auswählen
Zwei API-Pfade erfüllen die Frist, und welcher davon zutrifft, hängt davon ab, was Sie verkauft haben. Beide erfüllen die Anforderung gleichermaßen. Der Unterschied liegt darin, was sie danach sonst noch mit dem Produkt machen.
Verbrauchsartikel werden eingelöst. Das bedeutet purchases.products.consume auf einem sicheren Backend oder consumeAsync() aus der Play Billing Library auf dem Client. Das Einlösen erledigt zwei Aufgaben gleichzeitig, denn es erfüllt die Bestätigungspflicht und macht den Artikel wieder kaufbar. Genau das wollen Sie bei Münzen, Credits oder jeder einmaligen Generierung, die ein Kunde womöglich wiederholt kauft.
Nicht verbrauchbare Produkte und Abonnements werden hingegen bestätigt, über purchases.products.acknowledge, purchases.subscriptions.acknowledge oder acknowledgePurchase() auf dem Client. Das erfüllt die Frist, öffnet den Artikel aber nicht erneut für den Kauf.
So lässt sich jeder Produkttyp einem Call und einer Frist zuordnen:
Für einen Verbrauchsartikel rufen Sie purchases.products.consume oder consumeAsync() auf. Das macht den Artikel außerdem wieder kaufbar, und Ihre Frist beträgt drei Tage ab PURCHASED.
Für ein nicht verbrauchbares Produkt rufen Sie purchases.products.acknowledge oder acknowledgePurchase() auf. Die Berechtigung wird bestätigt, ohne einen erneuten Kauf zu ermöglichen, und Ihre Frist beträgt drei Tage ab PURCHASED.
Für den ersten Kauf eines Abonnements rufen Sie purchases.subscriptions.acknowledge oder acknowledgePurchase() auf. Das bestätigt das neue Abonnement, und Ihre Frist beträgt drei Tage ab PURCHASED.
Für eine Abo-Verlängerung brauchen Sie überhaupt keinen Call. Google markiert sie selbstständig als bestätigt, daher gibt es keine Frist.
Für einen Prepaid-Plan mit einer Laufzeit unter einer Woche verwenden Sie dieselben Bestätigungs-Calls, aber Ihre Frist schrumpft auf die halbe Plan-Laufzeit.
Die Pflicht endet nach der ersten Zahlung
Abo-Verlängerungen brauchen überhaupt keine Bestätigung. Google sagt das direkt: „Sie müssen Abo-Verlängerungen nicht bestätigen", und markiert jede davon selbstständig als bestätigt. Nur der allererste Kauf eines Abonnements kommt mit dem Status „ausstehende Bestätigung" an und bleibt so lange auf Ihrem Tisch, bis Sie ihn abschließen. Prüfen Sie den Bestätigungsstatus serverseitig, oder verwenden Sie isAcknowledged() auf dem Client, bevor Sie handeln. So senden Sie nie einen doppelten Bestätigungs-Call.
Eine kürzere Uhr für kurzfristige Prepaid-Pläne
Prepaid-Pläne mit einer Woche Laufzeit oder länger folgen der üblichen Drei-Tage-Regel. Kürzere tun das nicht. Googles Dokumentation besagt, dass Pläne „mit einer Laufzeit von weniger als einer Woche innerhalb der halben Plan-Laufzeit bestätigt werden müssen". Ein dreitägiger Prepaid-Plan gibt Ihnen anderthalb Tage, nicht das volle Fenster. Wenn kurze Prepaid-Aufladungen Teil Ihres Katalogs sind, muss der Bestätigungsweg schnell und serverseitig ablaufen – niemals abhängig davon, dass der Kunde die App erneut öffnet.
Wo der Acknowledgement-Call meist verloren geht
Niemand lässt diesen Schritt absichtlich aus. Er geht verloren, weil die Bestätigungslogik an den falschen Trigger gekoppelt wird. Das verbreitete Anti-Pattern ist ein Client, der nur bestätigt, wenn der Kaufablauf wieder in den Vordergrund zurückkehrt. Das deckt einen Kunden ab, der den Kauf abschließt und die App direkt danach weiter nutzt. Niemanden sonst.
Entwickler stoßen ständig darauf. Threads in Googles eigener Entwickler-Community folgen jedes Mal demselben Muster: eine Version davon, dass ein Nutzer drei Tage nach dem Kauf automatisch eine Rückerstattung erhält, oder die Bitte zu verstehen, warum sich Zahlungen am dritten Tag immer wieder selbst rückgängig machen. Die Diagnose ändert sich selten: Der Acknowledgement-Call war an eine Nutzeraktion gekoppelt, die nie stattfand, also wurde er schlicht nie ausgelöst.
Kostenlose Testphasen und der Kunde, der die App nie wieder öffnet
Die hässlichste Variante davon ist eine kostenlose Testphase oder ein Kauf in den letzten Momenten, bevor jemand Ihre App zum letzten Mal schließt. Wenn die Bestätigung auf das nächste App-Öffnen wartet und dieses nächste Öffnen nie kommt, läuft der Kauf einfach aus. Google erstattet und widerruft ihn am dritten Tag. Bei einer Testphase, die auf dem Weg zur Umwandlung war, verlieren Sie die erste Abrechnung, die Sie nie stellen konnten, und zusätzlich verschwindet leise eine Kundenberechtigung. Keines von beiden taucht in Ihrer Support-Warteschlange auf. Beides taucht als annullierter Kauf auf – vorausgesetzt, Sie suchen danach.
Eine Bestätigung, die vom nächsten App-Öffnen abhängt, ist ein Verkauf, den Sie jedes Mal verlieren, wenn ein Kunde drei Tage lang wegbleibt. Testphasen und One-Tap-Käufe sind genau die Momente, in denen Kunden wegbleiben.
Die wahren Kosten hinter einer unbestätigten Rückerstattung
Die Rückerstattungszeile untertreibt, was Sie tatsächlich verloren haben. Google macht den Verkauf rückgängig, Sie geben den Preis zurück, und das ist die Zahl, die jeder sieht. Das ist nicht die ganze Rechnung.
Nehmen Sie einen Verbrauchsartikel, der in dem Moment, in dem ihn jemand kauft, echte Arbeit auslöst. Eine Reihe von Bildgenerierungen, eine Serie von Aufrufen an die API eines Modellanbieters, ein Videoexport, eine fällige Auszahlung an einen Creator. Sie haben diese Rechenleistung, diese API-Calls, diesen Speicher und diese Auszahlungen zum Zeitpunkt der Nutzung bezahlt. Die Rückerstattung gibt dem Kunden den Verkaufspreis zurück. Sie erstattet Ihnen nicht die Rechnung des Anbieters. Reale Kosten haben Ihr Konto verlassen, und nichts davon kam zurück.
Bei Abonnements und Testphasen ist der Verlust die erste Abrechnung, die Sie nie einziehen, zuzüglich einer Kundenbeziehung, die endete, bevor sie überhaupt begann. Und der Einsatz steigt bald weiter. Ab dem 3. August 2026 wälzt Google Play den Chargeback-Kaufpreis und die Bankgebühren für Bestellungen nach diesem Datum auf die Entwickler ab, was es wert macht, jedes vermeidbare Leck jetzt statt später zu schließen. Eine unbestätigte Rückerstattung ist kein Chargeback, lehrt aber dieselbe Lektion: Geld, das Sie bereits ausgegeben haben, ist nicht automatisch Geld, das Sie behalten.
Den Bestätigungsschritt so aufbauen, dass er nicht ausfallen kann
Das zuverlässige Muster nimmt Ihre App vollständig aus dem kritischen Pfad heraus. Führen Sie es auf Ihrem Backend aus, gesteuert durch Benachrichtigungen – nicht dadurch, ob jemand einen Bildschirm wieder öffnet.
Abonnieren Sie Echtzeit-Entwicklerbenachrichtigungen. Ein Ereignis für den Kauf eines einmaligen Produkts oder ein Abo-Kaufereignis erreicht Ihren Server in dem Moment, in dem Google den Verkauf registriert – unabhängig davon, ob die App gerade läuft.
Validieren Sie das Purchase-Token über die Play Developer API und bestätigen Sie, dass der Status PURCHASED und nicht PENDING lautet.
Erfassen Sie die Berechtigung in Ihrem eigenen System, verknüpft mit dem Konto dieses Kunden.
Lösen Sie ein oder bestätigen Sie ohne Verzögerung. Verbrauchsartikel werden eingelöst, nicht verbrauchbare Produkte und Erst-Abonnements werden bestätigt. Lesen Sie zuerst den Bestätigungsstatus, damit der Call nie doppelt hinausgeht.
Behalten Sie ein clientseitiges Backfill bei. Der Aufruf von queryPurchasesAsync() in onResume() erfasst alles, was sich erledigt hat, während die App geschlossen war. Betrachten Sie das als Absicherung, nicht als Hauptweg.
Der ganze Sinn dahinter ist, dass die Bestätigung von einem Ereignis ausgelöst wird, das Google Ihnen liefert, statt von einer Nutzeraktion, die Sie unmöglich garantieren können. Jemand, der einmal kauft und nie wiederkommt, ist trotzdem vollständig abgedeckt, weil Ihr Server die Arbeit bereits erledigt hat, sobald der Kauf eingegangen ist.
Ein Rückhalt für alles, was trotzdem durchrutscht
Egal wie gut die Pipeline gebaut ist, sie verdient trotzdem ein Sicherheitsnetz darunter. Googles Voided Purchases API listet Bestellungen auf, die mit einer Rückerstattung, einem Widerruf oder einem Chargeback endeten, und sie hebt das besondere Szenario hervor, bei dem die Ursache ein Kauf war, der „vom Entwickler nie bestätigt wurde und daher möglicherweise nicht in den Aufzeichnungen des Entwicklers existiert". Fragen Sie sie regelmäßig ab, und Sie können jedem den Zugriff entziehen, dessen Bestellung Google leise hinter Ihrem Rücken rückgängig gemacht hat. Beachten Sie dabei aber die Grenze: Nur die letzten 30 Tage sind abrufbar, was dies zu einem geplanten Job macht statt zu etwas, das Sie vierteljährlich mal nebenbei erledigen.
iOS wurde nie dafür gebaut, Ihnen das anzutun
Wechseln Sie zum App Store, trifft nichts davon zu. Apple hat einen eigenen Abschlussschritt gebaut, das Abschließen einer Transaktion, nur läuft die Strafe für das Auslassen in die entgegengesetzte Richtung. Eine unabgeschlossene Transaktion bleibt in Apples Warteschlange stehen. Sie taucht bei jedem App-Start erneut auf, und erneut, sobald sich der Observer anmeldet, und gibt Ihnen wiederholt die Chance, das zu liefern, wofür der Kunde bezahlt hat. Apple löst dafür keine Rückabwicklung aus. Auf dieser Plattform gibt es nichts, was einem 72-Stunden-Rückerstattungs-Trigger ähnelt.
Genau deshalb kann sich ein einziges mentales Modell nicht über beide Stores spannen. Android gibt Ihnen einen Countdown und einen Verkauf, der sich auflöst, wenn Sie ihn verlieren. iOS gibt Ihnen eine dauerhafte Erinnerung und unbegrenzte Zeit, um darauf zu reagieren. Bringen Sie iOS-Gewohnheiten in eine Android-Codebasis, und früher oder später starren Sie auf einen Haufen rückgängig gemachter Bestellungen, für die niemand im Team eine Erklärung hat.
Genau diese Lücke zu schließen ist die Aufgabe von Refund Sensor. Die Bestätigung wird direkt durch die Store-Benachrichtigung ausgelöst, innerhalb von Augenblicken nach deren Eingang, während ein laufender Abgleich gegen die Voided Purchases API überall den Zugriff entzieht, wo Google eine Bestellung bereits hinter Ihrem Rücken rückgängig gemacht hat. Ein Countdown, den Sie verlieren könnten, wird zu einem Häkchen, das schon gesetzt war, bevor Sie überhaupt daran dachten, nachzusehen.
Wo diese Regeln dokumentiert sind
Häufig gestellte Fragen
Ihr Server hat den Acknowledgement-Call nicht rechtzeitig gesendet. Bleibt ein Kauf länger als drei Tage nach Erreichen des Status PURCHASED unbestätigt, macht Google den Verkauf automatisch rückgängig und entzieht die Berechtigung. Das liegt nicht am Kunden, und es ist auch keine von Google verhängte Strafe. Es fehlt lediglich der Acknowledgement-Call – und wenn Sie serverseitig direkt auf die Store-Benachrichtigung hin bestätigen, verschwindet das Problem vollständig.
Beide stoppen die Drei-Tage-Uhr, hinterlassen das Produkt aber in unterschiedlichen Zuständen. Das Einlösen über purchases.products.consume oder consumeAsync() ist für Verbrauchsartikel gedacht. Es löst die Frist auf und stellt den Artikel wieder zum Kauf bereit. Das Bestätigen über purchases.products.acknowledge, purchases.subscriptions.acknowledge oder acknowledgePurchase() ist für nicht verbrauchbare Produkte und Abonnements gedacht. Es bestätigt die Berechtigung, ohne das Produkt für einen erneuten Kauf freizugeben.
Nein, nur der erste Kauf. Google verlangt für Verlängerungen keine Bestätigung und markiert sie automatisch als bestätigt. Nur der anfängliche Abo-Kauf, der mit dem Status „ausstehende Bestätigung" eingeht, bleibt so lange Ihre Aufgabe, bis Sie ihn abschließen.
Nein, warten Sie auf PURCHASED. Ein Kauf im Status PENDING, etwa eine Barzahlung oder eine Freigabeanfrage durch Eltern, hat die Drei-Tage-Uhr noch gar nicht gestartet. Gewähren Sie die Berechtigung und senden Sie die Bestätigung erst, wenn der Status tatsächlich von PENDING zu PURCHASED gewechselt ist.
Nein, und das sollten Sie wissen, bevor Sie davon ausgehen, dass sich Android und iOS gleich verhalten. Eine unabgeschlossene StoreKit-Transaktion wird einfach bei jedem App-Start erneut zugestellt, bis Sie sie abschließen. Apple erstattet sie niemals automatisch. Die automatische Rückerstattung nach drei Tagen gibt es nur bei Google Play, daher brauchen die beiden Plattformen unterschiedliche Behandlung.
Die Rückerstattung selbst lässt sich nicht rückgängig machen. Was Sie tun können, ist abgleichen. Die Voided Purchases API zeigt erstattete und widerrufene Käufe der letzten 30 Tage an und markiert diejenigen, die speziell deshalb annulliert wurden, weil sie nie bestätigt wurden – so können Sie die gewährte Berechtigung entziehen. Für die Zukunft gilt: Bestätigen Sie direkt anhand der Store-Benachrichtigung, damit Ihnen der nächste Kauf nicht wieder durchrutscht.
