Binance Smart Chain API pour paiements BNB et BEP-20
Envoyez et recevez du BNB et des tokens BEP-20 via une seule API REST. Créez des adresses de dépôt, recevez des webhooks signés HMAC, et passez en production sur BSC sans faire tourner de node.
L'API Binance Smart Chain de Chaingateway déplace du BNB et des tokens BEP-20 via de simples appels REST. Votre backend crée des adresses de dépôt via HTTPS et envoie des tokens avec une seule requête POST. Quand un client paie, un webhook atteint votre serveur, cadencé sur les blocs infra-seconde de BSC. Il n'y a aucune node à faire tourner et aucune bibliothèque web3 à installer : l'authentification est un jeton Bearer dans l'en-tête Authorization, et chaque réponse est en JSON.
L'inscription prend une minute. L'essai dure 7 jours, ne coûte rien et ne demande aucun KYC. Créez une clé API et envoyez votre première transaction testnet dès aujourd'hui.
Tout ce dont vous avez besoin pour développer sur Binance Smart Chain
Webhooks (IPN)
BSC produit un bloc environ toutes les 0,75 seconde depuis l'entrée en vigueur du hardfork Maxwell le 30 juin 2025, et les notifications de dépôt suivent le même rythme. Quand un transfert BEP-20 atteint l'une de vos adresses, Chaingateway appelle votre endpoint avec le payload décodé. Définissez un secret personnel dans votre profil et chaque appel porte un en-tête X-Signature pour que vous puissiez vérifier l'expéditeur. Si votre endpoint était en panne, les livraisons échouées sont listées par l'API et renvoyées en un appel par notification.
Transactions faciles
Une requête POST envoie du BNB (POST /api/v2/bsc/transactions) ou n'importe quel token BEP-20 (POST /api/v2/bsc/transactions/bep20). Gas et nonce sont des champs de requête optionnels que l'API renseigne, donc vous n'ajustez jamais manuellement des valeurs de gwei ni ne suivez de nonces à travers des paiements concurrents.
Gestion sécurisée des adresses
BSC utilise le même format d'adresse 0x et la même checksum EIP-55 qu'Ethereum. L'API valide chaque adresse avant qu'une transaction ne soit construite, et l'architecture est non-custodial : vos clés restent les vôtres. Si vous gérez déjà des paires de clés, enregistrez-les avec POST /api/v2/bsc/addresses/import.
Requêtes décodées
Les logs bruts de BSC sont des blobs hex. L'endpoint de transaction décodée de Chaingateway retourne à la place du JSON lisible — expéditeur, destinataire et montant en champs simples — et les payloads de webhook arrivent décodés de la même façon.
Une API REST, pas un autre endpoint RPC
Si vous avez cherché « Binance Smart Chain RPC », vous vous attendiez probablement à une URL de node. La documentation officielle sur docs.bnbchain.org liste des endpoints JSON-RPC publics, et ils fonctionnent. Mais ils vous laissent la partie difficile. Une connexion RPC brute comprend eth_call et eth_sendRawTransaction ; l'encodage ABI et la gestion du nonce se font dans votre code, tout comme la gestion des clés. Les endpoints publics limitent aussi agressivement sous charge, exactement au moment où votre système de paiement en a le plus besoin.
Chaingateway se situe un niveau plus haut. Vous dites à l'API quel token envoyer, combien et à qui. Elle construit la transaction et la diffuse au réseau ; chaque transaction créée via l'API est listée, hash inclus, sous GET /api/v2/bsc/transactions, si bien que vous pouvez rediriger vos utilisateurs directement vers BscScan.
Le compromis est honnête : si vous avez besoin d'appels de contrat arbitraires ou de requêtes de profondeur archive, faites tourner une node ou utilisez un fournisseur RPC. Si vous avez besoin de paiements, c'est-à-dire des dépôts entrants et des paiements sortants, la couche REST retire la majeure partie du code que vous devriez autrement écrire et maintenir vous-même.
Référence des endpoints BSC
La documentation officielle BNB Chain répond à la question RPC avec une liste de quinze méthodes JSON-RPC et une URL de node publique. Cette liste décrit le protocole. Une intégration de paiement a besoin de quelque chose de plus court. Cinq endpoints couvrent toute la boucle chez Chaingateway :
| Méthode | Endpoint | Ce qu'il fait |
|---|---|---|
POST | /api/v2/bsc/addresses/import | Enregistrer une clé privée existante pour que l'API puisse envoyer depuis cette adresse |
POST | /api/v2/bsc/transactions | Construire, signer et diffuser un transfert BNB natif |
POST | /api/v2/bsc/transactions/bep20 | Construire, signer et diffuser un transfert de token BEP-20 |
GET | /api/v2/bsc/webhooks/notifications | Lister chaque notification de dépôt envoyée par l'API à votre serveur |
GET | /api/account | Vérifier votre compte et le statut de votre forfait |
Chacun d'eux accepte l'en-tête X-Network: testnet pour des essais à blanc, et chaque requête s'authentifie avec le même jeton Bearer. Les schémas exacts de requête et de réponse figurent dans la référence API.
Méthode JSON-RPC vs. un appel REST
Voici le même tableau du point de vue de l'intégrateur : ce qu'une tâche vous coûte contre une node brute, et ce qu'elle coûte contre la couche REST.
| Tâche à accomplir | JSON-RPC brut | Chaingateway |
|---|---|---|
| Envoyer 25 USDT | eth_gasPrice, eth_getTransactionCount, eth_estimateGas, eth_sendRawTransaction, plus encodage ABI et signature de transaction dans votre propre code |
Un seul POST /api/v2/bsc/transactions/bep20 |
| Détecter un dépôt | Sonder eth_blockNumber, scanner eth_getLogs pour des événements Transfer, décoder les topics et ajuster pour les décimales du token |
Un POST de webhook arrive à votre serveur |
| Auditer l'historique des dépôts | Construire et exploiter votre propre indexeur | GET /api/v2/bsc/webhooks/notifications |
Pour ressentir la différence, voici à quoi ressemble une conversation avec une node BSC publique :
curl -X POST https://bsc-dataseed.bnbchain.org \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'
La réponse est une chaîne hex. Tout ce qui vient après, de la conversion de 0x30bf8d3 en nombre à la récupération des logs et à la correspondance des montants bruts avec les décimales du token, est du code que vous écrivez et déboguez. Multipliez cela par chaque méthode dont vous avez besoin, et vous vous retrouvez avec un petit projet de middleware interne. L'appel REST saute le middleware parce qu'il est le middleware.
BSC en chiffres
BSC vise des blocs de 0,75 seconde depuis le hardfork Maxwell du 30 juin 2025, et le gas est resté bon marché, typiquement 0,1 à 1 gwei selon le tracker de BscScan. Un transfert BEP-20 standard consomme 50 000 à 65 000 de gas, ce qui à ces prix représente une fraction de centime.
Les faits sur les chaînes vieillissent vite, voici donc les chiffres plus complets avec des dates. Au début juillet 2026 :
La cible d'intervalle de bloc est de 0,75 seconde. Le hardfork Maxwell l'a fixée le 30 juin 2025, et BscScan a mesuré une moyenne d'environ 0,8 seconde peu après l'activation. Plus tôt en 2025, le hardfork Lorentz avait déjà réduit de moitié l'ancien intervalle de 3 secondes à 1,5 seconde, donc BSC a divisé par quatre son temps de bloc en une seule année.
Le gas est bon marché et l'est resté. Le tracker de gas de BscScan a oscillé dans la fourchette 0,1 à 1 gwei tout au long de 2026, avec une moyenne journalière d'environ 0,63 gwei en mars 2026. Un transfert BEP-20 standard consomme de l'ordre de 50 000 à 65 000 de gas, ce qui à ces prix représente environ 0,00004 BNB. Vérifiez vous-même le prix actuel du BNB avant de communiquer des frais à des clients, mais le résultat est resté à quelques centimes pendant des années.
Pour une page de checkout, la conséquence pratique est la suivante : le transfert USDT d'un client est dans un bloc en environ une seconde, et après une poignée de blocs supplémentaires, quelques secondes au total, vous pouvez créditer la commande. Comparez cela à Ethereum mainnet, où un seul slot prend 12 secondes.
Envoyer et recevoir n'importe quel token sur BSC, même le vôtre
Tout contrat BEP-20 standard fonctionne. USDT, USDC et DAI fonctionnent d'emblée, avec des montants en unités de token plutôt qu'en unités de base brutes. Si vous avez lancé votre propre token, passez son adresse de contrat au même endpoint et il se comporte comme n'importe quel autre. Comme l'API est identique sur toutes les chaînes, le code que vous écrivez pour BSC tourne aussi contre Ethereum, Polygon ou Arbitrum une fois que vous échangez le segment de chaîne dans l'URL.
Pourquoi les développeurs choisissent Binance Smart Chain
Les frais sur BSC sont bien inférieurs à ceux d'Ethereum mainnet, ce qui compte quand vous traitez de nombreux petits paiements plutôt que quelques gros. Des temps de bloc infra-seconde gardent les flux de checkout réactifs. L'écosystème DeFi autour de PancakeSwap donne aux tokens BEP-20 une liquidité profonde, et le réseau porte une forte activité quotidienne depuis des années, si bien que ses modes de défaillance sont bien compris et son outillage mature.
Quickstart : envoyer de l'USDT (BEP-20) en quatre langages
Tous les exemples appellent POST /api/v2/bsc/transactions/bep20 avec un jeton Bearer. L'adresse de contrat ci-dessous est l'USDT sur BSC (0x55d398326f99059fF775485246999027B3197955) ; password est le mot de passe du wallet protégé par mot de passe de l'adresse expéditrice. Le schéma exact de requête est dans la référence API. Pour tester sans fonds réels, ajoutez l'en-tête X-Network: testnet.
cURL
curl -X POST https://app.chaingateway.io/api/v2/bsc/transactions/bep20 \
-H "Authorization: Bearer $CHAINGATEWAY_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"contractaddress": "0x55d398326f99059fF775485246999027B3197955",
"from": "0xYourSenderAddress",
"to": "0xRecipientAddress",
"amount": 25.0,
"password": "wallet-password"
}'C'est la requête de transfert complète — créez un compte et exécutez-la d'abord sur BSC testnet.
Comment les dépôts BEP-20 atteignent votre backend
Une intégration de paiement sur BSC suit une boucle :
- Donnez à chaque utilisateur une adresse de dépôt. Si votre système gère déjà des clés, enregistrez-les avec
POST /api/v2/bsc/addresses/import. - Attachez un webhook à l'adresse. La configuration prend quelques minutes et est décrite dans le guide des webhooks.
- Le client envoie de l'USDT à l'adresse. Le transfert atterrit dans un bloc en environ une seconde, et Chaingateway POST l'événement décodé vers votre endpoint.
- Votre serveur vérifie la signature HMAC et crédite le compte. C'est tout le flux.
En production, trois détails séparent une démo d'un système que vous pouvez laisser tranquille.
Le premier est la correspondance d'adresse. Stockez une ligne par client ou par commande : votre identifiant interne, l'adresse de dépôt, la date de création. Quand un webhook arrive, l'adresse destinataire dans le payload est votre clé de recherche. Un index unique sur la colonne adresse signifie qu'un dépôt ne peut jamais être crédité à deux clients, quoi que fasse votre code autour.
Le second est l'idempotence. La livraison n'est pas exactement-une-fois : une notification échouée que vous renvoyez via l'API arrive à nouveau en entier. Enregistrez le hash de transaction de chaque dépôt traité avec une contrainte unique, et laissez la base de données rejeter les doublons. Une logique de crédit qui survit au même événement arrivant trois fois est la différence entre un mécanisme de re-livraison qui vous protège et un qui paie en double.
Le troisième est une politique de confirmation. Un webhook vous dit que le transfert est dans un bloc. Avec des blocs de 0,75 seconde, dix blocs supplémentaires arrivent en bien moins de dix secondes, donc attendre une petite marge de sécurité coûte presque rien en expérience utilisateur. Pour un achat numérique de 5 USDT, créditer sur la notification est une décision métier raisonnable. Pour un dépôt de 50 000 USDT, attendez quelques secondes de plus et revérifiez la transaction (GET /api/v2/bsc/transactions/{txid}) avant de libérer quoi que ce soit.
Les dépôts s'accumulent aussi sur de nombreuses adresses au fil du temps. La réponse habituelle est un balayage périodique : une tâche planifiée qui envoie les soldes accumulés des adresses de dépôt vers votre wallet de trésorerie, en utilisant le même appel POST /api/v2/bsc/transactions/bep20 avec l'adresse de dépôt dans le champ from. Chaque adresse balayée a besoin d'un soupçon de BNB pour le gas, ce qui à des prix sous le gwei est une erreur d'arrondi.
Si votre endpoint était injoignable, les livraisons manquées ne sont pas perdues : GET /api/v2/bsc/webhooks/notifications/failed les liste, et POST /api/v2/bsc/webhooks/notifications/{id}/retry renvoie chacune. Pour la réconciliation, vous pouvez aussi lister tout ce que l'API vous a envoyé :
curl https://app.chaingateway.io/api/v2/bsc/webhooks/notifications \
-H "Authorization: Bearer $CHAINGATEWAY_API_KEY"
Cet unique endpoint transforme « avons-nous manqué un dépôt ? » d'un ticket de support en un diff contre votre propre base de données.
Paiements sortants : l'autre moitié de la boucle
Les retraits méritent le même soin que les dépôts, car un bug ici envoie de l'argent au lieu d'en manquer.
Valider avant d'envoyer
Le flux commence avant l'appel API. Validez l'adresse de destination dès que l'utilisateur la soumet : longueur correcte, préfixe 0x, et la checksum EIP-55 si des lettres mixtes sont présentes. Un échec de checksum signifie une faute de frappe, et l'attraper dans le formulaire ne coûte rien, tandis que l'attraper après diffusion est impossible. L'API rejette les adresses malformées avant de construire la transaction, mais le test de checksum vous appartient — et le temps que l'API réponde, l'utilisateur a quitté la page.
Suivre chaque paiement sortant dans votre base de données
Écrivez le paiement sortant dans votre base de données avant de l'envoyer. Une ligne par paiement, avec une colonne d'état : queued, sent, confirmed. Un worker récupère les lignes en attente, fait exactement un appel POST /api/v2/bsc/transactions/bep20 par ligne, et stocke la réponse API à côté. Le hash de transaction — votre reçu — apparaît dans GET /api/v2/bsc/transactions, la liste de tout ce qui a été créé via l'API. Montrez-le à l'utilisateur comme un lien BscScan et il peut suivre son propre retrait se confirmer, ce qui élimine discrètement le ticket de support le plus courant de cette catégorie.
Gérer les timeouts
Le cas d'échec qui compte est le timeout. Si votre appel API expire, vous ne savez pas si le transfert est sorti. Ne réessayez pas aveuglément. Vérifiez d'abord GET /api/v2/bsc/transactions et vos propres enregistrements, et ne renvoyez que lorsque vous êtes sûr que rien n'a été diffusé. Comme les paiements sortants proviennent d'un hot wallet, gardez un flottant de BNB sur l'adresse expéditrice pour le gas ; aux prix actuels de BSC, une petite recharge couvre des milliers de transferts, c'est donc une tâche mensuelle plutôt qu'un risque opérationnel.
Testez d'abord sur le testnet BSC
Chaque endpoint de cette page tourne contre le testnet BSC quand vous ajoutez un en-tête :
X-Network: testnet
Aucun second compte, aucune clé API séparée, aucun changement de code au-delà de l'en-tête. Le BNB testnet est gratuit via le faucet officiel de BNB Chain, si bien que vous pouvez répéter toute la boucle, de la création d'adresse au webhook de dépôt jusqu'au paiement sortant, sans fonds réels. Les formats d'adresse et la mécanique des transactions sont identiques au mainnet.
La répétition qui vaut la peine est la laide : envoyer un dépôt pendant que votre endpoint webhook est éteint, le remettre en ligne, puis renvoyer la livraison depuis la liste des échecs (POST /api/v2/bsc/webhooks/notifications/{id}/retry) et la voir arriver. Confirmez votre gestion de l'idempotence en rejouant une notification contre votre propre endpoint. Dix minutes de test délibéré des échecs sur testnet épargnent une revue d'incident sur mainnet. Quand tout tient, supprimez l'en-tête et le même code est en production.
Sécurité des webhooks en pratique
Un endpoint webhook est une porte vers votre système comptable, traitez-le donc comme tel.
Vérifiez la signature avant de parser quoi que ce soit d'autre. Définissez un secret personnel dans vos paramètres de profil ; dès lors, Chaingateway envoie un en-tête X-Signature avec chaque notification — base64 d'un HMAC-SHA256 sur le txid du payload, avec ce secret comme clé. Votre serveur le recalcule à partir du txid reçu et compare à temps constant. Une requête qui échoue à la vérification reçoit un 4xx et aucun traitement ultérieur, quelle que soit la plausibilité de son payload. La mécanique, code de vérification inclus, est dans le guide des webhooks.
Un second verrou, distinct, garde l'autre direction : dans le panneau de compte, vous pouvez restreindre votre clé API aux adresses IP de vos propres serveurs. Cette liste blanche protège l'accès API — une clé fuitée ne déplace rien depuis ailleurs — pas l'endpoint webhook, elle complète donc la signature plutôt que de la remplacer.
Le rejeu est l'attaque que le HMAC seul n'arrête pas, puisqu'une notification valide enregistrée reste valide. Votre contrainte d'idempotence ferme cette brèche : un hash de transaction déjà crédité est acquitté et ignoré. Servez l'endpoint uniquement en HTTPS, et gardez l'URL du webhook exempte de secrets, car les URL finissent dans des logs sur des systèmes que vous ne contrôlez pas.
Quand les requêtes échouent
Toute intégration voit des erreurs tôt ou tard, et l'API les signale comme des codes de statut HTTP ordinaires, donc vos modèles de gestion d'erreur existants s'appliquent.
Un 401 signifie que le jeton Bearer est manquant, expiré ou faux ; vérifiez l'en-tête Authorization et la clé dans votre tableau de bord. Les échecs de validation dans la plage 4xx, comme une adresse malformée ou un champ manquant, viennent avec un corps JSON expliquant quoi corriger. Ne les réessayez pas : la même requête échouera de la même façon jusqu'à ce que le payload change.
Les limites de requête et d'adresse dépendent de votre forfait ; si vous les atteignez régulièrement, la page de tarification liste des forfaits avec des limites plus élevées. Les erreurs 5xx côté serveur et les timeouts sont sûrs à réessayer pour les requêtes de lecture. Pour les envois, appliquez la règle de timeout de la section paiements sortants : vérifiez que rien n'a été diffusé avant de soumettre à nouveau.
Loguez le corps de réponse complet à côté de votre propre enregistrement de requête. Quand quelque chose nécessite l'attention du support, cette association répond à la plupart des questions avant qu'elles ne soient posées. Les codes de statut et schémas d'erreur par endpoint sont documentés dans la référence API.
Se passer de votre propre node BSC
De nombreuses équipes font tourner une full node BSC pour exactement un but : surveiller les dépôts et diffuser des paiements sortants. Cette node coûte de l'argent réel et de l'attention. Les besoins de stockage se mesurent en téraoctets de NVMe, la synchronisation initiale prend des jours sans snapshot, et 2025 seule a apporté deux hardforks, Lorentz et Maxwell, chacun une mise à jour client obligatoire avec échéance. En manquer un et votre node cesse de suivre la chaîne, ce qui pour un système de paiement signifie que les dépôts s'arrêtent silencieusement d'arriver.
Si la node n'existe que pour les paiements, le chemin de migration est court. Importez vos clés existantes avec POST /api/v2/bsc/addresses/import, remplacez votre boucle de polling eth_getLogs par des notifications webhook, et pointez votre code de paiement sortant vers POST /api/v2/bsc/transactions/bep20. Faites tourner les deux systèmes en parallèle une semaine et comparez les résultats ; la liste de notifications transforme cette comparaison en une requête plutôt qu'un projet. Puis mettez la node hors service et récupérez le budget matériel.
Si vous voulez garder une node, ou si vous décidez d'en construire une, notre guide pour configurer une node Binance Smart Chain détaille honnêtement le matériel, la synchronisation et la maintenance. Les deux approches se combinent aussi : certaines équipes gardent une node pour les requêtes d'archive et les appels de contrat tout en acheminant le trafic de paiement via l'API, car la couche webhook de l'API est la partie véritablement fastidieuse à reconstruire.
Conçu pour tous les cas d'usage
La plupart des équipes sur les endpoints BSC de Chaingateway font tourner l'un de deux schémas. Le premier est l'acceptation de paiements : une boutique ou un SaaS génère une adresse de dépôt par commande, attend le webhook et expédie le produit, avec un règlement en secondes plutôt qu'en jours ouvrés bancaires. Le second est les opérations de wallet à grande échelle : plateformes d'échange et plateformes qui surveillent les dépôts et traitent les retraits sur des milliers d'adresses utilisateur, tout via les mêmes quelques endpoints.
Les mêmes briques couvrent les lancements de tokens (airdrops et paiements de vesting scriptés comme des transferts BEP-20), les transferts transfrontaliers là où un virement prendrait des jours, les paiements récurrents pour la facturation par abonnement, et les produits DeFi qui doivent voir les transactions dès qu'elles se confirment.
Intégration en trois étapes
Obtenez votre clé API. Inscrivez-vous et la clé est immédiatement dans votre tableau de bord. L'essai de 7 jours démarre sans KYC.
Effectuez votre première requête. Le quickstart vous guide de l'inscription à une première transaction.
Configurez les webhooks et passez en production. Les dépôts poussent vers votre serveur au lieu que vous les sondiez — le guide des webhooks couvre la configuration et la vérification de signature — puis retirez l'en-tête X-Network: testnet et le même code tourne contre mainnet.
Tarification
Les forfaits et leurs limites sont listés sur la page de tarification. Chaque nouveau compte démarre avec l'essai gratuit de 7 jours, si bien que vous pouvez finir toute l'intégration BSC avant de payer quoi que ce soit.
Ce qui fonctionne sur quelle chaîne
BSC suit le même schéma de requête qu'Ethereum, avec BEP-20 à la place d'ERC-20. Le tableau ci-dessous le place à côté des six autres chaînes couvertes par l'API.
| 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.
Questions fréquentes
Prêt à intégrer Binance Smart Chain ?
Créez votre compte, copiez la clé API et envoyez une transaction testnet dans les dix prochaines minutes. La référence complète des endpoints est sur /docs/, et le portail développeur rassemble des tutoriels pour les flux de paiement les plus courants.