Solana API : paiements SOL et tokens SPL via REST

La voie officielle vers Solana est JSON-RPC, documentée sur solana.com/docs/rpc. Elle expose le protocole de la node : des méthodes comme getLatestBlockhash et sendTransaction, plus une bibliothèque client pour les rendre utilisables. Pour envoyer un token SPL de cette façon, votre code récupère un blockhash récent avant son expiration, résout le compte de token associé du destinataire (et le crée s'il n'existe pas encore), puis construit, signe et sérialise la transaction. En JavaScript, web3.js et le paquet spl-token font cela pour vous. Dans tout autre langage, vous êtes largement livré à vous-même.

Chaingateway remplace cela par un seul appel HTTP. L'API résout les comptes de token et construit la transaction côté serveur, et votre backend n'importe jamais de SDK Solana. Si vous voulez un accès brut à la chaîne pour de l'analyse ou des programmes personnalisés, un fournisseur RPC est le bon outil. Pour les paiements, REST est plus court, et du code plus court a moins d'endroits où casser.

Si vous venez d'Ethereum, BSC ou Polygon, la partie de Solana la plus susceptible de vous mordre n'est ni la vitesse ni les frais. C'est le modèle de compte.

Le modèle EVM

Un solde de token est une entrée dans le stockage propre du contrat de token. Votre adresse « détient » de l'USDT parce que la table interne du contrat le dit. Envoyer des tokens à un tout nouveau wallet ajoute simplement une ligne à cette table ; le destinataire n'a pas besoin d'exister on-chain d'une façon spéciale.

Le modèle Solana

Solana divise la même idée en comptes séparés. Un token est défini par son compte mint, qui stocke l'offre et les décimales. Les soldes vivent dans des comptes de token, un par combinaison de wallet et de mint, et la variante standard est le compte de token associé (ATA) : son adresse est dérivée de façon déterministe à partir de l'adresse du wallet et de l'adresse du mint. Votre wallet ne contient pas d'USDC. Il possède un compte séparé qui contient de l'USDC.

Deux conséquences pour les paiements

1. Un ATA doit exister avant que des tokens puissent y atterrir. Si votre destinataire n'a jamais détenu le token, le compte doit être créé on-chain, et la création nécessite un dépôt pour le rendre exempt de loyer (rent-exempt) : 0,00203928 SOL mi-2026, selon la documentation officielle de Solana. En pratique, la transaction de l'expéditeur crée et finance le compte manquant.
2. Les transferts déplacent de la valeur entre comptes de token, pas entre adresses de wallet. Du code qui vise naïvement l'adresse du wallet échoue, c'est pourquoi l'instruction de transfert SPL prend les deux comptes de token plus le mint et ses décimales pour vérification.

C'est exactement cette comptabilité que Chaingateway fait côté serveur. Vous passez des adresses de wallet et un mint de token ; l'API dérive les comptes de token et construit un transfert valide. Votre backend n'apprend jamais ce qu'est une adresse dérivée de programme, ce qui est le but.

Les chiffres ci-dessous sont vérifiés contre la documentation officielle de Solana au début juillet 2026.

Un slot, la fenêtre pendant laquelle un validateur peut produire un bloc, est configuré à environ 400 millisecondes et fluctue en pratique entre environ 400 et 600 millisecondes. Cette cadence explique pourquoi le polling des dépôts toutes les une à deux secondes ne prend jamais beaucoup de retard sur la chaîne.

Les frais de transaction de base sont de 5 000 lamports par signature, soit 0,000005 SOL. La moitié est brûlée, l'autre moitié va au producteur de bloc. Par-dessus s'ajoutent des frais de priorité optionnels, tarifés en micro-lamports par unité de calcul ; ils sont nuls par défaut et achètent une préférence d'ordonnancement quand le réseau est chargé. Pour une charge de travail de paiement, la lecture pratique est simple : les frais sont si faibles qu'ils disparaissent dans votre marge même sur une transaction d'un dollar.

