РЕЛЕПРЕДЛОЖЕНИЕ
25 ОКТЯБРЯ 2026

РАЗРАБОТКА ПЛАТЁЖНОЙ ПЛАТФОРМЫ СБП

Свой бренд.
Контроль каждого
платежа.

Рабочий тестовый MVP под ваше ТЗ: от создания QR-ссылки до статуса операции, комиссии и уведомления магазина.

Сначала — проверяемый результат

Здравствуйте! Подготовил «РЕЛЕ», чтобы обсуждать вашу платформу на конкретных экранах. Название и визуальный стиль — самостоятельная концепция, которую можно адаптировать к вашему бренду. В основе подачи — точные цифры, строгая типографика, таблицы и понятная хронология операций.

В MVP работают создание тестового платежа через кабинет и API, QR-ссылка на симулятор, обновление статуса, полный тестовый возврат, поиск и выгрузка CSV. Есть выпуск и отзыв API-ключей, переключение демонстрационных ролей, индивидуальные комиссии, приостановка новых платежей мерчанта и журнал действий. Операции сохраняются в базе на сервере; сессии посетителей изолированы и действуют 24 часа.

Что даёт преимущество

Проблема магазина часто начинается после оплаты: деньги подтверждены, а заказ ещё не обновился. Поэтому в одной карточке я показываю два независимых результата — статус платежа и доставку события магазину. Видны комиссия, маршрут, хронология и ответ тестового приёмника. Сбой HTTP 503 можно воспроизвести и затем проверить повтор с тем же event.id и HMAC-подписью.

Это преимущество предлагаемого сценария: оператор получает объяснение сбоя рядом с операцией. Это не заявление об отсутствии похожих возможностей в закрытых кабинетах конкурентов.

Проверено по официальным открытым материалам 25.10.2026. Закрытые кабинеты, фактические SLA и коммерческие условия не проверялись. Ценовое сравнение не заявляется.

Как проверить MVP за две минуты

1. Откройте кабинет и нажмите «Новый платёж». Выберите сценарий «Магазин недоступен».
2. Создайте операцию и откройте симулятор по QR или кнопке. Подтвердите тестовую оплату.
3. Вернитесь в карточку операции: платёж оплачен, webhook получил HTTP 503.
4. Повторите уведомление. Тестовый приёмник проверит подпись и ответит HTTP 200.
5. Выполните полный тестовый возврат и проверьте расчёт сальдо. В роли администратора измените ставку: история уже созданных платежей сохранится.

Пять смежных работ на моём сервере

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

План реализации рабочей платформы

1. Архитектура и контракт API. Согласовать модель мерчантов, денежных потоков, комиссий, возвратов и выплат. Определить нагрузку и критерии приёмки.
2. Сайт, кабинеты и доступ. Разработать дизайн под бренд, регистрацию и подключение мерчантов, полноценную авторизацию, роли и аудит.
3. Провайдеры. Единый API интернет-магазинов и отдельные адаптеры провайдеров; проверка подписей входящих событий, очередь уведомлений, повторы, сверка статусов. Реальные возвраты — если разрешены API и договором.
4. Проверка и запуск. Тестовый контур → sandbox выбранного провайдера → приёмочные сценарии, мониторинг и резервное копирование → согласованный запуск реального процессинга после договора.

Для рабочей версии предлагаю модульный сервер, PostgreSQL и отдельные фоновые обработчики для уведомлений и сверки. Масштабирование проверяем нагрузочными сценариями. В MVP сейчас — компактный сервер Python и SQLite: он предназначен для демонстрации, а не для промышленного оборота.

Что нужно для точной оценки

Бренд и юрисдикция компании; документация и sandbox выбранного провайдера; модель комиссий и график выплат; перечень ролей; ожидаемое количество мерчантов и пиковая нагрузка. После проверки API зафиксирую стоимость, этапы, сроки и критерии приёмки. Обещать реальное подключение без согласования с провайдером было бы некорректно.

ПРЕДЛОЖЕНИЕ ПОДГОТОВЛЕНО, НЕ ОТПРАВЛЕНО ЗАКАЗЧИКУ · РЕЛЕ — КОНЦЕПЦИЯ БРЕНДА