Apple en Google betalen per store terug, dus je cross-platform abonnement moet overal elders de toegang beëindigen

Je abonnee betaalde via Apple, opende dezelfde middag je Android-app en gebruikt nu op het werk je website. Dan betaalt Apple het terug. Google Play weet het niet. Je webfacturering weet het niet. Tenzij je eigen server de toegang beëindigt, blijft een terugbetaald cross-platform abonnement werken op elk scherm dat je accountdatabase uitleest. De stores betalen per storefront terug, en je accountsysteem is de enige plek waar het hele abonnement bestaat. Daarmee is het ook de enige plek die het kan beëindigen.

Waarom de terugbetaling van één store een cross-platform abonnement niet beëindigt

Apple staat deze opzet uitdrukkelijk toe. App Review Guideline 3.1.3(b), Multiplatform Services, zegt dat apps die op meerdere platforms werken gebruikers toegang mogen geven tot content, abonnementen of functies die ze in je app op andere platforms of op je website hebben gekocht, mits die ook als in-app-aankoop in de app beschikbaar zijn.

Apples handleiding voor het aanbieden van één abonnement in meerdere apps beschrijft hoe dit in de praktijk werkt. Je server verleent de toegang via een centrale accountdatabase, en elke app leest daaruit. Dezelfde handleiding waarschuwt dat als een aankoop niet naar de andere apps wordt doorgegeven, de gebruiker meer dan eens voor dezelfde dienst kan gaan betalen.

Dat ontwerp heeft een gevolg dat vaak over het hoofd wordt gezien. Het recht staat in jouw database, maar elke store kent alleen zijn eigen bonnen. Apple kan de iPhone-aankoop terugbetalen en je server inlichten. Je Android-app of je website kan Apple niets vertellen. Als de handler voor terugbetalingen alleen de iOS-client bijwerkt, krijgt de klant zijn geld terug en houdt hij het abonnement overal elders.

Zo trek je na een terugbetaling de toegang op elk platform in

Koppel elke store-aankoop aan één account

Een terugbetaling aan een persoon koppelen is het lastige deel, omdat elke store de koper op zijn eigen manier identificeert. Beide bieden je een veld voor je eigen account-ID. Gebruik het bij elke aankoop.

• Stel bij Apple een appAccountToken in, een UUID die je zelf genereert, wanneer de aankoop start. De App Store geeft dezelfde UUID terug in de transactie- en verlengingsinformatie. Volgens Apple kun je één waarde hergebruiken voor alle transacties van dezelfde klant.
• Kocht de klant buiten je app, bijvoorbeeld door een aanbiedingscode in de App Store in te wisselen, dan heeft de transactie geen token. Het Set App Account Token-endpoint voegt er een toe. Bij een automatisch verlengend abonnement geldt het voor de huidige verlenging en latere verlengingen, niet voor eerdere transacties, en het werkt niet voor aankopen die via Delen met gezin worden gedeeld.
• Geef bij Google Play een versleutelde account-ID mee met setObfuscatedAccountId wanneer je de betaalflow start. Die is beperkt tot 64 tekens. Volgens Google worden aankopen geblokkeerd als er leesbare persoonsgegevens zoals een e-mailadres in staan, en Google raadt versleuteling of een eenrichtingshash aan.

Luister naar beide stores en schrijf één recht weg

Apple stuurt REFUND wanneer het een willekeurig producttype terugbetaalt, automatisch verlengende abonnementen inbegrepen. Het stuurt REFUND_REVERSED wanneer het een al toegekende terugbetaling terugdraait vanwege een geschil dat de klant heeft aangespannen. Bij Google Play somt de Voided Purchases API terugbetaalde en teruggeboekte aankopen op, elk met een orderId die de exacte aankoop of verlenging aanduidt. Je webbetaalprovider stuurt zijn eigen terugbetalingsevent. Alle drie moeten in dezelfde handler binnenkomen en hetzelfde record wijzigen.

Trek het recht in, niet het account

Een terugbetaling annuleert een aankoop, geen persoon. Verwijder de toegang die uit de terugbetaalde aankoop voortkwam en bereken daarna opnieuw wat het account nog heeft. Heeft de klant ook een actief abonnement uit een andere store, dan houdt hij via dat abonnement toegang. Zo niet, dan verliest elke client de premiumfuncties zodra hij de volgende keer bij je server controleert.

Als dezelfde persoon in twee stores een abonnement neemt

