Verificar transacciones TRON a través de API

Los sistemas de pago, intercambios y dApps deben confirmar las transacciones TRON mediante programación antes de acreditar a los usuarios. Un txid de transmisión no es suficiente: necesita un recibo de ejecución, un estado de éxito/error y, para los tokens, eventos Transfer decodificados.

Esta guía cubre los bucles de confirmación con TronWeb y TronGrid REST.

Ciclo de vida de la transacción

1. Transmisión: la transmisión firmada ingresa al mempool
2. Incluido en el bloque — ~3 segundos típico
3. Recibo disponible — getTransactionInfo completado
4. Solidificado — Bloque considerado final (espera configurable)

Las transacciones fallidas aún consumen tarifas y devuelven el recibo FAILED.

Obtener transacción por ID (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 DESCANSO

GET /v1/transactions/{txid}
GET /wallet/gettransactioninfobyid?value={txid}

Agregue el encabezado TRON-PRO-API-KEY según la guíaTronGrid.

Validar USDT detalles de la transferencia

No confíe únicamente en las cantidades proporcionadas por el cliente. Analizar registros:

const USDT = 'TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t';

function parseUsdtTransferFromInfo(txInfo) {
  const logs = txInfo.log || [];
  for (const log of logs) {
    if (tronWeb.address.fromHex(log.address) !== USDT) continue;
    // Transfer(address,address,uint256) topic0 = 0xddf252ad...
    // Decode topics[1] from, topics[2] to, data value
    // Use tronWeb.utils.abi.decodeLog or ethers ABI decoder
  }
}

Confirmar:

• Contrato de token = oficial USDT
• to = su dirección de depósito
• value = importe esperado (6 decimales)

Transacciones pendientes y faltantes

Guía de usuario: transacciones pendientes.

Solidificación del bloque {#solidificación}

Para depósitos de alto valor:

const block = await tronWeb.trx.getBlockByNumber(info.blockNumber);
// Optionally wait N more blocks via getCurrentBlock()

TRON la finalidad es rápida; muchos comerciantes utilizan un solo SUCCESS.

Registros comerciales coincidentes

Flujo de crédito idempotente:

1. El usuario envía txid
2. El servidor verifica SUCCESS + analiza la transferencia
3. Verifique que el txid no esté acreditado en la base de datos.
4. Saldo del usuario de crédito
5. Almacenar número de bloque, marca de tiempo y registro sin procesar

Diagnóstico de transacción fallido

Lea resMessage / resultado del contrato hexadecimal para conocer el motivo de reversión. Común:

• OUT_OF_ENERGY
• Saldo de token insuficiente
• Contrato en pausa

Solución de problemas: la transacción falló.

Patrón de integración de webhook

Encuesta gettransactioninfobyid cada 3 segundos hasta blockNumber > 0 o tiempo de espera (5 minutos). En SUCCESS, emita webhook interno. En REVERT o tiempo de espera, marque el pago fallido y alerte al equipo de operaciones.

Manejo de REVERT y falsos positivos

getTransactionInfo devuelve receipt.result = REVERT por ejecución fallida; no acredite los pagos. Algunos indexadores devuelven brevemente el mensaje vacío antes de la confirmación; distinguen el recibo nulo (pendiente) del REVERT (fallido). Implemente un tiempo de espera después de 5 a 10 minutos y una cola de revisión humana para casos ambiguos.

Lista de verificación para solucionar problemas

Si algo sale mal en TRON, trátelo como un problema de depuración estructurado: confirme el txid exacto en la cadena, verifique la dirección del contrato de destino y solo entonces decida si la falla es recuperable. En TRON, muchos problemas "misteriosos" son simplemente uno de: red incorrecta (mainnet vs testnet), contrato de token incorrecto (falso USDT/tokens con nombres similares), recursos insuficientes (OUT_OF_ENERGY/ancho de banda) o retraso en la interfaz de usuario/indexador entre la billetera y el explorador.

Comience con estas comprobaciones en cadena:

• Copie siempre el txid/hash completo de su billetera o explorador.
• Confirme el estado del resultado del tx en TronScan (SUCCESS, REVERT, OUT_OF_ENERGY o aún pendiente).
• Compruebe si la dirección del destinatario/contrato coincide con la que desea enviar.
• Si se trata de una llamada de contrato, confirme que el selector de función y los parámetros coincidan con el estándar de token que cree que está utilizando (TRC-20 vs TRC-10 vs BEP-20 en BSC).

Luego aplique la ruta de corrección para su categoría:

• Confirmar el estado y los parámetros de la transacción.
• Verificar direcciones (contrato de token, destinatario, enrutador/gastador).
• Agregar o delegar recursos (Energía/Ancho de banda) cuando el fallo esté basado en recursos.

Errores comunes

Estos patrones causan la mayoría de los errores a nivel de usuario:

• Usar direcciones de mainnet en testnet (o al revés).
• Copiar un símbolo de token en lugar de la dirección real del contrato TRC-20.
• Firmar la dirección de aprobación/gastador incorrecta porque el enlace de la interfaz de usuario es malicioso o está desactualizado.
• Reintentar sin cambiar la entrada fallida (por ejemplo, REVERT sigue revirtiéndose hasta que corrija el parámetro).

Si no está seguro, no “simplemente envíe de nuevo”. Realice un cambio controlado, verifique en TronScan y luego continúe.

Preguntas frecuentes

¿Cómo sé si una transacción está realmente confirmada?

Utilice TronScan y verifique el estado del resultado del tx. Las etiquetas "pendientes" de la billetera pueden retrasarse; El estado de la cadena es la fuente de la verdad. Copie txid y verifique SUCCESS/REVERT/OUT_OF_ENERGY, no solo el texto de la interfaz de usuario.

¿Por qué la interfaz de usuario difiere de TronScan?Algunas billeteras y dApps utilizan diferentes indexadores o capas de caché. Es normal que haya un breve retraso entre la transmisión y la indexación; compare txid y espere a que la cadena se estabilice antes de concluir que hay una falla.

¿Qué debo hacer después de un REVERT?

Detenga y decodifique la llamada fallida. La mayoría de los REVERT se deben a parámetros no válidos, dirección de contrato incorrecta, aprobaciones faltantes o una falta de coincidencia entre el estándar del token y el método. Solucione la causa y luego vuelva a firmar.

¿Es seguro firmar una aprobación ilimitada?

Las aprobaciones ilimitadas son seguras solo para direcciones de gastadores confiables que usted haya verificado (fuente verificada, enrutador correcto y contrato de token esperado). Para las pruebas, prefiera aprobaciones limitadas y revoque una vez que haya terminado.

¿Qué recursos requiere TRON para las llamadas de contrato?

La ejecución de contratos inteligentes consume principalmente energía, mientras que los bytes de transacciones consumen ancho de banda. Si recibe OUT_OF_ENERGY, agregue/congela/delegue energía. Si se agota el ancho de banda, concéntrese en mantener suficiente líquido TRX para bytes y asignación de recursos.

¿Cómo puedo reducir los tickets de soporte?

Muestre a los usuarios un mensaje claro de "qué sucedió" basado en el estado de la cadena y vincule directamente a la guía relevante (pendiente, fallida, sin energía o verificación). Guarda txid para que puedas conciliar rápidamente.

Guías relacionadas

• Aceptar API de pagos USDT
• Guía de seguimiento de transacciones
• Leer detalles de la transacción
• TRON Referencia de API HTTP

Preguntas frecuentes

¿Cuántas confirmaciones necesita TRON?

TRON utiliza bloques solidificados rápidamente; la mayoría de las aplicaciones tratan un recibo SUCCESS como final. Las aplicaciones de alto valor pueden esperar a que se solidifiquen bloques adicionales.

¿Cuál es la diferencia entre getTransaction y getTransactionInfo?

getTransaction devuelve datos de transmisión; getTransactionInfo incluye recibo, tarifas, energía utilizada y resultado del contrato después de la ejecución.

¿Puede un tx mostrar SUCCESS pero una cantidad incorrecta?

Analice siempre los registros de eventos: verifique el monto y el orden de coincidencia del destinatario.

¿Cuánto tiempo tardará en sondear?

Generalmente menos de 10 segundos. Se agota el tiempo de espera después de 60 a 120 segundos y se solicita al usuario el enlace TronScan.

TronScan frente a API?

Mismos datos de cadena. API para automatización; Guía TronScan para depuración manual.