lovable stripe Checkout stirbt am Launch-Tag

Dein lovable stripe hat in der Vorschau Testkarten geladen — und war am Tag still, an dem echte Kunden zahlen wollten.

Checkout sah fertig aus. Du hast Stripe eingebunden, die Testkarte lief durch, eine Danke-Seite kam. Du published. Ein Kunde zahlte. Stripe zeigte grün. Deine App behandelte ihn noch wie einen Free-User. Kein Webhook. Keine Zeile in der Datenbank. Support-Tickets kamen, bevor du sahst, dass der Schalter noch im Testmodus hing.

Lovable + Stripe nach Launch tot

Zahlungsfehler nach dem Launch kommen meist von drei Lücken: falsche Keys, fehlende Webhooks, Erfolgsseiten, die lügen.

Nur die Testkarte funktioniert auf der Live-Site

Echte Karten werden abgelehnt oder die Checkout-Session öffnet nicht. Das Dashboard zeigt noch Testmodus. Das deployed Bundle liest noch sk_test_... aus einer Env-Variable, die auf dem Host nie ein Live-Pendant bekam.

Kunde zahlte, Zugang blieb gesperrt

Stripe bucht die Zahlung. Deine Subscriptions-Tabelle bleibt leer. Der Nutzer lädt die Success-URL — Paywall bleibt. Ohne Webhook-Handler in Produktion lief die Backend-Logik nie.

Webhook-Endpunkt fehlt im Live-Mode

Die Stripe CLI hat Events nach localhost weitergeleitet. Der Tunnel starb mit dem Laptop. Live-Mode hat keinen registrierten Endpunkt — oder er zeigt noch auf eine Vorschau-URL ohne öffentliches Internet.

Checkout leitet auf die falsche Domain um

Success- und Cancel-URLs referenzieren noch einen Lovable-Vorschau-Hostnamen. Kunden kommen auf einen Host zurück, den deine App nicht mehr bedient. Sie halten die Zahlung für gescheitert, obwohl Stripe erfolgreich war.

Stripe-Probleme bleiben selten isoliert. Sie treten am Publish-Tag neben fehlenden Env-Vars und Auth-Lücken auf. Starte mit dem Hub unter lovable deploy, dann verdrahte den Webhook-Pfad in stripe webhook.

Warum die KI lovable stripe im Testmodus ausgeliefert hat

Lovable und ähnliche Tools optimieren für sichere Demos. Stripe-Test-Keys lassen jeden 4242-Karten laufen, ohne echtes Geld. Die KI verdrahtet Test-Keys zuerst, weil sie in der Vorschau immer funktionieren.

Checkout-UI ist leicht zu generieren: Button, Redirect, Success-Komponente. Server-Routen, die Signaturen prüfen und DB-Zeilen schreiben, sieht man im Editor schlechter. Agents stoppen oft bei der Happy-Path-Oberfläche.

Webhooks brauchen eine öffentliche HTTPS-URL. Beim Bauen existiert die noch nicht. Tutorials nutzen stripe listen auf localhost. Die KI kopiert das Muster in Kommentare und Env-Beispiele. Nichts erinnert dich, vor dem Launch einen Live-Endpunkt zu registrieren.

Umgebungsvariablen verteilen sich auf drei Orte: Lovable-Vorschau-Secrets, lokale .env, Deployment-Host. Code referenziert STRIPE_SECRET_KEY. Nur eine Umgebung hat den Wert. Produktions-Builds sind grün mit leeren Secrets — bis die erste echte Zahlung scheitert.

lovable stripe für Produktion fixen

Diese Schritte auf dem Live-Deployment erledigen — nicht nur im Lovable-Editor.

1. Live-Mode in Stripe bestätigen. Stripe Dashboard öffnen. Testmodus aus. Live Secret Key (sk_live_...) und Publishable Key (pk_live_...) kopieren. Secret nicht ins Frontend pasten.
2. Live-Keys auf dem Host setzen. In Vercel, Railway oder Deployment-Settings STRIPE_SECRET_KEY und NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY (oder dein Public-Prefix) für Production setzen. Nach dem Speichern redeployen.
3. Live-Webhook-Endpunkt registrieren. Stripe → Developers → Webhooks → Endpunkt-URL auf dem Produktions-Host, z. B. https://yourdomain.com/api/webhooks/stripe. checkout.session.completed für Checkout, invoice.paid bei Abos.
4. Webhook-Signing-Secret kopieren. Nach dem Anlegen den Signing Secret (whsec_...) öffnen. Als STRIPE_WEBHOOK_SECRET in Production-Env setzen. Erneut redeployen.
5. Handler muss Signaturen prüfen. In Lovable die Webhook-Route öffnen. Raw Body lesen und Stripe-Signatur-Check aufrufen. Handler ohne Verifikation ist unsicher und ignoriert echte Events.
6. Checkout Success- und Cancel-URLs aktualisieren. Nach success_url und cancel_url suchen. Vorschau-Hostnamen durch Live-Origin ersetzen. Nur HTTPS.
7. Eine echte kleine Zahlung testen. Live-Karte, die du kontrollierst. Stripe-Zahlung, erfolgreiche Webhook-Delivery und DB-Zeile prüfen. Testzahlung ggf. erstatten.
8. Bei Code-Änderungen aus Lovable republishen. URL- und Key-Fixes auf dem Host greifen nur, wenn Code Env-Vars korrekt liest. Hardcodierte Test-Keys im Source entfernen und redeployen.

Test- und Live-Webhook-Endpunkte getrennt halten. Eine URL, die mit Test-Keys lief, existiert im Live-Mode nicht automatisch.

Checkliste, bevor du lovable stripe live-ready nennst

• Production-Env nutzt sk_live_, nicht sk_test_
• Live-Webhook-Endpunkt mit korrekten Events registriert
• STRIPE_WEBHOOK_SECRET auf dem Host und passend zum Live-Endpunkt
• Webhook-Handler prüft Signaturen und aktualisiert die Datenbank
• Checkout Success- und Cancel-URLs nutzen deine Live-Domain
• Ein echter End-to-End-Zahlungstest abgeschlossen

FAQ

Warum funktioniert lovable stripe in der Vorschau, aber nicht nach dem Launch?

Die Vorschau nutzt oft Stripe-Test-Keys und localhost-Webhook-Forwarding. Produktion braucht Live-API-Keys in der Host-Umgebung, eine öffentliche HTTPS-Webhook-URL und Checkout für deine Live-Domain.

Brauche ich einen stripe webhook für lovable stripe Zahlungen?

Ja. Die Erfolgsseite ist kosmetisch. Dein Server muss checkout.session.completed oder invoice.paid Events empfangen, um Zugang zu geben, Bestellungen zu schreiben und Bestätigungs-Mails zu senden.

Wo lege ich Stripe-Live-Keys für eine Lovable-App ab?

STRIPE_SECRET_KEY und STRIPE_WEBHOOK_SECRET in den Environment Variables des Deployment-Hosts setzen — nicht nur in Lovable-Vorschau-Einstellungen. Nach dem Speichern redeployen. Secret Keys nie in Client-Code.