DeviceCheck di Apple ricorda il telefono di chi abusa dei rimborsi, anche dopo una registrazione con un nuovo account

Bannare l'account non ferma chi abusa dei rimborsi e si registra di nuovo sullo stesso telefono. DeviceCheck di Apple e il richiamo del dispositivo (device recall) di Google Play esistono proprio per questa lacuna. Ciascuno permette al tuo server di associare a un dispositivo fisico pochi bit, con il significato che decidi tu. Sono conservati sui server dello store, quindi il contrassegno resta lì quando la persona torna con un nuovo indirizzo email. Nessuno dei due strumenti ti fornisce un ID del dispositivo, e nessuno dei due può bloccare un rimborso. Quello che fanno è dirti, alla registrazione o al paywall, che questo dispositivo ti ha già fatto perdere denaro.

Ecco cosa memorizza davvero ciascuno store, la trappola dei tempi che decide se puoi davvero impostare il contrassegno e quanto costa un abusatore recidivo prima che tu lo individui.

Perché un nuovo account supera ogni difesa a livello di account

La maggior parte delle difese contro i rimborsi si basa su un account. L'appAccountToken di Apple collega una transazione a un utente nel tuo database. L'ID account offuscato di Google Play fa lo stesso su Android. È giusto impostarli entrambi a ogni acquisto, ed entrambi descrivono l'account di una persona, non l'hardware che ha in mano. Basta eliminare l'account e registrarsi con una nuova email perché il tuo storico su quella persona riparta da zero.

Gli store non colmano la lacuna al posto tuo. Una notifica di rimborso dell'App Store ti dice quale transazione è stata rimborsata. Un acquisto annullato di Google Play ti comunica il token di acquisto, l'ID dell'ordine e un voidedReason. Nessuno dei due contiene un identificatore del dispositivo. Lo sviluppatore di un'app di incontri ha descritto il risultato in una discussione degli Apple Developer Forums: profili truffaldini continuavano ad acquistare un abbonamento premium poi rimborsato, e bannare i loro dispositivi con il metodo interno dello sviluppatore non è servito.

Un nuovo account azzera la prova offerta dallo store?

Non con lo stesso Account Apple. La documentazione di Apple afferma che le offerte introduttive, prove gratuite comprese, spettano ai clienti che non ne hanno già ricevuta una per quel prodotto o per qualsiasi prodotto dello stesso gruppo di abbonamenti. Quindi un nuovo login nella tua app non fa ottenere una seconda prova Apple. Un nuovo Account Apple sì, e lo stesso vale per tutto ciò che regali tu: crediti di registrazione, una prova finanziata dal tuo server, un bonus per i referral. Sono questi i regali che un contrassegno sul dispositivo protegge.

Cosa memorizza davvero DeviceCheck di Apple

DeviceCheck ha due parti. Nell'app, la classe DCDevice genera un token effimero che identifica il dispositivo. Sul tuo server, invii quel token ad Apple insieme a un JSON web token firmato con una chiave del tuo account sviluppatore, e Apple ti consente di interrogare o aggiornare due bit per quel dispositivo. La risposta all'interrogazione restituisce bit0, bit1 e last_update_time, espresso come anno e mese. Gli esempi d'uso indicati da Apple sono un dispositivo che ha già usufruito di un'offerta promozionale e un dispositivo che hai stabilito essere fraudolento.

Apple conserva i bit, ma il significato è tuo. La documentazione dice che sei tu a dover tenere traccia di cosa significano i bit e a decidere quando ripristinarli, e porta come esempio un dispositivo venduto. Due bit danno quattro stati, quindi uno schema semplice è un bit per rimborsato dopo un uso intenso e uno per ha già ricevuto crediti gratuiti.

