Die Stripe-Umstellung braucht Rollen, Belege und eine eindeutige Abrechnungsgrenze

Benenne jeweils eine verantwortliche Person für Quellkonto, Zielkonto, Migration, Anwendung, kaufmännische Abstimmung und Go/No-Go-Freigabe. Bei einem SaaS-Kauf sollten Käufer und Verkäufer nicht über getrennte Schattenlisten arbeiten. Eine Person darf mehrere Rollen übernehmen, aber jede Entscheidung braucht einen eindeutigen Eigentümer und eine Vertretung. Definiere auch, wer den Stripe-Support kontaktiert und wer Kundenkommunikation freigibt.

Das Belegpaket enthält bestätigten Kontoweg, Kontokennungen, datiertes Umfangsmanifest, Customer-Data-Copy-Ergebnis, Katalogzuordnung, Abo-Konfiguration, Probelauf, Ausnahmeliste, Abrechnungsgrenze, Anwendungsliste und Abnahmekriterien. Geheimschlüssel, Webhook-Signaturgeheimnisse, rohe Zahlungsdaten und vertrauliche Kundenexporte gehören nicht in einen allgemeinen Deal-Ordner. Verwende sichere, eingeschränkte Ablagen und dokumentierte Zugriffe.

Lass Stripe bestätigen, ob eine Inhaberänderung des bestehenden Kontos möglich ist oder ein separates Zielkonto benötigt wird. Prüfe Rechtsträger, Länder, vollständigen Geschäftsumfang und verbleibende Quellverpflichtungen. Für eine getrennte Migration muss Customer Data Copy für das konkrete Kontopaar und die tatsächlichen Zahlungsmethoden geklärt sein. Die Stripe-Matrix schließt unter anderem Abonnements, Rechnungen, Pläne, Gutscheine, Ereignisse und Protokolle aus.

Inventarisiere den Abrechnungsbestand vollständig: Währungen, Beträge, Intervalle, Mengen, mehrere Positionen, Testphasen, Anker, Proration, Discounts, Steuerverhalten, Subscription Schedules, Send-Invoice, gemessene Nutzung und problematische Status. Erfasse parallel die Anwendung: lokale Customer- und Subscription-Kennungen, API-Schlüssel, Webhooks, Portal, Mahnwesen, Berichte, Berechtigungen und Hintergrundaufgaben. Jede unbekannte Abhängigkeit wird vor der Probe aufgelöst oder ausdrücklich vom Lauf ausgeschlossen.

Erzeuge eine repräsentative Sandbox-Population mit gewöhnlichen und schwierigen Fällen. Sandbox- und Live-Kennungen müssen getrennt zugeordnet werden. Prüfe nicht nur, ob Zielobjekte entstehen, sondern ob Betrag, Währung, Intervall, Menge, nächster Rechnungstermin, Testphase, Rabatt, Steuer und Collection Method beabsichtigt sind. Eine erfolgreiche API-Antwort ist noch keine kaufmännische Abnahme.

Teste die Anwendung mit neuen Kennungen und Ziel-Webhooks. Stripe garantiert keine Ereignisreihenfolge; die Integration muss Signaturen prüfen, Wiederholungen aushalten und bei Bedarf den aktuellen Objektzustand abrufen. Probiere fehlgeschlagene Zahlungen, SCA, Kündigung, Planwechsel und Portalzugriff. Der Probelauf endet mit einer Liste aller Abweichungen und einer erneuten Freigabe, nicht mit der Annahme, Sandbox-Erfolg übertrage sich automatisch auf Live.

Schreibe die Reihenfolge mit Uhrzeit, Verantwortlichem, Eingabe, erwarteter Ausgabe und Prüfbeleg. Lege fest, wie neue Abschlüsse, Kündigungen und Planwechsel nach dem letzten Snapshot behandelt werden. Definiere, welche Fehler eine Pause, einen Abbruch oder manuelle Nacharbeit auslösen. Ein verpasster Termin darf nicht zu improvisierter Quellkündigung führen.

