La tua app può mostrare un foglio di richiesta di rimborso dentro l'app, ed ecco cosa fa Apple dopo che il cliente tocca invia

Apple permette a un cliente di richiedere un rimborso senza mai uscire dalla tua app. Una sola chiamata di StoreKit, beginRefundRequest, presenta il foglio di rimborso di Apple stessa proprio dentro la tua interfaccia, il cliente sceglie un motivo, e la richiesta va ad Apple per l'esame. Non costruisci il modulo, non tocchi il denaro, e non decidi l'esito. Quello che ottieni è un modo per mettere un percorso di rimborso dove il cliente frustrato già si trova, invece di perderlo a favore della sua banca. Questa è la richiesta di rimborso dentro l'app, e vale la pena capirla prima di decidere se pubblicare il pulsante.

Ecco la parte che conta per i tuoi ricavi. Il pulsante non rimborsa nulla da solo. Apre una richiesta, Apple impiega fino a 48 ore per approvarla o negarla, e per gli acquisti consumabili prima invia un CONSUMPTION_REQUEST al tuo server. Quindi il foglio non è un regalo. È un imbuto verso lo stesso esame di rimborso che puoi già influenzare, e può riportare indietro una contestazione dalla rete delle carte prima che diventi un chargeback che non puoi contestare.

Cos'è davvero il foglio di richiesta di rimborso dentro l'app

beginRefundRequest è un metodo di StoreKit 2 che presenta il foglio di richiesta di rimborso per una transazione in una scena di finestra. La firma è breve: func beginRefundRequest(in scene: UIWindowScene) async throws -> Transaction.RefundRequestStatus. Quando lo chiami, il sistema mostra un foglio con i dettagli dell'acquisto del cliente e un elenco di codici di motivo tra cui scegliere. Apple costruisce e controlla quell'interfaccia. Tu fornisci la scena e la transazione, nient'altro.

La raccomandazione di Apple su dove metterlo è esplicita. Chiama questa funzione dalle impostazioni dell'account o da un menu di aiuto, così un cliente che vuole un rimborso lo trova dove cercherebbe assistenza. È arrivato in iOS 15 e iPadOS 15, Mac Catalyst 15 e visionOS 1, quindi qualsiasi app che punta a quelle versioni può presentarlo oggi.

Due modi per aprire il foglio

Ci sono due punti di ingresso. Puoi chiamare beginRefundRequest(in:) su una transazione specifica che già possiedi, il che limita il foglio a quell'unico acquisto. Puoi anche aprire il foglio per identificatore di prodotto quando vuoi che il cliente rimborsi l'acquisto di un dato prodotto. In entrambi i casi, il foglio, l'elenco dei motivi e la decisione appartengono ad Apple. Il tuo compito finisce nel presentarlo e leggere il risultato.

Cosa restituisce la chiamata, e cosa può andare storto

Il metodo è async throws, quindi o restituisce uno stato o lancia un errore. Entrambe sono liste brevi, ed entrambe meritano di essere gestite affinché la tua interfaccia dica qualcosa di vero quando il foglio si chiude.

Cosa succede sul tuo server dopo che il cliente tocca invia

La chiusura del foglio è l'inizio del processo, non la fine. Apple esamina la richiesta e impiega fino a 48 ore per approvarla o negarla. Per un acquisto in-app consumabile, prima di decidere, l'App Store invia una notifica CONSUMPTION_REQUEST al tuo server chiedendo dati di utilizzo. Se il cliente ha acconsentito a condividere quei dati, rispondi tramite l'endpoint Send Consumption Information. Se non ha acconsentito, l'istruzione di Apple stessa è di non rispondere affatto alla notifica.

Una volta che Apple decide, l'esito atterra sul tuo server come un App Store Server Notification. È lo stesso flusso che già ricevi, e la richiesta dentro l'app vi viene instradata esattamente come un rimborso che un cliente avvia dalla pagina reportaproblem di Apple. Nulla della gestione cambia solo perché la richiesta è iniziata dentro la tua app.

