Etichetta ogni acquisto Google Play con un id account offuscato, oppure uno storno arriva senza modo di tracciarlo

Una revisione di storno di Google Play compare nominando un ordine e un token di acquisto. Non ti dice chi è il cliente. Se non hai mai apposto il tuo identificatore su quell'acquisto, ora stai abbinando un semplice id ordine alla tua tabella utenti sotto un conto alla rovescia di 24 ore, e devi rispondere con prove di utilizzo che forse non riuscirai a trovare. L'id account offuscato è la soluzione. È una stringa breve che alleghi al pagamento, che Google Play memorizza con l'acquisto e ti restituisce in seguito, così ogni ordine può essere ricondotto all'utente esatto che l'ha effettuato. Ecco cos'è il campo, perché decide se puoi rispondere o meno a una contestazione, e quanto costa saltarlo ora che uno storno perso è una fattura.

Cos'è davvero l'id account offuscato

L'id account offuscato è una stringa opzionale che passi al flusso di fatturazione di Google Play quando un cliente acquista qualcosa. Lo imposti con setObfuscatedAccountId sul builder di BillingFlowParams, e Google lo memorizza accanto all'acquisto. Non è il nome del cliente, né la sua email, né il suo account Google. È il tuo identificatore per il tuo utente, scritto in una forma che Google può conservare senza sapere chi sia la persona.

È una stringa che imposti al pagamento, non un nome

Nelle parole di Google, setObfuscatedAccountId specifica una stringa offuscata opzionale associata in modo univoco all'account utente dell'acquirente nella tua app. La parola offuscata svolge un ruolo concreto. Google non vuole il tuo id utente grezzo né nulla che identifichi la persona. Vuole un token stabile che mappi uno a uno un utente dal tuo lato, e nulla di più. Il campo è limitato a 64 caratteri, che ospita comodamente un hash e poco altro.

Google lo legge prima per il proprio controllo antifrode

Prima ancora di esserti utile, il campo svolge un compito per Google. La documentazione di fatturazione dice che Google Play può usare questo valore per rilevare attività irregolari, come molti dispositivi che effettuano acquisti sullo stesso account in un breve arco di tempo, e che Google usa questi dati per rilevare comportamenti sospetti e bloccare alcuni tipi di transazioni fraudolente prima che vengano completate. Quindi il primo vantaggio di impostarlo è a monte, in acquisti più puliti e meno di quelli fraudolenti che si trasformano poi in annullamenti e contestazioni. Google elenca l'id account offuscato e la Voided Purchases API insieme come i suoi due strumenti centrali contro gli abusi per un motivo.

Perché conta quando arriva una revisione di storno

Un rimborso che vedi arrivare è facile. Il caso difficile è lo storno bancario, perché non inizia con il tuo cliente che ti parla. Inizia con la banca, e Google Play te lo inoltra come una revisione con un conto alla rovescia allegato.

La contestazione nomina un ordine, non una persona

Quando un cliente contesta un addebito con la sua banca e Google ha bisogno del tuo contributo, Google Play invia una PendingRefundReviewNotification. Quel messaggio identifica l'ordine. Non porta il tuo id utente, perché Google non ha mai avuto il tuo id utente. Aveva solo ciò che hai apposto sull'acquisto. Se non era nulla, ora stai cercando a ritroso un semplice id ordine e token di acquisto nei tuoi registri, sperando di aver registrato il token al momento dell'acquisto e sperando che la corrispondenza sia inequivocabile. Se hai impostato un id account offuscato, l'acquisto porta il tuo hash, cerchi l'utente in una sola query, e passi a costruire prove invece di dare la caccia all'identità.

Cosa ti chiede davvero orders.reviewrefund

Rispondere alla contestazione significa chiamare il metodo orders.reviewrefund entro 24 ore. Google registra la tua prima chiamata e ignora il resto, quindi la prima risposta è l'unica risposta. Questi sono i campi che richiede, e ognuno dei campi di prova presuppone che tu sappia già a quale utente appartiene l'ordine.

Quanto costa davvero saltarlo

Per gran parte della storia di Google Play, uno storno che non potevi difendere era una vendita persa e un'alzata di spalle. Questo è cambiato. Per gli ordini effettuati a partire dal 3 agosto 2026, uno storno perso addebita allo sviluppatore il prezzo di acquisto meno la commissione di servizio di Google, più la commissione di storno della banca. La contestazione a cui non puoi rispondere è ora una voce di spesa.

