Apples DeviceCheck onthoudt de telefoon achter een terugbetalingsmisbruiker, ook na aanmelding met een nieuw account

Een accountblokkade houdt iemand die terugbetalingen misbruikt niet tegen als die zich op dezelfde telefoon opnieuw aanmeldt. Apples DeviceCheck en Google Plays apparaatherkenning (device recall) bestaan precies voor dat gat. Met beide kan uw server een paar bits met een eigen betekenis aan een fysiek apparaat koppelen, opgeslagen op de servers van de store. De markering staat er dus nog als de persoon erachter terugkomt met een nieuw e-mailadres. Geen van beide geeft u een apparaat-ID, en geen van beide kan een terugbetaling tegenhouden. Wat ze wel doen, is u bij de aanmelding of bij de paywall vertellen dat dit apparaat u al eerder schade heeft berokkend.

Hieronder leest u wat elke store werkelijk opslaat, welke tijdsval bepaalt of u de markering überhaupt kunt instellen, en wat een herhaalde misbruiker kost voordat u hem betrapt.

Waarom een nieuw account elke verdediging op accountniveau omzeilt

De meeste verdedigingen tegen terugbetalingen zijn aan een account gekoppeld. Apples appAccountToken koppelt een transactie aan een gebruiker in uw database. De verhulde account-ID van Google Play doet hetzelfde op Android. Beide hoort u bij elke aankoop in te stellen, en beide beschrijven het account van een persoon, niet de hardware die hij vasthoudt. Account verwijderen, aanmelden met een nieuw e-mailadres, en uw geschiedenis met die persoon begint weer bij nul.

De stores dichten dat gat niet voor u. Een terugbetalingsmelding van de App Store vertelt u welke transactie is terugbetaald. Een geannuleerde aankoop bij Google Play geeft u het aankooptoken, de bestel-ID en een voidedReason. Geen ervan bevat een apparaatidentificatie. Een ontwikkelaar van een datingapp beschreef het gevolg in een thread op de Apple Developer Forums: nepprofielen bleven een premiumlidmaatschap kopen dat later werd terugbetaald, en het blokkeren van hun apparaten met een eigen methode hielp niet.

Reset een nieuw account de proefperiode van de store zelf?

Niet bij hetzelfde Apple Account. Volgens de documentatie van Apple gaan introductieaanbiedingen, inclusief gratis proefperiodes, naar klanten die er nog geen hebben ontvangen voor dat product of een ander product in dezelfde abonnementsgroep. Een nieuwe login in uw app levert dus geen tweede Apple-proefperiode op. Een nieuw Apple Account wel, en dat geldt ook voor alles wat u zelf weggeeft: aanmeldtegoed, een door de server betaalde proefperiode, een verwijzingsbonus. Dat zijn de cadeaus die een apparaatmarkering beschermt.

Wat Apples DeviceCheck werkelijk opslaat

DeviceCheck bestaat uit twee delen. In de app genereert de klasse DCDevice een tijdelijk token dat het apparaat identificeert. Uw server stuurt dat token naar Apple met een JSON-webtoken dat is ondertekend met een sleutel uit uw ontwikkelaarsaccount, waarna u twee bits voor dat apparaat kunt opvragen of bijwerken. Het antwoord op een opvraging bevat bit0, bit1 en last_update_time, uitgedrukt als jaar en maand. Apple geeft zelf als voorbeelden een apparaat dat al een promotieaanbieding heeft gebruikt en een apparaat dat u als frauduleus hebt aangemerkt.

Apple bewaart de bits, maar de betekenis bepaalt u. Volgens de documentatie bent u zelf verantwoordelijk voor het bijhouden van wat de bits betekenen en voor de beslissing wanneer u ze reset. Apple noemt een verkocht apparaat als voorbeeld. Twee bits geven vier toestanden, dus een eenvoudig schema is één bit voor terugbetaald na intensief gebruik en één voor al gratis tegoed ontvangen.

