Plesk-Abrechnung und Provisionierung automatisieren

Ein automatisiertes Hosting-Produkt hat drei Momente, in denen Geld und Maschinen einander berühren:

1. 01Die Bestellung wird bezahlt: ein Abonnement muss innerhalb von Sekunden existieren, auf dem richtigen Serviceplan.
2. 02Die Rechnung ist überfällig: das Abonnement muss stillgelegt werden und in dem Moment zurückkommen, in dem sie bezahlt wird.
3. 03Das Abonnement endet: es muss wirklich entfernt werden, samt seinen Daten.

Plesk hat Aufrufe für alle drei. Was es nicht hat, ist irgendetwas, das entscheidet, wann sie laufen, und das ist die Hälfte, die Sie bauen. Auf dieser Seite geht es darum, die beiden zu verdrahten, und um vier Verhaltensweisen, die harmlos sind, wenn Sie sie von Hand anklicken, und gefährlich, wenn ein Scheduler sie um drei Uhr morgens ausführt.

Alles hier wurde im August 2026 an einem laufenden Plesk-Obsidian-18.0.80-Server gemessen.

Die drei Momente und die Aufrufe darunter

Zwei dieser Zahlen prägen das Design. Ein Abonnement anzulegen dauert viereinhalb Sekunden und es zu löschen fast acht. Das ist lang genug, dass ein Bestellformular sagen muss, dass etwas geschieht, lang genug, dass ein Timeout-Budget, das für eine schnelle API geschrieben wurde, einen funktionierenden Aufruf auf halbem Weg abschneidet, und lang genug, dass zwei zusammen eintreffende Bestellungen wirklich gleichzeitig sind und nicht nur theoretisch.

Beachten Sie auch die Lesezeile. Ein XML-Aufruf liefert jedes Abonnement mit Plan, Status, Speicherkontingent und Auslastung in einer Drittelsekunde, egal wie viele es sind, und ein Abrechnungssystem gleicht ständig gegen das Panel ab.

Die Stilllegungs-Falle ist ein Abrechnungsfehler, kein API-Detail

Plesk bietet zwei Wege zum Stilllegen, und sie schreiben verschiedene Felder. In einem Hosting-Produkt hört das auf, eine Nebensächlichkeit zu sein.

Gemessen, am selben Abonnement:

Ein Mahnlauf, der über REST stilllegt, schreibt ein Feld, auf das der Sammel-Lesevorgang nicht schaut, sodass Ihre Plattform das Konto weiter als aktiv meldet. Und deshalb schmerzt das gerade bei der Abrechnung: Wenn die Rechnung endlich bezahlt ist, schaut Ihre Automatisierung auf ihren eigenen Zustand, sieht ein Konto, das nie stillgelegt wurde, und setzt es nicht fort. Der Kunde hat bezahlt und bleibt dunkel, und nichts hat einen Fehler festgehalten.

Die Regel ist eine Zeile: stilllegen über das Feld, das Sie lesen. Provibr schreibt <webspace><set><gen_setup><status>, wonach beide Ansichten übereinstimmen.

gen_info.status ist eine Bitmaske; wir haben 0 für aktiv, 1 für webspace-off und 16 für vom Administrator deaktiviert gemessen. Behandeln Sie alles, was nicht null ist, als stillgelegt: die einzige Lesart, die einen Wert übersteht, den noch niemand gesehen hat.

Ein abgelaufener Key sieht genau wie ein leerer Server aus

Das ist der Fehler, der echten Schaden anrichten kann, und er lässt sich in einem Satz beschreiben.

Die XML-API gibt für einen falschen Key HTTP 200 zurück. Der Fehler sitzt im Dokument, als Code 11003. Ein Client, der auf den Statuscode prüft, liest einen Authentifizierungsfehler daher als eine erfolgreiche Runde, die keine Abonnements fand.

Setzen Sie das nun in einen nächtlichen Abgleichsauftrag. Eine erfolgreiche Runde, die nichts fand, bedeutet für jede Hosting-Plattform, dass jedes gestern dort vorhandene Konto gelöscht wurde. Ein abgelaufener Key, und über Nacht markiert Ihr System Ihren gesamten Kundenstamm als verschwunden.

Daraus ergeben sich zwei Regeln, und sie gelten für jedes Panel, das Fehler mit einer 200 meldet, was auf die meisten der von uns integrierten Panels zutrifft:

