Die kurze Antwort
Abonnements im Testzeitraum können migriert werden, wenn im Zielkonto die erforderlichen Kunden-, Zahlungs-, Preis- und Testzeitraumdaten bereitstehen. Im Ziel sollte normalerweise der verbleibende Zeitraum bis zu einem geprüften künftigen Testende erhalten bleiben. Abgelaufene, fehlende oder inkompatible Daten sind Ausnahmen und dürfen nicht stillschweigend zu sofortigen Belastungen führen.
Geprüft am 24. Juli 2026 vom MoveMRR-Produktteam.
Verhalten bei der Migration
MoveMRR berechnet das Verhalten des Testzeitraums aus dem Quellabonnement und der Projektkonfiguration. Das Zielabonnement erhält den vorgesehenen verbleibenden Zeitraum und ein kompatibles Verhalten am Ende. Der Probelauf zeigt, ob ein Zahlungsmittel vorhanden ist und was beim Ablauf des Testzeitraums geschieht.
Was die Bereitschaftsprüfung bestätigen muss
Kompatibilität ergibt sich aus den tatsächlichen Stripe-Objekten und nicht aus dem Seitentitel. Das Projekt muss jede fehlende Zuordnung, jedes nicht unterstützte Feld, jeden mehrdeutigen Zustand und jede Voraussetzung im Zielkonto vor dem produktiven Lauf sichtbar machen.
- Das Testende liegt in der Zukunft und entspricht der Zusage an den Kunden.
- Preis- und Intervallzuordnungen im Zielkonto sind vollständig.
- Für automatische Belastungen besitzt der Kunde eine berechtigte kopierte Zahlungsmethode.
- Das Verhalten bei fehlendem Zahlungsmittel am Testende ist bewusst konfiguriert.
Das wichtigste zu kontrollierende Fehlerszenario
Ein fehlendes oder ungültiges Testende kann Kunden früher als zugesagt belasten oder das Zielabonnement in einen unbeabsichtigten Zustand versetzen. Testdatensätze sind nach Datum und Verhalten und nicht nur nach Anzahl abzugleichen.
Stripe-Abonnements im Testzeitraum: Prüfungen von Quelle zu Ziel
| Prüfung | Erforderlicher Nachweis | Bei Abweichung |
|---|---|---|
| Testende | Künftiges Zieldatum entspricht dem freigegebenen Restzeitraum | Ausschließen und prüfen |
| Standard-Zahlungsmittel | Berechtigtes Mittel zugeordnet oder bekannte Ausnahme | Vor Ablauf einen Verantwortlichen benennen |
| Verhalten am Ende | Kündigung, Pausierung oder Rechnung ist beabsichtigt | Zielkonfiguration korrigieren |
| Quellstatus | Kein zweites Abonnement wird am Testende aktiv | Deaktivierungsplan der Quelle ändern |
Ein kontrollierter Ablauf
- 1
Quellform inventarisieren
Genauen Status, Felder, verknüpfte Objekte, Termine und kontoweite Einstellungen erfassen.
- 2
Abhängigkeiten im Ziel vorbereiten
Alle benötigten Katalog-, Steuer-, Rabatt- und Zahlungsabhängigkeiten erstellen oder zuordnen.
- 3
Repräsentative Beispiele testen
Testdaten mit schwierigen Datensätzen und nicht nur den Idealfall verwenden.
- 4
Geplante Aktionen prüfen
Jede Warnung vor der produktiven Durchführung lösen oder ausdrücklich ausschließen.
- 5
Nach der Erstellung abgleichen
Zielverhalten mit dem freigegebenen Quellstatus vergleichen und das nächste Ereignis überwachen.
Vor der Migration zu prüfende Grenzen
- Abgelaufene Testzeiträume gelten nicht als gültige künftige Testzeiträume.
- Nach dem Testende kann weiterhin eine Authentifizierung durch die Bank erforderlich sein.
- Individuelle Anwendungsberechtigungen während Tests benötigen eine Prüfung der Anwendungsübergabe.
- Werbliche oder vertragliche Testzusagen müssen geschäftlich bestätigt werden.
Häufige Fragen
Verlieren Kunden ihren verbleibenden Testzeitraum?
Der freigegebene verbleibende Zeitraum kann erhalten bleiben, wenn Quelldatum und Zielkonfiguration gültig sind.
Braucht ein Testabonnement eine Zahlungsmethode?
Stripe unterstützt auch Testzeiträume ohne Zahlungsmittel. Das gewünschte Verhalten am Ende muss jedoch konfiguriert und überwacht werden.
Sollten Testabonnements mit aktiven Abonnements migriert werden?
Das ist möglich, sie sollten aber als eigene Gruppe geprüft werden, weil Testdaten, Zahlungsabdeckung und Verhalten am Ende andere Abnahmekriterien erzeugen.