• Het token is eenmalig bruikbaar. Volgens Apple blijft het lang genoeg geldig om een verzoek opnieuw te proberen, maar u hoort voor elke aanroep een nieuw token te genereren.
• Ontwikkelbuilds praten met api.development.devicecheck.apple.com. Productie moet api.devicecheck.apple.com gebruiken, anders komen uw markeringen op de verkeerde plek terecht.
• Apple beschrijft DeviceCheck als één factor in een totale risicobeoordeling, niet als een oordeel. Zie een ingesteld bit als reden om beter te kijken.

Wat de apparaatherkenning van Google toevoegt op Android

De versie van Google zit in de Play Integrity API en is nog in bèta, bereikbaar via een interesseformulier. Zodra u bent goedgekeurd en de functie in Play Console inschakelt, bevat elk integriteitsoordeel drie eigen bits voor het apparaat. U schrijft ze met een serveraanroep naar het endpoint deviceRecall:write, met een integriteitstoken dat u al hebt geverifieerd. Volgens Google blijven de gegevens bestaan na een herinstallatie van de app en na het resetten van het apparaat, omdat ze op de servers van Google staan.

De documentatie van Google is ongewoon duidelijk over het gebruiksdoel. Genoemd worden apparaten met bewijs van ernstig misbruik, apparaten die al een waardevol item zoals een gratis proefperiode hebben ingewisseld, en apparaten die steeds opnieuw worden gebruikt om nieuwe accounts voor misbruik aan te maken. Even duidelijk is de grens: apparaatherkenning mag alleen worden gebruikt om de beveiliging van de app te beschermen en misbruik, fraude en onbevoegde toegang te bestrijden. Nooit om individuele gebruikers te fingerprinten of te volgen, en nooit om gevoelige kenmerken zoals leeftijd, geslacht of locatie op te slaan.

Het tijdsprobleem: terugbetalingen komen binnen als het token weg is

Beide hulpmiddelen hebben iets van het apparaat zelf nodig voordat u het kunt markeren. Apple heeft een nieuw DCDevice-token nodig. Google heeft een integriteitstoken van dat apparaat nodig dat niet ouder is dan 14 dagen. De terugbetaling bereikt uw server intussen via een storemelding die niets over het apparaat weet. De vraag is dus niet of u een apparaat markeert. De vraag is of u het nog kunt bereiken wanneer de terugbetaling binnenkomt.

De terugbetalingen van 48 uur bij Google passen binnen het venster van 14 dagen

Zelfbedieningsterugbetalingen bij Google Play zijn alleen mogelijk binnen 48 uur na de aankoop, ruim binnen de 14 dagen dat een integriteitstoken bruikbaar blijft voor schrijfacties. Voer op het moment van aankoop een integriteitscontrole uit, bewaar het geverifieerde token naast de bestel-ID, en wanneer er voor die bestelling een geannuleerde aankoop binnenkomt, kunt u het bit direct schrijven. Chargebacks zijn lastiger, omdat een bankgeschil lang na dag 14 kan binnenkomen.

Bij terugbetalingen van Apple moet het apparaat terugkomen

Een terugbetaling van Apple kan weken na de aankoop binnenkomen, en een opgeslagen DeviceCheck-token is niet bedoeld voor hergebruik. Het praktische antwoord is eerst het account te markeren en daarna het apparaat. Wanneer de terugbetalingsmelding binnenkomt, markeert u het account in uw database. De volgende keer dat dat account de app opent, vraagt u een DeviceCheck-token op en stelt u het bit in. Wie na een terugbetaling de inhoud houdt, komt meestal terug, want het gebruik was juist het doel.

• Leg bij de aankoop de transactie vast op uw eigen account via appAccountToken of de verhulde account-ID.
• Markeer bij een terugbetaling of annulering dat account op uw server.
• Haal in de volgende sessie van het gemarkeerde account een apparaattoken op en stel uw bit in.
• Vraag bij elke aanmelding de bits op voordat u iets toekent dat u geld kost.

Wat een herhaalde terugbetalingsmisbruiker u kost

