Blog · 30 iul. 2026

Automatizarea facturării pentru Pelican Panel

De la comanda plătită la un server Pelican în funcțiune și de la o factură neplătită la unul suspendat: ciclul de viață, regula asincronă și limitele sincere.

De Provibr

Pelican are un indicator suspended pe fiecare server. Nimic din Pelican nu îl setează vreodată. Această singură frază este întregul motiv pentru care există această pagină: panoul este capabil să oprească serverul unui client, dar nu are nicio idee dacă acel client a plătit.

Această pagină acoperă cum arată o automatizare care funcționează: calea comenzii, calea de relansare și părțile care sunt cu adevărat mai grele decât par.

Două niveluri de facturare, și nu sunt același lucru

Înainte de orice altceva, separați-le. Oamenii le confundă în mod constant și apoi se ceartă despre problema greșită.

Nivel	Cine facturează pe cine	Ce numără
Facturarea dumneavoastră	Dumneavoastră → clientul dumneavoastră	Un server de jocuri, pe lună, la prețul pe care îl stabiliți
Facturarea platformei	Provibr → dumneavoastră	Capacitatea: câte servere de fiecare tip puteți rula în același timp

Ceea ce le percepeți propriilor clienți, și în ce mod, rămâne în întregime în interiorul sistemului dumneavoastră de facturare. Provibr nu vede niciodată o factură de client, nu stabilește niciodată un preț în locul dumneavoastră și nu vorbește niciodată cu clienții dumneavoastră; el vă facturează capacitatea rezervată per tip de resursă, la un preț unitar care scade pe paliere pe măsură ce numărul crește.

Această separare este cea care face automatizarea posibilă. Sistemul dumneavoastră de facturare deține decizia; nivelul de aprovizionare deține execuția.

Ciclul de viață, în corespondență

Iată corespondența de care are nevoie orice automatizare a găzduirii de jocuri, indiferent ce instrumente folosiți:

Eveniment de facturare	Ce ar trebui să se întâmple	Efect în Pelican
Comandă plătită	Creați serverul din plan	Server creat din egg, alocare atribuită, se rulează instalatorul
Factură restantă	Suspendare	`suspended` setat, serverul se oprește și rămâne oprit
Plată primită	Reluare	`suspended` șters, clientul îl pornește din nou
Anulare	Ștergere	Server eliminat, alocare eliberată
Trecere la un plan superior / inferior	Reinstalare sau redimensionare	Rulează din nou scriptul de instalare al egg-ului

Pelican este confortabil aici, iar acest lucru merită spus clar, pentru că nu orice panou de jocuri este. Pelican are o adevărată primitivă de suspendare. Un server suspendat este suspendat în panou: cineva cu acces direct la Pelican nu îl poate reporni pur și simplu. Când aplicarea regulii contează, iar pentru relansare contează, aceasta este diferența dintre o politică și o dorință.

(Prin contrast: PufferPanel nu are o suspendare proprie, așa că o suspendare acolo este o noțiune de platformă pe care panoul nu o impune.)

Regula care modelează totul: nimic nu este instantaneu

Aceasta este partea pe care oamenii o greșesc când racordează un API ei înșiși.

Panoul dumneavoastră trăiește în propria dumneavoastră rețea, iar o platformă rezonabilă îl atinge printr-un agent care se conectează spre exterior, niciun port de intrare, nicio breșă în firewall. Consecința este inevitabilă: un punct final care modifică o mașină nu poate răspunde cu rezultatul. El răspunde că ordinul a fost acceptat și vă înmânează ceva de urmărit:

http

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

json

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

Primiți 202 Accepted, nu 200. Apoi citiți acea comandă până când starea ei este definitivă: done, failed, timed_out sau cancelled. O comandă care a eșuat poartă codul de eroare al agentului însuși, cu argumentele sale.

Citirea nu funcționează niciodată astfel. Un inventar, o adresă sau o factură răspunde imediat, pentru că acel răspuns vine dintr-o bază de date, nu de la gazda dumneavoastră.

Proiectați-vă declanșatoarele de facturare în jurul acestui lucru. Un declanșator care tratează „API-ul a răspuns” ca „munca este gata” va raporta succes pentru o suspendare care nu s-a întâmplat niciodată, exact în ziua în care conta.

Repetarea în siguranță a unei cereri

Tot ce creează ceva acceptă un antet Idempotency-Key de propria dumneavoastră alcătuire. Repetați aceeași cerere cu aceeași valoare și veți primi înapoi primul rezultat, în loc de un al doilea server, o a doua comandă sau o a doua debitare.

Pentru relansare, acesta nu este un moft. Un cron de un sfert de oră, un webhook reluat, un administrator care dă clic de două ori: toate trei sunt normale și toate trei ar trebui să fie inofensive. Indexați cererea pe ceva stabil din partea dumneavoastră: ID-ul facturii, ID-ul serviciului, etapa de relansare. Reutilizarea acelei valori pentru o cerere diferită este refuzată în mod intenționat: o cheie care înseamnă două lucruri nu înseamnă nimic.

Verbele și când sunt permise

Un server de jocuri acceptă șase acțiuni prin API:

start · stop · restart · kill · suspend · resume

Ele sunt păzite de starea curentă a serverului, ceea ce este mai strict decât ar putea părea:

