ENELIS, все описанное как понимаю относится к ЕС, но если взять Россию, где нет необходимости переделывать систему счетов, шифрование данных и налогообложение, то система выглядит достаточно неплохо, так как всё можно решить за счет внутреннего API и тех самых hook'ов, которые упоминали.
У меня небольшой проект и минимум доработок. Давно был куплен шаблон и переделан под себя, платежные модули по примерам документации пишутся очень просто (менее 100 строк кода). Через hook's для оплаты происходит оплата чека. Также автоматизирована работа с юридическими лицами - автоматическое формирование счетов, выгрузка платежей из банка и их обработка, формирование актов подписанных квалифицированной подписью. Вот реально никаких проблем, но это за счет того, что не нужно было лезть в недры системы.
Почти за 10 лет работы могу вспомнить только 2 проблемы. Одна с официальным модулем ResellerClub - регистрация доменов в части зон не работала из-за неверного составления запросов по доп. полям (решил переходом на свой модуль, возможно позже данные проблемы решили в официальном модуле). Другая проблема связана с заказами на регистрацию доменов. Если в корзине только один домен, то при переходе к оплате заказа, он иногда создается пустым. Это происходит крайне редко, отловить до сих пор не получается, поэтому до сих пор не решил это. Больше ничего вспомнить не могу.
ENELIS, удивлен такое читать про WHMCS. Согласен, что у биллинга могут быть какие-то внутренние несоответствия функционала под законы ЕС, но так, чтобы биллинг работал криво и имел множество багов - не согласен. Согласен с тем, что исходный код WHMCS достаточно ужасен, но стоит отдать должное в том, что они его постепенно улучшают (делаю вывод из сравнения 5.X и 7.Х версий).
Я достаточно неплохо знаком с этим биллингом со стороны разработки, если использовать его задокументированные возможности, то модули работают стабильно и ничего не ломается при обновлении самого биллинга. Исходя из того, что Вы описали - есть ощущение, что используете какие-то модули, которые взаимодействуют с внутренними классами биллинга напрямую (в обход API), либо работают напрямую с базой данных (такой подход вполне вероятен, так как маловероятно, что все описанные задачи можно решить через внутренний API биллинг), что в свою очередь приводит к поломкам при обновлении биллинга.
Да да)) Сегодня только прописывал в шаблон ДНС насильно. Но проблема же решена =) Но я сужу как-то по себе. Что простои с ИСП у меня намного реже и короче, чем когда выпадает whmcs. Там просто сидишь и смотришь на нее почесывая затылок. Индусы не шибко тоже торопятся че-то исправлять.
А что за выпадения WHMCS?
Спасибо за ваш ответ.
Когда упали их сервера лицензий, потянуло только их модули, или лицензию на биллинг в том числе?
Писать самостоятельно, своими руками не представляется возможным, а вот аутсорс с радостью взял бы. Возможно подскажите кто занимается подобным, из проверенных?
Потянуло только модули. Но когда клиенты не могут совершить платежи из-за этого, такое себе удовольствие.
Посмотрите https://www.isplicense.ru/services/other/whmcs-dev/, но возможно есть более дешевые варианты.
IgnatFles, здравствуйте.
BILLmanager не пользуюсь, но расскажу об опыте работы whmcs.com.ua. Пользовался их модулями несколько лет до того момента, пока их сайт не отвалился, что за собой потянуло проблемы с проверкой лицензии на их модули и работоспособность нашего биллинга встала из-за этого. С того момента прошло уже много времени, скорее всего они приняли необходимые меры.
Если будете переходить на WHMCS, то рекомендую делать модули самостоятельно, а не заказывать готовые и зашифрованные. Аргументирую это тем, что у WHMCS неплохая документация и доработка биллинга выполняется достаточно просто, не требуя больших затрат. Для понимания, недавно делали модуль для ЮКассы, вышло всего 100 строк кода, при этом там же идет взаимодействие с кассой (используем свою, не арендуем).
Хорошо, что хоть не решили брать деньги за каждого пользователя в биллинге. А то сейчас всё хостинговое программное обеспечение идет только к этому.
Cpanel стали брать деньги за каждого пользователя в с осени 2019 года, WHMCS тоже разделяет тарифы исходя из количества пользователей.
С такой тенденцией скоро останутся только компании, которые будут иметь свои решения.
Скорее всего (большая вероятность) они перейдут на другой хостинг за 33 рубля в месяц, а тому хостингу наклепают кучу негативных отзывов какой он сякой. Если у клиента цена это самый главный фактор в выборе, то всегда найдется тот, кто даст цену меньше.
Плюсую, продавал много лет хостинг по 10 рублей в месяц, есть большой опыт работы с данной группой клиентов. На долгосрок берут немногие, некоторые найдя аналогичный тариф дешевле уходят туда и просят возврат денег. Обобщенно - высокая нагрузка на поддержку, профит небольшой. Как итог, теперь остался тариф на 500 мегабайт для 1 сайта за 299 рублей в год. Кому поиграться - не берут, кому действительно на долгосрок и просто нужно недорого - берут :)
Подтверждаю, в первом варианте было 0% + 99 рублей за платежи в их же банк до 150 тысяч. От новых тарифов прифигел, в горячей линии порекомендовали написать обращение через интернет-банк о сохранении условий. Отправил на следующий день после анонса, ответа до сих пор нет.
Также рассматривал для перехода Тинькофф и Точку. Однако, после общения с менеджером Тинькофф, они отпали, так как на дебетовую карту вывод только до 150 тысяч, остальные 250 тысяч без комиссии только на кредитную карту (я не пользуюсь). В итоге перешел в Точку, пока впечатления положительные. В Альфе поменяю тариф на 1%, оставил там мелкие платежи.
Сбер зря ругаете, у них вполне неплохой интернет-банк. С учетом того, что у них есть бесплатный тариф с возможность вывода до 150 тысяч, то это реально хороший вариант для многих.
Зависит от настроек сервера, но если правила из примера не работают, то действительно стоит попробовать добавить RewriteEngine on.
Вариант по ссылке тот самый, который имел ввиду, но согласитесь, прописывать правила для 100 доменов неудобно. Можно сделать универсальные:
RewriteEngine on RewriteCond %{HTTP_HOST} !^lite\-host\.in$ RewriteCond %{DOCUMENT_ROOT}/%{HTTP_HOST} -d RewriteRule ^(.*)$ %{REQUEST_SCHEME}://lite-host.in/%{HTTP_HOST}/$1 [P]
Этот вариант будет работать в том случае, если для Apache стоит mod_proxy. Проверил серверы с DirectAdmin, Cpanel и ISPmanager 4 / 5, везде этот модуль стоит из коробки. Если по простому, то прописываете основной домен в правилах, система проверит наличие подпапки запрашиваемого сайта, когда она существует, будет выполнено проксирование запроса в подкаталог через основной домен. Изначально хотел сделать вариант без проксирования, но цикличное перенаправление побороть не удалось.
Также стоит отметить, если сайты содержат свои правила mod_rewrite, то они не во всех случаях могут работать правильно (здесь нужно тестировать каждый случай).
