Վաճառեք Zinn® հոսթինգ HostBill-ի, Blesta-ի կամ ձեր սեփական համակարգի միջոցով

Եթե օգտագործում եք WHMCS, փոխարենը օգտագործեք WHMCS մոդուլը՝ այս էջը նախատեսված է մնացած ամեն ինչի համար։ Կա երկու տարբերակ, երկուսն էլ անվճար են և երկուսն էլ՝ GPL-2.0-or-later արտոնագրով։

HostBill

Հոսթինգի մոդուլ՝ WHMCS-ի նույն վեց գործողություններով։

1. Ներբեռնեք այն և ապակոմպրեսավորեք։
2. Վերբեռնեք zinn գրացուցակը includes/modules/Hosting/ թղթապանակի մեջ, այնպես որ ֆայլերը հայտնվեն

includes/modules/Hosting/zinn/class.zinn.php և includes/modules/Hosting/zinn/ZinnHostBillClient.php հասցեներում։

3. Settings → Modules → Hosting, ակտիվացրեք Zinn Digital®-ը և ավելացրեք միացում.

• API address: https://api.zinndigital.com
• API key: ձեր Zinn® API բանալին (password դաշտ, որպեսզի HostBill-ը պահպանի այն գաղտնագրված)

1. Ապրանքի համար սահմանեք Product line (օր.mainstream), Stack (լռելյայն՝

wordpress) և ըստ ցանկության՝ Application և PHP version։

2. Սեղմեք Test connection։

⛔ Մի վերանվանեք zinn գրացուցակը։ HostBill-ի բեռնիչը որոնվող դասը բխեցնում է գրացուցակի անունից, ուստի վերանվանումը ստեղծում է մի մոդուլ, որը վահանակը ցանկում ցույց է տալիս, բայց երբեք չի կանչում։

Ամեն ինչ այլ՝ PHP հաճախորդ

Մեկ ֆայլ, առանց կախվածությունների, առանց վահանակի նախադրյալների։ Տեղադրեք ZinnProvisioning.php-ն ձեր սեփական ծրագրային կոդի մեջ և կանչեք վեց մեթոդ։

require_once 'ZinnProvisioning.php';

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

// Երբ պատվերը վճարված է՝ մեկ անգամ ՅՈՒՐԱՔԱՆՉՅՈՒՐ ՀԱՃԱԽՈՐԴԻ ՀԱՄԱՐ, այնուհետև մեկ անգամ ՅՈՒՐԱՔԱՆՉՅՈՒՐ ԾԱՌԱՅՈՒԹՅԱՆ ՀԱՄԱՐ.
$orgId  = $zinn->account('customer-4211', 'Acme Ltd');
$siteId = $zinn->provision('service-9915', $orgId, 'acme.com', 'mainstream', 'wordpress');
// Պահպանեք $orgId-ն ձեր հաճախորդի և $siteId-ն ձեր ծառայության համար։

$zinn->suspend($siteId, 'INV-2026-114 unpaid');   // հաշիվը մնում է անվճար
$zinn->unsuspend($siteId);                        // նրանք վճարում են
$zinn->terminate($siteId);                        // նրանք չեղարկում են. նախատեսում է ջնջում

// Երբ նրանք սեղմում են «մուտք գործել իմ հոսթինգ» — թողարկեք այն ՍԵՂՄՄԱՆ պահին, երբեք էջի բեռնման ժամանակ.
header('Location: ' . $zinn->signInLink($siteId));

Չե՞ք գրում PHP-ով։ Նույն կանչերը առկա են API տեղեկատուում և դրանք կարող եք կատարել ցանկացած բանից։

API բանալին

Յոթ թույլտվություն և ոչ ավելին՝ org.create, org.read, sites.create, sites.view, sites.delete, reseller.view, reseller.provision։

⛔ Ոչ թե reseller.manage։ Վճարային վահանակի մեջ տեղադրված բանալին պետք է կարողանա սառեցնել հաճախորդի հաշիվը չվճարելու դեպքում և մուտք գործել նրա փոխարեն. այն չպետք է կարողանա վերագրել ձեր սեփական վճարային դարպասի հավատարմագրերը։

Երկու կանոնները, որոնք արժեն գումար, երբ խախտվում են

1. Կապեք հաշիվը ձեր ՀԱՃԱԽՈՐԴԻ, իսկ կայքը՝ ձեր ԾԱՌԱՅՈՒԹՅԱՆ հետ։ Հաճախորդի երկրորդ

պատվերը պետք է հայտնվի այն հաշվում, որն արդեն ունի։ Երկուսն էլ կապեք ծառայության հետ, և մի հաճախորդ կվերջացնի երեք անկապ հաշիվներով և երեք առանձին կառավարման վահանակներով։

2. Ուղարկեք անփոփոխության բանալի (idempotency key) յուրաքանչյուր ստեղծման ժամանակ՝ բխեցված իրի համար ձեր սեփական id-ից։ Յուրաքանչյուր

