Stripe Teil 1: Checkout, Subscriptions, Test vs Produktion

Überblick

Auth, Daten und Secrets sind an Ort und Stelle. Jetzt kann dein Produkt Geld verdienen. Stripe ist der Standard, um Zahlungen entgegenzunehmen, und der Hauptnutzen ist, dass du nie eine rohe Kreditkartennummer anfässt - Stripe sammelt sie ein, sodass deine Compliance-Last von beängstigend auf handhabbar schrumpft. Diese Lektion bringt dich zu einer funktionierenden Subscription: die zwei Geschmacksrichtungen von Checkout, wie Produkte und Preise deine Preisgestaltung modellieren, wie Subscriptions wiederkehrende Abrechnung handhaben inklusive des Monatlich-versus-Jährlich-Toggles, den deine Pricing-Seite braucht, und die Testmodus-Disziplin, die dich das Ganze bauen und prüfen lässt, ohne einen Cent echtes Geld zu bewegen.

Was du lernst

Du lernst den Unterschied zwischen Hosted und Embedded Checkout und wann du jedes nutzt, wie Stripes Produkte-und-Preise-Modell auf deine Preisstufen abbildet, wie Subscriptions wiederkehrende monatliche und jährliche Abrechnung handhaben, wie du komplett im Testmodus mit Stripes Testkarten baust und die saubere Checkliste, um auf Produktion umzustellen, sobald alles funktioniert.

Voraussetzungen

Eine funktionierende App mit Auth und Daten und die Secrets-Disziplin aus der vorigen Lektion, denn Stripe-Keys gehören zu den sensibelsten, die du je halten wirst - ein geleakter Live-Key ist eine direkte Leitung zu deinem Geld. Du solltest auch damit vertraut sein, dass Test und Produktion separate Welten sind, genau wie bei Clerk.

Das Problem

Einsteiger nehmen an, Zahlungen entgegenzunehmen heisse, ein Kreditkartenformular zu bauen und Kartennummern zu speichern. Dieser Weg ist ein Albtraum: rohe Karten zu handhaben stellt dich unter das volle Gewicht der PCI-Compliance, und ein Fehler setzt dich Betrug und rechtlicher Haftung aus, die du nicht zu tragen ausgerüstet bist. Also vermeiden Leute entweder das Belasten ganz und lassen Geld auf dem Tisch, oder sie bauen etwas Unsicheres. Stripe existiert genau dafür, dass du nie eine Kartennummer speicherst. Du reichst den Zahlungsschritt an Stripe weiter, es sammelt die Karte auf seiner eigenen sicheren Infrastruktur ein und teilt dir das Ergebnis mit. Dein Job schrumpft auf "Produkte einrichten und auf das reagieren, was Stripe dir sagt", was völlig machbar ist.

Hosted versus Embedded Checkout

Stripe Checkout ist eine vorgefertigte, sichere Zahlungsseite, die Stripe pflegt, sodass du einen polierten, PCI-konformen Zahlungs-Flow ohne ein Formular zu bauen bekommst. Es kommt in zwei Geschmacksrichtungen. Hosted Checkout leitet den Kunden auf eine von Stripe gehostete Seite um (checkout.stripe.com), er zahlt, und Stripe leitet ihn zurück zu deiner Erfolgs-URL - am einfachsten einzurichten, voll von Stripe gepflegt. Embedded Checkout rendert dieselbe sichere Zahlungserfahrung innerhalb deiner eigenen Seite, sodass der Kunde deine App nie verlässt, was die Conversion verbessern kann und sich nativer anfühlt. Beide sind gleich sicher, weil Stripe so oder so die Kartendaten handhabt; der Unterschied ist rein, ob die Zahlung auf Stripes Seite oder eingebettet in deiner passiert. Starte mit Hosted, um am schnellsten funktionsfähig zu sein, wechsle dann zu Embedded für eine reibungslosere Erfahrung (Teil 2 behandelt Embedded ausführlich).

