Er is één endpoint dat de volledige App Store refund history van een klant teruggeeft, en dit is wat het oplevert

Apple houdt voor elk account van een klant bij uw app een opvraagbaar overzicht bij van elke refund die het heeft verleend, en één aanroep geeft dat terug. Het endpoint heet Get Refund History, onderdeel van de App Store Server API, en het levert u de volledige App Store refund history van die klant als een lijst met ondertekende transacties. U geeft een transactie-id door, u krijgt terug wat Apple heeft terugbetaald, en u stemt het af tegen wat u nog aan hebt staan.

Dit is waarom het de moeite waard is. Een refund die u nooit ziet, is een refund waar u voor blijft betalen. Het geld is al weg, maar het account blijft actief, en elk uur dat dit zo is blijft u uitgeven aan rekenkracht, model-API-aanroepen, opslag en elke uitbetaling die aan die klant is gekoppeld. Uw refund-meldingen zijn bedoeld om dit te vangen op het moment dat het gebeurt. Get Refund History is het vangnet voor wanneer ze dat niet doen, na een storing, een deploy die een webhook liet vallen, of een supportzaak waarbij u het hele beeld in één aanroep nodig hebt.

Wat het App Store refund history endpoint teruggeeft

U roept GET /inApps/v2/refund/lookup/{transactionId} aan tegen de App Store Server API, ondertekend met dezelfde JWT die u voor elke andere aanroep gebruikt. De transactie-id in het pad kan elke transactie van de klant zijn. Apple leest het als een identiteit, niet als een filter, en geeft de terugbetaalde aankopen van die klant over uw hele app terug: verbruiksartikelen, niet-verbruiksartikelen, automatisch verlengende en niet-verlengende abonnementen gelijk. De oudere V1 van dit endpoint gaf tot 50 refunds in één antwoord terug en is verouderd. De huidige versie pagineert, zodat u klanten met een lange geschiedenis afhandelt zonder een reusachtige payload.

Het antwoord bestaat uit drie velden

Wat één terugbetaalde transactie u vertelt

Elke vermelding in signedTransactions is een JWS. Verifieer het tegen Apples certificaatketen, decodeer het, en u hebt een gewone transactie-payload met de refund-velden ingevuld. Dit zijn degene die hier tellen.

Het revision-token is hoe u stopt met de hele lijst opnieuw te lezen

De naïeve manier om dit endpoint te gebruiken is een klant opzoeken en elke keer elke pagina doorlopen. Dat werkt, en bij een klant met vijftig refunds zijn dat vijftig regels die u al kende plus die ene nieuwe. Het revision-token bestaat om die verspilling te doden. Elk antwoord draagt een revision. Wanneer hasMore true is, geeft u het terug om de volgende pagina te krijgen. Wanneer u het einde bereikt, bewaart u het laatste revision dat u zag.

Wat dit endpoint niet zal doen

Er is één verwachting die u moet laten varen voordat u erop bouwt. Get Refund History is per klant, niet per app. U kunt er niet elke refund aan vragen die uw app afgelopen week opliep. Het beantwoordt één vraag, namelijk welke refunds dit account heeft, en u moet met een transactie-id voor dat account aankomen om die te stellen. Ontwikkelaars lopen voortdurend tegen deze muur op en gaan op zoek naar een app-breed refund-endpoint dat niet bestaat.

Het app-brede overzicht ligt ergens anders. Uw App Store Server Notifications stroom stuurt een REFUND-melding op het moment dat Apple elke refund verleent, en met Get Notification History kunt u die stroom, gefilterd op refund-typen, over een datumbereik opnieuw afspelen. De verdeling is dus helder. Meldingen en hun geschiedenis geven u de app-brede stroom. Get Refund History geeft u de gezaghebbende lijst van één account, op aanvraag, wat is wat u wilt aan een supportbalie of na een storing.

Wat een gemiste refund u in geld kost

Het endpoint is leidingwerk. De rekening is de reden dat u de pijp legt. Elke refund in die lijst is geld dat al is teruggegeven, en de enige variabele die nog in uw controle ligt is hoe lang u blijft uitgeven aan een account dat niet meer betaalt.

U blijft betalen om een terugbetaald account te bedienen

De aankoopprijs is weg op het moment dat Apple de refund verleent. Wat blijft draaien zijn de kosten van levering. Voor een app die per gebruiker echt werk doet, is dat rekenkracht, model-API-aanroepen, opslag en elke creator- of partneruitbetaling die aan hun gebruik is gekoppeld. Een terugbetaalde klant wiens toegang u nooit hebt afgesneden, is een abonnement dat u uit eigen zak financiert. Afstemmen tegen Get Refund History en intrekken op wat u vindt, is hoe u die meter uitzet wanneer een melding erdoorheen glipte.

Een refund-reden van 1 is een vermomd defectrapport

revocationReason kost u dubbel als u het negeert. De eerste kost is de refund zelf. De tweede is elke toekomstige refund uit dezelfde oorzaak. Wanneer een product steeds terugkomt met revocationReason 1, een werkelijk of ervaren probleem in uw app, reikt Apple u een gelabeld staaltje aan van wat klanten hun geld terug doet vragen. Zet het uit per product en u kunt het lek dichten in plaats van het één refund tegelijk uit te betalen.

Het laat vangen is nog altijd beter dan het niet vangen

Een chargeback is definitief bij de bank en draagt in de andere store inmiddels een vergoeding die de ontwikkelaar slikt. Een App Store refund is dat niet. Hij is afgehandeld, maar de rechten zijn van u om in te trekken op het moment dat u het weet. Zelfs een refund die u dagen te laat via dit endpoint vindt, is dus de moeite waard om te vinden. U kunt het geld niet terughalen, maar u kunt de uitgave stoppen die er nog achter liep.

Hoe dit past bij meldingen, en bij Google

Zie de onderdelen als één systeem. De REFUND-melding is het live signaal, naar uw server geduwd terwijl Apple beslist. Get Refund History is de pull-gebaseerde bron van waarheid voor één klant, de aanroep die u doet wanneer de push mislukte of wanneer een mens het volledige account voor zich nodig heeft. Aan de Google Play kant is de vorm hetzelfde idee met andere namen: een VoidedPurchaseNotification wordt in realtime geduwd, en de Voided Purchases API is de lijst die u trekt. Beide stores geven u een stroom en een grootboek. De fout is alleen de stroom vertrouwen, want stromen vallen weg.

Het aansluiten op de RefundHalt manier

De lus is klein zodra elk onderdeel op zijn plaats staat. Neem een REFUND-melding als de trigger. Stem af tegen Get Refund History zodat een weggevallen webhook nooit een terugbetaald account actief laat. Decodeer elke transactie, koppel het op appAccountToken of transactionId terug aan uw gebruiker, lees revocationReason zodat een defect-refund wordt gemarkeerd en niet alleen weggeborgen, en trek de exacte rechten in in plaats van het hele account. Pagineer met het revision-token zodat u nieuwe refunds leest, niet oude.

Dit is het deel dat RefundHalt voor u draait. Het luistert naar de refund-meldingen, valt terug op Get Refund History wanneer het de gezaghebbende lijst nodig heeft, verifieert elke ondertekende transactie, trekt de precieze aankoop in en bewaart het revision zodat elke doorloop alleen leest wat veranderd is. U krijgt de toegang binnen seconden afgesneden en een schoon overzicht van wie werd terugbetaald, waarvoor en waarom, zonder de polling en de JWS-verificatie zelf op te zetten.