Je app kan een in-app formulier voor terugbetalingsverzoeken tonen, en dit doet Apple nadat een klant op verzenden tikt

Apple laat een klant een terugbetaling aanvragen zonder ooit je app te verlaten. Eén StoreKit aanroep, beginRefundRequest, toont Apples eigen terugbetalingsformulier direct in je interface, de klant kiest een reden, en het verzoek gaat ter beoordeling naar Apple. Je bouwt het formulier niet, je raakt het geld niet aan, en je beslist niet over de uitkomst. Wat je krijgt is een manier om een terugbetalingspad te plaatsen waar een gefrustreerde klant al is, in plaats van hem aan zijn bank te verliezen. Dit is het in-app terugbetalingsverzoek, en het is de moeite waard om het te begrijpen voordat je beslist of je de knop uitbrengt.

Hier komt het deel dat telt voor je omzet. De knop betaalt uit zichzelf niets terug. Hij opent een verzoek, Apple neemt tot 48 uur om het goed te keuren of te weigeren, en bij verbruiksaankopen vuurt Apple eerst een CONSUMPTION_REQUEST af op je server. Het formulier is dus geen weggevertje. Het is een trechter naar precies die terugbetalingsbeoordeling die je al kunt beïnvloeden, en het kan een geschil terughalen bij het kaartnetwerk voordat het een terugboeking wordt die je niet kunt betwisten.

Wat het in-app formulier voor terugbetalingsverzoeken werkelijk is

beginRefundRequest is een StoreKit 2 methode die het formulier voor terugbetalingsverzoeken voor een transactie in een window scene toont. De signatuur is klein: func beginRefundRequest(in scene: UIWindowScene) async throws -> Transaction.RefundRequestStatus. Wanneer je hem aanroept, toont het systeem een formulier met de aankoopgegevens van de klant en een lijst met redencodes om uit te kiezen. Apple bouwt en beheert die UI. Jij levert de scene en de transactie, verder niets.

Apples advies over waar je hem plaatst is expliciet. Roep deze functie aan vanuit de accountinstellingen of een helpmenu, zodat een klant die een terugbetaling wil hem vindt waar hij naar ondersteuning zou zoeken. Hij verscheen in iOS 15 en iPadOS 15, Mac Catalyst 15 en visionOS 1, dus elke app die op die versies richt kan hem vandaag tonen.

Twee manieren om het formulier te openen

Er zijn twee ingangen. Je kunt beginRefundRequest(in:) aanroepen op een specifieke transactie die je al hebt, wat het formulier beperkt tot die ene aankoop. Je kunt het formulier ook openen op productidentificatie wanneer je wilt dat de klant een aankoop van een bepaald product laat terugbetalen. Hoe dan ook horen het formulier, de redenlijst en de beslissing bij Apple. Jouw taak eindigt bij het tonen ervan en het uitlezen van het resultaat.

Wat de aanroep teruggeeft, en wat er mis kan gaan

De methode is async throws, dus hij geeft ofwel een status terug ofwel werpt hij een fout. Beide zijn korte lijsten, en beide zijn de moeite waard om af te handelen zodat je UI iets waars zegt nadat het formulier sluit.

Wat er op je server gebeurt nadat de klant op verzenden tikt

Het sluiten van het formulier is het begin van het proces, niet het einde. Apple beoordeelt het verzoek en neemt tot 48 uur om het goed te keuren of te weigeren. Bij een verbruiksgebonden in-app aankoop stuurt de App Store, voordat die beslist, een CONSUMPTION_REQUEST melding naar je server met de vraag om gebruiksgegevens. Als de klant toestemming gaf om die gegevens te delen, antwoord je via het Send Consumption Information endpoint. Gaf hij geen toestemming, dan luidt Apples eigen instructie om helemaal niet op de melding te reageren.

Zodra Apple beslist, landt de uitkomst op je server als een App Store Server Notification. Dat is dezelfde feed die je al ontvangt, en het in-app verzoek loopt er precies zo in als een terugbetaling die een klant op Apples reportaproblem pagina start. Er verandert niets aan de afhandeling alleen omdat het verzoek in je app begon.

