Neue Zielabonnements funktionieren erst, wenn die Anwendung das Zielkonto versteht

Ein Zielabonnement erhält eine neue sub-Kennung. Auch Payment Methods, Products, Prices, Coupons, Steuerobjekte, Webhook-Endpunkte und Schlüssel sind kontospezifisch. Stripe gibt für Customer Data Copy derzeit an, dass kopierte Customer-Kennungen gleich bleiben können; verwende dennoch das tatsächliche Kopierergebnis statt einer pauschalen Annahme. Jede lokale Referenz auf ein Stripe-Objekt gehört in das Übergabeinventar.

Suche nicht nur in der Hauptdatenbank. Hintergrundaufgaben, Analysepipelines, Supportoberflächen, Rechnungsabgleiche, CRM-Synchronisationen, Datenlager, interne Skripte und Alarmregeln können alte Kennungen oder das alte Konto verwenden. Ebenso wichtig sind Dashboard-Einstellungen wie Belegtexte, Mahnlogik, Rechnungsversand und Kundenportal, die nicht durch Abo-Neuanlage automatisch übernommen werden.

Dokumentiere für jeden Produktzugang, welche Stripe-Zustände ihn öffnen, einschränken oder schließen. Manche Anwendungen lesen nur subscription.status, andere verknüpfen Customer, Price, Rechnungen oder PaymentIntent. Schreibe auf, welche Ereignisse verarbeitet werden und wie die Anwendung bei verspäteten oder fehlenden Webhooks den aktuellen Zustand nachlädt. Diese Abhängigkeiten bestimmen die erforderlichen Tests.

Ordne jeder Komponente einen Eigentümer und eine Abnahme zu. Der Billing-Verantwortliche kann bestätigen, dass das Zielabonnement richtig konfiguriert ist; nur das Anwendungsteam kann bestätigen, dass der richtige Nutzer die richtige Leistung erhält. Support und Finance prüfen wiederum Portal, Belege, Mahnwesen und Berichtsergebnisse.

Die Zuordnung enthält mindestens Quell- und Ziel-Customer, Quell- und Ziel-Subscription sowie die relevanten Produkt- und Price-Bezüge. Ergänze Run-Kennung, Ergebnisstatus, Zeitstempel und Ausnahmegrund. Verwende keine Zuordnung nur anhand von E-Mail-Adressen: Adressen können fehlen, sich ändern oder bei mehreren Customers vorkommen. Die Migrationsausgabe und die bestätigte Customer-Data-Copy-Zuordnung sind die belastbareren Grundlagen.

Spiele die Zuordnung idempotent ein. Eine Wiederholung mit derselben Quellkennung darf nicht eine zweite Zielverknüpfung erzeugen. Bewahre den bisherigen Wert nachvollziehbar auf, statt ihn ohne Historie zu überschreiben. Führe vor und nach dem Import Mengen-, Eindeutigkeits- und Fremdschlüsselprüfungen aus und stoppe bei Mehrdeutigkeiten.

Erstelle für die laufende Anwendung eigene Zielschlüssel nach dem Prinzip geringstmöglicher Rechte. Migrationsschlüssel sind zeitlich begrenzte Arbeitszugänge und gehören nicht in den dauerhaften Produktionsbetrieb. Lege Zielgeheimnisse im vorgesehenen Secret Store ab, beschränke Zugriffe und rotiere Quellgeheimnisse nach dem vereinbarten Parallel- und Rückfallfenster.

Die Ausspielung sollte versionsfähig sein: Konfiguration bereitstellen, Verbindung zum erwarteten Zielkonto prüfen, abhängige Dienste neu starten und den Kontokontext in Gesundheitsprüfungen sichtbar machen. Protokolliere keine Schlüsselwerte. Wenn mehrere Dienste getrennt ausgerollt werden, verhindere einen Mischzustand, in dem ein Dienst Zielkennungen schreibt und ein anderer weiterhin in der Quelle liest.

Webhook-Endpunkte und ihre Signaturgeheimnisse gehören zum jeweiligen Konto. Richte im Ziel nur die tatsächlich benötigten Ereignisse ein, speichere das neue Signaturgeheimnis sicher und prüfe Signaturen mit dem unveränderten Roh-Request. Teste erfolgreiche Zustellung, Wiederholung, Duplikate, verspätete Ereignisse und Fehlerantworten. Aktiviere Quell- und Zielbeobachtung während des festgelegten Übergangs.

Stripe garantiert keine Ereignisreihenfolge. Die Anwendung darf deshalb nicht voraussetzen, dass ein einzelnes Ereignis immer vor einem anderen eintrifft. Nutze Ereigniskennungen gegen doppelte Verarbeitung und rufe bei unvollständigem Zustand das aktuelle Stripe-Objekt im richtigen Konto ab. Ein empfangener Webhook ist ein Signal, kein alleiniger Abstimmungsnachweis.

Vor T0 teste repräsentative Nutzer: aktives Monatsabo, Jahresabo, Testphase, überfällig, gekündigt zum Periodenende und mehrere Positionen. Vergleiche den Produktzugang vor und nach Einspielen der neuen Kennung. Definiere, wie sich die Anwendung verhält, wenn Quelle und Ziel kurzzeitig unterschiedliche Zustände melden oder ein Zielereignis verspätet ist.

Vermeide eine pauschale Freischaltung als Notlösung. Eine begrenzte, protokollierte Schonfrist kann Teil eines freigegebenen Plans sein, muss aber Missbrauch, Ablauf und Rücknahme berücksichtigen. Support braucht eine Möglichkeit, Quell- und Zielkennung sowie Migrationsstatus zu sehen, ohne geheime Zahlungsdaten offenzulegen.

Vergleiche für jeden Datensatz erwartete und tatsächliche Zielkonfiguration, lokale Kennungszuordnung und Produktzugang. Prüfe zusätzlich offene und entworfene Rechnungen in beiden Konten. Die Quell-Deaktivierung folgt erst nach der definierten Zielprüfung und muss vor einer überlappenden Belastung liegen. Ein bloßes Zählen aktiver Subscriptions reicht nicht.

Beobachte die ersten Zielverlängerungen auf Zahlungserfolg, Ablehnung, SCA, Mahnwesen, Ereignisverarbeitung und Berechtigung. Halte notwendige Quellhistorie für Rechnungen, Erstattungen, Streitfälle, Ereignisse und Steuern zugänglich. Widerrufe Migrationszugänge erst nach der vereinbarten Stabilisierung, dokumentiere Ausnahmen und übergib ihre Verantwortung in den Normalbetrieb.

Kein allgemeines Runbook kennt die interne Architektur eines SaaS. Eigene Entitlement-Modelle, Datenreplikation, Connect, mehrere Währungen oder individuelle Rechnungslogik können zusätzliche Schritte erfordern. Eine Probe kann bekannte Abhängigkeiten prüfen, aber keine unbekannte versteckte Referenz garantieren.

MoveMRR liefert Kennungszuordnungen, Laufdaten und optional unterstützte Webhook-Neuanlage. Es deployt nicht automatisch den Anwendungscode des Käufers und entscheidet nicht über dessen Zugriffsmodell. Die technische Freigabe bleibt beim zuständigen Team.