Wenn Stripes Billing Migration Toolkit verwendet wird, prüfe seine aktuellen Live-Regeln unmittelbar vor dem Upload. Die englische Ausgangsdokumentation nennt derzeit Startdaten mindestens 24 Stunden in der Zukunft, eine 24-stündige terminierte Phase und ein zehnstündiges Stornierungsfenster im Toolkit. Notiere die tatsächlich im Dashboard angezeigte Frist; Produktregeln können sich ändern und die terminierte Phase ist kein unbegrenzter Rückweg.

Ziehe den finalen Quell-Snapshot und vergleiche ihn mit dem freigegebenen Manifest. Jede neue oder veränderte Subscription wird als Delta verarbeitet, aus dem Lauf ausgeschlossen oder führt zur erneuten Freigabe. Prüfe Customer-Data-Copy-Abdeckung, Standardzahlungsarten und alle Zielzuordnungen erneut. Stelle sicher, dass Zielkonto, Bank, Steuern, Belegtexte, Rechnungen, Mahnwesen und Portal produktionsbereit sind.

Untersuche Quellrechnungen rund um den Wechsel: offene und entworfene Rechnungen, anstehende Rechnungspositionen, gemessene Nutzung, geplante Kündigungen und unmittelbar bevorstehende Erneuerungen. Kündigungszeitpunkt, Proration und ausstehende Positionen können zusammenwirken. Entscheide pro Kohorte, welcher Zeitraum noch durch die Quelle und welcher durch das Ziel abgerechnet wird.

Stripe empfiehlt, die Zielabonnements vor den alten Kündigungen anzulegen, die alten jedoch vor der Fälligkeit der neuen zu kündigen. Liegt ein Abrechnungstermin zu nah am Wechsel, kann die Quelle den letzten Zyklus abrechnen und das Ziel danach starten. Diese Reihenfolge erfordert eine eindeutige Abrechnungsgrenze; sie ist keine Aufforderung, beide Systeme gleichzeitig abrechnungsfähig zu lassen.

Vor dem ersten Zielschreibvorgang kann ein Abbruch häufig ohne Kundenwirkung erfolgen. Nach Zielanlage, Quellkündigung oder ausgespielten Anwendungsschlüsseln gibt es keinen allgemeinen Rückgängig-Knopf. Dann braucht es eine fallweise Vorwärtskorrektur: fehlerhafte Zielobjekte berichtigen, Quelle nur nach fachlicher Freigabe reaktivieren, Kommunikation und Erstattung koordinieren. Die Grenze wird vor T0 schriftlich festgelegt.

Bei API-basierten Abläufen verhindern stabile Idempotenzschlüssel, dass identische Wiederholungen unbemerkt doppelte Nebenwirkungen erzeugen. Speichere zu jeder Quellzeile die entstandene Zielkennung. Idempotenz beweist jedoch nicht, dass Betrag, Datum oder Zuordnung fachlich richtig waren. Nur die unabhängige Abstimmung prüft die beabsichtigte Wirkung.

In den ersten 24 Stunden beobachtet das Team Webhook-Signaturen, fehlende Ereignisse, Produktzugänge, Kundenportal, neue Rechnungen und Support. Bis T+7 werden die ersten Erneuerungskohorten gegen das Manifest geprüft. Der Subscription-Status „active“ beweist nicht, dass jede Rechnung bezahlt wurde; Invoice- und PaymentIntent-Zustände sowie Authentifizierungsanforderungen gehören in die Kontrolle.

Bis T+30 werden Ausnahmen geschlossen, Migrationsschlüssel widerrufen und Ergebnisse archiviert. Der notwendige Quellzugriff für Historie, Erstattungen, Streitfälle, Ereignisse und Steuern bleibt nach dem vereinbarten Plan bestehen. Ein Abschlussbericht nennt Umfang, Zielkennungen, Quellzustand, offene Fälle und verantwortliche Personen. Erst dann wechselt die Arbeit vom Migrationsprojekt in den normalen Betrieb.