Paiements USDT pour SaaS : renouvellement, solde prépayé et accès
Les paiements USDT d’un SaaS doivent relier facture, commande de paiement et accès au compte. Votre application décide du forfait et de la durée du service. UUGate fournit encaissement, requêtes et callbacks ; vos règles d’abonnement restent dans votre SaaS.
Factures ou solde prépayé
Créez une commande fixe par facture mensuelle ou annuelle que le client paie activement. Pour une consommation à l’usage, liez une adresse dédiée, créditez les recharges confirmées puis appliquez vos règles.
Conservez facture et orderNo dans le premier mode ; membre, bindKey, réseau et actif dans le second. Définissez vérification des montants et livraison pour chacun.
Générer l’entrée de paiement
Fixez montant, forfait et validité côté serveur et utilisez l’API d’encaissement. Conservez merchantOrderNo, orderNo, cashierUrl et expireAt pour ouvrir la page de paiement.
USDT prend en charge TRC20 et BEP20 ; USDC, BEP20 et SPL. Le client doit utiliser l’actif et le réseau de la facture. Une politique de parité n’est ni un taux de change en direct ni une conversion fiduciaire.
Activer les droits après confirmation
Vérifiez le callback, marchand, commande, réseau, actif, montant reçu et completed avant de modifier le compte. Enregistrement unique et transaction évitent une prolongation double.
Exemple : une facture mensuelle de 20 USDT prolonge d’une période après confirmation. C’est un exemple de parcours, pas un tarif UUGate ni un cas client. Conservez facture, paiement et modification des droits pour reprise ou compensation.
Traiter les recharges continues
Liez une adresse dédiée au membre authentifié. Créditez paidAmount pour chaque encaissement confirmé et dédupliquez par orderNo, pas par membre.
Votre SaaS gère consommation, alertes de solde et expiration. Séparez fonds du portefeuille et solde interne du membre. Voir le guide des notifications.
Renouveler ne signifie pas prélever automatiquement
Payer un lien est un renouvellement actif. Une adresse permanente n’autorise pas de prélèvement périodique sur le portefeuille client. Les plugins ne proposent pas de prélèvement récurrent ; WHMCS reste une version de test sans prélèvement automatique de renouvellement.
Votre application peut produire factures, rappels ou débits sur un solde interne déjà alimenté, selon des règles claires. Voir les limites dans le guide des plugins.
Reprendre les notifications et paiements atypiques
Sans callback, interrogez orderNo et vérifiez avant de reprendre le traitement métier. Paiements insuffisants, excédentaires, tardifs ou sur facture annulée exigent un contrôle. Si la création expire sans numéro, vérifiez le résultat ; la référence métier ne garantit pas une répétition idempotente.
- Aucun accès sans paiement, avec signature invalide ou montant incorrect.
- Un callback répété produit un paiement et une modification des droits.
- Vérifiez les effets déjà appliqués après une interruption.
- Testez factures et recharges séparément ; gardez les API Keys côté serveur.
Vérifier capacités et coûts
Choisissez via l’API USDT et les adresses dédiées. Consultez forfaits, quotas et frais dans les tarifs. Utilisez le SDK Node.js ou PHP / Laravel côté serveur.