WISP-facturatie automatiseren

WISP schort een server voor je op, en die opschorting houdt stand: een klant die nog paneelgegevens heeft kan niet op start drukken. Wat WISP niet heeft, en ook nooit beweert te hebben, is enig idee of die klant jou betaald heeft.

Deze pagina gaat over de laag ertussen. Hij gaat ook over het ene ding dat WISP anders maakt dan elk ander gamepaneel hier, en dat heeft niets met zijn API te maken: het paneel is niet van jou.

Het paneel is gehost, de node is van jou

WISP wordt verkocht als gehoste dienst. wisp.gg draait het paneel; de node die je gameservers draagt staat op je eigen hardware. Een agent binnen je netwerk praat uitgaand met het paneel over zijn API en met de daemon van je node voor de console, dus er hoeft niets naar het internet opengezet te worden.

Voor een facturatiekoppeling heeft die splitsing één echt gevolg: er is niets voor jou om bij te werken en niets voor jou om vast te pinnen. WISP kan zijn API wijzigen zonder een release die jij in de hand hebt. Provibr is getest tegen v3.7.5 en leest de draaiende versie uit het paneel zelf, dus afwijkingen komen boven in de verbindingstest en niet in een mislukte bestelling om twee uur 's nachts.

Nog een detail dat de moeite waard is voordat je je eigen code de schuld geeft. De voordeur van het paneel zit achter een Cloudflare-uitdaging; elk /api/…-pad gaat er dwars doorheen. Dat is gemeten met drie verschillende user agents en alle drie antwoordden 200. Het is een instelling bij wisp.gg, niet bij jou en niet bij ons, dus zet WISP diezelfde uitdaging ooit op de API, dan stopt elke WISP-koppeling tegelijk en is er lokaal niets te repareren. De storing heeft een herkenbare vorm (403, een Cf-Mitigated: challenge-kop, en HTML in plaats van JSON) en verdient een eigen melding, zodat het paneel zegt hij laat ons er niet in in plaats van verkeerde sleutel.

De levenscyclus, in kaart

Vijf acties, en alle vijf antwoorden met een lege 204. Er staat letterlijk niets in de body, dus de huisregel geldt zonder uitzondering: geen enkele mutatie vertrouwt zijn eigen antwoord. Lees de server daarna terug.

Opschorten is echt, en het is idempotent

Die combinatie is zeldzamer dan ze zou moeten zijn onder gamepanelen, en ze is de hele reden dat een aanmaanronde op WISP saai is in de goede zin.

Een tweede opschorting op een al opgeschorte server antwoordt opnieuw 204. Niets om apart af te vangen, niets om als stond al zo te behandelen, geen fout om weg te slikken. Vergelijk dat met controlepanelen waar twee keer opschorten een authenticatiefout is, en je ziet hoeveel van een aanmaankoppeling er normaal opgaat aan excuses voor het paneel.

Verwijderen werkt ook op een opgeschorte server, en dat telt bij de opzegging die een maand na de opschorting binnenkomt. Een tweede verwijdering antwoordt 404, en dat is de juiste uitkomst voor een beëindigingshook: er is niets meer op te ruimen.

De toestandsregels aan de Provibr-kant zijn strenger dan die van het paneel, met opzet:

Lees de regel voor suspend twee keer. Je kunt een server opschorten die al gestopt is, en een die nog aan het installeren is. Zou opschorten alleen op draaiende servers werken, dan kan een klant zijn eigen server stoppen, stoppen met betalen, en onaantastbaar zijn. Handhaving die je omzeilt door op stop te drukken is geen handhaving, en een opzegging die midden in een installatie binnenkomt hoort niet te wachten tot die installatie klaar is.

Twee sleutels, geen voorvoegsel, en de vergissing die erop volgt

WISP houdt de splitsing van Pterodactyl aan tussen twee API-oppervlakken, en geen enkele sleutel dekt ze allebei. De applicatiesleutel bouwt, schort op, herinstalleert en verwijdert; de clientsleutel doet stroom, live statistieken en de console. Allebei maak je ze aan op een beheerdersaccount.

Hier zit de valstrik. WISP-sleutels dragen geen voorvoegsel, anders dan ptla_ van Pterodactyl of papp_ van Pelican: het zijn 48 tekens zonder herkenbare kop, dus niets kan je vertellen dat je ze verwisseld hebt geplakt. Wij niet, en het paneel ook niet, want WISP antwoordt op een verkeerde sleutel met 403 en een lege melding. Een 403 betekent normaal deze sleutel mag dat niet, dus een klant die twee sleutels verwisselde gaat het paneel in en begint rechten aan te vinken die nooit het probleem waren. Faalt de verbindingstest, verwissel dan eerst die twee sleutels voordat je iets anders wijzigt.

De andere helft van dat inloggegeven verdient een zin in je eigen draaiboek: de applicatiesleutel is niet alleen serverbeheer. Dezelfde nodelijst die een koppeling leest draagt ook de licentiesleutel en het daemontoken van je node. Behandel hem als een inloggegeven voor het hele paneel, en trek hem in WISP in zodra je de koppeling ooit loskoppelt.

