SCA und 3D Secure bei Abo-Verlängerungen: Umgang mit authentication_required

Die meisten fehlgeschlagenen Verlängerungen haben mit Geld oder Karten zu tun: nicht genug Deckung, eine abgelaufene Karte, eine Sperre bei der Bank. Eine Art ist anders. Die Karte ist in Ordnung und das Geld ist da, aber die Bank möchte, dass der Kunde die Zahlung bestätigt. Bei Stripe zeigt sich das als Ablehnungscode authentication_required oder als Rechnung, die auf eine Aktion des Kunden wartet.

Kein noch so häufiger erneuter Versuch behebt das. Der Kunde muss zurückkommen und die Zahlung freigeben. Dieser Ratgeber erklärt, warum das passiert, was Stripe für Sie übernimmt und wie Sie den Kunden schnell durch den Vorgang bringen. Er stützt sich auf Stripes Dokumentation und die zugrunde liegenden EU-Regeln (Quellen abgerufen im November 2026).

Dies ist keine Rechtsberatung. Die Regulierung von Zahlungen ist komplex; prüfen Sie Ihr Setup mit Stripe und, wo nötig, mit einem Spezialisten.

Warum Verlängerungen überhaupt eine Authentifizierung brauchen

Starke Kundenauthentifizierung in Kürze

Die starke Kundenauthentifizierung (SCA) stammt aus der zweiten EU-Zahlungsdiensterichtlinie (PSD2). Sie verlangt, dass Zahler elektronische Zahlungen mit zwei von drei Faktoren authentifizieren: etwas, das sie wissen, etwas, das sie besitzen, etwas, das sie sind. Bei Karten geschieht das online meist über 3D Secure, wobei die Bank einen Bestätigungsschritt zeigt (ein Code, eine Freigabe in der App, ein Fingerabdruck).

Laut Stripes SCA-Leitfaden und Hilfecenter gilt SCA, wenn sowohl der Zahlungsanbieter des Unternehmens als auch die Bank des Karteninhabers im Europäischen Wirtschaftsraum sind. Stripes Seite zu Ausnahmen deckt auch das Vereinigte Königreich und die Schweiz ab. Zahlungen, bei denen eine Seite außerhalb der Region liegt („one leg out“), fallen nicht darunter, auch wenn Banken trotzdem eine Authentifizierung verlangen können.

Wiederkehrende Zahlungen und vom Händler ausgelöste Transaktionen

Eine Abo-Verlängerung geschieht, wenn der Kunde nicht anwesend ist. Die Regeln berücksichtigen das:

• Die technischen Standards der EU, die Delegierte Verordnung (EU) 2018/389 der Kommission, verlangen SCA, wenn ein Zahler eine Serie wiederkehrender Transaktionen mit gleichem Betrag und gleichem Zahlungsempfänger einrichtet, ändert oder erstmals auslöst. Spätere Zahlungen der Serie können ausgenommen sein (Artikel 14).
• Kartenzahlungen, die der Händler auf Grundlage einer Vereinbarung mit dem Kunden auslöst, gelten als vom Händler ausgelöste Transaktionen (MITs). Stripes Seite zu Ausnahmen erklärt, dass die Karte beim Speichern authentifiziert werden sollte und dass Sie die Zustimmung des Kunden (ein Mandat) brauchen, um sie später zu belasten. Eine Zahlung als MIT zu kennzeichnen funktioniert ähnlich wie das Beantragen einer Ausnahme.

Im Prinzip deckt also eine Authentifizierung bei der Anmeldung künftige Verlängerungen ab.

Warum es trotzdem scheitert

In der Praxis hat die kartenausgebende Bank das letzte Wort. Sie kann eine Ausnahme oder ein MIT ablehnen und trotzdem eine Authentifizierung verlangen. Häufige Situationen sind ein geänderter Betrag (ein Upgrade, eine Preiserhöhung, Nutzungsgebühren), eine ohne Authentifizierung gespeicherte Karte oder schlicht die eigene Risikobewertung der Bank. Geschieht das bei einer Verlängerung off-session, ist niemand da, um 3D Secure abzuschließen, und die Zahlung schlägt fehl.

Stripes Support-Artikel zu Ablehnungen mit authentication_required ergänzt einen Sonderfall: Banken geben authentication_required manchmal sogar bei Zahlungen zurück, die 3D Secure bereits durchlaufen haben. In diesem Fall muss der Kunde seine Bank kontaktieren.

Was Stripe bei Abos übernimmt

