White label платформа под своим брендом

White label торговая платформа — ваш бренд на готовом скрипте: клиент видит ваш домен, логотип и письма, а не Microscript. Лицензия и обновления продукта остаются продуктовыми, оболочка становится вашей. Это не «нарисовать логотип на чужом SaaS без доступа», а развёртывание скрипта под собственной маркой с настраиваемой витриной и кабинетом.

Запрос white label чаще всего приходит из Forex/БО, иногда из магазина или биржи. Смысл один: быстро выйти на рынок с рабочей логикой счетов, кабинета и платежей, не собирая терминал годами. Рядом по каталогу: Forex, бинарные опционы, магазин, кастомная разработка — сайт под ключ.

Что меняют при white label

• Логотип, фавикон, цвета, название в кабинете и письмах.
• Домен и почта отправителя (SPF/DKIM на вашем домене).
• Тексты лендинга, оферта, политика, контакты поддержки.
• Реквизиты и платёжные ключи мерчанта — ваши.
• Языки интерфейса при мультиязычности — многоязычный сайт.

Что обычно не «перекрашивается» за вечер: рыночная логика котировок, ядро ордеров, схема БД. И это нормально — вы покупали готовый двигатель, не заказ на изобретение рынка.

Чем white label отличается от сайта под ключ

White label — лицензия продукта с известной моделью. Сайт под ключ — уникальный бриф, дизайн, своя логика. Если вам нужен кабинет трейдера как в продукте — white label. Если нужен корпоративный сайт услуг без торгового ядра — корпоративный сайт или лендинг. Смешение ожиданий («хочу Forex, но чтобы всё было уникально как у Nike») бьёт по срокам и бюджету.

Домен, SSL, почта

Домен сразу боевой или временный стенд — решите до заливки контента. HTTPS обязателен до рекламы кабинета. Письма с чужого shared-домена попадают в спам: настройте DNS почты. Логотип в письмах — абсолютные https-URL, не относительные пути с локального стенда.

Смена домена после индексации и после раздачи ссылок клиентам болезненна. Зарезервируйте имя до публичного анонса.

Кабинет и публичная часть

Публичка — лендинг, тарифы, регистрация. Кабинет — счета, операции, поддержка. Проверьте оба контура под брендом: шапка, футер, title, ошибки 404. Демо-счёт и KYC, если есть в продукте, тоже должны говорить языком вашего бренда, не дефолтными строками.

Скриншоты для маркетинга делайте уже с вашим UI. Скриншоты «как у поставщика» в рекламе под вашим именем выглядят странно и путают поддержку.

Платежи и комплаенс

Ключи платёжки, тексты рисков, ограничения по странам — зона оператора. Скрипт даёт формы и статусы. Не обещайте в лендинге то, чего нет в оферте и в настройках продукта. KYC-ворота настраивайте до кампании «открой счёт за минуту», иначе минута превратится в день ручных исключений.

Процесс запуска

1. Поднять стенд на VDS/MicroServer, проверить базовый сценарий продукта.
2. Сменить бренд: лого, цвета, названия, письма.
3. Подключить домен, SSL, почту.
4. Прописать юридические страницы и контакты.
5. Подключить оплату на тестовых ключах, затем боевых.
6. Прогнать регистрацию → кабинет → операцию → письмо.
7. Только потом — трафик.

Поддержка и обновления

Уточните, как приходят обновления скрипта и что будет с вашими кастомными CSS. Чем меньше правок ядра «напильником», тем проще обновляться. Кастом держите в теме/конфиге. Документируйте свои патчи — через полгода вы сами не вспомните, зачем правили шаблон письма.

SLA поддержки продукта и ваша линия поддержки клиентов — разные линии. Клиент пишет вам; вы эскалируете в продуктовую поддержку по лицензии. Не давайте клиентам прямой контакт вендора, если модель white label это не предполагает.

Типичные ошибки

Анонс до настройки почты. Смешение тестовых и боевых ключей. Оферта «скопирована» с конкурента без правки реквизитов. Обещание MT4/уникального терминала, когда продукт другой. Мультиязычность в баннере при одном языке в кабинете. Скрытие рисков в UI мелким шрифтом — регуляторный и репутационный риск оператора.

Контент и тон голоса бренда

White label часто оставляют с дефолтными английскими строками в ошибках кабинета и письмах. Пройдите словарь интерфейса до рекламы: регистрация, пополнение, вывод, ошибки валидации. Тон — ваш: строгий финтех или проще, но единообразно. Смесь «Вы» и «ты» в одном кабинете выглядит незавершённой сборкой.

Юридические страницы не копируйте слепо с конкурента. Риски, комиссии, юрисдикция, контакты — ваши. Лендинг может быть коротким, но оферта не должна ссылаться на чужой бренд и несуществующий адрес.

Фавикон, OG-картинка, title главной — мелочи, которые видны в закладках и шарах. Если везде «Welcome | ScriptName», бренд не случился.

Операционный день после запуска

Кто отвечает на тикеты клиентов, кто смотрит платежные ошибки, кто держит связь с поддержкой продукта. Расписание дежурств важнее нового градиента на кнопке. Логи платежей и регистраций сохраняйте: без них разбор «деньги списались, счёта нет» превращается в гадание.

Регламент на инцидент: платёжка лежит, котировки не приходят, почта отвалилась. Даже короткий runbook из десяти строк экономит панику. Клиентам пишите статус честно; молчание хуже короткого «чиним, депозиты в очереди».

Раз в неделю смотрите воронку: регистрация → верификация → первый депозит → первая сделка. Где обрыв — туда продуктовые и UX-правки, не новый баннер «бонус 200%».

Чеклист визуального бренда

Пройдитесь списком: лого в шапке кабинета, лого на лендинге, лого в письме, фавикон, загрузчик/splash если есть, PDF или выписки если продукт их отдаёт. Часто забывают письмо «забыли пароль» и 404-страницу. Именно там клиент внезапно видит старое имя продукта и пишет «нас обманули».

Цвета кнопок CTA в кабинете и на лендинге согласуйте. Не обязательно пиксель в пиксель, но семейство должно узнаваться. Тёмная тема кабинета при светлом лендинге допустима, если оба выглядят намеренно, а не как сборка из двух шаблонов.

Перед кампанией попросите человека вне команды пройти регистрацию с телефона. Свежий взгляд ловит «остался Test Broker» быстрее, чем глаз разработчика, который смотрит на стенд месяц.