Verifica le notifiche server dell'App Store prima di agire su un rimborso, perché chiunque può inviare richieste al tuo URL di webhook

Chiunque conosca il tuo URL di webhook può inviargli un rimborso. È la scomoda verità dietro ogni notifica server dell'App Store e ogni notifica in tempo reale per sviluppatori di Google Play: finché non la verifichi, il messaggio è soltanto un POST HTTPS con dentro un po' di JSON. Se il tuo server revoca un abbonamento, ritira crediti o banna un account perché una richiesta diceva REFUND, hai consegnato quel potere a chiunque sappia scrivere un comando curl.

Entrambi gli store ti danno un modo per verificare. Apple firma la notifica stessa, quindi puoi verificare le notifiche server dell'App Store con il solo certificato radice di Apple. Google Play segue una strada diversa. Il messaggio non è firmato, ma la consegna di Pub/Sub può esserlo, e Google ti chiede comunque di confermare ogni modifica con la sua API. Ecco che cosa dimostra ciascuno e quanto costa sbagliare in un senso o nell'altro.

Che cosa firma davvero ciascuno store

Come verificare le notifiche server dell'App Store

La documentazione di Apple descrive il signedPayload come una stringa di tre componenti codificati in Base64URL e separati da punti: un header, un payload e una firma, firmata secondo la specifica JSON Web Signature. Decodificare il payload è facile. Fidarsene richiede quattro controlli.

• Leggi l'array x5c dall'header decodificato. Apple ne documenta l'ordine: prima il certificato con la chiave di firma, poi un certificato intermedio Apple, poi un certificato radice Apple.
• Convalida la catena rispetto a una radice Apple che hai scaricato tu stesso dal sito PKI di Apple, in pratica Apple Root CA - G3. Non fidarti mai della radice arrivata dentro il messaggio, perché un falsario può metterci qualsiasi certificato.
• Verifica che l'intermedio abbia l'estensione Apple Worldwide Developer Relations, 1.2.840.113635.100.6.2.1, poi verifica la firma JWS con la chiave pubblica del certificato foglia.
• Confronta i dati decodificati con la tua app: bundleId, appAppleId in produzione ed environment. Una firma Apple valida sull'app di un altro sviluppatore, o su un acquisto sandbox che arriva al tuo endpoint di produzione, continua a non essere il tuo rimborso.

Poi ripeti tutto per ciò che c'è dentro. L'oggetto data contiene signedTransactionInfo e signedRenewalInfo, e ciascuno è un JWS separato con la propria catena x5c. Un handler di REFUND che verifica la busta ma legge la transazione senza verificarla ha lasciato una falla nel mezzo.

Usa la libreria di Apple invece di scriverla da te

Apple pubblica la App Store Server Library per Swift, Java, Python e Node. Il suo SignedDataVerifier riceve i tuoi certificati radice, un flag per i controlli online, l'ambiente, il tuo bundle ID e, per la produzione, il tuo appAppleId. Il codice sorgente Node mostra che cosa impone: esattamente tre certificati nella catena, l'estensione foglia Apple 1.2.840.113635.100.6.11.1 e l'estensione dell'intermedio, le date di validità dei certificati, e bundle ID, ID dell'app e ambiente corrispondenti. Con i controlli online attivi, chiede anche al responder OCSP se i certificati foglia e intermedio sono stati revocati.

Basta una lista di IP consentiti?

No. Apple dice che, se il tuo server ha bisogno di una lista di consentiti, devi aggiungere la sottorete 17.0.0.0/8, e che questo vale sia per la sandbox sia per la produzione. Così riduci il rumore. Non dimostra che un messaggio sia autentico, e smette di funzionare non appena la rete di Apple cambia in un modo di cui non sei stato informato. Mantieni il controllo della firma come vero filtro.

Come verificare le notifiche di rimborso di Google Play

