Serieel terugbetalingsmisbruik kost je twee keer, zo laten de stores je terugvechten

Eén terugbetaling hoort bij het zakendoen. Hetzelfde account dat een vierde keer terugbetaalt, nadat het telkens heeft gebruikt wat het kocht, is terugbetalingsmisbruik, en het is een patroon dat je alleen kunt zien als elke aankoop een identiteit draagt die jij beheert. Apple en Google geven je die identiteit allebei, en allebei geven ze je een smal venster om hem aan de store te tonen voordat een terugbetaling of chargeback wordt beslist. Mis het venster, of koppel de identiteit nooit, en een serieterugbetaler ziet er precies zo uit als een ontevreden klant die voor het eerst komt. Zo houd je ze uit elkaar, en zoveel is het verschil waard in geld.

Waarom terugbetalingsmisbruik een identiteitsprobleem is, geen terugbetalingsprobleem

De store beslist over de terugbetaling. Je kunt een klant niet beletten te vragen, en bij de meeste stromen kun je de store niet beletten te verlenen. Wat je wel kunt doen, is beslissen of een bepaald account dit eerder heeft gedaan en of de gekochte inhoud daadwerkelijk is geleverd en gebruikt. Beide zijn vragen over identiteit: welke van je gebruikers zit achter deze transactie, en wat is hun geschiedenis. Als je aankopen geen stabiele identifier terugdragen naar je eigen gebruikersgegevens, kun je geen van beide vragen beantwoorden, en komt elke terugbetaling zonder context binnen.

Dat is de echte kloof. De mechaniek van de terugbetaling ligt vast in beleid. Het bewijs dat je erbij brengt is helemaal aan jou om op te bouwen, en het begint op het moment van aankoop, niet op het moment van de terugbetaling.

De twee vensters waar bewijs de uitkomst verandert

Er zijn precies twee stromen waarin alles wat je stuurt een beslissing kan bewegen. Apples CONSUMPTION_REQUEST wordt geactiveerd wanneer een klant een terugbetaling vraagt voor een consumable of een automatisch verlengend abonnement, en je hebt 12 hours om te antwoorden. Google Plays chargeback-beoordeling wordt geactiveerd wanneer een gebruiker een afschrijving betwist bij zijn bank, en je hebt 24 hours om te reageren via de Review Refund API. Elke andere terugbetaling, de 48-hour zelfbedieningsterugbetaling van Play, een door support verleende terugbetaling, een automatische terugbetaling bij een niet-bevestigde aankoop, wordt zonder jou beslist.

Beide bewijskanalen zijn veel sterker wanneer de transactie je identifier al draagt. Apples verbruiksinformatie kan de appAccountToken bevatten naast de geschiedenis en uitgaven van het account, en Googles beoordeling kan leunen op de obfuscated account ID die het sinds de aankoop in de gaten houdt. Een account zonder identifier is een account zonder geschiedenis om in te dienen.

De twee identiteitsvelden, naast elkaar

Apple en Google losten hetzelfde probleem op bijna dezelfde manier op, met verschillende namen en verschillende regels. Beide laten je een aankoop stempelen met een waarde die terugwijst naar je eigen gebruikersgegevens. Geen van beide staat standaard aan. Beide zijn waardeloos als je ze niet op het moment van aankoop instelt.

Apple: appAccountToken

appAccountToken is een UUID die je genereert en meegeeft wanneer een aankoop begint. StoreKit koppelt het aan de resulterende transactie, en het verschijnt in de transactiegegevens die je server verifieert en in de verbruiksinformatie die je terugstuurt tijdens een CONSUMPTION_REQUEST. Omdat het jouw waarde is, koppelt het een store-transactie rechtstreeks aan het account in je database, zonder dat er een e-mailadres of naam bij komt kijken. Het moet een echte UUID zijn, en al het andere wordt geweigerd. Apple voegde later een Set App Account Token-eindpunt toe dat de token kan koppelen aan of bijwerken op eerdere transacties, inclusief aankopen die buiten je app zijn gedaan, zoals het inwisselen van aanbiedingscodes.

Google Play: de obfuscated account ID

Googles equivalent is setObfuscatedAccountId, een optionele tekenreeks gekoppeld aan het kopende account. Googles eigen documentatie is onomwonden over het doel ervan: Google Play gebruikt het om ongewone activiteit te detecteren, zoals veel apparaten die binnen korte tijd aankopen doen op hetzelfde account, en om sommige frauduleuze transacties te blokkeren voordat ze worden voltooid. Het is beperkt tot 64 characters en mag geen persoonsgegevens in leesbare tekst bevatten. Sla er een ruw e-mailadres op en Google blokkeert de aankoop meteen, want het veld verwacht een versleutelde waarde of een eenrichtingshash. Een verwant veld, setObfuscatedProfileId, bestaat voor apps waar één account meerdere profielen bevat.

Wat een terugbetaling van een seriemisbruiker echt kost

