Deine App kann ein In-App-Formular für Rückerstattungsanträge anzeigen, und das passiert bei Apple, nachdem ein Kunde auf Absenden tippt

Apple lässt einen Kunden eine Rückerstattung anfordern, ohne jemals deine App zu verlassen. Ein einziger StoreKit Aufruf, beginRefundRequest, zeigt Apples eigenes Rückerstattungsformular direkt in deiner Oberfläche an, der Kunde wählt einen Grund, und der Antrag geht zur Prüfung an Apple. Du baust das Formular nicht, du fasst das Geld nicht an, und du entscheidest nicht über das Ergebnis. Was du bekommst, ist ein Weg, einen Rückerstattungspfad genau dort zu platzieren, wo ein frustrierter Kunde schon ist, statt ihn an seine Bank zu verlieren. Das ist der In-App-Rückerstattungsantrag, und es lohnt sich, ihn zu verstehen, bevor du entscheidest, ob du den Button auslieferst.

Hier kommt der Teil, der für deinen Umsatz zählt. Der Button erstattet von sich aus nichts. Er eröffnet einen Antrag, Apple braucht bis zu 48 Stunden für die Genehmigung oder Ablehnung, und bei Verbrauchskäufen feuert Apple zuerst eine CONSUMPTION_REQUEST an deinen Server ab. Das Formular ist also kein Geschenk. Es ist ein Trichter in genau die Rückerstattungsprüfung, die du bereits beeinflussen kannst, und es kann einen Streitfall vom Kartennetzwerk zurückholen, bevor er zu einer Rückbuchung wird, die du nicht anfechten kannst.

Was das In-App-Formular für Rückerstattungsanträge wirklich ist

beginRefundRequest ist eine StoreKit 2 Methode, die das Formular für Rückerstattungsanträge für eine Transaktion in einer Window-Scene anzeigt. Die Signatur ist kurz: func beginRefundRequest(in scene: UIWindowScene) async throws -> Transaction.RefundRequestStatus. Wenn du sie aufrufst, zeigt das System ein Formular mit den Kaufdetails des Kunden und einer Liste von Grundcodes zur Auswahl an. Apple baut und steuert diese UI. Du lieferst die Scene und die Transaktion, sonst nichts.

Apples Empfehlung zur Platzierung ist eindeutig. Rufe diese Funktion aus den Kontoeinstellungen oder einem Hilfemenü auf, damit ein Kunde, der eine Rückerstattung möchte, sie dort findet, wo er nach Support suchen würde. Sie kam mit iOS 15 und iPadOS 15, Mac Catalyst 15 und visionOS 1, sodass jede App, die auf diese Versionen abzielt, sie heute schon anzeigen kann.

Zwei Wege, das Formular zu öffnen

Es gibt zwei Einstiegspunkte. Du kannst beginRefundRequest(in:) für eine bestimmte Transaktion aufrufen, die du bereits hältst, was das Formular auf diesen einen Kauf beschränkt. Du kannst das Formular auch über eine Produktkennung öffnen, wenn der Kunde einen Kauf eines bestimmten Produkts erstatten lassen soll. So oder so gehören das Formular, die Gründeliste und die Entscheidung Apple. Deine Aufgabe endet damit, es anzuzeigen und das Ergebnis auszulesen.

Was der Aufruf zurückgibt und was schiefgehen kann

Die Methode ist async throws, sie gibt also entweder einen Status zurück oder wirft einen Fehler. Beides sind kurze Listen, und beides lohnt sich zu behandeln, damit deine UI etwas Wahres sagt, nachdem das Formular geschlossen wird.

Was auf deinem Server passiert, nachdem der Kunde auf Absenden tippt

Das Schließen des Formulars ist der Beginn des Prozesses, nicht das Ende. Apple prüft den Antrag und braucht bis zu 48 Stunden für die Genehmigung oder Ablehnung. Bei einem verbrauchbaren In-App-Kauf sendet der App Store, bevor er entscheidet, eine CONSUMPTION_REQUEST Benachrichtigung an deinen Server und fragt nach Nutzungsdaten. Wenn der Kunde der Weitergabe dieser Daten zugestimmt hat, antwortest du über den Send Consumption Information Endpunkt. Hat er nicht zugestimmt, lautet Apples eigene Anweisung, auf die Benachrichtigung überhaupt nicht zu antworten.

Sobald Apple entscheidet, landet das Ergebnis auf deinem Server als App Store Server Notification. Das ist derselbe Feed, den du bereits erhältst, und der In-App-Antrag läuft genauso hinein wie eine Rückerstattung, die ein Kunde auf Apples reportaproblem Seite startet. An der Verarbeitung ändert sich nichts, nur weil der Antrag in deiner App begann.

