Automatiser la facturation WISP

WISP suspendra un serveur pour vous, et il fera tenir cette suspension : un client qui détient encore ses identifiants de panneau ne peut pas appuyer sur démarrer. Ce que WISP n’a pas, et n’a jamais prétendu avoir, c’est la moindre idée de savoir si ce client vous a payé.

Cette page traite de la couche intermédiaire. Elle traite aussi de la seule chose qui distingue WISP de tous les autres panneaux de jeu présents ici, et qui n’a rien à voir avec son API : le panneau ne vous appartient pas.

Le panneau est hébergé, le nœud est à vous

WISP se vend comme un service hébergé. wisp.gg fait tourner le panneau ; le nœud qui porte vos serveurs de jeu tourne sur votre propre matériel. Un agent placé dans votre réseau parle vers l’extérieur au panneau via son API, et au démon de votre nœud pour la console, si bien que rien n’a besoin d’être ouvert sur internet.

Pour une intégration de facturation, cette séparation a une conséquence bien réelle : il n’y a rien à mettre à jour de votre côté et rien à épingler. WISP peut modifier son API sans aucune version que vous contrôliez. Provibr est testé contre la 3.7.5 et lit la version en cours depuis le panneau lui-même, si bien qu’une dérive apparaît dans le test de connexion plutôt que dans une commande échouée à deux heures du matin.

Un détail voisin mérite d’être connu avant d’accuser votre propre code. La porte d’entrée du panneau se trouve derrière un challenge Cloudflare ; chaque chemin /api/… passe directement. Cela a été mesuré avec trois agents utilisateurs différents et tous les trois ont répondu 200. C’est un réglage chez wisp.gg, pas de votre côté ni du nôtre, si bien que le jour où WISP poserait le même challenge sur l’API, toutes les intégrations WISP s’arrêteraient d’un coup et il n’y aurait rien à corriger localement. La panne a une forme reconnaissable (403, un en-tête Cf-Mitigated: challenge, et du HTML au lieu de JSON) et mérite son propre message, pour que le panneau dise il ne nous laisse pas entrer plutôt que mauvaise clé.

Le cycle de vie, en correspondance

Cinq actions, et toutes les cinq répondent par un 204 vide. Il n’y a littéralement rien dans le corps, si bien que la règle de la maison s’applique sans exception : aucune mutation ne fait confiance à sa propre réponse. Relisez le serveur ensuite.

La suspension est réelle, et elle est idempotente

Cette combinaison est plus rare qu’elle ne devrait l’être parmi les panneaux de jeu, et c’est toute la raison pour laquelle une campagne de relance sur WISP est ennuyeuse au bon sens du terme.

Une deuxième suspension sur un serveur déjà suspendu répond de nouveau 204. Rien à traiter comme un cas particulier, rien à considérer comme « c’était déjà le cas », aucune erreur à avaler. Comparez avec les panneaux de contrôle où suspendre deux fois donne une erreur d’authentification, et vous verrez quelle part d’une intégration de relance passe d’ordinaire à s’excuser pour le panneau.

Supprimer fonctionne aussi sur un serveur suspendu, ce qui compte pour la résiliation qui arrive un mois après la suspension. Une deuxième suppression répond 404, ce qui est le résultat correct pour un déclencheur de résiliation : il ne reste rien à nettoyer.

Les règles d’état du côté Provibr sont plus strictes que celles du panneau, volontairement :

Relisez deux fois la ligne suspend. Vous pouvez suspendre un serveur déjà arrêté, et un serveur encore en cours d’installation. Si la suspension ne fonctionnait que sur des serveurs en marche, un client pourrait arrêter son propre serveur, cesser de payer et devenir intouchable. Une application de la règle que l’on contourne en appuyant sur stop n’en est pas une, et une résiliation qui arrive au milieu d’une installation ne devrait pas attendre la fin de celle-ci.

Deux clés, aucun préfixe, et l’erreur qui s’ensuit

WISP conserve la séparation de Pterodactyl entre deux surfaces d’API, et aucune clé unique ne couvre les deux. La clé de gestion construit, suspend, réinstalle et supprime ; la clé client gère l’alimentation, les statistiques en direct et la console. Les deux se créent sur un compte administrateur.

Voici le piège. Les clés WISP ne portent aucun préfixe, contrairement au ptla_ de Pterodactyl ou au papp_ de Pelican : ce sont 48 caractères sans tête reconnaissable, si bien que rien ne peut vous dire que vous les avez collées à l’envers. Ni nous, ni le panneau, car WISP répond à une mauvaise clé par un 403 et un message vide. Un 403 signifie normalement cette clé n’a pas le droit de faire cela, si bien qu’un client qui a interverti ses deux clés entre dans le panneau et se met à cocher des permissions qui n’ont jamais été le problème. Si le test de connexion échoue, intervertissez les deux clés avant de changer quoi que ce soit d’autre.

L’autre moitié de cet identifiant mérite une phrase dans votre propre procédure : la clé de gestion ne sert pas qu’à gérer des serveurs. La même liste de nœuds que lit une intégration transporte aussi la clé de licence de votre nœud et le jeton de son démon. Traitez-la comme un identifiant valable pour le panneau entier, et révoquez-la dans WISP si vous déconnectez un jour l’intégration.

Rien n’est instantané, et l’API le dit

