Die Rückerstattungsverarbeitung fällt auf leise Weise aus, also teste In-App-Kauf-Rückerstattungen in der Sandbox, bevor es ein echter Kunde tut

Deine Rückerstattungsverarbeitung ist der eine Code-Pfad, der erst läuft, wenn der Kunde bereits weg ist. Nichts in deiner normalen QA berührt ihn, denn um ihn zu erreichen, musst du tatsächlich erstattet werden. Also geht er ungetestet in Produktion, bleibt monatelang still und scheitert dann an einer echten Rückerstattung, wo der Fehler Geld kostet statt eines roten Tests. Die Lösung ist, eine Rückerstattung nicht länger als etwas zu behandeln, das dir passiert, und stattdessen absichtlich eine auszulösen. Sowohl Apple als auch Google lassen dich eine Rückerstattung in einer Testumgebung auslösen und deinen Server reagieren sehen. So testest du In-App-Kauf-Rückerstattungen im App Store und bei Google Play, bevor ein zahlender Kunde beweist, dass dein Handler kaputt war.

Die drei Umgebungen, in denen eine Rückerstattung auslösen kann, und nur eine ist die Produktion

Es gibt drei getrennte Orte, an denen eine Apple- oder Google-Rückerstattung ausgelöst werden kann, während du entwickelst, und sie sind nicht austauschbar. Zwei davon gehören dir, du kannst sie auf Abruf auslösen. Der dritte ist die Produktion, wo du einem Rückerstattungsfehler nie zum ersten Mal begegnen willst. Die Falle ist die Annahme, dass die einfache, das lokale Testen in Xcode, deine gesamte Pipeline beweist. Sie beweist deine App. Sie sagt nichts über deinen Server.

Das StoreKit-Testing von Xcode ist lokal, also übt es deine App und sonst nichts

Das eingebaute StoreKit-Testing von Xcode läuft gegen eine Konfigurationsdatei auf deinem Mac, ohne Hin und Zurück zu Apple. Öffne den StoreKit Transaction Manager aus der Debug-Leiste, wähle eine gekaufte Transaktion und klicke auf den geschwungenen Rückerstattungspfeil. Die Transaktion wechselt zu erstattet und der Transaction.updates-Listener deiner App löst aus, genau wie es in der Praxis geschähe. Du kannst auch beginRefundRequest aufrufen, um das echte Rückerstattungsblatt anzuzeigen, und in der Xcode-Umgebung entspricht das von dir gewählte Problem eins zu eins einem RevocationReason, wobei die Rückerstattung sofort angewendet wird. Das ist der schnellste Weg zu beweisen, dass dein Client den Zugang in dem Moment kappt, in dem revocationDate nicht mehr null ist. Es ist auch alles, was das lokale Testen dir sagen kann, denn nichts hier erreicht jemals Apples Server, also wird keine App Store Server Notification gesendet. Dein Backend erfährt nichts.

Die Sandbox ist der Ort, an dem dein Server endlich von einer Rückerstattung erfährt

Um die Hälfte deiner Integration zu testen, die über Geld entscheidet, deinen Server, brauchst du Apples Sandbox. Konfiguriere eine Sandbox-URL für App Store Server Notifications V2 in App Store Connect, melde einen Sandbox-Tester auf einem Gerät an und kaufe. Jetzt liefert eine Rückerstattung in der Sandbox eine echte REFUND-Benachrichtigung an dein Backend, und eine Rückerstattungsanfrage bei einem Verbrauchsartikel oder einem automatisch erneuerbaren Abo liefert eine CONSUMPTION_REQUEST, dasselbe signierte Payload, das dein Produktionsserver erhalten wird. Bevor du irgendetwas auslöst, rufe den Endpoint Request a Test Notification auf. Er weist den App-Store-Server an, eine Benachrichtigung vom Typ TEST an die von dir konfigurierte URL zu senden, und übergibt dir einen testNotificationToken, den du an Get Test Notification Status weitergibst, um die Zustellung zu bestätigen. Wenn dieses Hin und Zurück nicht funktioniert, wird auch keine echte Benachrichtigung funktionieren.

Wie du In-App-Kauf-Rückerstattungen im App Store testest

Führe es in dieser Reihenfolge aus, von der günstigen Client-Prüfung bis zum vollständigen Server-Hin-und-Zurück. Jeder Schritt übt ein anderes Teil, und die späteren sind die, die die Produktion dir tatsächlich in Rechnung stellt.

• Erstelle einen In-App-Purchase-Schlüssel unter Users and Access, Integrations, In-App Purchase in App Store Connect und verwende ihn, um deine App-Store-Server-API-Aufrufe zu signieren.
• Richte deine Sandbox-URL für App Store Server Notifications V2 auf dein Backend, rufe dann Request a Test Notification auf und bestätige, dass das TEST-Payload ankommt und sich gegen Apples Zertifikatskette verifiziert.
• Erstatte im Transaction Manager von Xcode einen Kauf und bestätige, dass deine App die Berechtigung in dem Moment entzieht, in dem revocationDate gesetzt wird.
• Melde einen Sandbox-Tester an, kaufe einen Verbrauchsartikel, fordere eine Rückerstattung an und bestätige, dass dein Server die CONSUMPTION_REQUEST empfängt und eine Send-Consumption-Information-Antwort deutlich innerhalb des 12-Stunden-Fensters zusammenstellen und senden kann.
• Erstatte einen Sandbox-Kauf und bestätige, dass die REFUND-Benachrichtigung deinen Server erreicht, dass du den Zugang widerrufst oder den Verbrauchsartikel-Saldo abziehst, und dass eine wiederholte Zustellung derselben Benachrichtigung nicht doppelt angewendet wird.

