Leggi il codice motivo del rimborso che il tuo server riceve già, e ti dice se correggere la tua app o contestare il cliente

Quando Apple o Google rimborsa uno dei tuoi clienti, il denaro di solito è già sparito prima che tu abbia voce in capitolo. Ciò che arriva sul tuo server dopo sembra una ricevuta, e la maggior parte dei team la tratta come tale. È qualcosa di più. Ogni rimborso porta un codice motivo del rimborso, ed è l'unica parte di un rimborso che puoi ancora leggere una volta presa la decisione. Google Play ti dice che il rimborso era uno storno, o una richiesta per ripensamento, o un acquisto che la tua stessa app non ha mai riconosciuto. Apple ti dice se il rimborso ha incolpato qualcosa dentro la tua app. Leggi quel codice e un rimborso smette di essere una riga in un report e diventa un'istruzione: correggi questo, contesta questo, o lascia perdere quest'altro. Ecco cosa significa ogni codice, come smistarli, e quanto costa ciascuno.

Cos'è davvero un codice motivo del rimborso

Un codice motivo del rimborso è l'etichetta dello store stesso per il motivo per cui un acquisto è stato annullato. Non lo imposti tu e non puoi discuterne. Arriva allegato al rimborso a posteriori, e i due store lo espongono in forme diverse e con una risoluzione molto diversa.

Google Play imprime un motivo e una fonte su ogni annullamento

La Voided Purchases API di Google Play restituisce un record per ogni acquisto annullato, e ogni record porta due interi che contano. Il voidedReason dice perché l'acquisto è stato annullato. Il voidedSource dice chi lo ha messo in moto. Insieme trasformano un rimborso nudo in una frase: questo ordine è stato annullato a causa di uno storno, avviato da Google, o annullato per ripensamento, avviato dall'utente. Li leggi facendo polling dell'API o iscrivendoti alla notifica in tempo reale per sviluppatori che scatta quando arriva un annullamento. In entrambi i casi, i due numeri sono il payload che vale la pena conservare.

Apple ti dà un segnale più stretto, ma netto

Apple non ti consegna un motivo a nove vie. Su una transazione rimborsata, Apple imposta revocationReason a uno di due valori. Un 1 significa che l'App Store ha rimborsato la transazione a causa di un problema effettivo o percepito all'interno della tua app. Uno 0 significa che ha rimborsato per un altro motivo, per esempio un acquisto accidentale. Il campo compare solo sulle transazioni che sono state rimborsate o revocate, insieme a un revocationDate, all'interno delle informazioni firmate della transazione della REFUND App Store Server Notification. Due valori non sono molti, ma quello che conta, un 1, è Apple che ti dice che il rimborso riguardava il tuo prodotto, non il ripensamento del cliente.

I nove motivi che ti dà Google Play

Il voidedReason di Google è il più ricco dei due, e ogni valore vale la pena conoscerlo a colpo d'occhio perché ciascuno punta da qualche parte di diverso. Ecco l'insieme completo, direttamente dalla risorsa VoidedPurchase, con ciò che ogni codice ti sta effettivamente dicendo di fare.

voidedSource ti dice chi ha premuto il grilletto

Accanto al motivo c'è voidedSource, e risponde a una domanda diversa: chi ha annullato questo. Uno 0 significa che è stato l'utente, tramite self-service o una banca. Un 1 significa che è stato lo sviluppatore, cioè tu o i tuoi stessi strumenti che emettono un rimborso. Un 2 significa che è stato Google, di propria iniziativa, incluso il rimborso automatico per un acquisto non riconosciuto. Quando vedi un picco di annullamenti, la fonte è il primo taglio. Un muro di source 2 è Google che agisce sul tuo account, e di solito è un segnale che riporta alla tua integrazione più che ai tuoi clienti.

Smista ogni rimborso in correggere, contestare o accettare

Il motivo per cui un codice è utile è che ti dice quale delle tre risposte merita un rimborso. La maggior parte dei team tratta tutti i rimborsi allo stesso modo e brucia energie su quelli che non potrà mai vincere. I codici si dividono in modo netto.

Correggi: i rimborsi causati dal tuo prodotto

Alcuni codici sono segnalazioni di bug travestite da rimborso. Difettoso (3) e non ricevuto (2) su Google, e un revocationReason di 1 su Apple, dicono tutti la stessa cosa: il cliente ha pagato e la tua app non ha consegnato. Acquisto non riconosciuto (8) è il più netto di questi perché la colpa è interamente nel tuo codice di fatturazione. Questi sono i rimborsi più economici da eliminare, perché li elimini correggendo qualcosa che è tuo, non convincendo qualcuno. Un conteggio in crescita in questo mucchio è un difetto di prodotto con una cifra in denaro attaccata.

Contesta: i rimborsi su cui qualcuno sta lavorando

Frode (5), frode amichevole (6) e storno (7) sono le controversie. La frode pura (5) non è il tuo cliente e non è un ricavo che avresti mai tenuto. La frode amichevole (6), in cui l'acquirente ha ricevuto esattamente ciò per cui ha pagato e poi l'ha contestato, è l'unica controversia che le tue prove possono ancora smuovere, e lo storno (7) è dove quelle prove vengono presentate. Quando uno di questi arriva revochi l'accesso se non l'hai già fatto, e dove è aperta una finestra di revisione la rispondi con ciò che sai dell'account.

