Описание функциональных характеристик программного обеспечения «РР 2.0»

1. Система/Платформа — ПО «РР 2.0».
2. Поставщик — ООО «РЕСУРС РАЗВИТИЯ».
3. Партнер — юрлицо, использующее сервис по договору; Клиент — физлицо-покупатель.
4. Платежная форма (ссылка) — веб-страница оформления заказа с уникальным URL;
Полная/Короткая форма — расширенный или минимальный набор запрашиваемых данных.
5. Платежный шлюз — модуль безопасной обработки транзакций; Вебхук — автоотправка данных
между системами при событии; Нотификации — уведомления Партнерам через вебхуки.
6. Фискализация — регистрация операции в фискальном накопителе и передача данных в ФНС;
ОФД — оператор фискальных данных; ПЭП — простая электронная подпись.
7. ПДн/СОПД — персональные данные / согласие на их обработку; СТП — служба технической поддержки;
Административная панель — веб-интерфейс управления Платформой.

1.1. Назначение программного обеспечения

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

1.2. Основные функции (модули)

Регистрация и Личный кабинет Партнера — регистрация, ввод юридических и банковских реквизитов, загрузка сканов, настройка бизнес-профиля.
Платежные формы — конфигурируемые страницы оформления заказа: продукты, цены, способы оплаты, целевые страны, промо-акции; короткая и полная формы.
Сбор согласий (ПЭП) — подписание согласия на обработку ПДн SMS-кодом, генерация PDF с цифровым штампом.
Интеграция с платежными системами — единый шлюз приема оплат и проведения транзакций.
Интеграция с онлайн-кассами — автоформирование фискальных чеков и передача в ОФД.
Интеграция с CRM — автоматическая синхронизация заявок и данных клиентов.
API и вебхуки — создание заказов, получение статусов/обновлений, нотификации.
Административная панель — управление Партнерами, интеграциями и мониторинг операций.

1.3. Принципы работы и архитектура

Архитектура построена по модульному принципу на основе сервис-ориентированной модели: ключевая бизнес-логика инкапсулирована в отдельных подприложениях, взаимодействующих через общую инфраструктуру и стандартизированные интерфейсы. Выделены слои бизнес-логики, доступа к данным (Data Access Layer) и представления (Presentation Layer), что обеспечивает масштабируемость, высокую производительность обработки транзакций и эффективное взаимодействие с внешними системами. Работа платформы основана на конвейерной обработке данных, инициируемой через Платежную форму. После настройки Партнером Продуктов, промо-акций и параметров Формы система генерирует уникальную платежную ссылку. Клиент заполняет форму, и данные через вебхук передаются в CRM Поставщика: при выборе кредита/рассрочки инициируется первичная обработка колл-центром и скоринг в банках-партнерах; при эквайринге транзакция проводится автоматически через платежный шлюз. При одобрении/успешной оплате средства распределяются по правилам (удерживается комиссия Поставщика, остаток — Партнеру), а при настроенной интеграции автоматически формируются фискальные чеки.

1.4. Технологический стек

Языки программирования: backend — C++ (стандарты C++14/C++17), набор подприложений с общей инфраструктурой; frontend — HTML/CSS, генерируемые специализированным шаблонизатором на основе декларативных описаний на C++, интерактивность на JavaScript.
СУБД: PostgreSQL.
Операционные системы: Linux; совместимо с российскими ОС на базе ядра Linux (Astra Linux, РЕД ОС, ALT Linux).
Архитектура: модульная сервис-ориентированная; слои бизнес-логики, доступа к данным и представления.

1.5. Производительность и масштабируемость

Модульная сервис-ориентированная архитектура обеспечивает масштабируемость и высокую производительность обработки транзакций. 

Конвейерная автоматизированная обработка заявок: прием → скоринг/проведение платежа → распределение средств → фискализация.

Защита от дублирования операций через идентификатор X-Correlation-ID; механизм ограничения частоты запросов (HTTP 429) с повторными попытками.

1.6. Роли участников системы 

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

Для регистрации Партнер нажимает «Регистрация» на главной странице и заполняет форму с персональными и контактными данными. После валидации на указанный номер направляется код подтверждения для активации учетной записи.

После авторизации Партнер проходит внутреннюю форму из двух этапов: (1) сведения о юрлице и налоговом статусе, банковские реквизиты, загрузка сканов документов; (2) операционная информация — сегмент продукта, формат продаж, платформа обучения, наличие онлайн-кассы, мессенджер для рабочей группы. После валидации Партнер получает доступ к настройке бизнес-профиля.

