Jual hosting Zinn® dari HostBill, Blesta, atau sistem Anda sendiri

Jika Anda menggunakan WHMCS, gunakan modul WHMCS sebagai gantinya — halaman ini ditujukan untuk kebutuhan lainnya. Tersedia dua opsi, keduanya gratis dan keduanya berlisensi GPL-2.0-or-later.

HostBill

Modul hosting dengan enam tindakan yang sama seperti modul WHMCS.

1. Unduh modul dan ekstrak.
2. Unggah direktori zinn ke dalam includes/modules/Hosting/ sehingga file berada di includes/modules/Hosting/zinn/class.zinn.php dan includes/modules/Hosting/zinn/ZinnHostBillClient.php.
3. Settings → Modules → Hosting, aktifkan Zinn Digital®, lalu tambahkan koneksi:

• API address: https://api.zinndigital.com
• API key: kunci API Zinn® Anda (kolom password, sehingga HostBill menyimpannya dalam bentuk terenkripsi)

1. Pada produk, atur Product line (misalnya mainstream), Stack (secara default wordpress), serta secara opsional Application dan PHP version.
2. Tekan Test connection.

⛔ Jangan mengganti nama direktori zinn. Loader HostBill mengambil nama kelas yang dicarinya dari nama direktori, sehingga penggantian nama akan menghasilkan modul yang terdaftar di panel namun tidak pernah dipanggil.

Kebutuhan lainnya — klien PHP

Satu file, tanpa dependensi, tanpa asumsi panel. Masukkan ZinnProvisioning.php ke dalam basis kode Anda sendiri dan panggil enam metode.

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));

Tidak menggunakan PHP? Panggilan yang sama tersedia di referensi API dan Anda dapat melakukannya dari platform apa pun.

Kunci API

Tujuh izin, dan tidak lebih: org.create, org.read, sites.create, sites.view, sites.delete, reseller.view, reseller.provision.

⛔ Bukan reseller.manage. Kunci yang Anda tempelkan ke panel penagihan harus dapat menangguhkan klien karena belum membayar dan memasukkan mereka ke akun; kunci tersebut tidak boleh dapat menulis ulang kredensial gateway pembayaran Anda sendiri.

Dua aturan yang memicu biaya saat dilanggar

1. Tautkan akun pada PELANGGAN Anda, dan situs pada LAYANAN Anda. Pesanan kedua dari pelanggan harus diarahkan ke akun yang sudah mereka miliki. Jika keduanya ditautkan pada layanan, seorang pelanggan akan memiliki tiga akun yang tidak terkait dan tiga panel kontrol terpisah.
2. Kirimkan kunci idempoten pada setiap operasi pembuatan, yang diturunkan dari ID Anda sendiri untuk objek tersebut. Setiap sistem penagihan melakukan percobaan ulang — callback gateway diterima dua kali, administrator menjalankan ulang provisi yang gagal, pelanggan melakukan klik ganda. Tanpa kunci ini, percobaan kedua akan membuat situs kedua dan Anda akan ditagih untuk itu. Kedua modul dan klien PHP melakukan hal ini untuk Anda; jika Anda memanggil API secara langsung, kirimkan Idempotency-Key.

Tiga kolom yang mudah terlewatkan

Masing-masing merusak keseluruhan kata kerja operasional, dan tidak ada yang muncul selain sebagai kesalahan validasi — kecuali yang pertama, yang muncul sebagai tidak ada sama sekali:

• ⛔⛔ Klien harus dimasukkan ke dalam paket SEBELUM situs pertama mereka disiapkan, dengan POST /v1/reseller/clients/{orgId}/plan, dan subscription_id miliknya diteruskan ke POST /v1/sites. Ini adalah kondisi yang tidak memunculkan pesan kesalahan untuk dibaca. Akun klien baru tidak memiliki langganan dan POST /v1/sites tidak memiliki kolom paket, sehingga situs yang disiapkan tanpanya sama sekali tidak memiliki paket: laporan grosir Anda dibuat dari langganan aktif klien Anda, sehingga tidak ada tagihan yang muncul dan Zinn® tidak menagih apa pun kepada Anda selama hosting berjalan; klien Anda tidak mewarisi alokasi apa pun, sehingga tidak ada kuota yang diterapkan ke situs mereka; dan tidak ada yang dapat diubah oleh peningkatan paket. Pesanan mengembalikan respons 201, situs berhasil disiapkan, dan berfungsi dengan sempurna. Tidak ada sistem di kedua belah pihak yang melaporkan hal ini.

Urutan ini sangat penting: POST /v1/sites mencatat langganan apa pun yang ada pada saat permintaan dijalankan, sehingga paket yang ditetapkan setelahnya tidak berlaku surut.

• POST /v1/sites memerlukan stack_type. Abaikan ini dan tidak ada pesanan yang dapat berhasil.
• DELETE /v1/sites/{siteId} memerlukan body {"confirm_domain": "<the site's own domain>"} — konfirmasi yang diketik, karena ini adalah tindakan destruktif. Abaikan ini dan tidak ada pembatalan yang dapat berhasil, sehingga layanan tetap berjalan dan Anda tetap ditagih untuk itu. Dapatkan kembali domain dari GET /v1/reseller/services/{siteId} daripada menggunakan catatan Anda sendiri: nilai ini dibandingkan dengan domain utama milik situs itu sendiri dan tidak pernah dibandingkan dengan alias.

Baca seluruh kesalahan, bukan hanya kalimatnya

Pesan penolakan validasi sengaja dibuat umum — "The request was well-formed but failed validation." — karena bagian yang memerlukan tindakan terdapat di dalam details, yang menyebutkan kolom dan alasannya. Kedua modul dan klien PHP melampirkannya ke pesan yang mereka tampilkan kepada admin Anda. Jika Anda memanggil API secara mandiri, baca error.details; beberapa entri hanya memuat nilai dasar alih-alih sebuah kalimat, begitulah cara max_sites: 0 diterima ketika paket reseller Anda tidak memiliki ruang tersisa.

Sebelum pesanan pertama Anda

Situs yang dibeli klien Anda diperhitungkan ke dalam kuota alokasi situs paket reseller Anda, sehingga Anda memerlukan paket yang memiliki ruang tersisa. Pengujian koneksi tidak dapat mendeteksi hal ini — pengujian tersebut membaca program Anda dan tidak menyiapkan apa pun — sehingga pengujian akan melaporkan akun dalam keadaan baik yang sebenarnya belum dapat melakukan penjualan. Pesanan yang dibuat tanpa adanya alokasi akan ditolak dengan pesan yang menyatakan hal tersebut secara persis.

Verifikasi unduhan Anda

Kedua arsip disajikan melalui TLS dari nama host kami sendiri, tidak pernah dialihkan ke tempat lain, dengan checksum SHA-256 yang tercantum di samping tautan unduhan pada halaman unduhan.