Confirmation et finalité sont des choses différentes sur Solana, et la distinction compte pour la façon dont vous créditez les dépôts. Une transaction est généralement confirmée, ce qui signifie qu'une supermajorité de validateurs a voté sur son bloc, en une à deux secondes. La finalité complète prend environ 12,8 secondes mi-2026. La mise à niveau de consensus Alpenglow, prévue pour fin 2026, vise à compresser la finalité à environ 100 à 150 millisecondes ; traitez cela comme un plan annoncé plutôt qu'une propriété en production tant qu'elle n'est pas livrée. Une politique sensée aujourd'hui : créditer les petits paiements à la confirmation, retenir les gros la douzaine de secondes supplémentaires jusqu'à la finalité.

Solana n'a pas encore d'endpoint de webhook de dépôt sur l'API de Chaingateway. La détection sonde à la place deux appels : GET /api/v2/solana/blocks/number pour suivre les nouveaux blocs et GET /api/v2/solana/balances/{address} pour vérifier les fonds entrants. Avec des slots infra-seconde, un intervalle de polling de deux secondes montre encore un paiement comme reçu en quelques secondes.

Une boucle de polling disciplinée coûte peu à faire tourner. Stockez la hauteur de bloc traitée en dernier, et à chaque fois qu'elle bouge, vérifiez vos adresses de dépôt — ou GET /api/v2/solana/balances/{address}/tokens/{mint} pour un mint SPL spécifique — et faites correspondre ce que vous trouvez avec les commandes ouvertes.

Le coût de latence est plus faible qu'il n'y paraît. Solana produit des blocs en moins d'une seconde, donc même un intervalle de polling de deux secondes signifie qu'un client voit « payé » en quelques secondes après l'envoi. Toute la boucle tient en quelques dizaines de lignes dans n'importe quel langage et tourne comme tâche cron ou worker en arrière-plan. Quand vous étendez plus tard le même flux à une chaîne avec des webhooks, la comptabilité reste identique ; seul le déclencheur change de pull à push.

L'USDC est le rail de paiement qui a fait de Solana un réseau de règlement, il fournit donc un exemple concret. L'adresse du mint sur mainnet est EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v, émise par Circle ; tout ce qui prétend être USDC sans cela ne l'est pas.

Le côté réception : quand un client passe en caisse, créez une adresse fraîche avec POST /api/v2/solana/addresses et stockez-la avec la commande. Affichez l'adresse et le montant, et laissez le client payer depuis n'importe quel wallet ou plateforme d'échange. Votre boucle de polling de la section précédente capte le transfert entrant, fait correspondre l'adresse de réception avec la commande, et la bascule sur payée. Avec des slots de 400 millisecondes, l'écart entre « le client a appuyé sur envoyer » et « votre base de données dit payé » est de quelques secondes, la majeure partie étant votre propre intervalle de polling.

Enregistrez la signature de transaction de chaque dépôt crédité avec une contrainte unique. Les boucles de polling sont redémarrées, rechargées et relancées, et l'idempotence au niveau de la base de données signifie que rien de tout cela ne peut créditer une commande deux fois.

Le côté paiement reflète cela. Un paiement sortant est un seul appel POST /api/v2/solana/transactions/SPL avec le mint USDC comme contractaddress et un "amount": 10 lisible ; l'API applique les six décimales de l'USDC pour vous. Gardez un solde SOL modeste sur l'adresse expéditrice : 0,000005 SOL par signature pour les frais, plus 0,00203928 SOL chaque fois que le compte de token d'un destinataire doit être créé. Les deux montants sont assez faibles pour qu'un seul flottant rechargé couvre des mois de paiements.

Ce que vous gagnez par rapport aux rails de carte est un règlement en quelques secondes sans mécanisme de rétrofacturation, et ce que vous perdez est la capacité d'annuler une erreur. La validation d'adresse que l'API effectue avant de construire une transaction est votre alliée ici, mais votre propre écran de confirmation compte tout autant.

