Одна платформа — много клиентов и ваш бренд на каждом экране

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

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

Третья — отдельная база или отдельный контур на клиента. Так делают, когда этого требуют корпоративные заказчики или персональные данные особой категории. Стоимость эксплуатации выше, зато крупный клиент получает выделенные ресурсы и независимое обновление. На практике модели часто комбинируют: мелкие клиенты живут в общем контуре, а два-три крупных выносятся в отдельные базы.

White-label — это не только другой логотип. Клиент или партнёр должен получить собственный домен, письма с собственного адреса, документацию со своим названием и — что важнее — свои цифры: сколько его пользователей активно, сколько он заработал, сколько должен заплатить вам. Возможность выгрузить эти данные самостоятельно ценится выше, чем цвет кнопки.

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

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

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