Wenn du einen Google Play Kauf nicht innerhalb von drei Tagen bestätigst, erstattet Google ihn, und das kostet dich Folgendes

Ein Kunde kauft dein Produkt, die Zahlung geht durch, und drei Tage später erstattet Google Play sie stillschweigend und zieht zurück, was du geliefert hast. Niemand hat um diese Erstattung gebeten. Der Kunde hat sie nicht angefordert, und kein Support-Mitarbeiter hat sie gewährt. Sie wurde ausgelöst, weil dein Server Google nie mitgeteilt hat, dass der Kauf verarbeitet wurde. Wenn du einen Google Play Kauf nicht innerhalb von drei Tagen bestätigst, erstattet Google dem Käufer und widerruft den Kauf, jedes Mal. Es ist eine der wenigen Erstattungen in beiden Stores, die vollständig durch deine Integration zu verhindern ist, und eine der leisesten Arten, Umsatz zu verlieren.

Das ist kein Betrugsproblem und kein Richtlinienstreit. Es ist ein verpasster Callback. Die Lösung ist klein und die Kosten des Weglassens sind echtes Geld, daher lohnt es sich, die Regel genau zu kennen, warum Käufe unbestätigt durchrutschen und was jeder verlorene Verkauf tatsächlich mit sich nimmt.

Was die Dreitagesregel tatsächlich besagt

Die Play Billing Dokumentation von Google ist dazu unmissverständlich. Nachdem deine App die Berechtigung gewährt und dem Nutzer mitgeteilt hat, dass der Kauf erfolgreich war, muss sie Google benachrichtigen, dass der Kauf verarbeitet wurde. In Googles Worten "muss dies innerhalb von drei Tagen erfolgen, damit der Kauf nicht automatisch erstattet und die Berechtigung widerrufen wird." Die Seite zu Einmalprodukten wiederholt es ohne Abschwächung: "Wenn du einen Kauf nicht innerhalb von drei Tagen bestätigst, erhält der Nutzer automatisch eine Erstattung, und Google Play widerruft den Kauf." Abonnements tragen für den Erstkauf die identische Regel.

Die Bestätigung ist ein Signal, keine Formalität. Sie teilt Google mit, dass die Berechtigung den Nutzer erreicht hat. Google behandelt das Fehlen dieses Signals als eine Lieferung, die nie stattgefunden hat, und macht die Transaktion im Namen des Kunden rückgängig. Aus Sicht des Käufers sieht es aus wie eine kostenlose Erstattung, um die er nie gebeten hat. Aus deiner Sicht sieht es aus wie ein Verkauf, der sich in Luft aufgelöst hat.

Die Uhr startet bei PURCHASED, nicht beim Checkout

Das Dreitagesfenster beginnt nicht, wenn der Nutzer auf Kaufen tippt. Es beginnt, wenn der Kaufstatus zu PURCHASED wechselt. Ein Kauf kann zunächst in PENDING liegen, was bei Barzahlungen, langsamen Banküberweisungen oder wenn ein Elternteil die Anfrage eines Kindes genehmigt vorkommt. Google ist eindeutig: "Das Dreitagesfenster für die Bestätigung beginnt erst, wenn der Kaufstatus von PENDING zu PURCHASED wechselt."

Das hat zwei Konsequenzen. Gewähre die Berechtigung nur, wenn der Status PURCHASED ist, niemals bei PENDING, sonst gibst du Produkt für eine Zahlung heraus, die vielleicht nie abgeschlossen wird. Und bestätige auch keinen PENDING-Kauf. Du rufst enablePendingPurchases() auf, wenn du den BillingClient erstellst, wartest auf den Wechsel und startest erst dann im Kopf die Bestätigungsuhr.

Bestätigen oder verbrauchen, und was du schuldest

Es gibt zwei Möglichkeiten, die Anforderung zu erfüllen, und welche du verwendest, hängt vom Produkt ab. Beide halten die Dreitagesfrist ein. Der Unterschied liegt darin, was sie sonst noch tun.

Bei einem Verbrauchsartikel verbrauchst du ihn. Auf einem sicheren Backend ist das purchases.products.consume, oder clientseitig consumeAsync() in der Play Billing Library. Das Verbrauchen bestätigt den Kauf und macht das Produkt wieder kaufbar, was genau das ist, was du für Münzen, Credits oder eine einmalige Generierung willst. Bei einem Nicht-Verbrauchsartikel oder einem Abonnement bestätigst du es: purchases.products.acknowledge oder purchases.subscriptions.acknowledge auf dem Backend, oder acknowledgePurchase() clientseitig. Das Bestätigen hält die Frist ein, ohne das Produkt für einen erneuten Kauf freizugeben.

