In-App-Kauf: der Schritt, den die meisten KI-Baukästen noch nicht gelöst haben
Es gibt einen Moment, in dem fast jedes mit KI gebaute Projekt hängen bleibt, und er kommt spät: die App ist fertig, sie sieht gut aus, sie läuft im Browser, und dann wollen Sie sie in den App Store oder zu Google Play bringen, um ein Abo zu verkaufen. Da stellt sich heraus, dass genau der Zahlungsknopf, der im Web funktionierte, die App durchfallen lässt.
Dieser Leitfaden erklärt, warum das passiert, was vorhanden sein muss, um ein Abo in einer veröffentlichten App zu verkaufen, und wo die meisten KI-Werkzeuge 2026 aufhören.
Die Regel, die alle erwischt
Apple und Google verlangen, dass digitale Inhalte, die in einer installierten App verkauft werden, über ihre eigene Abrechnung laufen. Abos, Kurse, Mitgliederbereiche, Werbefreiheit, Premium-Funktionen: all das ist digital.
Einen Stripe-Checkout in die App zu setzen ist keine riskante Abkürzung, es ist das wörtliche Beispiel, mit dem beide Richtlinien beschreiben, was nicht geht. Und die Strafe ist nicht nur eine abgelehnte Prüfung. Eine bereits veröffentlichte App kann entfernt werden, und das passiert mit Abonnenten darin.
Base44 schreibt es in der eigenen Dokumentation, wörtlich: "Do not use Stripe for payments inside your mobile app. Apple and Google require their own billing systems for digital content."
Es gibt eine wichtige Ausnahme: physische Waren und außerhalb der App erbrachte Dienstleistungen dürfen weiterhin ein Gateway nutzen. Ein Kleidungsgeschäft, ein Restaurant mit Lieferung, ein Friseur mit Terminbuchung: dort ist das Gateway der richtige Weg, und der Store nimmt nichts.
Was die meisten KI-Baukästen heute liefern
Zwei Dinge werden zusammen verkauft, die man trennen sollte.
In den Store kommen ist das eine. Mehrere Baukästen können das bereits, indem sie die Web-App in eine native Hülle (ein Webview) packen, die Ihre URL öffnet. Das funktioniert, und ein großer Teil der Apps am Markt ist so gebaut.
In der App verkaufen ist das andere, und hier wird die Liste kurz. Laut der eigenen Dokumentation von Base44 unterstützt die erzeugte Hülle "does not support in-app purchase systems", und das Unternehmen schreibt: "We are working on a built-in integration for StoreKit and Google Play Billing to handle digital purchases and keep your app compliant." Also auf der Roadmap, nicht im Produkt.
Lovable liegt vor diesem Schritt: es ist ein Web-Baukasten, und der Weg in die Stores hängt von Drittanbietern ab, die die App einpacken.
Fairerweise: es gibt No-Code-Werkzeuge, die den In-App-Kauf längst beherrschen, manche seit Jahren. Was es kaum gibt, ist das in einem Baukasten, der die gesamte App aus einer Beschreibung in Textform erzeugt. Von dieser Lücke handelt dieser Artikel.
Was Fabapp macht
Fabapp veröffentlicht die native App und verkauft darin über die Abrechnung des Stores, von Anfang bis Ende. Der erste vollständige Kauf lief im September 2026 durch, und der Weg ist dieser:
- Sie erstellen die App, indem Sie in Textform beschreiben, was Sie wollen;
- die Plattform baut die native Version und reicht sie bei Ihrem Entwicklerkonto ein;
- Sie verknüpfen die Tarife der App mit Store-Produkten, und die Plattform legt das Produkt bei Google Play für Sie an;
- der Kunde kauft über den Bildschirm des Stores selbst, in der App;
- der Kauf wird auf dem Server mit Ihren Zugangsdaten geprüft, und der Zugang wird freigegeben.
Drei Details dieses Wegs gehören laut ausgesprochen, denn sie trennen eine Integration, die funktioniert, von einer, die so aussieht.
Das Geld gehört Ihnen, und die Plattform steht nicht im Weg
Die App wird unter Ihrem Entwicklerkonto mit Ihren Zugangsdaten veröffentlicht. Der Store zahlt auf das Bankkonto aus, das Sie bei Apple und Google hinterlegt haben. Fabapp ist nicht Vermittler des Verkaufs und behält keinen Prozentsatz Ihres Umsatzes.
Das klingt selbstverständlich und ist es nicht: auf Plattformen, wo die App unter dem Konto des Anbieters erscheint, hängen Sie beim Geld von ihm ab, und ein Wechsel bedeutet den Verlust des Store-Eintrags samt Abonnenten.
Das Gerät entscheidet nie
Wenn jemand kauft, gibt die App eine Transaktionskennung zurück. Das ist eine Behauptung, kein Beweis, und sie als Beweis zu behandeln ist der Weg, auf dem ein gefälschter Beleg bezahlten Zugang freischaltet.
Alles, was Geld bewegt (welches Produkt, von wem, bis wann, noch aktiv), wird beim Store zurückgefragt, mit Ihren Zugangsdaten, auf dem Server. Deshalb dauert ein Kauf ein paar Sekunden zwischen der Annahme im Store und der Freigabe in der App.
Die Verlängerung ist ein Schritt, keine Folge
Das ist das Detail, das die meisten zu spät entdecken, und es ist teuer.
Wenn jemand ein Abo abschließt, meldet der Store, bis wann dieser Zugang gilt. Jeden Monat bei der Verlängerung sendet er eine Benachrichtigung, dass die Frist weitergerückt ist. Hört niemand zu, entsteht die schlechteste denkbare Konstellation: Google bucht bei Ihrem Kunden weiter jeden Monat ab, und sein Zugang endet nach dem ersten. Auch eine Erstattung entzieht den Zugang dann nicht mehr, wer also sein Geld zurückholt, nutzt die App weiter.
Bei Fabapp wird dieser Kanal aktiviert, indem Sie eine Zeile in die Play Console einfügen, und der Bildschirm bestätigt es von selbst, sobald die erste Benachrichtigung eintrifft, statt Sie versichern zu lassen, dass Sie es getan haben. Unter iOS geschieht es automatisch.
Was Ihre Arbeit bleibt
Kein Werkzeug nimmt Ihnen das ab, und wer das behauptet, ist verdächtig:
- die Entwicklerkonten: einmalig 25 US-Dollar bei Google, 99 US-Dollar pro Jahr bei Apple;
- das Produkt anlegen in der Store-Konsole, oder das von der Plattform angelegte prüfen;
- die Berechtigungen des Dienstkontos bei Google Play. Veröffentlichen und Käufe lesen sind verschiedene Berechtigungen, und häufig wird die erste gesetzt und die zweite vergessen. Das Symptom täuscht: das Veröffentlichen klappt, und der Kauf schließt im Store ab, ohne in der App etwas freizuschalten;
- Apples Prüfung, die beim ersten Abo zusammen mit der App-Version stattfindet.
Lohnt sich das trotz der Provision?
Der Store behält einen Teil jedes Verkaufs, und beide haben reduzierte Stufen für die meisten kleinen Entwickler, jeweils mit eigenen Regeln. Prüfen Sie die offiziellen Seiten vor der Entscheidung, denn die Bedingungen ändern sich.
Die Rechnung, die meist entscheidet, ist nicht die Provision allein, sondern diese: eine App, die in sich selbst nicht verkaufen kann, schickt den Kunden mitten im Kauf in einen Browser, und ein guter Teil kommt schlicht nicht zurück. Eine Provision auf einen Verkauf, der stattfindet, ist meist mehr wert als null Prozent auf einen, der ausbleibt.
Und es gibt einen Mittelweg, den man vergisst: Sie können das Abo auf der Website über Ihr Gateway verkaufen, ganz ohne Store-Provision, und die Store-Abrechnung nur in der installierten App nutzen. Beides geht nebeneinander, und die Plattform behandelt jedes an seinem Ort.
Wo anfangen
Wenn Sie die App noch nicht haben, beginnen Sie mit der Beschreibung dessen, was sie tut, und lassen Sie die Abrechnung für später: es ist günstiger, zuerst den kostenlosen Ablauf richtig hinzubekommen. Wenn Sie sie schon haben, führt der Weg über den Tab Anwendung, beim Schritt Konten.
Die Leitfäden Abos in der App verkaufen und Ihre Apple- und Google-Konten verbinden gehen es mit den Bildschirmen durch.