Настройка приема платежей в USDT

Настройка приёма платежей в USDT

USDT существует в нескольких несовместимых версиях на разных сетях, и первый вопрос, который нужно закрыть: на каком блокчейне принимать. Это не технический выбор — это бизнес-решение с прямыми последствиями для конверсии. Большинство розничных пользователей держат USDT на TRC-20 (Tron) из-за минимальных комиссий (~0.3–1 USDT за перевод). Корпоративные клиенты и биржи — преимущественно ERC-20 (Ethereum) или BEP-20 (BNB Chain). Если не знаете свою аудиторию — поддерживайте минимум TRC-20 и ERC-20.

Технические особенности USDT

USDT (Tether) — ERC-20 токен с нестандартным поведением, о котором часто забывают:

• Не возвращает bool из transfer() на Ethereum. Стандартный ERC-20 должен возвращать bool, USDT этого не делает. Если пишете смарт-контракт, который принимает USDT, используйте SafeERC20.safeTransfer() из OpenZeppelin — он обрабатывает оба случая.
• Есть blacklist — Tether может заморозить адрес. Это реальный риск для custody-решений.
• Есть fee механизм (исторически не используется, но функция есть в контракте) — теоретически Tether может включить комиссию на переводы.

Архитектура приёма платежей

Вариант 1: уникальный адрес на каждый платёж (рекомендуется)

Генерируем HD-кошелёк (BIP-44), для каждого заказа деривируем новый адрес. Пользователь переводит на этот адрес — мы слушаем входящие транзакции через блокчейн-узел или API.

Master seed → BIP-44 path m/44'/195'/0'/0/N → адрес для заказа N

Преимущества: полная privacy пользователей между собой, нет shared state, легко reconcile платежи. Недостаток: нужно хранить индекс деривации и слушать адреса.

Для TRC-20 (Tron): путь деривации m/44'/195'/0'/0/N, адреса в формате base58check начинающиеся с T.

Вариант 2: один адрес с memo/comment

Один адрес приёма, пользователь указывает уникальный идентификатор в memo. Проще в реализации, хуже в UX — пользователи забывают memo.

Мониторинг входящих транзакций

Два подхода в зависимости от инфраструктуры:

Через сторонний API (быстро, с зависимостью):

• TronGrid API (https://api.trongrid.io) для TRC-20
• Alchemy/Infura webhooks для ERC-20 — подписка на Transfer events контракта USDT

// Пример webhook handler для Alchemy (ERC-20 USDT)
app.post('/webhook/alchemy', (req, res) => {
  const { event } = req.body
  if (event.eventName === 'Transfer') {
    const { to, value } = event.activity[0]
    // value в wei, делим на 10^6 (USDT имеет 6 decimals, не 18)
    const amount = BigInt(value) / BigInt(1_000_000)
    processPayment(to, amount)
  }
  res.sendStatus(200)
})

Важно: USDT использует 6 decimals, не 18. Это вызывает баги у разработчиков, привыкших к ETH.

Через собственный узел (надёжно, дороже):

Для ERC-20: подписка на eth_subscribe("logs") с фильтром по адресу USDT контракта и topic Transfer(address,address,uint256).

const USDT_ADDRESS = '0xdAC17F958D2ee523a2206206994597C13D831ec7'
const TRANSFER_TOPIC = '0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef'

provider.on({ address: USDT_ADDRESS, topics: [TRANSFER_TOPIC] }, (log) => {
  const to = '0x' + log.topics[2].slice(26) // decode indexed address
  const amount = BigInt(log.data) / BigInt(1_000_000)
  // сверяем 'to' с нашими адресами ожидающих платежей
})

Подтверждения транзакций

Для платежей до $1000 можно снизить до 3–6 подтверждений. Для крупных — ждать полной финальности.

Хранение приватных ключей

Приватные ключи от адресов приёма нельзя держать в базе данных в открытом виде. Минимально приемлемое решение — шифрование AES-256 с ключом из переменных среды. Правильное решение — HashiCorp Vault или AWS KMS для master seed, деривация ключей на лету.

Sweep стратегия: автоматически переводить поступившие средства с адресов приёма на cold wallet после каждого платежа. Не накапливать на hot адресах больше суточного оборота.

Что входит в работу

• Выбор и настройка сети (TRC-20, ERC-20, BEP-20 или несколько)
• Генерация HD-кошелька, настройка деривации адресов
• Интеграция с блокчейн API или развёртывание узла для мониторинга
• Webhook или polling сервис для обработки входящих транзакций
• Логика подтверждений и reconciliation с заказами
• Базовая защита ключей и sweep автоматизация