WHMCS 8.2: проверка личности пользователя

Новости
История вопроса

А у меня другие названия были ) В итоге я решил hosting.stream использовать в будущем потом. Типо мог бы только alice2k, но решил «а вдруг через 10 лет все же кто-то еще будет юзать»


Итак
Новое в WHMCS 8.2: проверка личности пользователя

hosting.kitchen/whmcs-com/novoe-v-whmcs-82-proverka-lichnosti-polzovatelya.html


Соснули хуйца да? Советы и мое мнение никому не нужно да? Проглатывай дальше тролль.

upd
у нас в РФ это может быть тинькоф ID сбер ID или госуслуги ID
ну или «известный в узких кругах» любой доверенный проект. например мой. или например на базе ISPsystem. или на базе SELECTEL даже.
mail ID
yandex ID
МТС ID
Билайн ID
Мегефон ID
Теле2 ID
прочее прочее
1 раз верифицировался — и больше уже не нужно
конечно и фейк мошеннические схемы могут пройти тоже

НО суть в чем? не нужно 500 раз доказывать что-то кому-то

и например если бы я верифицировал людей — мне документы не нужны
у меня другие критерии «нормального человека»

а так же это решило бы проблемы спама и ботов
и даже бесплатные акции с промокодами — проблема была бы решена
даже на СМС ЕБАННЫХ МОЖНО БЫЛО СЭКОНОМИТЬ если бы такой ID был именно ДЛЯ РЫНКА ХОСТИНГА
EMAIL рассылки перестали бы в спам залетать — если бы рассылки шли в системе ID

Даю советы по биллингу любому желающему

Статьи
Общее описание.
Должно быть две версии биллинга.
Первая версия это когда база данных клиентов локальная. Каждый установивший биллинг просто для себя клиентов копит. И начинает продавать с нуля под свою нишу.
Вторая версия, это когда при установке он добровольно соглашает с тем, что все регистрации с его проекта будут идти в общаг на будущее. Но зато он сразу сможет по уже готовому кем-то из прошлых хостеров, общагу, прорекламировать свой товар. Должен быть список всех хостингов кто участвует в общаге. А клиенты подобных хостеров должны просто переключаться по проектами и смотреть кто там и что продает.

Модель продажи биллинга.
Стандартная модель — помесячно, годовая, или вечная лицензия.
Либо модель будушево — брать % с оборота продаж всех товаров в биллинге, % за пользование биллинга. % за пользование обоих вариантов, хоть общага, хоть личного приватного.
Если кто-то будет делать биллинг, сами решите, что для вас удобнее. Брать % или продавать помесячно. Или может дорогую вечную делать как делает hostbillapp.

Методы оплаты биллинга.
Опять же два варианта.
Вариант для тех кто уверен в себе. Делает все как везде, подключается куча платежных модулей, интегрируется все. И потом поддерживается, все обновления API приходится постоянно обновлять создателю биллинга.
Вариант №2 — в биллинге делается пополнение по коду. А коды продаются как ваучеры непосредственно самими хостерами. Например какой-ниб хостер просто берет ставит модуль робокассы и назначает товару на 100р код какой-то, товару на 500р код еще один, на 1000р еще один. Т.е. хостер сам создает те платежные методы которые ему удобны, принимает там бабки автоматически, а клиенты получают коды, которые просто вводят в форумы в биллинге и на баланс биллинга зачисляется нужная сумма. Гибко, удобно, быстро и готово к продажам без гемороя.

Модульный биллинг.
Конечно же биллинг должен быть модульным.
Изначально он должен быть заточен под продажу выделенных серверов. Или может быть кто-то заточит его на ВДС, а может кто-то на шаред. Но я считаю эти модели давно в прошлом, поэтому логично что затачивать нада под дедики.
А все остальное — модульно.
Перепродажи API разных дата-центров, как отдельные модули.
Допустим при модели тарификация где берется % от продаж — все модули бесплатны. Просто хостер тыкает «включить» и включает те дата-центры какие хочет перепродавать. Ну конечно по FAQ все там настраивает уже сами настройки модуля.
А если продажа биллинга идет по штучно, помесячно, или единоразово даже — то каждый модуль имеет свою стоимость и так же помесячно или единоразово оплачивает и появляется возможность его включить.
Биллинг должен быть без говна, без доменов, без ssl, без прочего шлака. Все это — модули.
Перепродажа облаков — модули.
Хочешь продавать домены? Включи модуль регистратора.
Хочешь толкать ssl — включи модуль ssl сертификатов.
Хочешь захуярить шаред хостинг? Подключить модуль шаред хостинга. И тому подобное. Все гибкое. Никакого лишнего мусора. Включается только то, что человек хочет продавать.

