Il rilevamento dei rimborsi in StoreKit 2 si riduce a una sola proprietà della transazione, ed è revocationDate

La maggior parte delle app viene a sapere di un rimborso Apple dal proprio server, tramite una App Store Server Notification, e non nota mai che lo stesso rimborso è già dentro l'app. È sulla transazione, in una proprietà chiamata revocationDate, e leggerla permette alla tua app di togliere l'accesso a un cliente rimborsato alla prossima apertura, invece di attendere un job del backend. Il rilevamento dei rimborsi di StoreKit 2 è un segnale lato client che la maggior parte dei team salta. Ecco esattamente dove un rimborso compare sul dispositivo, cosa ti dice, cosa non ti dice, e perché deve stare accanto alle tue notifiche server e non al loro posto.

Dove compare un rimborso dentro StoreKit 2

StoreKit 2 ti consegna le transazioni come valori firmati, e un rimborso non elimina la transazione. La contrassegna. Due proprietà della Transaction portano il contrassegno, ed entrambe restano nil per tutta la vita di un acquisto sano. Quando una delle due diventa non nil, l'App Store ha ripreso l'acquisto.

revocationDate è il campo che cambia

revocationDate è un Date opzionale. La descrizione di Apple stessa è precisa: è la data in cui l'App Store ha rimborsato la transazione o l'ha revocata da Family Sharing. Per un acquisto ancora valido, vale nil. Nel momento in cui un rimborso viene elaborato, contiene il timestamp di quel rimborso. Quell'unico controllo, se revocationDate è non nil, è tutto il rilevamento dei rimborsi lato client. Tutto il resto è sfumatura accatastata sopra.

revocationReason ti dice perché Apple lo ha ritirato

revocationReason sta accanto alla data e ne spiega la causa. StoreKit le assegna due valori che contano per i rimborsi. developerIssue significa che il cliente ha detto ad Apple che il rimborso era dovuto a un problema reale o percepito nella tua app. other copre ogni altro motivo. Un terzo valore, upgradedToBundle, non è affatto un rimborso; segnala una transazione che l'App Store ha revocato perché il cliente è passato a un pacchetto di abbonamento. Leggi il motivo prima di agire, perché developerIssue è quello che vale la pena contare: un gruppo di questi è il tuo stesso prodotto che ti dice dove si è rotto.

currentEntitlements scarta già un acquisto rimborsato

Non devi sempre leggere tu stesso i campi di revoca. Transaction.currentEntitlements è la sequenza degli acquisti a cui un cliente ha ancora diritto in questo momento, e Apple la costruisce per lasciare fuori quelli che non dovresti onorare. Un prodotto che l'App Store ha rimborsato o revocato non vi compare. Nemmeno gli abbonamenti scaduti, né i consumabili, che spariscono nel momento in cui vengono usati.

Questo rende currentEntitlements il filtro più pulito per l'accesso. Chiedile cosa possiede il cliente, concedi esattamente quello, e un rimborso rimuove il diritto al posto tuo senza un solo controllo di revocationDate. I campi di revoca servono quando vuoi il dettaglio, la data e il motivo, per registrare l'evento o reagirvi. La lista dei diritti serve alla semplice domanda se tenere le luci accese.

Il rilevamento dei rimborsi di StoreKit 2 in pratica, dall'avvio e mentre l'app gira

Ci sono due momenti in cui la tua app può cogliere un rimborso sul dispositivo, e richiedono codice diverso. Uno è mentre l'app è aperta e un rimborso avviene in diretta o su un altro dispositivo. L'altro è all'avvio, recuperando tutto ciò che è cambiato mentre eri chiuso. Manca il secondo e il tuo rilevamento dei rimborsi di StoreKit 2 ha un buco proprio dove cade la maggior parte dei rimborsi, perché i clienti raramente hanno la tua app aperta quando ne chiedono uno.

Inizia ad ascoltare all'avvio o perdi i rimborsi avvenuti a chiusura

Transaction.updates è la sequenza asincrona che emette una transazione ogni volta che il sistema ne crea o aggiorna una fuori dalla tua app o su un altro dispositivo, un rimborso compreso. L'istruzione di Apple è netta: avvia un Task che la scorra non appena la tua app parte, altrimenti puoi perdere le transazioni che consegna una sola volta all'avvio. Un rimborso arrivato nella notte giunge tramite updates alla prossima apertura dell'app, ma solo se un ascoltatore è già in esecuzione per riceverlo. Nessun ascoltatore, nessun evento, e il rimborso resta invisibile finché qualcos'altro non lo riconcilia.