Рисунок 1.1 — Кнопка «Регистрация» на главной странице

Рисунок 1.2 — Форма регистрации в личный кабинет

Рисунок 1.3 — Поле ввода кода подтверждения

Рисунок 1.4 — Регистрация бизнеса: юридическая информация

Рисунок 1.5 — Регистрация бизнеса: банковские реквизиты

Рисунок 1.6 — Регистрация бизнеса: загрузка сканов документов

Рисунок 1.7 — Регистрация бизнеса: операционная информация

3.1. Назначение и ключевые функции

Платежная форма — ключевой элемент Платформы и точка взаимодействия Партнера и Клиента при оформлении сделки. Обеспечивает автоматизированное, безопасное и удобное оформление заявок с использованием различных финансовых инструментов (кредит, рассрочка, эквайринг и др.).
Персонализация предложения — динамическое отображение настроенных Партнером параметров (продукты, промо-акции, способы оплаты, доступные страны).
Сбор и валидация данных — структурированный сбор информации от Клиента.
Интеграция с финансовыми партнерами — точка входа данных в скоринг банков.
Юридическое сопровождение — согласия на оферты и обработку ПДн.
Управление пользовательским опытом — адаптация интерфейса (Короткая/Полная форма).

Платежная форма служит точкой интеграции с CRM (управление заявками), онлайн-кассами (фискализация), платежными шлюзами (транзакции) и системами нотификаций.

3.2. Жизненный цикл