Acțiune	Permisă din
start	stopped, error, unknown
stop / restart / kill	running, error, unknown
suspend	running, stopped, installing, error, unknown
resume	suspended
reinstall	running, stopped, error

Rândul suspend este cel interesant, și este intenționat: puteți suspenda un server care este deja oprit. Dacă suspendarea ar funcționa doar pe servere în funcțiune, un client și-ar putea opri propriul server, ar putea înceta să plătească și ar deveni imun: panoul ar refuza suspendarea pentru că nu rula nimic. Aplicarea unei reguli pe care o puteți evita apăsând „stop” nu este o aplicare.

suspend din installing contează, de asemenea: o anulare care sosește în mijlocul unei instalări nu ar trebui să aștepte terminarea acesteia.

Dintr-un panou de facturare în loc de cod

Dacă rulați deja WHMCS, nu trebuie să scrieți nimic din cele de mai sus. Provibr livrează un modul de aprovizionare pentru WHMCS sub forma unei simple arhive zip pe care o instalați singur: un produs WHMCS indică spre un plan Provibr, iar fluxul obișnuit de comandă al WHMCS se ocupă de creare, suspendare, reluare și reziliere.

Două decizii de proiectare din acest modul merită împrumutate chiar dacă vă scrieți propria punte:

O livrare care este încă în curs contează ca succes. Dacă bugetul de așteptare se epuizează în timp ce instalatorul încă lucrează, modulul raportează succes. Comanda a fost acceptată: rândul serverului există, adresa este atribuită, comanda este la agent. WHMCS nu are o stare „în curs de instalare” (Pending acolo înseamnă nu s-a întâmplat încă nimic, ceea ce este în mod demonstrabil fals). O comandă care eșuează cu adevărat este altceva: serviciul rămâne Pending, administratorul vede de ce, iar un clic repetat este inofensiv datorită cheii de idempotență.

Un server care nu mai există este o reziliere reușită. Un 404 la ștergere înseamnă patru lucruri deodată (ID necunoscut, alt cont, neatribuit acestui membru sau deja șters), iar pentru un declanșator de reziliere acțiunea corectă este identică în toate patru: nu mai este nimic de curățat. A-l trata ca pe o eroare lasă un serviciu blocat în „terminating” pentru totdeauna.

Ce nu este automatizat în mod deliberat

Frontiere sincere, pentru că acestea sunt întrebările care sosesc după ce ați vândut deja ceva:

Fără facturare pe bază de consum. Metricile per server sunt colectate și afișate în panou, dar nu încă expuse prin API. Fără un punct final, nu există facturare măsurată. Dacă produsul dumneavoastră este „plătiți pentru memoria RAM pe care ați folosit-o”, acesta nu face asta astăzi.
Fără schimbare de plan într-un singur apel. Schimbarea unui plan nu este nici la nivelul Pelican un singur apel de API. Este o reinstalare sau o schimbare de resurse, cu consecințe diferite pentru datele clientului.
Fără resetare de parolă prin API. Datele de autentificare circulă în mod tranzitoriu și nu sunt stocate nicăieri, așa că nu este nimic de retrimis.
Fără autentificare unică din panoul dumneavoastră de facturare în panoul Provibr.
Fără o buclă de reconciliere a inventarului, un refuz, nu un gol. Sincronizarea _ListAccounts a WHMCS reziliază orice serviciu absent din răspuns, iar „absent” are cauze nevinovate: un domeniu API mai îngust, un membru limitat la o parte din inventar, o limitare de debit, o pagină scurtă al cărei cursor nu a fost urmărit. Fiecare ar șterge mașini de client. În schimb, zona de client citește starea reală la fiecare afișare de pagină, ceea ce nu este o sincronizare și nici nu pretinde a fi.

Numărarea capacității și cum se întâlnește cu relansarea

Facturarea platformei numără capacitatea, nu consumul, cu o regulă care îi prinde pe toți în prima lună: fiecare server contează, în funcțiune sau nu. Doar un server suspendat nu contează, și nici unul șters. Oprirea unei mașini nu eliberează un loc.

Acest lucru se aliniază perfect cu relansarea. Un client pe care îl suspendați pentru neplată încetează să conteze pentru capacitatea dumneavoastră cât timp este suspendat și contează din nou în momentul în care plătește și îl reluați, așa că nu plătiți capacitate de platformă pentru un client care nu vă plătește.

Depășirea limitei dumneavoastră nu este blocată în momentul în care o faceți. Este detectată, vi se spune, iar dumneavoastră aveți o zi lucrătoare completă. Dacă acea perioadă de grație expiră, cele mai noi servere de peste limită sunt suspendate, cele mai noi mai întâi, astfel încât ceea ce ați construit primul să supraviețuiască.

Rularea Pelican alături de toate celelalte

O gazdă de jocuri care crește rămâne rareori pe un singur panou. Provibr acoperă panourile sale de control, hipervizoarele și panourile de joc într-un singur tablou de bord, cu un singur API și un singur număr de capacitate pentru toate.

POST /v1/servers/{id}/actions/suspend face același lucru fie că dedesubt se află un server Pelican, un server Pterodactyl sau un cont de găzduire DirectAdmin. Diferențele trăiesc în furnizor, nu în codul dumneavoastră de integrare.