• Hosted Checkout: zu einer Stripe-Seite umleiten, zahlen, zurück umleiten. Am schnellsten zu shippen, null Kartenhandhabung.
• Embedded Checkout: derselbe sichere Flow, gerendert innerhalb deiner eigenen App. Bessere Conversion, mehr Politur.
• Beide sind gleich sicher - Stripe handhabt die Karte in beiden Fällen. Die Wahl betrifft die Nutzererfahrung.
• Du siehst oder speicherst mit keiner der beiden Optionen eine Kartennummer.

Produkte und Preise

Stripe modelliert deine Preisgestaltung mit zwei verknüpften Objekten: einem Produkt und einem oder mehreren Preisen. Ein Produkt ist die Sache, die du verkaufst ("Pro-Plan"). Ein Preis ist eine bestimmte Art, dafür zu zahlen ("20 USD pro Monat" oder "200 USD pro Jahr"). Ein Produkt kann mehrere Preise haben - das ist genau, wie du eine Pricing-Seite mit einem Monatlich/Jährlich-Toggle baust: dasselbe Pro-Produkt hat einen monatlichen Preis und einen jährlichen Preis, und dein Toggle schaltet um, welchen Preis der Checkout nutzt. Du erstellst Produkte und Preise im Stripe-Dashboard (oder via API), und jeder Preis bekommt eine ID wie price_xxx, auf die du verweist, wenn du einen Checkout startest. Preise als separate Objekte zu halten, statt Beträge in deinem Code fest einzubauen, heisst, dass du die Preisgestaltung im Dashboard ändern kannst, ohne neu zu deployen.

• Produkt: was du verkaufst (der "Pro-Plan").
• Preis: eine Art, dafür zu zahlen (monatlich vs jährlich sind zwei Preise am selben Produkt).
• Ein Monatlich/Jährlich-Toggle ist einfach die Wahl zwischen zwei Preis-IDs zum Checkout-Zeitpunkt.
• Verweise auf Preise per ihrer price_xxx-ID; ändere Beträge im Dashboard, ohne Code anzufassen.

Subscriptions: monatlich und jährlich

Eine Subscription ist ein Preis, der nach einem wiederkehrenden Zeitplan abgerechnet wird. Wenn ein Kunde mit einem wiederkehrenden Preis auscheckt, erstellt Stripe eine Subscription und belastet seine Karte automatisch in jedem Zyklus - monatlich oder jährlich - und handhabt Verlängerungen, Wiederholungen bei fehlgeschlagenen Zahlungen und Kündigungen für dich. Das ist der Motor der SaaS-Umsätze, und Stripe fährt den Abrechnungszyklus, sodass du es nicht musst. Für die Pricing-Seite, die der Hausstil dieses Kurses verlangt, modellierst du zwei wiederkehrende Preise pro Stufe (einen monatlichen Preis und einen jährlichen Preis), stellst die Seite standardmässig auf den jährlichen Preis pro Monat und lässt den Toggle auf monatlich umschalten. Hier ist die Form, einen Subscription-Checkout zu starten - die genaue API-Oberfläche entwickelt sich, also folge Stripes aktuellen Docs, aber die Struktur bleibt stabil.

// Nur Backend (nutzt den SECRET key). Erstellt eine Checkout-Session für einen
// wiederkehrenden Preis. Die Preis-ID entscheidet monatlich vs jährlich.
import Stripe from 'stripe'

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!)

export async function createSubscriptionCheckout(opts: {
  priceId: string // price_xxx für den gewählten monatlichen ODER jährlichen Plan
  customerEmail: string
}) {
  return stripe.checkout.sessions.create({
    mode: 'subscription', // wiederkehrende Abrechnung, keine Einmalzahlung
    line_items: [{ price: opts.priceId, quantity: 1 }],
    customer_email: opts.customerEmail,
    success_url: 'https://app.yoursite.com/welcome?session_id={CHECKOUT_SESSION_ID}',
    cancel_url: 'https://app.yoursite.com/pricing',
  })
}

