Налаштування прийому платежів у 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 — він обробляє обидва випадки.
• Є чорний список — Tether може заморозити адресу. Це реальний ризик для custody-рішень.
• Є механізм комісій (історично не використовується, але функція є в контракті) — теоретично Tether може включити комісію на переводи.

Архітектура приймання платежів

Варіант 1: унікальна адреса на кожен платіж (рекомендується)

Генеруємо HD-гаманець (BIP-44), для кожного замовлення дериваціюємо нову адресу. Користувач переводить на цю адресу — слухаємо вхідні транзакції через блокчейн-вузол або API.

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

Переваги: повна приватність користувачів один від одного, немає shared state, легко согласовувати платежі. Недолік: потрібно зберігати індекс деривації і слухати адреси.

Для 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 eventi контракту 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) // декодуємо indexed адресу
  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 сервіс для обробки вхідних транзакцій
• Логіка підтверджень і согласованості з замовленнями
• Базова захист ключів і sweep автоматизація