Wie du eine Rückerstattung und eine Rückbuchung bei Google Play probst

Google Play hat keinen lokalen Modus wie den von Xcode. Alles läuft gegen Googles Server, aber License-Tester halten es kostenlos und sicher. Füge deine Test-Google-Konten als License-Tester in der Play Console hinzu, und sie erhalten eine Reihe von Test-Zahlungsmethoden, die nie echtes Geld abbuchen. Google markiert jeden Testkauf mit einem Hinweis quer über die Mitte des Kaufdialogs, und Steuern werden nicht berechnet. Was für das Testen von Rückerstattungen zählt, ist, welches Testinstrument du wählst, denn jedes führt zu einem anderen Ergebnis.

Löse eine Rückerstattung, eine Rückbuchung und die Auto-Rückerstattung bei fehlender Bestätigung aus

• Kaufe mit der approve-then-charge-back-Testkarte, und eine PendingRefundReviewNotification landet Momente später auf deinem Real-time-Developer-Notifications-Topic. Beantworte sie mit einem einzigen orders.reviewrefund-Aufruf, denn Google behält nur deine erste Antwort.
• Erstatte und widerrufe eine Testbestellung im Tab Orders in der Play Console, um eine VoidedPurchaseNotification auszulösen, und bestätige, dass dein Server die Berechtigung entzieht.
• Lass den Kauf eines License-Testers absichtlich unbestätigt. Google erstattet ihn nach 3 Minuten automatisch statt nach den 3 Tagen, die die Produktion erlaubt, und schickt dir die Stornierung per E-Mail, also zeigt sich ein kaputter Bestätigungspfad in Minuten, nicht am vierten Tag in der Produktion.

Was ein ungetesteter Rückerstattungspfad wirklich kostet

Ein Rückerstattungs-Handler ist keine Dekoration. Er ist der Code, der dich davon abhält, dafür zu zahlen, jemanden zu bedienen, der dich nicht mehr bezahlt. Wenn er still fehlschlägt, geht die Rückerstattung trotzdem durch, aber der Zugang, der Saldo und die Ausgaben dahinter hören nicht auf.

Folge dem Geld. Wenn Apple oder Google einen Kauf erstattet, gibst du den Verkaufspreis zurück und der Store gibt seine Provision zurück, so weit ist die Bilanz ausgeglichen. Was nicht zurückkommt, ist alles, was du bereits für die Lieferung des Produkts ausgegeben hast: die Rechenleistung hinter einem generierten Ergebnis, die Modell-API-Aufrufe, der Speicher für das, was der Nutzer gespeichert hat, die Auszahlung, die du einem Creator bereits gesendet hast. Ein Rückerstattungs-Handler, der den Zugang nie widerruft, lässt einen erstatteten Nutzer weiter auf deine Kosten ausgeben, ohne dass etwas im System übrig ist, um ihn abzuschneiden.

Die zwei Beweisfenster machen es schärfer. Eine CONSUMPTION_REQUEST, die du nie in der Sandbox geübt hast, ist eine Antwort, die du fehlerhaft oder zu spät sendest, und Apple gewährt die Rückerstattung oft standardmäßig, wenn deine Antwort nicht innerhalb von 12 Stunden ankommt. Eine Google-Play-Rückbuchungsantwort, die du nie mit der Testkarte ausgelöst hast, ist ein 24-Stunden-Fenster, das du live verpatzt, und ab dem 3. August 2026 kostet dich eine verlorene Play-Rückbuchung den Kaufpreis abzüglich der Servicegebühr von Play plus die Rückbuchungsgebühr der Bank. Jeder dieser Fehlschläge ist zuerst gratis in einer Testumgebung reproduzierbar. Keiner davon ist in der Produktion günstig.

Eine kurze Checkliste, bevor du die Rückerstattungsverarbeitung auslieferst

Du brauchst kein Labor. Du musst jedes Ereignis einmal deinen Code treffen gesehen haben.

• Deine App entzieht den Zugang in dem Moment, in dem eine StoreKit-Transaktion ein revocationDate zeigt, bestätigt im Transaction Manager von Xcode.
• Die URL deines Sandbox-Servers empfängt eine TEST-Benachrichtigung und verifiziert sie gegen Apples Zertifikate.
• Eine Sandbox-REFUND widerruft den Zugang oder zieht den Saldo ab, und eine wiederholte Zustellung zählt nicht doppelt.
• Eine Sandbox-CONSUMPTION_REQUEST erzeugt eine gültige Send-Consumption-Information-Antwort deutlich innerhalb von 12 Stunden.
• Eine Google-PendingRefundReviewNotification von der Rückbuchungs-Testkarte erzeugt genau einen orders.reviewrefund-Aufruf.
• Ein nicht bestätigter Google-Play-Testkauf wird in 3 Minuten automatisch erstattet und deine Abstimmung bemerkt es.

Führe diese Liste einmal aus, und die Rückerstattungsverarbeitung hört auf, der Code zu sein, von dem du hoffst, dass er funktioniert. Sie wird zum Code, den du hast funktionieren sehen.