Apples Retention Messaging API zet jouw woorden op het opzegscherm, maar terugbetalingsverzoeken komen daar nooit langs

Abonnees die op een iPhone op Opzeggen tikken, kunnen nu vóór de bevestiging een bericht zien dat jij hebt gekozen, een goedkoper abonnement of een korting. Dat is Apples Retention Messaging API, en het is de eerste keer dat een ontwikkelaar iets te zeggen heeft op Apples eigen opzegscherm. Het is nog een pre-release waarvoor je je moet aanmelden. Er zit ook een harde grens aan die ertoe doet als terugbetalingen je iets kunnen schelen: het spreekt mensen aan die op het punt staan te stoppen met betalen, niet mensen die hun geld terug willen. Die verzoeken bereiken Apple via een andere weg.

Wat Apples Retention Messaging API doet

De Retention Messaging API is een server-naar-serverdienst. Je uploadt vooraf berichtteksten en afbeeldingen naar Apple, Apple beoordeelt ze, en daarna kies je welk goedgekeurd bericht een abonnee ziet wanneer hij op het punt staat een automatisch verlengbaar abonnement op te zeggen. Apples documentatie noemt vier berichttypen:

• Een tekstbericht, eventueel met opsommingstekens.
• Een tekstbericht met een afbeelding.
• Een wisselbericht, dat een ander abonnement uit dezelfde abonnementsgroep voorstelt.
• Een promotiebericht, dat een lagere prijs biedt op hetzelfde of een ander niveau, met een promotieaanbod dat je in App Store Connect instelt en op je server ondertekent.

Het bericht verschijnt nadat de klant op een pagina met abonnementsgegevens op Cancel Subscription (Abonnement opzeggen) heeft getikt. Daarna toont Apple een pagina Confirm Cancellation (Opzegging bevestigen). De klant kan nog steeds opzeggen, op Keep Subscription (Abonnement behouden) tikken of het aanbod of abonnement nemen dat je voorstelde. De uitgang verbergen kan niet, en Apple zegt ontwikkelaars geen misleidende of onjuiste content te uploaden.

Standaardberichten en de realtime-flow

Er zijn twee manieren om het te gebruiken. De eenvoudige is standaardberichten: tekst, met of zonder afbeelding of opsommingstekens, toegewezen per product en taalregio. De uitgebreidere is de realtime-flow, waarbij Apple een Get Retention Message-endpoint op je server aanroept en jij antwoordt met een bericht-ID. Alleen de realtime-flow kan wissel- en promotieberichten tonen.

In de praktijk zijn standaardberichten niet optioneel. Apple gebruikt ze als terugval wanneer een realtime-aanroep mislukt, en toont helemaal geen retentiebericht voor een product in elke taalregio zonder standaardbericht.

Wat Apple je server vertelt in de realtime-aanroep

Het verzoek is een JWS, ondertekend door de App Store. Gedecodeerd bevat het originalTransactionId, appAppleId, productId, userLocale, een requestIdentifier-UUID, de omgeving en signedDate. Apple zegt dat je moet controleren of appAppleId bij je app hoort, en niet moet antwoorden als dat niet zo is. De originalTransactionId is het nuttige deel: daarmee zoek je op wat deze abonnee echt in je app heeft gedaan voordat je kiest wat je zegt.

Waar het retentiebericht verschijnt, en waar niet

Apple plaatst het bericht op één scherm: de stap Confirm Cancellation nadat de klant op Cancel Subscription tikt, bijvoorbeeld via Apple Account > Subscriptions of de pagina van een abonnement in de App Store. Dat scherm gaat over de vraag of de volgende verlenging doorgaat. Het raakt geen geld dat al is geïnd.

Een terugbetalingsverzoek is een aparte handeling. Apples supportpagina stuurt klanten naar reportaproblem.apple.com, waar ze ‘Request a refund’ (Vraag een terugbetaling aan) kiezen, een reden en een item selecteren en 24 tot 48 uur op een update wachten. In je app opent StoreKits beginRefundRequest Apples terugbetalingsvenster, en volgens Apple heeft de App Store tot 48 uur nodig om goed of af te keuren. Geen van beide routes loopt via het scherm Confirm Cancellation.

Kan een retentiebericht een terugbetalingsverzoek tegenhouden?

Nee. Het terugbetalingsverzoek komt nooit op het scherm waar het bericht staat. Een detail in Apples documentatie over meldingen maakt dit concreet. Vraagt een klant via je app met de API voor terugbetalingsverzoeken een terugbetaling aan, dan zet Apple zelf automatisch verlengen uit en stuurt DID_CHANGE_RENEWAL_STATUS met subtype AUTO_RENEW_DISABLED. Een klant die opzegt via de instellingenpagina Subscriptions levert hetzelfde type en subtype op. Je server ziet één melding voor twee heel verschillende klanten, en maar één van hen heeft je retentiebericht gezien.

Gaat het terugbetalingsverzoek door, dan is de CONSUMPTION_REQUEST je kanaal voor bewijs. Apple stuurt die bij terugbetalingsverzoeken voor elk producttype, en je hebt 12 uur om te antwoorden met Send Consumption Information. Je mag alleen antwoorden als de klant toestemming gaf. Daarna komt Apples beslissing binnen als REFUND-melding, of als REFUND_DECLINED als Apple een terugbetaling weigert die de klant in je app startte.

