Принять платёж мало: как наладить массовые выплаты в криптовалюте
Принять депозит легко. Клиент открывает страницу оплаты, платит со своего кошелька, ваша система получает вебхук. Сложности начинаются, когда деньги надо отправить обратно, и сразу многим. Массовые выплаты быстро превращаются в ручной аврал: сотни игроков, трейдеров или вебмастеров ждут денег одновременно, адреса лежат в таблице, финансист до ночи копирует и вставляет, а в саппорт и в Telegram сыплется одно и то же: «где мой вывод?»
Статья для тех, кто уже принимает криптовалюту или собирается, и теперь должен платить в ответ, причём много и регулярно. Разберём, почему выплаты ломаются раньше платежей, во что обходится ручной процесс, как устроены массовые выплаты через тот же API, что и приём оплаты, и какие настройки нужны, чтобы пачка из тысячи переводов не обернулась тысячей тикетов.
Почему выплаты ломаются раньше платежей
Платёж и выплата выглядят как зеркальные операции, но риски у них разные.
Когда клиент платит вам, транзакцию запускает он: сам выбирает монету, сам подписывает перевод своим кошельком. Ошибся, значит, проблема в основном его. Когда платите вы, каждый перевод становится вашим решением и вашей ответственностью. Неверный адрес, не та сеть или повторная отправка стоят вам денег, а подтверждённый перевод в блокчейне назад не развернуть.
Ещё выплаты бьют по репутации сильнее платежей. Медленную страницу депозита игрок простит. Вывод, который три дня висит в статусе «в обработке», нет. Регуляторы за этим тоже следят. Британская Gambling Commission с 31 октября 2021 года полностью запретила отмену заявок на вывод во всех видах онлайн-гемблинга (обзор Bird & Bird): игрока больше нельзя подтолкнуть к тому, чтобы он отозвал вывод и проиграл эти деньги.
С партнёрами то же самое. В iGaming-партнёрках чаще всего платят раз в месяц на условиях NET15, а программы, которые сверяют начисления вручную, в загруженные месяцы «стабильно тратят неделю и платят с опозданием», пишет Track360 в обзоре условий выплат за 2026 год. Там же стоимость банковского перевода или SWIFT оценена в $15–40 за платёж. Если у вас несколько сотен вебмастеров, это заметная строка в бюджете, причём ещё до того, как кто-то проверил суммы.
Как выглядит ручная выплата
Ручной процесс обычно никто не проектирует, он вырастает сам. Десять выводов в день легко отправить из приложения кошелька. На двухстах в день та же рутина съедает половину рабочего дня, а на двух тысячах под неё нужен отдельный отдел.
Обычный ручной цикл выглядит так:
- Кто-то выгружает одобренные заявки на вывод из бэк-офиса в таблицу.
- Финансы проверяют, хватает ли на кошельке нужной монеты в нужной сети.
- Каждый адрес копируется в кошелёк, сумма вбивается руками, перевод подписывается.
- Хеш транзакции вставляется обратно в таблицу или CRM.
- Саппорт отвечает тем, у кого выплата потерялась, ушла не в ту сеть или так и не отправилась.
На каждом шаге есть свой способ ошибиться.
| Шаг | Что ломается | Чем это оборачивается |
|---|---|---|
| Выгрузка и одобрение | Устаревшие данные, дубли, заявка одобрена дважды | Двойная выплата, вернуть которую часто нельзя |
| Проверка баланса | Не хватает USDT в нужной сети | Цикл встаёт на середине, остальные ждут до завтра |
| Копирование адресов | Ошибка в адресе, адрес-двойник, не та сеть | Потерянные деньги, обращение в поддержку, иногда спор |
| Запись хешей | Записи пропущены или не совпадают | Часы сверки в конце месяца |
| Поддержка | Клиент спрашивает статус, а живых данных нет | Тикеты, гневные сообщения, ушедшие клиенты |
С копированием адресов отдельная история. В декабре 2025 года трейдер потерял почти $50 млн в USDT из-за атаки address poisoning, то есть «отравления адреса». Злоумышленник подбросил в историю транзакций жертвы адрес, у которого первые и последние символы совпадали с настоящим, и жертва скопировала его оттуда для основного перевода (The Block). Бухгалтер, который в пятницу вечером вставляет триста адресов подряд, ровно та цель, под которую такую атаку строят.
Время на ручную работу легко недооценить. Хорошее сравнение даёт классическая бухгалтерия расчётов с поставщиками. По данным Ardent Partners за 2025 год, обработка одного счёта в среднем стоит $9,40, а у лучших компаний $2,78; доля счетов с исключениями 22% против 9% (по данным WEX). Разница между этими группами в основном в автоматизации. С криптовыплатами логика та же: деньги уходят на ручную обработку и исключения, а сам перевод стоит копейки по сравнению с ними.
Кому нужны массовые выплаты
Рано или поздно сюда приходит любой бизнес, который регулярно платит многим людям. Самые частые случаи:
- онлайн-казино и букмекеры, которые выплачивают выигрыши круглосуточно, с пиками по выходным;
- форекс-брокеры и проп-трейдинговые компании: выводы клиентов и доля прибыли трейдеров;
- партнёрские программы, которые раз в месяц или раз в неделю платят вебмастерам и арбитражникам;
- маркетплейсы и платформы для авторов, которые рассчитываются с продавцами и фрилансерами в разных странах;
- компании с подрядчиками и удалёнными сотрудниками, где зарплата в криптовалюте заменяет медленные международные переводы.
Общее у них одно: много получателей, многие за границей, и все ждут денег быстро. Банковский перевод в сорок стран медленный и дорогой. Перевод в стейблкоине стоит одинаково и идёт примерно одинаково, получатель хоть в Алматы, хоть в Лиссабоне.
Есть и ещё одна разница, которую хорошо знают все, кто платит игрокам. Банки обычно не проводят международные переводы по выходным и праздникам, а игроки выигрывают и просят вывод в любой день недели. Блокчейн работает без выходных, поэтому массовые выплаты в криптовалюте можно отправлять в субботу ночью так же, как во вторник днём. Вопрос только в том, кто их отправляет: человек с таблицей или ваша система через API.
Платежи и выплаты в одном API
Когда массовые выплаты только начинаются, многие работают с одним провайдером для входящих платежей, а исходящие деньги ведут отдельно: через аккаунт на бирже, горячий кошелёк, иногда второй процессинг. Пока объёмы маленькие, это работает. Потом деньги приходится гонять между системами перед каждой выплатой, а сверка превращается в сведение записей из двух-трёх источников.
Когда оба направления идут через один API, большая часть этой возни исчезает. В Speend выплаты идут с того же баланса мерчанта, на который приходят платежи клиентов. Один набор ключей API, один формат вебхуков, один личный кабинет и одна AML-политика на входящие и исходящие деньги. Депозиты не нужно выводить на биржу и заводить обратно на кошелёк для выплат, так что лишнего перевода, за который надо платить и которого надо ждать, нет.
Для разработчика вызов короткий. Отправляете POST https://api.speend.io/payout/create с пятью обязательными полями:
order_id: ваш уникальный ID выплаты;currency: например, USDT;network: например, TRON или SOL;amount: не меньше эквивалента 7 USD;address: адрес получателя в этой сети.
{
"order_id": 100245,
"currency": "USDT",
"network": "TRON",
"amount": 250,
"address": "TXk...recipient"
}В ответ приходят uuid выплаты, её текущий status и флаг is_final. Полное описание есть в документации Payouts API.
Как выплата проходит через Speend
У каждой выплаты фиксированный набор статусов. Если их знать, игрок или партнёр видит у вас честный ответ, а не вечное «обрабатывается».
| Статус | Что означает | Финальный |
|---|---|---|
| REQUESTED | Заявка принята | Нет |
| AWAITING_CONFIRMATION | Сумма выше вашего лимита, выплата ждёт ручного подтверждения в личном кабинете | Нет |
| ON_QUEUE | Одобрена и стоит в очереди на отправку | Нет |
| ON_QUEUE_CONVERSION | Перед отправкой идёт конвертация валюты, если она нужна | Нет |
| ON_NETWORK_QUEUE | Перевод отправлен в сеть и подтверждается | Нет |
| SUCCESS | Отправлена и подтверждена в блокчейне | Да |
| CANCELED | Отменена | Да |
| FAILED | Ошибка при обработке или отправке | Да |
| AML_FAILED | Отклонена AML-проверкой адреса получателя | Да |
Опрашивать API на каждое изменение не нужно. Speend присылает вебхук, когда выплата встаёт в очередь и когда доходит до финального статуса: process, success, cancel, fail или aml_fail. В каждом вебхуке есть поле sign: прежде чем доверять статусу, сервер проверяет подпись отдельным ключом для выплат. URL для вебхуков задаётся в личном кабинете, заполните его до первого боевого запуска.
Массовые выплаты за 7 шагов
Никакой магии в массовых выплатах через API нет. Пачка выплат состоит из отдельных переводов, и каждый уходит своим запросом. Безопасность даёт дисциплина вокруг этих запросов. Вот порядок, который выдерживает тысячи переводов в день.
1. Собирайте список из своей учётной системы
Берите одобренные выводы или начисления из бэк-офиса, а не из таблицы, которую кто-то правил руками. Кому и сколько платить, должна решать та же система, что ведёт баланс пользователя.
2. Дайте каждой выплате уникальный order_id
Это самая важная строчка интеграции. Speend использует order_id как ключ идемпотентности: если запрос пришёл с уже существующим order_id, API вернёт исходную выплату и вторую не создаст. Таймаут сети и повторный запрос не превратятся в двойную выплату. Берите ID заявки на вывод из своей базы и никогда не используйте его повторно.
3. Проверяйте адрес и сеть до отправки
Сверьте формат адреса с выбранной сетью и убедитесь, что сеть подходит к монете. Speend отклонит неверный адрес или адрес из чёрного списка ещё при создании выплаты, но поймать ошибку на своей стороне дешевле: там можно сразу попросить пользователя исправить данные. Храните адрес получателя в его профиле и платите на него, а не на адрес, скопированный из истории транзакций. С выбором сетей по умолчанию поможет наш разбор USDT в TRC-20 или ERC-20, а о том, что бывает при переводе не в ту сеть, рассказывает отдельная статья.
4. Убедитесь, что баланса хватит на всю пачку
Если денег не хватает, API ответит «insufficient balance», и выплата не создастся. Сравните сумму пачки с балансом до старта и оставьте запас на комиссии сети. Цикл, который встал на середине, хуже цикла, который начался на час позже.
5. Отправляйте запросы и сохраняйте uuid
Отправляйте выплаты в ровном темпе, сохраняйте полученный uuid рядом со своим order_id и отмечайте вывод в своей системе как «передан в процессинг». С этого момента пользователь видит честный статус.
6. Крупные выплаты подтверждайте вручную
Выплаты выше вашего лимита останавливаются в статусе AWAITING_CONFIRMATION, пока кто-то не подтвердит их в личном кабинете. Самые крупные переводы проходят через второго человека, а мелкие рутинные массовые выплаты идут без ожидания.
7. Сверяйтесь по вебхукам и закрывайте цикл
Обновляйте статус каждого вывода, когда приходит вебхук, и сообщайте получателю, когда статус стал финальным. Для пограничных случаев спрашивайте API напрямую через payout/getStatus. Пример: если выплату отменили, пока она ждала подтверждения, вебхук cancel не придёт, и такую отмену поймает плановая проверка статуса.
Что защищает массовые выплаты
Автоматизация убирает ручные ошибки. Но и неверное правило она повторит тысячу раз за минуту, поэтому несколько настроек лучше сделать до роста объёмов.
Проверяйте и тех, кому платите. По данным Chainalysis, незаконные адреса получили в 2025 году не меньше $154 млрд, и 84% этого объёма пришлось на стейблкоины, хотя на незаконную активность по-прежнему приходится меньше 1% всех транзакций в блокчейне (The Block). Перевод на санкционный или рискованный адрес может стать вашей комплаенс-проблемой, даже если получатель ваш собственный клиент. Speend проверяет адрес получателя в процессе выплаты, и выплата, которая не прошла проверку, заканчивается статусом AML_FAILED. Подробнее в наших статьях про KYT и AML.
Держите ключи для выплат отдельно. Вебхуки по выплатам Speend подписывает отдельным ключом, не тем, что используется для платежей. Дайте доступ к нему как можно меньшему числу людей и сервисов и меняйте ключ, когда кто-то уходит из команды.
Ставьте лимиты подтверждения под свой риск. Казино может пропускать выплаты до $1000 автоматически, а крупные отправлять менеджеру. Брокер может поставить планку ниже для новых клиентов. Лимит согласуйте с вашим менеджером в Speend, чтобы он подходил под ваш процесс.
Выбирайте сети для массовых выплат осознанно. У USDT сети отличаются комиссией, скоростью и тем, насколько их поддерживают кошельки ваших пользователей. Двух-трёх сетей хватает почти всем получателям. Десять сетей во столько же раз увеличивают шанс, что кто-то ошибётся сетью.
Что меняется в цифрах
Условный пример. Онлайн-казино обрабатывает 2000 криптовыводов в неделю. Вручную на каждую выплату уходит около трёх минут, если считать проверку, копирование, подпись и запись хеша. Получается около 100 часов в неделю, то есть два с половиной сотрудника, которые больше ничем не заняты. Плюс ошибки, которые неизбежны, когда глаза устали.
Когда массовые выплаты идут через API, те же 2000 переводов уходят из бэк-офиса автоматически. Люди разбирают только исключения: крупные суммы на подтверждении, адреса, не прошедшие проверку, и редких получателей, указавших не ту сеть. Если внимания требуют 3% выплат, это 60 случаев в неделю вместо 2000.
С партнёрками картина похожая. Программа, которая платит 150 вебмастерам через SWIFT по $15–40 за перевод, отдаёт $2250–6000 в месяц только на банковские комиссии. Выплаты тем же партнёрам в USDT заменяют это комиссией сети за каждый перевод. В недорогих сетях она обычно составляет малую долю стоимости банковского перевода, а деньги приходят в тот же день, а не через несколько рабочих дней.
Частые ошибки
- Новый случайный
order_idпри каждом повторе. Так идемпотентность выключается, и появляется риск двойной выплаты. - Доверие к вебхуку без проверки
sign. Иначе любой, кто узнал ваш callback URL, сможет отметить выплаты как проведённые. - Пустой URL для вебхуков в личном кабинете. Вебхуки без заданного адреса теряются, и ваша система так и не узнает финальный статус.
- Слепой повтор выплаты со статусом
FAILED. Сначала разберитесь в причине; новую попытку с новымorder_idделайте только тогда, когда точно знаете, что первая не ушла. - Пополнение баланса для выплат в последний момент. Держите на балансе сумму, которой хватит на следующую пачку.
Частые вопросы
Есть ли отдельный метод API для массовых выплат?
Нет. Каждая выплата отправляется отдельным запросом. Ваша система проходит по списку и отправляет их по очереди, а order_id делает любой запрос безопасным для повтора.
Какая минимальная сумма выплаты?
Эквивалент 7 USD за одну выплату. Этот минимум действует для каждого перевода, в том числе когда идут массовые выплаты.
Что будет, если одну и ту же выплату отправить дважды?
Если у обоих запросов одинаковый order_id, Speend вернёт исходную выплату и вторую не создаст.
Можно ли остановить выплату?
Выплату, которая ждёт подтверждения в личном кабинете, можно отменить. Когда она ушла в сеть, развернуть её уже нельзя, как и любой перевод в блокчейне.
Что, если адрес получателя не прошёл AML-проверку?
Выплата получает статус AML_FAILED, и деньги не отправляются. Попросите у получателя другой адрес, а за подробностями по конкретному случаю обратитесь к вашему менеджеру в Speend.
Сколько идёт выплата?
Зависит от очереди и от сети: перевод считается завершённым, когда блокчейн его подтвердил, а скорость подтверждения в разных сетях разная. Точный статус каждой выплаты всегда виден через вебхуки и payout/getStatus.
Можно ли платить в монете, которой нет на балансе?
Если выплате нужна конвертация, она проходит отдельный этап ON_QUEUE_CONVERSION перед отправкой. Какие пары доступны для вашего аккаунта, уточните у менеджера.
Можно ли отправлять выплаты вручную?
Да. Выплату можно создать вручную в личном кабинете, а не только через API. Для разовых переводов это удобно, а массовые выплаты лучше оставить API.
С чего начать
Посчитайте, во что вам обходится нынешний процесс выплат: сколько выплат в неделю, сколько минут на каждую, сколько уходит на банковские комиссии и какая доля тикетов в поддержке начинается со слов «где мои деньги». Потом прикиньте, что изменится, если массовые выплаты пойдут через ту же интеграцию, через которую вы уже принимаете платежи.
Если хотите посмотреть, как это будет работать у вас, напишите команде Speend. Персональный менеджер поможет настроить выплаты, лимиты подтверждения и вебхуки и проведёт с вами первую тестовую пачку.
