P2P-обмен

Один из сложных модулей crypto-проекта — P2P-обмен. Здесь пользователи взаимодействуют не просто с формой заявки, а с деньгами, балансами, встречными обязательствами, подтверждениями, статусами и возможными спорными ситуациями.

Я реализовал P2P-логику как управляемый процесс, где каждая операция проходит через понятные состояния, фиксируется в базе и может быть проверена администратором.

Как устроена логика P2P-обмена

В основе P2P-обмена лежит не одна транзакция, а цепочка действий:

1. Пользователь создаёт заявку на покупку или продажу.
2. Система фиксирует сумму, валюту, курс, реквизиты и условия сделки.
3. Второй пользователь принимает заявку.
4. Средства резервируются или блокируются внутри системы.
5. Стороны выполняют свои действия по сделке.
6. Система ждёт подтверждения.
7. После подтверждения средства переводятся получателю.
8. Сделка закрывается или уходит в спорный статус.

Главная задача backend — не дать операции “потеряться” между этими этапами. Поэтому каждая сделка должна иметь статус, историю изменений, участников, суммы, комиссии, timestamps и логи критичных действий.

Статусы сделки

Для P2P-обмена я использовал статусную модель. Сделка не просто “создана” или “завершена”, а проходит через несколько этапов.

Например:

• создана;
• ожидает встречного участника;
• принята;
• средства зарезервированы;
• ожидается оплата;
• оплата отмечена пользователем;
• ожидается подтверждение второй стороны;
• завершена;
• отменена;
• истекло время;
• открыт спор;
• закрыта администратором.

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

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

Резервирование средств

Один из ключевых моментов P2P-обмена — резервирование средств.

Если пользователь создаёт заявку на продажу или принимает сделку, система должна убедиться, что у него достаточно доступного баланса. После этого нужная сумма не просто списывается, а переводится в зарезервированное состояние.

Это защищает сделку от ситуации, когда пользователь создал заявку, а потом вывел или потратил средства до завершения обмена.

Внутри системы баланс можно разделять на несколько частей:

• доступный баланс;
• зарезервированный баланс;
• списанный баланс;
• начисленный баланс;
• баланс в ожидании подтверждения.

Такой подход делает финансовую логику прозрачнее. Администратор и система всегда понимают, какие средства доступны пользователю, какие участвуют в активной сделке, а какие уже ушли в завершённую операцию.

Внутренние операции и журнал баланса

Для P2P-обмена недостаточно просто менять число в поле balance. Каждое изменение баланса должно быть отдельной операцией.

Например:

• резервирование средств;
• отмена резерва;
• списание после завершения сделки;
• начисление второй стороне;
• возврат при отмене;
• удержание комиссии;
• ручная корректировка администратором.

Каждая такая операция должна фиксироваться в журнале:

• кто инициировал действие;
• по какой сделке;
• какая сумма изменилась;
• какая валюта;
• старый и новый статус;
• дата и время;
• технический идентификатор операции;
• комментарий или причина;
• результат выполнения.

Это позволяет восстановить картину, если пользователь задаёт вопрос, сделка ушла в спор или возникла ошибка на стороне внешней сети.

Комиссия сервиса

P2P-сделка часто включает комиссию сервиса. Её нельзя считать “где-то на фронте” или добавлять вручную. Комиссия должна рассчитываться на backend по понятным правилам.

Комиссия может быть:

• фиксированной;
• процентной;
• зависеть от направления обмена;
• зависеть от валюты;
• зависеть от роли пользователя;
• удерживаться с продавца, покупателя или обеих сторон.

В момент создания или принятия сделки система фиксирует условия: сумму, курс, комиссию и итоговые значения. Это важно, потому что условия сделки не должны неожиданно измениться в процессе выполнения.

Подтверждения сторон

В P2P-обмене важна логика подтверждений.

Например, один пользователь отмечает, что оплатил, а второй подтверждает получение. Только после этого система переводит зарезервированные средства.

Это защищает обе стороны:

• покупатель видит, что сделка находится в работе;
• продавец понимает, что средства зарезервированы;
• система не завершает сделку без нужного подтверждения;
• администратор видит, кто и когда нажал нужное действие.

Если подтверждение не происходит вовремя, сделка может перейти в статус ожидания, отмены или спора.

Спорные ситуации

В P2P-сервисе обязательно нужно предусмотреть спорные статусы.

Например:

• пользователь отметил оплату, но вторая сторона её не подтверждает;
• истекло время сделки;
• одна из сторон пытается отменить операцию;
• поступила жалоба;
• данные оплаты не совпадают;
• нужно ручное решение администратора.

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

После проверки администратор может принять решение: завершить сделку, отменить её, вернуть средства, удержать комиссию или выполнить другую предусмотренную операцию.

Защита от повторных действий

Одна из частых проблем в финансовых сценариях — повторное выполнение одного и того же действия.

Например, пользователь дважды нажал кнопку подтверждения, запрос повторился из-за плохого интернета или frontend отправил действие повторно.

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

• проверять текущий статус сделки;
• не выполнять финальное списание дважды;
• использовать уникальные идентификаторы операций;
• блокировать параллельную обработку одной сделки;
• фиксировать результат выполнения;
• возвращать понятный ответ, если действие уже было выполнено.

Для P2P это критично: повторное списание или повторное начисление баланса недопустимы.

Роль очередей и фоновых задач

Часть действий в P2P-сервисе лучше выполнять в фоне.

Например:

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

Очереди и планировщик позволяют не завязывать всю финансовую логику на действия пользователя в интерфейсе. Система сама следит за просроченными сделками и техническими состояниями.

Уведомления

P2P-обмен требует быстрых уведомлений.

Пользователям важно знать:

• заявка создана;
• сделка принята;
• средства зарезервированы;
• оплата отмечена;
• требуется подтверждение;
• сделка завершена;
• сделка отменена;
• открыт спор;
• администратор принял решение.

Уведомления можно отправлять в Telegram, email или показывать внутри личного кабинета. Для crypto/TON/GRAM-проектов Telegram часто особенно удобен, потому что пользователь быстрее реагирует на событие.

Админ-панель для контроля

Для P2P-обмена нужна отдельная административная часть.

В ней должны быть видны:

• список сделок;
• участники;
• направление обмена;
• суммы и комиссии;
• текущий статус;
• время создания и обновления;
• история действий;
• журнал балансовых операций;
• ошибки обработки;
• спорные сделки;
• ручные действия администратора.

Администратор должен иметь возможность не “лезть в базу”, а управлять спорными и нестандартными ситуациями через понятный интерфейс.

Итоговая схема реализации

В результате P2P-обмен реализуется не как простая форма “купить/продать”, а как полноценный backend-модуль:

1. Заявки создаются и фиксируются в базе.
2. Сделки проходят через строгую статусную модель.
3. Средства резервируются до завершения операции.
4. Все изменения баланса пишутся в журнал операций.
5. Комиссии рассчитываются и фиксируются на backend.
6. Действия пользователей проверяются по ролям и статусам.
7. Повторные запросы не приводят к повторному списанию.
8. Спорные ситуации уходят в отдельный статус.
9. Администратор видит всю историю и может принять решение.
10. Уведомления и фоновые задачи помогают контролировать процесс.

Такой подход позволяет сделать P2P-обмен управляемым и проверяемым. В финансовых и crypto-проектах это важнее, чем просто быстро собрать интерфейс: деньги, балансы и транзакции должны проходить через понятную логику, а каждое действие должно оставлять след в системе.