Magbenta ng Zinn® hosting mula sa HostBill, Blesta, o sa sarili mong sistema

Kung gumagamit kayo ng WHMCS, gamitin ang WHMCS module sa halip — ang pahinang ito ay para sa lahat ng iba pa. Mayroong dalawang opsyon, parehong libre at parehong GPL-2.0-or-later.

HostBill

Isang hosting module na may parehong anim na aksyon tulad ng sa WHMCS.

I-download ito at i-unzip.
I-upload ang zinn directory sa includes/modules/Hosting/ upang ang mga file ay mapunta sa

includes/modules/Hosting/zinn/class.zinn.php at includes/modules/Hosting/zinn/ZinnHostBillClient.php.

Settings → Modules → Hosting, i-activate ang Zinn Digital®, at magdagdag ng koneksyon:

API address: https://api.zinndigital.com
API key: ang inyong Zinn® API key (isang password field, kaya itinatago ito ng HostBill nang nakatago/encrypted)

Sa produkto, i-set ang Product line (hal. mainstream), Stack (wordpress bilang

default), at opsyonal ang Application at PHP version.

Pindutin ang Test connection.

⛔ Huwag palitan ang pangalan ng zinn directory. Ang loader ng HostBill ay nagmumula sa pangalan ng directory para sa class na hinahanap nito, kaya ang pagpapalit ng pangalan ay magbubunga ng module na nakalista sa panel ngunit hindi kailanman tinatawag.

Anuman pang iba — ang PHP client

Isang file, walang dependencies, walang inaasahang panel. I-drop ang ZinnProvisioning.php sa inyong sariling codebase at tumawag ng anim na method.

require_once 'ZinnProvisioning.php';

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

// Kapag ang isang order ay bayad na — minsan bawat CUSTOMER, pagkatapos ay minsan bawat SERVICE:
$orgId  = $zinn->account('customer-4211', 'Acme Ltd');
$siteId = $zinn->provision('service-9915', $orgId, 'acme.com', 'mainstream', 'wordpress');
// I-store ang $orgId laban sa inyong customer at ang $siteId laban sa inyong service.

$zinn->suspend($siteId, 'INV-2026-114 unpaid');   // ang isang invoice ay hindi nabayaran
$zinn->unsuspend($siteId);                        // nagbayad sila
$zinn->terminate($siteId);                        // nag-cancel sila — nag-iskedyul ng pagbura

// Kapag pinindot nila ang "log in to my hosting" — i-mint ito sa PAG-CLICK, huwag kailanman sa page render:
header('Location: ' . $zinn->signInLink($siteId));

Hindi nagsusulat ng PHP? Ang parehong mga call ay matatagpuan sa API reference at maaari ninyo itong gawin mula sa alinman.

Ang API key

Pitong pahintulot, at wala nang iba pa: org.create, org.read, sites.create, sites.view, sites.delete, reseller.view, reseller.provision.

⛔ Hindi reseller.manage. Ang key na ipe-paste ninyo sa isang billing panel ay dapat na may kakayahang mag-hold ng isang client dahil sa hindi pagbabayad at i-sign in sila; hindi ito dapat may kakayahang baguhin ang inyong sariling mga kredensyal sa payment-gateway.

Ang dalawang alituntunin na nagkakahalaga ng pera kapag nasira

I-key ang account sa inyong CUSTOMER, at ang site sa inyong SERVICE. Ang pangalawang

order ng isang customer ay dapat mapunta sa account na mayroon na sila. Kapag i-key ang pareho sa service, ang isang customer ay magtatapos sa tatlong walang kaugnayang account at tatlong magkahiwalay na control panel.

Magpadala ng idempotency key sa bawat paglikha, na hango sa inyong sariling id para sa bagay na iyon. Ang bawat

