Direcciones exclusivas y compartidas para USDT / USDC

2026-06-16 · Actualizado 2026-10-01 · UUGate · 3 min de lectura

Compra puntual y saldo recurrente necesitan relaciones diferentes. Elige según objeto de negocio, identificación de importe y autoridad de firma, no solamente si la dirección es fija.

Elige la red y el modelo

Las órdenes compartidas de importe fijo vinculan referencia comercial y plataforma, con vencimiento y ocupación de importes. Una orden activa del mismo importe puede devolver 40105. La vinculación exclusiva une bindKey, red, activo y dirección.

Parámetros y pasos de integración

Usa POST /openapi/payin/orders para compra fija y POST /openapi/payin/exclusive-bindings para recargas. Solo se admiten TRC20-USDT, BEP20-USDT, BEP20-USDC y SPL-USDC. Cambiar el modelo no agrega redes.

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",
  "merchantOrderNo": "DEMO_PRODUCT_001",
  "amount": "10.00",
  "notifyUrl": "https://merchant.example.com/payments/notify"
}

Estados, callbacks y excepciones

Vincular una dirección no concede autoridad de firma. Las wallets custodiales generadas por la plataforma pueden pagar según permisos. Las direcciones importadas de observación se monitorean, pero la plataforma no puede firmar desde ellas.

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: una compra de 10.00 USDT obtiene su orden y checkout. MEMBER_DEMO_001 guarda una vinculación para recargas futuras. Ambos terminan en abonos verificados una sola vez, pero la búsqueda de dueño y la relación con la orden permanecen distintas.

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.