API de passerelle de paiement crypto : 12 points à vérifier avant d'intégrer
Toute API de paiement crypto sait créer une facture. Les différences apparaissent avec les relances, les paiements partiels et les webhooks ratés. Une checklist en 12 points pour développeurs, avec la réponse de l'API mistKET à chacun.
Toute API de passerelle de paiement crypto promet la même chose : créer une facture, être payé, recevoir un callback. Les différences n'apparaissent que plus tard — quand deux requêtes se croisent, quand un client envoie un peu moins que le montant, quand votre serveur tombe pendant une heure ou quand un attaquant rejoue une requête interceptée. Bien choisir l'API fait gagner bien plus de temps que l'intégrer vite.
Voici une checklist pour les développeurs et CTO qui comparent des API de paiement crypto avant d'écrire la moindre ligne de code. Pour chaque point : quoi vérifier, pourquoi c'est important et comment l'API mistKET le gère. Si votre choix est fait et que vous voulez le code pas à pas, lisez notre guide d'intégration d'une API de paiement crypto.
Les endpoints minimum
Une API de paiement crypto exploitable doit offrir plus qu'un « créer un paiement ». Au minimum :
| Fonction | Pourquoi elle est nécessaire | Endpoint mistKET |
|---|---|---|
| Créer une facture | Une demande de paiement par commande, avec expiration | POST /invoices |
| Lire une facture | Rapprocher quand un webhook a été manqué | GET /invoices/{uuid} |
| Lister et filtrer | Back-office et rapprochement nocturne | GET /invoices |
| Annuler une facture | Libérer le stock d'une commande abandonnée | POST /invoices/{uuid}/cancel |
| Actifs pris en charge | N'afficher que les réseaux payables maintenant | GET /assets |
| Cotation du taux | Afficher le montant crypto avant de créer la facture | GET /rate |
| État du service | Supervision et repli propre | GET /health |
Si un prestataire ne permet pas de lire ou de lister les factures, vous devez faire une confiance aveugle aux webhooks — une mauvaise position dès la première livraison ratée.
1. Authentification : chaque requête est-elle signée ?
Une simple clé API dans un en-tête est l'option la plus faible : quiconque l'intercepte ou la récupère peut créer et annuler des factures. Préférez une API où chaque requête est signée avec un secret qui ne transite jamais sur le réseau. Les requêtes mistKET portent X-Api-Key, X-Api-Timestamp et une signature HMAC-SHA256 du timestamp et du corps brut. Le secret n'est affiché qu'une seule fois dans le panneau marchand.
2. Protection contre le rejeu
Une signature seule n'empêche pas de renvoyer une requête capturée. Cherchez une fenêtre de timestamp et la prise en charge d'un nonce. mistKET refuse les timestamps décalés de plus de ±300 secondes et n'accepte pas deux fois la même signature pour les requêtes qui modifient l'état. La version 2 de la signature ajoute un nonce par requête et signe aussi la méthode et le chemin : une signature ne peut pas être réutilisée sur un autre endpoint.
3. Idempotence à la création de facture
Les réseaux expirent. Si votre checkout relance un appel « créer une facture », vous ne devez pas vous retrouver avec deux factures pour une commande. Une bonne API propose une clé d'idempotence. Chez mistKET, votre propre order_id joue ce rôle : un nouvel appel avec le même numéro de commande renvoie la facture existante avec "idempotent": true au lieu d'en créer une autre.
4. Des statuts qui couvrent les vrais paiements
« Payé / non payé » ne suffit pas. Des clients envoient un peu moins parce que leur exchange a prélevé des frais, ou trop, ou paient après l'expiration. Vérifiez que l'API expose ces cas explicitement. Les factures mistKET passent par new, pending, underpaid, paid, confirmed, overpaid, expired et cancelled, avec des champs comme paid_amount, remaining_amount, can_pay_remaining et under_review : votre code n'a jamais à deviner.
paid signifie que le transfert est détecté et attend ses confirmations ; ne livrez que sur confirmed ou overpaid.5. Des confirmations visibles
L'API doit indiquer le nombre de confirmations de bloc obtenues et requises, ainsi que le hash de transaction et un lien vers l'explorateur. Les tickets de support sur un paiement deviennent alors de simples vérifications. mistKET renvoie confirmations, required_confirmations et un tableau transactions[] avec hash, montant, statut et URL d'explorateur pour chaque facture.
6. Blocage du taux et devises de prix
Vous fixez vos prix en monnaie fiat ; le client paie en crypto. Demandez quelles devises sont acceptées et combien de temps le taux est garanti. mistKET accepte des prix en USD, EUR, TRY, RUB, GBP et AED (ou directement dans le symbole crypto), bloque le taux pendant toute la durée de la facture et vous laisse régler cette durée entre 5 et 1 440 minutes par facture.
7. Choix du réseau
Pouvez-vous imposer le réseau dans l'appel API, ou laisser le client choisir sur la page hébergée ? Les deux sont utiles : imposer convient aux bots et aux flux automatisés, laisser choisir réduit les paiements envoyés sur le mauvais réseau. mistKET permet les deux via pay_currency + network ou asset_id, et GET /assets indique available: false quand un réseau n'a pas d'adresse libre. L'USDT sur TRON (TRC-20) est activé aujourd'hui ; d'autres actifs et réseaux sont activés par marchand sur demande. Voir USDT TRC20 ou ERC20 pour comprendre pourquoi TRON est le choix par défaut le plus courant.
8. Des webhooks signés, relancés et traçables
C'est sur les webhooks que la plupart des intégrations cassent. Vérifiez quatre points : la charge utile est signée, un timestamp permet de rejeter les livraisons périmées, les échecs sont relancés pendant des heures (pas des secondes) et chaque livraison porte un identifiant pour dédoublonner. mistKET signe les webhooks avec un secret dédié, envoie les en-têtes X-Mistket-Delivery et X-Mistket-Event, et relance les réponses non-2xx à 10 s, 30 s, 2 min, 10 min, 30 min, 1 h, 2 h et 3 h, avec l'historique des livraisons visible dans le tableau de bord. Notre article sur les webhooks de paiement crypto détaille la conception du handler.
9. Erreurs et limites documentées
Vous devez savoir à l'avance à quoi ressemblent une mauvaise signature, une IP bloquée ou une erreur de validation. mistKET renvoie un corps cohérent { "success": false, "error": … } avec le détail par champ pour les erreurs de validation, utilise des codes standard (401, 403, 404, 422, 429, 503) et documente sa limite : 120 requêtes par minute et par clé API.
10. Contrôles au niveau réseau
Avec une liste d'IP autorisées, une clé divulguée est inutilisable ailleurs que depuis vos serveurs. mistKET vous permet d'en définir une dans le tableau de bord ; les requêtes venant d'autres adresses reçoivent 403. Associée aux requêtes signées et à une fenêtre de timestamp courte, elle ferme les voies d'attaque les plus courantes.
11. Pas de dépendance à un SDK
Les SDK sont pratiques jusqu'au jour où ils ne suivent plus votre version de langage. Une API en HTTPS et JSON simples, où la signature tient en un appel HMAC, fonctionne depuis PHP, Node.js, Python, Go ou un script shell. mistKET publie des clients prêts à copier pour PHP, Node.js et Python dans sa documentation API, mais aucun n'est obligatoire.
12. Une voie manuelle pour les non-développeurs
Même une entreprise « API first » doit parfois facturer un client ponctuel. Vérifiez que les factures peuvent aussi être créées dans un panneau et partagées sous forme de lien, pour que les ventes et le support n'aient pas à solliciter les développeurs. Chez mistKET, les mêmes factures sont disponibles dans le panneau marchand et chaque page de paiement hébergée fonctionne comme un lien de paiement.
GET /invoices/{uuid} et comparez. Vous validez en une seule fois votre signature, votre handler de webhook et votre rapprochement.Signaux d'alerte en évaluant une API de paiement crypto
- Webhooks non signés ou « protégés » uniquement par une URL secrète.
- Impossible de relire une facture après sa création.
- Pas de statut sous-payé ou surpayé — les cas limites finissent dans le chat du support.
- Relances limitées à quelques minutes, ou aucun journal de livraison.
- Limites de débit et formats d'erreur non documentés.
- Tarification peu claire par transaction — comparez avec notre guide des frais de passerelle de paiement crypto.
Obtenir un accès à l'API mistKET
Les marchands sont intégrés par l'équipe mistKET : écrivez à @mistnetwork sur Telegram avec votre site, votre type d'activité et votre volume attendu. Une fois approuvé, vous créez votre clé API, votre secret et vos réglages de webhook dans le panneau marchand. Une intégration type prend un après-midi.
Consultez la section développeurs, les tarifs et la référence API complète avant de commencer.
