Zinn® ဟာ့စ်တင်းကို HostBill၊ Blesta သို့မဟုတ် သင်၏ကိုယ်ပိုင်စနစ်မှ ရောင်းချပါ

အကယ်၍ သင်သည် WHMCS ကို အသုံးပြုနေပါက WHMCS မော်ဂျူး ကို အစားထိုး အသုံးပြုပါ — ဤစာမျက်နှာသည် အခြားအရာအားလုံးအတွက် ဖြစ်ပါသည်။ အခမဲ့ဖြစ်ပြီး GPL-2.0-or-later လိုင်စင်ပါရှိသော ရွေးချယ်စရာနှစ်ခု ရှိပါသည်။

HostBill

WHMCS မော်ဂျူးကဲ့သို့ပင် လုပ်ဆောင်ချက် ခြောက်ခုပါဝင်သော ဟိုးစတင်းမော်ဂျူး။

1. ၎င်းကို ဒေါင်းလုဒ်ဆွဲပါ ပြီးလျှင် ဇစ်ဖြည်ပါ။
2. ဖိုင်များအား includes/modules/Hosting/zinn/class.zinn.php နှင့် includes/modules/Hosting/zinn/ZinnHostBillClient.php တို့တွင် တည်ရှိစေရန် zinn ဖိုဒါကို includes/modules/Hosting/ ထဲသို့ တင်ပါ။
3. Settings → Modules → Hosting သို့သွား၍ Zinn Digital® ကို ဖွင့်ပြီး ချိတ်ဆက်မှုတစ်ခု ထည့်ပါ -

• API address: https://api.zinndigital.com
• API key: သင်၏ Zinn® API key (၎င်းသည် password အကွက်ဖြစ်သောကြောင့် HostBill က လျှို့ဝှက်ကုဒ်စနစ်ဖြင့် သိမ်းဆည်းပါသည်)

1. ထုတ်ကုန်တွင် Product line (ဥပမာ- mainstream)၊ Stack (မူရင်းအားဖြင့် wordpress) နှင့် ရွေးချယ်နိုင်သော Application နှင့် PHP version တို့ကို သတ်မှတ်ပါ။
2. Test connection ကို နှိပ်ပါ။

⛔ zinn ဖိုဒါအမည်ကို မပြောင်းပါနှင့်။ HostBill ၏ loader သည် ရှာဖွေရမည့် class ကို ဖိုဒါအမည်မှတစ်ဆင့် ရယူသောကြောင့် အမည်ပြောင်းလဲပါက ထိန်းချုပ်ခွင်တွင် ပြသထားသော်လည်း မည်သည့်အခါမျှ ခေါ်ယူအသုံးမပြုနိုင်သော မော်ဂျူးတစ်ခု ဖြစ်သွားပါမည်။

အခြားအရာများအတွက် — PHP client

ဖိုင်တစ်ခုတည်း၊ မှီခိုရာဖိုင်များမရှိ၊ ထိန်းချုပ်ခွင်ကြိုတင်ယူဆချက်များမရှိပါ။ 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 key

ခွင့်ပြုချက် ခုနစ်ခုသာဖြစ်ပြီး၊ ပို၍ မပါဝင်ပါ- org.create၊ org.read၊ sites.create၊ sites.view၊ sites.delete၊ reseller.view၊ reseller.provision။

⛔ reseller.manage မဟုတ်ပါ။ ငွေတောင်းခံလွှာထိန်းချုပ်ခွင်ထဲသို့ သင်ထည့်သွင်းလိုက်သော key သည် ငွေမပေးချေမှုအတွက် သုံးစွဲသူအား ဆိုင်းငံ့နိုင်စွမ်းနှင့် ၎င်းတို့အား အကောင့်ဝင်ရောက်ခွင့်ပေးနိုင်စွမ်းသာ ရှိသင့်သည်၊ သင်၏ ငွေပေးချေမှု ပလက်ဖောင်း အထောက်အထားများကို ပြန်လည်ပြင်ဆင်ရေးသားနိုင်စွမ်း မရှိသင့်ပါ။

ချိုးဖောက်ပါက ငွေကြေးဆုံးရှုံးစေနိုင်သော စည်းမျဉ်းနှစ်ခု

