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 reference ਵਿੱਚ ਹਨ ਅਤੇ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਤੋਂ ਕਰ ਸਕਦੇ ਹੋ।

API ਕੁੰਜੀ

ਸੱਤ ਅਨੁਮਤੀਆਂ, ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ: org.create, org.read, sites.create, sites.view, sites.delete, reseller.view, reseller.provision।

⛔ reseller.manage ਨਹੀਂ। ਇੱਕ ਬਿਲਿੰਗ ਪੈਨਲ ਵਿੱਚ ਜੋ ਕੁੰਜੀ ਤੁਸੀਂ ਪੇਸਟ ਕਰਦੇ ਹੋ, ਉਸ ਕੋਲ ਭੁਗਤਾਨ ਨਾ ਕਰਨ ਲਈ ਗਾਹਕ ਨੂੰ ਰੋਕਣ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਸਾਈਨ ਇਨ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ; ਇਸ ਕੋਲ ਤੁਹਾਡੇ ਖ਼ੁਦ ਦੇ ਭੁਗਤਾਨ-ਗੇਟਵੇ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਮੁੜ ਲਿਖਣ ਦੀ ਸਮਰੱਥਾ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ।

ਦੋ ਨਿਯਮ ਜੋ ਟੁੱਟਣ 'ਤੇ ਪੈਸੇ ਦਾ ਨੁਕਸਾਨ ਕਰਾਉਂਦੇ ਹਨ

1. ਖਾਤੇ ਨੂੰ ਆਪਣੇ CUSTOMER ਨਾਲ, ਅਤੇ ਸਾਈਟ ਨੂੰ ਆਪਣੀ SERVICE ਨਾਲ ਜੋੜੋ। ਗਾਹਕ ਦਾ ਦੂਜਾ ਆਰਡਰ ਉਸ ਖਾਤੇ ਵਿੱਚ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਉਹਨਾਂ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਹੈ। ਦੋਵਾਂ ਨੂੰ ਸਰਵਿਸ ਨਾਲ ਜੋੜੋਗੇ ਤਾਂ ਇੱਕ ਗਾਹਕ ਕੋਲ ਤਿੰਨ ਅਸੰਬੰਧਿਤ ਖਾਤੇ ਅਤੇ ਤਿੰਨ ਵੱਖਰੇ ਕੰਟਰੋਲ ਪੈਨਲ ਬਣ ਜਾਣਗੇ।
2. ਹਰੇਕ ਬਣਾਉਣ 'ਤੇ ਇੱਕ ਆਈਡੈਂਪੋਟੈਂਸੀ ਕੁੰਜੀ ਭੇਜੋ, ਜੋ ਉਸ ਚੀਜ਼ ਲਈ ਤੁਹਾਡੀ ਆਪਣੀ 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} ਤੋਂ ਡੋਮੇਨ ਨੂੰ ਦੁਬਾਰਾ ਪੜ੍ਹੋ: ਇਸਦੀ ਤੁਲਨਾ ਸਾਈਟ ਦੇ ਆਪਣੇ ਪ੍ਰਾਇਮਰੀ ਡੋਮੇਨ ਨਾਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਕਦੇ ਵੀ ਕਿਸੇ ਉਪਨਾਮ (alias) ਨਾਲ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ।

ਸਿਰਫ਼ ਵਾਕ ਹੀ ਨਹੀਂ, ਪੂਰੀ ਗਲਤੀ ਨੂੰ ਪੜ੍ਹੋ

