Vindeți găzduire Zinn® din HostBill, Blesta sau propriul dumneavoastră sistem

Dacă rulați WHMCS, folosiți în schimb modulul WHMCS — această pagină este pentru orice altceva. Există două opțiuni, ambele gratuite și ambele sub licență GPL-2.0-or-later.

HostBill

Un modul de găzduire cu aceleași șase acțiuni ca cel pentru WHMCS.

1. Descărcați-l și dezarhivați-l.
2. Încărcați directorul zinn în includes/modules/Hosting/, astfel încât fișierele să ajungă la includes/modules/Hosting/zinn/class.zinn.php și includes/modules/Hosting/zinn/ZinnHostBillClient.php.
3. Settings → Modules → Hosting, activați Zinn Digital® și adăugați o conexiune:

• API address: https://api.zinndigital.com
• API key: cheia dumneavoastră API Zinn® (un câmp de tip password, astfel încât HostBill o stochează criptată)

1. La nivel de produs, setați Product line (de exemplu mainstream), Stack (wordpress în mod implicit) și, opțional, Application și PHP version.
2. Apăsați Test connection.

⛔ Nu redenumiți directorul zinn. Încărcătorul HostBill deduce clasa pe care o caută din numele directorului, astfel încât o redenumire produce un modul pe care panoul îl listează, dar nu îl apelează niciodată.

Orice altceva — clientul PHP

Un singur fișier, fără dependențe, fără ipoteze legate de panou. Plasați ZinnProvisioning.php în propria bază de cod și apelați șase metode.

require_once 'ZinnProvisioning.php';

$zinn = new ZinnProvisioning(getenv('ZINN_API_KEY'));

// When an order is paid — once per CUSTOMER, then once per SERVICE:
$orgId  = $zinn->account('customer-4211', 'Acme Ltd');
$siteId = $zinn->provision('service-9915', $orgId, 'acme.com', 'mainstream', 'wordpress');
// Store $orgId against your customer and $siteId against your service.

$zinn->suspend($siteId, 'INV-2026-114 unpaid');   // an invoice goes unpaid
$zinn->unsuspend($siteId);                        // they pay
$zinn->terminate($siteId);                        // they cancel — schedules a deletion

// When they click "log in to my hosting" — mint it on the CLICK, never on page render:
header('Location: ' . $zinn->signInLink($siteId));

Nu scrieți în PHP? Aceleași apeluri se găsesc în referința API și le puteți efectua din orice limbaj.

Cheia API

Șapte permisiuni și nimic mai mult: org.create, org.read, sites.create, sites.view, sites.delete, reseller.view, reseller.provision.

⛔ Nu reseller.manage. O cheie pe care o introduceți într-un panou de facturare ar trebui să poată suspenda un client pentru neplată și să îl poată autentifica; nu ar trebui să poată rescrie propriile date de conectare la gateway-ul de plată.

Cele două reguli care costă bani dacă sunt încălcate

1. Corelați contul cu CLIENTUL dumneavoastră și site-ul cu SERVICIUL dumneavoastră. A doua comandă a unui client trebuie să ajungă în contul pe care îl are deja. Dacă le corelați pe ambele cu serviciul, un client ajunge să aibă trei conturi fără legătură între ele și trei panouri de control separate.
2. Trimiteți o cheie de idempotență la fiecare creare, derivată din propriul identificator pentru elementul respectiv. Fiecare sistem de facturare reîncearcă — un callback de la gateway sosește de două ori, un administrator reia o alocare eșuată, un client dă dublu clic. Fără aceasta, a doua încercare creează un al doilea site și veți fi taxat pentru el. Ambele module și clientul PHP fac acest lucru pentru dumneavoastră; dacă apelați API-ul direct, trimiteți Idempotency-Key.

Trei câmpuri ușor de omis

Fiecare dintre ele compromite o întreagă operațiune și niciunul nu apare altfel decât ca o eroare de validare — cu excepția primului, care se manifestă ca nimic:

• ⛔⛔ Un client trebuie să fie asociat unui plan ÎNAINTE ca primul său site să fie provizionat, folosind POST /v1/reseller/clients/{orgId}/plan, iar parametrul său subscription_id trebuie transmis către POST /v1/sites. Acesta este cazul fără nicio eroare de citit. Un cont nou de client nu conține niciun abonament, iar POST /v1/sites nu are un câmp pentru plan, așa că un site provizionat fără unul nu are absolut niciun plan: factura dumneavoastră en gros este generată pe baza abonamentelor active ale clienților dumneavoastră, astfel încât nu se emite nicio linie și Zinn® nu vă facturează nimic atât timp cât găzduirea funcționează; clientul dumneavoastră nu moștenește nicio cotă, astfel încât site-ului său nu i se aplică nicio limită; și nu există nimic pe care o actualizare de plan să îl poată modifica. Comanda returnează 201, site-ul se provizionează și funcționează perfect. Nicio parte nu raportează nimic din toate acestea.

Ordinea contează: POST /v1/sites înregistrează abonamentul existent în momentul executării sale, prin urmare un plan setat ulterior nu se aplică retroactiv.

• POST /v1/sites necesită stack_type. Omiteți-l și nicio comandă nu va putea reuși.
• DELETE /v1/sites/{siteId} necesită un corp {"confirm_domain": "<the site's own domain>"} — o confirmare tastată, deoarece acesta este un verb distructiv. Omiteți-l și nicio anulare nu va reuși, astfel încât serviciul va continua să ruleze și veți continua să fiți facturat pentru el. Citiți domeniul înapoi din GET /v1/reseller/services/{siteId} în loc să utilizați propria dumneavoastră evidență: acesta este comparat cu domeniul principal al site-ului și niciodată cu un alias.

Citiți întreaga eroare, nu doar propoziția

Mesajul de refuz al validării este în mod deliberat generic — „The request was well-formed but failed validation.” — deoarece partea utilă se află în details, care indică numele câmpului și motivul. Atât modulele, cât și clientul PHP îl anexează la mesajul afișat administratorului dumneavoastră. Dacă apelați API-ul direct, citiți error.details; unele intrări conțin o valoare simplă în loc de o propoziție, acesta fiind modul în care primiți max_sites: 0 atunci când planul dumneavoastră de reseller nu mai are spațiu disponibil.

Înainte de prima dumneavoastră comandă

Site-urile pe care le cumpără clienții dumneavoastră se scad din alocarea de site-uri a planului dumneavoastră de reseller, deci aveți nevoie de un plan cu spațiu disponibil. Un test de conexiune nu poate detecta acest lucru — citește programul dumneavoastră și nu provizionează nimic — astfel încât raportează un cont funcțional care încă nu poate vinde. O comandă plasată fără o cotă disponibilă este refuzată cu un mesaj care explică exact acest lucru.

Verificați fișierul descărcat

Ambele arhive sunt furnizate prin TLS de pe propriul nostru nume de gazdă, nefiind niciodată redirecționate în altă parte, având sumele de control SHA-256 afișate lângă linkurile de descărcare de pe pagina de descărcări.