App Store terugbetaling: wat ziet de developer?

In de App Store is het Apple dat een terugbetaling toekent of weigert, nooit de developer. De klant dient zijn verzoek in op de site van Apple of vanuit je app. Als je de servermeldingen van Apple hebt ingesteld, krijg je een CONSUMPTION_REQUEST-melding op het moment van het verzoek, en daarna REFUND of REFUND_DECLINED bij de beslissing. Daartussen heb je 12 uur om verbruiksgegevens en je voorkeur te sturen, op voorwaarde dat de klant daarmee heeft ingestemd.

Een toegekende terugbetaling haalt de aankoop uit de actieve rechten van de klant en verschijnt als negatief in je verkooprapporten. Deze gids beschrijft elke stap, wat je naar Apple kunt sturen, en wat je mag doen tegen misbruik. De regels komen van de pagina's van Apple, nagelezen op 3 november 2026. Het echte voorbeeld komt van een alert die ik in oktober op mijn apps heb aangesloten.

Wie beslist over een App Store-terugbetaling?

Apple, en alleen Apple. De supportpagina van Apple beschrijft het traject van de klant: hij logt in op reportaproblem.apple.com, kiest "Request a refund", geeft een reden op en daarna de betreffende aankoop. Apple raadt hem aan 24 tot 48 uur te wachten op een antwoord.

De klant kan ook vanuit je app een terugbetaling aanvragen. StoreKit biedt daarvoor een aanvraagscherm, beschikbaar sinds iOS 15. Apple raadt aan het op te roepen vanuit de accountinstellingen of een helpmenu. Het toont de aankoop en een lijst met redenen, en Apple neemt tot 48 uur de tijd om te beslissen.

In beide gevallen hoef jij niets goed te keuren. Je kunt alleen informatie en een voorkeur geven, die meetellen als een van meerdere criteria in de beslissing van Apple.

Wat iedereen ziet, stap voor stap

Stap	Kant van de klant	Kant van de developer
Verzoek	Formulier van Apple of scherm in de app	Melding CONSUMPTION_REQUEST
Binnen 12 uur	Wachten	Verbruiksgegevens sturen is mogelijk
Binnen 48 uur	Antwoord van Apple	Melding REFUND of REFUND_DECLINED
Na toekenning	Geld terug op zijn betaalmiddel	Aankoop uit actieve rechten, negatieve eenheden
Na een betwisting	Terugbetaling door Apple geannuleerd	Melding REFUND_REVERSED, toegang herstellen

App Store Connect toont je alleen al toegekende terugbetalingen, in Sales and Trends. Het verzoek zelf komt alleen binnen via de servermeldingen. Zonder die meldingen ontdek je de terugbetaling achteraf.

De servermeldingen bij een terugbetaling

De App Store Server Notifications V2 sturen vijf types die hier relevant zijn. Je ontvangt ze op het HTTPS-adres dat je in App Store Connect hebt opgegeven, één voor productie en één voor de sandbox.

Melding	Wat ze aankondigt	Wat je doet
CONSUMPTION_REQUEST	De klant vraagt een terugbetaling aan	Binnen 12 uur reageren, als er toestemming is
REFUND	Apple heeft de transactie terugbetaald	De terugbetaalde content of toegang intrekken
REFUND_DECLINED	Apple heeft het verzoek geweigerd	Niets, de toegang blijft
REFUND_REVERSED	Apple annuleert een terugbetaling na een betwisting door de klant	Herstellen wat je had ingetrokken
REVOKE	Een aankoop gedeeld via Delen met gezin is niet meer beschikbaar	Toegang van het gezinslid intrekken

Je server moet antwoorden met een HTTP-code tussen 200 en 206. Volgens de pagina over het beantwoorden van meldingen probeert Apple het anders vijf keer opnieuw, 1, 12, 24, 48 en daarna 72 uur na de vorige poging. In de sandbox stuurt Apple maar één keer.

De Consumption API: wat je Apple kunt vertellen

Als het verzoek binnenkomt, kun je antwoorden met Send Consumption Information. De regel past in één zin van Apple: "Respond within 12 hours of receiving the CONSUMPTION_REQUEST notification." Versie 2 van de API geldt voor alle producttypes, abonnementen inbegrepen.

De velden van het request:

