Stripe-Abonnements ohne Kundenaktion migrieren

Direkte Antwort: Bei vielen Stripe-zu-Stripe-Migrationen können berechtigte Kunden- und gespeicherte Zahlungsmethodendaten im Hintergrund kopiert werden. Kunden müssen dann während des Cutovers weder ein neues Konto anlegen noch eine Karte erneut eingeben. Das ist keine universelle Garantie: nicht unterstützte Zahlungsmethoden, fehlende Standards, Ablehnungen durch die Bank und Strong Customer Authentication können einzelne Kunden weiterhin zum Handeln zwingen.

Das korrekte Ziel lautet deshalb, Kundenaktion zu minimieren und einen Nachbearbeitungsweg vorzubereiten – nicht zu versprechen, dass niemals eine Authentifizierung erforderlich wird.

Was Stripe im Hintergrund kopieren kann

Stripes aktuelle Dokumentation zur Kontodatenkopie nennt folgende unterstützte Daten:

• Name, E-Mail, Telefon, Adresse, Standard-Zahlungsmethode und Metadaten des Kunden;
• Karten als Card-, Source- oder PaymentMethod-Objekte;
• ACH-Bankkonten als Bankkonto- oder PaymentMethod-Objekte;
• SEPA-PaymentMethod-Objekte.

Laut Stripe behalten kopierte Customers ihre Customer-IDs, während sich Zahlungsmethoden-IDs ändern. Kunden werden über diese Hintergrundkopie nicht informiert.

Nicht kopiert werden unter anderem Charges, Invoices, Plans, Subscriptions, Coupons, Events, Logs, SEPA-Source-Objekte, Bacs-PaymentMethods, verbundene Konten und Gastkunden. Das Quellkonto behält seine Daten, weil kopiert und nicht verschoben wird.

Primärquelle: Stripe: Daten, die zwischen Konten kopiert werden können.

Entscheidungstabelle zur Kundenaktion

Bedingung	Wahrscheinliche Cutover-Erfahrung	Erforderliche Vorbereitung
Unterstützte Karte oder Bank-PaymentMethod wird kopiert und bleibt Standard	Keine Neuanmeldung oder erneute Zahlungseingabe während der Migration	Vor Terminierung prüfen, ob der Ziel-Customer den beabsichtigten Standard besitzt
Ziel-Customer hat kopierte Methoden, aber keinen gültigen Standard	Künftige automatische Einzüge können fehlschlagen	Den richtigen Standard nur wählen, wenn Einwilligung oder bisheriges Zahlungsverhalten dies trägt
SEPA ist als ältere Source gespeichert	Stripe dokumentiert, dass diese nicht kopiert wird	Unterstütztes Mandat beschaffen oder Kundenansprache planen
Bacs-PaymentMethod	Stripe dokumentiert, dass sie nicht zwischen Konten kopiert wird	Eigenen Bacs-Nachbearbeitungsplan erstellen
Bank akzeptiert die Ausnahme für wiederkehrende Off-Session-Zahlungen	Verlängerung kann ohne Authentifizierungssitzung erfolgen	Payment- und Invoice-Webhooks überwachen
Bank lehnt die Ausnahme ab oder fordert 3DS	Kundenaktion ist erforderlich	Gehosteten Authentifizierungsablauf senden und Abschluss verfolgen
Karte ist abgelaufen, ersetzt oder abgelehnt	Kunde muss Zahlungsdaten aktualisieren	Mahnwesen und Kommunikation zur Zahlungsaktualisierung im Ziel verwenden

„Wahrscheinlich“ ist bewusst gewählt: Bank und Zahlungsnetzwerk entscheiden an der finalen Autorisierung mit.

Warum SCA ein absolutes Versprechen verhindert

Für wiederkehrende Off-Session-Kartenzahlungen kann Stripe eine Merchant-Initiated-Transaction-Ausnahme anfordern, wenn die Zahlungsmethode korrekt eingerichtet wurde. Die ausstellende Bank entscheidet, ob sie diese Ausnahme akzeptiert. Bei Ablehnung muss der Kunde on-session zurückkehren und authentifizieren.

Deine Anwendung muss deshalb Folgendes behandeln:

• invoice.payment_action_required behandeln;
• invoice.payment_failed behandeln;
• PaymentIntents mit requires_action oder requires_payment_method behandeln;
• eine sichere Seite des Zielkontos bereitstellen, auf der Kunden authentifizieren oder die Methode ersetzen können.

Primärquellen:

