Bevestig je een Google Play aankoop niet binnen drie dagen, dan geeft Google het geld terug, en dit is wat dat je kost

Een klant koopt je product, de betaling gaat door, en drie dagen later geeft Google Play stilletjes het geld terug en haalt terug wat je hebt geleverd. Niemand heeft om die terugbetaling gevraagd. De klant heeft die niet aangevraagd, en geen supportmedewerker heeft die toegekend. Het ging af omdat je server Google nooit heeft verteld dat de aankoop was afgehandeld. Als je een Google Play aankoop niet binnen drie dagen bevestigt, geeft Google de koper geld terug en trekt de aankoop in, elke keer. Het is een van de weinige terugbetalingen in beide stores die volledig door jouw integratie te voorkomen is, en een van de stilste manieren om omzet te verliezen.

Dit is geen fraudeprobleem of een beleidsgeschil. Het is een gemiste callback. De oplossing is klein en de kosten van het overslaan zijn echt geld, dus het is de moeite waard om de regel precies te kennen, waarom aankopen onbevestigd doorglippen, en wat elke verloren verkoop daadwerkelijk meeneemt.

Wat de driedaagse regel eigenlijk zegt

De Play Billing documentatie van Google is er onomwonden over. Nadat je app het recht heeft verleend en de gebruiker heeft verteld dat de aankoop is gelukt, moet die Google op de hoogte stellen dat de aankoop is verwerkt. In Googles woorden "moet dit binnen drie dagen gebeuren zodat de aankoop niet automatisch wordt terugbetaald en het recht wordt ingetrokken." De pagina over eenmalige producten herhaalt het zonder verzachting: "Als je een aankoop niet binnen drie dagen bevestigt, ontvangt de gebruiker automatisch een terugbetaling, en trekt Google Play de aankoop in." Abonnementen dragen dezelfde regel voor de eerste aankoop.

Bevestiging is een signaal, geen formaliteit. Het vertelt Google dat het recht de gebruiker heeft bereikt. Google behandelt het ontbreken van dat signaal als een levering die nooit heeft plaatsgevonden, en draait de transactie terug namens de klant. Vanuit de kant van de koper ziet het eruit als een gratis terugbetaling waar hij nooit om heeft gevraagd. Vanuit jouw kant ziet het eruit als een verkoop die is verdampt.

De klok start bij PURCHASED, niet bij het afrekenen

Het driedaagse venster begint niet wanneer de gebruiker op kopen tikt. Het begint wanneer de aankoopstatus overgaat naar PURCHASED. Een aankoop kan eerst in PENDING staan, wat gebeurt bij contante betalingen, trage bankoverschrijvingen, of een ouder die het verzoek van een kind goedkeurt. Google is expliciet: "Het driedaagse bevestigingsvenster begint pas wanneer de aankoopstatus overgaat van PENDING naar PURCHASED."

Dat heeft twee gevolgen. Verleen het recht alleen wanneer de status PURCHASED is, nooit bij PENDING, anders geef je product weg voor een betaling die misschien nooit wordt voltooid. En bevestig ook geen PENDING-aankoop. Je roept enablePendingPurchases() aan wanneer je de BillingClient bouwt, wacht op de overgang, en start pas dan de bevestigingsklok in je hoofd.

Bevestigen of verbruiken, en welke je verschuldigd bent

Er zijn twee manieren om aan de eis te voldoen, en welke je gebruikt hangt af van het product. Beide halen de driedaagse deadline. Het verschil zit in wat ze verder doen.

Voor een verbruiksartikel verbruik je het. Op een veilige backend is dat purchases.products.consume, of aan de clientkant consumeAsync() in de Play Billing Library. Verbruiken bevestigt de aankoop en maakt het product weer koopbaar, wat precies is wat je wilt voor munten, credits, of een eenmalige generatie. Voor een niet-verbruiksartikel of een abonnement bevestig je het: purchases.products.acknowledge of purchases.subscriptions.acknowledge op de backend, of acknowledgePurchase() aan de clientkant. Bevestigen haalt de deadline zonder het product vrij te geven voor herhaalaankoop.

