Zwölf Stunden – mehr Zeit gibt Ihnen Apple nicht, um eine Rückerstattung mit Belegen zu rechtfertigen. Diese Uhr ist wertlos, wenn die Transaktion vor Ihnen einem Kunden gehört, den Sie nicht benennen können. appAccountToken ist die UUID, die den Namen liefert, und sie kann nur während des Kaufvorgangs angehängt werden.
Stellen Sie sich vor, die Benachrichtigung trifft ein. Apple möchte wissen, wie viel von dem Produkt dieser Käufer tatsächlich verbraucht hat, wie lange er schon Kunde ist, was er insgesamt ausgegeben hat. Berechtigte Fragen, und Ihre Datenbank hält jede Antwort bereit. Das Problem: Der Payload vor Ihnen bietet eine originalTransactionId und eine Produktkennung, und keine von beiden entspricht irgendetwas in Ihrer Nutzertabelle. Sie halten eine Rechnung ohne Namen in der Hand, und die Antworten, die Sie brauchen, sind unter Namen abgelegt.
Für diese Diskrepanz gibt es eine Lösung, und die Lösung hat eine Frist. appAccountToken ist eine UUID, die Ihr System generiert, beim Checkout an StoreKit übergibt, und die Apple anschließend auf die daraus entstehende Transaktion stempelt. Von diesem Moment an kommt alles, was Apple Ihnen über diesen Kauf mitteilt, bereits identifiziert an. Verpassen Sie diesen Moment jedoch, bleibt der betreffende Verkauf dauerhaft anonym. Im Folgenden: was das Feld ist, wie man es anhängt, der Endpunkt, der nachträglich Käufe rettet, die Ihre App nie gesehen hat, und die Rechnung, was eine anonyme Rückerstattung Ihrem Unternehmen tatsächlich entzieht.
Die wichtigsten Punkte
Hängen Sie einem App-Store-Kauf eine UUID an, zeigt die daraus entstehende Transaktion direkt auf einen bestimmten Nutzer in Ihren Unterlagen. Apple behält diesen Wert auf der Transaktion und gibt ihn überall zurück, wo die Transaktion wieder auftaucht.
Das Format ist das Einzige, was Apple überprüft, und das Format ist UUID. Füttern Sie es mit einer Datenbank-ID, einer E-Mail-Adresse oder einem zusammengeklebten String, verwirft StoreKit den Wert kommentarlos und liefert Ihnen nil, wo appAccountToken stehen sollte.
StoreKit 2 stellt es als eine einzige Kaufoption bereit, Product.PurchaseOption.appAccountToken(_:), gespeist von einer UUID, die Ihr System zuvor generiert und dem jeweiligen Konto zugeordnet hat.
Hängen Sie es dem ersten Kauf an, gibt Apple denselben Wert an jede Verlängerung, jeden erneuten Abrechnungsversuch und jedes Upgrade entlang der Abo-Kette weiter.
Ab 2025 gibt der Set-App-Account-Token-Endpunkt Ihrem Server eine Möglichkeit, Käufe zu kennzeichnen, die der In-App-Ablauf nie gesehen hat – darunter eingelöste Angebotscodes und beworbene Käufe.
Apples CONSUMPTION_REQUEST lässt sich nur dank dieses Tokens überhaupt beantworten. Fehlt es, können Sie die Rückerstattung nicht mit genau dem Kunden verknüpfen, dessen Verbrauch Sie innerhalb des 12-Stunden-Fensters darlegen sollen.
Eine nicht identifizierbare Rückerstattung lässt sich nicht verteidigen. Geld fließt zurück für Verkäufe, für die Sie Beweise hatten, und die Rechenleistung, API-Aufrufe und Auszahlungen, die bereits für deren Bereitstellung verbraucht wurden, gehen mit verloren.
Was dieses Feld wirklich leistet
Apple behandelt den Wert als bedeutungslos, und genau das ist der Punkt. Welche UUID Sie StoreKit auch beim Checkout übergeben, sie wird auf die Transaktion geschrieben und unbegrenzt aufbewahrt, ohne dass versucht wird, sie zu interpretieren, zu prüfen, worauf sie sich bezieht, oder zu überprüfen, ob sie überhaupt irgendetwas auflöst. Apples eigene Definition nennt sie „die UUID, die die Transaktion mit dem Konto des Nutzers in Ihrem eigenen Dienst verknüpft". Die Interpretation liegt vollständig in Ihrer Verantwortung. Apple trägt den Wert lediglich mit sich herum und gibt ihn auf Anfrage zurück.
Wo er zurückgegeben wird, macht das Feld nützlich. Server-Benachrichtigungen tragen ihn innerhalb der signierten Transaktion. Fragen Sie die App Store Server API nach Get Transaction Info, erscheint er dort. Jede nachfolgende Verlängerung in einer Abo-Kette gibt ihn weiter, vorausgesetzt der ursprüngliche Kauf trug ihn bereits. Hängen Sie den Wert also einmal an, und er taucht immer wieder auf, solange dieser Kunde Ihnen zahlt.
Übergeben Sie alles außer einer UUID, verschwindet sie ohne Vorwarnung
Entwickler entdecken diese Regel meist, indem sie dagegen verstoßen. Es wird etwas übergeben, das vernünftig erschien – eine interne Konto-ID, eine E-Mail-Adresse, ein paar zusammengefügte Felder –, und StoreKit erhebt überhaupt keinen Einwand. Keine Exception, keine Warnung, kein fehlgeschlagener Kauf. Die Transaktion kommt einfach mit appAccountToken auf nil zurück, und die Verknüpfung, von der Sie ausgingen, wurde nie hergestellt. Apples Entwicklerforen sind voll von genau dieser Verwirrung, meist formuliert als „appAccountToken is missing in the transaction payload", und die Erklärung ist fast immer ein Wert, der die Formatanforderung nicht erfüllt hat.
Diese Anforderung ist eng gefasst: StoreKit 2 akzeptiert ausschließlich eine RFC-4122-UUID. Das sichere Vorgehen besteht also darin, die UUID auf Ihrem Server zu erzeugen, sie dem Konto dauerhaft zuzuordnen und sicherzustellen, dass niemals ein anderer Wertetyp zum Kaufaufruf gelangen kann.
Gefährlich macht das die Stille. Ein fehlerhaft formatierter Wert kostet Sie keine Fehlermeldung und keinen gescheiterten Kauf, sondern nur die Verknüpfung selbst – sie wird still verworfen, während alles andere normal weiterläuft. Den Wert vor Erreichen von StoreKit gegen das UUID-Format zu prüfen, kostet eine einzige Zeile Code und beseitigt diesen gesamten Fehlerfall.
Das Token beim Checkout anhängen
Eine einzige Kaufoption ist die gesamte Implementierung. Erzeugen Sie die UUID serverseitig bei der Registrierung oder sobald ein Kunde erstmals zum Checkout gelangt, schreiben Sie sie in dessen Kontodatensatz und übergeben Sie anschließend bei jedem Kauf genau denselben Wert.
Die Signatur der Option lautet Product.PurchaseOption.appAccountToken(_ token: UUID), und der Aufruf selbst sieht so aus: try await product.purchase(options: [.appAccountToken(token)]). Auf welchem Weg auch immer die fertige Transaktion bei Ihnen eintrifft – ob Sie sie selbst gegen die App Store Server API verifizieren oder sie als Server-Benachrichtigung erhalten –, diese UUID reist mit, was die Kundenidentifikation auf einen einzigen indizierten Lookup reduziert.
Ein Token pro Kunde, für immer wiederverwendet
Ein verlockender Fehler ist es, pro Transaktion ein neues Token zu erzeugen. Dadurch wird der Nutzen still und leise zunichtegemacht. Apple gibt das Token, das beim ursprünglichen Kauf vorlag, über Verlängerungen, erneute Abrechnungsversuche und Upgrades innerhalb dieser Kette weiter – das heißt, eine dauerhafte UUID pro Konto hält die gesamte Zahlungshistorie eines Kunden verbunden. Rotieren Sie den Wert, wird jeder Kauf zu einer Insel. Stabilität ist hier die entscheidende Eigenschaft: Legen Sie bei der Kontoerstellung eine UUID fest und ändern Sie sie nie wieder.
Der Endpunkt, der Käufe rettet, mit denen Ihre App nie in Berührung kam
Zwei Kaufwege haben das früher vollständig ausgehebelt. Das Einlösen eines Angebotscodes geschieht im App Store, nicht in Ihrer App. Ebenso der Kauf eines beworbenen In-App-Kaufs aus einem Store-Listing. Keiner der beiden Wege führt Ihren Kaufcode aus, was bedeutete, dass es keinen Moment gab, in dem ein Token übergeben werden konnte, und diese Transaktionen blieben dauerhaft anonym.
Diese Einschränkung endete auf der WWDC 2025 mit dem Set-App-Account-Token-Endpunkt. Ihr Server sendet ein PUT /inApps/v1/transactions/{originalTransactionId}/appAccountToken an die App Store Server API, mit der UUID im Body, und Apple schreibt sie auf die Transaktion. Die Abdeckung erstreckt sich auf jeden Produkttyp, eingelöste Angebotscodes und beworbene Käufe ausdrücklich eingeschlossen, und ein auf diesem Weg gesendeter Wert ersetzt jedes Token, das die Transaktion bereits trug. Identifikation ist damit zu etwas geworden, das Sie nachträglich durchführen können, vollständig serverseitig, bei Käufen, mit denen Ihre App nie zu tun hatte.
Wo Sie das Token anhängen, hängt davon ab, wie der Kauf zustande kam:
Bei einem gewöhnlichen In-App-Kauf setzen Sie es in der StoreKit-Kaufoption im Moment des Kaufs, über Product.PurchaseOption.appAccountToken(UUID).
Bei einer Angebotscode-Einlösung setzen Sie es über den Set-App-Account-Token-Endpunkt von Ihrem Server aus, denn es gibt nichts In-App, woran Sie andocken könnten, und Sie müssen es nachträglich anhängen.
Bei einem beworbenen In-App-Kauf aus dem App Store setzen Sie es auf dieselbe Weise über den Set-App-Account-Token-Endpunkt, da die Transaktion außerhalb Ihrer App stattfindet.
Bei einer Abo-Verlängerung tun Sie nichts. Das Token wird automatisch vom ursprünglichen Kauf übernommen.
Was eine gebrochene Verknüpfung Ihrem Umsatz antut
Ordentliche Buchführung ist hier nicht das Argument. Das Argument ist, dass Apple Entwicklern bei einer Rückerstattung genau eine Frage stellt, übermittelt als CONSUMPTION_REQUEST, und um sie zu beantworten, müssen Sie wissen, von welchem Ihrer Kunden die Rede ist.
Anfragen für Rückerstattungen bei Verbrauchsgütern und nicht automatisch verlängernden Abos lösen diese Benachrichtigung aus, und Send Consumption Information ist Ihre Antwort darauf, innerhalb von zwölf Stunden. Apple erwartet konkrete Angaben zu einer Einzelperson: den Anteil des verbrauchten Produkts, die Dauer der Kundenbeziehung, die Gesamtausgaben, den Lieferstatus. Das Token erscheint als Feld innerhalb der Anfrage selbst, aber seine wichtigere Rolle ist strukturell, weil es das einzige ist, das diese Benachrichtigung in eine Zeile Ihrer eigenen Datenbank verwandeln kann. Entfernen Sie das Token, wird die Anfrage unbeantwortbar, egal wie gründlich Ihr Nutzungstracking ist.
Der Preis dafür, mit nichts zu antworten
Sobald eine Rückerstattung unidentifiziert eintrifft, bleiben zwei Optionen, und keine davon ist gut. Reichen Sie eine leere Consumption-Antwort ein, liest Apple das als minimale Nutzung, was die Entscheidung in Richtung Genehmigung verschiebt – auch bei Vielnutzern. Erfinden Sie stattdessen eine Schätzung, melden Sie einem Plattformbetreiber Fiktion. Welchen Weg Sie auch wählen, Verkäufe, die Sie hätten belegen können, werden trotzdem erstattet, nachdem Sie bereits für deren Erfüllung bezahlt haben.
Die Erfüllungskosten sind der Teil, der wirklich schmerzt, weil sie in keinem Verhältnis zum Verkaufspreis stehen. Verbrauchte Modell-API-Aufrufe während einer Generierung, erzeugte Bilder, ein gerendertes und exportiertes Video, eine weiter unten in der Kette ausgezahlte Creator-Vergütung: all dieses Geld hat Ihre Konten bei der Lieferung bereits verlassen, und die Rückerstattung an den Kunden holt es nicht zurück. Skalieren Sie das Problem jetzt. Ein anonymer Kunde beantragt wiederholt Rückerstattungen. Gewohnheitsmäßige Rückerstatter zielen gezielt auf Unternehmen, die sie nicht identifizieren können. Das ausgelassene Token ist an diesem Punkt keine kleine Unterlassung mehr, sondern funktioniert wie ein offener Hahn.
Apples Frage betrifft den tatsächlichen Verbrauch eines Kunden, und um sie zu beantworten, müssen Sie wissen, wer dieser Kunde ist. Ohne das Token verzichten Sie auf Verkäufe, die Sie hätten belegen können, zusammen mit den Rechen- und API-Kosten, die bereits für deren Bereitstellung aufgewendet wurden.
Android fährt dasselbe Spiel unter anderem Namen
setObfuscatedAccountId erledigt diese Aufgabe bei Google Play, indem es eine Kontokennung an einen Kauf bindet, sodass die Chargeback-Prüfung über orders.reviewrefund eine tatsächliche Person zu untersuchen hat. Die Implementierungen unterscheiden sich erheblich, aber die zugrundeliegende Disziplin überträgt sich unverändert: Die Identität wird während der Transaktion gebunden, oder der Streitfall geht später standardmäßig verloren. Apples Version dieser Disziplin heißt appAccountToken, und sie besteht auf einer UUID.
Drei Praktiken, die jeden Kauf identifiziert halten
Erzeugen Sie eine UUID pro Konto und speichern Sie sie dauerhaft. Ein einziges beständiges Token pro Kunde, erzeugt bei der Anmeldung oder beim ersten Checkout, in dessen Datensatz geschrieben und bei allem, was er kauft, wiederverwendet.
Prüfen Sie den Wert, bevor Sie ihn übergeben. Verifizieren Sie in Ihrem Kaufcode, dass es sich wirklich um eine UUID handelt, sodass eine fehlerhafte Kennung niemals still und leise zu einem nil-Token auf der Transaktion wird.
Tragen Sie nachträglich alles nach, was außerhalb der App gekauft wurde. Trifft eine Server-Benachrichtigung für eine Angebotscode-Einlösung oder einen beworbenen Kauf ohne Token ein, greifen Sie zum Set-App-Account-Token-Endpunkt und hängen Sie das richtige Token an.
Setzen Sie alle drei um, hört Identifikation auf, etwas zu sein, das Sie nachträglich versuchen. Sie wird zu einer Eigenschaft, die jede Transaktion bereits besitzt, wenn Apple sie Ihnen übergibt, Rückerstattungsanfragen ausdrücklich eingeschlossen.
Refund Sensor baut direkt auf dieser Annahme auf. Wir extrahieren appAccountToken aus jeder Transaktion und Server-Benachrichtigung, verknüpfen es mit den bereits für dieses Konto erfassten Nutzungsdaten und reichen eine Antwort auf Apples Anfrage deutlich innerhalb des Zwölf-Stunden-Fensters ein, mit Zahlen, die diesen Käufer wirklich beschreiben. Eine Rückerstattung, die Sie benennen können, ist eine Rückerstattung, über die Sie streiten können – und das ist die einzige Art, über die es sich überhaupt zu streiten lohnt.
Wo diese Regeln dokumentiert sind
Häufig gestellte Fragen
Eine UUID, die Ihrem System gehört und die StoreKit lediglich festhält. Sie übergeben sie beim Checkout, Apple schreibt sie auf die daraus entstehende Transaktion, und von da an taucht sie überall dort wieder auf, wo auch der Kauf auftaucht: in dessen Transaction-Info, in jeder diesbezüglichen Server-Benachrichtigung und in jeder weiteren Verlängerung derselben Kette. Der praktische Effekt: Alles, was Apple Ihnen später mitteilt, eine Rückerstattungsanfrage eingeschlossen, lässt sich auf die richtige Zeile in Ihrer eigenen Datenbank zurückführen.
Fast sicher das Format. RFC 4122 ist der Standard, den StoreKit 2 akzeptiert, und ein Wert, der diesen Test nicht besteht, wird ohne Fehlermeldung verworfen, sodass nil zurückbleibt, während der Kauf so abgeschlossen wird, als wäre nichts schiefgegangen. Interne Datensatz-IDs, E-Mail-Adressen und zusammengeklebte Strings scheitern alle auf diese Weise. Die andere Möglichkeit: Ihre App hat den Kauf überhaupt nie verarbeitet – meist liegt das an einer Angebotscode-Einlösung –, sodass niemals Code von Ihnen lief, um ein Token zu übergeben.
Seit 2025, ja. Apple hat Set App Account Token genau für diese Situation in die App Store Server API aufgenommen. Ein PUT an /inApps/v1/transactions/{originalTransactionId}/appAccountToken, mit der UUID im Body, schreibt ein Token auf eine bereits bestehende Transaktion oder ersetzt eines, das dort bereits vorhanden ist. Jeder Produkttyp kommt infrage, und die Funktion wurde speziell für Käufe entwickelt, mit denen Ihre App nie zu tun hatte – insbesondere Angebotscodes und beworbene Käufe.
Ja, ohne Ausnahme. Worauf die UUID auf Ihrer Seite verweist, bleibt ganz allein Ihre Angelegenheit und Apple prüft das nie, aber der Wert selbst muss dem UUID-Format entsprechen. Erfüllt er das nicht, weigert sich StoreKit, ihn zu behalten, und lässt nil auf der Transaktion zurück.
Rückerstattungen lösen eine CONSUMPTION_REQUEST aus, und Apple erwartet innerhalb von zwölf Stunden eine Antwort, die beschreibt, wie genau dieser Käufer das Produkt genutzt hat. Eine solche Antwort zu erstellen bedeutet, die Transaktion aus der Benachrichtigung in einen tatsächlich abfragbaren Kundendatensatz zu verwandeln – genau das ist die Funktion des Tokens. Es reist zudem als Feld innerhalb der Anfrage mit. Ohne es ist Ihre Antwort entweder leer oder erfunden, und eine leere Antwort führt in der Regel dazu, dass die Rückerstattung genehmigt wird.
