หากคุณใช้งาน WHMCS โปรดใช้ โมดูล WHMCS แทน — หน้านี้มีไว้สำหรับกรณีอื่นๆ ทั้งหมด มีสองตัวเลือก ทั้งสองตัวเลือกฟรีและเป็นไปตามสัญญาอนุญาต GPL-2.0-or-later ทั้งคู่
HostBill
โมดูลโฮสติ้งที่มีการทำงาน 6 รายการเช่นเดียวกับโมดูลของ WHMCS
- ดาวน์โหลดที่นี่ และแตกไฟล์ zip
- อัปโหลดไดเรกทอรี
zinn ไปยัง includes/modules/Hosting/ เพื่อให้ไฟล์อยู่ที่ includes/modules/Hosting/zinn/class.zinn.php และ includes/modules/Hosting/zinn/ZinnHostBillClient.php
- ไปที่ Settings → Modules → Hosting เปิดใช้งาน Zinn Digital® และเพิ่มการเชื่อมต่อ:
- API address:
https://api.zinndigital.com
- API key: คีย์ API ของ Zinn® ของคุณ (ช่อง
password ซึ่ง HostBill จะจัดเก็บไว้แบบเข้ารหัส)
- ที่รายการสินค้า ให้กำหนดค่า Product line (เช่น
mainstream), Stack (wordpress เป็นค่าเริ่มต้น) และ Application กับ PHP version ตามต้องการ
- กด 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
สิทธิ์การใช้งาน 7 รายการ และไม่มีรายการอื่นเพิ่มเติม: org.create, org.read, sites.create, sites.view, sites.delete, reseller.view, reseller.provision
⛔ ต้องไม่ใช่ reseller.manage คีย์ที่คุณวางลงในพาเนลการเรียกเก็บเงินควรจะสามารถระงับบริการของลูกค้าเมื่อไม่ชำระเงินและเข้าสู่ระบบให้แก่พวกเขาได้เท่านั้น ไม่ควรสามารถเขียนทับข้อมูลประจำตัวของเกตเวย์การชำระเงินของคุณเองได้
กฎสองข้อที่ทำให้คุณเสียเงินหากฝ่าฝืน
- กำหนดคีย์ของบัญชีตาม CUSTOMER ของคุณ และกำหนดคีย์ของไซต์ตาม SERVICE ของคุณ คำสั่งซื้อที่สองของลูกค้าต้องอยู่ในบัญชีที่พวกเขามีอยู่แล้ว หากกำหนดทั้งสองอย่างตามบริการ ลูกค้าหนึ่งรายจะลงเอยด้วยการมีบัญชีที่ไม่เกี่ยวข้องกันสามบัญชีและแผงควบคุมแยกกันสามชุด
- ส่งคีย์ความไม่แปรเปลี่ยน (idempotency key) ทุกครั้งที่มีการสร้าง โดยดึงมาจาก 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}` แทนการใช้ บันทึกของคุณเอง: โดเมนจะถูกนำไปเปรียบเทียบกับโดเมนหลักของไซต์นั้นๆ เสมอ และจะไม่เปรียบเทียบกับนามแฝง
อ่านข้อผิดพลาดทั้งหมด ไม่ใช่แค่อ่านเฉพาะประโยค
ข้อความของการปฏิเสธการตรวจสอบความถูกต้องนั้นจงใจทำให้เป็นแบบทั่วไป — "The request was well-formed but failed validation." — เนื่องจากส่วนที่สามารถนำไปปฏิบัติการต่อได้นั้นอยู่ใน details ซึ่งจะระบุชื่อฟิลด์และ เหตุผล ทั้งสองโมดูลและไคลเอ็นต์ PHP จะผนวกข้อมูลนี้เข้ากับข้อความที่แสดงต่อผู้ดูแลระบบของคุณ หากคุณ เรียกใช้ API ด้วยตนเอง โปรดอ่าน error.details บางรายการจะมีเพียงค่าเปล่าๆ มากกว่าที่จะเป็น ประโยค ซึ่งเป็นลักษณะที่ max_sites: 0 ส่งมาถึงคุณเมื่อแผนบริการตัวแทนจำหน่ายของคุณไม่มีพื้นที่ว่างเหลือ
ก่อนคำสั่งซื้อแรกของคุณ
ไซต์ที่ลูกค้าของคุณซื้อจะถูกนับรวมในโควตาไซต์ของแผนบริการตัวแทนจำหน่ายของคุณ ดังนั้นคุณจึงจำเป็นต้องมี แผนบริการที่มีพื้นที่ว่างเหลือ การทดสอบการเชื่อมต่อไม่สามารถตรวจพบสิ่งนี้ได้ — เนื่องจากการทดสอบจะอ่านโปรแกรมของคุณและ ไม่ได้จัดเตรียมสิ่งใด — ดังนั้นจึงรายงานว่าเป็นบัญชีที่ปกติดีแต่ยังไม่สามารถขายได้ คำสั่งซื้อที่ส่งเข้ามา โดยไม่มีโควตาจะถูกปฏิเสธพร้อมข้อความที่ระบุไว้อย่างชัดเจนตามนั้น
ตรวจสอบยืนยันการดาวน์โหลดของคุณ
ไฟล์เก็บถาวรทั้งสองไฟล์ให้บริการผ่าน TLS จากชื่อโฮสต์ของเราเอง โดยไม่มีการเปลี่ยนเส้นทางไปยังที่อื่น พร้อมระบุ ผลรวมตรวจสอบ SHA-256 ไว้ข้างลิงก์ดาวน์โหลดบน downloads page