• Этап 1. Конфигурация Партнером — продукты со стоимостью и описанием, способы оплаты и финансовые условия, целевые страны, объем данных (Короткая/Полная), сроки финансирования, чекбоксы согласий, поля комментариев.
• Этап 2. Генерация и распространение — система создает уникальную платежную ссылку (пример: https://pay.rrllc.ru/test_rr), которую Партнер передает Клиенту.
• Этап 3. Заполнение Клиентом — выбор страны и продукта, способа оплаты и условий, ввод контактных и (при необходимости) паспортных данных, принятие соглашений, кодовое слово (в Полной форме), отправка заявки.
• Этап 4. Автоматическая обработка — передача данных через вебхук в CRM, первичная верификация колл-центром, скоринг в банках; при одобрении — предварительный чек, после оплаты — закрывающий чек (при интеграции с онлайн-кассой).

3.3. Функциональное описание

На основе настроенной Формы Платформа генерирует Платежную форму, доступную по уникальному URL.

Партнер может задавать собственный логотип и конфигурировать:

• способы оплаты (кредит, рассрочка, эквайринг, международная оплата и др.);
• целевые страны (Россия, Беларусь, Казахстан, Кыргызстан, Узбекистан) и доступные для них способы оплаты;
• перечень продуктов с указанием стоимости (или без — тогда сумму вводит Клиент) и описанием;
• сроки рассрочки/кредита (в т.ч. индивидуальные по странам), поле комментария, поле id пользователя в мессенджере;
• промо-акции, в т.ч. с промокодами и эффектом снижения цены;
• чекбоксы согласий — персональные договоры-оферты и соглашения;
• объем запрашиваемых данных — Короткая или Полная форма (при эквайринге всегда Короткая).

Согласие на обработку ПДн (ПЭП). Реализовано через простую электронную подпись на основе одноразового SMS-кода: после отметки чекбокса Клиенту отправляется код, ввод которого подтверждает подписание. Система формирует итоговый PDF-документ согласия с подставленными данными Клиента, сохраняет исходную копию и создает копию с цифровым штампом «Подписано простой электронной подписью». В штампе указываются: ФИО, номер телефона, паспортные данные (для Полной формы), SMS-код, дата и время подписания, хеш-код исходного PDF. Документ доступен для скачивания Партнеру и Клиенту.

Типы форм. В Полной форме Клиент может отправить заявку после контактных данных либо продолжить ввод полного набора (паспортные данные, доверенное лицо, сведения о трудоустройстве, сканы); Партнер может сделать все поля обязательными. В Короткой форме заявка отправляется сразу после контактных данных. На завершающем этапе Полной формы Клиент задает кодовое слово для идентификации заявки и подтверждения личности; оно передается в банки-партнеры как дополнительный фактор безопасности.

Рисунок 2.1 — Платежная форма: выбор способа оплаты и контактные данные

Рисунок 2.2 — Платежная форма: этап выбора способа оплаты

Рисунок 2.3 — Платежная форма: выбор страны и продукта

Рисунок 2.4 — Платежная форма: заполнение контактных данных

Рисунок 2.5 — Платежная форма: контактные данные с промо-акцией

Рисунок 2.6 — Платежная форма: чекбоксы согласий

Рисунок 2.7 — Платежная форма: подтверждение согласия на обработку ПДн

Рисунок 2.8 — Цифровой штамп на PDF подписанного соглашения

Рисунок 2.9 — Платежная форма: паспортные данные, трудоустройство, сканы

Рисунок 2.10 — Платежная форма: кнопки управления по типам форм

Рисунок 2.11 — Платежная форма: ввод кодового слова

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

• эквайринговые сервисы — прием оплат банковскими картами онлайн;
• скоринговые системы банков-партнеров — проверка кредитных заявок и решения по кредиту/рассрочке;
• международные платежные шлюзы — прием платежей из других стран.

Конкретный набор систем определяется партнерскими соглашениями. Актуальный список и параметры подключения (комиссии, лимиты, валюты) предоставляются персональным менеджером; конфигурация и активация выполняются администратором через Административную панель.

При успешном завершении платежа система автоматически формирует фискальный документ с обязательными реквизитами: данные о Партнере, состав и стоимость продуктов, система налогообложения, реквизиты для отправки чека покупателю. Чек передается в ОФД и регистрируется в налоговых органах. Конфигурация доступна только администраторам Платформы (через раздел управления партнером в
Административной панели).

Поддерживаемые провайдеры: АТОЛ, CloudKassir, Бизнес.Ру, DigitalKassa. Каждый предоставляет собственный API, подключение к которому выполняется через единый интерфейс Административной панели.

Модуль обеспечивает автоматическую синхронизацию данных о заявках и Клиентах — бесшовный перенос новых лидов и сделок из Платежной формы в рабочий процесс Партнера для обработки менеджерами, построения воронок и аналитики. Платформа использует открытые стандарты (REST API, JSON), что позволяет интегрироваться с широким спектром CRM при наличии стабильного публичного API.

Штатная и наиболее оптимизированная интеграция — Битрикс24: автоматическое создание лидов в нужную воронку с заполнением стандартных и пользовательских полей и обновлением статусов по жизненному циклу заказа. Интеграция с другими системами (AmoCRM, RetailCRM, Microsoft Dynamics 365 и др.) возможна по индивидуальному запросу. Активация выполняется администратором Платформы.

API использует архитектуру RESTful поверх HTTP/HTTPS. Метод — POST; формат запроса и ответа — JSON; Content-Type: application/json; кодировка UTF-8. Авторизация — Basic Authentication (заголовок Authorization: Basic <base64(логин:пароль)>). Каждый запрос содержит X-Correlation-ID (UUID v4) для предотвращения дублирования операций. Подключение API для Партнера выполняет администратор через Административную панель.

HTTP-статусы: 200 — успех; 400 — ошибка запроса; 401 — ошибка аутентификации; 403 — недостаточно прав; 422 — ошибка бизнес-логики; 429 — превышен лимит запросов; 500 — внутренняя ошибка. Описание ошибки возвращается в поле error (code, text, subject.field).

Основные коды: 5006 (нет обязательного поля), 5009 (неправильный формат), 5199/5299 (нарушение числовых/строковых лимитов).

7.1. Создать заказ — createOrder

Endpoint: POST https://partner.rrllc.ru/api/v1/createOrder. Принимает JSON с данными заказа, возвращает
ссылку на платежную форму. Ключевые поля запроса:

Ответ: status (статус заказа) и link (URL платежной страницы).

7.2. Получить статус заказа — getOrderStatus

Endpoint: POST https://partner.rrllc.ru/api/v1/{orderId}/getOrderStatus. Возвращает текущий статус, размер комиссии (commission) и сумму кредитного договора (creditAmount). Для несуществующего заказа возвращается 404.

7.3. Получить обновления заказов — getOrderUpdates

Endpoint: POST https://partner.rrllc.ru/api/v1/getOrderUpdates. Возвращает список последних изменений статусов (до 20), после чего записи удаляются с сервера. При частых вызовах возможен 429 (в заголовке — время до повтора); при ошибке 500 очередь сохраняется.

7.4. Обработка нотификаций

Нотификации — автоматические HTTP-запросы Платформы на указанный Партнером URL при изменении статуса заказа (рекомендуемый способ получения данных в реальном времени; дополнительно следует запросить getOrderStatus). Структура: type, newStatus, salt (случайная строка), sign (подпись). Подпись: sign = MD5(newStatus + "_" + secretKey + "_" + salt), где secretKey — индивидуальный секретный ключ Партнера. Если вычисленная подпись не совпадает с sign — нотификациюобрабатывать не следует.