Elk Apple-restitutieverzoek komt nu met een reden, en consumptionRequestReason is hoe je die leest

Apple heeft veranderd hoe restitutieverzoeken op je server binnenkomen, en veel ontwikkelaars hebben het nooit gemerkt. Sinds de update App Store Server Notifications 2.11, aangekondigd op WWDC24, draagt elke CONSUMPTION_REQUEST-melding een veld genaamd consumptionRequestReason. Het is de door de klant zelf opgegeven reden om zijn geld terug te vragen. Eén eenvoudige tekenreeks, vijf mogelijke waarden, geleverd binnen dezelfde payload die je toch al twaalf uur hebt om te beantwoorden.

De Apple-restitutiereden beslist op zichzelf niets. Wat hij wel doet, is je vertellen in welke van vijf zeer verschillende situaties je zit, zodat je stopt met dezelfde generieke verbruiksgegevens te sturen naar een restitutie die je zou moeten toekennen en een restitutie die je zou moeten aanvechten. Hier staat wat het veld is, de exacte waarden die Apple kan sturen, wat elke waarde signaleert en hoe hij de voorkeur en het bewijs zou moeten veranderen die je terugstuurt.

Wat consumptionRequestReason eigenlijk is

consumptionRequestReason is een tekenreeksveld in het data-object van een CONSUMPTION_REQUEST-melding. Apple heeft het toegevoegd in App Store Server Notifications versie 2.11, naast de WWDC24-wijzigingen aan de restitutiestroom. Daarvoor kwam het verzoek binnen met de ondertekende transactie en niets over het motief. Je antwoordde blind. Nu reist de door de klant opgegeven reden mee met het verzoek.

Lees het woord opgegeven aandachtig. Dit is de reden die de klant selecteerde toen hij het bij Apple indiende, geen feit dat Apple heeft geverifieerd. UNINTENDED_PURCHASE bewijst niet dat de aankoop ongebruikt bleef, en UNSATISFIED_WITH_PURCHASE bewijst niet dat het product kapot was. De waarde is een lens, geen vonnis. Je combineert hem nog steeds met je eigen leverings- en gebruiksregistraties.

Hij reist mee in de melding die je toch al verwerkt

CONSUMPTION_REQUEST is de enige Apple-stroom die de ontwikkelaar überhaupt om bewijs vraagt. De tegenhanger bij Google Play is de terugboekingsbeoordeling via orders.reviewrefund. Wanneer er een binnenkomt, heb je 12 uur om te antwoorden door Send Consumption Information aan te roepen, een PUT naar het verbruiks-endpoint van de transactie. consumptionRequestReason maakt nu deel uit van diezelfde melding, dus er is niets nieuws om je op te abonneren. Als je CONSUMPTION_REQUEST al parseert, is de reden één veld dat je waarschijnlijk negeerde.

De vijf redenen, en wat elke je vertelt

Apple documenteert precies vijf waarden. Er komt er één per verzoek binnen. Hier is de volledige set en hoe je elke in de praktijk leest.

UNINTENDED_PURCHASE is de bak voor onbedoelde tikken

Dit is de reden die een ouder selecteert nadat een kind 10,000 munten heeft gekocht, of een volwassene die een bevestiging misklikte. Hij correleert met aankopen die nooit werden geopend of gebruikt. Precies daarom tellen je eigen gegevens. Als je registraties tonen dat het verbruiksartikel volledig is geleverd en zwaar is verbruikt, komen een claim van onbedoelde aankoop en een volledig opgebruikt saldo niet overeen, en die kloof is het waard om via consumptionPercentage te melden.

FULFILLMENT_ISSUE wijst terug naar jou

FULFILLMENT_ISSUE is de enige reden die deels over je app gaat, niet over de klant. Hij betekent dat de klant zegt dat hij niet kon ontvangen of gebruiken waarvoor hij betaalde. Voordat je reflexmatig aanvecht, haal je je leveringslogs erbij. Als je eigen server toont dat het recht nooit is geactiveerd, of de tegoeden nooit zijn geboekt, heeft de klant gelijk, en is DECLINE de verkeerde voorkeur. Een echte leveringsfout bevechten verspilt het venster en kan de klant naar zijn bank drijven, waar een terugboeking meer kost dan de restitutie had gekost.

UNSATISFIED_WITH_PURCHASE is waar bewijs beslist

Dit is gewone kopersspijt, en het is de reden waarbij je verbruiksgegevens het meeste werk doen. Het product werkte. De klant gebruikte een deel of alles ervan en wil nu zijn geld terug. Een hoge consumptionPercentage, een eerlijke deliveryStatus van DELIVERED en een refundPreference van DECLINE of GRANT_PRORATED zijn de zaak die Apple je vraagt te bouwen. Stuur de cijfers, geen argument.

