بيع استضافة 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: https://api.zinndigital.com
• مفتاح API: مفتاح Zinn® API الخاص بك (حقل password، لكي يقوم HostBill بتخزينه مشفراً)

1. في المنتج، قم بتعيين خط المنتج (مثل mainstream)، الحزمة (wordpress كوضع

افتراحي)، واختيارياً التطبيق وإصدار PHP.

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.

ثلاثة حقول يسهل تركها

كل منها يعطل فعلاً كاملاً، ولا يظهر أي منها إلا كخطأ تحقق — باستثناء الأول، الذي يظهر كـ لا شيء على الإطلاق:

• ⛔⛔ يجب وضع العميل على خطة قبل توفير وقته الأول (BEFORE their first site is provisioned)، باستخدام

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}` بدلاً من استخدام سجلك الخاص: تتم مقارنته بالنطاق الأساسي للموقع نفسه وليس بالاسم المستعار أبداً.

اقرأ الخطأ كاملاً، وليس الجملة فقط

رسالة رفض التحقق عامة بشكل متعمد — "The request was well-formed but failed validation." — لأن النصف القابل للتنفيذ موجود في details، والذي يحدد الحقل والسبب. تقوم كل من الوحدات النمطية وعميل PHP بإلحاقه بالرسالة التي يعرضونها لمسؤولك. إذا كنت تستدعي API بنفسك، فاقرأ error.details؛ تحمل بعض الإدخالات قيمة مجردة بدلاً من جملة، وهي الطريقة التي تصل بها max_sites: 0 إليك عندما لا يكون لدى خطة الموزع الخاصة بك متسع.

قبل طلبك الأول

تحتسب المواقع التي يشتريها عملاؤك ضد مخصصات مواقع خطة الموزع الخاصة بك، لذا فأنت بحاجة إلى خطة تتسع لذلك. لا يمكن لاختبار الاتصال اكتشاف هذا — فهو يقرأ برنامجك ولا يوفر شيئاً — لذا فهو يبلغ عن حساب سليم لا يمكنه البيع بعد. يتم رفض الطلب المقدم بدون مخصصات برسالة توضح ذلك بالضبط.

تحقق من التنزيل الخاص بك

يتم تقديم كلا الأرشيفين عبر TLS من اسم المضيف الخاص بنا، دون إعادة توجيههما إلى أي مكان آخر، مع طباعة مجاميع التحقق SHA-256 بجوار روابط التنزيل على صفحة التنزيل.