Niets is meteen klaar, en de API zegt dat ook

Je paneel staat in je eigen netwerk en de agent verbindt uitgaand, dus een endpoint dat een machine wijzigt kan niet met het resultaat antwoorden. Het antwoordt dat de opdracht is aangenomen en geeft je iets om te volgen:

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

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

Dat is 202 Accepted, niet 200. Daarna lees je het commando tot zijn status definitief is: done, failed, timed_out of cancelled. Lezen werkt nooit zo, want een inventaris of een factuur komt uit een database en niet van jouw host.

Alles wat iets aanmaakt accepteert een Idempotency-Key van je eigen makelij. Baseer hem op iets stabiels aan jouw kant, zoals het factuurnummer plus de aanmaanstap, en een cron die elke vijftien minuten draait, een herhaalde webhook en een beheerder die twee keer klikt worden alle drie onschadelijk.

Twee vormen die deze koppeling sloopten voordat jij hem zag

Allebei zijn ze het lezen waard, ook als je WISP nooit aanraakt, want allebei zijn ze het soort storing dat succes meldt.

Elke identiteit is een tekenreeks met een voorvoegsel, geen getal. Een WISP-server is server_01m0n8m94afcj2kk5mzt9z379q; nodes, eggs en allocaties zien er hetzelfde uit. Het platform had een controle die eiste dat een extern gameserver-id uit letters en cijfers bestond, wat op elk ander gamepaneel klopt en hier niet. Het gevolg was geen foutmelding: WISP-klanten boven hun limiet werden aan de handhavingsworker gemeld en daarna overgeslagen, elke ronde opnieuw, voor altijd. Ze werden gemarkeerd en nooit opgeschort. Eén gedeelde identiteitscontrole dekt nu allebei de vormen.

Een schijfgewicht van nul wordt geweigerd. WISP vereist limits.io en eist een waarde tussen 10 en 1000. Het planveld van het platform staat standaard op nul, dus elke WISP-bestelling zou geëindigd zijn in een 422 over een veld waar de meeste mensen nog nooit van gehoord hebben. Er staan nu twee hekken: het planformulier weigert een nul en zegt waarom, en de agent tilt een nul naar het standaardgewicht voordat hij verstuurt. Twee hekken voor één vergissing is bewust, want een van de twee staat aan de kant die je kunt zien.

Wat je niet kunt zien, en niet moet doen alsof

Dit is het eerlijke deel, en het is kort.

• Een WISP-server heeft geen statusveld. Pterodactyl heeft er wel een, met installing en install_failed erin. WISP heeft suspended en container.installed, allebei booleans. Een mislukte installatie ziet er daardoor precies zo uit als een lopende: installed blijft in beide gevallen false. In aanbouw en stuk zijn op dit oppervlak hetzelfde plaatje, en een product dat iets anders beweert gokt.
• Een node meldt zijn eigen bezetting niet. Het veld dat andere panelen daarvoor gebruiken ontbreekt, ook als je er expliciet om vraagt. De bezetting wordt in plaats daarvan uit de servers opgeteld, wat werkt en één aanroep meer kost.
• Er zit geen uptime in de live statistieken. Een container die tussen twee pollrondes herstartte is niet met zekerheid te herkennen. Daar staat tegenover dat WISP die statistieken niet twintig seconden cachet zoals Pterodactyl doet, dus de grafieken verzinnen geen dip die nooit gebeurd is. Netto beter, met één scherpe rand.

Capaciteit, en hoe die aanmaningen raakt

Provibr factureert jou voor capaciteit, niet voor je klanten. Wat jij voor een gameserver rekent blijft volledig binnen je eigen facturatiesysteem; wij zien nooit een klantfactuur en praten nooit met je klanten.

De regel waar iedereen in maand één op stukloopt: elke server telt mee, draaiend of niet. Een opgeschorte niet, en een verwijderde ook niet. Een machine stoppen maakt niets vrij.

Dat sluit netjes aan op aanmaningen. Schort een klant op wegens niet betalen en hij telt vanaf dat moment niet meer mee voor je capaciteit; hervat hem zodra hij betaalt en hij telt weer mee. Je betaalt geen platformcapaciteit voor iemand die jou niet betaalt.

Wat bewust niet geautomatiseerd is

Provibr beheert servers, niet het paneel. Het installeert WISP niet, raakt de daemon van je node niet aan buiten de console om, en beheert bij deze provider geen backups, firewallregels of IP-toewijzing: die capabilities staan uit in het register in plaats van half gebouwd te zijn. Er is geen verbruiksfacturatie op WISP-gebruik, want de cijfers per server staan in het paneel en zijn niet over de API ontsloten, en tegen een endpoint dat niet bestaat valt niet te factureren.

Ben je nog aan het kiezen, dan is de vergelijking die je eerst moet lezen Een gamepaneel kiezen op zijn API, die zes panelen meet op precies één vraag: of een opschorting iets doet. De verbinding zelf, de twee sleutels en het vingerafdrukveld staan op de integratiepagina van WISP.