Perdere le notifiche di rimborso può costarti gli unici rimborsi che puoi contestare, ed entrambi gli store ti permettono di recuperarle se controlli in tempo

Perdere le notifiche di rimborso è il modo silenzioso in cui uno sviluppatore perde le uniche due decisioni di rimborso in cui ha voce in capitolo. Il CONSUMPTION_REQUEST di Apple e la revisione dei chargeback di Google Play iniziano entrambi con una notifica, ed entrambi si chiudono con una scadenza breve: 12 ore su Apple, 24 ore su Google. Se il tuo server è giù, lento o configurato male quando arriva quel messaggio, lo store non ti aspetta. Decide con quello che ha già.

La buona notizia è che nessuno dei due store butta via il messaggio al primo errore. Apple ritenta e conserva una cronologia di 180 giorni che puoi interrogare. Google pubblica tramite Pub/Sub, che conserva per giorni i messaggi non confermati. La cattiva notizia è che i tempi dei nuovi tentativi non coincidono con le finestre di risposta, e una delle due procedure non ha alcuna API di recupero.

Come ogni store consegna le notifiche di rimborso

Apple invia le App Store Server Notifications direttamente a un URL HTTPS che imposti in App Store Connect. Google non chiama direttamente il tuo server. Pubblica le notifiche in tempo reale per sviluppatori (Real-time developer notifications) su un topic di Google Cloud Pub/Sub, e la tua sottoscrizione a quel topic le invia al tuo endpoint oppure aspetta che sia il tuo server a prelevarle.

Cosa Apple considera un errore

La documentazione di Apple è precisa. Restituisci uno stato da 200 a 206 e la consegna è conclusa. Restituisci un 40x o un 50x e Apple ritenta. Apple considera non riuscito anche qualsiasi altro codice. Ogni tentativo viene registrato con un sendAttemptResult, e i valori sembrano un elenco di guasti reali: TIMED_OUT, TLS_ISSUE, CIRCULAR_REDIRECT, NO_RESPONSE, PREMATURE_CLOSE, UNSUCCESSFUL_HTTP_RESPONSE_CODE e pochi altri. Per TIMED_OUT, il consiglio di Apple stessa è verificare che il tuo server non elabori i messaggi in modo sincrono.

Cosa Google considera un errore

In una sottoscrizione push, un codice di risposta di successo dal tuo endpoint vale come conferma. In una sottoscrizione pull, il tuo server deve confermare ogni messaggio che preleva, altrimenti Pub/Sub lo consegna di nuovo. La scadenza di conferma predefinita è di 10 secondi e il massimo è di 600 secondi. La guida RTDN di Google aggiunge una regola che vale la pena ripetere: una notifica dice solo che qualcosa è cambiato, quindi devi comunque chiamare la Google Play Developer API per ottenere lo stato completo dell'acquisto.

Perché il calendario dei nuovi tentativi di Apple non sta nella finestra di 12 ore

Gli intervalli dei nuovi tentativi di Apple si misurano dal tentativo precedente, non dal primo. Sommandoli ottieni questa sequenza per una singola notifica V2 che il tuo server continua a non ricevere.

Apple ti chiede di rispondere entro 12 ore dalla ricezione del CONSUMPTION_REQUEST. Se il tuo server è giù alla prima consegna e al nuovo tentativo un'ora dopo, il tentativo successivo arriva 13 ore dopo il primo. Apple non dice se una richiesta ricevuta per la prima volta durante un nuovo tentativo ottiene 12 ore nuove. La lettura prudente è considerare il primo tentativo come inizio del conteggio, il che significa che i soli nuovi tentativi non salveranno una richiesta persa per più di un'ora.

Apple ritenta dopo un HTTP 400?

Sì, secondo la documentazione. Apple indica 40x e 50x come i codici che attivano un nuovo tentativo. A marzo 2026 uno sviluppatore ha segnalato sui forum di Apple che i nuovi tentativi dopo risposte 400 sembravano essersi fermati, poi ha detto che le consegne erano riprese un giorno o due dopo, e Apple ha chiesto una segnalazione tramite Feedback Assistant. Considera il comportamento documentato come la regola e il tuo monitoraggio come la prova.

Recupera le notifiche App Store perse con Get Notification History

Get Notification History restituisce le notifiche della versione 2 che Apple ha tentato di inviare al tuo server nell'intervallo che scegli. Ogni record contiene il payload firmato completo, quindi puoi passarlo allo stesso handler di una notifica in tempo reale. Ogni record include anche un array sendAttempts con al massimo sei voci, una per il primo invio e una per ciascuno dei cinque nuovi tentativi.

• startDate ed endDate sono obbligatori, e startDate deve rientrare negli ultimi 180 giorni in produzione o negli ultimi 30 giorni in sandbox.
• Imposta onlyFailures su true per ottenere solo le notifiche che non hanno raggiunto il tuo server, più quelle che Apple sta ancora ritentando.
• Filtra per un notificationType, come CONSUMPTION_REQUEST o REFUND, oppure per un transactionId di un singolo cliente, ma non per entrambi nella stessa richiesta.
• Ogni chiamata restituisce al massimo 20 record. Continua a chiamare con il paginationToken finché hasMore è true, e invia ogni volta lo stesso corpo della richiesta.

Per i rimborsi conta una precisazione. Apple dice che i record della cronologia riflettono lo stato di un acquisto al momento del primo invio della notifica, non quello attuale. Quindi un REFUND recuperato è un fatto del passato. Prima di revocare l'accesso, verifica lo stato attuale con gli endpoint della transazione o dello stato dell'abbonamento.

