May 5, 2025
Криптоплатежи или банковские переводы: что выбрать бизнесу?
Читать статью
Ethereum часто воспринимают как “ещё одну криптовалюту для оплаты”. Для бизнеса это слишком упрощённый взгляд. Если вы хотите принимать оплату в ETH на сайте, нужно понимать не только, как клиент отправляет монеты с кошелька, но и что происходит с gas fee, статусами платежа, ERC-20 токенами, сетью, подтверждениями, недоплатами и сверкой операций.
На тесте всё может выглядеть просто: показать адрес кошелька, получить перевод, отметить заказ как оплаченный. В реальном потоке появляются вопросы: клиент отправил меньше нужной суммы, выбрал не ту сеть, заплатил после истечения счёта, не имел ETH для комиссии или закрыл страницу оплаты до подтверждения. Если эти сценарии не продуманы заранее, Ethereum-платежи быстро превращаются в ручную работу для поддержки и разработчиков.
Ниже — практический разбор Ethereum с точки зрения онлайн-бизнеса: что важно знать о сети, чем ETH отличается от ERC-20, почему gas влияет на конверсию и как правильно подключить оплату в ETH на сайт, приложение или другую цифровую платформу.
Ethereum — это блокчейн-сеть, в которой можно передавать ценность и запускать смарт-контракты. ETH — нативная монета сети. Её используют для переводов, оплаты комиссии gas и взаимодействия со смарт-контрактами.
Главное отличие Ethereum от более простых платёжных сценариев — программируемость. На Ethereum работают токены, децентрализованные приложения, кошельки, DeFi-сервисы, NFT и смарт-контракты. Для бизнеса это означает, что “оплата через Ethereum” может включать несколько разных сценариев:
Если нужно сначала разобраться в базовых понятиях, можно начать со статьи о том, как работает криптовалюта и блокчейн. А если важна логика программируемых условий, отдельно разобраны смарт-контракты в блокчейне.
На уровне блокчейна Ethereum-платёж выглядит так: пользователь создаёт транзакцию, указывает адрес получателя, сумму, параметры комиссии, подписывает операцию приватным ключом и отправляет её в сеть. После этого транзакция попадает в блок и получает подтверждения.
Но для сайта или приложения этого недостаточно. Бизнесу важно не просто увидеть перевод в блокчейне, а понять, к какому заказу он относится и что нужно делать дальше.
Практический сценарий оплаты выглядит так:
Блокчейн отвечает на вопрос: “Была ли транзакция?” Платёжная логика бизнеса отвечает на другой вопрос: “Кто оплатил, за что, в какой сумме, в какой сети и можно ли уже выдать товар или доступ?”
В разговорах о платежах часто смешивают ETH, Ethereum и ERC-20. Для пользователя это может быть “оплата в Ethereum”, но для сайта это разные сценарии.
ETH — нативная монета сети Ethereum. Если клиент платит в ETH, он отправляет ETH на адрес получателя. Комиссия сети тоже оплачивается в ETH.
ERC-20 — стандарт токенов в сети Ethereum. Многие токены и стейблкоины существуют в формате ERC-20. Клиент может платить таким токеном, но комиссия за транзакцию всё равно обычно нужна в ETH.
Здесь возникает частая проблема. У клиента может быть достаточно USDT ERC-20 для оплаты счёта, но не быть ETH для gas fee. В его глазах деньги есть, но платёж не проходит. Для бизнеса это выглядит как неуспешная оплата, обращение в поддержку или брошенный заказ.
Если вы принимаете стейблкоины, особенно USDT, важно не ограничиваться названием токена. Один и тот же USDT может существовать в разных сетях: Ethereum, TRON, BSC, Polygon и других. Подробно это разобрано в материале про TRC20, ERC20 и другие форматы USDT.
Gas fee — это комиссия за выполнение операции в Ethereum. Она нужна, чтобы сеть обработала транзакцию или взаимодействие со смарт-контрактом. Простая отправка ETH обычно требует меньше ресурсов, чем перевод ERC-20 токена или вызов смарт-контракта.
Для клиента gas — это часть пользовательского опыта. Для бизнеса — часть платёжной архитектуры.
Gas влияет на несколько вещей:
Важно: gas fee — это не комиссия платёжного провайдера. Это комиссия сети Ethereum. Но если страница оплаты объясняет её плохо, клиент всё равно воспринимает проблему как проблему вашего сайта.
Хороший платёжный сценарий должен показывать, в какой сети проходит оплата, какую сумму нужно отправить, сколько действует счёт, какой статус у платежа и что произойдёт при недоплате, задержке или оплате не в той сети. Общая логика сетевых комиссий подробнее раскрыта в статье о том, как работают комиссии за криптоплатежи.
Ethereum mainnet — основная сеть Ethereum. Она хорошо знакома криптопользователям, имеет большую экосистему и высокую ликвидность. Но комиссии в основной сети могут меняться, поэтому для небольших и частых платежей mainnet не всегда удобен.
Есть также сети второго уровня и EVM-совместимые сети. Они используют похожую логику кошельков и смарт-контрактов, но могут давать более низкие комиссии и более быстрый пользовательский сценарий.
Ethereum mainnet может быть уместен, если:
Альтернативные сети могут быть удобнее, если:
Например, для некоторых сценариев подойдёт Polygon. Отдельно можно посмотреть гайд о том, как принимать оплату в MATIC через сеть Polygon.
Главное правило: сеть выбирают не по популярности, а по реальному платёжному поведению клиентов. Важно, чтобы клиент мог оплатить, поддержка могла объяснить процесс, а финансовая команда могла сверить поступление.
Есть несколько способов подключить Ethereum-платежи. Они отличаются уровнем контроля, скоростью запуска и нагрузкой на команду.
Самый простой вариант — показать клиенту Ethereum-адрес и попросить отправить ETH вручную.
Так можно принимать разовые платежи, донаты, индивидуальные счета или тестировать спрос. Но для коммерческого сайта это слабый вариант.
Проблемы появляются быстро:
Прямой перевод — это не полноценная платёжная система. Это инструкция “отправьте деньги сюда”.
Техническая команда может построить собственную платёжную логику: генерировать адреса, отслеживать сеть, работать с узлами или провайдерами, обрабатывать подтверждения, хранить статусы и связывать транзакции с заказами.
Это даёт контроль, но требует ресурсов. Нужно поддерживать инфраструктуру, мониторинг, безопасность, обработку ошибок, правила возвратов, админку для поддержки и логику сверки.
Такой подход может быть оправдан для Web3-продуктов с сильной блокчейн-командой. Для обычного e-commerce, SaaS, онлайн-сервиса, маркетплейса или приложения это часто слишком дорогой и хрупкий путь.
Платёжный шлюз создаёт счёт, показывает клиенту инструкцию, отслеживает транзакцию, передаёт статусы и помогает связать оплату с заказом или аккаунтом клиента.
Для большинства бизнесов это самый практичный способ принимать ETH на сайте без самостоятельной поддержки блокчейн-инфраструктуры.
Хороший шлюз должен закрывать:
Если оплата должна быть глубоко встроена в продукт, посмотрите чеклист по API для криптоплатежей. Если нужно быстро добавить оплату на сайт без сложной логики, может хватить HTML-виджета для криптоплатежей.
Ethereum-платежи нельзя добавлять как экспериментальную кнопку без правил. Перед запуском нужно пройти весь путь оплаты.
Клиент должен понимать, что именно он оплачивает: ETH в сети Ethereum, ERC-20 токен в Ethereum или актив в другой сети.
Фраза “оплатить криптовалютой” слишком широкая. Лучше показывать конкретно: “ETH в сети Ethereum”, “USDT ERC-20”, “USDT TRC-20”. Это снижает риск ошибки и делает поддержку проще.
Если клиенту нужен ETH для оплаты комиссии, это нужно объяснить до перехода в кошелёк. Иначе он может увидеть ошибку уже в момент подтверждения транзакции.
Особенно часто это происходит с токенами. У клиента есть USDT ERC-20, но нет ETH для gas. Он считает, что средств достаточно, но платёж невозможен. Та же логика встречается в других сетях: для USDT TRC-20 нужен TRX, для BSC — BNB.
Эта проблема подробно разобрана в статье USDT без газа: почему оплата не проходит, если у клиента нет TRX, ETH или BNB.
Криптоплатёж не всегда укладывается в два состояния “оплачено” и “не оплачено”. Для нормальной работы нужны промежуточные статусы.
Минимально стоит продумать:
Эти статусы влияют на продуктовую логику. Интернет-магазин должен понять, когда менять статус заказа. SaaS — когда продлевать подписку. iGaming или приложение с балансом — когда зачислять депозит. Онлайн-школа — когда открывать доступ к курсу.
Нельзя считать платёж успешным только потому, что пользователь вернулся на сайт после оплаты. Редирект полезен для интерфейса, но не является доказательством оплаты.
Backend должен подтверждать платёж через API, webhook или надёжную серверную проверку. Это защищает от ложных статусов, повторных событий, закрытых вкладок, задержек и ошибок в frontend.
Финансовой команде недостаточно видеть хеш транзакции. Нужна связь между блокчейн-операцией и бизнес-событием.
В записи о платеже должны быть:
Если этих данных нет, каждое спорное обращение превращается в расследование.
Большинство проблем с Ethereum-платежами предсказуемы. Клиент может выбрать не ту сеть, не иметь ETH для gas, отправить меньше нужной суммы, оплатить позже срока или закрыть страницу до финального статуса.
Чтобы снизить ошибки, платёжный сценарий должен быть понятным.
На странице оплаты стоит показывать:
Лучше использовать динамические счета, а не один статический кошелёк для всех клиентов. Уникальный счёт проще связать с заказом, пользователем, тарифом или пополнением баланса.
Поддержку нужно подготовить до запуска. Сотрудник поддержки должен уметь найти платёж по ID заказа, аккаунту, сумме, валюте, сети, хешу транзакции и статусу. Если всё видно только в логах разработчика, бизнес будет терять время на каждом нестандартном платеже.
Больше типовых причин разобрано в статье о том, как снизить ошибки криптоплатежей.
ETH подходит, если аудитория уже пользуется Ethereum и хочет платить именно ETH. Это может быть актуально для Web3-сервисов, NFT-проектов, продуктов для криптоаудитории, разработчиков, цифровых товаров и международных онлайн-сервисов.
Но для повседневных оплат бизнес часто добавляет стейблкоины. Их проще использовать в ценах, отчётности и финансовом планировании, потому что стоимость привязана к базовой валюте, например доллару США. Это не убирает сетевые комиссии и операционные риски, но снижает влияние волатильности на сумму платежа.
Практичный набор может выглядеть так:
Если бизнес выбирает между разными стабильными активами, поможет разбор USDT, USDC и других стейблкоинов.
CryptumPay подходит бизнесу, которому нужно принимать криптовалюту на сайте, в приложении, Telegram-боте или другой цифровой платформе, не превращая каждый платёж в ручную проверку.
Для Ethereum-сценариев важны не только поддержка ETH и Ethereum, но и платёжная логика вокруг них: счёт, выбор валюты и сети, QR-код, API или HTML-виджет, статусы оплаты, личный кабинет, вывод средств, автоматическая конвертация поступлений в USDT, AML-проверки и двухфакторная защита аккаунта.
Отдельная практическая ценность — работа с комиссией сети. Если клиенту приходится вручную считать сумму и думать о gas, выше риск недоплаты или незавершённой оплаты. В сценарии CryptumPay комиссия может учитываться в счёте, чтобы клиенту не приходилось самостоятельно пересчитывать платёж.
Для повторных платежей важен ещё один момент: после первой оплаты клиент может быстрее совершать следующие платежи без полного ручного перевода каждый раз. Это особенно полезно для депозитов, пополнения баланса, приложений, игровых сервисов, SaaS и других продуктов с повторными оплатами.
Перед запуском Ethereum-платежей проверьте не только кнопку оплаты, но и весь процесс.
Ответьте на вопросы:
Если на эти вопросы нет ответов, интеграцию рано запускать в боевой поток.
Да. Сайт может принимать ETH через прямой перевод на кошелёк, собственную интеграцию с Ethereum или криптовалютный платёжный шлюз. Для большинства бизнесов шлюз удобнее, потому что он связывает счёт, транзакцию, статус оплаты и заказ в одной логике.
Да, в сети Ethereum комиссия gas оплачивается в ETH. Если клиент переводит ETH, комиссия списывается из ETH-баланса. Если клиент переводит ERC-20 токен, ему обычно всё равно нужен ETH на том же кошельке для оплаты gas.
ETH — нативная монета Ethereum. USDT ERC-20 — токен в сети Ethereum. При переводе USDT ERC-20 клиент платит сам токен, но комиссия сети всё равно обычно оплачивается в ETH. Поэтому у клиента может быть достаточно USDT, но платёж не пройдёт без ETH для gas.
Зависит от аудитории. Если клиенты держат ETH и привыкли платить через Ethereum-кошельки, ETH может быть полезным способом оплаты. Если важнее стабильная сумма и предсказуемый учёт, стейблкоины часто удобнее. На практике многие бизнесы принимают и ETH, и стейблкоины.
API нужен, если оплата должна автоматически менять статус заказа, пополнять баланс, открывать доступ, продлевать подписку или отправлять события во внутренние системы. Виджет подходит, если нужно быстрее добавить оплату на сайт и не строить сложную платёжную логику.
Принимать оплату в ETH на сайте — это не просто показать Ethereum-адрес. В рабочем платёжном сценарии должны быть понятные сети, корректный учёт gas fee, статусы оплаты, серверное подтверждение, обработка недоплат, связь с заказом и удобная сверка для финансовой команды.
Слабая интеграция может пройти один тестовый платёж, но начнёт ломаться на реальных клиентах: кто-то выберет не ту сеть, у кого-то не будет ETH для gas, кто-то оплатит позже срока, а кто-то отправит сумму без учёта комиссии.
Сильная интеграция делает Ethereum-платежи частью нормального бизнес-процесса. Клиент понимает, как платить. Разработчики получают статусы. Поддержка видит, что произошло. Финансы могут сверить поступления. Именно это отличает “мы принимаем ETH” от полноценного приёма Ethereum-платежей на сайте.
Create an account and connect the checkout yourself, or talk to sales and we will plan the integration with you.
Напишите нам в Telegram, и мы спланируем интеграцию
