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

Сделка как последовательность состояний
У аренды несколько связанных этапов: объявление → бронирование → подтверждение условий → оплата → передача вещи → завершение. Каждый этап влияет на то, какие действия доступны участникам и что должно произойти дальше.
| Этап | Что нужно согласовать в веб-части |
|---|---|
| Поиск и бронирование | Объявление, срок аренды и расчёт стоимости |
| Условия аренды | Подтверждение участника и согласие перед оплатой |
| Оплата | Состояние платежа и доступность повторных действий |
| Передача и завершение | Подтверждения участников, списание и возврат залога |
Поэтому исправления проверял в общем сценарии. Например, после оплаты интерфейс должен показывать актуальное состояние бронирования; повторный заход на страницу должен восстанавливать уже выполненные шаги.
За время работы этот путь менялся. В раннем варианте использовалась загрузка подписанных договоров; в июньской версии обязательный шаг убрали, а перед оплатой оставили согласие с пользовательским соглашением и политикой конфиденциальности. Старые состояния подписания ещё присутствуют в коде для прежних заявок.
Какие разделы связывал продукт
| Раздел | Сценарий участника |
|---|---|
| Каталог и поиск | Категория, город, цена за день, сортировка и карточка вещи |
| Объявление | Мастер: название, описание, категория, цена, фотографии и адрес |
| Избранное | Сохранить вещь и вернуться к ней позднее |
| Бронирование | Выбрать даты, проверить доступность и получить расчёт стоимости |
| Условия и верификация | Подтвердить участника и принять условия аренды |
| Оплата | Холд, залог, подтверждение списания, отмена и возврат |
| Передача вещи | Подтверждения сторон, фотографии состояния и начало аренды |
| Чат | Диалог, связанный с объявлением или конкретным бронированием |
| Профиль | Объявления, заявки, уведомления, история и рефералы |
| Завершение | Возврат вещи и залога, расчёт с владельцем, отзыв и архив |
| Управление | Модерация объявлений, верификация, пользователи и платёжные обращения |

Веб-часть и качество кода
Мастер объявления: от описания до понятной цены
Создание объявления разбито на шесть шагов: название, описание, категория и состояние, цена, фотографии, адрес. Переход дальше зависит от заполнения текущего шага: пустое название или описание не пропускает пользователя; цена должна быть положительной, а перед переходом от фотографий нужна хотя бы одна. Форма принимает до десяти снимков и показывает, какое изображение будет главным.
На шаге цены владелец вводит стоимость за день и сразу видит комиссию и сумму, которую получит. Процент загружается для типа аккаунта, поэтому расчёт связан с данными пользователя. В примере с ценой 600 ₽ и комиссией 10% форма показывает 60 ₽ комиссии и 540 ₽ владельцу.

Заявка: срок, расчёт и следующий шаг
После выбора вещи сделка получает собственную страницу. На ней участник видит контрагента, период, число дней, дневную цену, стоимость аренды, залог и итог. Представление зависит от роли: владелец может принять или отклонить новую заявку, арендатор видит ожидание решения. После одобрения арендатор получает форму согласия и доступ к оплате.
Даты считаются включительно: пример с 20 по 22 октября — три дня. При 600 ₽ за день аренда составляет 1800 ₽. Состояние оплаты хранится отдельно от состояния заявки: одобрение владельцем само по себе не означает, что деньги уже внесены.

Дорабатывал каталог, главную страницу, заявки и бронирование. Исправлял загрузку объявлений, отображение состояний, расчёт стоимости и повторные действия в формах. Отдельной частью были оформление и согласование интерфейса с макетами.

В коде убирал отладочные сообщения и устаревшие участки, приводил к общему порядку работу с авторизацией. Это помогало уменьшить число мест, где один и тот же пользовательский шаг мог обрабатываться по-разному.
Веб-приложение использует Next.js и React, API — NestJS, данные — PostgreSQL через Prisma, файлы — объектное хранилище S3. В существующем продукте изменения нужно было согласовывать между интерфейсом, API и моделью данных.
В бронировании важны выбранный срок, доступные даты и состояние заявки. Чат связывает обсуждение с вещью и сделкой, а экран аренды объединяет условия, оплату и передачу. Для завершения предусмотрены фотографии состояния, подтверждения участников и отзыв. Мои проверки проходили через эти переходы, где ошибка состояния могла заблокировать следующий шаг.
Платежи и завершение аренды
Работал над интеграцией эквайринга и двухстадийной оплатой: сначала средства блокируются, затем платёж подтверждается в предусмотренный момент сделки. Дорабатывал расчёт стоимости, залог и отображение статуса оплаты.
Для этого важно было различать состояние аренды и состояние платежа. Подтверждение одного шага не должно случайно повторять другой. Отдельно разбирал с поддержкой банка условия расчётов и выплаты владельцу после завершения аренды.
Расчёты с владельцем и условия выплат требовали отдельного согласования с банком. Поэтому интеграцию проверял по отдельным операциям и состояниям сделки.
Безопасность и данные
Проверял разграничение доступа, обработку персональных данных, сессии и защиту пользовательского ввода. Дорабатывал шифрование чувствительных полей, сокращал попадание данных в журналы и разделял среды хранения файлов.
В рамках аудита закрыли 43 находки: 24 по проверке кода, 10 в первом раунде red team и 9 во втором.
Как проверял изменения
Тестировал полный путь пользователя: создание объявления, бронирование, подтверждение условий, оплату и начало аренды. В раннем сценарии проверял и шаг договора. Проверял также отказ операций, которые пользователь не должен выполнять.
В репозитории сохранились отдельные E2E-тесты для авторизации, объявлений, бронирования, верификации и административного доступа. Такой набор помогает проверять связи между частями продукта после очередного изменения.
Результат
Мой вклад объединил fullstack-разработку, платёжную интеграцию и AppSec. Доработки интерфейса сопровождались изменениями в обработке состояний, защите данных и проверке пользовательского пути.
Главный опыт этого проекта — сопровождать существующий продукт целиком: понимать, как изменение на одном экране влияет на API, договор, платёж и дальнейшие действия участников.