• Auf der XML-API trägt der Statuscode überhaupt keine Information, nicht einmal über die Authentifizierung. Parsen Sie das Dokument.
• Eine unlesbare Antwort ist unbekannt, nie leer. Ein leerer Server existiert sehr wohl, und er erzeugt ein einzelnes leeres Ergebnis statt eines Fehlers. Diese beiden sind wirklich verschieden, und sie auseinanderzuhalten ist die ganze Aufgabe.

REST scheitert wieder anders: Ein unbrauchbarer Key kommt als HTTP 401 mit einem völlig leeren Body zurück. Ein Verbindungstest muss also beide Oberflächen prüfen und getrennt melden. Ein grünes REST-Ergebnis neben einer schweigenden XML-API bedeutet, dass die Kontoliste, die Planliste und jeder Planwechsel leer bleiben, und die verlockende Schlussfolgerung ist, der Kunde habe keine Konten.

Der Fehlercode sagt Ihnen nicht, was schiefging

Die REST-Fehler von Plesk tragen einen numerischen Code, und es ist verlockend, danach zu verzweigen. Gemessen, klassifiziert er nicht:

• 1007 deckt sowohl „diese Domain existiert bereits“ als auch „dieser Kunden-Login existiert bereits“ ab.
• 1013 deckt sowohl „es gibt keinen solchen Serviceplan“ (REST) als auch „Domain existiert nicht“ (XML) ab.
• 0 bedeutet kein Code, nicht kein Fehler.

Bei einer Abrechnungsintegration landet der Schaden in der Wiederholungslogik. „Domain existiert bereits“ nach einer bezahlten Bestellung kann bedeuten, dass der vorige Versuch halb gelang und Sie nachsehen sollten, bevor Sie es erneut versuchen; „kein solcher Serviceplan“ bedeutet, dass die Bestellung nie gelingen wird und vor einen Menschen gehört. Sie teilen sich eine Familie von Codes. Also klassifiziert der Text, und diese Zuordnung gehört an genau eine Stelle in Ihrem Code, statt an jeder Aufrufstelle neu abgeleitet zu werden.

Es gibt auch eine fünfte Fehlerform: Fragen Sie REST nach einer Route, die es nicht gibt, und es antwortet mit einer HTML-Seite, nicht mit JSON.

Eine fehlgeschlagene Bestellung kann den erneuten Versuch blockieren

Gemessen: Eine Domain gegen einen Serviceplan anzulegen, den es nicht gibt, liefert HTTP 404 mit einer klaren Meldung, und das Domain-Objekt existiert danach trotzdem, ohne Hosting-Typ und mit leerem Document-Root. Plesk legt zuerst das Objekt an und wendet danach den Plan an und macht nichts rückgängig, wenn der zweite Schritt scheitert.

In einem Abrechnungsablauf liest sich das so: Der Kunde hat bezahlt, die Provisionierung scheiterte, und der erneute Versuch scheitert nun anders, weil die Domain durch ein Konto in Gebrauch ist, das er nie erhalten hat. Der zweite Fehler sieht aus wie eine doppelte Bestellung, was zu den verwirrenderen Dingen gehört, die man aus einem Supportticket heraus debuggt.

Zwei günstige Dinge folgen. Lösen Sie den Plan auf, bevor Sie irgendetwas anlegen: Sie haben die Planliste schon, schlagen Sie den Namen also lokal nach und lassen Sie die Bestellung scheitern, bevor Sie das Panel berühren, was diesen Fehler beseitigt, statt ihn zu behandeln. Und räumen Sie nach einem fehlgeschlagenen Anlegen auf, denn das Wrack liegen zu lassen macht aus einer fehlgeschlagenen Bestellung einen dauerhaft blockierten Domainnamen.

Zum Vergleich: Ein Feld-Validierungsfehler wie ein doppelter Kunden-Login liefert HTTP 400 und hinterlässt nichts. Diese Prüfung läuft vor der Erstellung; nur die Plansuche kommt zu spät, um Sie zu retten.

Zwei Aufrufe, die jeweils eine Mitte haben

Ein Abonnement zu entfernen bedeutet DELETE /domains/{id} und dann DELETE /clients/{id}. Gelingt der erste und der zweite nicht, bleibt Ihnen ein Kundendatensatz, der nichts besitzt: in den meisten Ansichten unsichtbar und ein Doppel-Login-Fehler beim nächsten Mal, wenn dieser Kunde zurückkommt. Mit 7.7 Sekunden ist das Löschen auch lang genug, dass ein Netzwerk es unterbrechen kann, deshalb verdient eine Kündigung dieselbe Behandlung wie eine Provisionierung: Lesen Sie danach das Panel zurück und gleichen Sie gegen den Sammel-Lesevorgang ab, nicht gegen die Antwort, die Sie erhalten haben.