1. အကောင့်ကို သင်၏ CUSTOMER အပေါ်တွင် အခြေခံပြီး ဝဘ်ဆိုက်ကို သင်၏ SERVICE အပေါ်တွင် အခြေခံပါ။ သုံးစွဲသူတစ်ဦး၏ ဒုတိယအကြိမ်မှာယူမှုသည် ၎င်းတို့တွင် ရှိပြီးသားဖြစ်သော အကောင့်ထဲသို့သာ ရောက်ရှိရပါမည်။ နှစ်ခုစလုံးကို ဝန်ဆောင်မှုအပေါ် အခြေခံပါက သုံးစွဲသူတစ်ဦးတည်းသည် ဆက်စပ်မှုမရှိသော အကောင့်သုံးခုနှင့် သီးခြားထိန်းချုပ်ခွင် သုံးခုကို ရရှိသွားပါလိမ့်မည်။
2. ဖန်တီးမှုတိုင်းတွင် အရာဝတ္ထုအတွက် သင်၏ကိုယ်ပိုင် id မှတစ်ဆင့် ထုတ်ယူထားသော idempotency key တစ်ခုကို ပေးပို့ပါ။ ငွေတောင်းခံလွှာစနစ်တိုင်းသည် ပြန်လည်ကြိုးစားလေ့ရှိပါသည် — ငွေပေးချေမှု callback နှစ်ကြိမ် ရောက်ရှိလာခြင်း၊ စီမံခန့်ခွဲသူက မအောင်မြင်သော ဝန်ဆောင်မှုပေးခြင်းကို ပြန်လည်လုပ်ဆောင်ခြင်း၊ သုံးစွဲသူက နှစ်ချက်နှိပ်မိခြင်း စသည်တို့ဖြစ်ပါသည်။ ၎င်းမပါရှိပါက ဒုတိယအကြိမ် ကြိုးပမ်းမှုသည် ဒုတိယဆိုက်တစ်ခုကို ဖန်တီးပေးမည်ဖြစ်ပြီး သင့်ထံမှ ငွေတောင်းခံသွားပါလိမ့်မည်။ မော်ဂျူးနှစ်ခုစလုံးနှင့် PHP client တို့သည် ဤအရာကို သင့်အတွက် လုပ်ဆောင်ပေးပါသည်၊ အကယ်၍ သင်သည် API ကို တိုက်ရိုက်ခေါ်ယူနေပါက Idempotency-Key ကို ပေးပို့ပါ။

ချန်လှပ်ထားမိရန် လွယ်ကူသော အကွက်သုံးခု

တစ်ခုချင်းစီသည် verb တစ်ခုလုံးကို ပျက်စီးစေပြီး မည်သည့်အရာမျှ validation error အဖြစ်မှတစ်ပါး မပြပါ — ပထမတစ်ခုမှလွဲ၍ ဖြစ်ပြီး၊ ၎င်းသည် လုံးဝဘာမျှမပြပါ -

• ⛔⛔ 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>"} ပါဝင်သော body တစ်ခု လိုအပ်ပါသည် — ဤသည်မှာ ဖျက်ဆီးနိုင်သော လုပ်ဆောင်ချက်ဖြစ်သောကြောင့် စာရိုက်၍အတည်ပြုခြင်းဖြစ်ပါသည်။ ၎င်းကို ချန်လှပ်ထားပါက မည်သည့်ပယ်ဖျက်မှုမျှ အောင်မြင်နိုင်မည်မဟုတ်သောကြောင့် ဝန်ဆောင်မှုသည် ဆက်လက်လည်ပတ်နေမည်ဖြစ်ပြီး သင့်ထံသို့ ဆက်လက်ကျသင့်ငွေတောင်းခံနေမည်ဖြစ်ပါသည်။ သင့်ကိုယ်ပိုင်မှတ်တမ်းကို အသုံးပြုမည့်အစား GET /v1/reseller/services/{siteId} မှ ဒိုမိန်းကို ပြန်လည်ဖတ်ရှုပါ- ၎င်းကို ဆိုက်၏ကိုယ်ပိုင်ပင်မဒိုမိန်းနှင့် နှိုင်းယှဉ်ထားပြီး နာမည်ပွား (alias) နှင့် မည်သည့်အခါမျှ မနှိုင်းယှဉ်ပါ။

