Payment-Formular erstellen — Zahlungen direkt im Formular

Seit 2021 ist Strong Customer Authentication (SCA) für die meisten Online-Zahlungen in der EU Pflicht. Wer ein Payment-Formular ohne SCA-Unterstützung baut, sieht in der DACH-Region Conversion-Verluste von 20 bis 40 Prozent — die Bank lehnt die Transaktion einfach ab. Stripe Payment Intents lösen das auf Tool-Ebene, indem sie automatisch 3D-Secure auslösen, wenn die Bank es verlangt.

Technisch heißt das: Sie erstellen serverseitig einen Payment Intent, geben den Client-Secret an das Frontend, dort wird er mit Stripe.js bestätigt. Die SCA-Aufforderung erscheint als modaler Dialog (3D-Secure), der Nutzer bestätigt per App oder SMS, danach läuft die Zahlung durch. Der gesamte Flow dauert typischerweise 10 bis 30 Sekunden zusätzlich, ist aber rechtlich unausweichlich.

Wichtig: Testen Sie SCA explizit mit den Test-Karten von Stripe (4000 0027 6000 3184 erzwingt 3D-Secure). Viele Teams stellen erst nach dem Live-Gang fest, dass ihr Flow unter SCA bricht — etwa weil das Modal von einem Popup-Blocker geschluckt wird oder die Erfolgs-Page zu früh redirected. Webhook-Listener auf "payment_intent.succeeded" sind die einzig zuverlässige Methode, den Zahlungsstatus serverseitig zu bestätigen.

Einmalzahlungen sind technisch einfacher — Karte rein, Bestätigung raus, fertig. Recurring (Abos) bringt eine ganze Klasse zusätzlicher Probleme: Karten laufen ab, Banken lehnen Folge-Buchungen ab (Soft-Decline), Kunden wechseln Karten, Mehrwertsteuer ändert sich. Stripe Subscriptions löst das meiste, erfordert aber bewusste Entscheidungen.

Für Einmal-Käufe nutzen Sie Payment Intents direkt. Für Abos Subscription-Objekte mit einem Price-ID, der die Frequenz und den Betrag definiert. Beachten Sie die Behandlung von Pro-Rata-Berechnungen bei Plan-Wechseln, Trials, Coupons und Steuern (Stripe Tax oder eigene Berechnung). Eine selbstgebaute Abo-Logik wird schnell zur Falle — Stripe Subscriptions sind dafür gebaut und decken 95 Prozent der Fälle ab.

Für den Lebenszyklus brauchen Sie zwingend Webhooks: invoice.payment_failed, customer.subscription.deleted, invoice.upcoming. Ohne diese Events erfahren Sie nichts von gescheiterten Verlängerungen. Eine Dunning-Strategie (drei Versuche über sieben Tage) ist Standard. Customer Portal von Stripe spart Ihnen den Aufbau eines eigenen Abo-Verwaltungs-UIs — die Kunden können dort ihre Karte aktualisieren, Belege einsehen und kündigen.

Eine Zahlung ohne sichtbare Bestätigung erzeugt Verunsicherung — der Kunde fragt sich, ob das Geld weg ist und nichts ankommt. Drei Bestätigungs-Ebenen sind im B2B-Kontext erwartbar: ein Erfolgsbildschirm direkt nach der Zahlung, eine Bestätigungs-E-Mail innerhalb von Minuten, und ein PDF-Beleg/Rechnung als Anhang oder Download-Link.

Für den Erfolgsbildschirm gilt: Zeigen Sie die wichtigsten Daten (Betrag, Empfänger, Transaktions-ID), nicht nur ein Häkchen. Die Transaktions-ID ist die Brücke für Support-Anfragen. Bei Stripe Checkout läuft das automatisch — bei Custom-Implementierungen müssen Sie es selbst bauen. Die Bestätigungs-Mail sollte gleichzeitig den PDF-Beleg enthalten, nicht nur einen Download-Link, der in drei Monaten 404t.

