Une blockchain API pour les paiements crypto, sept chaînes
Acceptez et envoyez des paiements crypto sur Bitcoin, Ethereum, TRON, Solana, BNB Smart Chain, Polygon et Arbitrum. Une seule API REST pour les wallets, les transferts de tokens et les webhooks de dépôt.
Chaingateway est une API REST pour les paiements blockchain. Vous générez des adresses de wallet et envoyez des tokens avec de simples appels HTTPS, et quand un dépôt atteint une de vos adresses, un webhook notifie votre serveur en temps réel. La même API couvre Bitcoin, Ethereum, TRON, Solana, BNB Smart Chain, Polygon et Arbitrum.
Cette couverture compte plus que n'importe quelle fonctionnalité isolée. La plupart des API blockchain gèrent un réseau ; les équipes qui ajoutent une seconde chaîne finissent généralement avec une seconde base de code, parce que chaque réseau a son propre format RPC et ses propres bibliothèques client. Chaingateway supprime cette scission. La route pour un transfert ERC-20 sur Ethereum est POST /api/v2/ethereum/transactions/erc20 ; sur Polygon c'est POST /api/v2/polygon/transactions/erc20. Changez un segment de chemin et votre code existant tourne sur la chaîne suivante.
Il n'y a aucune node à synchroniser ni de SDK à installer. L'authentification est un jeton Bearer dans l'en-tête Authorization. Un en-tête supplémentaire, X-Network: testnet, pointe n'importe quel appel vers le réseau de test plutôt que le mainnet. Un essai gratuit de 7 jours démarre sans KYC.
Ce que couvre l'API
Wallets et adresses
Créez des wallets protégés par mot de passe pour Ethereum, BSC, Polygon et TRON, ou apportez des clés existantes via des endpoints d'import comme POST /api/v2/ethereum/addresses/import. Les clés privées sont stockées chiffrées avec un mot de passe que vous seul connaissez — Chaingateway ne conserve ni clés ni mots de passe en clair, donc sans vos identifiants, les fonds restent immobiles. Les adresses Solana proviennent de POST /api/v2/solana/addresses. Pour les produits de paiement, le schéma habituel est une adresse par client ou par facture, ce qui rend l'attribution triviale : ce qui arrive sur l'adresse X appartient au client X, sans correspondance par montant ou mémo.
Transactions natives et de tokens
Envoyez ETH, BNB, POL, TRX ou BTC en un seul appel, et déplacez des tokens ERC-20, BEP-20, TRC-20 et SPL via la même interface. Gas, prix du gas et nonce sont des champs de requête optionnels — omettez-les et l'API les renseigne, si bien que vous transmettez un destinataire et un montant plutôt que d'assembler des transactions brutes. Les montants sont en unités de token, pas en unités de base : 100 signifie 100 tokens de l'adresse de contrat que vous fournissez. TRON va plus loin que les autres chaînes : les endpoints freeze et delegate couvrent le staking (avec unfreeze et undelegate pour inverser), et TRC-10 côtoie TRC-20.
Données blockchain décodées
Les réponses reviennent en JSON lisible, pas en hex. Une transaction TRON décodée inclut l'expéditeur, le destinataire, le montant en unités de token, le numéro de bloc et le nombre de confirmations actuel. C'est ce qu'une API de données blockchain devrait retourner : des valeurs que votre application peut stocker et afficher sans parseur ABI.
Webhooks pour les paiements entrants
Abonnez-vous aux événements on-chain et recevez une notification dès qu'un dépôt se règle on-chain. Définissez un secret personnel dans votre profil et chaque notification porte un en-tête X-Signature que votre serveur peut vérifier. Les livraisons échouées sont listées par l'API et peuvent être renvoyées en un seul appel.
Ce qui fonctionne sur quelle chaîne
Le tableau condense la référence API actuelle en une seule vue : quelles chaînes ont des routes d'adresse, quels standards de token vous pouvez envoyer, et où les webhooks de dépôt sont documentés.
| Chaîne | Adresses | Transferts de tokens | Webhooks de dépôt |
|---|---|---|---|
| Bitcoin | POST /api/v2/bitcoin/wallets/{wallet}/addresses | — (pas de standard de token) | GET /api/v2/bitcoin/webhooks/notifications |
| Ethereum | POST /api/v2/ethereum/addresses/import | ERC-20 : POST /api/v2/ethereum/transactions/erc20 | GET /api/v2/ethereum/webhooks/notifications |
| TRON | POST /api/v2/tron/addresses/import | TRC-20 et TRC-10 : POST /api/v2/tron/transactions/trc20 et .../trc10 | GET /api/v2/tron/webhooks/notifications |
| Solana | POST /api/v2/solana/addresses | SPL : POST /api/v2/solana/transactions/SPL | — |
| BNB Smart Chain | POST /api/v2/bsc/addresses/import | BEP-20 : POST /api/v2/bsc/transactions/bep20 | GET /api/v2/bsc/webhooks/notifications |
| Polygon | POST /api/v2/polygon/addresses/import | ERC-20 : POST /api/v2/polygon/transactions/erc20 | GET /api/v2/polygon/webhooks/notifications |
| Arbitrum | POST /api/v2/arbitrum/addresses/import | ERC-20 : POST /api/v2/arbitrum/transactions/erc20 | GET /api/v2/arbitrum/webhooks/notifications |
Deux notes de bas de page pour bien lire le tableau. D'abord : TRON est l'intégration la plus complète de la plateforme. Au-delà des routes ci-dessus, la référence documente le staking (POST /api/v2/tron/freeze et /delegate), les paramètres de chaîne, et une paire d'auto-signature — /transactions/trc20/build pour construire une transaction et /transactions/broadcast pour en soumettre une que vous avez signée localement. Si votre équipe conformité insiste pour que les clés privées ne quittent jamais vos serveurs, ce schéma build-and-broadcast est votre porte d'entrée.
Ensuite : un tiret signifie que la référence actuelle ne documente pas de route v2 pour cette cellule, pas que le réseau est de seconde classe. Bitcoin n'a pas de standard de token, d'où la cellule token vide — le BTC natif passe plutôt par son propre modèle de wallet : créer un wallet chiffré par mot de passe avec POST /api/v2/bitcoin/wallets, dériver des adresses de dépôt en dessous, et envoyer avec POST /api/v2/bitcoin/transactions. La référence de Solana couvre la création d'adresse, les transferts SOL et SPL, et les recherches de solde et de bloc, mais pas encore les webhooks. Pour tout ce qui n'est pas listé ici, la référence API a l'état actuel.
Un exemple de blockchain API : le premier appel en quatre langages
Obtenez une clé API (section suivante), puis confirmez qu'elle fonctionne. GET /api/account retourne les détails de votre compte et prouve que la clé est valide.
curl https://app.chaingateway.io/api/account \
-H "Authorization: Bearer YOUR_API_KEY"C'est toute la vérification d'authentification — créez un compte et le même appel prouve que votre propre clé fonctionne.
Comment obtenir une clé de blockchain API
Inscrivez-vous sur app.chaingateway.io/register. L'essai de 7 jours démarre sans KYC.
Copiez la clé API depuis votre tableau de bord.
Envoyez-la avec chaque requête sous la forme Authorization: Bearer YOURAPIKEY, et gardez-la uniquement côté serveur. Du code côté client l'exposerait à quiconque ouvre la console du navigateur. Le panneau de compte peut en plus restreindre la clé aux adresses IP de vos propres serveurs, si bien qu'une clé fuitée est inutile ailleurs. D'autres étapes de durcissement figurent dans nos conseils de sécurité pour la blockchain API.
Recevoir des dépôts : le flux webhook
Une intégration de paiement ressemble généralement à ceci :
Créez ou importez une adresse de dépôt pour chaque client.
Le client envoie des pièces ou des tokens vers cette adresse.
Une fois le transfert réglé, Chaingateway POST une notification vers votre URL de callback — avec un en-tête X-Signature si vous avez défini un secret personnel.
Votre serveur vérifie la signature et crédite le compte client.
Sécurité des webhooks en pratique
Un endpoint webhook est une porte vers votre backend, et cette porte en particulier crédite de l'argent. Chaingateway vous donne trois mécanismes pour la protéger ; un handler de production devrait utiliser les trois. Cela s'applique aux six chaînes avec webhooks de dépôt — la détection de dépôt Solana utilise le polling à la place, couvert plus bas.
1. Vérifiez la signature
Définissez un secret personnel dans les paramètres de votre profil — dès lors, chaque notification porte un en-tête X-Signature, construit comme base64 d'un HMAC-SHA256 sur le champ txid du payload, avec ce secret comme clé. Recalculez-le à partir du txid reçu, comparez-le à la valeur de l'en-tête avant de créditer quoi que ce soit, et utilisez une comparaison à temps constant — la plupart des bibliothèques standards en fournissent une. Rejetez les échecs avec un 401. Cela ferme l'attaque évidente : quiconque découvre votre URL de callback peut y POST des dépôts fabriqués, et sans vérification de signature votre boutique expédierait des marchandises pour des paiements qui n'ont jamais eu lieu.
2. Concevez pour la re-livraison
Une notification peut vous atteindre plus d'une fois — vous pouvez renvoyer celles qui ont échoué via l'API, et rien ne garantit une livraison exactement-une-fois entre-temps. Faites dépendre votre logique de crédit du hash de transaction plutôt que du nombre de callbacks reçus — un INSERT ... ON CONFLICT DO NOTHING sur la colonne hash coûte une ligne et élimine toute la classe de bugs de double crédit. Répondez avec un 2xx dès que la notification est persistée et faites le traitement lent ensuite ; un handler qui fait du travail lourd en ligne rencontre des timeouts et transforme un dépôt en cas de support.
3. Utilisez les routes de récupération
Si votre endpoint était en panne ou a répondu avec une erreur, la livraison atterrit sur la liste des échecs : GET /api/v2/{chain}/webhooks/notifications/failed montre ce qui n'est pas passé, et POST /api/v2/{chain}/webhooks/notifications/{id}/retry renvoie chacune sur votre commande. Pour tout le reste — un basculement de base de données, un mauvais déploiement, un certificat TLS expiré — GET /api/v2/{chain}/webhooks/notifications retourne l'historique complet de livraison, si bien qu'une tâche de réconciliation nocturne peut le comparer à votre registre et réparer les écarts. Les détails du payload et le code de vérification sont dans le guide des webhooks.
Testez en testnet, livrez le même code
Chaque route accepte un en-tête supplémentaire, X-Network: testnet, et tourne contre le réseau de test plutôt que le mainnet. Endpoints, corps de requête et formes de réponse restent identiques ; les pièces sont sans valeur. Cette dernière propriété est l'essentiel. Vos tests d'intégration peuvent créer des adresses, déplacer des tokens et recevoir des webhooks toute la journée sans toucher de vrais fonds.
Une configuration pratique ressemble à ceci. Placez l'en-tête derrière une variable d'environnement, pour que le staging l'envoie et la production non — aucune différence de code entre les deux. Donnez au staging sa propre URL de callback, sinon les dépôts de test atterrissent dans votre handler webhook de production et brouillent le registre. Les pièces de test sont gratuites via les faucets publics que fait tourner chaque écosystème ; la page des réseaux supportés dans la documentation nomme le réseau de test par chaîne — Sepolia pour Ethereum, Nile pour TRON, Amoy pour Polygon, testnet3 pour Bitcoin.
Quand le flux fonctionne de bout en bout — adresse créée, dépôt détecté, webhook vérifié, solde crédité — supprimez l'en-tête. Rien d'autre ne change. Cette symétrie est délibérée, et c'est pourquoi passer en production est un changement de configuration plutôt qu'un second projet d'intégration.
Trois intégrations, expliquées pas à pas
Les listes de fonctionnalités disent peu sur l'effort d'intégration, voici donc trois constructions que nous voyons souvent, chacune réduite à ses rouages.
Dépôts pour une boutique en ligne
Une boutique veut accepter l'USDT au checkout. Quand un client choisit la crypto, votre backend assigne une adresse pour cette commande et l'affiche à côté du montant. À partir de là, le webhook fait le travail. La notification arrive une fois le transfert réglé on-chain ; marquez la commande « paiement détecté » et montrez-le au client, car un retour rapide est ce qui rend le checkout crypto digne de confiance. Si votre politique veut plus de profondeur pour les montants plus élevés, vérifiez la transaction avec GET /api/v2/{chain}/transactions/{txid} jusqu'à atteindre votre seuil, puis marquez la commande payée et démarrez le traitement.
Deux cas limites décident si cette construction est prête pour la production. Le sous-paiement : les clients envoient parfois un peu moins que la facture, généralement parce que leur wallet a déduit les frais réseau du montant saisi. Décidez la tolérance à l'avance — absorber un petit manque, ou retenir la commande et demander la différence. Le surpaiement est plus rare et plus simple : créditez-le ou remboursez-le, mais loguez-le dans les deux cas. Les deux cas découlent de la comparaison du montant notifié avec le montant de la facture plutôt que de traiter n'importe quel callback comme « payé ».
Paiements sortants en lot
Une plateforme d'affiliation paie des centaines de partenaires en stablecoins chaque mois, sur Polygon parce que les frais y restent faibles par rapport aux montants versés. La construction est une file et une boucle :
import requests
payouts = load_pending_payouts() # [{"address": ..., "amount": ...}, ...]
for p in payouts:
r = requests.post(
"https://app.chaingateway.io/api/v2/polygon/transactions/erc20",
headers={"Authorization": "Bearer YOUR_API_KEY"},
json={
"contractaddress": "0xTokenContract...",
"from": "0xTreasuryWallet...",
"to": p["address"],
"amount": p["amount"],
"password": "treasury-wallet-password",
},
)
record_result(p, r.json()) # persister avant l'itération suivante
La file compte plus que la boucle. Persistez l'état de chaque paiement avant de l'envoyer, stockez la réponse API immédiatement, et ne renvoyez jamais un envoi juste parce que l'appel HTTP a expiré — la transaction a peut-être quand même abouti. Vérifiez vos résultats stockés et GET /api/v2/polygon/transactions, qui liste chaque transaction créée via l'API, puis ne renvoyez que ce qui n'a manifestement jamais eu lieu. Cette seule règle sépare les systèmes de paiement qui survivent aux audits de ceux qui finissent en archéologie de tableur.
Facturation on-chain pour un SaaS
Un outil B2B facture ses clients mensuellement en stablecoins parce que les processeurs de carte continuent de rejeter sa catégorie de marchand. La construction réutilise le schéma de la boutique avec une variante : une nouvelle adresse de dépôt par facture, pas par client. Une adresse par facture rend la correspondance triviale — tout montant arrivant sur l'adresse de la facture 4711 appartient à la facture 4711 — et supprime les conjectures lors de la correspondance des paiements par montant quand deux factures totalisent par hasard la même somme. Le webhook marque les factures payées ; une tâche planifiée fait expirer les anciennes et envoie des rappels. Rien dans ce flux ne nécessite d'interface wallet, d'extension navigateur ou de connaissance crypto côté client au-delà de la capacité à envoyer un transfert.
Blockchains supportées
Chaque chaîne a sa propre page avec endpoints et exemples de code :
- Bitcoin API — la chaîne originelle. Transferts BTC natifs depuis des wallets chiffrés par mot de passe, plus des webhooks de dépôt pour les paiements entrants.
- Ethereum API — la plateforme de smart contracts la plus largement adoptée, avec transferts de tokens ERC-20 et support des NFT ERC-721.
- TRON API — transactions TRC-10 et TRC-20, staking via freeze et delegate, et routes d'auto-signature build/broadcast. Estimez les coûts de transfert à l'avance avec le calculateur de frais TRON.
- Solana API — création d'adresse et transactions de tokens SPL sur une chaîne à haut débit.
- BNB Smart Chain API — transferts BEP-20 avec le même schéma de route que sur Ethereum.
- Polygon API — transferts ERC-20 sur la chaîne de scaling d'Ethereum, pour une fraction des coûts de gas du mainnet. C'est la blockchain API Polygon, pas le service de données boursières Polygon.io.
- Arbitrum API — L2 Ethereum pour un débit élevé, partageant la disposition des endpoints du mainnet.
Migrer de JSON-RPC vers REST
Une blockchain API remplace les appels JSON-RPC bruts par une seule requête REST authentifiée par action. Là où JSON-RPC nécessite plusieurs allers-retours par transfert, plus un encodage ABI manuel, un suivi de nonce et une signature, un appel comme POST /api/v2/{chain}/transactions/erc20 (bep20 sur BNB Smart Chain) réduit tout cela à une seule requête.
Beaucoup d'équipes arrivent ici avec une intégration déjà en fonctionnement : web3.js contre un endpoint RPC payant, ou un client JSON-RPC fait maison issu d'une époque antérieure de la base de code. La migration est moins spectaculaire qu'il n'y paraît, car l'API absorbe des catégories entières de code plutôt que de remplacer appel par appel.
Prenez le chemin d'envoi EVM canonique. Via JSON-RPC, un transfert de token est une séquence : eth_getTransactionCount pour le nonce, eth_gasPrice ou un appel fee-history pour la tarification, eth_estimateGas contre du calldata encodé en ABI, signature locale, puis eth_sendRawTransaction pour diffuser. Chaque étape a des modes d'échec que votre code gère actuellement — ou pas, silencieusement. Les cinq se réduisent à un seul POST authentifié vers /api/v2/{chain}/transactions/erc20, et la comptabilité de nonce, source habituelle des tickets « transaction bloquée », quitte entièrement votre base de code.
La détection d'événements change de forme plus que de logique. Là où vous sondiez eth_getLogs avec un curseur de bloc ou mainteniez une souscription WebSocket ouverte à travers chaque bug de reconnexion, vous enregistrez maintenant un webhook et supprimez le poller. Votre logique en aval — parser le transfert, faire correspondre le client, créditer le solde — reste telle quelle ; seul le côté entrée bascule de pull à push.
Ce qui ne se transpose pas : les outils de consensus, les indexeurs personnalisés, tout ce qui nécessite un accès brut aux blocs. Gardez un endpoint RPC pour ces tâches ; les deux coexistent sans friction. Les paiements sont généralement la première charge de travail qui vaut la peine d'être déplacée, car ils portent le plus de risque opérationnel par ligne de code. La comparaison plus longue, y compris les cas où une node l'emporte, est dans blockchain API vs. blockchain node.
Quand une requête échoue
La gestion des erreurs pour une API de paiements mérite plus qu'un bloc catch générique, car une requête échouée et une transaction échouée sont des événements différents.
La couche HTTP suit les conventions REST. Un 401 signifie que le jeton Bearer est manquant, faux ou expiré — corrigez l'identifiant, ne réessayez pas. D'autres réponses dans la plage 4xx indiquent que la requête elle-même est en cause : une adresse malformée, un champ manquant, une erreur de validation. Loguez le corps de la réponse, qui nomme le problème spécifique, et traitez-les comme des bugs à corriger plutôt que des conditions transitoires à réessayer. La plage 5xx et les timeouts réseau forment la classe transitoire, où un nouvel essai avec backoff exponentiel est le bon réflexe.
Avec une exception, et c'est l'exception qui compte. Ne réessayez jamais aveuglément une requête qui déplace des fonds. Un timeout vous dit que vous n'avez pas reçu la réponse — pas que la transaction a échoué. La séquence sûre : vérifiez si le transfert est sorti, en utilisant vos résultats stockés et GET /api/v2/{chain}/transactions (la liste des transactions créées par votre clé), et ne renvoyez que lorsque vous pouvez démontrer que cela n'a jamais eu lieu. Des clés d'idempotence de votre côté, liées à vos propres identifiants de paiement ou de commande, rendent cette vérification peu coûteuse.
Intégrez l'observabilité dès le premier jour. Loguez les paires requête-réponse pour chaque appel qui déplace de l'argent, et alertez sur les taux de 4xx et pas seulement sur les 5xx — une soudaine rafale d'erreurs de validation signifie généralement qu'un déploiement a cassé votre format de requête. Le détecter en minutes plutôt qu'en jours fait la différence entre un incident et une note de bas de page.
Faire tourner ses propres nodes ou utiliser une API ?
Faire tourner des nodes vous-même vous donne un contrôle total et aucune dépendance à un tiers. Cela signifie aussi une machine par chaîne, des budgets de disque et de bande passante, une surveillance de synchronisation et des mises à jour de version — multiplié par sept si vous voulez la couverture décrite ci-dessus. Notre comparaison blockchain API vs. blockchain node parcourt ce compromis. En bref : faites tourner une node quand vous avez besoin d'un contrôle au niveau du consensus, utilisez l'API quand vous avez besoin que les paiements fonctionnent cette semaine.
Questions fréquentes
Prêt à accepter des paiements crypto ?
Créez un compte sur app.chaingateway.io/register, choisissez une chaîne parmi les sept ci-dessus et envoyez un transfert testnet. La référence complète des endpoints est dans la documentation, et les forfaits et limites de débit sont listés sur leur propre page.