• Il token è monouso. Apple dice che resta valido abbastanza a lungo da ritentare una richiesta, ma dovresti generarne uno nuovo per ogni chiamata.
• Le build di sviluppo comunicano con api.development.devicecheck.apple.com. In produzione va usato api.devicecheck.apple.com, altrimenti i tuoi contrassegni finiscono nel posto sbagliato.
• Apple descrive DeviceCheck come uno degli elementi di una valutazione complessiva del rischio, non come un verdetto. Considera un bit impostato come un motivo per guardare più da vicino.

Cosa aggiunge su Android il richiamo del dispositivo di Google

La versione di Google fa parte della Play Integrity API ed è ancora in beta, con accesso tramite un modulo di manifestazione di interesse. Una volta approvato e attivata la funzione in Play Console, ogni verdetto di integrità include tre bit personalizzati per il dispositivo. Li scrivi con una chiamata server all'endpoint deviceRecall:write, usando un token di integrità già verificato. Google afferma che i dati sopravvivono alla reinstallazione dell'app e al ripristino del dispositivo, perché sono conservati sui server di Google.

La documentazione di Google è insolitamente esplicita sul caso d'uso. Cita dispositivi con prove di abusi gravi, dispositivi che hanno già riscattato un elemento di valore elevato come una prova gratuita e dispositivi usati ripetutamente per creare nuovi account a scopo abusivo. È altrettanto esplicita sul limite: device recall può essere usato solo per proteggere la sicurezza dell'app e contrastare abusi, frodi e accessi non autorizzati, mai per il fingerprinting o il tracciamento dei singoli utenti, e mai per conservare caratteristiche sensibili come età, genere o posizione.

Il problema dei tempi: i rimborsi arrivano quando il token non c'è più

Entrambi gli strumenti hanno bisogno di qualcosa proveniente dal dispositivo stesso prima che tu possa contrassegnarlo. Apple richiede un token DCDevice nuovo. Google richiede un token di integrità di quel dispositivo vecchio al massimo 14 giorni. Il rimborso, invece, arriva al tuo server tramite una notifica dello store che non sa nulla del dispositivo. Quindi la domanda non è se contrassegnare un dispositivo. È se avrai ancora un modo per raggiungerlo quando arriva il rimborso.

I rimborsi entro 48 ore di Google rientrano nella finestra di 14 giorni

I rimborsi self-service di Google Play sono disponibili solo entro 48 ore dall'acquisto, ben dentro i 14 giorni in cui un token di integrità resta utilizzabile per le scritture. Esegui un controllo di integrità al momento dell'acquisto, conserva il token verificato accanto all'ID dell'ordine e, quando arriva un acquisto annullato per quell'ordine, puoi scrivere subito il bit. I chargeback sono il caso più difficile, perché una contestazione bancaria può arrivare molto dopo il 14° giorno.

I rimborsi di Apple richiedono che il dispositivo torni

Un rimborso Apple può arrivare settimane dopo l'acquisto, e un token DeviceCheck salvato non è pensato per essere riutilizzato. La risposta pratica è contrassegnare prima l'account e poi il dispositivo. Quando arriva la notifica di rimborso, contrassegna l'account nel tuo database. La volta successiva che quell'account apre l'app, richiedi un token DeviceCheck e imposta il bit. Chi tiene il contenuto dopo un rimborso di solito torna, perché usarlo era lo scopo.

• All'acquisto, registra la transazione sul tuo account tramite appAccountToken o l'ID account offuscato.
• In caso di rimborso o annullamento, contrassegna quell'account sul tuo server.
• Alla sessione successiva dell'account contrassegnato, raccogli un token del dispositivo e imposta il tuo bit.
• A ogni registrazione, interroga i bit prima di concedere qualsiasi cosa che ti costi denaro.

Quanto ti costa un abusatore recidivo dei rimborsi

