Проверка транзакций TRON через API

Платежные системы, биржи и децентрализованные приложения должны программно подтверждать транзакции TRON перед зачислением средств пользователям. Широковещательного txid недостаточно — вам нужна квитанция об исполнении, статус успеха/неудачи, а для токенов — декодированные события Transfer.

В этом руководстве рассматриваются циклы подтверждения с TronWeb и TronGrid REST.

Жизненный цикл транзакции

1. Broadcast — подписанная передача попадает в мемпул.
2. Включено в блок — обычно ~3 секунды.
3. Квитанция доступна — getTransactionInfo заполнено
4. Solidified — блок считается окончательным (настраиваемое ожидание).

Неудачные транзакции по-прежнему потребляют комиссию и возвращают квитанцию в размере FAILED.

Получить транзакцию по идентификатору (TronWeb)

async function waitForTx(txid, maxAttempts = 30, delayMs = 2000) {
  for (let i = 0; i < maxAttempts; i++) {
    const info = await tronWeb.trx.getTransactionInfo(txid);
    if (info && Object.keys(info).length > 0) {
      return info;
    }
    await new Promise((r) => setTimeout(r, delayMs));
  }
  throw new Error('Transaction info not found — timeout');
}

async function isTxSuccess(txid) {
  const info = await waitForTx(txid);
  return info.receipt?.result === 'SUCCESS';
}

TronGrid ОТДЫХ

⟦Т1⟧

Добавьте заголовок TRON-PRO-API-KEY в руководство TronGrid.

Подтвердить данные перевода USDT

Не доверяйте только суммам, предоставленным клиентом. Разбор логов:

⟦Т2⟧

Подтвердите:

• Контракт токена = официальный USDT
• to = адрес вашего депозита
• value = ожидаемая сумма (6 десятичных знаков)

Ожидающие и отсутствующие транзакции

Руководство пользователя: ожидающие транзакции.

Блокирование затвердевания

Для депозитов на большую сумму:

⟦Т3⟧

TRON быстрая завершенность; многие торговцы используют одиночный SUCCESS.

Соответствующие бизнес-записи

Идемпотентный кредитный поток:

1. Пользователь отправляет txid
2. Сервер проверяет SUCCESS + анализ передачи
3. Проверьте, что txid еще не зачислен в базу данных.
4. Кредитный баланс пользователя
5. Сохраните номер блока, метку времени, необработанный журнал.

Неудачная диагностика транзакции

Прочтите resMessage / шестнадцатеричный результат контракта, чтобы узнать причину возврата. Общие:

• ⟦Т11⟧
• Недостаточный баланс токенов
• Контракт приостановлен

Устранение неполадок: транзакция не удалась.

Шаблон интеграции вебхука

Опрашивайте gettransactioninfobyid каждые 3 секунды до blockNumber > 0 или таймаута (5 минут). На SUCCESS создайте внутренний вебхук. По REVERT или по тайм-ауту отметьте неудачный платеж и предупредите оперативную группу.

Обработка REVERT и ложных срабатываний

getTransactionInfo возвращает receipt.result = REVERT в случае неудачного выполнения — платежи не зачисляются. Некоторые индексаторы кратковременно возвращают пустое значение перед подтверждением — отличайте нулевое получение (ожидание) от REVERT (ошибка). Внедрите таймаут через 5–10 минут и очередь проверки человеком для неоднозначных случаев.

Контрольный список устранения неполадок

Если что-то пойдет не так на TRON, отнеситесь к этому как к проблеме структурированной отладки: подтвердите точный txid в цепочке, проверьте адрес целевого контракта и только затем решите, можно ли устранить сбой. В TRON многие «загадочные» проблемы — это просто одна из следующих: неправильная сеть (основная сеть или тестовая сеть), неправильный контракт токена (поддельный USDT / токены с одинаковым названием), недостаточность ресурсов (OUT_OF_ENERGY / пропускная способность) или задержка пользовательского интерфейса/индексатора между кошельком и проводником.

Начните с этих цепочек проверок:

• Всегда копируйте полный txid/хэш из своего кошелька или проводника.
• Подтвердите статус результата отправки на TronScan (SUCCESS, REVERT, OUT_OF_ENERGY или все еще в ожидании).
• Проверьте, соответствует ли адрес получателя/договора тому, что вы намеревались отправить.
• Если это вызов контракта, убедитесь, что селектор функций и параметры соответствуют стандарту токена, который, по вашему мнению, вы используете (TRC-20 vs TRC-10 vs BEP-20 на BSC).

Затем примените путь исправления для вашей категории:

• Подтвердите статус и параметры транзакции.
• Проверка адресов (контракт токена, получатель, маршрутизатор/отправитель).
• Добавляйте или делегируйте ресурсы (энергию/пропускную способность), если сбой связан с ресурсами.

Распространенные ошибки

Эти шаблоны вызывают большинство сбоев на уровне пользователя:

• Использование адресов основной сети в тестовой сети (или наоборот).
• Копирование символа токена вместо фактического адреса контракта TRC-20.
• Подписание неправильного адреса одобрения/платежа, поскольку ссылка пользовательского интерфейса является вредоносной или устаревшей.
• Повторная попытка без изменения ошибочного ввода (например, REVERT продолжает возвращаться до тех пор, пока вы не исправите параметр).

Если вы не уверены, не «просто отправьте еще раз». Внесите одно контролируемое изменение, проверьте на TronScan, затем продолжайте.

Часто задаваемые вопросы

Как узнать, действительно ли транзакция подтверждена?

Используйте TronScan и проверьте статус результата передачи. Ярлыки кошелька «ожидающие» могут отставать; Статус цепочки является источником истины. Скопируйте txid и проверьте SUCCESS/REVERT/OUT_OF_ENERGY, а не только текст пользовательского интерфейса.

Почему пользовательский интерфейс отличается от TronScan?Некоторые кошельки и децентрализованные приложения используют разные индексаторы или уровни кэша. Короткая задержка между трансляцией и индексированием является нормальной; сравните txid и подождите, пока цепочка стабилизируется, прежде чем сделать вывод об ошибке.

Что мне делать после REVERT?

Остановитесь и декодируйте неудачный вызов. Большинство ошибок REVERT вызваны неверными параметрами, неправильным адресом контракта, отсутствием утверждений или несоответствием между стандартом токена и методом. Устраните причину и подпишите заново.

Безопасно ли подписывать неограниченное разрешение?

Неограниченное одобрение безопасно только для проверенных вами адресов доверенных отправителей (проверенный источник, правильный маршрутизатор и ожидаемый контракт токена). Для тестирования отдавайте предпочтение ограниченному утверждению и отзыву после завершения.

Какие ресурсы требуются TRON для вызовов контракта?

Выполнение смарт-контракта в основном потребляет энергию, а байты транзакций потребляют пропускную способность. Если вы получили OUT_OF_ENERGY, добавьте/заморозьте/делегируйте Энергию. Если полоса пропускания исчерпана, сосредоточьтесь на сохранении достаточного количества TRX для байтов и распределения ресурсов.

Как я могу уменьшить количество обращений в службу поддержки?

Покажите пользователям четкое сообщение «что произошло» на основе статуса цепочки и дайте прямую ссылку на соответствующее руководство (ожидание, сбой, отсутствие энергии или проверка). Сохраните txid, чтобы можно было быстро выполнить согласование.

Похожие руководства {#связанные}

• API приема платежей USDT
• Руководство по отслеживанию транзакций
• Читать детали транзакции
• TRON Справочник по HTTP API

Часто задаваемые вопросы

Сколько подтверждений нужно TRON?

TRON быстро использует затвердевшие блоки — большинство приложений считают одну квитанцию ​​SUCCESS окончательной. Высокоценные приложения могут ждать дополнительного закрепления блока.

В чем разница между getTransaction и getTransactionInfo?

getTransaction возвращает широковещательные данные; getTransactionInfo включает в себя квитанции, комиссии, использованную энергию и результат контракта после исполнения.

Может ли транзакция показать SUCCESS, но неправильную сумму?

Всегда анализируйте журналы событий — проверяйте сумму и порядок сопоставления получателей.

Как долго будет проводиться опрос?

Обычно менее 10 секунд. Тайм-аут через 60–120 секунд и запросить у пользователя ссылку TronScan.

TronScan против API?

Те же данные цепи. API для автоматизации; TronScan руководство для ручной отладки.