Von zwei Stripe-Konten zu einer überprüfbaren Abrechnungsübergabe

Nicht jeder SaaS-Verkauf braucht eine Abonnementmigration. Gehört das bestehende Stripe-Konto vollständig zum verkauften Unternehmen und darf es mit derselben oder einer von Stripe akzeptierten Struktur fortgeführt werden, kann eine Änderung der Kontoinhaberschaft der einfachere Weg sein. Wenn der Verkäufer weitere Geschäftsbereiche im Konto behält, der Käufer sein eigenes Konto benötigt oder Rechtsträger und Land wechseln, ist meist eine getrennte Migration zu prüfen. Die Entscheidung sollte Stripe für das konkrete Kontopaar bestätigen.

Dokumentiert vor Projektbeginn Quellkonto, Zielkonto, Rechtsträger, Länder, Verantwortliche und den genauen Umfang. Eine bloße Einladung des Käufers ins Dashboard ändert nicht automatisch wirtschaftlich Berechtigte, Bankverbindung, Steuerdaten oder Vertragspartner. Ohne diese Klarheit kann ein technisch sauberer Lauf die falsche Kontostruktur herstellen.

Stripe Customer Data Copy kann berechtigte Customer-Datensätze und unterstützte gespeicherte Zahlungsmethoden zwischen Konten kopieren. Stripe beschreibt diesen Vorgang ausdrücklich als Kopie: Die Quelldaten bleiben im alten Konto. Abonnements, Rechnungen, Pläne, Gutscheine, Ereignisse und Protokolle werden dabei nicht kopiert. Nach dem Vorgang muss deshalb geprüft werden, welche Zielkunden und Standardzahlungsarten tatsächlich nutzbar sind.

Trennt die Population in automatisch vorbereitete Fälle und Ausnahmen. Nicht unterstützte Zahlungsmethoden, Gastkunden, fehlende Standardzahlungsarten oder unklare Zuordnungen benötigen einen eigenen Weg. MoveMRR erhält keine rohen Kartendaten und ersetzt den Stripe-Prozess nicht. Erst wenn die tatsächliche Kopierabdeckung bekannt ist, lässt sich die Abonnementmigration belastbar planen.

Für Quell- und Zielkonto werden unterschiedliche Rechte benötigt. Das Quellkonto muss den relevanten Bestand lesen können; eine gewählte Deaktivierung kann begrenzte Schreibrechte erfordern. Das Zielkonto braucht die Rechte, um die vorgesehenen Kunden-, Katalog- oder Abonnementaktionen auszuführen. Verwendet keine allgemeinen Live-Geheimschlüssel, wenn zweckgebundene eingeschränkte Schlüssel ausreichen.

MoveMRR prüft die erforderlichen Berechtigungen vor dem Lauf. Gespeicherte Live-Schlüssel liegen geschützt in Supabase Vault, werden nach der Speicherung nicht an den Browser zurückgegeben und laufen in MoveMRR nach 30 Tagen ab. Nach Abschluss und vereinbarter Nachbeobachtung sollten die Migrationsschlüssel in Stripe widerrufen werden. Die Produktanwendung des Käufers verwendet eigene Schlüssel; ein Migrationsschlüssel ist kein dauerhafter Anwendungsschlüssel.

Produkte, Prices, Coupons, Steuerobjekte und weitere Kontoeinstellungen sind kontospezifisch. Erstellt eine eindeutige Quell-zu-Ziel-Zuordnung und prüft nicht nur Namen, sondern Währung, Betrag, Intervall, Nutzungsart, Menge, Steuerverhalten und Archivstatus. Historische oder kundenspezifische Preise dürfen nicht stillschweigend auf ein ähnliches Standardangebot fallen.

Für jedes Abonnement gehören Abrechnungsanker, nächste erwartete Rechnung, Testphase, Einzugsmethode, mehrere Positionen, Metadaten und Status in die Prüfung. Der Zielzustand soll wirtschaftlich und technisch beabsichtigt sein, nicht lediglich syntaktisch gültig. Änderungen am Quellbestand während der Vorbereitung werden über eine klare Änderungs- oder Einfrierregel erfasst.

Eine realistische Sandbox-Probe sollte einfache Monatsabos ebenso enthalten wie Jahresabos, aktive Tests, mehrere Positionen, Rabatte, ungewöhnliche Anker und fehlerhafte Zahlungen. Sandbox- und Live-Kennungen sind getrennt; ein erfolgreicher Test mit Test-IDs beweist nicht, dass Live-Zuordnungen stimmen. Prüft Mengen, Abrechnungsdaten, geplante Aktionen und alle Warnungen.

Der MoveMRR-Probelauf schreibt keine neuen Live-Abonnements. Er macht bekannte Lücken und geplante Folgen sichtbar. Käufer und Verkäufer sollten das Ergebnis gemeinsam freigeben und für jede Ausnahme einen Verantwortlichen benennen. Ein Probelauf kann spätere Bankablehnungen oder SCA nicht vorhersagen, verringert aber vermeidbare Konfigurationsfehler.

Während des finalen Umstellungsfensters sollten neue Abschlüsse, Planwechsel und Kündigungen entweder kurz kontrolliert oder als Delta protokolliert werden. Zielabonnements werden erstellt oder terminiert und anschließend unabhängig gegen die erwarteten Beträge, Daten, Testphasen, Zahlungsarten und Status geprüft. Erst danach folgt die gewählte Deaktivierung im Quellkonto, bevor beide Konten denselben Zeitraum abrechnen können.

Ein aktiver Zielstatus allein genügt nicht. Prüft offene und entworfene Rechnungen in beiden Konten, anstehende Rechnungspositionen, Nutzung, Rabatte und den nächsten tatsächlichen Zahlungstermin. Wiederholbare Ausführung schützt vor versehentlichen Doppelanlagen, ersetzt jedoch nicht die fachliche Abstimmung, ob die ursprünglichen Parameter richtig waren.

Neue Abonnements besitzen neue Stripe-Kennungen. Der Käufer muss die alte-zu-neu-Zuordnung in der Anwendungsdatenbank anwenden, Zielschlüssel sicher ausrollen, Webhook-Endpunkte samt Signaturgeheimnissen einrichten und Kundenportal, Mahnwesen, Berichte sowie Berechtigungslogik prüfen. Webhook-Ereignisse können verzögert oder in anderer Reihenfolge eintreffen; die Anwendung sollte den aktuellen Objektzustand bei Stripe nachladen können.

Nach dem Wechsel werden Quell- und Zielmenge, Einzelergebnisse und Ausnahmen abgestimmt. Beobachtet die ersten Erneuerungskohorten auf fehlgeschlagene Zahlungen, Authentifizierungsanforderungen und Quellüberschneidungen. Bewahrt den notwendigen Zugriff auf historische Rechnungen, Streitfälle, Ereignisse und Steuerunterlagen nach dem vereinbarten Aufbewahrungsplan. Erst wenn offene Ausnahmen einen Eigentümer haben, ist die Übergabe operativ abgeschlossen.