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. प्रत्येक निर्माण पर एक idempotency key भेजें, जो उस वस्तु के लिए आपकी अपनी आईडी से प्राप्त हो। प्रत्येक बिलिंग प्रणाली पुनः प्रयास करती है — एक गेटवे कॉलबैक दो बार आता है, एक व्यवस्थापक विफल प्रावधान को पुनः चलाता है, एक ग्राहक डबल-क्लिक करता है। इसके बिना दूसरा प्रयास एक दूसरी साइट बना देता है और आपसे इसके लिए शुल्क लिया जाता है। दोनों मॉड्यूल और 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) से नहीं की जाती।

केवल वाक्य ही नहीं, पूरी त्रुटि पढ़ें

सत्यापन अस्वीकृति का संदेश जानबूझकर सामान्य रखा गया है — "The request was well-formed but failed validation." — क्योंकि कार्रवाई योग्य भाग details में होता है, जो फ़ील्ड और कारण का नाम बताता है। दोनों मॉड्यूल और PHP क्लाइंट इसे आपके एडमिन को दिखाए जाने वाले संदेश में जोड़ते हैं। यदि आप स्वयं API को कॉल कर रहे हैं, तो error.details पढ़ें; कुछ प्रविष्टियों में वाक्य के बजाय केवल एक मान होता है, जिससे आपके पुनर्विक्रेता प्लान में जगह न होने पर max_sites: 0 आप तक पहुँचता है।

अपने पहले ऑर्डर से पहले

आपके क्लाइंट द्वारा खरीदी जाने वाली साइटें आपके पुनर्विक्रेता प्लान के साइट अलाउंस में गिनी जाती हैं, इसलिए आपको एक ऐसे प्लान की आवश्यकता है जिसमें जगह हो। कनेक्शन परीक्षण इसका पता नहीं लगा सकता — यह आपके प्रोग्राम को पढ़ता है और कुछ भी प्रोविज़न नहीं करता — इसलिए यह एक स्वस्थ खाते की रिपोर्ट करता है जो अभी बेच नहीं सकता। बिना अलाउंस के दिया गया ऑर्डर ठीक यही बताते हुए संदेश के साथ अस्वीकार कर दिया जाता है।

अपने डाउनलोड का सत्यापन करें

दोनों अभिलेखागार (archives) हमारे अपने होस्टनाम से TLS पर दिए जाते हैं, उन्हें कभी भी कहीं और पुनर्निर्देशित नहीं किया जाता है, और उनके SHA-256 चेकसम डाउनलोड पृष्ठ पर डाउनलोड लिंक के बगल में मुद्रित होते हैं।