Wenn Sie Stripe Billing nutzen, übernimmt Stripe den größten Teil der Mechanik:

• Verlängerungen werden automatisch als off-session markiert. Stripes Artikel zu on-session und off-session sagt, dass dieses Flag bei Billing-Verlängerungen für Sie gesetzt wird.
• Gespeicherte Karten werden zu MITs. Laut Stripes Seite zur SCA-Bereitschaft werden spätere Off-Session-Zahlungen als vom Händler ausgelöst gekennzeichnet, wenn eine Karte über die Payment Intents oder Setup Intents APIs gespeichert wird.
• Die Rechnung sagt Ihnen, wann eine Aktion nötig ist. Stripe sendet das Event invoice.payment_action_required, wenn eine Rechnungszahlung eine weitere Aktion des Kunden erfordert. Stripes Leitfaden zu Abo-Webhooks sagt, dass Ihre App den Kunden dann benachrichtigen muss.
• Die gehostete Rechnungsseite übernimmt 3D Secure. Die gehostete Rechnungsseite kann den Authentifizierungsablauf ohne zusätzlichen Aufwand auf Ihrer Seite ausführen.
• Stripe kann die E-Mail senden. In den Einstellungen für Kunden-E-Mails können Sie Stripe einen Link senden lassen, mit dem Kunden Zahlungen bestätigen, wenn ihre Bank es verlangt.

Zu Wiederholungen: Stripes Seite zu Smart Retries führt authentication_required unter den Hard-Decline-Codes: Stripe versucht es ohne Aktion des Kunden nicht automatisch erneut.

Die zwei Formen, in denen es auftritt

Signal	Was es bedeutet	Was zu tun ist
invoice.payment_action_required, PaymentIntent in requires_action	Die Bank will 3D Secure für diese Zahlung	Dem Kunden den Link zur gehosteten Rechnung (oder Ihre eigene Seite) zum Bestätigen senden
Ablehnungscode authentication_required bei invoice.payment_failed	Die Bank hat abgelehnt und eine Authentifizierung verlangt	Dasselbe: Den Kunden on-session zurückholen, um zu bestätigen oder die Karte neu einzugeben

Stripes Support-Artikel zu SCA-Fehlschlägen off-session weist darauf hin, dass ein fehlgeschlagener Off-Session-PaymentIntent in requires_payment_method statt in requires_action landen kann. Wenn Sie Ihre eigene Bestätigungsseite bauen, behandeln Sie beide Zustände: Bestätigen Sie entweder die bestehende Zahlungsmethode mit 3D Secure oder erfassen Sie erneut eine Zahlungsmethode.

Den Kunden zur Bestätigung bringen

Der Kunde hat nichts falsch gemacht, und oft weiß er nicht, was „Authentifizierung“ bedeutet. Die Nachricht sollte kurz, ruhig und konkret sein.

Was in der E-Mail stehen sollte

• Betreff: „Bitte bestätigen Sie Ihre Zahlung für [Produkt]“
• Warum: „Ihre Bank bittet Sie, diese Zahlung zu bestätigen. Das ist eine übliche Sicherheitsprüfung, kein Problem mit Ihrer Karte.“
• Was: der Betrag, der Plan, das Datum.
• Wie: ein Button, „Zahlung bestätigen“, der direkt zur Bestätigungsseite führt.
• Wann: „Ihr Abo bleibt aktiv, während Sie bestätigen. Wenn wir bis [Datum] nicht bestätigen können, wird es pausiert.“

Vermeiden Sie „Ihre Zahlung ist fehlgeschlagen“ im Betreff. Das stimmt nicht ganz und lässt Kunden glauben, sie bräuchten eine neue Karte.

Timing

Senden Sie die erste Nachricht, sobald das Event eintrifft. Anders als bei Soft Declines hilft Warten nicht: Die Bank ändert ihre Meinung nicht von selbst. Eine kurze Nachfass-Mail nach zwei oder drei Tagen und dann eine letzte Mitteilung vor dem Ende Ihrer Kulanzfrist reichen. Unsere Vorlagen für Mahnmails enthalten eine Variante für die Authentifizierung.

Die Bestätigungsseite

• Funktioniert auf dem Handy ohne Anmeldung (ein signierter Link).
• Zeigt Betrag und Produkt vor dem Schritt der Bank.
• Öffnet den 3D-Secure-Schritt der Bank direkt.
• Bietet „andere Karte verwenden“ als Ausweichlösung, für Kunden, deren Bank immer wieder ablehnt.
• Bestätigt den Erfolg klar und stoppt alle weiteren E-Mails bei invoice.paid.