Verlengingen zijn al afgehandeld, eerste aankopen niet

Je bent alleen bevestiging verschuldigd bij de eerste aankoop van een abonnement. Google stelt duidelijk dat "je abonnementsverlengingen niet hoeft te bevestigen," en stempelt verlengingen uit zichzelf als ACKNOWLEDGEMENT_STATE_ACKNOWLEDGED. Een nieuwe aankoop komt binnen als ACKNOWLEDGEMENT_STATE_PENDING en blijft jouw verantwoordelijkheid totdat je die afhandelt. Controleer voordat je bevestigt acknowledgementState op de backend of isAcknowledged() aan de clientkant zodat je niet dubbel bevestigt.

Prepaid-abonnementen krijgen een kortere lont

Prepaid-abonnementen verkleinen het venster. Googles regel: prepaid-abonnementen die een week of langer duren moeten binnen drie dagen worden bevestigd, maar "prepaid-abonnementen met een duur korter dan een week moeten binnen de helft van de abonnementsduur worden bevestigd." Een driedaags prepaid-abonnement geeft je anderhalve dag, niet drie dagen. Als je korte prepaid-oplaadingen verkoopt, moet je bevestigingspad snel en servergestuurd zijn, niet afhankelijk van de gebruiker die de app opnieuw opent.

Waarom aankopen überhaupt onbevestigd blijven

Niemand neemt zich voor om de bevestiging over te slaan. Het glipt door omdat de code die bevestigt op de verkeerde plek staat. Het gebruikelijke antipatroon is een client die alleen bevestigt wanneer de aankoopflow op de voorgrond terugkeert. Dat werkt voor een gebruiker die de aankoop afrondt en de app blijft gebruiken. Voor iedereen anders faalt het.

Ontwikkelaars lopen hier voortdurend tegenaan. Threads in Googles eigen ontwikkelaarscommunity lezen elke keer hetzelfde, een of andere variant van "een gebruiker kreeg na het kopen uit mijn app na drie dagen automatisch geld terug" en "waarom worden betalingen na drie dagen automatisch terugbetaald." Het antwoord is bijna altijd hetzelfde: de bevestigingsaanroep is nooit afgegaan omdat de app nooit in een staat was om die af te vuren.

De gratis proefperiode en de gebruiker die nooit terugkomt

De ergste versie is de gratis proefperiode of een aankoop vlak voordat de gebruiker de app voorgoed sluit. Als je bevestiging afhangt van de volgende keer dat de app wordt geopend, en er is geen volgende keer, dan verjaart de aankoop. Op dag drie geeft Google het geld terug en trekt de aankoop in. Voor een proefperiode die zou zijn omgezet naar een betaald abonnement, verlies je de eerste facturering die je nooit hebt kunnen innen, plus een klantrecht dat stilletjes is verdwenen. Geen van beide gebeurtenissen verschijnt als een supportticket. Het verschijnt als een ingetrokken aankoop waar je naar moet gaan zoeken.

Wat een onbevestigde terugbetaling daadwerkelijk kost

De terugbetalingsregel onderschat het verlies. Wanneer Google de verkoop terugdraait, geef je de prijs terug, en dat is het zichtbare getal. Het is niet de hele rekening.

Denk aan een verbruiksartikel dat echt werk in gang zet op het moment dat het wordt gekocht. Een reeks beeldgeneraties, een serie aanroepen naar de API van een modelaanbieder, een video-export, een uitbetaling aan een maker. Je hebt voor die rekenkracht, die API-aanroepen, die opslag en die uitbetalingen betaald op het moment van gebruik. De terugbetaling geeft de klant de verkoopprijs terug. Het geeft jou de factuur van de aanbieder niet terug. Je hebt een echte kostenpost geleverd en er niets voor teruggekregen.