Cosa ti costa il pulsante, e cosa può farti risparmiare

Un rimborso che puoi contestare batte un chargeback che non puoi

Un cliente che non trova un percorso di rimborso dentro la tua app non si arrende. Va dalla sua banca. Un chargeback di carta è definitivo con la banca, comporta una commissione di contestazione, e toglie la decisione dalle tue mani e da quelle di Apple. Una richiesta di rimborso dentro l'app tiene quello stesso cliente dentro il sistema di Apple, dove un acquisto consumabile attiva un CONSUMPTION_REQUEST a cui puoi rispondere e una decisione che puoi influenzare. Scambiare un chargeback incontestabile con un esame contestabile di Apple è tutto l'argomento finanziario a favore del pulsante.

Stai abbassando l'attrito su un rimborso

Il contrappeso onesto è che un percorso di rimborso visibile e con un solo tocco produce più richieste di rimborso di quante ne produca un'email di assistenza sepolta. Alcune di quelle non sarebbero mai avvenute. Questo è un costo reale, ed è per questo che Apple ti dice di collocare il punto di ingresso nelle impostazioni dell'account o in un menu di aiuto anziché nella schermata di acquisto. Vuoi che lo trovi il cliente già insoddisfatto, non il cliente che è solo curioso.

Il costo che corre per tutto il tempo è servire un account rimborsato

Comunque vada la decisione, il contatore della fornitura continua a correre finché non agisci sull'esito. Ogni ora che un diritto rimborsato resta attivo, continui a pagare i costi reali che lo sostengono: calcolo, chiamate all'API del modello, archiviazione, e qualsiasi pagamento a creator o partner legato all'utilizzo di quel cliente. La richiesta dentro l'app non cambia questo. Revocare prontamente sulla notifica REFUND sì. Il pulsante è economico solo quanto lo è la tua gestione della notifica che alla fine produce.

Dovresti pubblicare la richiesta di rimborso dentro l'app?

Mettila dove vive l'assistenza, non dove vivono le vendite

Segui la raccomandazione di posizionamento di Apple. Le impostazioni dell'account e un menu di aiuto sono le case giuste. Un link di rimborso accanto a un paywall abitua le persone ad aspettarsi indietro i loro soldi, e invita il rimborso di curiosità che non avevi mai avuto bisogno di offrire.

Prova l'intero flusso nel sandbox prima di fidarti

Puoi simulare l'intero percorso nel sandbox e nel test di StoreKit in Xcode, spostando una richiesta da in sospeso ad approvata o negata. Un'approvazione consegna una notifica REFUND al tuo server, e un diniego consegna REFUND_DECLINED, così puoi dimostrare che il tuo gestore reagisce correttamente prima che un cliente reale tocchi invia.

Gestisci ogni risultato, e non esagerare mai

Mostra in sospeso su success, offri un nuovo tentativo su failed, di' che nulla è cambiato su userCancelled, e tratta duplicateRequest come una nota discreta che la precedente richiesta del cliente è ancora valida. L'unico errore che fa male è dire a un cliente che il suo rimborso è fatto quando tutto ciò che hai è una richiesta inviata.

Come RefundHalt gestisce ciò che viene dopo

Il foglio dentro l'app è di Apple. Ciò che viene dopo è tuo, ed è la parte che RefundHalt esegue. Quando un cliente invia un rimborso da dentro la tua app, RefundHalt cattura il CONSUMPTION_REQUEST per gli acquisti consumabili e vi risponde entro la finestra di 12 ore con le prove di utilizzo che aiutano Apple a decidere. Quando Apple decide, revoca su REFUND e mantiene l'accesso intatto su REFUND_DECLINED, ciascuno legato alla transazione esatta. Puoi offrire il percorso di rimborso più amichevole dentro l'app senza lasciare l'esame, le prove o la revoca a una corsa manuale.