Esiste un endpoint che restituisce l'intera cronologia dei rimborsi App Store di un cliente, ed ecco cosa restituisce

Apple conserva un registro consultabile di ogni rimborso concesso sull'account di un cliente per la tua app, e una sola chiamata lo restituisce. L'endpoint è Get Refund History, parte dell'App Store Server API, e ti consegna la cronologia completa dei rimborsi App Store di quel cliente come elenco di transazioni firmate. Passi un id di transazione, ricevi ciò che Apple ha rimborsato, e lo riconcili con ciò che hai ancora attivo.

Ecco perché ne vale la pena. Un rimborso che non vedi mai è un rimborso che continui a pagare. Il denaro è già andato, ma l'account resta attivo, e ogni ora che lo è continui a spendere in calcolo, chiamate all'API del modello, archiviazione e qualsiasi pagamento legato a quel cliente. Le tue notifiche di rimborso dovrebbero intercettarlo nel momento in cui accade. Get Refund History è la rete di sicurezza per quando non lo fanno, dopo un'interruzione, un deploy che ha perso un webhook, o un caso di assistenza in cui ti serve il quadro completo in una sola chiamata.

Cosa restituisce l'endpoint della cronologia dei rimborsi App Store

Chiami GET /inApps/v2/refund/lookup/{transactionId} sull'App Store Server API, firmato con lo stesso JWT che usi per ogni altra chiamata. L'id di transazione nel percorso può essere qualsiasi transazione del cliente. Apple lo legge come un'identità, non come un filtro, e restituisce gli acquisti rimborsati di quel cliente in tutta la tua app: consumabili, non consumabili, abbonamenti a rinnovo automatico e non rinnovabili allo stesso modo. La vecchia V1 di questo endpoint restituiva fino a 50 rimborsi in una singola risposta ed è deprecata. La versione attuale pagina, così gestisci clienti con cronologie lunghe senza un payload gigante.

La risposta è composta da tre campi

Cosa ti dice una transazione rimborsata

Ogni voce in signedTransactions è un JWS. Verificalo contro la catena di certificati di Apple, decodificalo, e hai un payload di transazione ordinario con i campi di rimborso compilati. Sono questi quelli che contano qui.

Il token revision è come smetti di rileggere l'intero elenco

Il modo ingenuo di usare questo endpoint è cercare un cliente e percorrere ogni pagina ogni volta. Funziona, e su un cliente con cinquanta rimborsi sono cinquanta righe che già conoscevi più l'unica nuova. Il token revision esiste per eliminare quello spreco. Ogni risposta porta un revision. Quando hasMore è vero, lo rimandi per ottenere la pagina successiva. Quando arrivi alla fine, conservi l'ultimo revision che hai visto.

Cosa questo endpoint non farà

C'è un'aspettativa da abbandonare prima di costruirci sopra. Get Refund History funziona per cliente, non per app. Non puoi chiedergli tutti i rimborsi che la tua app ha subito la settimana scorsa. Risponde a una domanda, quali rimborsi ha questo account, e devi arrivare con un id di transazione di quell'account per porla. Gli sviluppatori sbattono contro questo muro di continuo e vanno a cercare un endpoint di rimborsi sull'intera app che non esiste.

La vista sull'intera app vive altrove. Il tuo feed App Store Server Notifications invia una notifica REFUND nel momento in cui Apple ne concede ciascuno, e Get Notification History ti permette di riprodurre quel feed filtrato sui tipi di rimborso in un intervallo di date. Quindi la divisione è netta. Le notifiche e la loro cronologia ti danno il flusso sull'intera app. Get Refund History ti dà l'elenco autorevole di un account, su richiesta, che è ciò che vuoi a un banco di assistenza o dopo un'interruzione.

Quanto ti costa in denaro un rimborso mancato

L'endpoint è l'impianto idraulico. La bolletta è il motivo per cui posi il tubo. Ogni rimborso in quell'elenco è denaro già restituito, e l'unica variabile rimasta sotto il tuo controllo è per quanto tempo continui a spendere su un account che non paga più.

Continui a pagare per servire un account rimborsato

Il prezzo d'acquisto sparisce nell'istante in cui Apple concede il rimborso. Ciò che continua a girare è il costo dell'erogazione. Per un'app che fa lavoro reale per utente, è calcolo, chiamate all'API del modello, archiviazione e qualsiasi pagamento a creator o partner legato al suo utilizzo. Un cliente rimborsato a cui non tagli mai l'accesso è un abbonamento che finanzi di tasca tua. Riconciliare contro Get Refund History e revocare in base a ciò che trovi è come spegni quel contatore quando una notifica è passata inosservata.

Un motivo di rimborso pari a 1 è una segnalazione di difetto travestita

revocationReason ti costa il doppio se lo ignori. Il primo costo è il rimborso stesso. Il secondo è ogni rimborso futuro dovuto alla stessa causa. Quando un prodotto continua a tornare con revocationReason 1, un problema reale o percepito nella tua app, Apple ti sta consegnando un campione etichettato di ciò che spinge i clienti a chiedere indietro i soldi. Analizzane l'andamento per prodotto e potrai tappare la falla invece di pagarla un rimborso alla volta.

Intercettarlo tardi è comunque meglio che non intercettarlo

Uno storno è definitivo con la banca e, sull'altro store, ora comporta una commissione che lo sviluppatore assorbe. Un rimborso App Store non è così. È liquidato, ma il diritto è tuo da revocare nel momento in cui lo sai. Quindi anche un rimborso che trovi con giorni di ritardo tramite questo endpoint vale la pena trovarlo. Non puoi recuperare il denaro, ma puoi fermare la spesa che ancora girava dietro di esso.

Come si integra con le notifiche, e con Google

Pensa ai pezzi come a un unico sistema. La notifica REFUND è il segnale in tempo reale, inviato al tuo server man mano che Apple decide. Get Refund History è la fonte di verità in modalità pull per un singolo cliente, la chiamata che fai quando l'invio è fallito o quando una persona ha bisogno dell'account completo davanti. Sul lato Google Play la forma è la stessa idea con nomi diversi: una VoidedPurchaseNotification viene inviata in tempo reale, e la Voided Purchases API è l'elenco che estrai. Entrambi gli store ti danno un flusso e un registro. L'errore è fidarsi solo del flusso, perché i flussi cadono.

Configurarlo alla maniera di RefundHalt

Il ciclo è breve una volta che ogni pezzo è al suo posto. Prendi una notifica REFUND come trigger. Riconcilia contro Get Refund History così che un webhook perso non lasci mai attivo un account rimborsato. Decodifica ogni transazione, collegala tramite appAccountToken o transactionId al tuo utente, leggi revocationReason così che un rimborso da difetto venga segnalato e non solo archiviato, e revoca il diritto esatto invece dell'intero account. Pagina con il token revision così da leggere i rimborsi nuovi, non quelli vecchi.

Questa è la parte che RefundHalt esegue per te. Ascolta le notifiche di rimborso, ricorre a Get Refund History quando gli serve l'elenco autorevole, verifica ogni transazione firmata, revoca l'acquisto preciso, e conserva il revision così che ogni passaggio legga solo ciò che è cambiato. Ottieni l'accesso tagliato in pochi secondi e un registro pulito di chi è stato rimborsato, per cosa e perché, senza dover allestire tu stesso il polling e la verifica JWS.