Apple può annullare un rimborso che ha già concesso, e un rimborso annullato che il tuo server ignora blocca un cliente che ha pagato

Un rimborso non è sempre l'ultima parola. L'App Store può annullare un rimborso che ha già concesso, dopo che il cliente lo contesta, e quando quel rimborso annullato arriva sul tuo server porta con sé una sola istruzione: restituisci l'accesso. La maggior parte dei team collega la semplice notifica REFUND, blocca il cliente e si ferma lì. Non costruisce mai l'altra metà. Così, quando arriva l'annullamento, non viene eseguito nulla, e un cliente che sta pagando di nuovo resta bloccato fuori da ciò che ha acquistato. Ecco come funziona l'intero insieme di notifiche di rimborso sull'App Store e su Google Play, e quanto ti costa ognuna quando la ignori.

L'App Store invia tre notifiche di rimborso, non una

La maggior parte della gestione dei rimborsi è costruita per un singolo evento: il denaro è stato restituito, blocca il cliente. Il feed delle App Store Server Notifications V2 in realtà trasporta tre distinti esiti di rimborso, e richiedono tre cose diverse. Due di essi modificano ciò a cui un cliente può accedere. Uno di essi annulla il primo. Ecco l'insieme completo, con le parole di Apple.

REFUND, quella che ogni team gestisce

Quando l'App Store elabora un rimborso, invia una notifica REFUND all'URL che hai configurato, e la definizione di Apple è chiara: 'indica che l'App Store ha rimborsato con successo una transazione per un In-App Purchase consumabile, un In-App Purchase non consumabile, un abbonamento a rinnovo automatico o un abbonamento non rinnovabile.' Registri la transazione rimborsata, revochi qualunque cosa abbia acquistato e Apple ti chiede di comunicare al cliente cosa è cambiato con messaggi contestuali nell'app. Questa è la notifica che tutti collegano per prima, e spesso l'unica.

REFUND_DECLINED, quella che non richiede nulla da te

REFUND_DECLINED significa esattamente ciò che dice: 'l'App Store ha respinto una richiesta di rimborso.' Il cliente ha chiesto, Apple ha detto no e la transazione resta valida. Nulla cambia riguardo all'accesso del cliente, quindi la tua logica dei diritti qui non fa nulla. Il valore di questa notifica è contabile. Chiude il cerchio su una richiesta di rimborso a cui potresti aver risposto con una CONSUMPTION_REQUEST, e conferma che il cliente ha ancora ciò per cui ha pagato. Trattala come un record, non come un'azione.

REFUND_REVERSED, quella che coglie i team di sorpresa

Questa è la notifica che la maggior parte delle pipeline di rimborso non gestisce mai. La definizione di Apple è inequivocabile: REFUND_REVERSED 'indica che l'App Store ha annullato un rimborso concesso in precedenza a causa di una contestazione sollevata dal cliente. Se la tua app ha revocato contenuti o servizi in seguito al rimborso correlato, deve ripristinarli.' Rileggilo due volte. Apple ha concesso al cliente un rimborso, tu hai revocato l'accesso, poi Apple ha deciso che il rimborso non doveva restare valido e lo ha ritirato. L'addebito è di nuovo attivo. Il cliente ha pagato e, se il tuo server sa solo revocare, resta comunque bloccato. Un rimborso annullato è l'unico evento di rimborso che aggiunge di nuovo l'accesso, ed è quello che quasi nessuno prevede.

Quanto ti costa davvero un rimborso annullato

Un annullamento mancato non è un errore di arrotondamento. Segui il denaro in entrambe le direzioni, perché sbagliare l'una o l'altra metà ha un prezzo.

Se manchi l'annullamento, tieni un cliente pagante bloccato fuori. Apple ha ripristinato l'addebito, quindi il cliente è di nuovo in perdita, e la tua app gli nega la cosa che ha acquistato. Il costo immediato è il tempo di assistenza e un rimborso di cortesia che potresti dover emettere tu stesso, questa volta senza alcuna commissione dello store che torni ad ammorbidirlo. Il costo più lento è la recensione e l'abbandono, e su Google Play quella stessa frustrazione da blocco è esattamente ciò che si trasforma in un chargeback.

Se manchi il rimborso originale, continui a servire un cliente che non ha pagato nulla. L'errore speculare è non revocare mai. Un cliente rimborsato che continua a generare immagini, a chiamare le tue API e a riempire il tuo storage accumula costi reali a fronte di una vendita che è stata annullata. Il calcolo, le chiamate di terze parti e lo storage sono denaro che hai già speso, e nulla di tutto ciò torna indietro con il rimborso.

• Costo di assistenza: una persona che risponde a un ticket per un accesso che il tuo stesso codice ha rimosso e mai ripristinato.
• Rimborsi di cortesia: restituire denaro a un cliente che hai bloccato ingiustamente, senza alcuna commissione dello store restituita su un gesto manuale.
• Spesa sprecata: calcolo, chiamate API e storage consumati da un account rimborsato che non hai mai bloccato.
• Rischio di chargeback: su Google Play, un cliente che si sente addebitato due volte può contestare, e una contestazione persa ora ricade su di te.

