Eine WHMCS-Kündigung erfordert drei Entscheidungen: wann die Rechnungsstellung endet, wann etwaige externe Vereinbarungen über wiederkehrende Zahlungen enden und wann der Hosting-Zugang endet. Halten Sie das beantragte und das wirksame Datum, den bezahlten Leistungsumfang und das zuständige System fest, bevor Sie Maßnahmen ergreifen. Eine Kündigung über das Portal ist kein Nachweis dafür, dass jedes Zahlungsgateway, jedes Hosting-Modul und jeder Registrar die entsprechende Maßnahme abgeschlossen hat.
Dieser Leitfaden richtet sich an Hosting-Anbieter, die den Kundenselbstservice überprüfen oder die Kundenabrechnung in ein anderes Portal verlagern. Er enthält eine Vorlage für einen Kündigungsbeleg sowie eine Vorlage für die Kundenbestätigung. Er empfiehlt keine einheitliche Kündigungsfrist und ersetzt nicht Ihre Nutzungsbedingungen. Für eine umfassendere Auswahl an Plattformen lesen Sie den Leitfaden „Vergleich der WHMCS-Kundenportale“.
Wie wirken sich WHMCS-Kündigungsanfragen auf einen Dienst aus?
WHMCS kann Kündigungsanfragen von Kunden entgegennehmen und die Beendigung von Diensten entsprechend der Konfiguration abwickeln. Das Ergebnis hängt von der Art der Anfrage, den Automatisierungseinstellungen und dem Bereitstellungsmodul ab. Überprüfen Sie das installierte Verhalten, bevor Sie versprechen, dass zu einem bestimmten Datum die Abrechnung und das Hosting gleichzeitig eingestellt werden.
Das offizielle Dokument „Dokumentation zur WHMCS-Kündigung“ beschreibt die sofortige und geplante Kündigung, Kundenanfragen sowie die manuelle Genehmigung. Darin wird erläutert, dass eine Kündigung die zukünftige Rechnungserstellung stoppt und dass die Kündigung durch ein Modul den Zugriff auf bereitgestellte Dienste beeinträchtigen kann. Hierbei handelt es sich um Folgeaktionen, nicht lediglich um eine Änderung einer Portalbezeichnung.
Prüfen Sie, welche Jobs aktiviert sind und wer Ausnahmen bearbeitet. Ein vom Kunden eingereichter Antrag erfordert möglicherweise ein Eingreifen des Personals, wenn die automatische Kündigungsabwicklung nicht aktiviert ist. Ein als „gelöst“ markiertes Support-Ticket ist kein Nachweis dafür, dass ein Hosting-Modul seinen Befehl vollständig ausgeführt hat.
Definieren Sie, was eine Kündigung für das jeweilige Produkt bedeutet. Managed Hosting, ein Wartungsvertrag und eine jährliche Domain-Registrierung erfordern unterschiedliche operative Maßnahmen. Wenn ein Kunde die Kündigung eines einzelnen Postens beantragt, überprüfen Sie dessen Dienstreferenz, bevor Sie ein zugehöriges Paket oder alle Dienste auf dem Konto ändern.
Unterscheiden Sie außerdem zwischen einer Kündigung und einer Umstellung der Abrechnung. Die Verlagerung eines Kunden auf ein neues Portal bedeutet nicht, dass der Kunde die Beendigung des Hosting-Dienstes wünscht. Lesen Sie die „Leitfaden zur Übergabe bei Vertragsverlängerung“, bevor Sie eine Kündigungssteuerung lediglich dazu nutzen, alte Abrechnungen zu unterbinden.
Abrechnung, Zahlungsvereinbarungen und Zugriffsrechte getrennt prüfen
Halten Sie jede Maßnahme und das beobachtete Ergebnis fest. Das Stoppen der Rechnungserstellung beweist für sich genommen nicht, dass eine wiederkehrende Vereinbarung auf Anbieterseite gekündigt wurde. Ebenso führt die Beendigung einer wiederkehrenden Zahlungsvereinbarung nicht zwangsläufig zur Kündigung des Hosting-Kontos.
„WHMCS-Verwaltung von Gateway-Abonnements“ ist eine optionale Modulfunktion für extern verarbeitete wiederkehrende Vereinbarungen. Das dokumentierte Verhalten hängt von der Gateway-Unterstützung und den Einstellungen ab. Überprüfen Sie das Ergebnis des Anbieters, anstatt davon auszugehen, dass jede Integration denselben Kündigungsweg verfolgt.
Behandeln Sie den Hosting-Zugang als eigenständigen Lebenszyklus. Ein Modulbefehl muss möglicherweise im Hosting-System überprüft werden. Wenn eine Integration fehlgeschlagen ist, kann ein geänderter Abrechnungsstatus neben einem weiterhin verfügbaren Konto bestehen. Weisen Sie einem Mitarbeiter die Verantwortung für die Behebung dieser Diskrepanz zu.
Die automatische Verlängerung von Domains ist ein weiterer Aspekt, der gegebenenfalls überprüft werden muss. Eine Hosting-Kündigung sollte nicht stillschweigend eine davon unabhängige Entscheidung zur Domain-Verlängerung ändern. Halten Sie fest, was der Kunde gekündigt hat und was weiterhin aktiv bleibt, einschließlich des Verantwortlichen für etwaige Maßnahmen auf Seiten des Registrars.
Verwenden Sie in der Kundenkommunikation den tatsächlichen Status. „Anfrage eingegangen“, „Kündigung geplant“ und „gekündigt“ sollten unterschiedlichen Nachweisen entsprechen. Vermeiden Sie es, eine endgültige Bestätigung zu versenden, solange wichtige Abrechnungs- oder Zugangsmaßnahmen noch nicht überprüft wurden.
Verwenden Sie pro Dienst ein Kündigungsübergabeprotokoll
Laden Sie die CSV-Datei mit den Stornierungsdaten herunter. Die englische Vorlage enthält fiktive Beispiele für sofortige und geplante Anfragen. Sie dokumentiert Entscheidungen und Beobachtungen; sie führt weder eine Kündigung durch noch importiert sie Daten in WHMCS oder PayRequest.
| Feld | Fiktives Beispiel | Warum es wichtig ist |
|---|---|---|
| Dienstreferenz | Beispiel A / Managed Hosting | Definiert genau, was gekündigt wird |
| Anfrage eingegangen | 10. Oktober 2026 | Bewahrt die ursprüngliche Anfrage des Kunden |
| Bezahlt bis | 31. Oktober 2026 | Unterscheidet bezahlte Laufzeit von Kündigungsfrist |
| Gültigkeitsdatum | Nach Prüfung der Bedingungen bestätigen | Verhindert ein fiktives Enddatum |
| Verantwortlicher für die Schlussabrechnung | Bestehender Abrechnungsworkflow | Identifiziert ausstehende oder abschließende Rechnungen |
| Ergebnis der Zahlungsvereinbarung | Warten auf Bestätigung durch den Anbieter | Trennt eine Anfrage von einer abgeschlossenen Kündigung |
| Hosting-Maßnahme und Verantwortlicher | Geplant / Hosting-Betreiber | Legt die Zugriffsentscheidung fest |
| Bestätigung an den Kunden | Noch nicht gesendet | Erfordert überprüfte Daten und Ergebnisse |
Fügen Sie die Anfragekategorie, etwaige ausstehende Beträge und einen Ort für den Bestätigungsnachweis hinzu. Halten Sie Notizen sachlich und angemessen. Das Arbeitsblatt benötigt keine Passwörter, Servergeheimnisse oder Zahlungsdaten, um zu beschreiben, wer für die nächste Maßnahme verantwortlich ist.
Lassen Sie die Abrechnungs- und Hosting-Verantwortlichen denselben Datensatz prüfen. Separate private Notizen sind manchmal notwendig, doch widersprüchliche Enddaten führen zu vermeidbaren Fehlern. Eine Person sollte die Gesamtverantwortung für den Fall tragen, während die zuständigen Spezialisten ihre Maßnahmen überprüfen.
Bearbeitung von sofortigen und zum Periodenende gerichteten Anträgen
Angenommen, Kunde A hat 29 € für das Hosting im Oktober bezahlt und beantragt am 10. Oktober eine Kündigung zum Periodenende. Erfassen Sie den tatsächlich bezahlten Zeitraum und die Vertragsbedingungen und bestätigen Sie dann das Datum des Inkrafttretens über den konfigurierten Workflow. Erstellen Sie während einer gleichzeitigen Portal-Migration kein neues laufendes Abonnement.
Prüfen Sie, ob bereits eine zukünftige Verlängerungsrechnung oder ein Zahlungsversuch vorliegt. Ist dies der Fall, überprüfen Sie deren Status, bevor Sie den Zeitplan ändern. Ein ungelöster, ausstehender Zahlungsversuch erfordert eine andere Maßnahme als eine abgeschlossene Zahlung oder eine noch nicht versendete Rechnungsvorlage.
Kunde B beantragt die sofortige Kündigung eines separaten Dienstes. Vergewissern Sie sich, dass der Antrag autorisiert ist, und klären Sie die Konsequenzen für den Zugriff und die Daten. Die sofortige Kündigung, die Unterdrückung zukünftiger Rechnungen und eine Entscheidung über die Rückerstattung sind separate Angelegenheiten. Lassen Sie nicht den Eindruck entstehen, dass das Klicken auf eine Schaltfläche „Kündigen“ automatisch zu einer Rückerstattung für den nicht genutzten Zeitraum führt.
Kunde C hat ein monatliches Hosting-Abo und eine jährlich verlängerte Domain. In der Anfrage wird nur das Hosting erwähnt. Halten Sie die Entscheidung bezüglich der Domain ausdrücklich fest, einschließlich der Frage, ob die automatische Verlängerung aktiviert bleibt und wer beim Registrar tätig werden muss. Leiten Sie aus der Hosting-Anfrage allein keine Kündigung der Domain ab.
Diese Beispiele sind fiktive Planungsfälle. Sie zeigen, warum eine einzige Spalte „gekündigt“ nicht alle Ergebnisse abdecken kann. Daten, betroffene Dienste und Nachweise über den Abschluss ermöglichen es den Mitarbeitern, dem Kunden eine präzise Antwort zu geben und den Fall auch bei einem Wechsel der Abrechnungsplattform weiter zu bearbeiten.
Konfigurieren Sie den PayRequest-Self-Service passend zum Produkt
Die „Dokumentation zum Kundenselbstservice“ von PayRequest beschreibt produktunabhängige Steuerungsmöglichkeiten für die Pause und Kündigung. Dabei wird zwischen einer sofortigen Kündigung und einem Workflow für Kündigungsanträge unterschieden. Überprüfen Sie die vorgesehenen Produkteinstellungen, anstatt davon auszugehen, dass jedes Portal identische Aktionen anzeigt.
Die „Dokumentation zur Stornierungsanfrage“ erläutert die im Workflow angezeigten Angaben zu Antrag, Support-Eintrag und wirksamem Kündigungsdatum. Überprüfen Sie das tatsächliche Datum, bevor Sie es dem Kunden bestätigen. Eine Kündigungsfrist und ein bereits bezahlter Abrechnungszeitraum sind keine austauschbaren Begriffe.
Wählen Sie die Steuerungsmöglichkeiten entsprechend der Servicevereinbarung und den geltenden Kundenverpflichtungen aus. Eine Pause ist nicht automatisch für eine Domain oder einen bereitgestellten Hosting-Dienst geeignet. Integrationsspezifische Produkte können ein anderes Verhalten aufweisen; vergewissern Sie sich, was die Konfiguration unterstützt, bevor Sie eine generische Pause-Schaltfläche bewerben.
Testen Sie die kundenorientierte Formulierung anhand der tatsächlichen operativen Maßnahme. Wenn das Portal eine Anfrage anbietet, erklären Sie, dass es sich um eine Anfrage mit einem Datum des Inkrafttretens handelt. Wenn das Produkt eine sofortige Kündigung vorsieht, erläutern Sie das daraus resultierende Abonnementverhalten und prüfen Sie etwaige separate Hosting-Maßnahmen.
Nutzen Sie die „Beispielhafte Portal-Demo“, um die Aufgaben des Kunden zu besprechen. Die Demo enthält fiktive Daten und führt keine Kündigung eines echten Dienstes durch. Die Bedienelemente dienen als Vorschau auf die Benutzererfahrung und sind kein Nachweis dafür, dass Ihre WHMCS-Hosting-Module integriert sind.
Übertragen Sie ausstehende Kündigungsanfragen in eine Abrechnungsmigration
Erfassen Sie ausstehende Anfragen, bevor Sie aktive Abonnements verschieben. Berücksichtigen Sie dabei das beantragte Datum, das Datum des Inkrafttretens, die Dienstreferenz, den aktuellen Abrechnungsinhaber sowie alle geplanten Hosting-Maßnahmen. Der Begriff „aktiv“ im Quellsystem kann auch Kunden umfassen, deren Kündigung bereits geplant ist.
Wandeln Sie nicht jeden aktiven Datensatz in einen neuen, verlängerbaren Dienst um. Prüfen Sie die Kündigungsgruppe separat und legen Sie fest, was im Zielsystem angezeigt werden soll. Andernfalls könnte es so aussehen, als hätte sich ein Kunde, der bereits gekündigt hat, für einen neuen laufenden Vertrag entschieden.
Bewahren Sie die ursprüngliche Anfrage und die Entscheidungen der Mitarbeiter auf. Von Kunden zu verlangen, eine gültige Anfrage zu wiederholen, nur weil sich das Portal geändert hat, schafft ein vermeidbares betriebliches Problem. Stellen Sie den für die Übergabe zuständigen Mitarbeitern die historischen Nachweise zur Verfügung.
Überprüfen Sie die Zahlungsvereinbarung und die nächste Rechnung zusammen mit dem Gültigkeitsdatum. Wenn die alte Anbietervereinbarung noch besteht, stoppt die Migration des Anfragetextes nicht das Inkasso. Nutzen Sie die „Leitfaden zur Zahlungsbereitschaft“, um festzustellen, welche Vereinbarungen weiterhin abrechnungsfähig sind.
Verfolgen Sie während des ersten Pilotprojekts eine ausstehende Kündigung vom alten Antrag bis zur endgültigen Abrechnung und dem Ergebnis. Halten Sie die überprüften Systeme und noch offenen Schritte fest. Erweitern Sie den Prozess erst, wenn aus den Aufzeichnungen hervorgeht, wer in welcher Phase handelt und was der Kunde sieht.
Senden Sie eine Bestätigung mit konkreten Daten und Zuständigkeiten
Eine aussagekräftige Bestätigung enthält Angaben zum betroffenen Dienst, zum Datum der Anfrage, zum vereinbarten Datum des Inkrafttretens, zum bezahlten Leistungsumfang sowie zu etwaigen Maßnahmen seitens des Kunden. Außerdem wird erläutert, welche Leistungen weiterhin aktiv bleiben. Vermeiden Sie eine allgemeine Nachricht wie „Ihr Konto wurde gekündigt“, wenn nur ein Produkt ausläuft.
Eine wiederverwendbare Nachricht lautet: „Wir haben Ihren Kündigungsantrag für [Dienst] am [Datum] erhalten. Das bestätigte Datum des Inkrafttretens ist [Datum]. Ihr derzeit bezahlter Leistungsumfang gilt für den Zeitraum [Zeitraum]. [Geben Sie etwaige bestätigte abschließende Abrechnungsmaßnahmen an]. Der Hosting-Zugang wird [bestätigtes Ergebnis und Datum] eingestellt. [Führen Sie alle separaten Dienste auf, die weiterhin aktiv bleiben]. Wenden Sie sich an [Supportkanal], falls diese Angaben nicht mit Ihrer Anfrage übereinstimmen.“
Füllen Sie die Nachricht erst nach den entsprechenden Überprüfungen aus. Wenn eine Zugangsmaßnahme noch aussteht, geben Sie diesen Status klar an, anstatt endgültige Formulierungen zu verwenden. Geben Sie keine unbegründeten Rückerstattungsversprechen ab und bezeichnen Sie eine noch nicht geklärte Vereinbarung mit dem Anbieter nicht als gekündigt.
Geben Sie den Mitarbeitern die Möglichkeit, die Bestätigung und den Empfänger zu dokumentieren. Ein Kunde, der später nach einer Verlängerung fragt, sollte eine nachvollziehbare Antwort erhalten: welcher Dienst, welcher Zeitraum und welche Maßnahme abgeschlossen wurde. Die Aufzeichnung sollte auch dann noch nutzbar sein, wenn das alte Portal schreibgeschützt wird.
Prüfen Sie, wie Kunden historische Rechnungen nach Änderungen der Zugriffsrechte abrufen können. Der Zugriff auf Rechnungen und der bereitgestellte Hosting-Zugang können unterschiedlichen Regeln unterliegen. Legen Sie den Supportweg im Voraus fest, damit ein beendetes Hosting-Konto nicht dazu führt, dass eine berechtigte Frage zur Rechnungsstellung nicht mehr geklärt werden kann.
Schließen Sie den Fall erst nach Überprüfung der Ergebnisse ab
Führen Sie eine abschließende Überprüfung des Service-Datensatzes, des Rechnungsplans, der Anbietervereinbarung und des Hosting-Systems durch. Stellen Sie fest, welche Maßnahmen abgeschlossen sind und welche noch nachbereitet werden müssen. Eine Statusänderung in einer Anwendung ist lediglich eine Feststellung, keine vollständige Darstellung der Kündigung.
Bei einem zurückgezogenen Antrag prüfen Sie die umgekehrten Maßnahmen ebenso sorgfältig. Vergewissern Sie sich über die Fortsetzung des Dienstes, den nächsten Abrechnungsverantwortlichen und etwaige geänderte Verlängerungseinstellungen. Die Wiederaufnahme eines Abonnements ohne Überprüfung einer zuvor beendeten externen Vereinbarung kann dazu führen, dass ein aktiver Dienst ohne vorgesehenen Inkassoweg verbleibt.
Halten Sie Ausnahmen für den zuständigen Mitarbeiter sichtbar. Eine fehlgeschlagene Kündigung oder eine unerwartete Rechnung sollte einen Verantwortlichen und eine nächste Maßnahme haben. Blenden Sie dies nicht aus, indem Sie die Anfrage als „gelöst“ markieren, nur weil die kundenbezogene Nachricht versendet wurde.
Wenn Sie das Abrechnungsportal ersetzen, bringen Sie diese Aufzeichnungen in die „Bewertung der WHMCS-Migration“ ein. Dies hilft dabei zu definieren, welche Kündigungsaufgaben in PayRequest gehören und welche bei bestehenden Hosting- oder Registrar-Workflows verbleiben.
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; Provisionszahlungen unterliegen weiterhin einer separaten Gebühr. Schließen Sie die Kontoeinrichtung ab und aktivieren Sie „Business“ an der Kasse. Die Auswahl von „Business“ bei der Anmeldung gewährt an sich 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.