ਇੱਕ ਵੈਲੀਡੇਸ਼ਨ ਇਨਕਾਰ ਦਾ ਸੁਨੇਹਾ ਜਾਣਬੁੱਝ ਕੇ ਆਮ ਹੁੰਦਾ ਹੈ — "The request was well-formed but failed validation." — ਕਿਉਂਕਿ ਕਾਰਵਾਈਯੋਗ ਅੱਧਾ ਹਿੱਸਾ details ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਜੋ ਫੀਲਡ ਦਾ ਨਾਮ ਅਤੇ ਕਾਰਨ ਦੱਸਦਾ ਹੈ। ਮੋਡੀਊਲ ਅਤੇ PHP ਕਲਾਇੰਟ ਦੋਵੇਂ ਇਸਨੂੰ ਉਸ ਸੁਨੇਹੇ ਨਾਲ ਜੋੜਦੇ ਹਨ ਜੋ ਉਹ ਤੁਹਾਡੇ ਐਡਮਿਨ ਨੂੰ ਦਿਖਾਉਂਦੇ ਹਨ। ਜੇਕਰ ਤੁਸੀਂ ਖੁਦ API ਨੂੰ ਕਾਲ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ error.details ਨੂੰ ਪੜ੍ਹੋ; ਕੁਝ ਐਂਟਰੀਆਂ ਵਿੱਚ ਇੱਕ ਵਾਕ ਦੀ ਬਜਾਏ ਸਿਰਫ਼ ਮੁੱਲ ਹੁੰਦਾ ਹੈ, ਜਿਸ ਤਰੀਕੇ ਨਾਲ max_sites: 0 ਤੁਹਾਡੇ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਡੇ ਰੀਸੈਲਰ ਪਲਾਨ ਵਿੱਚ ਕੋਈ ਥਾਂ ਨਹੀਂ ਹੁੰਦੀ।

ਤੁਹਾਡੇ ਪਹਿਲੇ ਆਰਡਰ ਤੋਂ ਪਹਿਲਾਂ

ਤੁਹਾਡੇ ਕਲਾਇੰਟ ਜੋ ਸਾਈਟਾਂ ਖਰੀਦਦੇ ਹਨ, ਉਹ ਤੁਹਾਡੇ ਰੀਸੈਲਰ ਪਲਾਨ ਦੇ ਸਾਈਟ ਭੱਤੇ ਵਿੱਚ ਗਿਣੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਇੱਕ ਅਜਿਹੇ ਪਲਾਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਥਾਂ ਹੋਵੇ। ਇੱਕ ਕਨੈਕਸ਼ਨ ਟੈਸਟ ਇਸਦਾ ਪਤਾ ਨਹੀਂ ਲਗਾ ਸਕਦਾ — ਇਹ ਤੁਹਾਡੇ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਕੁਝ ਵੀ ਪ੍ਰੋਵੀਜ਼ਨ ਨਹੀਂ ਕਰਦਾ — ਇਸ ਲਈ ਇਹ ਇੱਕ ਠੀਕ ਖਾਤੇ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ ਜੋ ਅਜੇ ਵੇਚ ਨਹੀਂ ਸਕਦਾ। ਬਿਨਾਂ ਭੱਤੇ ਦੇ ਦਿੱਤਾ ਗਿਆ ਆਰਡਰ ਬਿਲਕੁਲ ਇਹੀ ਕਹਿਣ ਵਾਲੇ ਸੁਨੇਹੇ ਨਾਲ ਅਸਵੀਕਾਰ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।

ਆਪਣਾ ਡਾਊਨਲੋਡ ਪ੍ਰਮਾਣਿਤ ਕਰੋ

ਦੋਵੇਂ ਆਰਕਾਈਵ ਸਾਡੇ ਆਪਣੇ ਹੋਸਟਨਾਮ ਤੋਂ TLS ਰਾਹੀਂ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ, ਕਦੇ ਵੀ ਕਿਤੇ ਹੋਰ ਰੀਡਾਇਰੈਕਟ ਨਹੀਂ ਕੀਤੇ ਜਾਂਦੇ, ਅਤੇ ਉਹਨਾਂ ਦੇ SHA-256 ਚੈੱਕਸਮ ਡਾਊਨਲੋਡ ਪੰਨੇ 'ਤੇ ਡਾਊਨਲੋਡ ਲਿੰਕਾਂ ਦੇ ਨਾਲ ਪ੍ਰਿੰਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।