Abonnementsrestituties werken niet zoals eenmalige restituties, en de store waarop je zit bepaalt hoeveel inspraak je krijgt

Een abonnement restitueren en een enkele in-app-aankoop restitueren voelen als dezelfde knop. Dat zijn ze niet. Een eenmalige aankoop is één afschrijving die je teruggeeft. Een abonnement is een terugkerende afschrijving met een lopend recht eraan, dus abonnementsrestituties moeten twee vragen beantwoorden die een eenmalige restitutie nooit stelt: hoeveel van de huidige periode geef je terug, en blijft het abonnement lopen. De App Store en Google Play beantwoorden die twee vragen op tegengestelde wijze, en het gat bepaalt hoeveel controle je hebt en hoeveel geld je rekening verlaat.

Hier is de korte kaart. In de App Store bezit Apple de beslissing en verneem je het achteraf. Bij Google Play houd je de knoppen vast en kies je zelf volledig of naar rato. Dit loopt door beide stores, de exacte velden en meldingen die elk gebruikt, welke bestelling je aanraakt wanneer een abonnement vele malen is gefactureerd, en wat een abonnementsrestitutie werkelijk kost zodra je de rekenkracht meetelt die je al hebt uitgegeven.

Hoe abonnementsrestituties verschillen van eenmalige restituties

Beide stores behandelen een restitutie als het terugdraaien van een specifieke bestelling. Voor een eenmalige aankoop is er maar één bestelling, dus er valt niets te kiezen. Een abonnement is een keten van bestellingen, één per factureringsperiode, met een recht dat ofwel actief is of niet. Die structuur is waarom een abonnementsrestitutie keuzes draagt die een eenmalige restitutie niet heeft.

De eenheid die wordt teruggedraaid is een factureringsperiode

Wanneer je een abonnement restitueert, geef je geen levenslange reeks betalingen terug. Je handelt op één bestelling in de keten, meestal de meest recente, die één factureringsperiode is. Een volledige restitutie geeft die hele periode terug. Een naar rato berekende restitutie geeft alleen het deel van de periode terug dat de klant nog niet heeft gebruikt. Hoe dan ook is de verkoop die je terugdraait de prijs van één periode, niet de hele geschiedenis van de klant met de app.

Wie beslist is het echte verschil

De scherpere scheiding is de bevoegdheid. In de App Store beslist Apple of een abonnementsrestitutie überhaupt plaatsvindt, en jij levert hooguit context. Bij Google Play beslis jij, en de API doet precies wat je zegt. Dezelfde uitkomst voor de klant, een volstrekt andere stoel voor de ontwikkelaar, en het verandert wat je bouwt om elk af te handelen.

Hoe de App Store een abonnementsrestitutie afhandelt

Aan Apples kant ben je een toeschouwer met een kleine microfoon. De klant praat met Apple, Apple neemt de beslissing, en je server leest het resultaat.

De klant vraagt het aan Apple, en Apple oordeelt

Een App Store-klant vraagt een abonnementsrestitutie aan op reportaproblem.apple.com, niet bij jou. Apple beoordeelt de aanvraag aan de hand van zijn eigen signalen en beslist. Jij keurt het niet goed, en er is geen Apple-consoleknop waarmee je een abonnementsrestitutie kunt uitgeven zoals Google Play toelaat. Apple heeft tot 90 dagen na de aankoop om een aanvraag ter beoordeling te aanvaarden, en zodra het oordeelt, is de beslissing die van Apple.

Wat je server ziet wanneer de restitutie binnenkomt

Je verneemt de uitkomst via App Store Server Notifications V2. Een toegekende restitutie komt binnen als een REFUND-melding, en de transactie draagt nu een revocationDate dat markeert wanneer de toegang moet eindigen. De autoRenewStatus van het abonnement wordt op false gezet, zodat het niet meer verlengt en de klant het recht verliest. Als Apple de aanvraag afwijst krijg je REFUND_DECLINED, en als Apple later een reeds toegekende restitutie terugdraait krijg je REFUND_REVERSED en komt het abonnement terug. Jouw taak is deze te lezen en de toegang om te schakelen, niet een stem uit te brengen.

Apple meet een abonnement op tijd, niet op jouw statistieken

Voor een verbruiksartikel kun je Apple via verbruiksgegevens vertellen hoeveel er is gebruikt. Voor een automatisch verlengend abonnement berekent Apple het verbruik zelf uit de verstreken tijd. Apples eigen voorbeeld is een klant die zes maanden in een jaarabonnement zit en er ongeveer 50 procent van heeft verbruikt. Jouw gebruiksstatistieken bepalen dus niet het getal voor een abonnement. De enige hendel die je kunt overhalen is refundPreference, en voor een abonnement is de relevante waarde GRANT_PRORATED, wat zegt dat je liever hebt dat Apple alleen het ongebruikte deel teruggeeft. Het is een voorkeur, geen beslissing. Apple oordeelt nog steeds.

Hoe Google Play een abonnementsrestitutie afhandelt

Google Play legt de beslissing in jouw handen. Er is een Play Console-scherm en een set API-methoden waarmee je een abonnement rechtstreeks kunt restitueren, kunt kiezen hoeveel, en kunt beslissen of de toegang eindigt. Dit is de tegenovergestelde houding van Apple, en het komt met keuzes die je goed moet krijgen.

Volledig of naar rato, en het is jouw keuze