Das läuft auf dem Backend mit deinem Secret Key, nie im Browser. Die Session, die es zurückgibt, ist das, wohin du den Kunden umleitest (Hosted) oder was du in deiner Seite renderst (Embedded). So oder so wird die Karte von Stripe eingesammelt.

Testmodus und Testkarten

Stripe gibt dir zwei völlig separate Modi - Test und Live - jeden mit eigenen Keys und eigenen Daten. Im Testmodus baust und prüfst du den gesamten Zahlungs-Flow, ohne echtes Geld zu bewegen, mit speziellen Testkartennummern, die Stripe erkennt. Die berühmte ist 4242 4242 4242 4242: eine Visa, die immer gelingt. Stripe bietet auch Karten, die Fehlschläge, Ablehnungen und Authentifizierungs-Herausforderungen simulieren, sodass du auch die unglücklichen Pfade testen kannst. Nutze ein beliebiges zukünftiges Ablaufdatum, eine beliebige dreistellige CVC und eine beliebige Postleitzahl. Mach deine ganze Entwicklung hier. Deine Test-Keys beginnen mit sk_test und pk_test und spiegeln dieselbe Präfix-Konvention, die du bei Clerk gesehen hast.

• 4242 4242 4242 4242 - gelingt jedes Mal. Deine Voreinstellung fürs Happy-Path-Testen.
• 4000 0000 0000 0002 - immer abgelehnt, sodass du die Fehlerbehandlung testen kannst.
• 4000 0025 0000 3155 - erfordert Authentifizierung (3D Secure), sodass du diesen Flow testen kannst.
• Nutze ein beliebiges zukünftiges Ablaufdatum, eine beliebige CVC, eine beliebige Postleitzahl. Echte Karten tun im Testmodus nichts.

Testmodus-Daten (Kunden, Subscriptions, Zahlungen) sind völlig getrennt von Live-Daten und übertragen sich nie. Wenn du live gehst, startest du mit einem sauberen Live-Dashboard. Diese Trennung ist ein Feature: du kannst frei experimentieren, ohne je eine echte Abbuchung zu fürchten.

Auf Produktion gehen

Sobald alles im Testmodus funktioniert, ist Live-Gehen eine kurze, sorgfältige Checkliste statt eines Neuaufbaus. Du aktivierst deinen Stripe-Account (Stripe braucht deine Geschäfts- und Bankdaten, um dich auszuzahlen), erstellst deine Produkte und Preise im Live-Modus neu, falls du sie nur im Test gemacht hast, tauschst deine Test-Keys gegen Live-Keys in deiner deployten Umgebung und aktualisierst alle Preis-IDs, auf die dein Code verweist, auf die Live-IDs. Dann fährst du selbst eine echte, kleine Transaktion, um zu bestätigen, dass die ganze Schleife von Anfang bis Ende mit Live-Keys funktioniert. Entscheidend ist, dass du Test und Live strikt getrennt hältst - füg nie einen Live-Key in eine Development-env-Datei ein. Teil 2 fügt das Webhook-Setup hinzu, das Produktions-Billing wirklich braucht, also behandle Live-Gehen als "bereit, Zahlungen entgegenzunehmen" statt "voll produktionsgehärtet", bis du Teil 2 gemacht hast.

• Aktiviere deinen Stripe-Account mit echten Geschäfts- und Bankdaten, damit Auszahlungen funktionieren.
• Erstelle Produkte und Preise im Live-Modus neu; notiere die neuen Live-price_xxx-IDs.
• Tausche sk_test / pk_test gegen sk_live / pk_live nur in deiner deployten Umgebung.
• Mach selbst eine kleine echte Transaktion, um die Live-Schleife zu bestätigen, dann erstatte sie zurück.
• Nenn es nicht fertig, bis Teil 2 die Webhooks verdrahtet - sie sind, wie deine App erfährt, was wirklich passiert ist.