Accetta: i rimborsi che non sono mai stati tuoi da fermare

Ripensamento (1) e acquisto accidentale (4) sono il cambio di idea del cliente stesso. Il revocationReason di 0 di Apple sta anche qui. Nessuna funzione ha fallito e nessuna frode è avvenuta. Puoi attenuare il mucchio degli accidentali con una conferma d'acquisto più chiara, ma non puoi discutere via un rimborso per ripensamento, e il tempo speso a provarci è tempo tolto al mucchio da correggere, dove c'è davvero il denaro.

La trappola dei 30 giorni che rende i codici motivo facili da perdere

C'è un limite rigido dal lato di Google che trasforma questo da una funzione di reportistica in una scadenza. Se non stai catturando i codici in continuazione, li stai perdendo.

La Voided Purchases API guarda indietro solo 30 giorni

Google è esplicito sul fatto che l'API può mostrare solo gli acquisti annullati degli ultimi 30 giorni. Gli annullamenti più vecchi non vengono restituiti indipendentemente dallo startTime che passi, e il valore stesso di startTime non può essere impostato prima di 30 giorni fa. Peggio, per un'integrazione ingenua, la finestra di 30 giorni è misurata da quando i sistemi di Google vedono un acquisto come annullato, non da quando l'acquisto è stato effettuato e nemmeno dal voidedTimeMillis nel record. Quindi un codice motivo del rimborso che non estrai entro quella finestra è perso, e un job di esportazione mensile con una qualsiasi lacuna scarterà silenziosamente gli annullamenti che è stato troppo lento a catturare.

Quanto valgono in denaro i codici motivo

Due codici portano un prezzo specifico, e leggerli è il modo in cui metti un numero su problemi che altrimenti si nascondono dentro un tasso di rimborso aggregato.

Un codice è una fattura che ti sei scritto da solo

voidedReason 8, acquisto non riconosciuto, è l'esempio più pulito di un rimborso che hai causato tu. Google Play richiede che la tua app riconosca un acquisto entro tre giorni dalla concessione del diritto, e se non lo fai, Google rimborsa automaticamente l'ordine e revoca l'articolo. Ogni annullamento marcato 8 è una vendita reale, da un cliente che voleva il prodotto, restituita perché una chiamata per riconoscere l'acquisto non è mai scattata. L'importo perso è l'intero prezzo di vendita più il calcolo, le chiamate API e lo spazio di archiviazione che hai già speso per consegnarlo. Questo non è un rimborso che negozi. È un bug che chiudi, e il codice è il modo in cui lo trovi.

Il codice storno ora porta una commissione

voidedReason 7, storno, ha cambiato costo il August 3, 2026. Per gli ordini Google Play effettuati a partire da quella data, uno storno perso costa allo sviluppatore il prezzo di acquisto meno la commissione di servizio di Play, più la commissione di storno della banca, mentre Google copre solo la propria commissione di servizio. Poiché le commissioni di storno sono fisse e i prezzi dei prodotti no, su un acquisto in-app economico la sola commissione può superare ciò che il cliente ha pagato. Contare i tuoi annullamenti con codice 7 ora significa contare una voce di costo, non solo una vendita persa, ed è esattamente per questo che il mucchio degli storni merita una riga propria in qualsiasi report sui rimborsi tu costruisca.

Come si allineano Apple e Google

I due store rispondono alla stessa domanda a risoluzioni diverse, quindi un report sui rimborsi tra store deve normalizzarli invece di aspettarsi che coincidano.

Gli store non ti daranno mai lo stesso codice per lo stesso rimborso, e va bene così. Ciò che conta è che entrambi ti consegnano un motivo leggibile dalla macchina, ed entrambi premiano un team che lo legge. Il singolo bit di Apple ti dice quando un rimborso è colpa del tuo prodotto. I nove motivi di Google e il suo flag di fonte ti dicono quale bug di prodotto, quale controversia e quale lacuna di fatturazione autoinflitta stai guardando. Nessuno dei due codici ferma un rimborso. Entrambi ti dicono cosa fare affinché il prossimo non accada.

RefundHalt cattura il codice motivo su ogni rimborso nel momento in cui arriva, su entrambi gli store, e lo conserva ben dentro la finestra di 30 giorni di Google così nulla sfugge. Smista ogni annullamento in correggere, contestare o accettare, così un picco nel codice 3 difettoso ti arriva come un allarme di prodotto e un picco nel codice 8 non riconosciuto ti arriva come un bug di integrazione, non come un vago calo di ricavi. Risponde alla CONSUMPTION_REQUEST di Apple entro 12 ore e alla revisione dello storno di Google Play entro 24, e revoca l'accesso nel momento in cui arriva un rimborso o uno storno. Non puoi cambiare il codice che uno store imprime su un rimborso. Puoi assicurarti di leggerli tutti, e di agire su quelli che sono davvero tuoi da correggere.