API de recargas USDT para miembros: vinculación y conciliación

2026-07-17 · Actualizado 2026-10-01 · UUGate · 3 min de lectura

La recarga debe identificar al dueño del depósito. Una compra fija usa una orden; el saldo continuo puede usar una dirección exclusiva vinculada a un identificador estable de miembro.

Elige la red y el modelo

USDT está admitido en TRON (TRC20) y BSC (BEP20). Guarda bindKey, red, activo, bindingId y dirección. Los depósitos de miembros y las recargas de costos del comercio son distintos; no uses la dirección de costos de la plataforma.

Parámetros y pasos de integración

Crea o reutiliza POST /openapi/payin/exclusive-bindings. bindKey es tu identificador estable y notifyUrl tu callback HTTPS. Consulta GET /openapi/payin/exclusive-bindings/{bindKey}?chainCode=TRON&tokenSymbol=USDT&recentLimit=10. bindKey no es orderNo.

Este cuerpo es ilustrativo: no se envía una solicitud ni incluye datos reales. La llamada completa requiere UID, API Key, timestamp, nonce y firma en el servidor. Envía importes como cadenas y usa aritmética exacta para la contabilidad.

{
  "chainCode": "TRON",
  "tokenSymbol": "USDT",
  "bindKey": "MEMBER_DEMO_001",
  "label": "Demo member",
  "notifyUrl": "https://merchant.example.com/member-topups/notify"
}

Estados, callbacks y excepciones

Cada depósito genera un registro de cobro. Valida miembro, completed, paidAmount y red antes de abonar. stats acumulados no son el importe nuevo. Revisa recentOrders y consulta cada orden; la compensación debe usar la misma deduplicación.

Si crear un cobro vence por timeout y no tienes orderNo, comprueba la operación original en el panel. No supongas que merchantOrderNo garantiza reintentos idempotentes. Con orderNo, consulta esa orden de plataforma. La deduplicación de callbacks es distinta del reintento de creación.

Usa la API Key de la orden original y el rawBody sin cambios. Verifica HMAC-SHA256(timestamp + "." + nonce + "." + rawBody) contra x-callback-signature. Después valida identidad, orden, activo, red e importe. Una transacción de base de datos y una restricción única evitan el doble abono. Devuelve HTTP 2xx tras persistir de forma fiable; una redirección no confirma el pago.

Caso ilustrativo de integración

Ejemplo: MEMBER_DEMO_001 deposita 10.00 y 5.00 USDT en TRON. Dos órdenes verificadas abonan 15.00; repetir el segundo callback no suma otros 5.00. No son datos ni pagos reales. Valida tu implementación antes de abrirla.

Verificaciones antes del lanzamiento

La firma válida pasa; cambiar el cuerpo original invalida la firma.
Un callback duplicado abona una vez; el procesamiento interrumpido se recupera.
Consulta, callback, contabilidad y transacción en cadena coinciden.
Red incorrecta, importe anómalo, vencimiento o resultado desconocido requieren revisión.

Integración y referencias técnicas

Las fuentes explican estándares y métodos técnicos; no implican respaldo a UUGate. Los parámetros aplicables están en la documentación actual de UUGate.