Все статьиБизнес8 мин

О биллинге в прокси-бизнесе

История биллинга прокси-сервиса с 2011 года: свой код, потом WHMCS и снова свой. Честно о граблях, отставании от рынка и почему коробка нас подвела.

Владимир Извеков

Владимир Извеков

Founder20 июля 2026 г.

#биллинг#прокси-бизнес#WHMCS#инфраструктура#изнанка

А давайте поговорим о базе, без которой продавать не получится? В этой статье расскажу про биллинг.

Итак, вы — предприниматель.

Итак, вы — предприниматель. Решили заняться продажей прокси, и перед вами встает вопрос: как клиенты будут покупать ваши услуги? Вернее, даже не так — вы же понимаете, что для продаж нужен биллинг, но какой — написанный самостоятельно или коробочная версия от стороннего разработчика? Вы идете изучать рынок и предложения. Смотрите цены и сроки интеграции. В 2011 году, когда мы стартовали, выбора практически не было, а то, что было, стоило столько, что никогда не отбилось бы, поэтому вариант тут только один — берем Юру-программиста и сажаем его писать свой. Юра старается, но опыта у Юры нет, поэтому биллинг работает (потому что Юра старается), но он работает так, что лучше бы не работал (потому что у Юры нет опыта).

Клиентам плевать.

Клиентам плевать. Продукт востребованный — клиент покупает, хоть и плюется. О клиентоориентированности в то время нет речи, потому что:

  1. Какая клиентоориентированность — на дворе 2012-2013 годы?
  2. Даже если бы хотели — биллинг не позволяет особо разгуляться в плане опций.

Но главное сделано — клиент МОЖЕТ выбирать и оплачивать большие пакеты услуг (больше 1000 IP) и более того — есть выбор гео-локаций.

Конкуренты пока в большинстве своем такого не предоставляют. На тот период времени — победа. Сервис быстро растёт. Идет время.

Задач по биллингу становится всё больше

Задач по биллингу становится всё больше, а желания у программиста их реализовывать в том виде, в котором это просят собственники, становится всё меньше. Почему? Потому, что он знает лучше, как надо. Юра зарабатывает как небольшой отдел, но как известно, не в деньгах счастье. Начинается не то, чтобы саботаж, но откровенное забивание на задачи. Если вы с таким сталкивались — напишите, пожалуйста. Очень интересно, это нам так везло, или история регулярная? Что делать? Вариантов опять особо нет...

Переходим на WHMCS

Юра уходит, приходят новые программисты Саша и Алексей, и собственники задумываются. Им не хочется, чтобы с Сашей и Алексеем произошло со временем то же, что и с Юрой. Собственникам хочется, чтобы биллинг мог подхватить любой компетентный программист, поэтому опять мониторится рынок. Из всего кажущегося многообразия выбор падает на WHMCS. Коробочное решение — биллинг для хостинг-провайдера, который постоянно допиливают создатели. Еще один плюс — модульная система. Новые опции можно внедрять через добавление штатных или самописных модулей, а ядро трогать не надо. Кра-со-та! Казалось бы, но время опять всё расставит по местам.

Коробка, которая стала дикобразом

В один не очень прекрасный день Саше приходит задача создать FPR2-модуль. На тот момент сервис уже чудовищно (лет на пять) отстает от конкурентов в плане опций и гибкости в создании услуг. Банально нет возможности сделать прогрессивную скидку или добавить дополнительный white-IP для того, чтобы клиент мог работать с двух адресов. WHMCS + фактор Х (мы не знаем, что случилось с Сашей) = год потраченного времени и денег и нулевой результат. Модуль не готов, отставание от конкурентов уже не пять, а семь лет. Саша, сославшись на семейные обстоятельства, уходит. Знаете, что случилось с WHMCS-биллингом за эти годы? Он оброс доп. модулями так, что стал похож на дикобраза. Никто, кроме Саши (да и он не до конца), не понимал, как с этим работать. Еще полгода убили, чтобы новый сотрудник разобрался хотя бы в основных моментах.

Сейчас продолжаем работать, но всё еще всплывают новые вопросы. Вот вам и "коробочное решение, которое подхватит любой программист"!

Круг замкнулся

В итоге: круг замкнулся, и мы в настоящий момент доделываем своё собственное решение. Т.е. мы опять вернулись к тому, что делаем собственный биллинг. Да, во многом помогает ИИ, но вся архитектура и контур контроля, тестирования и баг-фикса построена и контролируется людьми. Функционально получается бомба — мне, по крайней мере, очень нравится. Как раз то место, где мы отставали, сейчас выглядит самым сильным: человек полностью конфигурирует услугу под свои задачи, начиная с выбора Гео-базы (Ripe или MaxMind) и заканчивая опцией UDP. Для тех, кто понимает, структура такая: ТИП прокси (DC, ISP, personal) — ГеоБаза — Количество IP — Страна — Количество одновременных коннектов — Количество White-IP (для авторизации) — Функция UDP (on/off). И всё это биллится, уменьшается по цене в зависимости от предоплаченного периода, продлевается/обновляется и т.д. В общем, в конце месяца планируем отправить всё в прод на одном из наших сайтов, а дальше уже масштабируем на остальные.

Кому интересно — пишите, дадим потестить бесплатно. В общем, что я хочу в конце сказать — универсального ответа на вопрос, какой биллинг лучше, я всё же дать не могу. При всех минусах, те решения, которые принимались, были максимально адекватны времени принятия и на тот момент выглядели наиболее оптимальными. Мы просто прозевали момент, когда надо было "спрыгивать" с WHMCS обратно на самописный биллинг. Вот это было ошибкой. В остальном — отталкивайтесь от ваших возможностей и внешних условий. Всем быстрого, гибкого и надежного биллинга! В следующей статье напишу, на что я бы смотрел в первую очередь при выборе прокси, и объясню почему.

Нужны надёжные прокси для вашего проекта?

InfraProxy предоставляет серверные и резидентные прокси для российского бизнеса. Договор, постоплата, техподдержка.