Dubbele abonnementen zijn de andere helft van het probleem. Iemand neemt een abonnement op Android, krijgt een nieuwe iPhone, logt niet in en neemt opnieuw een abonnement. Nu betaalt hij twee keer voor één dienst, en een van die afschrijvingen wordt meestal een verzoek om terugbetaling. Apples commerceteam zei het, in antwoord op een ontwikkelaar op de Apple Developer Forums, eenvoudig: een accountsysteem van een app moet logica bevatten die de dubbele aankoop op een ander platform voorkomt.

Controleer elke store voordat je de paywall toont

Laat de gebruiker inloggen vóór de paywall, zoek op je server al zijn actieve aankopen op en sla het aanbod over als een daarvan dit platform dekt. Die ene controle voorkomt de meeste dubbele afschrijvingen voordat ze gebeuren.

Welke aankoop moet ik terugbetalen als het al is gebeurd?

Betaal de aankoop terug waar jij over beslist. Bij Google Play kun je de terugbetaling zelf uitvoeren in Play Console, en purchases.subscriptionsv2.cancel met DEVELOPER_REQUESTED_STOP_PAYMENTS stopt de volgende betaling. Je webabonnement kun je gewoon zelf terugbetalen. Over App Store-terugbetalingen beslist Apple, dus als het duplicaat op de iPhone staat, vraagt de klant de terugbetaling bij Apple aan, en je app kan dat verzoek openen met de refund request-API van StoreKit.

Wat een terugbetaling kost die een platform mist

De terugbetaalde prijs is pas het eerste verlies. Een klant van wie de Apple-terugbetaling nooit je Android-app of website heeft bereikt, blijft gebruiken waarvoor jij de rekening betaalt. Elke sessie kost nog steeds rekenkracht. Elke AI-functie doet nog steeds API-aanroepen bij derden die aan jou worden gefactureerd. Zijn bestanden nemen nog steeds opslag in, en als je app makers per weergave of per gebruik betaalt, blijven die uitbetalingen doorlopen. Bij een jaarabonnement kan dat een volledig jaar aan kosten betekenen voor een account dat niets meer betaalt.

De route via de bank maakt het erger. Voor Google Play-bestellingen vanaf 3 augustus 2026 zegt Google dat bij een geslaagde chargeback de ontwikkelaar verantwoordelijk is voor de aankoopprijs, min de servicekosten van Play, plus de chargebackkosten die de financiële instelling rekent. Een chargeback is bij de bank definitief. Een klant die een chargeback heeft gedaan en nog toegang heeft, kost je in één keer de prijs, de kosten en de serverkosten.

Gebruik op meerdere platforms blijft bewijs

Eén account over alle platforms helpt ook wanneer een store om jouw kant van het verhaal vraagt. Apples verbruiksinformatie vraagt welk deel van een verbruiksartikel, niet-verbruiksartikel of niet-verlengend abonnement de klant heeft verbruikt. Voor automatisch verlengende abonnementen stuur je geen percentage, omdat Apple dat berekent op basis van de verstreken tijd. De chargebackbeoordeling van Google Play accepteert tot 1.000 gebruiksevents, die elk de versleutelde account-ID kunnen bevatten. Gebruik dat onder één account-ID is vastgelegd, ongeacht het apparaat, is gebruik dat je kunt aantonen.

Bij welke terugbetalingen je nooit om jouw kant wordt gevraagd

De meeste terugbetalingen worden zonder jou beslist. Google Play kan een aankoop binnen 48 uur via zijn eigen terugbetalingsproces terugbetalen. Terugbetalingen door storesupport, geannuleerde aankopen en Googles automatische terugbetaling van aankopen die je nooit bevestigt, na ongeveer 72 uur, gebeuren allemaal eerst en worden pas daarna gemeld. Daarvoor is de intrekkingslogica hierboven het hele werk.

Slechts twee processen vragen om bewijs. Apples CONSUMPTION_REQUEST geeft je 12 uur om verbruiksinformatie te sturen. De chargebackbeoordeling van Google Play geeft je 24 uur vanaf de PendingRefundReviewNotification om te antwoorden via orders.reviewrefund, en Google registreert alleen je eerste aanroep. RefundHalt beantwoordt beide binnen de termijn, met de gebruiksgegevens die je al verzamelt, gekoppeld aan hetzelfde account in al je apps.

Een korte checklist voor cross-platform terugbetalingen

• Stel appAccountToken in bij Apple-aankopen en een versleutelde account-ID bij Google Play-aankopen.
• Vul ontbrekende Apple-tokens aan met Set App Account Token bij ingewisselde aanbiedingscodes.
• Stuur Apples REFUND en REFUND_REVERSED, geannuleerde Google Play-aankopen en webterugbetalingen naar één handler.
• Sla elke aankoop op met zijn bron en bereken de toegang uit alle actieve aankopen.
• Controleer de aankopen in elke store voordat je op welk platform dan ook een paywall toont.