Il prezzo rimborsato è la parte visibile. Il resto è tutto ciò che l'acquisto ha già messo in moto. Se la tua app spende denaro per fornire ciò che vende, ogni ciclo di acquisto, consumo e rimborso lascia quel denaro speso: tempo GPU per le immagini generate, chiamate a pagamento a un'API di modelli o di dati, archiviazione per le esportazioni che il cliente conserva e compensi ai creator calcolati sulla vendita. Un nuovo account riapre il ciclo, e la tua contabilità lo registra come un cliente completamente nuovo.

Gli omaggi gratuiti si disperdono allo stesso modo, senza alcun rimborso. Un dispositivo che accumula crediti di registrazione su dieci account consuma dieci volte la potenza di calcolo che avevi previsto per una sola prova. Su Google Play, i chargeback sugli ordini successivi al 3 agosto 2026 ti costano anche il prezzo di acquisto meno la commissione di servizio di Google, più le commissioni della banca, quindi chi contesta ogni volta da un nuovo account ti costa di nuovo l'intera contestazione.

Cosa fare con un dispositivo contrassegnato

Un contrassegno risponde a una sola domanda: questo dispositivo deve ricevere di nuovo qualcosa gratis? Mantieni una risposta proporzionata, perché un bit impostato è un indizio, non una prova. I telefoni vengono rivenduti, le famiglie condividono gli iPad, e Google ti invita esplicitamente a valutare di ignorare o ripristinare i dati vecchi proprio per questo.

• Salta i crediti di registrazione, la prova finanziata dal server o il bonus per i referral su un dispositivo contrassegnato, e proponi invece il piano a pagamento.
• Non firmare un'offerta promozionale per un dispositivo contrassegnato. Sull'App Store è il tuo server a generare la firma che sblocca un'offerta promozionale, quindi la scelta è tua.
• Richiedi che il pagamento sia confermato prima di consegnare consumabili costosi su un dispositivo contrassegnato.
• Usa la data. Un contrassegno impostato il mese scorso pesa più di uno impostato due anni fa.
• Offri alle persone un modo per contattare l'assistenza. Chi ha comprato un telefono usato ed è stato contrassegnato per errore merita una risposta, e tu puoi ripristinare i bit.

Si può semplicemente bannare il dispositivo?

Puoi negare i tuoi extra gratuiti, ed è lì che i contrassegni sul dispositivo ripagano. Un blocco totale è più rischioso. Chi ha il telefono oggi potrebbe non essere chi ne ha abusato, e i termini stessi di Google limitano device recall alla prevenzione degli abusi, non al tracciamento delle persone. Limita ciò che ti costa denaro e lascia aperta la strada a pagamento.

E il Keychain (portachiavi) o un identificatore del dispositivo?

Gli sviluppatori chiedono spesso se un marcatore nel Keychain o un ID hardware farebbero lo stesso lavoro. Un marcatore che la tua app salva sul telefono scompare dopo il ripristino del dispositivo, e Apple non fornisce alle app un identificatore hardware stabile per questo scopo. DeviceCheck e device recall sono le risposte approvate dagli store, proprio perché i bit risiedono sui server di Apple e Google invece che sul telefono.

Dove decide ancora lo store

I contrassegni sul dispositivo cambiano ciò che la tua app regala in seguito. Non toccano il rimborso che hai davanti. Solo due flussi di rimborso ti permettono di presentare prove prima che lo store decida. Apple invia un CONSUMPTION_REQUEST e chiede i dati di consumo entro 12 ore. Google Play apre una revisione del chargeback a cui rispondi entro 24 ore tramite orders.reviewrefund. Tutto il resto, dai rimborsi entro 48 ore di Google Play ai rimborsi dell'assistenza e ai rimborsi automatici degli acquisti non confermati, viene deciso senza di te. I chargeback sono definitivi una volta che la banca si è pronunciata.

RefundHalt risponde a ogni CONSUMPTION_REQUEST e a ogni revisione dei chargeback di Google Play entro la scadenza con i tuoi dati di utilizzo reali, e collega ogni rimborso all'account che lo ha richiesto, così il tuo server sa quale dispositivo contrassegnare la prossima volta che si connette.