Gemiste terugbetalingsmeldingen kunnen je de enige terugbetalingen kosten die je mag aanvechten, en beide stores laten je ze terughalen als je op tijd kijkt

Gemiste terugbetalingsmeldingen zijn de stille manier waarop een ontwikkelaar de enige twee terugbetalingsbeslissingen verliest waarin hij iets te zeggen heeft. Apples CONSUMPTION_REQUEST en de chargebackbeoordeling van Google Play beginnen allebei met een melding, en allebei lopen ze op een korte klok: 12 uur bij Apple, 24 uur bij Google. Is je server plat, traag of verkeerd ingesteld als dat bericht binnenkomt, dan wacht de store niet op je. Hij beslist met wat hij al heeft.

Het goede nieuws: geen van beide stores gooit het bericht weg bij de eerste mislukking. Apple probeert het opnieuw en houdt een geschiedenis van 180 dagen bij die je kunt opvragen. Google publiceert via Pub/Sub, dat onbevestigde berichten dagenlang vasthoudt. Het slechte nieuws: de herhaaltijden sluiten niet aan op de antwoordvensters, en een van de twee processen heeft helemaal geen herstel-API.

Hoe elke store terugbetalingsmeldingen aflevert

Apple stuurt App Store Server Notifications rechtstreeks naar een HTTPS-URL die je instelt in App Store Connect. Google roept je server niet rechtstreeks aan. Het publiceert realtime ontwikkelaarsmeldingen naar een Google Cloud Pub/Sub-topic, en je abonnement op dat topic pusht ze naar je endpoint of wacht tot je server ze ophaalt.

Wat Apple als mislukking ziet

Apples documentatie is duidelijk. Geef je een status van 200 tot en met 206 terug, dan is de levering klaar. Geef je een 40x of 50x terug, dan probeert Apple het opnieuw. Elke andere code beschouwt Apple ook als mislukt. Elke poging wordt vastgelegd met een sendAttemptResult, en de waarden lezen als een checklist van echte storingen: TIMED_OUT, TLS_ISSUE, CIRCULAR_REDIRECT, NO_RESPONSE, PREMATURE_CLOSE, UNSUCCESSFUL_HTTP_RESPONSE_CODE en nog een paar. Bij TIMED_OUT raadt Apple zelf aan te controleren of je server berichten niet direct in de request verwerkt.

Wat Google als mislukking ziet

Bij een push-abonnement is een succescode van je endpoint de bevestiging. Bij een pull-abonnement moet je server elk opgehaald bericht bevestigen, anders levert Pub/Sub het opnieuw. De standaard bevestigingstermijn is 10 seconden en het maximum is 600 seconden. Googles RTDN-handleiding voegt een regel toe die het herhalen waard is: een melding zegt alleen dat er iets is veranderd. De volledige aankoopstatus haal je nog steeds op via de Google Play Developer API.

Waarom Apples herhaalschema niet past bij het venster van 12 uur

Apples herhaalintervallen tellen vanaf de vorige poging, niet vanaf de eerste. Tel ze op en je krijgt deze tijdlijn voor één V2-melding waarop je server steeds faalt.

Apple vraagt je binnen 12 uur na ontvangst van de CONSUMPTION_REQUEST te antwoorden. Is je server plat bij de eerste levering en bij de herhaling een uur later, dan komt de volgende poging 13 uur na de eerste. Apple zegt niet of een verzoek dat je pas bij een herhaling ontvangt, opnieuw 12 uur krijgt. De voorzichtige lezing is dat de klok start bij de eerste poging. Herhalingen alleen redden dus geen verzoek dat je met meer dan een uur hebt gemist.

Herhaalt Apple na een HTTP 400?

Volgens de documentatie wel. Apple noemt 40x en 50x als de codes die een herhaling starten. In maart 2026 meldde een ontwikkelaar op Apples forums dat herhalingen na 400-antwoorden leken te stoppen, en schreef later dat de leveringen een dag of twee daarna weer liepen. Apple vroeg om een melding via Feedback Assistant. Zie het gedocumenteerde gedrag als de regel en je eigen monitoring als het bewijs.

Gemiste App Store-meldingen herstellen met Get Notification History

Get Notification History geeft de meldingen van versie 2 terug die Apple in een door jou gekozen periode naar je server probeerde te sturen. Elk record bevat de volledige ondertekende payload, dus je kunt hem aan dezelfde handler geven als een live melding. Elk record bevat ook een array sendAttempts met maximaal zes items, één voor de eerste poging en één voor elk van de vijf herhalingen.

• startDate en endDate zijn verplicht, en startDate moet in productie binnen de afgelopen 180 dagen vallen en in de sandbox binnen de afgelopen 30 dagen.
• Zet onlyFailures op true om alleen de meldingen te krijgen die je server niet hebben bereikt, plus de meldingen die Apple nog herhaalt.
• Filter op één notificationType, zoals CONSUMPTION_REQUEST of REFUND, of op een transactionId voor één klant, maar niet op beide in hetzelfde verzoek.
• Elke aanroep geeft maximaal 20 records terug. Blijf aanroepen met het paginationToken zolang hasMore true is, en stuur elke keer dezelfde request-body.

Eén kanttekening is belangrijk voor terugbetalingen. Volgens Apple tonen geschiedenisrecords de status van een aankoop op het moment dat de melding voor het eerst werd verstuurd, niet de huidige. Een herstelde REFUND is dus een feit uit het verleden. Controleer de huidige status via de endpoints voor transacties of abonnementsstatus voordat je toegang intrekt.