Verlängerungen sind bereits erledigt, Erstkäufe nicht

Du schuldest die Bestätigung nur beim ersten Kauf eines Abonnements. Google stellt klar fest, dass "du Abonnementverlängerungen nicht bestätigen musst," und markiert Verlängerungen von sich aus als ACKNOWLEDGEMENT_STATE_ACKNOWLEDGED. Ein neuer Kauf kommt als ACKNOWLEDGEMENT_STATE_PENDING an und bleibt in deiner Verantwortung, bis du ihn erledigst. Bevor du bestätigst, prüfe acknowledgementState auf dem Backend oder isAcknowledged() clientseitig, damit du nicht doppelt bestätigst.

Prepaid-Pläne haben eine kürzere Zündschnur

Prepaid-Abonnementpläne verengen das Fenster. Googles Regel: Prepaid-Pläne, die eine Woche oder länger dauern, müssen innerhalb von drei Tagen bestätigt werden, aber "Prepaid-Pläne mit einer Dauer von weniger als einer Woche müssen innerhalb der Hälfte der Plandauer bestätigt werden." Ein dreitägiger Prepaid-Plan gibt dir eineinhalb Tage, nicht drei Tage. Wenn du kurze Prepaid-Aufladungen verkaufst, muss dein Bestätigungspfad schnell und serverseitig gesteuert sein, nicht davon abhängig, dass der Nutzer die App erneut öffnet.

Warum Käufe überhaupt unbestätigt bleiben

Niemand nimmt sich vor, die Bestätigung zu überspringen. Sie rutscht durch, weil der Code, der bestätigt, an der falschen Stelle liegt. Das übliche Anti-Muster ist ein Client, der nur bestätigt, wenn der Kaufablauf im Vordergrund zurückkehrt. Das funktioniert für einen Nutzer, der den Kauf abschließt und die App weiter nutzt. Bei allen anderen scheitert es.

Entwickler stoßen ständig darauf. Threads in Googles eigener Entwickler-Community lesen sich jedes Mal gleich, irgendeine Variante von "ein Nutzer wurde nach dem Kauf aus meiner App nach drei Tagen automatisch erstattet" und "warum werden Zahlungen nach drei Tagen automatisch erstattet." Die Antwort ist fast immer dieselbe: Der Bestätigungsaufruf ist nie ausgelöst worden, weil die App nie in einem Zustand war, ihn auszulösen.

Die kostenlose Testphase und der Nutzer, der nie zurückkommt

Die schlimmste Variante ist die kostenlose Testphase oder ein Kauf kurz bevor der Nutzer die App für immer schließt. Wenn deine Bestätigung vom nächsten App-Öffnen abhängt und es kein nächstes App-Öffnen gibt, altert der Kauf aus. Am dritten Tag erstattet und widerruft Google ihn. Bei einer Testphase, die zu einem bezahlten Abonnement geworden wäre, verlierst du die erste Abrechnung, die du nie einziehen konntest, plus eine Kundenberechtigung, die stillschweigend verschwunden ist. Keines der beiden Ereignisse taucht als Support-Ticket auf. Es taucht als stornierter Kauf auf, nach dem du suchen musst.

Was eine unbestätigte Erstattung tatsächlich kostet

Die Erstattungsposition untertreibt den Verlust. Wenn Google den Verkauf rückgängig macht, gibst du den Preis zurück, und das ist die sichtbare Zahl. Es ist nicht die ganze Rechnung.

Denk an einen Verbrauchsartikel, der in dem Moment, in dem er gekauft wird, echte Arbeit auslöst. Eine Reihe von Bildgenerierungen, eine Serie von Aufrufen an die API eines Modellanbieters, ein Videoexport, eine Auszahlung an einen Creator. Du hast für diese Rechenleistung, diese API-Aufrufe, diesen Speicher und diese Auszahlungen zum Zeitpunkt der Nutzung bezahlt. Die Erstattung gibt dem Kunden den Verkaufspreis zurück. Sie gibt dir nicht die Rechnung des Anbieters zurück. Du hast echte Kosten geliefert und nichts dafür zurückbekommen.

