Автоматизація білінгу та провізіювання Plesk

Автоматизований хостинговий продукт має три моменти, коли гроші й машини стикаються одне з одним:

1. 01Замовлення оплачено: підписка має існувати, на правильному сервісному плані, протягом кількох секунд.
2. 02Рахунок прострочено: підписку потрібно згасити, і вона має повернутися щойно її оплачено.
3. 03Підписка завершується: її потрібно видалити, по-справжньому, разом з даними.

У Plesk є виклики для всіх трьох. Чого в ньому немає, так це чогось, що вирішує, коли їх запускати, і саме цю половину ви будуєте. Ця сторінка про те, як зʼєднати ці дві частини, і про чотири поведінки, які нешкідливі, коли ви натискаєте їх вручну, і небезпечні, коли планувальник запускає їх о третій годині ночі.

Усе тут виміряно на робочому сервері Plesk Obsidian 18.0.80 у серпні 2026 року.

Три моменти та виклики, що стоять за ними

Два з цих чисел визначають дизайн. Створення підписки триває чотири з половиною секунди, а видалення триває майже вісім. Це достатньо довго, щоб форма замовлення мусила повідомляти, що щось відбувається, достатньо довго, щоб бюджет таймауту, написаний для швидкого API, обірвав робочий виклик на півдорозі, і достатньо довго, щоб два замовлення, які надходять разом, були справді одночасними, а не лише теоретично.

Зверніть увагу й на рядок читання. Один XML-виклик повертає кожну підписку з її планом, статусом, квотою та використанням за третину секунди, незалежно від їхньої кількості, а система білінгу постійно звіряється з панеллю.

Пастка призупинення є помилкою білінгу, а не деталлю API

Plesk пропонує два способи призупинення, і вони записують різні поля. У хостинговому продукті це перестає бути дрібницею.

Виміряно на одній і тій самій підписці:

Цикл нагадувань про оплату, який призупиняє через REST, записує поле, на яке масове читання не дивиться, тож ваша платформа далі повідомляє про обліковий запис як про активний. Ось чому це шкодить саме білінгу: коли рахунок нарешті оплачено, ваша автоматизація дивиться на власний стан, бачить обліковий запис, який ніколи не був призупинений, і не відновлює його. Клієнт оплатив, але лишається згаслим, і ніщо не зафіксувало помилки.

Правило вміщується в один рядок: призупиняйте через те поле, яке читаєте. Provibr записує <webspace><set><gen_setup><status>, після чого обидва подання збігаються.

gen_info.status є бітовою маскою; ми виміряли 0 для активного, 1 для вимкненого webspace та 16 для вимкненого адміністратором. Вважайте будь-яке ненульове значення призупиненням: єдине тлумачення, що витримує значення, якого ще ніхто не бачив.

Одна чесна прогалина: ми не вимірювали призупинення вже призупиненої підписки. У HestiaCP цей випадок не є ідемпотентним і повертає помилку, схожу на помилку автентифікації (саме те, на чому цикл нагадувань спотикається щодня), тож перевірте це на власному сервері, перш ніж покладатися на нього.

Прострочений ключ виглядає точнісінько як порожній сервер

Це збій, який може завдати справжньої шкоди, і його можна описати одним реченням.

XML API повертає HTTP 200 для неправильного ключа. Помилка міститься всередині документа, як код 11003. Тому клієнт, який перевіряє код статусу, читає збій автентифікації як успішний прохід, що не знайшов жодної підписки.

А тепер помістіть це в нічне завдання звіряння. Успішний прохід, що нічого не знайшов, означає для будь-якої хостингової платформи, що кожен обліковий запис, який був там учора, видалено. Один прострочений ключ, і за ніч ваша система позначає всю вашу клієнтську базу як зниклу.

Звідси випливають два правила, і вони стосуються будь-якої панелі, що повідомляє про збій кодом 200, а таких серед панелей, які ми інтегрували, більшість:

• У XML API код статусу не несе взагалі жодної інформації, навіть про автентифікацію. Розбирайте документ.
• Нечитабельна відповідь означає невідомо, ніколи не порожньо. Порожній сервер справді існує, і він видає один порожній результат, а не помилку. Ці два випадки насправді різні, і розрізняти їх і є вся робота.

REST дає збій знову ж по-іншому: непридатний ключ повертається як HTTP 401 з цілком порожнім тілом. Тож перевірка зʼєднання має зондувати обидві поверхні й повідомляти про них окремо. Зелений результат REST поряд із мовчазним XML API означає, що список облікових записів, список планів і кожна зміна плану залишаться порожніми, а спокуслива думка полягатиме в тому, що в клієнта немає облікових записів.

Код помилки не каже вам, що саме пішло не так

Помилки REST у Plesk несуть числовий код, і його спокусливо використати для розгалуження. Як виміряно, він не класифікує:

• 1007 охоплює і «цей домен уже існує», і «цей логін клієнта вже існує».
• 1013 охоплює і «немає такого сервісного плану» (REST), і «домен не існує» (XML).
• 0 означає немає коду, а не немає помилки.

Для інтеграції білінгу шкода потрапляє в логіку повторних спроб. «Домен уже існує» після оплаченого замовлення може означати, що попередня спроба вдалася наполовину і варто подивитися, перш ніж пробувати знову; «немає такого сервісного плану» означає, що замовлення ніколи не вдасться і має потрапити до людини. Вони належать до однієї родини кодів. Тож класифікує текст, і ця відповідність має бути в одному-єдиному місці вашого коду, а не виводитися заново в кожній точці виклику.