Für Rechnungen sind in der EU bestimmte Pflichtangaben gesetzlich vorgeschrieben (UStG §14 in DE): vollständige Adressen beider Parteien, Steuernummer/USt-IdNr., Rechnungsdatum, fortlaufende Nummer, Leistungsbeschreibung, Netto/USt/Brutto. Stripe Invoices können das automatisch generieren, wenn die Daten korrekt erfasst sind. Bei Eigenbau lohnt sich eine Tax-Engine wie Stripe Tax oder Quaderno — die Mehrwertsteuer-Logik (B2C, B2B mit Reverse-Charge, OSS für EU) ist nicht trivial.

Zahlungsdaten gehören zu den sensibelsten personenbezogenen Daten. Kreditkartennummern direkt zu speichern, ist außer für PCI-DSS-zertifizierte Anbieter rechtlich nicht zulässig — und auch praktisch eine Katastrophe (Haftung bei Datenleck). Die Lösung ist Tokenisierung: Stripe (oder vergleichbare Anbieter) hält die Karte, Sie speichern nur einen Token.

Für die DSGVO bedeutet das: Stripe ist Auftragsverarbeiter, ein AVV (DPA) ist Pflicht — Stripe stellt einen Standard-Vertrag bereit. Für die Datenschutzerklärung müssen Sie Stripe als Empfänger nennen, den Drittlandtransfer (USA) kennzeichnen und sich auf die EU-Standardvertragsklauseln stützen. Stripe ist über die EU-US Data Privacy Framework zertifiziert, was den Transfer rechtlich absichert.

Für Ihr eigenes Formular gilt: Speichern Sie nie die Kartennummer, das CVC oder das Ablaufdatum in Ihrer Datenbank — nicht einmal verschlüsselt. Stripe Elements (oder Checkout) tokenisiert direkt im Browser, Ihre Server sehen die Daten nie. Ein Hidden Field für die Stripe-Customer-ID reicht für die spätere Verknüpfung. Speicherdauer: Transaktions-IDs und Belege müssen Sie nach HGB/AO 10 Jahre aufheben — das ist eine eigene gesetzliche Pflicht und überschreibt die "so kurz wie möglich"-Regel der DSGVO.

Zahlungen scheitern aus vielen Gründen: gesperrte Karte, Limit überschritten, Bank-Decline, Tippfehler, abgebrochene 3D-Secure-Bestätigung. Eine generische Fehlermeldung "Zahlung fehlgeschlagen" ist Conversion-Killer — der Kunde weiß nicht, ob er es nochmal probieren soll oder eine andere Karte braucht.

Die Stripe-API liefert pro Fehler einen "decline_code" mit klarer Bedeutung (insufficient_funds, expired_card, do_not_honor). Mappen Sie diese auf konkrete Handlungs-Anweisungen: bei "insufficient_funds" — "Ihre Karte hat das Limit erreicht. Bitte versuchen Sie es mit einer anderen Karte". Bei "do_not_honor" — "Ihre Bank hat die Zahlung abgelehnt. Bitte kontaktieren Sie Ihre Bank oder verwenden Sie eine andere Zahlungsmethode". Generic-Catch-all sollte nur die letzte Stufe sein.

Für Retry-Logik gilt: Bei sofortigen Decline-Fehlern (insufficient_funds, expired_card) lohnt sich kein automatischer Retry — der scheitert wieder. Bei temporären Fehlern (processing_error, bank_offline) kann ein Retry nach 30 Sekunden sinnvoll sein. Für Recurring-Charges baut Stripe das automatisch ein (Smart Retries), bei Einmal-Charges müssen Sie es selbst implementieren oder dem Kunden den Knopf "Erneut versuchen" anbieten. Webhook-Logging jeder Fehlschlag-Stufe hilft später, Muster zu erkennen — etwa eine plötzliche Häufung von Decline-Codes aus einer bestimmten Bank.