Bei Abonnements und Testphasen ist der Verlust die erste Abrechnung, die du nie einziehst, und die Kundenbeziehung, die endete, bevor sie begann. Und ab dem 3. August 2026 verlagert Google Play den Kaufpreis bei Rückbuchungen und Bankgebühren für nach diesem Datum aufgegebene Bestellungen auf die Entwickler, was jeden vermeidbaren Umsatzverlust jetzt und nicht später schließenswert macht. Eine unbestätigte Erstattung ist keine Rückbuchung, aber es ist dieselbe Lektion: Geld, das du bereits ausgegeben hast, ist nicht automatisch Geld, das du behältst.

Wie du einen Google Play Kauf serverseitig bestätigst

Das zuverlässige Muster nimmt die App aus dem kritischen Pfad. Erledige es auf deinem Backend, gesteuert durch Benachrichtigungen, nicht dadurch, dass der Nutzer den Bildschirm erneut öffnet.

• Höre auf Real-time developer notifications. Ein ONE_TIME_PRODUCT Kauf oder ein SUBSCRIPTION_PURCHASED Ereignis teilt deinem Server mit, dass ein Kauf existiert, in dem Moment, in dem Google es weiß, egal ob die App geöffnet ist oder nicht.
• Verifiziere den Kauf-Token gegen die Play Developer API und bestätige, dass der Status PURCHASED ist, nicht PENDING.
• Gewähre die Berechtigung in deinen eigenen Datensätzen, mit dem Nutzer als Schlüssel.
• Bestätige oder verbrauche sofort. Verbrauche Verbrauchsartikel, bestätige Nicht-Verbrauchsartikel und Erstabonnements. Prüfe zuerst acknowledgementState, damit du nie doppelt bestätigst.
• Fülle auch auf dem Client nach. Rufe queryPurchasesAsync() in onResume() auf, damit jeder Kauf, der abgeschlossen wurde, während die App geschlossen war, trotzdem verarbeitet wird. Das ist ein Sicherheitsnetz, nicht der primäre Pfad.

Der Punkt ist, dass die Bestätigung von einem Ereignis ausgelöst wird, das Google dir sendet, nicht von einer Nutzeraktion, auf die du dich nicht verlassen kannst. Ein Nutzer, der kauft und nie zurückkehrt, ist vollständig abgedeckt, weil dein Server in dem Moment gehandelt hat, in dem der Kauf einging.

Ein Abgleichsnetz für die, die durchrutschen

Selbst eine saubere Pipeline profitiert von einer Kontrolle. Die Voided Purchases API listet Käufe auf, die erstattet, widerrufen oder zurückgebucht wurden, und benennt den Fall, in dem der Grund ist, dass der Kauf "nie vom Entwickler bestätigt wurde und daher möglicherweise nicht in den Datensätzen des Entwicklers existiert." Frage sie ab, und du kannst die Berechtigung widerrufen, die du für alles gewährt hast, was Google bereits rückgängig gemacht hat. Beachte die Grenze: Die API gibt nur stornierte Käufe der letzten 30 Tage zurück, daher muss der Abgleich nach einem Zeitplan laufen, nicht einmal pro Quartal.

Apple hat kein Äquivalent, und das ist wichtig

Das ist speziell ein Google Play Problem. Apples StoreKit hat auch einen Abschlussschritt, das Abschließen einer Transaktion, aber im Fehlerfall tut es das Gegenteil. Wenn du eine StoreKit-Transaktion nie abschließt, behält Apple sie in der Warteschlange und stellt sie jedes Mal erneut zu, wenn deine App startet oder der Observer sich anhängt, sodass du eine weitere Chance bekommst, die Berechtigung zu gewähren. Apple erstattet eine nicht abgeschlossene Transaktion nicht. Es gibt keine automatische Dreitageserstattung im App Store.

Das mentale Modell muss also plattformspezifisch bleiben. Bei Google Play ist ein unbehandelter Kauf eine Erstattung, die darauf wartet zu passieren, und eine Frist, gegen die du rennst. Im App Store ist ein unbehandelter Kauf eine erneute Zustellung, die darauf wartet zu passieren, und überhaupt keine Uhr. Die Apple-Annahme auf Android zu übertragen, ist die Art, wie Teams am Ende eine Wand aus unbestätigten Erstattungen haben, die sie nicht erklären können.

Deshalb bestätigt RefundHalt Google Play Käufe automatisch in dem Moment, in dem die Store-Benachrichtigung eintrifft, und gleicht gegen die Voided Purchases API ab, damit eine Berechtigung, die für einen Kauf gewährt wurde, den Google später rückgängig gemacht hat, nicht aktiv bleibt. Die Dreitagesregel hört auf, ein Rennen zu sein, das du verlieren kannst, und wird zu einem Schritt, der bereits passiert ist.