MVP платёжного сервиса: минимальный набор функций

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

Почему платёжный MVP разрастается до монстра

Проблема начинается ещё на стадии обсуждения с командой разработки. Фраза «сделайте нам платёжный сервис» автоматически вызывает в голове разработчика образ полноценного продукта — с авторизацией через три соцсети, возвратами, рекуррентными платежами, личным кабинетом с графиками и push-уведомлениями. Это не злой умысел: просто люди инстинктивно строят «правильно», а не «минимально».

Второй источник раздувания — регуляторная паранойя. Стартаперы читают статьи про ФЗ-115, 161-ФЗ и требования ЦБ и приходят к выводу, что без стека compliance-инструментов корпоративного уровня выходить нельзя. На самом деле для MVP работают совсем другие правила.

Что реально обязательно: восемь функций

После десятков FinTech-проектов мы в IT2BE пришли к конкретному минимуму. Вот что должно работать в день запуска — и ничего лишнего:

1. Приём платежей через шлюз. В России в 2026 году для MVP достаточно одного шлюза: ЮKassa или Тинькофф Pay. ЮKassa подключается за 1–3 рабочих дня, поддерживает карты, СБП и ЮMoney. Для 95% FinTech-сценариев этого хватает.
2. Регистрация и авторизация пользователя. Email + пароль с подтверждением по email или номер телефона + SMS-код. Никаких «Войти через Google/VK/Госуслуги» в MVP — это недели интеграций ради удобства, которое пользователь оценит потом.
3. KYC-лайт. Верификация по номеру телефона через SMS. Этого достаточно, чтобы привязать пользователя к реальному человеку и выполнить минимальные требования без полноценной проверки паспорта.
4. Проведение транзакции. Создание платежа, редирект на страницу шлюза, обработка callback (webhook) от шлюза о статусе — успех, ошибка, ожидание.
5. История транзакций. Простой список: дата, сумма, статус, получатель/отправитель. Без фильтров и экспорта в Excel — это можно добавить в версии 1.1.
6. Личный кабинет. Баланс (если он есть в логике продукта), данные профиля, смена пароля. Один экран, не дизайн-марафон.
7. Уведомления о транзакциях. Email или SMS при успешном платеже и при ошибке. Без push на первом MVP — они требуют отдельного сервиса (Firebase или APNs), что добавляет минимум неделю.
8. Базовый дашборд для вас. Не для пользователя — для команды. Количество транзакций, общий оборот, количество ошибок. Google Data Studio + прямые запросы в базу работают лучше любого самописного дашборда.

Что не нужно в MVP — и почему это иллюзия необходимости

Есть функции, которые кажутся обязательными, но на этапе MVP только тормозят:

• Несколько платёжных методов. QIWI, WebMoney, криптовалюта, рассрочка — всё это нужно только после того, как вы поняли, кто ваш пользователь и как он привык платить. До этого момента любой второй шлюз — это выброшенные деньги и время.
• Мультивалютность. Если ваш MVP не работает с иностранными пользователями в день запуска, рубль и только рубль. Конвертация, курсы, SWIFT — это масштабирование, не MVP.
• Сложная аналитика транзакций. Сегменты пользователей, когортный анализ, воронки — используйте внешние инструменты (Яндекс.Метрику, Amplitude на free-плане) вместо самописного аналитического модуля.
• Система возвратов с UI. Возвраты через API шлюза делаются из консоли администратора — вы или ваш разработчик сами запускают возврат. Для MVP с небольшим числом транзакций этого хватает с избытком.
• Мобильное приложение. Web-версия с адаптивной вёрсткой проверяет гипотезу не хуже нативного приложения, но разрабатывается в 2–3 раза быстрее.

Compliance-минимум: что реально нужно по закону

Здесь важно не путать «то, что нужно в день запуска» и «то, что нужно через полгода». Для MVP платёжного сервиса:

Обязательно сразу:

• Политика конфиденциальности и пользовательское соглашение — уведомление РКН об операторе персональных данных (это бесплатно, занимает 15 минут на gosuslugi.ru).
• ФЗ-152 — данные пользователей хранятся на серверах в России. Облако Mail.ru, Yandex Cloud или любой российский хостинг решают этот вопрос автоматически.
• Договор с платёжным шлюзом — ЮKassa требует юрлицо или ИП, занимает 1–3 рабочих дня.

Не нужно в MVP:

• Лицензия ЦБ на деятельность НКО — она нужна только если вы сами выступаете оператором платёжной системы. Если вы используете шлюз (ЮKassa, Тинькофф), они уже лицензированы — вы только клиент.
• PCI DSS-сертификация — при работе через шлюз данные карт не проходят через ваши серверы. Шлюз сертифицирован, вы нет, и это нормально.
• Полноценный AML-модуль — достаточно базовых лимитов на транзакции (ЮKassa накладывает их автоматически).

Стоимость и сроки реального MVP

Если взять восемь обязательных функций из списка выше и реализовать их без излишеств, получается следующая картина:

Это не теоретические расчёты — это средние показатели по нашим реальным FinTech-проектам.

Подводные камни, которые съедают сроки

Даже с чётким минимальным набором функций есть несколько точек, где проекты спотыкаются:

Sandbox vs. production в ЮKassa. В тестовой среде платежи проходят всегда. В production шлюз проводит дополнительную проверку юрлица и может заблокировать первые транзакции до ручной верификации. Заложите 2–3 дня на «раскатку» в проде и не планируйте публичный запуск сразу после деплоя.

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

Webhooks и надёжность. Платёжный шлюз уведомляет ваш сервер о статусе транзакции через webhook. Если ваш сервер был недоступен в момент уведомления — нужен механизм повторной проверки статуса (polling). Это простая функция, но про неё часто забывают в MVP.

Тестирование с реальными деньгами. Не все сценарии ошибок воспроизводятся в sandbox. Зарезервируйте 3–5 тысяч рублей на тестовые транзакции в продакшене — сразу после запуска, до открытия доступа пользователям.

Итог

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

Если вы сейчас проектируете FinTech MVP и хотите понять, какой минимум подходит именно под вашу модель — запишитесь на бесплатный 30-минутный Zoom-колл с командой IT2BE. Разберём вашу идею, определим обязательный набор функций и оценим сроки.