Se trasferisci un'app a un altro account sviluppatore, gli ordini fatti prima della vendita restano al venditore, ed ecco cosa significa per i rimborsi

La pagina di assistenza di Google lo dice in una riga: gli ordini creati prima del trasferimento di un'app restano nell'account originale. Quindi, quando trasferisci un'app a un altro account sviluppatore, gli abbonati passano all'acquirente, ma lo storico degli acquisti no. I rimborsi, le contestazioni e i ticket di assistenza legati a quello storico non si sistemano da soli. Ricadono su chi indicano le regole dello store, che non è sempre la parte che ha incassato. Apple e Google gestiscono la cosa in modo diverso, e Apple dice meno di Google. Ecco cosa documenta ciascuno store, quali parti del tuo sistema di rimborsi smettono di funzionare in silenzio dopo un trasferimento e cosa mettere per iscritto prima che una delle due parti firmi.

Cosa si sposta e cosa resta quando trasferisci un'app

Entrambi gli store trattano un trasferimento come un cambio di proprietario da quel momento in poi. L'app, i suoi utenti e le sue valutazioni si spostano. Lo storico finanziario del passato, per lo più, no.

Sull'App Store

La regola di Apple riguarda i dati. Lo sviluppatore che trasferisce conserva l'accesso alle informazioni su pagamenti e vendite precedenti al trasferimento e perde l'accesso a tutto ciò che viene dopo. Il destinatario riceve le informazioni su pagamenti e vendite solo per le transazioni che avvengono dopo il trasferimento. La guida di Apple al trasferimento non tratta i rimborsi di acquisti fatti prima del trasferimento. Non dice nulla su quali proventi debba coprire un rimborso tardivo.

Su Google Play

Google è più esplicito. Utenti, statistiche, dati, commenti, valutazioni e abbonamenti si trasferiscono. Gli ordini creati prima del trasferimento restano nell'account originale, e se uno di questi va rimborsato, Google dice che devi tornare all'account originale o usare la Google Play Developer API. L'account del venditore non smette di contare il giorno della vendita. Resta l'unico posto da cui si possono emettere alcuni rimborsi.

Chi emette un rimborso dopo il trasferimento di un'app

Su entrambi gli store, la maggior parte dei rimborsi viene decisa senza alcuno sviluppatore. Apple gestisce da sé le richieste di rimborso. Su Google Play, gli acquirenti possono rimborsarsi da soli molti acquisti entro 48 ore, e l'assistenza di Google ne concede altri. Un trasferimento non cambia nulla di tutto questo. Cambia chi può vedere il rimborso e chi può intervenire nei rari flussi che chiedono qualcosa allo sviluppatore.

Un rimborso che vuoi concedere su Google Play

Mettiamo che un abbonato di lunga data scriva al nuovo proprietario per farsi restituire un addebito di due mesi prima della vendita. Il nuovo proprietario non può rimborsarlo dalla propria Play Console, perché l'ordine non è lì. Deve accedere il venditore e farlo, oppure qualcuno con accesso API all'account del venditore deve chiamare la Google Play Developer API. Se il venditore ha chiuso l'account o non risponde più, quel rimborso resta bloccato. Google offre persino di rimborsare al venditore la quota di registrazione di $25 se chiude l'account originale dopo un trasferimento, ed è proprio per questo che l'acquirente dovrebbe assicurarsi che i rimborsi precedenti al trasferimento siano gestiti prima che succeda.

Un rimborso che Apple concede da sola

Sull'App Store i rimborsi non li emetti tu, li emette Apple. Quando Apple rimborsa un acquisto precedente al trasferimento, il relativo registro di pagamento e vendita resta allo sviluppatore originale. La documentazione di Apple sul trasferimento non dice sui proventi di quale parte ricada quel rimborso, quindi nessuna delle due dovrebbe darlo per scontato. Scrivilo nell'accordo.

I due flussi di rimborso che chiedono prove

Solo due flussi di rimborso chiedono qualcosa allo sviluppatore. Apple invia un CONSUMPTION_REQUEST e ti dà 12 ore per rispondere con i dati di consumo tramite Send Consumption Information. Google Play invia una revisione del chargeback, e hai 24 ore per rispondere tramite orders.reviewrefund. Entrambe le risposte vengono firmate con credenziali che appartengono a un account, non all'app. È lì che i trasferimenti si rompono.

Il meccanismo dei rimborsi che si rompe durante un trasferimento

Un'app trasferita può continuare a vendere per settimane senza che nessuno si accorga che il lato rimborsi si è spento.

L'URL delle notifiche e la chiave In-App Purchase di Apple

L'URL di App Store Server Notifications si imposta app per app, sotto App information in App Store Connect. La guida di Apple al trasferimento non lo menziona, quindi il nuovo proprietario dovrebbe aprire quella schermata il primo giorno e puntare produzione e sandbox al proprio server. Se indica ancora l'endpoint del venditore, ogni CONSUMPTION_REQUEST dell'app arriva a un server che l'acquirente non gestisce, e le 12 ore passano nel silenzio.

