Tre notifiche di rimborso dell'App Store arrivano dopo la decisione di Apple, e REFUND_REVERSED ti restituisce la vendita

Apple decide il tuo rimborso, e poi continua a parlare. Una volta stabilito l'esito, l'App Store invia al tuo server una di tre notifiche di rimborso dell'App Store, e ciascuna chiede una mossa diversa. Un REFUND dice che il denaro è andato e che dovresti togliere l'accesso. Un REFUND_DECLINED dice che il cliente ha perso la richiesta e che mantieni la vendita. Un REFUND_REVERSED dice che Apple ha annullato un rimborso già concesso, quindi la vendita è di nuovo tua e devi restituire ciò che avevi tolto. La maggior parte delle app collega la prima e ignora in silenzio le altre due. È così che un cliente pagante finisce escluso da qualcosa per cui ha pagato.

Queste tre sono distinte da CONSUMPTION_REQUEST, l'unico messaggio di rimborso che ti chiede una risposta. Le notifiche successive alla decisione non vogliono una discussione. Vogliono un HTTP 200 e il giusto cambiamento all'accesso del cliente. Ecco cosa significa ciascuna, i campi esatti che portano i fatti, e dove il denaro si perde quando le gestisci male.

Le quattro notifiche di rimborso, e quale attende una risposta

App Store Server Notifications V2 è un unico flusso. Lo punti a un solo URL e Apple gli invia ogni tipo di notifica, quindi ricevi già tutti e quattro i messaggi di rimborso, che tu li gestisca o no. Quattro dei tipi riguardano i rimborsi, e solo uno è una domanda.

Cosa ti dice davvero una notifica REFUND

REFUND scatta quando l'App Store ha rimborsato con successo una transazione a un cliente. Si applica a ogni tipo di acquisto: un consumabile, un non consumabile, un abbonamento a rinnovo automatico e un abbonamento senza rinnovo. La transazione firmata dentro la notifica ora porta due campi che non aveva prima del rimborso, e quei due campi sono tutta la storia.

revocationDate e revocationReason portano i fatti

revocationDate è l'ora UNIX, in millisecondi, in cui l'App Store ha rimborsato la transazione o l'ha revocata. revocationReason ti indica la categoria del rimborso, e assume esattamente due valori.

La presenza di un revocationDate su una transazione è di per sé il segnale. Se recuperi una transazione più tardi e ha un revocationDate, quell'acquisto è stato rimborsato, con o senza notifica. Leggi il motivo accanto perché un'ondata di rimborsi di valore 1 su una singola release non ti sfugga come rumore.

Revoca per transazione, non per prodotto

La trappola qui è revocare troppo. Un REFUND nomina una transazione. Non ti dice di disattivare ogni acquisto che il cliente abbia mai fatto di quell'id di prodotto. L'indicazione di Apple stessa è verificare quale accesso il cliente detiene ancora prima di tagliare qualcosa, perché i diritti si sovrappongono. Il caso classico è un abbonamento: un rimborso ricade sul rinnovo del mese scorso mentre il rinnovo di questo mese è attivo e interamente pagato. Revoca sul prodotto e hai appena tagliato fuori un cliente attuale e pagante per un rimborso di un periodo già finito.

REFUND_DECLINED significa che hai già vinto, quindi non disfarlo

REFUND_DECLINED arriva quando l'App Store ha respinto la richiesta di rimborso del cliente. Il cliente ha chiesto, Apple ha detto no, e tu mantieni la vendita. A prima vista non c'è nulla da fare, ed è proprio questo il punto. L'errore che questa notifica mette in luce è un altro: revocare l'accesso troppo presto.

Se il tuo codice reagisce al CONSUMPTION_REQUEST togliendo l'accesso del cliente prima che Apple abbia deciso, un REFUND_DECLINED è il momento in cui quella decisione salta. Apple ha tenuto i tuoi soldi, e tu hai escluso un cliente il cui rimborso è stato negato. Quel cliente ora paga per un prodotto che non può usare, apre un ticket di assistenza, e se lo ricorda. La soluzione è una regola, non una funzione: revoca su REFUND, mai sulla richiesta. REFUND_DECLINED è semplicemente Apple che conferma che una revoca anticipata sarebbe stata la scelta sbagliata.

REFUND_REVERSED è la notifica che ti restituisce il denaro

REFUND_REVERSED è quella che quasi nessuno gestisce, ed è quella che ti restituisce denaro. Apple la invia quando annulla un rimborso concesso in precedenza, di solito dopo che il cliente contesta quel rimborso. I campi di revoca che un REFUND aveva aggiunto alla transazione vengono di nuovo rimossi, quindi l'acquisto risulta di nuovo pagato. Apple riassume il compito dello sviluppatore in una riga: se la tua app ha revocato contenuti o servizi a causa del rimborso correlato, deve ripristinarli. Si applica a qualsiasi tipo di acquisto, da un consumabile a un abbonamento a rinnovo automatico.