Fehlgeschlagene Authentifizierungen verringern

Ganz beseitigen können Sie sie nicht, denn die Bank entscheidet. Seltener machen können Sie sie.

1. Beim Speichern der Karte authentifizieren

Erfassen Sie die Karte mit einem SetupIntent (oder dem ersten PaymentIntent) und setup_future_usage für Off-Session-Nutzung, sodass die Karte mit bestehendem Mandat authentifiziert wird. Stripes Dokumentation zu SetupIntents behandelt das. Stripe Checkout und das Payment Element erledigen das bei der Abo-Anmeldung für Sie.

2. Bei einer Änderung des Vertrags neu erfassen

Upgrades, Preisänderungen und neue Add-ons ändern den Betrag. Lassen Sie den Kunden die Änderung nach Möglichkeit bestätigen, während er in Ihrer App ist, damit eine Authentifizierung on-session stattfindet statt um 3 Uhr morgens am Verlängerungstag.

3. Vorsicht bei kostenlosen Testphasen

Beginnt eine Testphase ohne Belastung, stellen Sie sicher, dass die Karte trotzdem über einen SetupIntent mit Authentifizierung gespeichert wird. Sonst ist die erste echte Belastung nach der Testphase das erste Mal, dass die Bank das Mandat sieht. Testphasen behandeln wir in Umwandlung von Testphasen in zahlende Kunden.

4. Indien gesondert behandeln

Indien hat eigene Regeln für wiederkehrende Zahlungen. Stripes Seite zu wiederkehrenden Zahlungen in Indien erklärt, dass Karten ein E-Mandat brauchen, das mit zusätzlicher Faktorauthentifizierung registriert wird, dass Kunden mindestens 24 Stunden vor jeder Belastung eine Vorabbenachrichtigung erhalten und dass wiederkehrende Belastungen über 15.000 INR jedes Mal eine Authentifizierung brauchen. Wenn Sie Kunden in Indien haben, lesen Sie diese Seite; dort funktioniert es anders als bei SCA.

Messen

Erfassen Sie Authentifizierungen getrennt von anderen Fehlschlägen. Sie verhalten sich anders und haben eine eigene Lösung.

• Authentifizierungsanfragen pro Monat, nach Land der Karte.
• Bestätigungsquote: Rechnungen mit Authentifizierungsanfrage, die innerhalb Ihrer Kulanzfrist bezahlt wurden.
• Zeit bis zur Bestätigung: vom Event bis invoice.paid.
• Ausweichquote: Kunden, die stattdessen durch einen Wechsel auf eine neue Karte bestätigt haben.

Ist die Bestätigungsquote niedrig, sehen Sie sich zuerst die E-Mail an (Betreff, Klarheit, ein einziger Button), dann die Seite auf dem Handy.

Checkliste

• Karten werden bei der Anmeldung mit Authentifizierung für Off-Session-Nutzung gespeichert.
• invoice.payment_action_required und authentication_required lösen beide eine Bestätigungs-E-Mail aus.
• Stripes E-Mails „Zahlung bestätigen“ sind aktiv, oder Ihre eigenen E-Mails ersetzen sie (nicht beides).
• Die Bestätigungsseite funktioniert auf dem Handy ohne Passwort.
• Preisänderungen und Upgrades werden nach Möglichkeit on-session bestätigt.
• E-Mails stoppen, sobald die Rechnung bezahlt ist.
• Authentifizierung wird als eigene Kategorie ausgewiesen.
• Kunden in Indien werden nach den E-Mandat-Regeln behandelt.

Wie NoChurn hilft

NoChurn behandelt Authentifizierungsanfragen als eigenen Fall. Braucht eine Verlängerung eine Bestätigung, überspringt es nutzlose Wiederholungen und sendet eine von der KI geschriebene Mahnmail, vor dem Versand geprüft und in der Sprache des Kunden, die erklärt, dass die Bank eine kurze Bestätigung möchte, mit einem Link zum Bestätigen der Zahlung und einer gehosteten Seite zur Kartenaktualisierung als Ausweichlösung. Kartendaten bleiben bei Stripe.

Es verbindet sich mit einem Klick mit Stripe oder funktioniert per API mit Ihrer eigenen Abrechnung. Der Preis hängt nur vom MRR ab, nie vom zurückgewonnenen Umsatz. Siehe fehlgeschlagene Zahlungen und Preise.