ฐานความรู้

ขายโฮสติ้ง Zinn® จาก HostBill, Blesta หรือระบบของคุณเอง

ขายโฮสติ้ง Zinn® จาก HostBill, Blesta หรือระบบของคุณเอง: โมดูล HostBill ฟรี ไคลเอนต์ PHP ไฟล์เดียว กฎสองข้อที่ก่อให้เกิดค่าใช้จ่ายเมื่อละเมิด และฟิลด์คำขอสองฟิลด์ที่มักถูกละเลยได้ง่าย

หากคุณใช้งาน WHMCS โปรดใช้ โมดูล WHMCS แทน — หน้านี้มีไว้สำหรับกรณีอื่นๆ ทั้งหมด มีสองตัวเลือก ทั้งสองตัวเลือกฟรีและเป็นไปตามสัญญาอนุญาต GPL-2.0-or-later ทั้งคู่

HostBill

โมดูลโฮสติ้งที่มีการทำงาน 6 รายการเช่นเดียวกับโมดูลของ WHMCS

  1. ดาวน์โหลดที่นี่ และแตกไฟล์ zip
  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: คีย์ API ของ Zinn® ของคุณ (ช่อง 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

สิทธิ์การใช้งาน 7 รายการ และไม่มีรายการอื่นเพิ่มเติม: org.create, org.read, sites.create, sites.view, sites.delete, reseller.view, reseller.provision

⛔ ต้องไม่ใช่ reseller.manage คีย์ที่คุณวางลงในพาเนลการเรียกเก็บเงินควรจะสามารถระงับบริการของลูกค้าเมื่อไม่ชำระเงินและเข้าสู่ระบบให้แก่พวกเขาได้เท่านั้น ไม่ควรสามารถเขียนทับข้อมูลประจำตัวของเกตเวย์การชำระเงินของคุณเองได้

กฎสองข้อที่ทำให้คุณเสียเงินหากฝ่าฝืน

  1. กำหนดคีย์ของบัญชีตาม CUSTOMER ของคุณ และกำหนดคีย์ของไซต์ตาม SERVICE ของคุณ คำสั่งซื้อที่สองของลูกค้าต้องอยู่ในบัญชีที่พวกเขามีอยู่แล้ว หากกำหนดทั้งสองอย่างตามบริการ ลูกค้าหนึ่งรายจะลงเอยด้วยการมีบัญชีที่ไม่เกี่ยวข้องกันสามบัญชีและแผงควบคุมแยกกันสามชุด
  2. ส่งคีย์ความไม่แปรเปลี่ยน (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

ล่าสุดจากบล็อก

สิ่งที่เราเขียนเกี่ยวกับโฮสติ้ง, SEO และการดูแลเว็บไซต์ในระดับสเกลใหญ่

SEO และการสร้างลิงก์จากเลเยอร์โฮสติง: มุมมองของผู้ปฏิบัติงานในปี 2026

โฮสติ้งส่งผลต่อการจัดทำดัชนีและมูลค่าของลิงก์ (link equity) ในปี 2026 อย่างไร: การดูแลให้หน้าเว็บยังคงอยู่ในดัชนี, การตรวจสอบโดเมนเก่าก่อนที่คุณจะเริ่มพัฒนา, การสร้างลิงก์โดยไม่ทิ้งร่องรอย (footprint) และข้อเท็จจริงอย่างตรงไปตรงมาเกี่ยวกับสิ่งที่โครงสร้างพื้นฐานสามารถและไม่สามารถทำให้กับ SEO ได้

อ่านโพสต์ →

การทำให้ WordPress รวดเร็วและปลอดภัย: รายการตรวจสอบประสิทธิภาพและปลั๊กอิน

รายการตรวจสอบที่ใช้งานได้จริงสำหรับ WordPress ที่รวดเร็วและปลอดภัย: การแคชระดับเซิร์ฟเวอร์, อ็อบเจกต์แคชสำหรับแต่ละไซต์, ปลั๊กอินจำนวนหนึ่งที่คุ้มค่าแก่การใช้งาน, การอัปเดตสแต็กให้เป็นปัจจุบันอยู่เสมอ และหน้า WooCommerce ที่คุณต้องไม่แคชโดยเด็ดขาด

อ่านโพสต์ →

วิธีเลือกเว็บโฮสติ้งที่มีการจัดการในปี 2026: คู่มือสำหรับผู้ซื้อ

สิ่งที่แยกแยะระหว่างโฮสติ้งที่มีการจัดการที่ดีกับเซิร์ฟเวอร์ราคาถูกที่มีเพียงแผงควบคุมได้อย่างแท้จริง ได้แก่ การย้ายข้อมูล การสำรองข้อมูล การแยกสภาพแวดล้อม แคชที่มีประสิทธิภาพจริง และการปรับขนาดที่โปร่งใส ตลอดจนวิธีประเมินก่อนที่คุณจะตัดสินใจเลือกใช้งาน

อ่านโพสต์ →

อ่านบล็อก →

ยังติดปัญหาอยู่ใช่หรือไม่?

บริการช่วยเหลือรวมอยู่ในทุกแพลตฟอร์ม ทีมงานพร้อมให้บริการ 24 ชั่วโมงต่อวัน และคุณสามารถเขียนหาเราเป็นภาษาใดก็ได้จาก 58 ภาษาของเรา เราจะตอบกลับคุณด้วยภาษาของคุณ

ติดต่อฝ่ายสนับสนุน → บทความทั้งหมด →