Eine leere Stripe-Sandbox testet den Ablauf, aber nicht deine tatsächlichen Abo-Formen

Alle vier Umgebungen haben eigene acct-Kennungen. Verlasse dich nicht nur auf Anzeigenamen. Das schwerwiegendste vermeidbare Risiko wäre, die richtige Livequelle zu lesen, aber in die falsche Sandbox zu schreiben. MoveMRR prüft deshalb Modus, Kontokennung und Rechte beider einmaligen Schlüssel, bevor ein Lauf freigegeben wird.

Das Seeding ist nur in einem als Sandbox angelegten MoveMRR-Projekt verfügbar. Testschlüssel in einem Live-Projekt ändern den Projekttyp nicht. Die regulär im Connect-Schritt gespeicherten Quell- und Ziel-Testschlüssel sind von den einmaligen Seeding-Zugängen getrennt.

Du brauchst Administratorzugriff auf beide Livekonten und beide Stripe-Sandboxes, die richtigen gespeicherten Testschlüssel im MoveMRR-Projekt und die für eingeschränkte Schlüssel nötige Zwei-Faktor-Authentifizierung. Während Seeding oder Migration darf kein konkurrierender Lauf aktiv sein. Halte alle vier acct-Kennungen zur Sichtprüfung bereit.

Für jede Seite werden zwei einmalige Zugänge validiert: Ein nur lesender Live-Schlüssel entdeckt Customers, Subscriptions, Products, Prices, Coupons, Promotion Codes und Tax Rates. Ein schreibfähiger Testschlüssel erstellt die ausgewählten Strukturen in der passenden Sandbox. Beide werden für den Lauf geprüft und nach seinem Start als Seeding-Eingaben gelöscht.

Produkte und Prices sind immer ausgewählt, weil andere Objekte von ihnen abhängen. Coupons, Promotion Codes, Subscriptions und Tax Rates sind optional und zunächst ausgewählt. Fingerprints ermöglichen die Wiederverwendung bereits erstellter Objekte. Kontrolliere nach jedem Lauf getrennt Created, Reused, Skipped und Failed; Completed bedeutet nur, dass der Lauf beendet wurde.

Migrationskunden werden nicht über einen Quell- oder Zielschalter erzeugt, sondern im späteren Customer Sync. Reale Kartendaten werden niemals kopiert; Stripe-Testzahlungsmethoden ersetzen sie. Webhook-Endpunkte, kontoweite Stripe-Tax-, Zahlungsarten-, Branding- und Unternehmenskonfiguration werden nicht geseedet. Externe Systeme brauchen eine eigene Testanbindung.

Ein Vorschauwert 100+ ist eine abgeschnittene erste Ergebnisseite und keine exakte Gesamtzahl. Die vollständige Zählung entsteht im Lauf. Stoppe bei falscher Kontokennung, falschem Modus, fehlendem Recht oder unplausibel niedriger Vorschau. Eine abgeschlossene Quell-Ausführung kann übersprungene Datensätze enthalten; untersuche sie, bevor du weitergehst.

Wiederhole denselben Ablauf im Tab Ziel: Ziel-Livekonto nur lesen, Ziel-Sandbox als Testmodus und Schreibziel validieren, Entitäten bewusst auswählen und Ergebnis prüfen. Auch ein Käuferkonto, das später fast leer erscheinen soll, braucht einen abgeschlossenen Ziel-Seeding-Lauf, weil der aktuelle Customer-Sync-Schritt Belege für beide Seiten voraussetzt.

Ein realistisches Ziel ist wertvoll, weil vorhandene Products, Prices, Coupons und Customers Kollisionen und falsche Annahmen sichtbar machen. Übernimm die zu migrierenden Quellkunden nicht direkt per Seeding in die Ziel-Sandbox. Customer Sync übernimmt diese Population und erzeugt dabei die maßgebliche alte-zu-neu-Zuordnung.

Customer Sync verwendet die bereits im Connect-Schritt gespeicherten Sandbox-Schlüssel und fragt keine Live-Schlüssel ab. Voraussetzung sind gespeicherte Quell- und Ziel-Testschlüssel, mindestens ein abgeschlossener Seeding-Lauf pro Seite und kein aktiver Sync. Die Oberfläche nennt jeden fehlenden Blocker ausdrücklich.

Der Lauf findet die Kunden hinter den geseedeten Quellabonnements, verwendet sichere Treffer im Ziel erneut, legt fehlende Testkunden an, fügt Stripe-Testzahlungsmethoden hinzu und erzeugt eine CSV mit Quell-zu-Ziel-Kundenzuordnungen. Diese Datei wird als Upload im Projekt registriert. Wiederholungen verwenden vorhandene Kunden, statt sie absichtlich zu duplizieren.

Danach geht es im normalen Projekt mit Catalog, Customers, Configure, Rehearse, Launch und Verify weiter. Ein grüner Abschlussstatus ist kein Ersatz für die Sichtprüfung. Besonders übersprungene Promotion Codes, Tax Rates oder Subscriptions können genau jene Formen verbergen, die später im Live-Lauf Probleme verursachen.

Seeding folgt fünf Grenzen: Live nur lesen, ausschließlich in Testumgebungen schreiben, einmalige Schlüssel nach Start löschen, Konto und Vorschau vor Ausführung zeigen und konkurrierende Operationen sperren. Bei einem Lauf ohne frischen Heartbeat wird nicht einfach eine zweite Operation gestartet; Laufkennung sichern, aktualisieren und bei anhaltendem Zustand Support einbeziehen.

Eine Sandbox ist kein bytegenauer Klon. Sie liefert starke Evidenz für Katalog- und Kundenzuordnung, Subscription-Erstellung, Konfiguration und Laufverhalten. Sie beweist nicht, dass reale Zahlungsautorisierungen, jede historische Rechnungsform, Webhooks oder kontoweite Einstellungen identisch sind. Diese Grenzen gehören in die Freigabe des späteren Live-Laufs.