HostBill, Blesta किंवा तुमच्या स्वतःच्या सिस्टमवरून Zinn® होस्टिंग विका

तुम्ही 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'));

// 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));

PHP लिहीत नाही आहात? तेच कॉल्स API संदर्भ मध्ये आहेत आणि तुम्ही ते कशातूनही करू शकता.

API की

सात परवानग्या, आणि त्यापेक्षा जास्त नाही: org.create, org.read, sites.create, sites.view, sites.delete, reseller.view, reseller.provision.

⛔ reseller.manage नाही. तुम्ही बिलिंग पॅनेलमध्ये पेस्ट करत असलेली की पैसे न भरल्यामुळे क्लायंटला रोखून धरण्यास आणि त्यांना साइन इन करण्यास सक्षम असली पाहिजे; ती तुमची स्वतःची पेमेंट-गेटवे क्रेडेंशियल्स पुन्हा लिहिण्यास सक्षम नसावी.

मोडल्यास आर्थिक नुकसान करणारे दोन नियम

1. खाते तुमच्या CUSTOMER वर आणि साइट तुमच्या SERVICE वर आधारित ठेवा. ग्राहकाची दुसरी ऑर्डर त्यांच्या आधीपासून असलेल्या खात्यामध्येच गेली पाहिजे. दोन्ही सेवेवर आधारित ठेवल्यास एकाच ग्राहकाकडे तीन असंबद्ध खाती आणि तीन स्वतंत्र नियंत्रण पॅनेल्स तयार होतात.
2. प्रत्येक तयार करण्यावर, त्या घटकासाठीच्या तुमच्या स्वतःच्या आयडीवरून घेतलेली आयडेम्पोटन्सी की पाठवा. प्रत्येक बिलिंग प्रणाली पुन्हा प्रयत्न करते — गेटवे कॉलबॅक दोनदा येतो, ॲडमिन अयशस्वी झालेले प्रोव्हिजन पुन्हा चालवतो, ग्राहक दोनदा क्लिक करतो. त्याशिवाय दुसरा प्रयत्न दुसरी साइट तयार करतो आणि त्याचे बिल तुम्हाला आकारले जाते. दोन्ही मॉड्यूल्स आणि 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} वरून डोमेन परत वाचा: त्याची तुलना साइटच्या स्वतःच्या प्राथमिक डोमेनशी केली जाते आणि उपनावाशी (alias) कधीही केली जात नाही.

केवळ वाक्यच नव्हे, तर संपूर्ण त्रुटी वाचा

व्हॅलिडेशन नाकारल्याचा संदेश जाणूनबुजून सामान्य असतो — "विनंती योग्य स्वरूपाची होती परंतु तिचे प्रमाणीकरण अयशस्वी झाले." — कारण कारवाई करण्यायोग्य भाग details मध्ये असतो, जो फील्डचे नाव आणि कारण सांगतो. दोन्ही मॉड्यूल्स आणि PHP क्लायंट तो संदेश त्यांच्या ॲडमिनला दाखवत असलेल्या संदेशासोबत जोडतात. जर तुम्ही स्वतः API कॉल करत असाल, तर error.details वाचा; काही नोंदींमध्ये वाक्याऐवजी केवळ मूल्य असते, ज्याद्वारे तुमच्या पुनर्विक्रेता प्लॅनमध्ये जागा नसताना max_sites: 0 तुमच्यापर्यंत पोहोचते.

तुमच्या पहिल्या ऑर्डरपूर्वी

तुमचे क्लायंट खरेदी करत असलेल्या साइट्स तुमच्या पुनर्विक्रेता प्लॅनच्या साइट अलाउन्समध्ये मोजल्या जातात, त्यामुळे तुम्हाला जागा असलेल्या प्लॅनची आवश्यकता आहे. कनेक्शन चाचणी हे शोधू शकत नाही — ती तुमचा प्रोग्राम वाचते आणि काहीही प्रोव्हिजन करत नाही — त्यामुळे ती अशा निरोगी खात्याची नोंद करते जे अद्याप विक्री करू शकत नाही. अलाउन्सशिवाय दिलेली ऑर्डर नेमके तेच सांगणाऱ्या संदेशासह नाकारली जाते.

तुमचे डाउनलोड सत्यापित करा

दोन्ही संग्रह (archives) आमच्या स्वतःच्या होस्टनेमवरून TLS वर सर्व्ह केले जातात, इतरत्र कुठेही पुनर्निर्देशित केले जात नाहीत, आणि त्यांचे SHA-256 चेकसम डाउनलोड पृष्ठावरील डाउनलोड लिंक्सच्या बाजूला मुद्रित केले जातात.