API de recharge USDT pour membres : liaison et rapprochement
Une recharge doit identifier le propriétaire du dépôt. Un achat fixe utilise un ordre ; un solde récurrent peut utiliser une adresse dédiée liée à un identifiant membre stable.
Choisir le réseau et le modèle
USDT est pris en charge sur TRON (TRC20) et BSC (BEP20). Conservez bindKey, réseau, actif, bindingId et adresse. Dépôts des membres et recharges du compte de frais marchand sont distincts ; n’utilisez pas l’adresse de frais de la plateforme.
Paramètres et étapes d’intégration
Créez ou réutilisez POST /openapi/payin/exclusive-bindings. bindKey est votre identifiant stable et notifyUrl votre callback HTTPS. Consultez GET /openapi/payin/exclusive-bindings/{bindKey}?chainCode=TRON&tokenSymbol=USDT&recentLimit=10. bindKey n’est pas orderNo.
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",
"bindKey": "MEMBER_DEMO_001",
"label": "Demo member",
"notifyUrl": "https://merchant.example.com/member-topups/notify"
}Statuts, callbacks et exceptions
Chaque dépôt produit un enregistrement. Vérifiez membre, completed, paidAmount et réseau avant crédit. Les stats cumulées ne sont pas un nouveau montant. Examinez recentOrders, consultez chaque ordre et utilisez la même déduplication pour la compensation.
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 : MEMBER_DEMO_001 dépose 10.00 et 5.00 USDT sur TRON. Deux ordres vérifiés créditent 15.00. Un second envoi du dernier callback n’ajoute pas 5.00. Aucun membre ni paiement réel ; validez votre implémentation avant ouverture.
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
- Paramètres API
- Signature des requêtes
- Vérification des callbacks
- Offres et frais réseau
- Tutoriel associé
- API de paiement USDT
- API de paiement USDC
- Encaissement par adresse dédiée
- SDK Node.js
- SDK PHP / Laravel
- TRON: TRC-20 protocol interface
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.