Il rimborso annullato e il semplice rimborso sono lo stesso feed di webhook che punta in direzioni opposte. Gestisci l'uno e salti l'altro e paghi da entrambe le parti.

Perché Apple annulla un rimborso, e come leggere revocationReason

Un annullamento non è casuale. Apple lo collega a 'una contestazione sollevata dal cliente', cioè il cliente che mette in discussione la decisione di rimborso a posteriori. Quando il rimborso è stato concesso inizialmente, la transazione portava con sé una revocationDate e un revocationReason, e vale la pena leggere quel motivo prima che qualsiasi processo a valle agisca su di esso.

• revocationReason 1: l'App Store ha rimborsato 'a causa di un problema reale o percepito all'interno della tua app.' È un segnale sul tuo prodotto, non solo su questo cliente.
• revocationReason 0: l'App Store ha rimborsato 'per altri motivi, ad esempio un acquisto accidentale.' Nessun segnale sulla qualità dell'app associato.

Quando arriva un REFUND_REVERSED per quella transazione, la revoca viene annullata. La tua logica di ripristino dovrebbe cercare l'id della transazione originale, confermare che l'avevi revocata e rimettere il diritto esattamente com'era.

Google Play non invia un annullamento, quindi riconcili invece

Il modello di Google Play è diverso, e la differenza conta se gestisci entrambi gli store con un unico gestore di webhook. Non esiste un equivalente Google di REFUND_REVERSED. Le notifiche in tempo reale per sviluppatori di Google dividono gli eventi di rimborso in due messaggi, e gli annullamenti sono gestiti tramite riconciliazione, non con un push.

La notifica di acquisto annullato

Quando un acquisto su Google Play viene annullato, il tuo server riceve una VoidedPurchaseNotification. Indica il purchaseToken e l'orderId, un productType di subscription o one-time, e un refundType che è o un annullamento completo o un rimborso parziale basato sulla quantità per gli acquisti multi-quantità. Google dice che quei dati sono sufficienti per trovare l'acquisto giusto e adeguare il diritto. Per qualsiasi cosa in più, ti indirizza alla Voided Purchases API, un modello pull che elenca gli ordini annullati all'interno di un intervallo di timestamp che interroghi.

La revisione del chargeback e il suo timer di 24 ore

I chargeback arrivano tramite un messaggio diverso, la PendingRefundReviewNotification. Quando un cliente contesta un addebito con la propria banca, Google Play invia questa notifica e avvia un timer. Hai 24 hours per chiamare orders.reviewrefund con una preferenza di rimborso ed eventuali prove di utilizzo, così Google può contestare per tuo conto un chargeback illegittimo. Google registra la tua prima chiamata e ignora il resto. Questo è il parallelo di Google alla CONSUMPTION_REQUEST di Apple, l'unica finestra in cui la tua parte di una contestazione conta.

Poiché non esiste un push di annullamento, un chargeback che Google contesta e vince non arriva come un ordinato evento di ripristino. Lo riconcili con la Voided Purchases API e i tuoi stessi record. La lezione è la stessa dell'App Store: un ordine annullato non è sempre definitivo, e lo stato dei tuoi diritti deve poter tornare indietro, non solo andare avanti.

Come gestire ogni notifica di rimborso senza bloccare nessuno

Non ti servono pipeline separate per store. Ti serve un gestore in grado di spostare un diritto in entrambe le direzioni e che tratti ogni messaggio come potenzialmente duplicato.

• Costruisci il ripristino, non solo la revoca. Per ogni percorso che rimuove l'accesso su un REFUND, scrivi l'inverso che lo ripristina su un REFUND_REVERSED, collegato allo stesso id della transazione.
• Rendilo idempotente. Entrambi gli store possono consegnare la stessa notifica più di una volta, quindi collega ogni revoca e ripristino all'id della transazione o dell'ordine e fai in modo che una ripetizione non produca alcun effetto.
• Leggi il motivo prima di agire. Usa revocationReason per distinguere un rimborso per qualità dell'app da uno accidentale, e indirizza quelli per qualità dell'app a chi possiede la qualità del prodotto.
• Rispondi alle finestre per le prove in tempo. Invia i dati di consumo di Apple entro 12 hours da una CONSUMPTION_REQUEST, e chiama orders.reviewrefund entro 24 hours da una PendingRefundReviewNotification.
• Archivia ogni evento. Conserva REFUND_DECLINED e le notifiche grezze, così un annullamento che arriva più tardi può essere abbinato al rimborso che disfa.

Nulla di tutto ciò cambia se un rimborso avviene. Cambia se il cliente dall'altra parte di un rimborso annullato si accorge mai che il tuo server ha sbagliato.