Adresses dédiées et partagées pour USDT / USDC

2026-06-16 · Mis à jour 2026-10-01 · UUGate · 3 min de lecture

Achats ponctuels et soldes récurrents nécessitent des relations différentes. Choisissez selon l’objet métier, l’identification du montant et le pouvoir de signature, pas seulement la permanence de l’adresse.

Choisir le réseau et le modèle

Les ordres partagés à montant fixe relient références marchand et plateforme, avec expiration et réservation des montants. Un ordre actif de même montant peut retourner 40105. La liaison dédiée associe bindKey, réseau, actif et adresse.

Paramètres et étapes d’intégration

Utilisez POST /openapi/payin/orders pour les achats fixes et POST /openapi/payin/exclusive-bindings pour les recharges. Combinaisons : TRC20-USDT, BEP20-USDT, BEP20-USDC et SPL-USDC. Le changement de modèle n’ajoute aucun réseau.

Ce corps est illustratif : aucune requête n’est envoyée et aucune donnée réelle n’est incluse. L’appel complet exige UID, API Key, timestamp, nonce et signature côté serveur. Transmettez les montants en chaînes et utilisez un calcul exact pour la comptabilité.

{
  "chainCode": "TRON",
  "tokenSymbol": "USDT",
  "merchantOrderNo": "DEMO_PRODUCT_001",
  "amount": "10.00",
  "notifyUrl": "https://merchant.example.com/payments/notify"
}

Statuts, callbacks et exceptions

Une liaison métier ne confère pas le droit de signer. Les portefeuilles custodiaux générés par la plateforme peuvent payer selon les permissions. Les adresses importées en observation sont surveillées, mais la plateforme ne peut pas signer leurs sorties.

Si la création d’un encaissement expire sans orderNo, vérifiez l’opération originale dans le tableau de bord. Ne supposez pas que merchantOrderNo garantit une relance idempotente. Avec orderNo, consultez cet ordre. La déduplication des callbacks et la relance de création sont distinctes.

Utilisez l’API Key de l’ordre original et le rawBody inchangé. Vérifiez HMAC-SHA256(timestamp + "." + nonce + "." + rawBody) avec x-callback-signature. Contrôlez ensuite identité, ordre, actif, réseau et montant. Transaction de base de données et contrainte unique évitent les crédits doubles. Répondez HTTP 2xx après persistance fiable ; une redirection ne confirme pas le paiement.

Exemple illustratif d’intégration

Exemple : un achat de 10.00 USDT reçoit ordre et checkout. MEMBER_DEMO_001 conserve une liaison pour les dépôts futurs. Les deux flux finissent par un crédit vérifié une fois, mais la recherche du propriétaire et la relation avec l’ordre restent distinctes.

Vérifications avant lancement

La signature valide passe ; modifier le corps original invalide la vérification.
Un callback répété crédite une seule fois ; un traitement interrompu peut reprendre.
Requêtes, callbacks, écritures et transactions en chaîne concordent.
Mauvais réseau, montant anormal, expiration et résultat inconnu nécessitent une enquête.

Intégration et références techniques

Ces sources expliquent les standards et méthodes techniques ; elles ne constituent pas une approbation d’UUGate. Les paramètres applicables sont dans la documentation UUGate actuelle.