Warum Vibe-codierte Zahlungs-Apps im App Store abgelehnt werden
KI kann eine Checkout-App an einem Nachmittag schreiben, aber Apple lehnt Zahlungs-Apps ab – aufgrund des Einreichers, der Zahlungsleitung und Berechtigungen, die kein Prompt generieren kann. Hier scheitern Vibe-codierte Apps im Review.
Vibe-codierte Zahlungs-Apps werden im App Store häufiger abgelehnt als fast alles andere in der Review-Warteschlange, und die Gründe haben meist nichts mit der Codequalität zu tun. Eine Vibe-codierte App – also eine App, die Sie erstellt haben, indem Sie einem KI-Assistenten beschrieben haben, was Sie wollen, und das Ergebnis veröffentlicht haben – kann optisch nicht von professioneller Arbeit zu unterscheiden sein. Apples Review bewertet nicht den Code. Es prüft, wer die App eingereicht hat, welcher Zahlungsmechanismus für welche Art von Waren zuständig ist, ob Hardware-Berechtigungen separat genehmigt wurden und ob der Prüfer eine echte Transaktion abschließen kann. Das sind genau die Dinge, die ein KI-Assistent nicht generieren kann.
Das ist die Wand, gegen die jeder stößt, nachdem er ein benutzerdefiniertes POS mit einem KI-Modell gebaut hat: Der Code steht an einem Nachmittag, aber ihn als echte Checkout-App auf ein iPhone zu bekommen, ist ein Compliance-Prozess, keine Programmieraufgabe.
Hat Ihre KI Zahlungen über das falsche System geleitet?
Die häufigste Ablehnung erfolgt aufgrund der Verwendung des falschen Zahlungsmechanismus für die verkauften Waren, und KI-Assistenten sind ungewöhnlich gut darin, dies falsch zu machen. Apples App-Store-Prüfrichtlinien ziehen hier eine klare Grenze. Digitale Inhalte und Dienste, die innerhalb der App konsumiert werden, müssen gemäß Richtlinie 3.1.1 Apples In-App-Käufe nutzen. Physische Güter und Dienstleistungen in der realen Welt – ein Kaffee, ein Haarschnitt, eine versandte Bestellung – müssen gemäß Richtlinie 3.1.5(a) genau das Gegenteil tun: Sie dürfen In-App-Käufe überhaupt nicht nutzen und erfordern eine externe Zahlungsmethode.
Ein Coding-Modell reproduziert das Zahlungsmuster, das in seinen Trainingsdaten dominierte – sei es In-App-Kauf-Boilerplate aus Abonnement-Tutorials oder ein Web-Checkout-SDK aus E-Commerce-Beispielen –, ohne jemals zu fragen, was Sie eigentlich verkaufen. Prompten Sie es für „eine App, die Zahlungen entgegennimmt“, und Sie erhalten eine der beiden Optionen, ausgewählt nach statistischer Wahrscheinlichkeit statt nach Apples Regeln. Die Regeln ändern sich zudem je nach Storefront: Nach dem Epic-Urteil von 2025 dürfen Apps im US-Store auf externe Kaufoptionen für digitale Güter verlinken, aber diese Ausnahme gilt nur in den USA. Eine weltweit vertriebene App muss überall sonst weiterhin die strengeren Regeln erfüllen.
Dürfen Sie überhaupt eine Zahlungs-App einreichen?
Apple erwartet, dass Apps, die Geldverwaltung oder Finanzdienstleistungen anbieten, von der Institution eingereicht werden, die diese Dienste tatsächlich erbringt, und zwar mit den erforderlichen Lizenzen in jeder Region, in der die App verfügbar ist – das ist Richtlinie 3.2.1. Ein Einzelentwickler, der eine KI-generierte Zahlungs-App veröffentlicht, ist kein lizenziertes Finanzinstitut, und eine Agentur, die eine solche App für einen Kunden einreicht, ebenfalls nicht. Die App in einem Land anzubieten, in dem keine Lizenz für den Geldtransfer vorliegt, führt zur gleichen Ablehnung, nur mit einem anderen Poststempel.
Apples Prüfer bewerten nicht, wie gut Ihr Compliance-Programm ist; sie prüfen, ob das richtige Unternehmen die App eingereicht hat, und lehnen sie ab, wenn dies nicht der Fall ist. Kein Prompt der Welt ändert das.
Warum ist Tap to Pay ein eigener Genehmigungsprozess?
Das Akzeptieren von kontaktlosen Karten auf einem iPhone erfordert die Berechtigung „Tap to Pay on iPhone“ – ein separater Antrag bei Apple, unabhängig vom App-Review, der einer juristischen Person und nicht einer Codebasis gewährt wird. Die Entwicklungsberechtigung wird meist in ein bis zwei Tagen erteilt. Die Veröffentlichungsberechtigung läuft über das Operations-Team von Apple, dauert in der Regel ein bis zwei Wochen und erfordert die Zusammenarbeit mit einem unterstützten Zahlungsdienstleister. Ein KI-Assistent schreibt den Tap-to-Pay-Code gerne, ohne dies zu erwähnen; reichen Sie die App ein, bevor die Berechtigung erteilt wurde, und sie wird abgelehnt.
Die Kartenakzeptanz bringt zudem Anforderungen mit sich, die nicht bei Apple liegen: zertifizierte Terminal-Hardware, EMV-Regeln und PCI-Vorgaben für alles, was mit Kartendaten in Berührung kommt. Nichts davon liefert ein Modell, das Swift schreibt.
Kann der Prüfer eine Transaktion tatsächlich abschließen?
Richtlinie 2.1 (Vollständigkeit der App) lässt im Stillen mehr Zahlungs-Apps scheitern als die eigentlichen Zahlungsregeln. Prüfer müssen in der Lage sein, die App vollständig zu testen, einschließlich des Zahlungsflusses. Eine Zahlungs-App erfordert in der Regel ein Händlerkonto, eine Identitätsprüfung und manchmal ein Bankkonto – Dinge, für die sich ein Prüfer während des Reviews nicht anmelden kann. Vibe-codierte Einreichungen scheitern hier ständig, weil der Entwickler oft selbst nie ein echtes Händlerkonto eingerichtet hat; die App wurde nur mit Mock-Daten getestet, die die KI parallel dazu generiert hat. Ohne ein funktionierendes Demokonto und eine Möglichkeit, eine Testtransaktion durchzuführen, wird die App als unvollständig abgelehnt, und jede erneute Einreichung kostet einen weiteren Review-Zyklus.
Was geht also tatsächlich live?
Der schwierige Teil war nie der Code. Ein KI-Assistent kann an einem Nachmittag eine funktionierende Checkout-Oberfläche erstellen, aber der Vertrieb im App Store ist ein Spießrutenlauf aus Berechtigungen, Lizenzen und Review-Richtlinien, der völlig außerhalb der Reichweite eines Prompts liegt. Die Demo funktioniert; die Infrastruktur existiert noch nicht.
Für einen Händler, der physische Güter verkauft, ist die praktische Schlussfolgerung einfacher: Stellen Sie sich erst gar nicht in der Warteschlange an. Ihr Unternehmen benötigt einen funktionierenden Checkout, keinen eigenen Eintrag im App Store – die Lizenzierung, Hardware-Zertifizierung und der Review-Aufwand lohnen sich nur für Unternehmen, deren Produkt die Zahlungssoftware selbst ist. Betreiben Sie Ihre Kasse auf einer POS-Plattform, die diese Kosten bereits übernommen hat (Final ist genau so aufgebaut – Zahlungen über Final Pay mit zertifizierter Terminal-Hardware, ohne dass Sie eine eigene App veröffentlichen müssen), und stecken Sie das Geld für die Review-Zyklen in Dinge, die den Umsatz steigern, wie einen schnelleren Checkout-Flow und niedrigere effektive Kartengebühren.
Apples Review-Prozess existiert aus gutem Grund – fehlerhafte Finanz-Apps schaden echten Menschen. Es ist nur ein Prozess, den die meisten Händler niemals durchlaufen müssen, egal wer oder was die App geschrieben hat.
Häufig gestellte Fragen
Was ist eine per „Vibe-Coding“ erstellte Zahlungs-App?
Eine App, die dadurch entsteht, dass man einem KI-Programmierassistenten beschreibt, was man möchte, und das Generierte direkt veröffentlicht, anstatt sie Zeile für Zeile selbst zu entwickeln. Dieser Ansatz funktioniert für Benutzeroberfläche und Logik, kann aber keine Berechtigungen, Lizenzierungen oder die Einhaltung von Review-Richtlinien gewährleisten.
Was ist die App Store Richtlinie 3.1.1?
Das ist Apples Regel, nach der digitale Inhalte und Dienste, die innerhalb einer App verkauft werden, über Apples In-App-Kaufsystem abgewickelt werden müssen. Sie gilt nicht für physische Güter oder reale Dienstleistungen, die andere Zahlungsmethoden nutzen müssen.
Müssen Apps, die physische Güter verkaufen, Apples In-App-Kauf nutzen?
Nein. Richtlinie 3.1.5(a) verlangt das Gegenteil: Zahlungen für physische Güter und reale Dienstleistungen müssen über eine andere Methode als den In-App-Kauf abgewickelt werden, beispielsweise über das SDK eines Zahlungsabwicklers.
Wie lange dauert die Genehmigung für Tap to Pay auf dem iPhone?
Die Entwicklungsberechtigung wird in der Regel innerhalb von ein bis zwei Werktagen erteilt. Die Veröffentlichungsberechtigung wird vom Operations-Team von Apple geprüft und dauert normalerweise ein bis zwei Wochen, sofern die Anforderungen erfüllt sind.
Kann ein Händler Kartenzahlungen akzeptieren, ohne eine eigene App zu veröffentlichen?
Ja. Die meisten Händler veröffentlichen nie eine App – sie wickeln den Checkout über eine POS-Plattform ab, deren Zahlungsinfrastruktur und zertifizierte Kartenleser-Hardware bereits im Einsatz sind, und konfigurieren diese für ihr Unternehmen.
Warum scheitern Zahlungs-Apps an Apples Vollständigkeitsprüfung?
Prüfer müssen in der Lage sein, eine echte Transaktion durchzuführen. Wenn eine App ein Händlerkonto, eine Bankverifizierung oder Hardware erfordert, die dem Prüfer nicht vorliegt, und kein funktionierendes Demokonto bereitgestellt wird, wird sie gemäß Richtlinie 2.1 abgelehnt.