Prüfen Sie App Store Server Notifications, bevor Sie auf eine Erstattung reagieren, denn jeder kann an Ihre Webhook-URL senden

Wer Ihre Webhook-URL kennt, kann ihr eine Erstattung schicken. Das ist die unbequeme Wahrheit hinter jeder App Store Server Notification und jeder Google Play Real-time developer notification: Solange Sie sie nicht prüfen, ist die Nachricht nur ein HTTPS-POST mit etwas JSON darin. Wenn Ihr Server ein Abonnement kündigt, Guthaben zurückholt oder ein Konto sperrt, weil in einer Anfrage REFUND stand, haben Sie diese Macht jedem übertragen, der einen curl-Befehl schreiben kann.

Beide Stores bieten Ihnen eine Möglichkeit zur Prüfung. Apple signiert die Benachrichtigung selbst, sodass Sie App Store Server Notifications allein mit Apples Root-Zertifikat verifizieren können. Google Play geht einen anderen Weg. Die Nachricht ist nicht signiert, die Zustellung über Pub/Sub kann es aber sein, und Google fordert Sie ohnehin auf, jede Änderung über seine API zu bestätigen. Hier sehen Sie, was jeder Weg beweist und was es kostet, wenn Sie in die eine oder andere Richtung falsch liegen.

Was jeder Store tatsächlich signiert

So verifizieren Sie App Store Server Notifications

Laut Apples Dokumentation ist der signedPayload eine Zeichenfolge aus drei Base64URL-codierten Bestandteilen, die durch Punkte getrennt sind: Header, Payload und Signatur, signiert nach der Spezifikation JSON Web Signature. Den Payload zu decodieren ist einfach. Ihm zu vertrauen erfordert vier Prüfungen.

• Lesen Sie das x5c-Array aus dem decodierten Header. Apple dokumentiert die Reihenfolge: zuerst das Zertifikat mit dem Signaturschlüssel, dann ein Apple-Zwischenzertifikat, dann ein Apple-Root-Zertifikat.
• Validieren Sie diese Kette gegen ein Apple-Root-Zertifikat, das Sie selbst von Apples PKI-Website heruntergeladen haben, in der Praxis Apple Root CA - G3. Vertrauen Sie niemals dem Root-Zertifikat, das in der Nachricht mitgeliefert wurde, denn ein Fälscher kann dort jedes beliebige Zertifikat einsetzen.
• Stellen Sie sicher, dass das Zwischenzertifikat die Apple Worldwide Developer Relations-Erweiterung 1.2.840.113635.100.6.2.1 trägt, und prüfen Sie dann die JWS-Signatur mit dem öffentlichen Schlüssel des Leaf-Zertifikats.
• Gleichen Sie die decodierten Daten mit Ihrer App ab: bundleId, appAppleId in der Produktion und environment. Eine gültige Apple-Signatur auf der App eines anderen Entwicklers oder auf einem Sandbox-Kauf, der Ihren Produktionsendpunkt erreicht, ist trotzdem nicht Ihre Erstattung.

Wiederholen Sie das dann für den Inhalt. Das data-Objekt enthält signedTransactionInfo und signedRenewalInfo, und beide sind jeweils ein eigenes JWS mit eigener x5c-Kette. Ein REFUND-Handler, der den Umschlag prüft, die Transaktion aber ungeprüft ausliest, hat in der Mitte eine Lücke gelassen.

Nutzen Sie Apples Bibliothek, statt alles selbst zu schreiben

Apple veröffentlicht die App Store Server Library für Swift, Java, Python und Node. Ihr SignedDataVerifier erhält Ihre Root-Zertifikate, ein Flag für Online-Prüfungen, die environment, Ihre Bundle-ID und für die Produktion Ihre appAppleId. Der Node-Quellcode zeigt, was er durchsetzt: genau drei Zertifikate in der Kette, die Apple-Leaf-Erweiterung 1.2.840.113635.100.6.11.1 und die Erweiterung des Zwischenzertifikats, die Gültigkeitsdaten der Zertifikate sowie übereinstimmende Bundle-ID, App-ID und environment. Mit aktivierten Online-Prüfungen fragt er außerdem den OCSP-Responder, ob das Leaf- und das Zwischenzertifikat widerrufen wurden.

Reicht eine IP-Allowlist aus?

Nein. Apple empfiehlt, das Subnetz 17.0.0.0/8 aufzunehmen, wenn Ihr Server eine Allowlist benötigt, und das gilt für Sandbox und Produktion. Das reduziert Störsignale. Es beweist aber nicht, dass eine Nachricht echt ist, und es versagt, sobald sich Apples Netz auf eine Weise ändert, von der Sie nichts erfahren haben. Behalten Sie die Signaturprüfung als eigentliche Schranke bei.

So verifizieren Sie Erstattungsbenachrichtigungen von Google Play