Google Play pubblica i messaggi RTDN in un argomento Pub/Sub di tua proprietà, e solo l'account di servizio google-play-developer-notifications@system.gserviceaccount.com dovrebbe avere su di esso il ruolo di publisher Pub/Sub. La tua sottoscrizione consegna poi i messaggi in uno di due modi, ciascuno con la propria prova.

• Sottoscrizione pull: il tuo server apre una connessione autenticata verso Pub/Sub e recupera i messaggi. Non c'è alcun endpoint pubblico, quindi non c'è nulla a cui un estraneo possa inviare richieste.
• Sottoscrizione push con autenticazione attiva: Pub/Sub firma un JSON Web Token e lo invia nell'header Authorization come token Bearer. La guida di Google indica di convalidare la firma del token e di controllare che i claim email e audience corrispondano ai valori che hai configurato, e il suo codice di esempio richiede anche che email_verified sia true. Il token può avere fino a un'ora di età.
• Sottoscrizione push senza autenticazione: qualunque cosa raggiunga l'URL può inviare un messaggio con la forma di una RTDN.

Perché Google vuole che tu confermi con l'API

Anche una RTDN perfettamente autenticata non racconta tutta la storia. La guida di configurazione di Google afferma chiaramente che queste notifiche ti dicono soltanto che lo stato di un acquisto è cambiato e che devi chiamare la Google Play Developer API per ottenere lo stato completo. Per una voidedPurchaseNotification, ciò significa trovare l'acquisto nella Voided Purchases API, o recuperarne lo stato attuale, prima di revocare qualsiasi cosa. La chiamata all'API è autenticata con il tuo account di servizio, quindi la sua risposta non può essere contraffatta.

Quanto costa in denaro un rimborso falsificato o respinto

Una notifica di rimborso falsificata di cui ti fidi ti costa un cliente pagante. Blocchi qualcuno di cui hai ancora il denaro, questi apre un ticket di assistenza, e alcuni andranno allo store a chiedere il rimborso che il tuo sistema ha già finto di concedere. Un acquisto o un rinnovo falsificato costa nel senso opposto: fornisci calcolo GPU, chiamate a pagamento ad API di terze parti, storage e compensi ai creator a fronte di entrate mai esistite.

L'errore opposto è più silenzioso e spesso più grave. Un verificatore che respinge messaggi autentici, a causa di un appAppleId sbagliato, di un'impostazione sandbox in produzione o di un certificato radice obsoleto, scarta proprio i due flussi di rimborso in cui le tue prove contano. Apple chiede i dati di consumo entro 12 ore da un CONSUMPTION_REQUEST. Google ti concede 24 ore per rispondere a una revisione di chargeback tramite orders.reviewrefund e, per gli ordini effettuati dopo il 3 agosto 2026, un chargeback perso su Google Play ti costa il prezzo di acquisto meno la commissione di servizio di Play, più la commissione addebitata dalla banca dell'acquirente.

Non lasciare che un bug di verifica ti faccia perdere una scadenza

• Salva la richiesta grezza prima di verificarla, così un messaggio respinto non va mai perso davvero.
• Genera un avviso per ogni verifica fallita. Un messaggio falsificato è rumore. Tutti i messaggi che falliscono insieme sono un tuo bug.
• Con Apple puoi rielaborare ciò che hai respinto. Get Notification History restituisce il signedPayload originale degli ultimi 180 giorni, quindi correggi il verificatore e fagli rielaborare i payload salvati o recuperati.
• Con Google, una revisione di chargeback in sospeso esiste solo nella sua notifica, quindi un'audience push configurata male equivale a una revisione persa. Provala con Send Test Message in Play Console dopo ogni modifica.

RefundHalt verifica le notifiche di entrambi gli store, conferma i rimborsi con le API degli store prima che cambi qualsiasi cosa e risponde ai CONSUMPTION_REQUEST e alle revisioni di chargeback entro le rispettive finestre, così un messaggio falso non può costarti un cliente e uno vero non può sfuggirti.