Партнёрская витрина за полминуты: как устроена мультиарендная платформа

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

Что требовалось

У офлайн-магазина есть покупатели, которые готовы рекомендовать. Нужно превратить рекомендацию в канал: человек получает ключ, за полминуты разворачивает витрину с товарами магазина под своим именем, продаёт своим знакомым и получает вознаграждение.

Ограничение, определившее архитектуру: продажа должна проходить через кассу и склад магазина. Партнёр не закупает товар, не держит остаток и не принимает деньги. Он приводит покупателя — и всё.

Чей остаток

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

Поэтому каталог единый, а остаток транзакционный: резерв происходит в момент заказа, а не в момент показа. Партнёрская витрина — это способ показать один и тот же склад под другим оформлением, а не отдельный магазин.

Побочная выгода: магазин заводит товар один раз. Появление сотни партнёров не создаёт сотню карточек, которые надо обновлять.

Чьи деньги: решение, стоившее переделки

Самая дорогая находка проекта, и она не про код.

Мессенджеры дают встроенный приём платежей, и он выглядит идеально для витрины-бота. Но провайдер платежей привязан к боту. Значит, в боте партнёра деньги придут партнёру, а не магазину.

Для модели, где партнёр ничего не закупает и не отвечает за товар, это недопустимо: он получает полную сумму заказа, а магазин должен потом её у него забрать. Это не канал продаж, а генератор задолженностей.

Поэтому оплата идёт только через эквайринг магазина, а партнёрскому боту достаётся роль витрины и привязки. Решение выглядит скучно, но именно оно делает схему рабочей.

Ту же развилку разбирал шире в статье про учёт партнёрских выплат.

Чей клиент

Третий вопрос — привязка. Если она держится на промокоде, который покупатель должен вспомнить и назвать, споры «чей это клиент» возникнут на первой же неделе.

Здесь привязка техническая: партнёрский ключ зашит в витрину, заказ приходит с ним, атрибуция не зависит от памяти покупателя. Покупатель вообще не знает, что участвует в партнёрской схеме, — он просто покупает в магазине, который ему показали.

Вход покупателя тоже сделан без формы: подпись данных мессенджера проверяется на сервере, номер телефона приходит по кнопке «поделиться контактом», имя и телефон подставляются в заказ сами. Ноль полей для заполнения — и, что важнее, ноль опечаток в номере.

Один вебхук на всех ботов

Техническая деталь, которая определяет, масштабируется схема или нет.

Наивно каждому партнёрскому боту дать свой обработчик. Тогда сто партнёров — это сто настроек, сто адресов и сто мест, где что-то может отвалиться.

Здесь все боты маршрутизируются через один вебхук: приходит сообщение, система по токену определяет, какому боту и какому партнёру оно принадлежит, и обрабатывает в общей логике. Подключение партнёра становится записью в базе, а не развёртыванием сервиса.

Отсюда и берутся обещанные полминуты: технически подключение — это создать бота, отдать токен, нажать кнопку.

Юридическая деталь, которую находят поздно

Партнёров удобно держать самозанятыми. Но самозанятый по закону не может получать доход по агентским договорам. Если оформить вознаграждение как агентское, схема ломается на уровне бухгалтерии, а не программы.

Поэтому вознаграждение оформляется как услуги по привлечению клиентов. Разница в формулировке, последствия — в законности всей конструкции.

Это тот класс решений, которые невозможно найти в коде и которые обнаруживаются либо на этапе проектирования, либо при первой проверке.

Почему демо показывают на чужом ассортименте

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

Показывать платформу на вымышленном магазине бесполезно: клиент смотрит на чужие товары и не примеряет на себя. Показывать на его ассортименте — совсем другой разговор, там он сразу видит свои карточки и свои цены.

Поэтому в системе есть роль, которая создаёт новый магазин с копией демо-набора и переключается между магазинами. Партнёр по продажам заводит стенд под конкретного клиента заранее, заливает его ассортимент и приходит на встречу с готовой витриной.

Из этого же следует мультиарендность на уровне платформы, а не только на уровне партнёров: магазинов много, они изолированы, а роль платформы видит все. Это решение стоило одного дня разработки и заметно изменило, как продукт показывают.

Частые вопросы

Чем это отличается от обычной реферальной программы?

Реферальная программа даёт ссылку на общий магазин. Здесь у партнёра свой бот со своим именем и оформлением. Разница в ощущении: одно выглядит как подработка на проценте, другое — как собственная витрина.

Что если партнёр начнёт вести себя некорректно?

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

Нужен ли отдельный бот каждому партнёру?

Да, если нужна витрина под его именем. Есть и второй сценарий — один общий бот, где привязка идёт по персональной ссылке входа. Он проще в запуске, но партнёр в нём не чувствует магазин своим.

Это подходит только для офлайн-магазинов?

Нет. Модель переносится на любой бизнес, где есть каталог и люди, готовые рекомендовать: доставка, автоподбор, услуги с фиксированным прайсом. Условие одно — продажа должна проходить через того, кто отвечает за товар.

Что происходит, когда товар заканчивается?

Он пропадает во всех витринах сразу — остаток общий. Это и есть главный аргумент против копирования каталога каждому партнёру: при копиях десять человек продолжают продавать то, чего уже нет, а разбираться с покупателями будет магазин.

Сколько партнёров выдержит такая схема?

Ограничение не в количестве партнёров, а в числе ботов на один вебхук и в нагрузке на базу. Для сотен партнёров схема работает без изменений; на тысячах придётся разносить обработку, но это уже другая задача.

Коротко о главном

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

Технически ключевое — единый каталог с транзакционным остатком и маршрутизация всех ботов через один вебхук. Юридически — форма договора с самозанятым. Продуктово — привязка, не зависящая от памяти покупателя.

Демо-стенд развёрнут, бот и вебхук живые, витрина рендерит каталог; эквайринг и выплаты — следующий этап. Если хотите посмотреть, как это работает на вашем ассортименте, — пришлите каталог, залью на стенд. Напишите в Telegram, MAX или VK.