LEGAL en OTHER

LEGAL betekent dat de klant een juridisch of regelgevend recht heeft ingeroepen. Redelijke mensen verschillen van mening, maar in de regel is dit niet het venster om te procederen. Ken het toe en ga verder. OTHER is de restcategorie die Apple gebruikt wanneer de opgegeven reden op geen van de vier hierboven aansluit. Hij draagt op zichzelf geen signaal, dus behandel een OTHER precies zoals je een verzoek zonder enige reden zou behandelen: begin met je leveringsstatus en gebruiksbewijs.

Hoe de reden je antwoord verandert, veld voor veld

Je antwoordt op een CONSUMPTION_REQUEST door Send Consumption Information aan te roepen met een ConsumptionRequest-body. De reden zou drie velden in die body moeten vormen.

customerConsented moet true zijn

Apple accepteert de indiening alleen wanneer customerConsented true is, wat betekent dat de klant heeft ingestemd om verbruiksgegevens te delen. Als je die toestemming niet hebt, kun je helemaal geen gegevens sturen, ongeacht de reden. Geen toestemming, geen bewijs, en het verzoek wordt beslist zonder je cijfers.

deliveryStatus en consumptionPercentage dragen de feiten

deliveryStatus zegt of je een werkende aankoop hebt geleverd. Is het iets anders dan DELIVERED, dan vereist Apple dat consumptionPercentage 0 is. Wanneer je wél hebt geleverd, is consumptionPercentage een geheel getal in milliunits van 0 tot 100,000, waarbij 100,000 betekent dat de klant de hele aankoop heeft gebruikt. Dit paar is je feitelijke kern, en het is wat een FULFILLMENT_ISSUE- of een UNSATISFIED_WITH_PURCHASE-zaak zou moeten dragen, niet de reden zelf.

refundPreference is je enige hefboom

refundPreference is waar je aangeeft wat je wilt. Apple documenteert drie waarden: GRANT_FULL, GRANT_PRORATED en DECLINE. Lees de reden, weeg hem tegen je gegevens, en kies dan. FULFILLMENT_ISSUE met een mislukte levering in je logs neigt naar GRANT_FULL. UNSATISFIED_WITH_PURCHASE bij een volledig verbruikt product neigt naar DECLINE of GRANT_PRORATED. LEGAL neigt naar GRANT_FULL.

Wat een restitutie je werkelijk kost

Het redenveld doet ertoe omdat een restitutie zelden alleen de verkoop is die van je grootboek verdwijnt. Voor een verbruiksartikel dat al is gebruikt, heb je betaald om het te vervullen. Een tegoedpakket dat een betaalde inferentie-API aanriep, een reeks gegenereerde afbeeldingen die GPU-tijd verbrandde, een opgeslagen export die op je opslagrekening staat, een uitbetaling aan een maker die je al hebt gestuurd: die kosten blijven besteed wanneer de aankoop wordt teruggedraaid. De store geeft de klant zijn geld terug. Hij geeft je je rekenkracht niet terug.

Daarom is de reden het lezen waard. Stel dat een klant 5,000 tegoeden kocht die elk een betaalde API-aanroep activeren, er 4,000 van gebruikte en toen indiende onder UNSATISFIED_WITH_PURCHASE. Je deliveryStatus is DELIVERED, je consumptionPercentage is 80,000 milliunits, en een DECLINE- of GRANT_PRORATED-voorkeur is het verschil tussen het slikken van de API-rekening en het grootste deel ervan terugwinnen. Draai nu de reden om naar FULFILLMENT_ISSUE met logs die tonen dat de tegoeden nooit zijn geboekt, en de eerlijke, goedkopere zet is GRANT_FULL voordat de klant escaleert naar zijn bank.

De reden lezen zonder overdreven te reageren

De valkuil is de reden als bewijs behandelen. UNINTENDED_PURCHASE is geen bekentenis dat het product ongebruikt bleef, en LEGAL is niet altijd een echte juridische claim. De reden versmalt de situatie. Je leveringslogs en verbruiksregistraties lossen hem op. Wanneer ze het met de klant eens zijn, ken vroeg en goedkoop toe. Wanneer ze de klant tegenspreken, is die tegenspraak, uitgedrukt als deliveryStatus en consumptionPercentage, het sterkste wat je kunt sturen. RefundHalt leest consumptionRequestReason bij elke CONSUMPTION_REQUEST en combineert die automatisch met je echte gebruiksgegevens, zodat elke reden binnen het venster van 12 uur het antwoord krijgt dat hij verdient.

De verandering is klein en makkelijk te missen, maar ze verschoof het restitutiegesprek in jouw voordeel. Apple vertelt je nu waarom, voordat je antwoordt. Gebruik het.