Основа.
Я буду описывать основу на примере выделенных серверов.
Во первых — боковая колонка. Это уже стандарт индустрии. И чтобы ее можно было самому настроить те пункты, какие нужны.
Поиск по тарифам — по тексту тарифа — тоже стандарт. Не нужны никакие бегунки от озу как делают на сайтах за 40 миллионов евро.
А просто нужна форма поиска, куда можно забить что угодно, например SSD — и будет показано все с ssd, или забить i7-6700k и будут показаны тарифы только с этим процессором. И так далее. Реализация подобного хорошо видна на аукционе хетзнера.
Метки для тарифов тоже можно оставить, в Bill ISP метки достаточно хорошо реализованы.
Выделение цветом html тарифов, чтобы можно было выделить распродажи и тому подобное.
Возможно даже сделать «закрепленные тарифы» — чтобы одной кнопкой из биллинга закрепить тариф, чтобы как тема на форуме закрепляется, так и тариф закрепился и всегда был только наверху.
Сортировка. Так как в мире дата-цетнров огромная куча. То товаров будет 10000 50000 и выше. Сортировка должна начинаться — с Страны. Потом идти на Город/локацию. Потом уже группам, типо бомж серверы, типо дорогие серверы, типо там энтерпрайз, прочее прочее, группы админ может сам создавать уже какие хочет. Т.е. уже уровень вложенности не 2, а 3. Текушие биллинги дальше 2х не ходят. В идеале сделать карточку из 4 уровней вложенности. Чтобы создатель сам потом уже поделил 10000 товаров так как ему удобно.

Тикетница.
Идеальная тикетница — внешняя тикетница.
Чтобы не засорять биллинг мусором, сразу подключать какой-ниб bitrix24.ru бесплатный тариф и через него прогонять.
Либо делать это на любой внешней CMS.
В биллинге же должно быть что-то вроде — формы ответов.
Вот когда вы отвечаете — у вас накапливается куча тикетов, которые не закрыты. Потому что они «в процессе» или «ждут ответа от клиента». Т.е. не на 100% еще решены эти вопросы.
И вот они висят все одним списком. Даже отступов или пробелов нихуя нет. Чем их больше тем сложнее ориентироваться.
Идеальная тикетница — можно создавать категории. И переносить тикеты по уровню. Допустим в самом верху категория. Потом в середке. Потом еще ниже. И все эти 3 категории — у них есть отступ и пробел. И вот ты как хостер сортируешь по ним потом. И это — удобно.

Функционал.
Конечно же бесплатный SSL lets чтобы из панели сам делался.
Конечно же подключение внешних SMTP yandex/mail/google/свой-сервер — как сейчас сделано на VM-6 панели
Возможно уведомления сразу в социальные сети или мессенджеры, типо в телегу дублировать или в VK-прочее.
Делать рассылки. Делать рассылки по сегментам.
Промо-акции, скидки.
Возможность сделать Объявление для всех. Типо какое-то поле, куда ты вписываешь свой html и оно закрепляется и все его видят. Это может быть техническая авария. Или может быть это распродажа. Или «без установки сбрасываешь серверы актуально 1-2 дня». Тому подобное.
Резервное копирование — на внешние хранилища. Ну как везде.
Журнал посещений. И чтобы указать место куда он будет сохраняться, чтобы в бесконечно можно было сохранять например даже на отдельном хранилище.
Возможно реализовать какой-то доверенный ID для хостинг рынка. Например на базе «модели с общей клиентской базой» где как раз уже будут проверенные регистрации.
Конечно же активные сессии. Конечно же fail2ban nginx правила чтобы банить сразу из панели.
Настройка собственного бренда
Настройка блокировок по IP, по почтовым доменам и просто возможность банов.

Вторичный функционал.
Возможно защита от мошенников посредством sms шлюзов.
Локализации языки
Собственные шаблоны рассылок на email писем уведомлений
Реферальная система
Договоры
Персональные данные
Налоги
Валюты для методов оплат



Да, мне не жалко поделиться. Хоть и у нас тоже будет биллинг в будущем.
Мысли by alice2k :) Если кто-ниб прочитает и не будет знать кому сказать спасибо.