De huidige manier om een abonnement te restitueren en in te trekken is purchases.subscriptionsv2.revoke, aangeroepen met een revocationContext. Geef fullRefund door en Google Play beëindigt het abonnement en geeft het volle bedrag van de huidige factureringsperiode terug. Geef proratedRefund door en Google Play beëindigt het abonnement en geeft alleen de resterende, ongebruikte rechttijd terug. De oudere methode kon alleen volledige restituties doen, wat de reden is om de nieuwere te gebruiken. Een naar rato berekende intrekking is een body van twee regels, een revocationContext die proratedRefund omhult, en je wisselt fullRefund in voor de hele periode. Elke intrekking activeert een SUBSCRIPTION_REVOKED realtime-ontwikkelaarsmelding, wat jouw signaal is om de toegang af te snijden.

Welke bestelling je restitueert verandert wat er gebeurt

Google Play laat je ook een bestelling restitueren zonder in te trekken, via orders.refund, en hier bijt een subtiele regel. Als je de meest recente bestelling van een abonnement restitueert, wordt de bestelling gerestitueerd, het abonnement onmiddellijk verwijderd, en toekomstige herhalingen geannuleerd. Als je een oudere bestelling in de keten restitueert, wordt die bestelling gerestitueerd maar blijft het abonnement actief. Bij orders.refund trekt de revoke-parameter alleen in wanneer de bestelling de meest recente is, dus om de toegang bij een actief abonnement te beëindigen gebruik je in plaats daarvan purchases.subscriptionsv2.revoke.

De limieten waarover ontwikkelaars struikelen

Een paar harde randen vangen mensen, en geen ervan ligt in het gelukkige pad.

• Bestellingen ouder dan drie jaar kunnen helemaal niet worden gerestitueerd.
• Gedeeltelijke restituties werken alleen op bestellingen geplaatst na maart 2018, en nooit op aankopen van betaalde apps.
• Je kunt meerdere gedeeltelijke restituties op één bestelling stapelen, maar niet tot aan of voorbij het besteltotaal.
• Een restitutie kan niet worden teruggedraaid zodra ze is uitgegeven.

Google Play geeft een restitutiebeslissing meestal binnen een dag, al kan het tot vier duren. Reken op die vertraging wanneer een restitutie in je eigen toegangscontroles moet worden weerspiegeld.

Wat een abonnementsrestitutie je werkelijk kost

De gerestitueerde afschrijving is nooit de hele rekening. Op het moment dat een abonnementsbestelling werd geleverd, had je er al echt geld aan uitgegeven: rekenkracht, model-API-aanroepen, opslag, en alle uitbetalingen die aan die periode gebonden zijn. Een restitutie geeft de verkoop terug. Ze geeft niet terug wat je uitgaf om die te bedienen. Bij een abonnement hangt de vorm van het verlies af van welke restitutie je uitgeeft.

Volledig versus naar rato is een geldbeslissing

Een volledige restitutie bij Google Play geeft de hele huidige periode terug, dus je verliest de hele omzet van de periode terwijl je elke kost behoudt die je die periode al hebt gemaakt. Een naar rato berekende restitutie geeft alleen de ongebruikte schijf terug, dus je behoudt de omzet voor het deel dat de klant daadwerkelijk had. Als een klant 60 procent door een maandperiode zit op een plan van 10 dollar, kost een volledige restitutie je de volle 10 dollar, en een naar rato berekende restitutie kost je ongeveer 4 dollar, de ongebruikte 40 procent. Apple past aan zijn kant dezelfde logica van verstreken tijd toe wanneer het een abonnementsrestitutie bepaalt.

De kosten die nooit terugkomen

Welke restitutie je ook uitgeeft, de nageschakelde kosten van die periode zijn weg. Een model-API-aanroep waarvoor je betaalde, een video die je renderde, opslag die je inrichtte, een creator-uitbetaling die je al verstuurde, niets daarvan draait terug wanneer de abonnementsrestitutie wordt verwerkt. Bepaal de omvang van de restitutie op wat de klant daadwerkelijk gebruikte, nooit op hoe lang geleden ze zich abonneerden, want verstreken tijd is geen kost en geen enkele store behandelt het als een. En na 3 augustus 2026, als een Google Play-abonnementsafschrijving eindigt in een bank-chargeback in plaats van een restitutie die je uitgeeft, draag je ook de chargebackkosten van de bank, die een restitutie die je eerst toekent vermijdt.

Hoe je abonnementsrestituties afhandelt zonder dat iemand toekijkt

Niets hiervan zou moeten wachten op iemand die een dashboard leest. De meldingen komen op elk uur binnen, en de toegang zou moeten omschakelen op het moment dat een restitutie binnenkomt, niet de volgende ochtend.

Lees de uitkomst en trek de toegang in bij beide stores

In de App Store luister je naar REFUND, REFUND_DECLINED en REFUND_REVERSED, en gebruik je het revocationDate en de autoRenewStatus om de toegang automatisch te beëindigen of te herstellen. Bij Google Play luister je naar SUBSCRIPTION_REVOKED en signalen van geannuleerde aankopen en doe je hetzelfde. Dit is het leidingwerk dat RefundHalt voor je draait: melding binnen, account gematcht, toegang omgeschakeld, geen mens in de lus.

Houd het bewijs klaar vóór het geschil

De smalle vensters die wél om jouw input vragen, Apples 12-uurs CONSUMPTION_REQUEST op verbruiksartikelen en Google Plays 24-uurs chargebackbeoordeling, helpen alleen als het bewijs al bestaat. Hang aan elke aankoop een accountidentificatie, een appAccountToken-UUID bij Apple en een gehashte setObfuscatedAccountId van 64 tekens of minder bij Google Play, en log wat elke betaalde periode leverde. Wanneer dan een token binnenkomt, is de zaak al opgebouwd, en antwoorden binnen het venster is het werk van een machine, geen geharrewar.