Suivez une facture de la sélection à la confirmation

Les sélections de paiement sont BTC, ETH, SOL, LTC et TRX sur leurs réseaux natifs, USDT sur Ethereum ERC-20 ou TRON TRC-20, et USDC uniquement sur Ethereum ERC-20. Ce sont huit routes réparties sur sept actifs. Monero, USDC sur TRON, Lightning, les cartes et autres réseaux de jetons ne sont pas proposés.

Le serveur indique le montant total complet de la commande USD dans l'actif sélectionné, avec un horodatage du taux et une expiration explicite affichée lors du paiement. Lisez ensemble l'adresse, l'actif, le réseau et le montant exact. L'adresse de réception est fixe plutôt que générée pour chaque facture ; une référence de commande doit être explicitement associée à une transaction vérifiée. N'inventez pas de mémo et ne supposez pas qu'un montant seul identifie uniquement une commande. Les frais de réseau ou de retrait du portefeuille restent séparés du total de la commande.

Les seuils du backend sont BTC 2, LTC 6, ETH et USDT/USDC ERC-20 12, natif TRX et USDT TRC-20 20, et SOL 1, avec un statut finalisé vérifié indépendamment requis. Les délais de confirmation dépendent des conditions du réseau. Aucun moniteur connecté ne détecte actuellement ces transactions ni ne fournit de mises à jour de confirmation ; le timing de la chaîne ne constitue pas une garantie de livraison.

Conservez la référence de commande et l’identifiant de transaction du portefeuille. Si un devis impayé expire avant toute observation, actualisez-le via le paiement. Si une transaction est déjà observée ou si le montant, le réseau ou la destination est incorrect, demandez à la facturation de rapprocher les preuves. N’écrasez pas un paiement observé par un nouveau devis et ne soumettez pas automatiquement un second virement.

Le paiement authentifié affiche l'adresse de réception fixe configurée, le réseau sélectionné, le montant exact en cryptomonnaie et l'expiration du devis. Les taux USD sont obtenus par le serveur. Aucun moniteur de transaction blockchain n'est connecté : la détection et la confirmation nécessitent une intégration backend de confiance. Un état de paiement ne crée pas de serveur réel ni de droit à un service. Les conditions de remboursement restent une proposition de lancement : elles utilisent l'actif d'origine et la valeur de paiement USD initiale au taux de remboursement actuel, avec l'éligibilité des produits et les déductions expliquées séparément.

Une commande commence pending_crypto avant qu’une méthode ne soit sélectionnée. Une demande peut attendre un devis, attendre le paiement, expirer, être observée ou être confirmée. La vérification côté serveur peut également signaler un sous-paiement ou un surpaiement. Un résultat payé enregistre la vérification du paiement ; il n’alloue pas d’infrastructure.

• awaiting_quote : un tarif de serveur valide n'est pas encore disponible.
• awaiting_payment : un devis exact et les instructions de réception sont disponibles.
• detected / confirming : un observateur de confiance a associé une transaction, la vérification étant toujours en cours.
• underpaid / overpaid : le montant observé nécessite une réconciliation.
• payé : paiement vérifié, l’exécution du service restant distincte.