De terugbetaalde prijs is het zichtbare deel. De rest is alles wat de aankoop al in gang had gezet. Als uw app geld uitgeeft om te leveren wat ze verkoopt, blijft dat geld bij elke cyclus van kopen, gebruiken en terugbetalen uitgegeven: GPU-tijd voor gegenereerde afbeeldingen, betaalde aanroepen naar een model of data-API, opslag voor exports die de klant houdt, en uitbetalingen aan makers die op de verkoop zijn berekend. Een nieuw account opent de cyclus opnieuw, en uw boekhouding noteert het als een gloednieuwe klant.

Gratis weggevers lekken op dezelfde manier weg, zonder enige terugbetaling. Een apparaat dat op tien accounts aanmeldtegoed binnenhaalt, verbruikt tien keer de rekenkracht die u voor één proefperiode had begroot. Bij Google Play kosten chargebacks op bestellingen na 3 augustus 2026 u bovendien de aankoopprijs minus de servicekosten van Google, plus de bankkosten. Iemand die elke keer vanaf een nieuw account een geschil indient, kost u dus telkens opnieuw het volledige geschil.

Wat u met een gemarkeerd apparaat doet

Een markering beantwoordt één vraag: moet dit apparaat nog een keer iets gratis krijgen? Reageer proportioneel, want een ingesteld bit is een aanwijzing, geen bewijs. Telefoons worden doorverkocht, gezinnen delen iPads, en Google raadt u om die reden uitdrukkelijk aan oude gegevens te negeren of te resetten.

• Sla op een gemarkeerd apparaat het aanmeldtegoed, de door de server betaalde proefperiode of de verwijzingsbonus over en bied in plaats daarvan het betaalde abonnement aan.
• Onderteken geen promotieaanbieding voor een gemarkeerd apparaat. In de App Store genereert uw server de handtekening die een promotieaanbieding ontgrendelt, dus de keuze ligt bij u.
• Eis op een gemarkeerd apparaat dat de betaling is afgerond voordat u dure verbruiksartikelen levert.
• Gebruik de tijdstempel. Een markering van vorige maand weegt zwaarder dan een van twee jaar geleden.
• Geef mensen een manier om support te bereiken. Wie een gebruikte telefoon kocht en ten onrechte is gemarkeerd, verdient een antwoord, en u kunt de bits resetten.

Kunt u het apparaat gewoon blokkeren?

U kunt uw eigen gratis extra's weigeren, en daar betalen apparaatmarkeringen zich uit. Een harde blokkade is riskanter. Wie de telefoon vandaag vasthoudt, is misschien niet degene die hem heeft misbruikt, en de eigen voorwaarden van Google beperken apparaatherkenning tot het voorkomen van misbruik, niet tot het volgen van mensen. Scherm af wat u geld kost en laat de betaalde route open.

Hoe zit het met de Keychain (sleutelhanger) of een apparaatidentificatie?

Ontwikkelaars vragen vaak of een markering in de Keychain of een hardware-ID hetzelfde zou doen. Een markering die uw app op de telefoon opslaat, is na een reset van het apparaat verdwenen, en Apple geeft apps hiervoor geen stabiele hardware-identificatie. DeviceCheck en apparaatherkenning zijn de door de stores goedgekeurde oplossingen, juist omdat de bits op de servers van Apple en Google staan in plaats van op de telefoon.

Waar de store nog steeds beslist

Apparaatmarkeringen veranderen wat uw app hierna weggeeft. Ze raken de terugbetaling die nu voorligt niet. Slechts twee terugbetalingsprocessen laten u bewijs indienen voordat de store beslist. Apple stuurt een CONSUMPTION_REQUEST en vraagt binnen 12 uur om verbruiksgegevens. Google Play opent een chargebackbeoordeling die u binnen 24 uur beantwoordt via orders.reviewrefund. Al het andere, van de terugbetalingen van 48 uur bij Google Play tot terugbetalingen via support en automatische terugbetalingen van niet-bevestigde aankopen, wordt zonder u beslist. Chargebacks zijn definitief zodra de bank heeft beslist.

RefundHalt beantwoordt elke CONSUMPTION_REQUEST en elke chargebackbeoordeling van Google Play binnen de termijn met uw echte gebruiksgegevens, en koppelt elke terugbetaling aan het account dat haar aanvroeg. Zo weet uw server welk apparaat hij moet markeren zodra het zich weer meldt.