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} ನಿಂದ ಡೊಮೇನ್ ಅನ್ನು ಮರಳಿ ಓದಿ: ಇದನ್ನು ಸೈಟ್‌ನ ಸ್ವಂತ ಪ್ರಾಥಮಿಕ ಡೊಮೇನ್‌ನೊಂದಿಗೆ ಮಾತ್ರ ಹೋಲಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಎಂದಿಗೂ ಅಲಿಯಾಸ್‌ನೊಂದಿಗೆ ಹೋಲಿಸುವುದಿಲ್ಲ.

ಕೇವಲ ವಾಕ್ಯವನ್ನು ಮಾತ್ರವಲ್ಲ, ಸಂಪೂರ್ಣ ದೋಷವನ್ನು ಓದಿ

ದೃಢೀಕರಣ ನಿರಾಕರಣೆಯ ಸಂದೇಶವು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿಯೇ ಸಾಮಾನ್ಯವಾಗಿರುತ್ತದೆ — "The request was well-formed but failed validation." — ಏಕೆಂದರೆ ಕ್ರಮ ಕೈಗೊಳ್ಳಬಹುದಾದ ಮುಖ್ಯ ಭಾಗವು details ನಲ್ಲಿದೆ, ಇದು ಆ ಫೀಲ್ಡ್ ಮತ್ತು ಕಾರಣವನ್ನು ಹೆಸರಿಸುತ್ತದೆ. ಮಾಡ್ಯೂಲ್‌ಗಳು ಮತ್ತು PHP ಕ್ಲೈಂಟ್ ಎರಡೂ ನಿಮ್ಮ ಅಡ್ಮಿನ್‌ಗೆ ತೋರಿಸುವ ಸಂದೇಶಕ್ಕೆ ಇದನ್ನು ಸೇರಿಸುತ್ತವೆ. ನೀವು ಸ್ವತಃ API ಗೆ ಕರೆ ಮಾಡುತ್ತಿದ್ದರೆ, error.details ಅನ್ನು ಓದಿ; ಕೆಲವು ನಮೂದುಗಳು ವಾಕ್ಯದ ಬದಲಿಗೆ ಕೇವಲ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿರುತ್ತವೆ, ನಿಮ್ಮ ರಿಸೆಲ್ಲರ್ ಪ್ಲಾನ್‌ನಲ್ಲಿ ಸ್ಥಳಾವಕಾಶವಿಲ್ಲದಿದ್ದಾಗ max_sites: 0 ನಿಮಗೆ ತಲುಪುವುದು ಹೀಗೆಯೇ.

ನಿಮ್ಮ ಮೊದಲ ಆರ್ಡರ್‌ಗೆ ಮುನ್ನ

ನಿಮ್ಮ ಗ್ರಾಹಕರು ಖರೀದಿಸುವ ಸೈಟ್‌ಗಳು ನಿಮ್ಮ ರಿಸೆಲ್ಲರ್ ಪ್ಲಾನ್‌ನ ಸೈಟ್ ಮಿತಿಗೆ ಲೆಕ್ಕಕ್ಕೆ ಬರುತ್ತವೆ, ಆದ್ದರಿಂದ ನಿಮಗೆ ಸ್ಥಳಾವಕಾಶವಿರುವ ಪ್ಲಾನ್ ಅಗತ್ಯವಿದೆ. ಸಂಪರ್ಕ ಪರೀಕ್ಷೆಯು ಇದನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಸಾಧ್ಯವಿಲ್ಲ — ಇದು ನಿಮ್ಮ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಓದುತ್ತದೆ ಮತ್ತು ಏನನ್ನೂ ಪ್ರೊವಿಶನ್ ಮಾಡುವುದಿಲ್ಲ — ಆದ್ದರಿಂದ ಇದು ಇನ್ನೂ ಮಾರಾಟ ಮಾಡಲು ಸಾಧ್ಯವಾಗದ ಉತ್ತಮ ಖಾತೆಯನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ. ಮಿತಿಯಿಲ್ಲದೆ ಇರಿಸಲಾದ ಆರ್ಡರ್ ಅನ್ನು ನಿಖರವಾಗಿ ಅದನ್ನೇ ತಿಳಿಸುವ ಸಂದೇಶದೊಂದಿಗೆ ನಿರಾಕರಿಸಲಾಗುತ್ತದೆ.

ನಿಮ್ಮ ಡೌನ್‌ಲೋಡ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ

ಎರಡೂ ಆರ್ಕೈವ್‌ಗಳನ್ನು ನಮ್ಮದೇ ಹೋಸ್ಟ್‌ನೇಮ್‌ನಿಂದ TLS ಮೂಲಕ ಒದಗಿಸಲಾಗುತ್ತದೆ, ಬೇರೆಲ್ಲಿಗೂ ಮರುನಿರ್ದೇಶಿಸುವುದಿಲ್ಲ ಮತ್ತು ಅವುಗಳ SHA-256 ಚೆಕ್‌ಸಮ್‌ಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಪುಟದಲ್ಲಿನ ಡೌನ್‌ಲೋಡ್ ಲಿಂಕ್‌ಗಳ ಪಕ್ಕದಲ್ಲಿ ಮುದ್ರಿಸಲಾಗಿರುತ್ತದೆ.