Le risposte passano dalla App Store Server API, che richiede una chiave In-App Purchase. Queste chiavi le genera in Users and Access un Account Holder o un Admin, e Apple permette di scaricarle una sola volta ciascuna. La chiave del venditore vive nell'account del venditore. L'acquirente dovrebbe generarne una propria, e il venditore dovrebbe revocare la sua a passaggio di consegne concluso.

Il segreto condiviso e i webhook di Apple

Per le app con abbonamenti a rinnovo automatico, Apple chiede al venditore di generare un segreto condiviso specifico dell'app prima del trasferimento e di condividerlo con il destinatario, che lo usa per verificare gli abbonamenti. Una volta completato il trasferimento, il destinatario dovrebbe generarne uno nuovo, così che nessuno al di fuori della sua organizzazione lo abbia più. Anche i webhook di App Store Connect passano al destinatario, e Apple suggerisce al venditore di eliminarli prima se non vuole che in seguito gli eventi continuino ad arrivare al suo server.

Le autorizzazioni e il progetto Cloud di Google

Google dice che le autorizzazioni e le impostazioni di collegamento dei servizi integrati non si trasferiscono. Chiede al venditore di aggiungere l'account di destinazione come Owner di tutti i progetti Google Developers Console usati dall'app. Su Play, di solito è lì che si trovano il tuo argomento per le notifiche in tempo reale per gli sviluppatori e l'account di servizio dietro le tue chiamate alla Developer API. Se l'account di servizio non riceve accesso nella Play Console dell'acquirente, i controlli sugli acquisti annullati falliscono e una risposta orders.reviewrefund non può partire entro le sue 24 ore.

Quanto costa un trasferimento in rimborsi e chargeback

I meccanismi descritti sopra si traducono in soldi in tre punti.

Servi utenti che hanno pagato il venditore

Prendi un abbonato che ha acquistato un piano annuale da $59,99 un mese prima della vendita. Su Google Play quell'ordine sta nell'account del venditore. Sull'App Store il suo registro di pagamento resta al venditore. L'acquirente non riceve alcun pagamento per lui e intanto sostiene il calcolo, le chiamate ad API di terze parti e lo spazio di archiviazione che quell'abbonato usa per il resto dell'anno. Se in seguito quell'abbonato chiede un rimborso all'acquirente, l'acquirente non può emetterlo su Google Play senza il venditore. Conta questi abbonamenti prepagati al momento della firma, perché sono un costo che l'acquirente si accolla senza entrate collegate.

Chargeback su ordini che l'acquirente non ha mai venduto

Per gli ordini Google Play effettuati dopo il 3 agosto 2026, lo sviluppatore risponde del prezzo d'acquisto del chargeback, al netto della commissione di servizio di Play, più la commissione di chargeback della banca. Un chargeback, una volta deciso, è definitivo per la banca. La pagina di Google sul trasferimento non dice come viene gestito quel costo per un ordine rimasto nell'account del venditore. Finché Google non lo chiarisce, un contratto di vendita dovrebbe dire chi paga un chargeback su un ordine precedente al trasferimento e chi risponde alla relativa revisione del chargeback.

La fascia del 15% conta due volte gli stessi guadagni

La commissione di servizio del 15% di Google Play si applica al primo $1 milione di guadagni di uno sviluppatore ogni anno. Quando un'app passa tra account sviluppatore in Account Groups diversi, tutti i guadagni dell'app per quell'anno solare vengono inclusi nei totali di entrambi i gruppi. L'esempio di Google stessa è un'app che ha guadagnato $100.000 nell'Account Group A e passa all'Account Group B. Quei $100.000 contano per il primo $1 milione di entrambi i gruppi. Un acquirente vicino alla soglia può arrivare alla tariffa standard prima di quanto suggeriscano le sue vendite.

Cosa definire prima di trasferire un'app

Per il venditore

• Scarica i report che ti serviranno. L'esportazione collettiva, le vendite stimate e i report sui guadagni di Google non si trasferiscono, e il destinatario su Apple non vedrà il tuo storico.
• Tieni l'account originale aperto e raggiungibile finché i rimborsi e le contestazioni precedenti al trasferimento non hanno fatto il loro corso.
• Genera e condividi il segreto condiviso specifico dell'app prima di un trasferimento sull'App Store, poi revoca la tua chiave In-App Purchase ed elimina i webhook che non vuoi più vedere attivarsi.

Per l'acquirente

• Imposta il tuo URL di App Store Server Notifications e genera la tua chiave In-App Purchase fin dal primo giorno.
• Dai accesso al tuo account di servizio nella tua Play Console e verifica che le notifiche in tempo reale per gli sviluppatori arrivino al tuo endpoint.
• Fatti dare un elenco degli abbonamenti prepagati e dei grandi acquisti recenti, così sai chi servirai senza entrate.
• Metti nel contratto di vendita i rimborsi, i chargeback e le revisioni dei chargeback precedenti al trasferimento, con un referente nominato dalla parte del venditore.

RefundHalt si collega a ogni app con le credenziali dell'account che ne è proprietario. Dopo un trasferimento, collega l'app dall'account del nuovo proprietario, e da quel momento le richieste di consumo e le revisioni dei chargeback arriveranno al nuovo proprietario.