Was der Button dich kostet und was er sparen kann

Eine Rückerstattung, die du anfechten kannst, ist besser als eine Rückbuchung, die du nicht anfechten kannst

Ein Kunde, der in deiner App keinen Rückerstattungspfad findet, gibt nicht auf. Er geht zu seiner Bank. Eine Karten-Rückbuchung ist bei der Bank endgültig, sie bringt eine Streitgebühr mit sich, und sie nimmt die Entscheidung sowohl dir als auch Apple aus der Hand. Ein In-App-Rückerstattungsantrag hält denselben Kunden in Apples System, wo ein Verbrauchskauf eine CONSUMPTION_REQUEST auslöst, die du beantworten kannst, und eine Entscheidung, die du beeinflussen kannst. Eine unanfechtbare Rückbuchung gegen eine anfechtbare Apple-Prüfung zu tauschen, ist das gesamte finanzielle Argument für den Button.

Du senkst die Hürde für eine Rückerstattung

Das ehrliche Gegengewicht ist, dass ein sichtbarer Rückerstattungspfad mit einem Tipp mehr Anträge erzeugt als eine versteckte Support-E-Mail. Manche davon wären nie passiert. Das ist ein echter Preis, und deshalb rät Apple dir, den Einstiegspunkt in den Kontoeinstellungen oder einem Hilfemenü zu platzieren statt auf dem Kaufbildschirm. Du willst, dass der Kunde ihn findet, der bereits unzufrieden ist, nicht der, der nur neugierig ist.

Der Kostenposten, der die ganze Zeit läuft, ist die Versorgung eines erstatteten Kontos

Egal wie die Entscheidung ausfällt, der Zähler für die Bereitstellung läuft weiter, bis du auf das Ergebnis reagierst. Für jede Stunde, in der eine erstattete Berechtigung aktiv bleibt, zahlst du weiter die echten Kosten dahinter: Rechenleistung, Modell-API-Aufrufe, Speicher und jede Auszahlung an Creator oder Partner, die an die Nutzung dieses Kunden gebunden ist. Der In-App-Antrag ändert das nicht. Ein prompter Widerruf bei der REFUND Benachrichtigung schon. Der Button ist nur so günstig wie deine Verarbeitung der Benachrichtigung, die er letztlich erzeugt.

Solltest du den In-App-Rückerstattungsantrag ausliefern

Platziere ihn dort, wo der Support wohnt, nicht wo der Verkauf wohnt

Folge Apples Empfehlung zur Platzierung. Die Kontoeinstellungen und ein Hilfemenü sind die richtigen Orte. Ein Rückerstattungslink neben einer Paywall bringt Leuten bei, ihr Geld zurückzuerwarten, und lädt zur Neugier-Rückerstattung ein, die du nie hättest anbieten müssen.

Teste den gesamten Ablauf in der Sandbox, bevor du ihm traust

Du kannst den gesamten Pfad in der Sandbox und in Xcodes StoreKit Testing simulieren und einen Antrag von ausstehend auf genehmigt oder abgelehnt bewegen. Eine Genehmigung liefert eine REFUND Benachrichtigung an deinen Server, und eine Ablehnung liefert REFUND_DECLINED, sodass du beweisen kannst, dass dein Handler richtig reagiert, bevor je ein echter Kunde auf Absenden tippt.

Behandle jedes Ergebnis und behaupte nie zu viel

Zeige bei success ausstehend an, biete bei failed einen erneuten Versuch an, sage bei userCancelled, dass sich nichts geändert hat, und behandle duplicateRequest als leisen Hinweis, dass der frühere Antrag des Kunden weiterhin gilt. Der eine Fehler, der wehtut, ist einem Kunden zu sagen, seine Rückerstattung sei erledigt, obwohl du nur einen eingereichten Antrag in der Hand hältst.

Wie RefundHalt die Nachbearbeitung übernimmt

Das In-App-Formular gehört Apple. Was danach kommt, gehört dir, und das ist der Teil, den RefundHalt übernimmt. Wenn ein Kunde eine Rückerstattung aus deiner App heraus absendet, fängt RefundHalt die CONSUMPTION_REQUEST für Verbrauchskäufe ab und beantwortet sie innerhalb des 12-Stunden-Fensters mit den Nutzungsnachweisen, die Apple bei der Entscheidung helfen. Sobald Apple entscheidet, widerruft es bei REFUND und lässt den Zugang bei REFUND_DECLINED unangetastet, jeweils an die genaue Transaktion gebunden. Du kannst den freundlicheren In-App-Rückerstattungspfad anbieten, ohne die Prüfung, die Nachweise oder den Widerruf einem manuellen Durcheinander zu überlassen.