Voor abonnementen en proefperiodes is het verlies de eerste facturering die je nooit int en de klantrelatie die eindigde voordat die begon. En vanaf 3 augustus 2026 verschuift Google Play de aankoopprijs bij terugboekingen en de bankkosten naar ontwikkelaars voor bestellingen die na die datum zijn geplaatst, wat elk vermijdbaar omzetlek nu de moeite waard maakt om te dichten in plaats van later. Een onbevestigde terugbetaling is geen terugboeking, maar het is dezelfde les: geld dat je al hebt uitgegeven is niet automatisch geld dat je houdt.

Hoe je een Google Play aankoop aan de serverkant bevestigt

Het betrouwbare patroon haalt de app uit het kritieke pad. Doe het op je backend, aangestuurd door notificaties, niet doordat de gebruiker het scherm opnieuw opent.

• Luister naar Real-time developer notifications. Een ONE_TIME_PRODUCT aankoop of een SUBSCRIPTION_PURCHASED gebeurtenis vertelt je server dat er een aankoop bestaat op het moment dat Google het weet, of de app nu open is of niet.
• Verifieer het aankooptoken tegen de Play Developer API en bevestig dat de status PURCHASED is, niet PENDING.
• Verleen het recht in je eigen administratie, gekoppeld aan de gebruiker.
• Bevestig of verbruik onmiddellijk. Verbruik verbruiksartikelen, bevestig niet-verbruiksartikelen en eerste abonnementen. Controleer eerst acknowledgementState zodat je nooit dubbel bevestigt.
• Vul ook aan de clientkant bij. Roep queryPurchasesAsync() aan in onResume() zodat elke aankoop die is voltooid terwijl de app gesloten was toch wordt verwerkt. Dit is een vangnet, niet het primaire pad.

Het punt is dat de bevestiging afgaat op een gebeurtenis die Google je stuurt, niet op een gebruikersactie waar je niet op kunt rekenen. Een gebruiker die koopt en nooit terugkomt is volledig gedekt omdat je server handelde op het moment dat de aankoop binnenkwam.

Een afstemmingsnet voor degene die doorglippen

Zelfs een schone pijplijn heeft baat bij een controle. De Voided Purchases API somt aankopen op die zijn terugbetaald, ingetrokken of teruggeboekt, en benoemt het geval waarin de reden is dat de aankoop "nooit door de ontwikkelaar is bevestigd, en daarom mogelijk niet bestaat in de administratie van de ontwikkelaar." Vraag die op en je kunt het recht intrekken dat je hebt verleend voor alles wat Google al heeft teruggedraaid. Let op de limiet: de API geeft alleen ingetrokken aankopen van de afgelopen 30 dagen terug, dus de afstemming moet op een schema draaien, niet eens per kwartaal.

Apple heeft geen equivalent, en dat is belangrijk

Dit is specifiek een Google Play probleem. Apples StoreKit heeft ook een afrondstap, het afronden van een transactie, maar het doet het tegenovergestelde bij een fout. Als je een StoreKit-transactie nooit afrondt, houdt Apple die in de wachtrij en bezorgt die opnieuw elke keer dat je app start of de observer zich koppelt, zodat je nog een kans krijgt om het recht te verlenen. Apple geeft geen geld terug voor een niet-afgeronde transactie. Er is geen automatische driedaagse terugbetaling in de App Store.

Dus het mentale model moet platformspecifiek blijven. Bij Google Play is een onafgehandelde aankoop een terugbetaling die staat te gebeuren en een deadline waar je tegen racet. In de App Store is een onafgehandelde aankoop een herbezorging die staat te gebeuren en helemaal geen klok. De Apple-aanname naar Android overzetten is hoe teams eindigen met een muur van onbevestigde terugbetalingen die ze niet kunnen verklaren.

Daarom bevestigt RefundHalt Google Play aankopen automatisch op het moment dat de storenotificatie binnenkomt, en stemt af tegen de Voided Purchases API zodat een recht dat is verleend voor een aankoop die Google later heeft teruggedraaid niet actief blijft. De driedaagse regel houdt op een race te zijn die je kunt verliezen en wordt een stap die al is gebeurd.