Seguiamo un ordine. Un cliente contesta un acquisto da $9.99 con la sua banca. Google Play invia la revisione, e hai 24 ore. Se hai etichettato l'acquisto, trovi l'utente, vedi che ha consumato la maggior parte di ciò che ha acquistato, e rispondi a reviewrefund con una preferenza DECLINE e le prove di consumo, dando a Google un caso reale per contestare una contestazione illegittima. Se non l'hai etichettato, o non riesci a identificare l'ordine in tempo oppure rispondi senza nulla, la contestazione viene decisa senza la tua versione, e su un ordine successivo al 3 agosto restituisci i $9.99 meno la commissione di Google, più una commissione fissa di storno bancario che spesso si aggira intorno ai $20. Su una piccola vendita, quella commissione fissa da sola può essere maggiore di quanto hai guadagnato netto.

• I proventi persi: la tua quota netta della vendita, stornata.
• La commissione di storno della banca: un costo fisso che stabilisce il circuito delle carte, addebitato in aggiunta sugli ordini effettuati dopo il 3 agosto 2026, che un semplice rimborso non comporta mai.
• La spesa sprecata: il calcolo, le chiamate API di terze parti e lo storage che l'account ha già usato, persi indipendentemente dal fatto che tu abbia potuto rispondere.
• Lo schema che non puoi vedere: senza un id account stabile non puoi nemmeno accorgerti che lo stesso utente sta contestando ancora e ancora, così l'abuso seriale si legge come perdite isolate non correlate.

Come impostarlo senza far bloccare gli acquisti

Due regole coprono quasi ogni errore che i team commettono con questo campo. Applica l'hash all'id, e impostalo ovunque.

Applica l'hash al tuo id utente, non inviare mai PII

Non mettere un'email, un numero di telefono o qualsiasi dato personale grezzo in questo campo. Google è esplicito nel dire che memorizzare PII come le email in chiaro comporta il blocco degli acquisti, e raccomanda un hash unidirezionale o la crittografia per generare il valore. Lo schema pulito è un hash unidirezionale del tuo id utente interno, calcolato allo stesso modo ogni volta così che lo stesso utente produca sempre la stessa stringa di 64 caratteri. Non usare nemmeno l'id account Google della persona né il tuo id sviluppatore. Il valore dovrebbe significare qualcosa solo per il tuo sistema.

Impostalo su ogni acquisto, e rileggilo sul tuo server

Allega l'id a ogni flusso di fatturazione, sia prodotti una tantum sia abbonamenti, così nessun acquisto resti mai senza etichetta. Dopo l'acquisto, rileggilo in due punti. Sul client, Purchase.getAccountIdentifiers restituisce un oggetto il cui getObfuscatedAccountId ti dà la stringa che hai impostato. Sul tuo backend, il record di acquisto lato server lo porta come il campo obfuscatedExternalAccountId, e la copia del server è quella di cui fidarsi, perché una contestazione arriva al tuo server, non al dispositivo.

Usa setObfuscatedProfileId quando un account ha molti profili

Se la tua app permette a un account di contenere più profili, un nucleo di streaming o un gioco con più personaggi, imposta anche setObfuscatedProfileId. È lo stesso tipo di stringa con hash, di 64 caratteri e senza PII, circoscritta al profilo che ha effettuato l'acquisto. Google osserva che impostare un id profilo richiede anche di passare l'id account, quindi invia entrambi. Il risultato è che una contestazione mappa non solo all'account ma al profilo esatto che ha speso il denaro.

Il parallelo iOS, in una riga

L'App Store ha la stessa idea sotto un nome diverso. Su iOS alleghi un appAccountToken, un UUID, a un acquisto, e torna sulla transazione e sulla CONSUMPTION_REQUEST che Apple invia quando un cliente chiede un rimborso. La forma del problema è identica su entrambi gli store. Il flusso di contestazione o rimborso fa riferimento a una transazione, e il tuo identificatore è ciò che la ricollega a un utente di cui puoi segnalare l'utilizzo.

Niente di tutto questo è difficile da costruire. È facile da saltare, perché il giorno in cui scrivi il codice di pagamento non è il giorno in cui arriva uno storno, e il costo di saltarlo è invisibile fino ad allora. RefundHalt imposta e traccia l'identificatore di account su entrambi gli store, mantiene il collegamento acquisto-utente così che una contestazione si risolva sempre in un cliente reale, e risponde a orders.reviewrefund di Google Play e alla CONSUMPTION_REQUEST di Apple entro le loro finestre con le prove di consumo registrate al momento della vendita. Il conto alla rovescia di 24 ore non è il momento per scoprire che non riesci a dire chi ha acquistato la cosa.