Upgrades und Downgrades haben ihre eigene Ecke. <webspace><switch-subscription> akzeptiert keinen Plannamen, nur die GUID des Plans oder seine externe ID, wo überall sonst in Plesk ein Paket über den Namen referenziert wird. Provibr behält den Namen als das, was Menschen sehen, und erledigt die Übersetzung von Name zu GUID intern aus der Planliste, die die Abfrage ohnehin holt. Stattdessen eine GUID in Ihrem Abrechnungssystem zu speichern funktioniert genau so lange, bis jemand einen Plan neu aufbaut.

Wo die Rechnung wohnt

Die drei Momente oben sind nur die Hälfte eines Hosting-Produkts. Die andere Hälfte ist, wie Ihre eigene Rechnung aussieht.

Sie zahlen für Kapazität, je Ressourcentyp, und ein Hosting-Konto ist einer davon. Jedes Abonnement zählt, ob es läuft oder nicht; nur ein stillgelegtes zählt nicht. Das ist für die Mahnung genau herum: Einen überfälligen Kunden stillzulegen gibt den Platz frei, während seine Daten unangetastet bleiben, und das Fortsetzen nimmt ihn wieder.

Ihr Limit zu überschreiten wird nicht in dem Moment blockiert, in dem es geschieht. Es wird erkannt, Ihnen wird gesagt, welcher Ressourcentyp und um wie viel, und Sie bekommen einen Werktag, um es zu beheben. Läuft der ab, werden die neuesten Server oberhalb des Limits ausgeschaltet, die neuesten zuerst, damit das zuerst Gebaute überlebt. Eine zweite Überschreitung innerhalb einer Woche bekommt eine Stunde statt eines Tages, weil sich die Schonfrist sonst beliebig oft erneuern ließe, indem man kurz unter das Limit geht und wieder darüber. Ist es behoben, wird nichts für Sie wieder gestartet: Eine Maschine einzuschalten ist eine Entscheidung, und die Plattform trifft sie nicht, während niemand zusieht.

Jeder Zeitraum ergibt eine Proformarechnung, die Sie lesen und drucken können, wobei die endgültige Rechnung aus der Buchhaltung als Datei kommt. Eine Rechnungsposition hält den Paketnamen so fest, wie er zum Zeitpunkt der Rechnungsstellung lautete, ein Plan später umzubenennen schreibt die Historie also nicht um.

Was Provibr tut, und was es bewusst nicht tut

Provibr sitzt zwischen Ihrer Abrechnung und Ihrem Plesk-Server. Ein Abonnement ist eine gewöhnliche Zeile: bestellen, stilllegen, fortsetzen, seinen Serviceplan wechseln, löschen. Das Stilllegen geht über das Feld, das die Abfrage liest. Der Plan wird vor dem Anlegen aufgelöst, und ein fehlgeschlagenes Anlegen wird aufgeräumt. Jede Mutation endet damit, das Abonnement zurückzulesen, sodass gespeichert wird, was beobachtet wurde, und nicht, was angefordert wurde. Der Agent wählt sich von Ihrem eigenen Netzwerk aus nach außen, sodass Port 8443 nicht zum Internet zeigen muss.

Was es nicht tut: den Plesk-Server selbst verwalten oder in ein Abonnement hineingreifen. Es fragt Plesk auch nie nach den Datensätzen, die das FTP-Passwort oder den Passwort-Hash des Kunden enthalten (die das Panel beide im Klartext herausgibt, wenn Sie sie anfordern).

Weiterlesen

• Webhosting mit Plesk verkaufen: das Produktmodell, die zwei APIs und was wir das Panel nie fragen.
• Abrechnung und Lizenz: Kapazität, Staffelpreise, Guthaben, Proformarechnungen und was bei einer Überschreitung passiert.
• Plesk einrichten: der API-Key, Servicepläne, Webpläne und Abonnements importieren.

Gemessen an Plesk Obsidian 18.0.80 im August 2026, mit den Antworten als Fixtures aufgezeichnet. Wiederholtes Stilllegen, auf einen Reseller beschränkte Keys und das Verhalten unter realer Verkehrslast wurden nicht gemessen und sind oben als solche vermerkt.