Typische Fehler

Die häufigen: den Stripe Secret Key in Frontend-Code legen, wo jeder Besucher ihn lesen kann (er gehört nur ins Backend); Preisbeträge im Code fest einbauen, statt auf Preis-IDs zu verweisen, sodass eine Preisänderung ein Neu-Deploy bedeutet; vergessen, dass Test- und Live-Daten sich nie verbinden, und dann in Panik geraten, dass die Produktion leer aussieht; und der grosse, vor dem dieser Kurs immer wieder warnt - denken, Checkout allein reiche. Ohne Webhooks (Teil 2) rät deine App, ob eine Zahlung wirklich gelungen ist. Bau im Testmodus, halt den Secret Key im Backend und behandle Teil 2 als verpflichtend, nicht optional.

Business-ROI

Payments sind der Moment, in dem dein Produkt aufhört, eine Kostenstelle zu sein, und ein Business wird. Stripe lässt eine Solo-Gründerin Geld von überall auf der Welt entgegennehmen, nach einem wiederkehrenden Zeitplan, ohne ein Payments-Team oder PCI-Auditoren, an einem Nachmittag. Subscriptions verwandeln speziell einmaligen Aufwand in wiederkehrenden Umsatz, was der gesamte finanzielle Reiz von SaaS ist - du baust einmal und verdienst monatlich. Und der Monatlich-versus-Jährlich-Toggle ist nicht kosmetisch: jährliche Pläne verbessern den Cashflow und senken die Abwanderung, weshalb der Hausstil dieses Kurses die Pricing-Seite standardmässig auf den jährlichen Preis stellt. Gut bezahlt zu werden ist genauso eine Produktentscheidung wie eine technische.

Checkliste

Du bist bereit für Teil 2, wenn all das im Testmodus stimmt.

• Du kannst erklären, warum du nie rohe Kartendaten handhabst und was Checkout für dich tut.
• Du hast ein Produkt mit sowohl einem monatlichen als auch einem jährlichen Preis erstellt.
• Ein Subscription-Checkout funktioniert im Testmodus mit Karte 4242 4242 4242 4242.
• Der Stripe Secret Key lebt nur im Backend, in einer gitignored env-Datei.

Ressourcen

Die Stripe-Docs und die Testkarten-Referenz sind essentiell und immer aktuell - halt sie offen, während du baust. Die Stripe CLI (in Teil 2 stark genutzt) lohnt sich jetzt zu installieren. Deine Pricing-Seite sollte dem Hausstil dieses Kurses folgen: jährlicher Preis standardmässig pro Monat gezeigt, mit einem Monatlich/Jährlich-Toggle. Als Nächstes macht Teil 2 das Billing mit Webhooks wirklich verlässlich.

Deine Aufgabe

Erstelle im Testmodus ein Pro-Produkt mit einem monatlichen und einem jährlichen Preis, baue dann einen Subscription-Checkout, den ein eingeloggter Nutzer mit der 4242-Testkarte abschliessen kann. Bestätige, dass die Subscription in deinem Stripe-Test-Dashboard erscheint. Probier dann die abgelehnte Karte (4000 0000 0000 0002) und beachte, wie deine App den Fehlschlag handhabt - dieses Bewusstsein für den unglücklichen Pfad trennt einen echten Billing-Flow von einer Demo.

Nächste Lektion

Checkout ist nur die halbe Geschichte. Die nächste Lektion handhabt die Teile, die Billing vertrauenswürdig machen: Webhooks (und warum Polling der falsche Instinkt ist), Signaturverifizierung, Idempotenz, Proration, wenn ein Kunde mitten im Zyklus upgradet, Coupons und Promotion Codes und Embedded Checkout. Das sind die Details, die ein Spielzeug von einem echten Billing-System trennen.