SPL est le standard de token de Solana, et l'API traite chaque mint SPL de la même façon. USDC et USDT fonctionnent d'emblée, avec les décimales appliquées automatiquement. Si vous avez minté votre propre token, passez son adresse de mint au même endpoint et il se comporte comme les principaux. Comme Chaingateway utilise une structure d'endpoint unique sur toutes les chaînes, le code Solana ci-dessus se transpose vers Ethereum, BSC ou Polygon en échangeant le segment de chaîne et le suffixe de token dans l'URL : /solana/transactions/SPL devient /ethereum/transactions/erc20.

Solana exécute les transactions en parallèle plutôt que strictement l'une après l'autre, d'où provient son débit. Les frais sont assez faibles pour que payer de minuscules montants reste économique, et la confirmation est assez rapide pour qu'une page de checkout puisse simplement l'attendre. Le volume d'USDC sur Solana a transformé la chaîne en un réseau de règlement sérieux, et la dynamique des développeurs autour a tenu à travers plusieurs cycles de marché.

Solana fait tourner deux clusters de test publics, et les noms prêtent à confusion. Devnet est le bac à sable quotidien pour les développeurs d'applications : du SOL gratuit est disponible via des airdrops de faucet, et rien n'y a de valeur. Testnet existe principalement pour que les validateurs et contributeurs principaux exercent de nouvelles versions sous charge. Si vous avez utilisé le Sepolia d'Ethereum, devnet en est l'équivalent le plus proche en esprit.

Avec Chaingateway, vous ne gérez aucune URL de cluster. Ajoutez l'en-tête X-Network: testnet à n'importe quelle requête et elle tourne contre l'environnement de test ; retirez-le et la requête identique est un appel mainnet. Il n'y a aucune seconde clé API ni compte séparé.

Utilisez l'essai pour les scénarios qui font mal sur mainnet : un paiement sortant vers une adresse qui n'a jamais détenu le token (le chemin de création de compte de token), un redémarrage de votre boucle de polling en plein milieu, et une soumission en double du même paiement. Chacun prend quelques minutes à répéter et chacun est un vrai incident si vous le rencontrez pour la première fois en production.

L'API rapporte les problèmes comme de simples codes de statut HTTP, donc rien dans votre gestion d'erreurs n'a besoin d'être spécifique à Solana.

Un 401 signifie que le jeton Bearer est manquant ou faux. Les erreurs dans la plage 4xx sont des échecs de validation, comme une adresse qui ne se décode pas en base58 ou un champ manquant ; le corps JSON dit quoi corriger, et réessayer sans changer le payload est inutile. Un 429 signifie que vous avez atteint la limite de débit de votre forfait ; ralentissez, et cadencez le polling des dépôts sur le battement de hauteur de bloc plutôt que sur une boucle serrée. Des forfaits avec des limites plus élevées sont sur la page de tarification.

Les erreurs serveur dans la plage 5xx sont sûres à réessayer pour les lectures. Pour les envois de tokens, soyez plus prudent : après un timeout, vous ne savez pas si le transfert a été diffusé, et Solana n'a pas encore de piste de webhook ici. Vérifiez vos propres enregistrements et les transferts récents de l'adresse avant de soumettre à nouveau, et gardez une ligne de base de données par paiement prévu pour qu'une relance de votre worker ne puisse pas envoyer deux fois.

Loguez le corps de réponse complet à côté de votre requête. Les codes de statut et schémas d'erreur par endpoint sont dans la référence API.

Le schéma le plus courant est l'acceptation de paiements : assignez à chaque client une adresse de dépôt, sondez les transferts SPL entrants et marquez la commande payée, avec un règlement en quelques secondes et des frais trop faibles pour compter dans votre calcul de marge. Le second schéma est les opérations de wallet : plateformes qui gèrent dépôts et retraits pour de nombreux utilisateurs via les mêmes quelques endpoints.

Les mêmes briques gèrent l'automatisation des paiements sortants pour les airdrops et lancements de tokens, les transferts récurrents pour la facturation par abonnement, et les paiements transfrontaliers là où l'alternative est une chaîne de banques correspondantes qui prend des jours et prélève des points de pourcentage.