Эскроу на бирже фриланса

Эскроу на бирже фриланса — механизм, при котором оплата заказа блокируется (холд) до принятия результата. Заказчик видит, что деньги «уже внесены», исполнитель видит, что работа не «на честном слове», площадка держит рычаг на случай спора. Без эскроу биржа быстро превращается в доску контактов: договорились и ушли в перевод на карту.

В скрипте биржи Microscript эскроу — логический слой статусов поверх платёжного провайдера. Конкретный шлюз (карта, СБП, баланс кабинета) настраивается под ваш юрконтур. Важно не название кнопки, а цепочка: холд → работа → выплата или возврат/арбитраж.

Зачем холд, если «можно по предоплате напрямую»

Прямая предоплата защищает исполнителя и бьёт по заказчику. Постоплата — наоборот. Холд балансирует обе стороны. Площадка при этом зарабатывает доверие и комиссию, а не только трафик на ленту. Для нишевых бирж это часто единственный способ удержать сделки внутри домена.

Маркетингово не стоит обещать «банковский эскроу», если у вас обычный холд на балансе мерчанта. Пишите честно: безопасная сделка, средства резервируются до принятия работы. Юридические формулировки — в оферте, не в слогане.

Этапы сделки с эскроу

1. Заказ опубликован, выбран исполнитель (или наоборот — сначала холд, потом выбор: зависит от вашей политики).
2. Заказчик вносит сумму на холд. Статус заказа: «оплачен / средства заморожены».
3. Исполнитель работает, сдаёт результат в карточке заказа.
4. Заказчик принимает — холд уходит в выплату исполнителю минус комиссия площадки.
5. Либо заказчик открывает спор — деньги остаются замороженными до решения арбитра.

Перестановка шагов 1–2 допустима, но должна быть одна и понятная. Хуже всего, когда в половине заказов холд до выбора, в половине после — поддержка захлебнётся.

Спор и арбитраж

Спор — не чат «поругались». Это статус с дедлайном ответа, вложениями обеих сторон и решением админа: выплатить, вернуть, разделить. Критерии решения заранее в правилах: что считается сдачей, сколько итераций правок, что если заказчик молчит.

Админке нужна очередь споров, фильтр по дате и сумма холда. Без суммы арбитраж превращается в чтение переписки наугад. Логи смены статусов сохраняйте: потом придёт запрос «почему списали».

Комиссия и частичные выплаты

Комиссию удобно брать в момент выплаты исполнителю. Тогда в холде лежит полная сумма заказа, а на вывод уходит net. Если берёте комиссию с заказчика сверху — покажите это в форме оплаты явно, до клика.

Вехи (milestones) — когда заказ режут на этапы с отдельным холдом. На старте можно обойтись одним холдом на весь заказ; вехи усложняют UI и отчёты. Имеет смысл, если средний чек высокий и цикл длинный.

Связка с остальным контуром биржи

Эскроу бессмысленен без нормальных заказов и откликов: иначе не к чему привязать холд. Рейтинг после успешной выплаты усиливает эффект — рейтинг фрилансеров. Обзор площадки: скрипт биржи, позиционирование: аналог FL.ru.

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

Проверки перед боевыми деньгами

• Тестовый холд малой суммой: статус у обеих ролей совпадает.
• Принятие работы инициирует выплату (или задачу на выплату) без ручного SQL.
• Спор блокирует кнопку «принять» у заказчика и «вывести» у исполнителя.
• Возврат заказчику отражается в истории платежа.
• Письма о холде, сдаче, споре уходят с вашего домена.
• Комиссия в отчёте админа сходится с суммой выплат за день.

Отдельно проверьте отмену заказа до старта работы: холд должен возвращаться по правилам, а не «висеть до конца месяца». И таймаут молчания заказчика после сдачи — авто-приём или эскалация, как решите.

Риски и антифрод

Новые аккаунты с крупным холдом — красный флаг. Лимиты на сумму первой сделки, верификация, ручной просмотр — обычная гигиена. Исполнители, которые уговаривают «давайте вне сайта, вам же без комиссии» — удар по модели. Технически не всё отловите, но в правилах запрет и санкции должны быть.

Не храните лишние платёжные данные в своих таблицах «на всякий случай». Токены провайдера и статусы транзакций — да; полные карточные данные — нет.

Баланс кабинета и вывод средств

Частая схема: холд → после принятия сумма падает на баланс исполнителя → вывод на карту или кошелёк по заявке. Между зачислением на баланс и выводом можно держать клиринг-паузу (сутки–трое) против чарджбеков. Это нужно прописать в правилах до первой выплаты, не после первого скандала.

Заказчику тоже полезен баланс: пополнил один раз — холдит несколько мелких заказов. Но не усложняйте бухгалтерию раньше времени: один платёжный путь лучше трёх «на выбор», пока оборот маленький.

Отчётность и расхождения

Раз в день сверяйте сумму холдов, сумму выплат и комиссию площадки. Расхождение на копейки из-за округления лучше поймать сразу. Админский экран «транзакции заказа» с ID платежа провайдера экономит часы переписки с поддержкой шлюза.

При частичном возврате после спора статусы заказа и платёжные статусы должны остаться читаемыми: «закрыт спором, возврат 40%». Иначе через квартал вы не восстановите картину по тикету налоговой или по претензии пользователя.

Тестовый контур провайдера и боевой не смешивайте ключами. Вынесенные в конфиг ключи, разные webhook URL, проверка подписи уведомлений — обязательный минимум до рекламы «безопасной сделки».

Коммуникация статусов пользователю

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

Кнопку «открыть спор» не прячьте, но и не делайте её первым экраном. Рядом — срок на доработку и ссылка на правила. Чем спокойнее UX спора, тем меньше эскалаций «напишу в банк».