Veld	Verplicht	Wat het Apple vertelt
customerConsented	Ja	De klant heeft ingestemd met het delen van zijn gegevens
deliveryStatus	Ja	De aankoop is geleverd en werkt, of waarom dat niet zo is
sampleContentProvided	Ja	Er was vóór de aankoop een proefversie, fragment of beschrijving beschikbaar
consumptionPercentage	Nee	Het verbruikte deel, van 0 tot 100.000 voor 0 tot 100 %
refundPreference	Nee	Je voorkeur: DECLINE, GRANT_FULL of GRANT_PRORATED

Twee details zijn belangrijk. Als deliveryStatus niet DELIVERED is, moet het verbruikte deel nul zijn. En bij een pro-rata terugbetaling van een abonnement laat je het verbruikte deel weg: Apple berekent het zelf.

Toestemming is de voorwaarde voor alles. Apple schrijft: "You must obtain valid consent from the customer before sharing their personal data with Apple in the Send Consumption Information API." Zonder toestemming antwoord je niet. Apple verbiedt ook om het venster voor advertentietracking te gebruiken om die toestemming te vragen: "Don't use the AppTrackingTransparency prompt to obtain consent".

Als je RevenueCat gebruikt

Met RevenueCat ontvangt RevenueCat de meldingen van Apple en beantwoordt het het verzoek, met Refund Control. Je kiest uit vier beleidsopties: voorkeur voor een volledige terugbetaling, voorkeur voor een weigering, alleen de verbruiksgegevens sturen, of niet reageren.

Het delen van gegevens inschakelen betekent dat je bevestigt dat je de toestemming van je klanten hebt. RevenueCat zegt het zelf: "Enabling consumption data sharing confirms that you obtained consent from your Customers." Het raadt ook aan "Prefer no refund" te reserveren voor een gerichte groep, en waarschuwt als die voorkeur de meeste van je klanten raakt.

Om de meldingen ook op je eigen server te ontvangen, biedt RevenueCat een veld "Apple Server Notification Forwarding URL" in de app-instellingen. Het staat beschreven op de pagina over de meldingen van Apple. Dat gebruik ik. Hoe je een abonnement opzet met RevenueCat, lees je in RevenueCat en het in-app abonnement op iOS.

Het effect op je inkomsten en op het abonnement

Op de toegang. Volgens de documentatie van currentEntitlements: "Products that the App Store has refunded or revoked don't appear in the current entitlements". Als je app de rechten controleert met currentEntitlements, verdwijnt de terugbetaalde toegang vanzelf. De transactie bevat de datum en de reden van de intrekking, in revocationDate en revocationReason.

Op de rapporten. Volgens de help van het verkooprapport verschijnt een terugbetaling met negatieve eenheden en een negatieve klantprijs. Voor abonnementen telt de pagina over abonnementsgegevens volledige en gedeeltelijke terugbetalingen mee als events, en trekt ze af van de dagelijkse eenheden.

Op je reputatie. Guideline 5.6.4 noemt buitensporige terugbetalingsverzoeken als een van de tekenen van onvoldoende kwaliteit. Een hoog terugbetalingspercentage is niet alleen geldverlies: Apple kan er rekening mee houden bij het beoordelen of je je aan de gedragscode houdt.

Mijn geval: de alert op mijn apps

Op 12 oktober 2026 heb ik een alert op mijn apps aangesloten. RevenueCat stuurt de meldingen van Apple door naar een route op devoria.fr. Die controleert de handtekening van Apple en stuurt me dan een alert, zonder bedrag. Ik wilde het verzoek zien op het moment dat het binnenkomt, niet alleen het resultaat.

Op 18 oktober kwam het eerste echte verzoek binnen op TradaZen, mijn tradingsimulator. Een jaarabonnement, betaald aan het eind van een gratis proefperiode van 7 dagen. Opgegeven reden: een onbedoelde aankoop. Drie lessen:

1. Hetzelfde verzoek kan meerdere keren binnenkomen. Ik kreeg dezelfde alert drie keer op dezelfde avond. Sindsdien wordt elke alert ontdubbeld op het type melding en het transactie-ID.
2. De beslissing kwam binnen een dag. Apple weigerde ongeveer 22 uur na het verzoek. De klant hield zijn toegang.
3. Een weigering is niet het einde. Dezelfde klant diende twee dagen later opnieuw een verzoek in, voor dezelfde transactie.

Een verzoek wegens "onbedoelde aankoop" aan het eind van een proefperiode win je niet in je antwoord aan Apple. Dat voorkom je op de paywall, vóór de eerste betaling.