Il problema delle settimane dopo

La vera domanda che gli sviluppatori pongono, sui forum di Apple stessa, è la tempistica. Un REFUND_REVERSED può arrivare settimane dopo il REFUND originale, molto dopo che un periodo di abbonamento è scaduto. Ripristini l'accesso allora? Ripristina ciò che la transazione concede davvero, limitato a ciò che quella transazione copre. Per un consumabile o un non consumabile, riattiva lo sblocco. Per un periodo di abbonamento già trascorso, non stai distribuendo tempo nuovo, stai correggendo il registro perché la cronologia del cliente sia accurata e qualsiasi diritto ancora valido torni attivo. Ripristina la transazione specifica, e la tua logica di sovrapposizione decide cosa è attivo in quel momento.

Dove sta il denaro nel fare bene questa cosa

Ognuna di queste notifiche corrisponde a un numero reale, e il costo di gestirla male non è solo il prezzo della vendita.

REFUND: smetti di pagare per servire un cliente rimborsato

Il prezzo della vendita è andato nel momento in cui arriva REFUND. Ciò che puoi ancora controllare è il costo di continuare a erogare. Ogni ora in cui un diritto rimborsato resta attivo, continui a spendere per ciò che il cliente non paga più: calcolo, chiamate all'API del modello, archiviazione e qualsiasi pagamento a creator o partner legato al suo utilizzo. Revocare prontamente su REFUND ferma quel contatore. Ignorare la notifica significa che finanzi un prodotto per qualcuno che il negozio ha già risarcito.

REFUND_DECLINED: non trasformare una vittoria in un rimborso di buona volontà

Quando revochi in anticipo e il rimborso viene poi respinto, hai mantenuto la vendita sulla carta e l'hai persa nella pratica. Il cliente che ha pagato non può usare il prodotto, quindi erediti una conversazione di assistenza e, spesso, un rimborso a titolo di cortesia per sistemare le cose. Questo è pagare due volte per una vendita che non è mai stata in pericolo. Gestire REFUND_DECLINED correttamente non costa nulla, ed è esattamente per questo che lasciare l'accesso intatto fino a REFUND è la regola più economica che puoi adottare.

REFUND_REVERSED: la combinazione peggiore è che il cliente resti senza i suoi soldi e senza il suo accesso allo stesso tempo

Ignora REFUND_REVERSED e raggiungi il risultato peggiore possibile. Sei stato pagato, e il cliente non ha nulla. Ha già contattato la banca una volta per annullare il rimborso, e una persona esclusa da un prodotto per cui ora le viene addebitato è una persona propensa a contattare la banca una seconda volta. Quella successiva contestazione può diventare un chargeback della carta, definitivo da parte della banca e più costoso di quanto la vendita sia mai stata. Ripristinare l'accesso appena arriva REFUND_REVERSED è l'assicurazione più economica di tutto il flusso di rimborso.

Cosa mettere in piedi

La gestione è piccola una volta che il modello è corretto. Indicizza i diritti sull'id di transazione così che ogni notifica punti a un acquisto. Su CONSUMPTION_REQUEST, invia i tuoi dati entro 12 ore. Su REFUND, revoca quella transazione. Su REFUND_DECLINED, non fare nulla. Su REFUND_REVERSED, ripristina. Restituisci HTTP 200 velocemente su tutte e fai il cambiamento di accesso con i tuoi tempi.

Per il vuoto che le notifiche lasciano, usa l'endpoint Get Refund History. Se il tuo server era inattivo durante un'interruzione e ha perso un REFUND, chiama la ricerca dei rimborsi dell'App Store Server API per un id di transazione, in /inApps/v2/refund/lookup/{transactionId}, e rileggi le transazioni firmate con i loro revocationDate e revocationReason. Riconcilia una transazione alla volta e sfoglia gli acquisti rimborsati di un cliente, così un webhook perso non diventa un diritto impostato male in modo permanente.

Questa è la parte che RefundHalt esegue per te. Ascolta tutti e quattro i tipi, revoca su REFUND, mantiene l'accesso intatto su REFUND_DECLINED, e ripristina automaticamente su REFUND_REVERSED, ciascuno indicizzato alla transazione esatta. Un rimborso annullato non resta in coda mentre un cliente pagante rimane escluso, e uno respinto non innesca mai una revoca che dovresti annullare.