Знакомая сцена из любого торгового чата в Telegram: покупатель нашёл нужный товар, продавец просит предоплату, и переписка замирает. Один боится отправить деньги и остаться ни с чем, второй — отдать товар и не получить оплату. Сделка есть, доверия нет. Мы в DEVCORE решали эту задачу в проекте SafeEscrow — Telegram-боте, который выступает гарантом P2P-сделок: принимает деньги на хранение, следит за выполнением условий и отдаёт оплату продавцу только после подтверждения покупателя. Разбираем, как бот устроен изнутри: сценарий сделки, роли участников, подводные камни разработки и то, каким бизнесам эта модель пригодится в готовом виде.
Почему P2P-сделки срываются: треугольник недоверия
В Telegram продают всё: цифровые товары, аккаунты, услуги, технику, рекламу в каналах. Но у площадки нет встроенного механизма защиты сделок — это мессенджер, а не маркетплейс с эскроу. Стороны обычно решают вопрос тремя способами, и все три плохие.
- Предоплата. Покупатель рискует всем: перевёл — и надейся на честность продавца. Именно на этом строится большинство скам-схем.
- Оплата после получения. Теперь рискует продавец, особенно с цифровыми товарами: переданный файл или доступ уже не вернёшь.
- Гарант-человек. Админ чата или «проверенный» посредник. Медленно, зависит от часового пояса и занятости, а главное — гарант тоже человек, и доверие к нему держится на репутации, которую сложно проверить.
Эскроу-бот закрывает все три сценария одной механикой: деньги вносятся до передачи товара, но продавец их не получит, пока покупатель не подтвердит, что всё в порядке. Ни одна из сторон не может обмануть другую в одностороннем порядке — у обмана просто нет технической возможности.
Гарант убирает из сделки не сам риск, а необходимость доверять незнакомцу. Это разные вещи — и именно поэтому модель работает.
Сценарий сделки: семь шагов от «договорились» до «деньги у продавца»
Основной поток в SafeEscrow выглядит так.
- Создание сделки. Инициатор — любая из сторон — открывает бота и указывает предмет сделки, сумму и условия: что передаётся, в какой срок, как проверяется результат.
- Приглашение второй стороны. Бот генерирует уникальную ссылку. Инициатор отправляет её контрагенту — тому не нужно ничего искать и настраивать, достаточно нажать Start.
- Подтверждение условий. Вторая сторона видит карточку сделки: сумма, описание, роли. Пока обе стороны не согласились с одними и теми же условиями, сделка не двигается дальше. Это принципиально: спорить о том, «как договаривались», потом бессмысленно — условия зафиксированы в системе.
- Внесение оплаты. Покупатель переводит сумму, и она блокируется на стороне сервиса. Продавец видит статус «оплачено, средства заморожены» — это его сигнал, что товар можно передавать без риска.
- Передача товара или услуги. Происходит вне бота — в личных сообщениях, файлом, доступом к аккаунту, как угодно. Бот фиксирует момент, когда продавец отметил передачу.
- Подтверждение покупателя. Покупатель проверяет полученное и подтверждает. С этого момента деньги принадлежат продавцу.
- Выплата. Бот переводит сумму продавцу за вычетом комиссии сервиса. Сделка закрыта, у обеих сторон остаётся её полная история.
Ветка «что-то пошло не так»
Счастливый путь — меньшая часть проектной работы. Больше времени ушло на ветвления.
- Покупатель получил товар и молчит. Нельзя вечно держать деньги замороженными. На каждый статус сделки — свой таймаут и свои автоматические действия: напоминание, эскалация, закрытие по регламенту.
- Покупатель открывает спор. Сделка переходит в арбитраж: обе стороны прикладывают доказательства — переписку, скриншоты, файлы, — а решение принимает арбитр.
- Продавец пропал после оплаты. Деньги заморожены, товара нет: по таймауту сделка отменяется, средства возвращаются покупателю.
- Стороны передумали. Обоюдная отмена с возвратом — тоже отдельный сценарий, с явным подтверждением от каждой стороны.
Роли: кто что может и чего не может
Правильная ролевая модель — половина безопасности эскроу-сервиса. В SafeEscrow их четыре.
Покупатель
Вносит оплату, подтверждает получение, может открыть спор. Не может: отменить сделку в одностороннем порядке после передачи товара, изменить условия после согласования.
Продавец
Подтверждает условия, отмечает передачу товара, получает выплату. Не может: получить деньги до подтверждения покупателя или решения арбитра, поменять сумму задним числом.
Арбитр
Подключается только при споре. Видит материалы обеих сторон и историю сделки, выносит решение: выплата продавцу, возврат покупателю или частичное распределение. Ключевой принцип — арбитр не участвует в обычных сделках и не имеет к ним доступа, пока спора нет.
Администратор
Управляет сервисом: комиссии, лимиты, блокировки недобросовестных пользователей, статистика. Админка — обязательная часть такого проекта, без неё денежный сервис не проживёт и недели, поэтому в ботах для бизнеса мы закладываем её с первого дня.
Что оказалось сложным
Честный список без прикрас — что съело больше всего времени.
Машина состояний вместо «бота с кнопками»
Снаружи SafeEscrow выглядит как диалог с кнопками. Внутри — конечный автомат: у сделки есть строго определённые статусы и разрешённые переходы между ними. Каждое действие проверяется: можно ли из текущего статуса выполнить эту операцию и та ли роль её выполняет. Первая версия логики «на ифах» начала разваливаться, как только добавились споры и таймауты, — мы переписали её на явную машину состояний, и количество краевых багов резко упало. Урок: в любых денежных сценариях статус сделки должен быть единственным источником правды, а не вычисляться из контекста переписки.
Идемпотентность и гонки
Telegram может доставить нажатие кнопки дважды, пользователь может нажать её в старом сообщении, а обе стороны — действовать одновременно. Для обычного бота это мелочи, для денежного — катастрофа: двойная выплата или двойной возврат. Поэтому каждая операция с балансом идемпотентна: повторный вызов с тем же ключом не делает ничего. Это скучная, невидимая пользователю работа, и именно она отличает бота-гаранта от бота-визитки.
Споры: сценарий, в котором нет довольных
Арбитраж — самый деликатный участок. Нужно собрать доказательства обеих сторон, не превратив бота в бесконечный чат жалоб; дать арбитру полную картину; зафиксировать решение так, чтобы его нельзя было «переиграть». Мы намеренно сделали процесс формальным: ограниченные окна для подачи материалов, фиксированный набор исходов. Чем меньше свободы в конфликтном сценарии — тем меньше пространства для манипуляций с обеих сторон.
Доверие к самому боту
Парадокс эскроу: сервис, который решает проблему доверия, сам должен его заслужить. Клоны с похожими названиями и фишинговые «зеркала» — обычная практика в Telegram. Часть защиты техническая: юзернейм бота в каждой карточке сделки, проверяемые ссылки-приглашения. Часть — продуктовая: прозрачные правила, понятная комиссия, публичные условия арбитража. Без второй половины первая не работает.
Кому пригодится модель эскроу: шесть готовых применений
Механика «заморозили — проверили — выплатили» переносится далеко за пределы P2P-барахолок.
- Фриланс и услуги. Заказчик вносит оплату до начала работ, исполнитель получает её после приёмки. Чаты дизайнеров, разработчиков и копирайтеров — готовая аудитория.
- Продажа цифровых товаров. Аккаунты, ключи, шаблоны, доступы — товары, которые нельзя «вернуть», поэтому защита нужна обеим сторонам сразу.
- Реклама в Telegram-каналах. Рекламодатель платит в эскроу, админ канала получает деньги после выхода поста и проверки размещения.
- Поэтапные проекты. Ремонт, стройка, разработка: каждый этап — отдельная мини-сделка со своей приёмкой. Это снимает главный страх заказчика «заплачу за всё вперёд, а подрядчик пропадёт».
- Аренда с залогом. Техника, инструмент, оборудование: залог замораживается на время аренды и автоматически возвращается при закрытии сделки.
- Нишевые маркетплейсы сообществ. Закрытые клубы и профессиональные чаты, где сделки уже идут: бот добавляет безопасность, а владельцу сообщества — комиссию с оборота.
Если сделок много и нужен полноценный каталог с фильтрами и историей, логику гаранта можно упаковать не в чистого бота, а в Telegram Mini App: интерфейс богаче, механика та же.
Сколько стоит такой бот и из чего складывается цена
Разработка Telegram-бота уровня SafeEscrow в DEVCORE начинается от 60 000 ₽, срок — 3–5 недель. На итоговую смету влияют:
- количество сценариев и ветвлений — спор, отмена, таймауты, возвраты требуют отдельной логики и отдельного тестирования;
- приём платежей — от 10 000 ₽;
- админ-панель со статистикой и управлением пользователями — от 12 000 ₽;
- личный кабинет с историей сделок — от 20 000 ₽.
Код полностью передаётся заказчику: сервис остаётся вашим активом, а не подпиской на чужую платформу. Детали реализации SafeEscrow — в карточке кейса, остальные наши работы — в портфолио.
Вывод: чек-лист для тех, кто задумал своего бота-гаранта
Модель эскроу в Telegram работает, если сделать её честно и дотошно. Проверьте себя перед стартом.
- Сценарий сделки расписан по статусам, включая все «плохие» ветки: спор, молчание сторон, отмену, возврат.
- Роли жёстко разделены: никто не может выполнить чужое действие, арбитр не видит сделки без спора.
- Все операции с деньгами идемпотентны — двойное нажатие кнопки не создаёт двойную выплату.
- Для каждого статуса определён таймаут: деньги не зависают навсегда.
- Правила арбитража сформулированы до запуска, а не придумываются на первом споре.
- Есть админка: комиссии, лимиты, блокировки, статистика.
- Продумана защита от клонов и фишинга — от юзернейма в карточках до публичных правил сервиса.
Если по половине пунктов пока вопросы — это нормально: именно за этим приходят к подрядчику. Напишите нам в Telegram (@dev_core_web) или посмотрите, как мы делаем ботов для бизнеса: покажем SafeEscrow в деле и посчитаем смету под вашу задачу.