Wat de knop je kost, en wat hij kan besparen

Een terugbetaling die je kunt betwisten is beter dan een terugboeking die je niet kunt betwisten

Een klant die binnen je app geen terugbetalingspad vindt, geeft niet op. Hij gaat naar zijn bank. Een kaartterugboeking is bij de bank definitief, brengt geschilkosten met zich mee, en haalt de beslissing zowel uit jouw handen als die van Apple. Een in-app terugbetalingsverzoek houdt diezelfde klant binnen Apples systeem, waar een verbruiksaankoop een CONSUMPTION_REQUEST triggert die je kunt beantwoorden en een beslissing die je kunt beïnvloeden. Een onbetwistbare terugboeking ruilen voor een betwistbare Apple-beoordeling is het hele financiële argument voor de knop.

Je verlaagt de drempel voor een terugbetaling

Het eerlijke tegenwicht is dat een zichtbaar terugbetalingspad met één tik meer terugbetalingsverzoeken oplevert dan een verstopte support-e-mail. Sommige daarvan waren nooit gebeurd. Dat is een echte kostenpost, en daarom zegt Apple je om de ingang in de accountinstellingen of een helpmenu te plaatsen in plaats van op het aankoopscherm. Je wilt dat de klant die al ontevreden is hem vindt, niet de klant die slechts nieuwsgierig is.

De kostenpost die de hele tijd doorloopt is het bedienen van een terugbetaald account

Hoe de beslissing ook uitvalt, de meter op levering blijft lopen totdat je op de uitkomst reageert. Elk uur dat een terugbetaald recht actief blijft, betaal je de echte kosten erachter door: rekenkracht, model-API-aanroepen, opslag, en elke uitbetaling aan makers of partners die aan het gebruik van die klant is gekoppeld. Het in-app verzoek verandert dat niet. Prompt intrekken bij de REFUND melding wel. De knop is alleen zo goedkoop als jouw afhandeling van de melding die hij uiteindelijk oplevert.

Moet je het in-app terugbetalingsverzoek uitbrengen

Zet hem waar de ondersteuning woont, niet waar de verkoop woont

Volg Apples plaatsingsadvies. De accountinstellingen en een helpmenu zijn de juiste plekken. Een terugbetalingslink naast een paywall leert mensen hun geld terug te verwachten, en nodigt uit tot de nieuwsgierigheidsterugbetaling die je nooit had hoeven aanbieden.

Test de volledige flow in de sandbox voordat je erop vertrouwt

Je kunt het hele pad simuleren in de sandbox en in Xcodes StoreKit testing, door een verzoek van in behandeling naar goedgekeurd of geweigerd te bewegen. Een goedkeuring levert een REFUND melding aan je server, en een weigering levert REFUND_DECLINED, zodat je kunt aantonen dat je handler correct reageert voordat een echte klant ooit op verzenden tikt.

Handel elk resultaat af, en beweer nooit te veel

Toon in behandeling bij success, bied een nieuwe poging bij failed, zeg dat er niets veranderde bij userCancelled, en behandel duplicateRequest als een stille notitie dat het eerdere verzoek van de klant nog steeds staat. De ene fout die pijn doet is een klant vertellen dat zijn terugbetaling rond is terwijl je alleen een ingediend verzoek in handen hebt.

Hoe RefundHalt de nasleep afhandelt

Het in-app formulier is van Apple. Wat erna komt is van jou, en dat is het deel dat RefundHalt runt. Wanneer een klant een terugbetaling vanuit je app verzendt, vangt RefundHalt de CONSUMPTION_REQUEST voor verbruiksaankopen op en beantwoordt die binnen het 12-uursvenster met het gebruiksbewijs dat Apple helpt beslissen. Wanneer Apple beslist, trekt het in bij REFUND en laat het toegang onaangeroerd bij REFUND_DECLINED, elk gekoppeld aan de exacte transactie. Jij kunt het vriendelijkere in-app terugbetalingspad aanbieden zonder de beoordeling, het bewijs of de intrekking aan een handmatig geploeter over te laten.