Success в обозревателе означает, что транзакция выполнилась успешно. Оплата заказа требует большего: нужный актив должен попасть нужному получателю в нужной сумме и соответствовать текущему счёту.
Возьмём выдуманный заказ в вашем магазине на 100 USDT. Покупатель присылает ссылку на транзакцию с зелёной отметкой Success и ждёт отправки товара. Счёт пока не оплачен. Чтобы разобраться, нужно понять, на какой вопрос отвечает каждая из этих двух страниц.
Что именно означает Success?
Блокчейн записывает результат выполнения транзакции. В Ethereum статус в квитанции показывает, завершился ли основной вызов успешно или откатился из-за ошибки. Обозреватель отображает этот результат знакомой отметкой Success. Определение статуса в EIP-658.
Обозреватель не знает, что вы продаёте и сколько стоил заказ. Он не проверяет условия вашего счёта. Поэтому настоящая, успешно выполненная транзакция может не иметь отношения к покупке на 100 USDT. Ссылка помогает найти запись в сети; сама по себе она ещё не отвечает на вопрос об оплате.
Кому ушли токены?
В EVM-сетях поле to легко прочитать неверно. При вызове токен-контракта оно указывает на этот контракт. Адрес конечного получателя перевода может находиться в данных вызова и в событии, которое контракт записал после выполнения. Так устроены транзакции с вызовом контракта в Ethereum.
Следовательно, адрес из верхней строки страницы не всегда нужно сравнивать с адресом для оплаты. Для нашего заказа важен фактический перевод токена: кому и сколько передал проверенный контракт. Входные данные показывают запрошенное действие; результат нужно проверять отдельно. Даже запись с названием Transfer нельзя принимать за доказательство без проверки контракта, который её создал.
А перевод вообще состоялся?
Успешной может быть и операция approve: она разрешает другому адресу расходовать токены, но сама их не переводит. Имя и тикер тоже не удостоверяют актив. ERC-20 описывает эти поля как свойства токен-контракта, а не знак подлинности. Стандарт ERC-20.
Покупатель мог прислать транзакцию с разрешением или переводом другого токена под названием USDT. Это разные ситуации, хотя на обеих страницах возможен Success. Поддельный токен не становится принимаемым активом из-за знакомой надписи. Нельзя обещать, что такая запись пополнит баланс магазина. Другие способы подмены разобраны в статье о мошенничестве с криптоплатежами.
Что нужно сопоставить со счётом?
Вернёмся к заказу на 100 USDT. Допустим, перевод действительно состоялся. Теперь остаётся установить, относится ли он к этому счёту. Разница даже в одном условии меняет результат.
Это объясняет, почему две правдивые страницы иногда показывают разные статусы. Обозреватель сообщает о выполненной операции, а платёжная страница — о состоянии конкретного счёта.
Почему ещё нужны подтверждения?
Success и окончательность записи — отдельные свойства транзакции. Успешное выполнение в блоке ещё не означает, что сеть достигла требуемой финальности. В Ethereum блок проходит дальнейшие стадии подтверждения после включения транзакции.
Поэтому счёт может ждать подтверждений уже обнаруженного перевода. В Paymos требования зависят от сети и суммы; единого срока для всех платежей нет. Если покупатель действительно отправил наши 100 USDT по условиям счёта, ожидание само по себе не доказывает ошибку или обман. Подробнее — в статье о подтверждениях транзакции.
Может ли баланс пополниться без оплаты счёта?
Такое различие существует и в Paymos. Например, другой принимаемый актив, поздний перевод или поступление к уже закрытому счёту могут зачислиться бизнесу отдельно. Счёт от этого не становится оплаченным, а вебхук об оплате заказа не приходит.
С другой сетью тоже нельзя делать вывод по одной отметке. Результат зависит от того, разрешён ли соответствующий маршрут оплаты и отслеживается ли поступление для этого счёта. Перевод не обязательно пропадает и не обязательно закрывает заказ.
Для магазина здесь два отдельных факта: что поступило на баланс и какой заказ оплачен. Их нужно сверять, прежде чем отправлять товар. Поддельный токен с чужим контрактом не следует считать примером принимаемого актива.
По чему магазин подтверждает заказ?
Покупатель ориентируется на статус платёжной страницы. Магазин подтверждает заказ по серверному состоянию связанного счёта либо по проверенному вебхуку о его оплате. До обработки уведомления проверяют подпись; порядок описан в документации Paymos.
Подлинное уведомление тоже нужно отнести к правильному счёту. Переход покупателя на страницу «Спасибо» и скриншот обозревателя такой проверки не заменяют. В нашем примере отправку товара запускает подтверждённая оплата счёта на 100 USDT.
| Что проверяем | Почему одного Success недостаточно |
|---|---|
| Сеть | Перевод выполнен в конкретной сети |
| Актив | Нужен принимаемый токен с проверенным контрактом |
| Получатель | Средства могли уйти на другой адрес |
| Сумма | Успешный перевод мог быть меньше требуемого |
| Текущий счёт | Перевод может относиться к другой или уже закрытой покупке |
Частые вопросы
Покупатель заплатил комиссию сети. Это доказывает оплату?
Комиссия относится к выполнению транзакции. Она не подтверждает поступление нужного токена магазину.
Можно ли подтвердить заказ по хешу транзакции?
Хеш помогает найти перевод. Для подтверждения нужны его проверенный результат, соответствие счёту и требуемые подтверждения.
Неоплаченный счёт означает, что средства потеряны?
Нет. При отдельном зачислении средства могут быть на балансе бизнеса, хотя заказ остаётся неоплаченным. Это проверяют отдельно.
Источники
- 1. EIP-658: статус транзакции в квитанции (accessed 2026-10-09)
- 2. ERC-20: стандарт токенов (accessed 2026-10-09)
- 3. Ethereum: транзакции (accessed 2026-10-09)
Последняя проверка: 9 окт. 2026 г.