Google Play veröffentlicht RTDN-Nachrichten in einem Pub/Sub-Thema, das Ihnen gehört, und nur das Dienstkonto google-play-developer-notifications@system.gserviceaccount.com sollte darauf die Rolle Pub/Sub Publisher innehaben. Ihr Abonnement stellt die Nachrichten dann auf einem von zwei Wegen zu, und jeder hat seinen eigenen Nachweis.

• Pull-Abonnement: Ihr Server baut eine authentifizierte Verbindung zu Pub/Sub auf und ruft die Nachrichten ab. Es gibt keinen öffentlichen Endpunkt, also nichts, an das ein Fremder senden könnte.
• Push-Abonnement mit aktivierter Authentifizierung: Pub/Sub signiert ein JSON Web Token und sendet es im Authorization-Header als Bearer-Token. Googles Leitfaden verlangt, die Signatur des Tokens zu validieren und zu prüfen, ob seine E-Mail- und Audience-Claims den von Ihnen konfigurierten Werten entsprechen. Der Beispielcode verlangt zudem, dass email_verified true ist. Das Token kann bis zu einer Stunde alt sein.
• Push-Abonnement ohne Authentifizierung: Alles, was die URL erreichen kann, kann eine Nachricht senden, die wie eine RTDN aussieht.

Warum Google eine Bestätigung über die API verlangt

Selbst eine einwandfrei authentifizierte RTDN enthält nicht die ganze Geschichte. Googles Einrichtungsleitfaden stellt klar, dass diese Benachrichtigungen Ihnen nur mitteilen, dass sich der Status eines Kaufs geändert hat, und dass Sie die Google Play Developer API aufrufen müssen, um den vollständigen Status zu erhalten. Bei einer voidedPurchaseNotification heißt das, den Kauf in der Voided Purchases API zu finden oder seinen aktuellen Status abzurufen, bevor Sie irgendetwas entziehen. Der API-Aufruf wird mit Ihrem eigenen Dienstkonto authentifiziert, daher kann ein Fälscher dessen Antwort nicht nachahmen.

Was eine gefälschte oder abgelehnte Erstattung in Geld kostet

Eine gefälschte Erstattungsbenachrichtigung, der Sie vertrauen, kostet Sie einen zahlenden Kunden. Sie sperren jemanden aus, dessen Geld Sie noch haben, er eröffnet ein Support-Ticket, und manche wenden sich an den Store und verlangen die Erstattung, die Ihr System bereits vorgetäuscht hat. Ein gefälschter Kauf oder eine gefälschte Verlängerung kostet in umgekehrter Richtung: Sie liefern GPU-Rechenleistung, kostenpflichtige API-Aufrufe bei Drittanbietern, Speicher und Auszahlungen an Creator gegen Umsätze, die es nie gab.

Der umgekehrte Fehler ist leiser und oft größer. Ein Verifier, der echte Nachrichten ablehnt, etwa wegen einer falschen appAppleId, einer Sandbox-Einstellung in der Produktion oder eines veralteten Root-Zertifikats, verwirft genau die beiden Erstattungsabläufe, in denen Ihre Nachweise zählen. Apple fordert Verbrauchsdaten innerhalb von 12 Stunden nach einem CONSUMPTION_REQUEST an. Google gibt Ihnen 24 Stunden, um eine Chargeback-Prüfung über orders.reviewrefund zu beantworten, und für Bestellungen nach dem 3. August 2026 kostet Sie ein verlorener Google Play-Chargeback den Kaufpreis abzüglich der Servicegebühr von Play, zuzüglich der Gebühr, die die Bank des Käufers erhebt.

Lassen Sie keinen Verifizierungsfehler eine Frist kosten

• Speichern Sie die Rohanfrage, bevor Sie sie prüfen, damit eine abgelehnte Nachricht nie endgültig verloren ist.
• Lösen Sie bei jedem Verifizierungsfehler eine Warnung aus. Eine gefälschte Nachricht ist Rauschen. Wenn alle Nachrichten gleichzeitig scheitern, liegt der Fehler bei Ihnen.
• Bei Apple können Sie Abgelehntes erneut abspielen. Get Notification History liefert den ursprünglichen signedPayload für die letzten 180 Tage. Korrigieren Sie also den Verifier und lassen Sie die gespeicherten oder wiederhergestellten Payloads erneut durchlaufen.
• Bei Google existiert eine offene Chargeback-Prüfung nur in ihrer Benachrichtigung, daher bedeutet eine falsch konfigurierte Push-Audience eine verpasste Prüfung. Testen Sie sie nach jeder Änderung mit Send Test Message in der Play Console.

RefundHalt verifiziert die Benachrichtigungen beider Stores, bestätigt Erstattungen über die Store-APIs, bevor sich etwas ändert, und beantwortet CONSUMPTION_REQUEST und Chargeback-Prüfungen innerhalb ihrer Fristen. So kann Sie eine gefälschte Nachricht keinen Kunden kosten, und eine echte kann nicht durchrutschen.