ဝါကျတစ်ခုတည်းမဟုတ်ဘဲ အမှားတစ်ခုလုံးကို ဖတ်ပါ

စိစစ်အတည်ပြုမှု ငြင်းပယ်ခြင်းဆိုင်ရာ မက်ဆေ့ဂျ်သည် တမင်တကာ ယေဘုယျဆန်ထားပါသည် — "တောင်းဆိုမှုသည် ပုံစံမှန်ကန်သော်လည်း စိစစ်အတည်ပြုခြင်း မအောင်မြင်ပါ။" — အကြောင်းမှာ အရေးယူဆောင်ရွက်နိုင်သည့် အစိတ်အပိုင်းသည် အကွက်အမည်နှင့် အကြောင်းရင်းကို ဖော်ပြထားသည့် details တွင် ရှိနေသောကြောင့်ဖြစ်ပါသည်။ မော်ဂျူးနှစ်ခုလုံးနှင့် PHP client သည် သင့်စီမံခန့်ခွဲသူအား ပြသသော မက်ဆေ့ဂျ်တွင် ၎င်းကို ပေါင်းထည့်ပေးပါသည်။ အကယ်၍ သင်သည် API ကို ကိုယ်တိုင်ခေါ်ယူနေပါက error.details ကို ဖတ်ပါ၊ အချို့သော အကြောင်းအရာများတွင် ဝါကျတစ်ခုအစား တန်ဖိုးသီးသန့်သာ ပါဝင်လေ့ရှိပြီး ယင်းသည် သင့်ပြန်လည်ရောင်းချသူအစီအစဉ်တွင် နေရာလွတ်မရှိသည့်အခါ max_sites: 0 ရောက်ရှိလာသည့် ပုံစံဖြစ်ပါသည်။

သင်၏ ပထမဆုံးမှာယူမှုမပြုမီ

သင့်ဝယ်ယူသူများ ဝယ်ယူသောဆိုက်များသည် သင်၏ ပြန်လည်ရောင်းချသူအစီအစဉ်၏ ဆိုက်ခွင့်ပြုချက်ပမာဏထဲမှ တွက်ချက်ခြင်းဖြစ်သောကြောင့် နေရာလွတ်ပါဝင်သော အစီအစဉ်တစ်ခု လိုအပ်ပါသည်။ ချိတ်ဆက်မှုစမ်းသပ်မှုတစ်ခုသည် ဤအရာကို ရှာဖွေဖော်ထုတ်နိုင်မည်မဟုတ်ပါ — ၎င်းသည် သင့်ပရိုဂရမ်ကို ဖတ်ရှုပြီး မည်သည့်အရာကိုမျှ ပြင်ဆင်သတ်မှတ်ခြင်းမရှိပါ — ထို့ကြောင့် ၎င်းသည် အရောင်းမလုပ်ဆောင်နိုင်သေးသော်လည်း ပုံမှန်ကောင်းမွန်နေသော အကောင့်တစ်ခုအဖြစ် အစီရင်ခံပါလိမ့်မည်။ ခွင့်ပြုချက်မရှိဘဲ မှာယူမှုပြုလုပ်ပါက ယင်းအကြောင်းကို အတိအကျဖော်ပြထားသော မက်ဆေ့ဂျ်ဖြင့် ငြင်းပယ်ခံရပါမည်။

သင် ဒေါင်းလုဒ်လုပ်ထားသည်ကို စစ်ဆေးပါ

မော်ကွန်းဖိုင် (archive) နှစ်ခုစလုံးကို အခြားမည်သည့်နေရာသို့မျှ လမ်းကြောင်းလွှဲခြင်းမရှိဘဲ ကျွန်ုပ်တို့၏ကိုယ်ပိုင် hostname မှတစ်ဆင့် TLS ဖြင့် ပေးပို့ထားပြီး ၎င်းတို့၏ SHA-256 checksum များကို ဒေါင်းလုဒ်များစာမျက်နှာ ပေါ်ရှိ ဒေါင်းလုဒ်လင့်ခ်များဘေးတွင် ဖော်ပြထားပါသည်။