Є ще й пʼята форма збою: попросіть у REST маршрут, якого не існує, і він відповість HTML-сторінкою, а не JSON.

Невдале замовлення може заблокувати повторну спробу

Виміряно: створення домену на сервісному плані, якого не існує, повертає HTTP 404 із зрозумілим повідомленням, і обʼєкт домену все одно існує після цього, без типу хостингу й із порожнім кореневим каталогом документів. Plesk спершу створює обʼєкт, а вже потім застосовує план, і нічого не відкочує, коли другий крок зазнає невдачі.

У процесі білінгу це звучить так: клієнт оплатив, провізіювання зазнало невдачі, і повторна спроба тепер зазнає невдачі інакше, бо домен уже зайнятий обліковим записом, якого клієнт так і не отримав. Другий збій виглядає як дубльоване замовлення, а це одна з найбільш заплутаних речей для налагодження за зверненням у підтримку.

Звідси випливають дві дешеві дії. Розвʼяжіть план, перш ніж будь-що створювати: список планів у вас уже є, тож знайдіть назву локально і відхиліть замовлення, перш ніж торкатися панелі, що усуває цей збій, а не обробляє його. І прибирайте після невдалого створення, бо залишений уламок перетворює одне невдале замовлення на назавжди заблоковане доменне імʼя.

Для контрасту: помилка перевірки поля, як-от дубльований логін клієнта, повертає HTTP 400 і не залишає нічого. Ця перевірка виконується до створення; лише пошук плану відбувається запізно, щоб вас урятувати.

Два виклики, у кожного з яких є середина

Видалення підписки виконується як DELETE /domains/{id}, а потім DELETE /clients/{id}. Якщо перший вдається, а другий ні, у вас лишається запис клієнта, який нічим не володіє: невидимий у більшості подань і помилка дубльованого логіна наступного разу, коли цей клієнт повернеться. За 7,7 секунди видалення також достатньо довге, щоб мережа могла його перервати, тож скасування заслуговує на таке саме поводження, як і провізіювання: прочитайте панель назад після цього й звірте з масовим читанням, а не з відповіддю, яку ви отримали.

Підвищення та зниження планів мають свій власний закуток. <webspace><switch-subscription> не приймає назву плану, лише GUID плану або його зовнішній ID, тоді як усюди в іншому місці в Plesk на пакет посилаються за назвою. Provibr зберігає назву як те, що бачать люди, і виконує переклад назви в GUID усередині, зі списку планів, який опитування й так отримує. Натомість зберігати GUID у вашій системі білінгу працює рівно доти, доки хтось не перебудує план.

Де живе рахунок

Три моменти вище становлять лише половину хостингового продукту. Друга половина полягає в тому, який вигляд має ваш власний рахунок.

Ви платите за потужність, за кожним типом ресурсу, і обліковий запис хостингу є одним із них. Кожна підписка враховується, працює вона чи ні; не враховується лише призупинена. І це правильний бік для нагадувань: призупинення простроченого клієнта звільняє слот, тоді як його дані лишаються недоторканими, а відновлення забирає його знову.

Перевищення ліміту не блокується в момент, коли воно стається. Його виявляють, вам повідомляють, який тип ресурсу й наскільки, і ви маєте один робочий день, щоб це виправити. Якщо цей час спливає, найновіші сервери понад лімітом вимикаються, найновіші першими, тож те, що ви збудували найраніше, виживає. Друге перевищення протягом тижня дає годину замість дня, бо інакше пільговий період можна було б поновлювати нескінченно, опускаючись під ліміт і знову його перевищуючи. Ніщо не запускається для вас назад, коли це владнано: увімкнути машину є рішенням, і платформа не ухвалює його, поки ніхто не дивиться.

Кожен період створює проформу, яку ви можете прочитати й роздрукувати, а остаточний рахунок надходить із бухгалтерії у вигляді файлу. Рядок рахунку фіксує назву пакета такою, якою вона була в момент виставлення рахунку, тож перейменування плану згодом не переписує історію.

Що Provibr робить і чого він свідомо не робить

Provibr стоїть між вашим білінгом і вашим сервером Plesk. Підписка є звичайним рядком: замовте її, призупиніть, відновіть, змініть її сервісний план, видаліть. Призупинення проходить через поле, яке читає опитування. План розвʼязується перед створенням, а невдале створення прибирається. Кожна зміна завершується зчитуванням підписки назад, тож зберігається те, що спостережено, а не те, що запитано. Агент зʼєднується назовні з вашої власної мережі, тож порту 8443 не доводиться дивитися в інтернет.

Чого він не робить: не керує самим сервером Plesk і не заглядає всередину підписки. Він також ніколи не запитує в Plesk набори даних, що містять пароль FTP або хеш пароля клієнта, обидва з яких панель віддає у відкритому вигляді, якщо їх запитати.

Читати далі

• Як продавати вебхостинг за допомогою Plesk: модель продукту, два API і про що ми ніколи не запитуємо панель.
• Біллінг і ліцензія: потужність, тарифікація за рівнями, кредит, проформи та що відбувається понад лімітом.
• Налаштування Plesk: ключ API, сервісні плани, вебплани та імпорт підписок.

Виміряно на Plesk Obsidian 18.0.80 у серпні 2026 року, з відповідями, записаними як фікстури. Повторне призупинення, ключі в межах реселера та поведінку під реальним навантаженням трафіку не вимірювали, і вони позначені як такі вище.