Налаштування прийому Ethereum платежів
Прийом ETH звучить просто: користувач надсилає транзакцію, гроші прийшли. На практиці питання "як я дізнаюся, що платіж прийшов і від кого" вирішується кількома способами, і більшість швидких реалізацій мають race conditions або проблеми з безпекою. Ми, як команда з 5-річним досвідом розробки блокчейн-рішень, пропонуємо надійну архітектуру, що виключає втрату коштів. Зв'яжіться з нами для консультації. У цій статті ми розберемо ключові архітектурні рішення: генерацію унікальних депозитних адрес через HD Wallet, моніторинг транзакцій через вебхуки та алгоритми підтвердження.
Архітектура: не робіть одну адресу для всіх
Найнадійніша схема — унікальна адреса на кожне замовлення/користувача. Це усуває проблему атрибуції: не потрібно зіставляти суми із замовленнями, не буває колізій, коли два користувачі платять однакову суму.
Реалізація через HD wallet (BIP-44): один master private key, адреси деривуються детерміновано за індексом. Користувачеві видається адреса m/44'/60'/0'/0/{order_id}, кошти з неї пересилаються на гарячий гаманець після підтвердження. HD Wallet (BIP-44)
import { HDNodeWallet } from 'ethers' const masterWallet = HDNodeWallet.fromPhrase(process.env.MNEMONIC) function getDepositAddress(orderId: number): string { return masterWallet.deriveChild(orderId).address } Master mnemonic — в HSM або як мінімум у зашифрованому вигляді в змінних оточення, ніколи в коді.
Моніторинг вхідних транзакцій
Поганий спосіб — поллити eth_getBalance кожні N секунд. Повільно, дорого за RPC-запитами, пропускає транзакції при перезапуску.
Правильний спосіб — підписка на події через WebSocket RPC:
provider.on({ address: depositAddress }, (log) => { // Обробка вхідного переказу }) Або через eth_subscribe newPendingTransactions — отримуємо сповіщення до підтвердження, але статус pending не можна вважати фінальним.
Для надійного production рішення — Alchemy Notify або QuickNode Streams: вебхуки при активності на адресах, працюють навіть якщо ваш backend перезапустився. Наш досвід показує, що така система в 10 разів швидша за polling за часом реакції.
Підтвердження та finality
На Ethereum після Merge finality настає через ~2 епохи (~12.8 хвилин). Для платежів:
| Сума | Рекомендовані підтвердження |
|---|---|
| < $100 | 1–3 блоки (~15–45 сек) |
| $100–$10k | 6–12 блоків (~1.5–2.5 хв) |
| > $10k | 32–64 блоки (до finality) |
Ніколи не зараховуйте кошти за pending транзакцією — транзакція може бути замінена через EIP-1559 replacement або виштовхнута з mempool.
Робота з ERC-20 токенами
Якщо потрібно приймати USDC/USDT поверх ETH — логіка ускладнюється: Transfer подія замість нативної транзакції. Необхідно слухати логи за ABI токена:
const filter = { address: USDC_CONTRACT, topics: [ ethers.id('Transfer(address,address,uint256)'), null, ethers.zeroPadValue(depositAddress, 32) ] } provider.on(filter, handleUsdcDeposit) Окремо потрібно врахувати: USDT на Ethereum має нестандартний approve (повертає void, а не bool) — це ламає стандартний ERC-20 інтерфейс. Використовуйте SafeERC20 від OpenZeppelin або обробляйте обидва випадки.
Як уникнути race conditions при прийомі ETH?
Race condition виникає, коли два користувачі надсилають платежі одночасно з однаковою сумою. Рішення — унікальні адреси (описано вище). Додатково використовуйте блокування на рівні бази даних при обробці транзакцій. Наприклад, використовуйте SELECT ... FOR UPDATE при зарахуванні коштів.
Що робити, якщо користувач надіслав невірну суму?
У такому випадку не зараховуйте кошти. Налаштуйте повернення (sweeping) на адресу відправника після визначеної кількості блоків. Або зв'яжіться з користувачем для уточнення. Ми гарантуємо, що ваші кошти не загубляться.
Що входить у налаштування під ключ?
- Генерація унікальних deposit адрес через HD wallet
- Вебхук-моніторинг через Alchemy/QuickNode або self-hosted listener
- Логіка підтверджень із налаштовуваним порогом
- Автоматичне пересилання коштів на основний гаманець (sweeping)
- Базовий API для інтеграції з вашим бекендом (Node.js, Python, Go)
- Документація та підтримка на етапі запуску
Оцініть наш проєкт: напишіть на пошту або в Telegram, отримайте консультацію протягом 1 дня. Замовте налаштування прямо зараз.
Досвід компанії
Ми виконали 30+ проєктів з інтеграції Ethereum платежів, сумарно оброблено понад $10 млн у криптовалюті. 5 років на ринку блокчейн-розробки. Наші інженери сертифіковані з Solidity та Rust.
Покрокова інструкція для самостійної реалізації
- Згенеруйте майстер-сид (12–24 слова) і збережіть у HSM.
- Розгорніть сервер з ethers.js або viem.
- Реалізуйте функцію getDepositAddress для генерації адреси.
- Підпишіться на вебхуки від Alchemy Notify або QuickNode Streams.
- Встановіть поріг підтверджень залежно від суми.
- Налаштуйте процес sweeping — періодичне надсилання балансів на основний гаманець.
Деталі щодо налаштування SafeERC20
Використовуйте бібліотеку OpenZeppelin: SafeERC20.safeTransfer() та SafeERC20.safeApprove(). Це захищає від нестандартних реалізацій токенів, таких як USDT, які повертають void замість bool.