Un acquisto sullo stesso dispositivo non arriva tramite updates

Una trappola coglie chi prova i rimborsi a mano. Un acquisto normale fatto sullo stesso dispositivo non arriva tramite updates; StoreKit lo restituisce direttamente dal risultato della chiamata di acquisto. updates è per i cambiamenti fuori banda: rimborsi, approvazioni di Ask to Buy, riscatti di codici promozionali e acquisti fatti altrove. Quindi costruisci la tua gestione dei rimborsi attorno a updates e currentEntitlements, non attorno al flusso di acquisto, perché il rimborso non tornerà mai indietro per la strada che ha preso la vendita.

Cosa il rilevamento lato client non può fare per te

Leggere i rimborsi sul dispositivo è veloce ed è gratis, ma ha un limite, e fingere che non ce l'abbia è il modo in cui i ricavi si perdono. Il dispositivo sa solo ciò che StoreKit gli ha detto, e StoreKit parla solo mentre la tua app è in esecuzione. Un cliente che ottiene un rimborso e non riapre mai la tua app è un cliente che il tuo controllo lato client non vede mai.

Una revocationDate non è sempre un rimborso

Lo stesso campo cambia per Family Sharing. Quando un cliente perde l'accesso a un acquisto condiviso, perché l'organizzatore lo ha rimosso o la condivisione è finita, anche quella transazione riceve una revocationDate. Quindi una data non nil significa che il cliente non ha più questo acquisto, che è esattamente ciò che ti serve per il controllo dell'accesso, ma non significa sempre che del denaro sia tornato indietro. Se stai contando i rimborsi per i ricavi, separa le revoche di Family Sharing da quelle reali prima di fidarti del numero.

Un rimborso può essere annullato

Un rimborso non è sempre definitivo. Apple può annullarne uno, e quando lo fa, i campi di revoca vengono rimossi dalla transazione e l'acquisto torna valido. Se hai tolto l'accesso al rimborso, ci si aspetta che tu lo ripristini all'annullamento. Sul dispositivo questo compare come un altro evento updates con una transazione pulita; sul tuo server è una notifica distinta, REFUND_REVERSED. Gestisci solo il rimborso e lascerai a piedi un cliente pagante, senza accesso e con una ricevuta valida.

Quanto costa davvero una revoca tardiva

Un rimborso è raramente solo il prezzo di vendita che lascia il tuo conto. Quando viene liquidato, di solito hai già speso denaro reale per servire quell'acquisto, e quella spesa non torna. Le immagini generate costano minuti di GPU. Le risposte della chat costano chiamate all'API del modello che ti sono state fatturate a token. I caricamenti costano spazio di archiviazione che paghi ancora per conservare. Se l'acquisto ha finanziato un pagamento a un creatore, quel denaro è già uscito dalla porta. Niente di tutto ciò si annulla con il rimborso.

Il rilevamento lato client riduce la finestra sull'unica parte che puoi ancora controllare, cioè la spesa futura. Prima sai che un acquisto è rimborsato, prima smetti di servirlo. Ma il dispositivo ti avvisa solo mentre l'app è aperta, quindi un utente rimborsato che non torna più mantiene l'accesso lato server che gli hai concesso, costandoti in silenzio ogni volta che un job in background o un dispositivo sincronizzato agisce per suo conto. Il client rende la revoca veloce. Non la rende garantita.

Usa il client per la rapidità e il server per la verità

Il design pulito usa entrambi i segnali per ciò in cui ciascuno è bravo. Sul dispositivo, Transaction.updates e currentEntitlements ti danno una reazione locale e istantanea nel momento in cui un cliente rimborsato apre l'app, utile per l'interfaccia e per completare i cambiamenti di diritto senza un viaggio di andata e ritorno. Sul server, le App Store Server Notifications V2 inviano un messaggio REFUND che arriva sia che l'app venga riaperta sia che no, ed è l'unico segnale che ferma in modo affidabile la spesa del tuo backend su un account rimborsato.

Collega i segnali del dispositivo per il cliente che ha il telefono in mano, e la notifica del server per quello che non ce l'ha. Il rimborso compare in entrambi i posti di proposito. Leggerne solo uno è il modo in cui un account rimborsato continua a costarti dopo che la vendita è già andata.