վճարային համակարգ կրկնում է փորձը. դարպասի հետադարձ կանչը ժամանում է երկու անգամ, ադմինիստրատորը նորից է գործարկում ձախողված տրամադրումը, հաճախորդը կրկնակի սեղմում է։ Առանց դրա երկրորդ փորձը ստեղծում է երկրորդ կայք և դրա համար ձեզանից գումար է գանձվում։ Երկու մոդուլներն էլ և PHP հաճախորդն անում են սա ձեզ համար. եթե դուք կանչում եք API-ն անմիջապես, ուղարկեք Idempotency-Key։

Երեք դաշտ, որոնք հեշտ է բաց թողնել

Դրանցից յուրաքանչյուրը խախտում է ամբողջական հրամանը, և ոչ մեկը չի երևում որպես այլ բան, քան վավերացման սխալ, բացառությամբ առաջինի, որը երևում է որպես ընդհանրապես ոչինչ.

• ⛔⛔ Հաճախորդին պետք է տեղադրել պլանի վրա ՆԱԽՔԱՆ նրա առաջին կայքի տրամադրումը,

POST /v1/reseller/clients/{orgId}/plan հրամանով, և նրա subscription_id-ն փոխանցել POST /v1/sites-ին։ Սա այն դեպքն է, երբ ընթերցելու սխալ չկա։ Նոր հաճախորդի հաշիվը բաժանորդագրություն չունի, և POST /v1/sites-ը պլանի դաշտ չունի, ուստի առանց դրա տրամադրված կայքը կրում է ընդհանրապես ոչ մի պլան. ձեր մեծածախ հաշվետվությունը կառուցված է ձեր հաճախորդների գործող բաժանորդագրություններից, ուստի ոչ մի տող չի ստեղծվում և Zinn®-ը ոչինչ չի գանձում ձեզանից քանի դեռ հոսթինգն աշխատում է. ձեր հաճախորդը չի ժառանգում որևէ արտոնություն, ուստի որևէ քվոտա չի կիրառվում նրա կայքի նկատմամբ. և չկա որևէ բան, որը թարմացումը կարող է փոխել։ Պատվերը վերադարձնում է 201, կայքը տրամադրվում է և աշխատում է կատարելապես։ Ոչ մի կողմում ոչինչ չի հայտնում այս մասին։

Հերթականությունը կարևոր է. POST /v1/sites-ը գրանցում է ցանկացած բաժանորդագրություն, որը գոյություն ունի այն պահին, երբ այն աշխատում է, ուստի հետագայում սահմանված պլանը հետադարձ կերպով չի կցվում։

• POST /v1/sites-ը պահանջում է stack_type: Բաց թողեք այն, և ոչ մի պատվեր չի կարող հաջողվել։
• **DELETE /v1/sites/{siteId}-ը պահանջում է `{"confirm_domain": "<the site's own

domain>"} մարմին** — մուտքագրված հաստատում, քանի որ սա կործանարար հրաման է։ Բաց թողեք այն, և ոչ մի չեղարկում չի կարող հաջողվել, հետևաբար ծառայությունը շարունակում է աշխատել, և ձեզանից շարունակում են գումար գանձել դրա համար։ Կարդացեք դոմենը GET /v1/reseller/services/{siteId}` հասցեից՝ ձեր սեփական գրառումն օգտագործելու փոխարեն. այն համեմատվում է կայքի սեփական առաջնային դոմենի հետ և երբեք՝ կեղծանունի հետ։

Կարդացեք ամբողջ սխալը, ոչ միայն նախադասությունը

Վավերացման մերժման հաղորդագրությունը միտումնավոր ընդհանուր է՝ «Հարցումը ձևավորված էր ճիշտ, բայց չհաջողվեց անցնել վավերացումը», քանի որ գործող կեսը գտնվում է details-ում, որը նշում է դաշտը և պատճառը։ Երկու մոդուլներն էլ և PHP հաճախորդն այն կցում են իրենց ադմինիստրատորին ցուցադրվող հաղորդագրությանը։ Եթե դուք ինքներդ եք կանչում API-ն, կարդացեք error.details-ը. որոշ գրառումներ պարունակում են մերկ արժեք՝ նախադասության փոխարեն, ինչպես ձեզ է հասնում max_sites: 0-ն, երբ ձեր վերավաճառողի պլանում տեղ չկա։

Նախքան ձեր առաջին պատվերը

Կայքերը, որոնք գնում են ձեր հաճախորդները, հաշվարկվում են ձեր վերավաճառողի պլանի կայքերի սահմանաչափի դեմ, ուստի ձեզ անհրաժեշտ է պլան, որում տեղ կա։ Միացման թեստը չի կարող հայտնաբերել սա. այն կարդում է ձեր ծրագիրը և ոչինչ չի տրամադրում, ուստի այն հայտնում է առողջ հաշվի մասին, որը դեռևս չի կարող վաճառել։ Առանց սահմանաչափի տեղադրված պատվերը մերժվում է հաղորդագրությամբ, որն ուղղակիորեն ասում է այդ մասին։

Ստուգեք ձեր ներբեռնումը

Երկու արխիվներն էլ մատուցվում են TLS-ի միջոցով մեր սեփական հոսթի անունից, երբեք չեն վերահասցեավորվում այլ տեղ, և դրանց SHA-256 վերահսկիչ գումարները տպված են ներբեռնման հղումների կողքին ներբեռնումների էջում։