De terugbetaling zelf is het kleinste deel van de rekening. Wanneer een store een terugbetaling verleent, geef je de omzet terug, en zoveel is zichtbaar in het grootboek. Wat niet op de terugbetalingsregel staat, is alles wat je hebt uitgegeven om het product te leveren dat nu gratis is.

Stel je een consumable voor die echt werk in gang zet: een beeldgeneratie, een reeks API-aanroepen naar een modelprovider, een video-export, een uitbetaling aan een creator. Je betaalde voor die rekenkracht op het moment dat de klant hem gebruikte. De terugbetaling haalt de prijs terug, maar niet de factuur van de provider. Een serieterugbetaler is iemand die heeft geleerd dat de inhoud de terugbetaling overleeft, dus draait hij de lus opnieuw: kopen, verbruiken, terugbetalen, herhalen. Elke cyclus eet je de leveringskosten een tweede keer op.

Dan is er de eigen kostenverschuiving van de store. Vanaf August 3 2026 verplaatst Google Play de aankoopprijs en de chargeback-kosten van de bank naar de ontwikkelaar, voor bestellingen die na die datum zijn geplaatst. Een chargeback die vroeger vooral Googles probleem was, wordt jouw omzet plus een kost, en een herhaalde betwister verhoogt dat getal telkens. De identiteitsvelden zijn wat je in staat stelt de Review Refund API het bewijs te voeren om een onterecht geschil binnen het venster van 24 hours aan te vechten.

Google verwoordt de schaal helder: het zegt in 2022 meer dan $2 billion aan frauduleuze en misbruikende transacties te hebben geblokkeerd. Dat getal bestaat omdat de signalen, de obfuscated account ID daaronder, waren ingevuld. Een app die aankopen verstuurt met lege identiteitsvelden ziet af van die bescherming.

Hoe je herhaalde terugbetalers betrapt voordat de store beslist

Tag elke aankoop met een identiteit die van jou is

Stel appAccountToken in op elke StoreKit-aankoop en setObfuscatedAccountId op elke Play Billing-aankoop, beide gegenereerd uit je eigen gebruikersgegevens. Bij Apple gebruik je een echte UUID gekoppeld aan het account. Bij Google hash je de accountsleutel zodat er geen persoonsgegevens in leesbare tekst reizen. Doe dit op het moment van aankoop, want bij Google is het de ene stap die je later niet meer kunt herstellen.

Houd een grootboek gesleuteld op die identiteit

Sla elke aankoop, levering, verbruiksgebeurtenis en terugbetaling op tegen de identifier. Wanneer een CONSUMPTION_REQUEST of een chargeback-beoordeling binnenkomt, is de volledige geschiedenis van het account, eerdere terugbetalingen inbegrepen, één opzoekactie verderop. Apples verbruiksinformatie heeft daar expliciete velden voor: consumptionStatus, deliveryStatus, playTime, accountTenure, lifetimeDollarsPurchased en je refundPreference.

Lees voidedReason en stuur misbruikers anders

Wanneer een Google-aankoop wordt geannuleerd, vertelt het veld voidedReason je waarom, en friendly_fraud en fraud zijn aparte waarden, los van een gewone remorse-terugbetaling. Stuur die naar een beoordelingswachtrij en een strenger beleid, niet hetzelfde automatische pad als een eerste terugbetaling. Googles eigen richtlijn is een meervoudige-overtredingen-model: waarschuw een eerste overtreder, tref stevigere maatregelen bij herhaalde overtreders, en schakel aankopen uit voor een account dat ermee doorgaat.

Beantwoord het venster elke keer

Het bewijs telt alleen binnen de twee vensters. Automatiseer de CONSUMPTION_REQUEST-reactie zodat die ruim binnen 12 hours vertrekt, en de chargeback-beoordeling zodat die binnen 24 hours vertrekt. Een perfecte geschiedenis die je te laat indient, is een geschiedenis die de store nooit leest.

Wat de stores wel en niet voor je doen

Het loont om precies te zijn over de taakverdeling, want je neemt makkelijk aan dat de stores misbruik afhandelen, en ze vertellen je meestal niet wanneer ze dat niet doen. Google gebruikt de obfuscated account ID actief om sommige fraude te blokkeren voordat een aankoop wordt voltooid, en zijn systemen vangen een groot deel op platformniveau af. Apple beslist elke terugbetaling zelf en behandelt je verbruiksinformatie als een invoer, nooit als een stem. Geen van beide stores onderhoudt je misbruikerslijst voor je, trekt een terugbetaalde consumable van je saldo af, of zegt een herhaalde terugbetaler namens jou nee. De identiteit is aan de store om aan de randen op te treden en aan jou om overal elders op te treden.

Dat is dezelfde reden waarom RefundHalt alles op de aankoopidentiteit sleutelt: een terugbetaling, een chargeback-beoordeling en een verbruiksverzoek voor hetzelfde account komen samen tot één geschiedenis, zodat een serieterugbetaler opduikt als een patroon de eerste keer dat hij zich herhaalt, niet pas na de vierde factuur die je al hebt betaald.