billing system ay nagsu-subok ulit — ang isang gateway callback ay dumarating nang dalawang beses, ang isang admin ay muling nagpapatakbo ng nabagong provision, ang isang customer ay nag-double click. Kung wala ito, ang pangalawang pagsubok ay lumilikha ng pangalawang site at sisingilin kayo para dito. Ginagawa ito ng parehong module at ng PHP client para sa inyo; kung direktang tinatawag ninyo ang API, magpadala ng Idempotency-Key.

Tatlong field na madaling maiwanan

Ang bawat isa ay nakakasira ng isang buong verb, at walang lumalabas bilang alinman maliban sa isang validation error — maliban sa una, na lumalabas bilang wala man lang:

⛔⛔ Ang isang client ay dapat ilagay sa isang plan BAGO ang kanilang unang site ay ma-provision, gamit ang

POST /v1/reseller/clients/{orgId}/plan, at ang subscription_id nito ay ipapasa sa POST /v1/sites. Ito ang isa na walang error na mababasa. Ang isang bagong client account ay walang hawak na subscription at ang POST /v1/sites ay walang plan field, kaya ang isang site na na-provision nang wala nito ay nagtataglay ng walang plan man lang: ang inyong wholesale statement ay binuo mula sa mga live na subscription ng inyong mga client, kaya walang linya na itataas at walang isisingil sa inyo ang Zinn® hangga'ts gumagana ang hosting; ang inyong client ay walang mana na allowances, kaya walang quota na ilalapat sa kanilang site; at walang anumang babaguhin para sa isang upgrade. Ang order ay nagbabalik ng 201, ang site ay nag-pro-provision, at ito ay gumagana nang perpekto. Walang anuman sa alinmang dulo ang nag-uulat ng alinman dito.

Mahalaga ang pagkakasunod-sunod: itinatala ng POST /v1/sites ang anumang subscription na umiiral sa sandaling tumakbo ito, kaya ang isang plan na itinakda pagkatapos ay hindi nakakabit nang pabalik.

Kailangan ng POST /v1/sites ang stack_type. Laktawan ito at walang order ang magtatagumpay.
**Kailangan ng DELETE /v1/sites/{siteId} ang body na `{"confirm_domain": "<the site's own

domain>"}** — isang na-type na kumpirmasyon, dahil ito ang destructive verb. Laktawan ito at walang pagkansela ang magtatagumpay, kaya ang serbisyo ay patuloy na gagana at patuloy kayong sisingilin para dito. Basahin muli ang domain mula sa GET /v1/reseller/services/{siteId}` sa halip na gamitin ang inyong sariling rekord: ito ay inihahambing laban sa sariling primary domain ng site at hindi kailanman laban sa isang alias.

Basahin ang buong error, hindi lang ang pangungusap

Ang mensahe ng isang validation refusal ay sadyang pangkalahatan — "The request was well-formed but failed validation." — dahil ang kalahati na maaaring aksyunan ay nasa details, na nagpapangalan sa field at kung bakit. Idinagdag ito ng parehong module at ng PHP client sa mensahe na ipinapakita nila sa inyong admin. Kung kayo mismo ang tumatawag sa API, basahin ang error.details; ang ilang entry ay nagtataglay ng nakatagong halaga sa halip na isang pangungusap, kung paano nakakarating sa inyo ang max_sites: 0 kapag ang inyong reseller plan ay walang bakante.

Bago ang inyong unang order

Ang mga site na binibili ng inyong mga client ay nabibilang laban sa site allowance ng inyong reseller plan, kaya kailangan ninyo ng isang plan na may bakante dito. Hindi ito matukoy ng isang connection test — binabasa nito ang inyong programa at walang pino-provision — kaya nag-uulat ito ng isang malusog na account na hindi pa makakapagbenta. Ang isang order na inilagay nang walang allowance ay tatanggihan sa isang mensahe na nagsasabi nang eksakto niyon.

I-verify ang inyong download

Ang parehong archive ay inihahain sa TLS mula sa aming sariling hostname, hindi kailanman nai-redirect sa ibang lugar, kasama ang kanilang mga SHA-256 checksum na nakalimbag sa tabi ng mga download link sa pahina ng mga download.