Heeft Google Play een API voor opzegberichten?

Niet volgens Googles documentatie over de levenscyclus van abonnementen. Een Google Play-abonnee zegt op in het Play-abonnementencentrum, houdt toegang tot het einde van de lopende factuurperiode en kan tot die tijd op Resubscribe (Opnieuw abonneren) tikken om het ongedaan te maken. Google noemt dat een herstel. Je hoort het achteraf via een SUBSCRIPTION_CANCELED-melding, en het veld userInitiatedCancellation in de abonnementsresource vertelt waarom de gebruiker vertrok. Pauzeren, volgens Google standaard ingeschakeld voor alle abonnementen, is het belangrijkste ingebouwde middel tegen vrijwillig verloop.

Aan de terugbetalingskant heeft Google Play een eigen kanaal voor bewijs. Een PendingRefundReviewNotification komt binnen wanneer een chargeback beoordeling door de ontwikkelaar nodig heeft, en je hebt 24 uur om te antwoorden via orders.reviewrefund. Voor bestellingen geplaatst na 3 augustus 2026 rekent Google bij een geslaagde chargeback de aankoopprijs, minus de servicekosten van Play, plus de chargebackkosten van de bank door aan de ontwikkelaar.

Wat het opzegscherm je aan geld kost

Retention messaging lijkt gratis. Dat is het niet, en de rekeningen komen op drie plekken binnen.

Rekenkracht bij elke paginaweergave

Apple roept je endpoint aan wanneer een actieve abonnee een pagina met abonnementsgegevens en een knop Opzeggen bekijkt, niet alleen bij opzeggen. Elk bezoek is een verzoek dat je server moet authenticeren, opzoeken en binnen 700 ms beantwoorden, anders valt Apple terug op het standaardbericht. Een functie met koude start die soms twee seconden nodig heeft, valt daarmee af. Je betaalt voor capaciteit die warm blijft, plus alle databaselezingen en betaalde API-aanroepen bij derden die je beslislogica per verzoek doet.

De korting is omzet die je bewust laat liggen

Een promotieaanbod dat een abonnee behoudt, is echt behouden geld. Een aanbod voor iemand die toch was gebleven, is pure korting. Hier een illustratie, geen benchmark. Een maandabonnement van $ 9,99 dat drie maanden voor de halve prijs wordt aangeboden, kost $ 14,99 per geaccepteerd aanbod. Als één op de drie mensen die accepteren ook voor de volle prijs was gebleven, kosten duizend acceptaties ongeveer $ 5.000 aan korting voor mensen die die nooit nodig hadden. Aan de andere kant van de balans staan de abonnees die echt aan het vertrekken waren.

De terugbetaling die een stroeve uitgang uitlokt

Apple laat de knop Cancel Subscription op de pagina staan, dus je kunt niemand vasthouden, maar irritant zijn kan nog steeds. Een klant die zich opgejaagd voelt, heeft een andere optie: Apple vragen de laatste afschrijving terug te betalen. Komt er een terugbetaling, dan gaat het geld terug, terwijl de rekenkracht, opslag, API-aanroepen en eventuele affiliatevergoedingen voor die abonnee al zijn uitgegeven. Die kosten haalt geen retentiebericht terug.

Zo gebruik je retention messaging zonder je terugbetalingspercentage te verhogen

Zie het opzegscherm als een plek om nauwkeurig te zijn, niet slim. Een paar regels houden het aan de goede kant van de terugbetalingsgrens:

• Beslis per abonnee. Gebruik de originalTransactionId uit Apples verzoek om recent gebruik op te zoeken. Bied korting of een goedkoper abonnement aan mensen die het product gebruiken. Geef mensen die het al weken niet hebben geopend een kort, eerlijk bericht.
• Antwoord snel. Bereken de beslissing vooraf wanneer je gebruiksgegevens veranderen, zodat het verzoek zelf één opzoeking is die ruim binnen 700 ms past.
• Schrijf een standaardbericht voor elk product en elke taalregio. Zonder standaardbericht betekent een mislukte aanroep helemaal geen bericht.
• Houd AUTO_RENEW_DISABLED goed in de gaten. Volgt er een CONSUMPTION_REQUEST voor dezelfde originalTransactionId, dan heb je te maken met een terugbetalingsverzoek, geen opzegging, en is de klok van 12 uur gaan lopen.
• Beantwoord elke CONSUMPTION_REQUEST die je mag beantwoorden. RefundHalt stuurt Apple nauwkeurige verbruiksgegevens binnen het venster van 12 uur en beantwoordt de chargebackbeoordeling van Google Play binnen 24 uur, omdat dat de enige twee momenten zijn waarop een van beide stores om jouw kant van het verhaal vraagt.

Is het de moeite waard om Apple om toegang te vragen?

Als je automatisch verlengbare abonnementen verkoopt en App Store Server Notifications V2 al verwerkt, waarschijnlijk wel. Het opzegscherm is de laatste plek waar je een abonnee bereikt voordat hij vertrekt, en een abonnementswissel kost je minder dan hem helemaal kwijtraken. Reken wel op een endpoint dat bij elke weergave van een abonnementspagina antwoordt, en houd je verdediging tegen terugbetalingen daar waar terugbetalingen echt gebeuren.