1.1 Vision & Scope

Документ задаёт бизнес-рамку продукта PSP Aggregator: цели, аудиторию, глоссарий и границы MVP.

1. Бизнес-цели

1.1 Глобальная цель

Создание B2B-маркетплейса платежных решений — аналога платформы AllPayPayz. Платформа объединяет провайдеров платежей, мерчантов и агентов в единую экосистему.

[Post-MVP]: открытая регистрация, кабинеты провайдеров, автоматизированный биллинг и расширенная аналитика.

1.2 Бизнес-цель платформы

Основная бизнес-цель MVP — переход от учёта в разрозненных таблицах (Excel/Google) к автоматизированному бизнес-процессу.

Запуск базовой платформы в закрытом режиме: единая инвайт-ссылка, роль назначает только SuperAdmin.
Мерчанты подбирают платежные решения. В каталоге виден Alias оффера; Real Name провайдера скрыт до статуса сделки Agreed.
Агенты привлекают мерчантов и задают свою Agent Margin.
SuperAdmin и Admin централизованно контролируют систему.
Платформа собирает аналитические данные и ведёт системный трекинг действий.

2. Ключевые особенности платформы

Закрытая экосистема: регистрации по единой инвайт-ссылке. Доступ открывается после того, как SuperAdmin назначит роль.
Анонимность провайдеров: в каталоге агенты и мерчанты видят Alias оффера, не Real Name. После Agreed имя открывается мерчанту; агент его по-прежнему не видит.
Аналитический слой: сквозное логирование действий с привязкой мерчанта к агенту, если агент участвовал в сделке.

3. Целевая аудитория

Мерчант / Merchant: бизнес, который ищет платежное решение (PSP).
Агент / Agent: привлекает мерчантов на платформу и ведёт свой пул сделок.
Admin (Операционный менеджер): ведёт каталог, провайдеров и сделки.
SuperAdmin (Владелец): управляет доступом и ролями, осуществляет глобальный контроль.

У провайдера кабинета нет: его заводят только Admin / SuperAdmin.

4. Глоссарий терминов

4.1 Роли и сущности

SuperAdmin (Владелец): единственный, кто назначает роли и модерирует регистрации.
Admin (Операционный менеджер): сотрудник платформы, отвечает за провайдеров, офферы и сделки.
Агент / Agent: собирает Proposal, задаёт Agent Margin, отправляет Secure-ссылку.
Мерчант / Merchant: конечный бизнес, видит Total Fee / Final Fee как единую ставку.
Провайдер / Provider: платежная система. Кабинета в платформе нет. Real Name всегда видят Admin / SuperAdmin; мерчанту открывается после Agreed; агент не видит.
Оффер / Offer: публичный тариф в каталоге на базе провайдера; витринный «товар».
Alias: публичный псевдоним оффера (например Card-EU-01). Для агента и мерчанта вместо Real Name.
Proposal: подборка офферов плюс маржа, оформленная в Secure-ссылку.
Сделка / Deal / Тикет: главная сущность. Ticket-based: итерации внутри одного тикета, а не одноразовая ссылка как единственная модель.
Каталог: витрина офферов с каскадными фильтрами GEO → метод оплаты.
Assignee: на ком сейчас «мяч» по сделке.

4.2 Флоу сделок

Agent Outbound: агент собирает Proposal и шлёт Secure-ссылку мерчанту.
Merchant Inbound: мерчант сам создаёт заявку из каталога или холодный запрос без офферов.
Admin Outbound: Admin шлёт прямое предложение, Agent Margin = 0.

4.3 Ставки

Base Rate  = Raw Provider Rate + Platform Margin
Total Fee  = Base Rate + Agent Margin
           = Raw Provider Rate + Platform Margin + Agent Margin

Raw Provider Rate (Чистая ставка провайдера): видят только Admin / SuperAdmin.
Platform Margin (Маржа платформы): видят только Admin / SuperAdmin.
Base Rate (Базовая ставка): видит агент; в Merchant Inbound без агента — также мерчант.
Agent Margin (Маржа агента): задаёт агент; мерчант разбивку не видит.
Total Fee / Final Fee (Итоговая ставка): то, что видит мерчант — единая монолитная ставка.

Агент не может снизить Base Rate сам: только свою маржу или пинг Request Special Terms админу.

4.4 Статусы (MVP)

Пользователь: Pending, Active, Blocked, Inactive, Rejected.
Провайдер / Оффер: Active, Paused. Пауза провайдера каскадно паузит его офферы.
Сделка: Draft, Negotiation, Agreed, Declined, Revoked, Terminated, Archived.

Истечение срока Secure-ссылки (1 неделя без ответа) переводит сделку в Revoked.

5. Границы проекта

5.1 Текущий функционал (MVP)

Каталог: список офферов с анонимностью провайдеров (Alias вместо Real Name).
Личные кабинеты: мерчант, агент, Admin / SuperAdmin. Кабинета провайдера нет.
Управление офферами: создание офферов на базе провайдеров, статусы Active / Paused.
Сделки: три флоу (Agent Outbound, Merchant Inbound, Admin Outbound), Secure-ссылка, Assignee.
Слой данных и аналитика: инфраструктура для сбора данных и трекинга связей между субъектами.
Интеграция с Telegram: базовые уведомления. Текстовые переговоры в MVP ведутся вне платформы (в Telegram).

5.2 Архитектурные особенности

Модель переговоров (Ticket-based Deal): итерации внутри единой сделки-тикета. Драйвер сделки — смена Assignee. В MVP внутри тикета фиксируются системные пинги (Request Special Terms) и изменения маржи. Полноценный текстовый чат и field-level comments — [Post-MVP].
Кабинет провайдера: не предусмотрен. Заведение и администрирование — только Admin / SuperAdmin.
Регистрация: свободного Sign Up нет. Единая инвайт-ссылка, роль назначает только SuperAdmin.
Автоматизированный биллинг: автоматические выплаты и транзитные взаиморасчёты на стороне платформы не производятся.
Лидогенерация без API-интеграций: платформа — информационный каталог и matchmaker. Нет интеграции с API провайдеров для трекинга транзакций. Сверки комиссий агентов — ретроспективно по отчётам, которые провайдеры присылают админам.
Аналитика трафика: UTM и источники трафика — внешние инструменты (например Google Analytics). Внутри сохраняются базовая история поисковых запросов и факты создания заявок.