Misbruik beperken zonder de regels te overtreden

Wat mag:

• Elk verzoek beantwoorden met juiste gegevens, als de klant heeft ingestemd.
• Een gerichte voorkeur uitspreken, bijvoorbeeld een weigering voor een aankoop die al verbruikt is, in plaats van een weigering voor iedereen.
• Elke REFUND koppelen aan een klantaccount. De pagina van Apple over terugbetalingsmeldingen raadt dat aan om herhaalde terugbetalingen op te sporen.
• Vóór de aankoop duidelijk zeggen wat je koopt. Guideline 3.1.2(c) vraagt om te beschrijven wat de gebruiker voor de prijs krijgt, voordat je hem een abonnement aanbiedt.

Wat niet mag:

• Valse gegevens sturen om een verzoek te laten weigeren, of antwoorden zonder toestemming.
• Toestemming vragen via het venster voor advertentietracking, wat Apple met zoveel woorden uitsluit.
• De aankoop als val opzetten. Guideline 5.6 verbiedt klanten tot ongewilde aankopen te verleiden of te laten betalen voor wat niet geleverd wordt.
• Druk uitoefenen op een klant die een terugbetaling vraagt. Dezelfde regel eist respect in de klantenservice, zonder intimidatie.

De beste hefboom ligt nog steeds vooraf: een paywall die de prijs, de datum van de eerste betaling en de manier van opzeggen vermeldt. De fouten die je moet vermijden staan in de paywall-fouten, en de regels voor de proefperiode in de gratis proefperiode in de App Store.

Testen vóór productie

Volgens de pagina over het testen van verzoeken accepteren de sandbox en de StoreKit-tests van Xcode terugbetalingsverzoeken. In de sandbox leidt elke reden tot een automatische toekenning. Om een weigering te simuleren kies je "Other" en typ je DECLINE. Voor een pro-rata terugbetaling typ je GRANT_PRORATED. In de sandbox moet je verbruiksantwoord binnen vijf minuten verstuurd worden.

Een abonnement dat minder vaak wordt terugbetaald

De iOS & Android Kit vertrekt van de code van mijn apps, met onboarding, paywall en abonnementen al gecodeerd, en volgt vier stappen tot in de App Store, in je eigen tempo. De volledige opzet staat op de pagina in-app abonnement op iOS, en de regels van Apple voor abonnementen in guideline 3.1.2.

Voordat je je paywall lanceert: doe je gratis diagnose. Die vertelt je wat je project echt blokkeert en stuurt je mijn checklist tegen afwijzingen door Apple.

Veelgestelde vragen

Kan de developer een App Store-terugbetaling weigeren?

Nee. Apple beslist alleen. Je kunt verbruiksgegevens en een voorkeur sturen, bijvoorbeeld DECLINE, die meetellen als een van meerdere criteria. Apple heeft het laatste woord.

Wordt de developer op de hoogte gebracht van een terugbetalingsverzoek?

Ja, als hij de App Store Server Notifications V2 heeft ingesteld. Apple stuurt CONSUMPTION_REQUEST op het moment van het verzoek, en daarna REFUND of REFUND_DECLINED bij de beslissing. Zonder meldingen zie je alleen de toegekende terugbetalingen, in je rapporten.

Hoe lang doet Apple over een terugbetalingsverzoek?

Apple noemt 24 tot 48 uur aan de klant. De StoreKit-documentatie spreekt van maximaal 48 uur. Jij hebt 12 uur om de verbruiksgegevens te sturen.

Wat gebeurt er met de toegang na een terugbetaling?

De terugbetaalde aankoop verdwijnt uit de actieve rechten van de klant: StoreKit 2 geeft hem niet meer terug in currentEntitlements. Als Apple de terugbetaling daarna annuleert, krijg je REFUND_REVERSED en moet je de toegang herstellen.

Heb je toestemming van de klant nodig om Apple te antwoorden?

Ja. Apple eist geldige toestemming voordat je gegevens deelt via de Consumption API. Zonder die toestemming beantwoord je de melding niet. Het venster voor advertentietracking mag je niet gebruiken om haar te vragen.

Tellen terugbetalingen tegen mijn app?

Dat kan. Guideline 5.6.4 noemt buitensporige terugbetalingsverzoeken als een van de tekenen van onvoldoende kwaliteit, waar Apple rekening mee kan houden bij het beoordelen of je je aan de gedragscode houdt.