Ein WHMCS-Kundenexport stellt kein übertragbares Zahlungsmandat dar. Bevor Sie wiederkehrende Abrechnungen migrieren, ermitteln Sie das Anbieterkonto, die gespeicherte Zahlungsreferenz und die von jedem Dienst verwendete Autorisierung. Überprüfen Sie anschließend, ob der Zielanbieter diese Konfiguration nutzen kann oder ob der Kunde eine neue Autorisierung benötigt. Rechnungsdaten und die Einzugsermächtigung sind unterschiedliche Datensätze.
Dieser Leitfaden hilft Hosting-Anbietern bei der Planung dieser Entscheidung. Er enthält weder ein Skript zum Kopieren von Tokens noch verspricht er die automatische Übertragbarkeit von Zahlungsmethoden. Das unten stehende ursprüngliche Arbeitsblatt zur Vorbereitung kann ausgefüllt werden, ohne dass Rohdaten von Kreditkarten erfasst werden müssen. Für die umfassendere Umstellung beginnen Sie mit dem Leitfaden „Checkliste für die WHMCS-Migration“.
Was stellt eine in WHMCS gespeicherte Zahlungsmethode dar?
Eine gespeicherte Zahlungsreferenz identifiziert eine Beziehung innerhalb eines bestimmten Gateways und eines Anbieter-Kontos. Ihre Bedeutung hängt vom jeweiligen Modul ab. Sie kann sich auf einen Kunden, eine gespeicherte Zahlungsmethode oder eine externe Vereinbarung über wiederkehrende Zahlungen beziehen. Die Bezeichnung allein gibt keinen Aufschluss darüber, ob die neue Plattform Zahlungen einziehen darf.
Das offizielle Dokument „Dokumentation zum WHMCS-Stripe-Modul“ beschreibt die tokenisierte Speicherung und modulspezifische Referenzen. Prüfen Sie, welches Modul Ihre Installation tatsächlich verwendet. Eine Stripe-Kunden-ID ist kein vollständiger Abonnementplan, und ein Plan allein identifiziert noch keine verwendbare Karte.
Einige Zahlungsgateways erstellen wiederkehrende Vereinbarungen außerhalb von WHMCS. Der separate Artikel „Dokumentation zur Abonnementverwaltung in WHMCS“ beschreibt Gateway-Kündigungs-Hooks für solche Vereinbarungen. Dies ist ein anderer Mechanismus als der, bei dem eine Anwendung entscheidet, wann eine Rechnung erstellt und eine Zahlung angefordert wird.
Notieren Sie sich den tatsächlichen Gateway-Namen und die Version, das Anbieter-Konto sowie den Inhaber der Inkassoberechtigung. Fragen Sie nach, wer die jeweilige Verlängerung initiiert: WHMCS, das Abonnementsystem des Anbieters oder eine andere Integration. Ohne diese Antwort kann es leicht passieren, dass ein Abrechnungsplan deaktiviert wird, während eine unabhängige Vereinbarung weiterhin Gebühren berechnet.
Betrachten Sie die anfängliche Bestandsaufnahme als Beweissicherung. Ändern Sie keine Live-Verweise, während Sie diese identifizieren. Ein stabiler Momentaufnahme ermöglicht es dem Abrechnungsteam, die alte Vereinbarung mit dem beabsichtigten Ziel zu vergleichen und Konten zu identifizieren, die vor der nächsten Verlängerung einer besonderen Behandlung bedürfen.
Trennen Sie Kundendaten, Autorisierung und Verlängerungszeitpläne
Kundendaten helfen Ihnen bei der Identitätsabgleichung. Die Autorisierung legt eine zulässige Zahlungsweise fest. Der Zeitplan bestimmt, wann und in welcher Höhe abgerechnet wird. Behalten Sie diese drei Aspekte als separate Prüfschritte bei, auch wenn die alte Schnittstelle sie auf einer Seite anzeigt.
Laden Sie die CSV-Datei zur Zahlungsbereitschaft herunter. Die englische Vorlage erfasst Überprüfungsergebnisse und fiktive Referenzen. Es handelt sich um ein Planungsarbeitsblatt, nicht um eine Importdatei für Anbietervorgaben. Geben Sie darin keine Kartennummern, Sicherheitscodes, Passwörter oder API-Geheimnisse an.
| Eintrag | Planungsfrage | Beispielergebnis |
|---|---|---|
| Kundenabgleich | Gehört diese Referenz zum beabsichtigten Kunden? | Identität überprüft |
| Anbieter-Konto | Welches Konto ist Eigentümer der gespeicherten Zahlungsmethode? | Vorhandenes Konto erfasst |
| Zahlungsautorisierung | Kann das Zielsystem diese Autorisierung für diesen Dienst nutzen? | Warten auf Bestätigung |
| Verlängerungszeitplan | Welcher Zeitraum wurde bereits bezahlt? | Oktober bezahlt; November als Nächstes |
| Inhaber des Einzugs | Welches System initiiert heute die Zahlung? | Vorhandener Gateway-Workflow |
| Zielzuordnung | Wurde dort eine unterstützte Referenz verifiziert? | Nicht bereit für automatischen Einzug |
Bei einem fiktiven Kunden A können alle Kontaktdaten korrekt übertragen werden, während die Zahlungszuordnung noch unbestätigt ist. Dieser Kunde ist nicht bereit für den automatischen Einzug. Die Kennzeichnung des Datensatzes als „importiert“ sollte nicht dazu führen, dass alle drei Prüfungen zu einem einzigen grünen Status zusammengefasst werden.
Bei Kunde B könnte die Zahlungsvereinbarung zwar bestätigt sein, der nächste Zeitraum jedoch bereits bezahlt sein. Eine korrekte Autorisierung rechtfertigt keine erneute Abbuchung. Kombinieren Sie dieses Arbeitsblatt vor der Aktivierung mit dem „Protokoll zur Übergabe bei Vertragsverlängerung“.
Prüfen Sie, ob Sie den Zahlungsanbieter wechseln
Der Wechsel zu einer neuen Abrechnungsschnittstelle und der Wechsel zu einem neuen Zahlungsanbieter sind unterschiedliche Projekte. Der Verbleib beim gleichen Anbieter kann zwar den Arbeitsaufwand etwas verringern, garantiert jedoch nicht, dass zwei Integrationen dieselben Kunden- und Zahlungsreferenzen verwenden können.
Wenn das Anbieterkonto dasselbe bleibt, fragen Sie bei der Zielintegration nach, welche Referenztypen akzeptiert werden, wie die Eigentumsverhältnisse überprüft werden und welche Einstellungen erforderlich sind. Bestätigen Sie dies mit einer kleinen autorisierten Testgruppe. Verwechseln Sie einen vertrauten Kontonamen nicht mit der tatsächlichen Unterstützung des Einzugswegs.
Wenn der Anbieter wechselt, erkundigen Sie sich bei beiden Anbietern nach dem unterstützten Migrationsprozess. Unter Anleitung von Mollie zum Import von Kartenmandaten wird ein koordinierter Anbieterwechsel und die Zuordnung zu neuen Referenzen beschrieben. Dabei wird die Migration von Karteninformationen ausdrücklich von der Abonnementlogik getrennt. Diese Unterscheidung ist für die Planung der Umstellung der Abrechnung von zentraler Bedeutung.
Der Kartenprozess von Mollie ist keine universelle Methode für jede Zahlungsart. In der Dokumentation wird die Kartenmigration von SEPA- und PayPal-Mandatswegen unterschieden. Planen Sie anhand Ihrer tatsächlichen Methode, Ihres Kontos und Ihrer Integration, anstatt jede gespeicherte Zahlungszeile als austauschbar zu behandeln.
Halten Sie die Koordination mit den Anbietern getrennt von einem Versprechen bezüglich des Kundenerlebnisses. Solange die Zuordnung zum Ziel und der erste Einzugsweg nicht verifiziert sind, lautet der ehrliche Status „wird geprüft“. Ein Migrationsdatum sollte die tatsächliche Bereitschaft widerspiegeln und nicht die pauschale Annahme, dass alle gespeicherten Zahlungsmethoden übertragen werden.
Entscheiden Sie, wann eine erneute Autorisierung durch den Kunden der klarere Weg ist
Wenn eine bestehende Vereinbarung nicht als nutzbar bestätigt werden kann, planen Sie eine neue Kundenautorisierung ein, anstatt eine nicht unterstützte Referenzkopie zu versuchen. Teilen Sie dem Kunden mit, welche Maßnahme erforderlich ist, welchen Dienst sie abdeckt und wann die zukünftige Abbuchung beginnt.
Bei der erneuten Autorisierung sollte der Kunde nicht aufgefordert werden, Kartendaten per E-Mail zu übermitteln. Leiten Sie ihn durch den konfigurierten Ablauf der sicheren Zahlungsmethode. Mitarbeiter sollten keine Kartennummern oder Sicherheitscodes in einem Support-Ticket erfassen, um eine unvollständige Integration zu umgehen.
Verwenden Sie unterschiedliche Nachrichten für bestätigte und unbestätigte Konten. Ein Kunde, dessen Zahlungszuordnung bereits eingerichtet ist, sollte keine unnötige Aufforderung erhalten, eine weitere Karte hinzuzufügen. Ein Kunde, dessen Zuordnung noch nicht eingerichtet ist, sollte keine beruhigende Nachricht mit dem Hinweis „Keine Aktion erforderlich“ erhalten, nur weil seine E-Mail-Adresse erfolgreich importiert wurde.
Eine wiederverwendbare Nachricht lautet: „Die Abrechnung für [Dienstleistung] wird ab [Zeitraum] auf [Portal] umgestellt. Bitte autorisieren Sie die Zahlungsmethode über [verifizierter Einrichtungslink] vor dem [Datum]. Ihr bestehender bezahlter Versicherungsschutz endet am [Datum]. Wir werden den nächsten fälligen Betrag bestätigen, bevor wir mit der neuen Abbuchung beginnen.“
Ersetzen Sie jedes Feld durch die tatsächlichen Daten und verwenden Sie die verifizierte Ziel-URL. Prüfen Sie, wer Kundenfragen beantworten darf und wie mit unvollständigen Autorisierungen umgegangen wird. Wiederholte Erinnerungs-E-Mails können eine nicht unterstützte Zahlungsvereinbarung nicht gültig machen.
Automatische und manuelle Abrechnung von Abonnements mit PayRequest verstehen
Der Leitfaden „Dokumentation zu Abonnementzahlungen“ von PayRequest beschreibt die automatische Abbuchung unter Verwendung eines zugewiesenen gültigen Mandats sowie die manuelle wiederkehrende Rechnungsstellung. Der dokumentierte Mandats-Workflow nutzt Mollie. Betrachten Sie das Vorhandensein einer Stripe-Verbindung an anderer Stelle nicht als Beweis dafür, dass jede WHMCS-Stripe-Referenz diesem Ablauf zugeordnet werden kann.
Überprüfen Sie die im aktuellen Abonnement angegebene Zahlungsmethode. Bestätigen Sie die Inhaberschaft des Kunden und den gültigen Status des Mandats über die unterstützte Schnittstelle. Eine bekannte Referenz, die in ein nicht zugehöriges Feld kopiert wurde, beweist nicht, dass ein Einzugsweg funktioniert oder dass der Kunde diesen autorisiert hat.
Die manuelle wiederkehrende Rechnungsstellung kann für Kunden genutzt werden, die per Banküberweisung bezahlen, sofern das Produkt und die Einrichtung dies zulassen. Dabei erhält der Kunde eine zu begleichende Rechnung, anstatt dass der Betrag automatisch eingezogen wird. Dies verändert den Arbeitsablauf: Jemand muss die Rechnung und das Zahlungsergebnis überwachen, bevor der Saldo als beglichen behandelt wird.
Wählen Sie die Methode bewusst aus. Die manuelle Rechnungsstellung sollte kein unsichtbarer Ausweichweg sein, nachdem ein versprochenes automatisches Inkasso fehlgeschlagen ist. Teilen Sie den Kunden mit, ob der Betrag eingezogen wird oder ob sie die Rechnung bezahlen müssen, und stimmen Sie diese Anweisung mit dem Status im Portal ab.
Die „Kundenportal“ ist Teil der Benutzererfahrung, aber das Portal allein stellt keine Zahlungsautorisierung dar. Nutzen Sie die „Portal-Demo“, um Kundenaufgaben zu bewerten, während die Zahlungszuordnung separat überprüft wird.
Testen Sie das Referenz-Mapping vor der ersten Live-Verlängerung
Erstellen Sie für jedes Pilotkonto einen kurzen Verifizierungsbericht. Darin sollten die alte Dienstreferenz, der Zielkunde, der nächste Abrechnungszeitraum, die Zahlungsart und die Person, die die Überprüfung durchgeführt hat, genannt werden. Halten Sie Beobachtungen und Ergebnisse fest, ohne sensible Zahlungsdaten zu erfassen.
Bei einem automatischen Ablauf sollten Sie vor einer autorisierten Einzugsprüfung die zulässige Zahlungsvereinbarung und den fälligen Betrag bestätigen. Beobachten Sie das tatsächliche Ergebnis des Anbieters und den Rechnungsstatus. Ein als „aktiv“ angezeigtes Abonnement ist kein Ersatz für die Überprüfung der entsprechenden Zahlung.
Bei einem manuellen Ablauf überprüfen Sie die Rechnungsanweisungen und die Art und Weise, wie die Zahlung abgeglichen wird. Das Fehlen eines Mandats kann beabsichtigt sein. Die Frage ist, ob der ausgewählte Workflow mit der Produktkonfiguration und dem dem Kunden gegebenen Versprechen übereinstimmt.
Stellen Sie außerdem sicher, dass der bisherige Inkassoverantwortliche denselben Zeitraum nicht abrechnen kann. Eine korrekte Zielzahlungsmethode kann doppelte Inkassovorgänge erleichtern, wenn das alte Gateway noch eigenständig agiert. Lesen Sie die „Leitfaden zur Migration bei doppelter Abrechnung“, bevor Sie nach einer fehlgeschlagenen Prüfung einen alten Auftrag reaktivieren.
Verwenden Sie eine auf Nachweisen basierende Go-Live-Bedingung: unterstützte Referenz, korrekter Kunde, korrekter Betrag und Datum, ein einziger Inkassoverantwortlicher und ein geprüftes Ergebnis. „Alle Zeilen importiert“ ist ein Datenmeilenstein. Es handelt sich dabei nicht um den vollständigen Test der Zahlungsannahme.
Unvollständige Zahlungsbereitschaft handhaben, ohne die Kontrolle zu verlieren
Führen Sie unbestätigte Konten in einer separaten Gruppe. Weisen Sie jedem eine Maßnahme zu: Bestätigung durch den Anbieter, erneute Autorisierung durch den Kunden, einen ausdrücklich vereinbarten manuellen Rechnungsweg oder eine verschobene Übergabe. Vermeiden Sie es, die gesamte Gruppe zu aktivieren und darauf zu hoffen, dass fehlgeschlagene Zahlungen die Ausnahmen später identifizieren.
Bei zeitkritischen Verlängerungen lassen Sie die alte Vereinbarung nur so lange verantwortlich, wie sie noch der vereinbarte Abrechnungsinhaber ist. Dokumentieren Sie das geänderte Übergabedatum. Wenn das neue System bereits einen Versuch unternommen hat, überprüfen Sie das Ergebnis, bevor Sie das alte System erneut eine Einziehung vornehmen lassen.
Bewahren Sie historische Zahlungsaufzeichnungen und Support-Notizen auf. Eine Anbieterzuordnung ist nützlich für den Abgleich von Referenzen, aber Kunden können dennoch nach einer alten Rückerstattung, Rechnung oder Kontoauszugsbeschreibung fragen. Geben Sie Ihren Mitarbeitern die Möglichkeit, diese Fragen nachzuverfolgen, ohne unnötige Kopien von Zugangsdaten aufzubewahren.
Legen Sie das ausgefüllte Bereitschaftsformular dem „Bewertung der WHMCS-Migration“ vor. Beschreiben Sie Ihren Anbieter, die Zahlungsmethoden und die Serviceautomatisierung. So erhält das Team eine konkrete Konfiguration zur Überprüfung und nicht nur die Aufforderung, „alle Abonnements zu übertragen“, ohne dass definiert ist, was dies umfasst.
PayRequest Business kostet 20 € pro Monat und umfasst das Kundenportal sowie die wiederkehrende Abrechnung. Die Standard-Zahlungsgebühren der Plattform betragen 0 %, solange der kostenpflichtige Tarif aktiv ist. Bearbeitungsgebühren der Anbieter fallen separat an; für Provisionszahlungen gilt eine eigene Gebühr. Schließen Sie die Kontoeinrichtung ab und aktivieren Sie „Business“ an der Kasse. Die Auswahl von „Business“ bei der Anmeldung gewährt noch keinen kostenpflichtigen Zugang. Informieren Sie sich unter Aktuelle Preise, bevor Sie Ihre Konfiguration auswählen.
Anmerkung der Redaktion: Dieser Artikel und das illustrative Titelbild wurden mithilfe von KI erstellt. Die offizielle Dokumentation wurde am 7. Oktober 2026 überprüft. Arbeitsblätter und Kundenmitteilungen sind originale Planungsvorlagen. Alle Beispiele sind fiktiv; für diesen Artikel wurden keine tatsächlichen Abrechnungen, Kundenmigrationen oder Hosting-Kündigungen durchgeführt.