• Stripe: Zahlungsmethoden für Abonnements nach SCA speichern
• Stripe: Webhooks mit Abonnements verwenden

Voraussetzungen für eine reibungsarme Migration

Führe diese Prüfungen vor dem Neuerstellen der Abonnements durch:

1. Zahlungsmethoden klassifizieren: unterstützte kopierte Methoden getrennt von Bacs, älteren SEPA Sources, fehlenden Methoden und abgelaufenen Karten zählen.
2. Standards im Ziel prüfen: Stripes Billing Migration Toolkit benötigt für automatische Einzüge eine Standard-Zahlungsmethode.
3. Berechtigung für wiederkehrende Zahlungen bestätigen: Einwilligungsnachweise des Verkäufers aufbewahren und rechtlich prüfen, ob sich Händler oder Bedingungen ändern.
4. Darstellung abstimmen: Statement Descriptor, Support-E-Mail, Beleg-Branding und Customer Portal des Ziels vorbereiten.
5. Wiederherstellung konfigurieren: Ziel-Mahnwesen, E-Mails bei fehlgeschlagenen Zahlungen und Authentifizierungsweg vor der ersten Verlängerung einrichten.
6. Repräsentative Fälle proben: normale Karte, fehlender Standard, Testphase, fehlgeschlagene Zahlung und jede relevante Bankmethode testen.

MoveMRR kann Probleme mit Zahlungsmethoden und Zuordnungen sichtbar machen; Käufer bleiben für rechtliche Einwilligung, Stripe-Einstellungen im Ziel und Kundenkommunikation verantwortlich.

Cutover-Sequenz

Für berechtigte Kunden folgt ein kontrollierter Ablauf dieser Reihenfolge:

1. Stripes Kopie der Kunden- und Zahlungsdaten abschließen;
2. kopierte Customer-Population und Standard-Zahlungsmethoden abgleichen;
3. Quell-Prices und Abo-Konfiguration den Zielobjekten zuordnen;
4. Dry Run ausführen und automatische Fälle von manueller Nachbearbeitung trennen;
5. Ziel-Abonnements zum vereinbarten künftigen Abrechnungstermin erstellen;
6. gewählte Strategie zur Quell-Deaktivierung anwenden;
7. erste Verlängerungsgruppen und Action-required-Ereignisse überwachen;
8. nur Kunden kontaktieren, die Nachbearbeitung benötigen.

So muss nicht jeder Kunde seine Karte allein deshalb aktualisieren, weil sich das Stripe-Konto ändert.

Was du Kunden mitteilen solltest

Ob alle Kunden informiert werden, ist eine geschäftliche und rechtliche Entscheidung. Auch ohne erwartete Aktion kann eine proaktive Mitteilung Streitfälle reduzieren, wenn Händlername oder Statement Descriptor wechseln.

Eine präzise Nachricht erklärt:

• Service und Verlängerungsrhythmus bleiben gleich;
• Abrechnungsgesellschaft oder Statement Descriptor ändern sich;
• die meisten Kunden müssen nichts tun;
• Stripe oder das Unternehmen kann einzelne Kunden kontaktieren, wenn die Bank eine Authentifizierung oder neue Zahlungsmethode verlangt;
• wo eine legitime Aufforderung zur Zahlungsaktualisierung überprüft werden kann.

Vermeide Aussagen wie „Deine Karte wird garantiert funktionieren“ oder „Du musst dich niemals erneut autorisieren“.

Was MoveMRR tut und nicht tut

MoveMRR koordiniert die Abo-Seite der Übergabe: Readiness-Prüfungen, Zuordnungen, Dry Runs, Zielerstellung, konfigurierbare Quell-Deaktivierung, Abgleich und ID-Exporte. Stripe kopiert berechtigte Zahlungsdaten; MoveMRR erhält keine rohen Kartennummern.

MoveMRR kann Folgendes nicht außer Kraft setzen:

• Stripes Berechtigung zur Kontodatenkopie;
• Autorisierungsentscheidungen von Banken;
• SCA- oder Zahlungsnetzwerkregeln;
• fehlende Kundeneinwilligung;
• nicht unterstützte Zahlungsmethoden;
• unvollständiges Mahnwesen oder eine fehlende Authentifizierungsintegration des Käufers.

Passende Anleitungen

• Funktionen und Grenzen von Stripe Customer Data Copy
• Stripe Billing Migration Toolkit vs. MoveMRR
• Doppelbelastungen während der Migration verhindern
• Application-Übergabe nach einer Stripe-Migration
• Technische Migrationsanleitung