V1-meldingen kun je zo niet herstellen

Get Notification History dekt alleen versie 2. Apple herhaalt V1-meldingen drie keer, 6, 24 en 48 uur na de vorige poging, en als die allemaal mislukken, is er geen geschiedenis om opnieuw af te spelen. Nog een reden om elke app die nog V1 gebruikt over te zetten naar V2.

Gemiste terugbetalingsmeldingen van Google Play herstellen

Googles vangnet is Pub/Sub zelf. Zolang je abonnement bestaat, blijft een bericht dat niemand heeft bevestigd daar staan voor de bewaartermijn, standaard 7 dagen en tot 31 dagen als je die verhoogt. Komt je endpoint terug, dan gaat de levering verder. Twee instellingen kunnen dat ongemerkt tenietdoen.

• Een dead-letter-topic haalt een bericht uit je abonnement na een ingesteld aantal mislukte leverpogingen. De standaard is 5, en met het standaard herhaalbeleid van directe herlevering zijn vijf pogingen snel voorbij. Gebruik je er een, houd het dead-letter-topic dan in de gaten als een tweede inbox.
• Een abonnement zonder abonneeactiviteit, zoals open verbindingen, actieve pulls of geslaagde pushes, verloopt standaard na 31 dagen. Een endpoint dat een maand kapot blijft, kan het abonnement zelf kwijtraken, met alles wat erin wacht.

Ongeldig gemaakte terugbetalingen hebben een back-up van 30 dagen

Voor terugbetalingen die al hebben plaatsgevonden, is de Voided Purchases API de pull-back-up. Hij toont ongeldig gemaakte aankopen van de afgelopen 30 dagen, tot 1.000 per pagina, met een quotum van 6.000 query's per dag en 30 query's per periode van 30 seconden per app. Geef type 1 mee om naast eenmalige producten ook abonnementen op te nemen. Draai je hem dagelijks, dan vang je elke terugbetaling op die je meldingsketen liet vallen, en blijven rechten en omzetcijfers kloppen.

Chargebackbeoordelingen hebben er geen

Een PendingRefundReviewNotification is anders. Die bevat het pendingRefundToken dat je moet meegeven aan orders.reviewrefund, en je hebt vanaf ontvangst 24 uur om je terugbetalingsvoorkeur en gebruiksbewijs te sturen. Google registreert je eerste aanroep en negeert de rest. Googles documentatie beschrijft geen endpoint dat openstaande beoordelingen opsomt. Raakt dat Pub/Sub-bericht kwijt, dan raakt je bewijs voor die chargeback mee kwijt.

Wat een gemiste terugbetalingsmelding in geld kost

Een gemiste melding voor een terugbetaling die al definitief is, kost je administratie. Je vindt hem later in de Voided Purchases API of in Get Notification History, trekt toegang in als je beleid dat voorschrijft, en je rapporten lopen weer bij. Vervelend, maar goedkoop.

Een gemiste melding in een van de twee aanvechtbare processen kost echt geld, omdat de store zonder jouw bewijs beslist. Bij Apple valt de terugbetalingsbeslissing dan zonder je verbruiksgegevens. Bij Google Play kost een verloren chargeback je voor bestellingen vanaf 3 augustus 2026 de aankoopprijs min de servicekosten van Play, plus de chargebackkosten die de bank van de koper rekent. Google vergoedt alleen zijn eigen servicekosten.

En het geld dat je uitgaf om de aankoop te leveren, was al weg voordat het geschil begon.

• Rekenkracht: GPU- en servertijd achter elke generatie, render of modelreactie die de koper al heeft gebruikt.
• API-aanroepen: verzoeken aan derden die werden gefactureerd zodra ze werden verstuurd, vaak per aanroep.
• Opslag: bestanden en media die de koper heeft gemaakt en die nog op je hostingrekening staan.
• Uitbetalingen: omzetaandelen die voor die verkoop al zijn betaald aan makers, affiliates of partners.

Niets daarvan komt terug als een terugbetaling doorgaat. Het bewijs dat je in die 12 of 24 uur stuurt, is je enige hefboom, en een gemiste melding neemt die weg.

Een herstelroutine die standhoudt

• Eerst bevestigen. Sla de ruwe payload op, geef een succescode terug en verwerk hem daarna in een wachtrij.
• Vraag Apples Get Notification History om de paar minuten met onlyFailures op CONSUMPTION_REQUEST, zodat een storing je minuten van het venster van 12 uur kost.
• Draai dagelijks een ronde Get Notification History met onlyFailures over de afgelopen paar dagen voor alle typen, en speel opnieuw af wat je vindt.
• Roep dagelijks de Voided Purchases API aan met type 1 voor elke Google Play-app, en vergelijk het resultaat met de terugbetalingen die je al hebt vastgelegd.
• Houd bij Pub/Sub de berichtbewaring op 7 dagen of meer, stel een alarm in op het dead-letter-topic als je er een hebt, en stel een alarm in als onbezorgde berichten zich opstapelen.
• Test het hele pad ook in productie. Apples sandbox stuurt elke melding één keer zonder herhalingen, en Request a Test Notification samen met Get Test Notification Status laat precies zien hoe je server antwoordde.

RefundHalt ontvangt de meldingen van beide stores voor je en beantwoordt CONSUMPTION_REQUEST en chargebackbeoordelingen automatisch binnen hun termijnen. Jij hoeft de klok dus niet in de gaten te houden.