Um Stripe-Zahlungen in eine mit KI gebaute App einzubauen, wählen Sie das Stripe-Produkt, das zu Ihrem Angebot passt (einen Payment Link, Checkout oder Checkout mit Abonnement), halten den geheimen Stripe-Schlüssel auf dem Server in einer Edge Function und lassen einen Webhook, nicht die Erfolgsseite, den Zahlstatus in Ihre Datenbank schreiben. Danach testen Sie alles im Testmodus von Stripe, bevor Sie live gehen. Ein KI-App-Baukasten kann den gesamten Code schreiben, braucht diese Entscheidungen aber ausdrücklich genannt, Schritt für Schritt.
Dieser Leitfaden behandelt die drei Stripe-Optionen, die serverseitige Einrichtung, den Webhook, das Kundenportal, das Testen und die genauen Prompts zum Senden. Zum größeren Zusammenhang, wie Sie die App selbst bauen, lesen Sie unseren Leitfaden zum Erstellen einer App mit KI.
Payment Links, Checkout oder Abos: was passt
Nutzen Sie einen Payment Link, wenn Sie etwas Einfaches verkaufen und Ihre App nicht in Echtzeit reagieren muss, Checkout, wenn Ihre App bestimmt, was abgerechnet wird und wer zahlt, und eine Checkout-Session im Abo-Modus, wenn der Zugang von einem wiederkehrenden Tarif abhängt. Laut der Dokumentation zu Stripe Payment Links ist ein Payment Link eine von Stripe gehostete Seite, die Sie ohne Code anlegen und per Link, QR-Code oder einbettbarem Kaufbutton teilen. Er kann ein Produkt, ein Abo verkaufen oder Spenden annehmen, bei begrenzter optischer Anpassung.
Checkout ist dieselbe Art Zahlungsseite, aber Ihr Code erstellt sie über die Checkout Sessions API, wie in der Checkout-Dokumentation von Stripe beschrieben. Dadurch kann Ihre App die Zahlung einem angemeldeten Nutzer zuordnen, den Preis aus Ihrer Datenbank wählen und den Kunden auf den richtigen Screen zurückschicken. Checkout kann eine von Stripe gehostete Seite oder ein in Ihre Website eingebettetes Formular sein.
| Option | Code nötig | Weiß, welcher Nutzer gezahlt hat | Am besten für | Haupteinschränkung |
|---|---|---|---|---|
| Payment Link | Keiner zum Anlegen | Nur durch nachträglichen Abgleich der E-Mail oder eines URL-Parameters | Ein erster Verkauf, ein einmaliges Produkt, eine Spende, ein Vorverkauf | Begrenzte Anpassung; Ihre App ist nicht eingebunden, solange Sie keinen Webhook ergänzen |
| Checkout (Einmalzahlung) | Eine Server-Funktion | Ja, Sie übergeben beim Anlegen der Session Ihre Nutzer-ID | Credits kaufen, ein kostenpflichtiger Bericht, eine Buchungsanzahlung | Sie pflegen die Funktion und den Webhook |
| Checkout (Abo-Modus) | Eine Server-Funktion plus Webhook-Verarbeitung | Ja | SaaS-Tarife, Mitgliedschaften, alles, was monatlich oder jährlich abgerechnet wird | Verlängerungen, fehlgeschlagene Zahlungen und Kündigungen treffen später ein und müssen verarbeitet werden |
Der geheime Schlüssel gehört nie in den Browser
Der geheime Stripe-Schlüssel darf nur auf einem Server liegen, denn wer ihn besitzt, kann Zahlungen auslösen, Rückerstattungen veranlassen und Kundendaten lesen. Der Browser braucht lediglich eine kurzlebige Checkout-URL, die Ihr Server nach dem Aufruf von Stripe zurückgibt. Legt ein KI-App-Baukasten den geheimen Schlüssel in eine React-Datei, ist die App unsicher, und das ist die erste Prüfung bei jedem generierten Zahlungscode.
Das Standardmuster ist eine Edge Function, ein kleines Stück Servercode, das neben Ihrer Datenbank läuft. Der Browser ruft sie mit dem Login des Nutzers auf, die Funktion prüft, wer der Nutzer ist, erstellt mit dem geheimen Schlüssel die Checkout-Session und gibt die URL zurück. Der Schlüssel selbst liegt als Umgebungsvariable, nie im Code. Unser Leitfaden zur Sicherheit beim Vibe Coding nennt weitere Prüfungen, die sich für generierten Code lohnen.
Warum die Datenbank vom Webhook aktualisiert wird und nicht von der Erfolgsseite
Markieren Sie eine Bestellung erst dann als bezahlt, wenn Stripe es Ihrem Server per Webhook mitteilt, nie, wenn der Kunde auf Ihrer Erfolgsseite landet. Die Erfolgsseite ist nur ein Browser-Tab: Man kann ihn schließen, bevor er lädt, jemand kann die Adresse einfach eintippen, oder er wird nie erreicht, weil die Verbindung des Kunden nach der Zahlung abreißt. Ein Webhook ist Stripe, das Ihren Server direkt aufruft, und die Webhook-Dokumentation von Stripe beschreibt ihn als den Weg, auf asynchrone Ereignisse zu reagieren, etwa wenn eine Bank eine Zahlung bestätigt, ein Streitfall eintritt oder eine wiederkehrende Zahlung gelingt.
Ein Webhook-Handler braucht vier Eigenschaften:
- Er prüft die Signatur. Jede Anfrage trägt einen Header
Stripe-Signature. Der Handler prüft ihn mit dem Endpoint-Secret, sodass ein Fremder, der gefälschte „bezahlt“-Ereignisse schickt, abgewiesen wird. Der Zeitstempel im Header begrenzt zudem Wiederholungen. - Er antwortet schnell mit einem Erfolgscode. Stripe erwartet eine 2xx-Antwort. Im Live-Modus wiederholt Stripe eine fehlgeschlagene Zustellung bis zu drei Tage lang mit wachsenden Abständen; im Testmodus gibt es drei Versuche über einige Stunden.
- Er verträgt eine doppelte Ausführung. Wegen der Wiederholungen kann dasselbe Ereignis mehrfach eintreffen. Speichern Sie die Ereignis-ID oder schreiben Sie den Status so, dass ein zweiter Lauf dasselbe Ergebnis liefert.
- Er ist ohne Nutzer-Login erreichbar. Stripe ist kein angemeldeter Nutzer Ihrer App, also muss genau diese Funktion Anfragen ohne Ihre übliche Login-Prüfung annehmen und sich stattdessen auf die Signatur stützen.
Was in die Datenbank gehört
Speichern Sie die Stripe-Kunden-ID, die Abo-ID, den Tarif und den Abo-Status neben jedem Nutzer und aktualisieren Sie sie nur aus Webhook-Ereignissen. Ihre App liest dann eine lokale Zeile, um zu entscheiden, was ein Nutzer darf, ohne bei jeder Seite Stripe aufzurufen. Für Abos listet der Webhook-Leitfaden zu Abos von Stripe die Ereignisse und Status auf, die Sie behandeln müssen:
| Stripe-Signal | Bedeutung | Was Ihre App tut |
|---|---|---|
invoice.paid | Eine Rechnung, auch eine Verlängerung, wurde bezahlt | Zugang gewähren oder verlängern (Stripe rät, zuvor zu prüfen, dass der Abo-Status active ist) |
invoice.payment_failed | Ein Zahlungsversuch ist fehlgeschlagen | Den Kunden warnen und bitten, seine Karte zu aktualisieren |
customer.subscription.updated | Tarif, Verlängerung oder Status haben sich geändert | Neuen Tarif und Status in Ihre Tabelle übernehmen |
customer.subscription.deleted | Das Abo ist beendet | Bezahlten Zugang entziehen |
Status past_due | Die letzte Zahlung ist fehlgeschlagen, Stripe versucht es eventuell erneut | Den Kunden benachrichtigen; entscheiden, wie lange der Zugang bleibt |
Status canceled oder unpaid | Zahlt nicht mehr | Zugang entziehen, gemäß Stripes Empfehlung |
Weil Nutzer ihren eigenen Tarif aus dieser Tabelle lesen, braucht sie Row Level Security: Ein Nutzer darf seine eigene Zeile lesen, und niemand darf aus dem Browser hineinschreiben. Nur die Webhook-Funktion schreibt, mit einem serverseitigen Schlüssel. Unser Leitfaden zu Supabase Row Level Security erklärt die Policy.
Kunden über das Kundenportal kündigen lassen
Nutzen Sie das Kundenportal von Stripe für Kündigungen, Kartenwechsel und Rechnungen, statt diese Screens selbst zu bauen. Laut der Dokumentation zum Stripe-Kundenportal können Kunden Rechnungsdaten und Zahlungsmethoden aktualisieren, ein Abo ändern oder pausieren, sofort oder zum Ende des Abrechnungszeitraums kündigen sowie Rechnungen ansehen oder bezahlen. Sie konfigurieren es im Stripe Dashboard.
Ihre App braucht einen Button „Abrechnung verwalten“, der eine zweite Edge Function aufruft. Die Funktion erstellt eine Portal-Session für die Stripe-Kunden-ID des angemeldeten Nutzers und gibt eine URL zurück. Zwei Einschränkungen derselben Seite zählen: Das Portal lässt sich nicht in einem iframe anzeigen, und der Link einer neuen Session läuft nach 5 Minuten ab, erstellen Sie ihn also beim Klick des Nutzers und nicht im Voraus. Kündigungen dort erreichen Ihre Datenbank über dieselben Webhook-Ereignisse, es ist also kein zusätzlicher Code nötig.
Testmodus und Testkarten
Testen Sie alles mit den Test-Schlüsseln von Stripe, bevor Sie den Live-Modus anfassen, denn Testumgebungen sind isoliert und bewegen kein echtes Geld. Laut dem Testleitfaden von Stripe dürfen Sie beim Testen nie echte Kartendaten verwenden. Diese Karten lohnen einen Versuch:
| Szenario | Kartennummer |
|---|---|
| Erfolgreiche Zahlung | 4242 4242 4242 4242 |
| Allgemeine Ablehnung | 4000 0000 0000 0002 |
| Nicht genügend Guthaben | 4000 0000 0000 9995 |
| 3D Secure, Authentifizierung, sofern nicht bereits eingerichtet | 4000 0025 0000 3155 |
Als Ablaufdatum genügt ein beliebiges Datum in der Zukunft, als CVC drei beliebige Ziffern, und für die übrigen Felder jeder Wert. Spielen Sie mindestens vier Szenarien durch: eine erfolgreiche Zahlung, eine abgelehnte Karte, eine Kündigung über das Portal und einen zweimal zugestellten Webhook. Prüfen Sie nach jedem die Datenbankzeile.
Gebühren, Steuern und Rechnungen
Die Standardgebühr von Stripe für Kartenzahlungen besteht aus einem Prozentsatz pro Zahlung plus einem Fixbetrag, und beides variiert je nach Land. Lesen Sie den Wert für Ihr Land auf stripe.com/pricing, bevor Sie Ihre Preise festlegen. Auf den Seiten, die wir im November 2026 lesen konnten, fanden wir keinen US-Satz, deshalb nennen wir hier keine Kartengebühr. Dieselbe Seite zeigt Billing, das Abo-Produkt, als separate Gebühr auf wiederkehrendes Volumen (0,7 % bei Pay-as-you-go, im November 2026 auf der französischen Preisseite geprüft), und Stripe Tax als weitere optionale Position.
Kurz gesagt: Checkout und Payment Links unterstützen beide Stripe Tax, das Umsatzsteuer oder Sales Tax für Sie berechnet, und Stripe kann Belege und Rechnungen automatisch versenden. Ob Sie sich registrieren und Steuern erheben müssen, hängt davon ab, wo Sie und Ihre Kunden sitzen. Fragen Sie vor dem Start einen Steuerberater, nicht einen KI-App-Baukasten.
Die Prompts zum Senden, Schritt für Schritt
Senden Sie diese Prompts der Reihe nach und prüfen Sie jedes Ergebnis vor dem nächsten, denn ein einziger Prompt, der Zahlungen, Webhooks und Portal auf einmal verlangt, erzeugt Code, der schwer zu debuggen ist. Legen Sie zuerst Ihr Stripe-Konto, ein Produkt und einen Preis im Testmodus an und halten Sie die Preis-ID bereit. Ersetzen Sie die Teile in [eckigen Klammern].
- Checkout. „Füge eine Seite Preise mit einem Tarif [Pro] zu [19 $ im Monat] hinzu. Der Button Abonnieren ruft eine Server-Funktion auf, die prüft, ob der Nutzer angemeldet ist, eine Stripe-Checkout-Session im Abo-Modus für die Preis-ID [price_xxx] mit angehängter Nutzer-ID erstellt und die URL zurückgibt. Leite den Browser dorthin weiter. Der geheime Stripe-Schlüssel darf nur innerhalb dieser Funktion verwendet werden.“
- Datenbank. „Lege eine Tabelle subscriptions an mit Nutzer-ID, Stripe-Kunden-ID, Abo-ID, Tarif, Status und Ende des aktuellen Zeitraums. Füge Row Level Security hinzu, sodass ein Nutzer nur seine eigene Zeile lesen kann und nichts aus dem Browser geschrieben werden kann.“
- Webhook. „Erstelle eine Stripe-Webhook-Funktion, die den Header Stripe-Signature mit dem Webhook-Secret prüft und dann checkout.session.completed, invoice.paid, invoice.payment_failed, customer.subscription.updated und customer.subscription.deleted behandelt, indem sie die Tabelle subscriptions aktualisiert. Es muss unbedenklich sein, dasselbe Ereignis zweimal zu empfangen, und die Funktion darf keinen Nutzer-Login verlangen.“
- Zugang. „Lies die Tabelle subscriptions, um zu entscheiden, was ein Nutzer verwenden darf. Zeige bei [Funktion] einen gesperrten Zustand mit Upgrade-Button für Nutzer, deren Status nicht active oder trialing ist. Vertraue nie der Erfolgsseite, um etwas freizuschalten.“
- Portal. „Füge in den Einstellungen einen Button Abrechnung verwalten hinzu, der eine Server-Funktion aufruft, die eine Stripe-Kundenportal-Session für den aktuellen Nutzer erstellt und deren URL zurückgibt.“
- Fehlschläge. „Schlägt eine Zahlung fehl, zeige ein Banner, das den Nutzer bittet, seine Karte zu aktualisieren, mit einem Link zum Portal.“
Die erste Nachricht zählt am meisten; unser Leitfaden zum Schreiben von Prompts für den Bau einer App erklärt, warum.
Wie Cadrant es macht
Cadrant, unser Baukasten, erzeugt React-Web-Apps mit einem Supabase-Backend und behandelt Stripe über Supabase Edge Functions in Ihrem eigenen Supabase-Projekt. Sie fordern die Integration im Chat an, zum Beispiel „Füge Stripe-Zahlung für Abonnements hinzu“. Cadrant schreibt den Code der Edge Function und deployt ihn in Ihr Supabase-Projekt. Laut unserer Dokumentation zu Edge Functions ruft der Browser die Funktion über die Supabase-API auf, und die Schlüssel erreichen ihn nie.
Den Schlüssel tragen Sie selbst im Bereich Environment des Projekts ein, unter dem Bereich Database, als Variable wie STRIPE_SECRET_KEY, das Webhook-Secret als zweite Variable. Laut der Seite zu Umgebungsvariablen stehen Variablen nur dem Servercode zur Verfügung und lassen sich ändern, ohne die App neu zu deployen. Fügen Sie nie einen geheimen Schlüssel in den Chat ein. Die KI schreibt außerdem die Datenbankmigrationen mit Row Level Security, sodass die Tabelle subscriptions aus Schritt 2 denselben Regeln folgt wie Ihre übrigen Daten.
Cadrant ist nicht der einzige Weg. Jeder Baukasten, der Server-Funktionen erzeugt, kann denselben Schritten folgen, und wenn Sie volle Kontrolle über die Abrechnungslogik wollen, ist es weiterhin sinnvoll, dass ein Entwickler den generierten Code vor dem Start prüft. Stripe kümmert sich in jedem Fall um das Geld und die Kartendaten; Ihr Code entscheidet nur, wer Zugang bekommt.
Sobald die Zahlungen funktionieren, veröffentlichen Sie auf Ihrer eigenen Domain; unser Leitfaden zum Deployen einer Web-App behandelt diesen Schritt.