Votre panneau vit dans votre propre réseau et l’agent se connecte vers l’extérieur, si bien qu’un point d’accès qui modifie une machine ne peut pas répondre par le résultat. Il répond que l’ordre a été accepté et vous remet de quoi en suivre la suite :

POST /v1/servers/{serverId}/actions/suspend
Authorization: Bearer pvk_...
Idempotency-Key: dunning-inv-10482

{
  "command": {
    "id": "cmd_...",
    "kind": "game.suspend",
    "status": "pending"
  }
}

Vous obtenez 202 Accepted, pas 200. Ensuite vous relisez la commande jusqu’à ce que son statut soit définitif : done, failed, timed_out ou cancelled. La lecture ne fonctionne jamais ainsi, car un inventaire ou une facture vient d’une base de données et non de votre hôte.

Tout ce qui crée quelque chose accepte un Idempotency-Key que vous composez vous-même. Indexez-le sur quelque chose de stable de votre côté, le numéro de facture plus l’étape de relance par exemple, et un cron qui tourne toutes les quinze minutes, un webhook renvoyé et un administrateur qui clique deux fois deviennent tous inoffensifs.

Deux formes qui ont cassé cette intégration avant que vous ne la rencontriez

Toutes deux méritent d’être lues même si vous ne touchez jamais à WISP, car toutes deux relèvent du genre de panne qui signale un succès.

Chaque identité est une chaîne préfixée, pas un nombre. Un serveur WISP, c’est server_01m0n8m94afcj2kk5mzt9z379q ; les nœuds, les eggs et les allocations ont la même allure. La plateforme vérifiait qu’un identifiant externe de serveur de jeu était fait de lettres et de chiffres, ce qui est vrai de tous les autres panneaux de jeu et faux ici. Le résultat n’était pas un message d’erreur : les clients WISP au-delà de leur limite étaient signalés au processus d’application de la règle, puis ignorés, à chaque tour, indéfiniment. Ils étaient marqués et jamais suspendus. Une seule vérification d’identité partagée couvre désormais les deux formes.

Un poids de disque à zéro est refusé. WISP exige limits.io et demande une valeur comprise entre 10 et 1000. Le champ correspondant du plan vaut zéro par défaut sur la plateforme, si bien que chaque commande WISP se serait terminée par un 422 portant sur un champ dont la plupart des gens n’ont jamais entendu parler. Il y a maintenant deux garde-fous : le formulaire de plan refuse un zéro et dit pourquoi, et l’agent relève un zéro au poids par défaut avant l’envoi. Deux garde-fous pour une seule erreur, c’est délibéré, car l’un des deux se trouve du côté que vous voyez.

Ce que vous ne pouvez pas voir, et ne devez pas faire semblant de voir

C’est la partie honnête, et elle est courte.

• Il n’existe aucun champ de statut sur un serveur WISP. Pterodactyl en a un, avec installing et install_failed dedans. WISP a suspended et container.installed, deux booléens. Une installation échouée ressemble donc exactement à une installation réussie : installed reste false dans les deux cas. En construction et cassé donnent la même image sur cette surface, et un produit qui prétend le contraire devine.
• Un nœud ne rapporte pas sa propre occupation. Le champ que les autres panneaux utilisent pour cela est absent, y compris quand on le demande explicitement. L’occupation est donc calculée à partir des serveurs, ce qui fonctionne et coûte un appel de plus.
• Il n’y a pas d’uptime dans les statistiques en direct. Un conteneur qui a redémarré entre deux relevés ne peut pas être reconnu avec certitude. En regard, WISP ne met pas ces statistiques en cache pendant vingt secondes comme le fait Pterodactyl, si bien que les graphiques n’inventent pas un creux qui n’a jamais eu lieu. Meilleur au total, avec un angle vif.

La capacité, et comment elle rejoint les relances

Provibr vous facture la capacité, pas vos clients. Ce que vous facturez pour un serveur de jeu reste entièrement dans votre propre système de facturation ; nous ne voyons jamais une facture client et ne parlons jamais à vos clients.

La règle qui surprend tout le monde le premier mois : chaque serveur compte, qu’il tourne ou non. Un serveur suspendu ne compte pas, un serveur supprimé non plus. Arrêter une machine ne libère rien.

Cela s’articule assez proprement avec les relances. Suspendez un client pour impayé et il cesse de compter dans votre capacité à cet instant ; réactivez-le quand il paie et il recompte. Vous ne payez pas de capacité de plateforme pour quelqu’un qui ne vous paie pas.

Ce qui n’est volontairement pas automatisé

Provibr gère des serveurs, pas le panneau. Il n’installe pas WISP, ne touche pas au démon de votre nœud au-delà de la console, et ne gère ni les sauvegardes, ni les règles de pare-feu, ni l’attribution d’adresses IP chez ce fournisseur : ces capacités sont désactivées dans le registre plutôt qu’à moitié implémentées. Il n’y a pas de facturation à l’usage sur WISP, car les statistiques par serveur sont affichées dans le panneau et non exposées via l’API, et un point d’accès qui n’existe pas ne peut servir de base à aucune facture.

Si vous êtes encore en train de choisir, le comparatif à lire d’abord est Choisir un panneau de jeu d’après son API, qui mesure six panneaux sur exactement une question : la suspension fait-elle quelque chose. La connexion elle-même, les deux clés et le champ d’empreinte sont traités sur la page d’intégration WISP.