Le notifiche V1 non si recuperano così

Get Notification History copre solo la versione 2. Apple ritenta le notifiche V1 tre volte, a 6, 24 e 48 ore dal tentativo precedente, e se falliscono tutte non c'è alcuna cronologia da riprodurre. È un motivo in più per passare a V2 qualsiasi app ancora su V1.

Recupera le notifiche di rimborso di Google Play perse

La rete di sicurezza di Google è Pub/Sub stesso. Finché la tua sottoscrizione esiste, un messaggio che nessuno ha confermato resta lì per il periodo di conservazione, 7 giorni di default e fino a 31 giorni se lo aumenti. Quando il tuo endpoint torna attivo, la consegna riprende. Due impostazioni possono vanificare tutto senza dare segnali.

• Un topic di messaggi non recapitabili (dead-letter) sposta un messaggio fuori dalla tua sottoscrizione dopo un numero stabilito di tentativi di consegna falliti. Il valore predefinito è 5, e con la policy di nuovo tentativo predefinita, che riconsegna subito, cinque tentativi possono passare in fretta. Se ne usi uno, tienilo d'occhio come una seconda casella di posta.
• Una sottoscrizione senza attività dei sottoscrittori, come connessioni aperte, pull attivi o push riusciti, scade dopo 31 giorni di default. Un endpoint che resta guasto per un mese può perdere la sottoscrizione stessa, insieme a tutto ciò che vi era in attesa.

I rimborsi annullati hanno un backup di 30 giorni

Per i rimborsi già avvenuti, la Voided Purchases API è il backup in pull. Elenca gli acquisti annullati degli ultimi 30 giorni, fino a 1.000 per pagina, con una quota di 6.000 query al giorno e 30 query in qualsiasi periodo di 30 secondi per ogni app. Passa type 1 per includere gli abbonamenti insieme ai prodotti ad acquisto singolo. Eseguirla ogni giorno intercetta qualsiasi rimborso perso dalla tua pipeline di notifiche, e mantiene corretti diritti di accesso e numeri dei ricavi.

Le revisioni dei chargeback non lo hanno

Una PendingRefundReviewNotification è diversa. Contiene il pendingRefundToken che devi passare a orders.reviewrefund, e hai 24 ore dalla ricezione per inviare la tua preferenza di rimborso e le prove di utilizzo. Google registra la tua prima chiamata e ignora le altre. La documentazione di Google non descrive alcun endpoint che elenchi le revisioni in sospeso, quindi se quel messaggio Pub/Sub va perso, le tue prove per quel chargeback vanno perse con lui.

Quanto costa in denaro una notifica di rimborso persa

Una notifica persa per un rimborso già definitivo ti costa lavoro contabile. La ritrovi più tardi nella Voided Purchases API o in Get Notification History, revochi l'accesso se la tua policy lo prevede, e i tuoi report si riallineano. Fastidioso, ma economico.

Una notifica persa in una delle due procedure contestabili costa denaro vero, perché lo store decide senza le tue prove. Su Apple significa che la decisione sul rimborso viene presa senza i tuoi dati di consumo. Su Google Play, per gli ordini effettuati dopo il 3 agosto 2026, un chargeback perso ti costa il prezzo d'acquisto meno la commissione di servizio di Play, più la commissione di chargeback addebitata dalla banca dell'acquirente. Google copre solo la propria commissione di servizio.

E il denaro speso per erogare l'acquisto era già andato prima che iniziasse la contestazione.

• Calcolo: tempo di GPU e di server dietro ogni generazione, rendering o risposta del modello che l'acquirente ha già usato.
• Chiamate API: richieste a terzi fatturate nel momento in cui sono partite, spesso a chiamata.
• Archiviazione: file e contenuti multimediali creati dall'acquirente, ancora nella tua bolletta di hosting.
• Compensi: quote di ricavo già pagate a creator, affiliati o partner su quella vendita.

Niente di tutto questo torna indietro quando un rimborso va a buon fine. Le prove che invii in quelle 12 o 24 ore sono l'unica leva che hai, e una notifica persa te la toglie.

Una procedura di recupero che regge

• Conferma prima di tutto. Salva il payload grezzo, restituisci un codice di successo, poi elaboralo in una coda.
• Interroga Get Notification History di Apple con onlyFailures ogni pochi minuti per CONSUMPTION_REQUEST, così un'interruzione costa solo minuti della finestra di 12 ore.
• Esegui ogni giorno una scansione di Get Notification History con onlyFailures sugli ultimi giorni per tutti i tipi, e riproduci ciò che trovi.
• Esegui ogni giorno una chiamata alla Voided Purchases API con type 1 per ogni app Google Play, e riconcilia il risultato con i rimborsi che hai già registrato.
• Su Pub/Sub, mantieni la conservazione dei messaggi a 7 giorni o più, imposta un avviso sul topic dei messaggi non recapitabili se ne hai uno, e un avviso quando i messaggi non consegnati si accumulano.
• Testa l'intero percorso anche in produzione. Il sandbox di Apple invia ogni notifica una sola volta, senza nuovi tentativi, e Request a Test Notification insieme a Get Test Notification Status mostrano esattamente come ha risposto il tuo server.

RefundHalt riceve per te le notifiche di entrambi gli store e risponde automaticamente ai CONSUMPTION_REQUEST e alle revisioni dei chargeback entro le scadenze, così non sei tu a dover tenere d'occhio l'orologio.