pay.sh s'efforce de combler le fossé entre les agents IA et les API payantes.
Article rédigé par KarenZ, Foresight News
Un agent capable d'écrire du code, de rechercher des informations et d'appeler ses propres outils se bloque souvent à l'étape la plus simple : le paiement.
Ce que pay.sh souhaite démolir, c'est ce mur. Le 5 mai, la Fondation Solana, en partenariat avec Google Cloud, a lancé pay.sh. Ce produit ne vise pas à créer un portefeuille destiné aux consommateurs ni à réinventer un bouton de paiement. Il cible un autre besoin plus spécifique : lorsque qu'un agent doit appeler une API de paiement, il n'est plus nécessaire de s'inscrire manuellement ni d'utiliser des clés API ; au lieu de cela, le paiement est effectué à la demande, puis le droit d'appel est obtenu.
En bref, pay.sh vise à décomposer l’action « appeler une API » en un processus plus adapté aux machines : voir le prix, envoyer une demande, autoriser le paiement, recevoir le résultat.
Selon les informations du Solana Foundation et du site officiel de pay.sh, le premier périmètre de connexion couvre déjà certaines API de Google Cloud, notamment Gemini, BigQuery, Vertex AI, BigTable et Cloud Run, ainsi que plus de 50 facilitateurs d'API communautaires offrant des services dans les domaines du commerce électronique, des données, des communications et de l'infrastructure sur chaîne.
Qu'est-ce que Pay.sh ?
D'après la description officielle, pay.sh est une couche de paiement proxy et de coordination d'appels destinée aux API payantes. Elle enveloppe les outils en ligne de commande familiers aux développeurs et les flux de proxy, détectant automatiquement les protocoles de paiement lorsque l'API cible impose un défi du type « payer avant d'obtenir les données ». pay prépare les justificatifs de paiement, demande l'autorisation du portefeuille localement, puis réessaie la requête une fois le paiement effectué. Pour les développeurs, la requête curl précédemment en erreur ne nécessite désormais qu'un « pay » en plus au début ; pour le proxy, il reçoit un chemin d'outil directement exploitable pour consommer des capacités payantes.
Il y a plusieurs points particulièrement importants.
- Quel protocole de paiement utilise-t-on ? Pay.sh mise techniquement sur des normes de paiement machine ouvertes. Officiellement, pay.sh est construit sur les deux protocoles de paiement x402 et MPP.
- Méthodes de paiement : Les paiements et règlements sous-jacents de pay.sh reposent sur des stablecoins sur Solana. La Fondation Solana indique que les utilisateurs peuvent effectuer un dépôt par carte de crédit ou par stablecoin en environ 60 secondes.
- Signature : pay.sh n’autorise pas l’agent à accéder directement à la clé privée « à nu ». Selon le site officiel et le README GitHub, son processus d’autorisation local utilise les fonctionnalités de sécurité système, telles que le Keychain et Touch ID sous macOS, Windows Hello, GNOME Keyring ou 1Password. Autrement dit, bien que l’agent puisse déclencher automatiquement une demande de signature, l’étape finale de validation conserve un mécanisme d’autorisation contrôlé en coulisses. Ce design ressemble à donner à un agent IA une carte de paiement avec un crédit limité et des actions traçables, plutôt que de lui remettre les clés du coffre-fort de l’entreprise.
Qui d'autre a lancé un partenaire ?
La page souvent négligée au lancement de tout projet d'infrastructure est la liste des partenaires.
Les partenaires de lancement de l'endpoint source de la communauté pay.sh incluent : PayAI, Crossmint, Merit Systems, Corbits, MoonPay, Sponge Wallet, ATXP, Tektonic Company.
MoonPay et Crossmint comblent les entrées de fonds et l'infrastructure de portefeuille. Le premier résout la conversion entre les devises fiat et les stablecoins, tandis que le second offre des portefeuilles, des stablecoins et des intégrations de paiement de niveau entreprise. Sans cette couche, les paiements par代理 restent confinés à un petit cercle d'utilisateurs natifs de chaîne.
Sponge Wallet se rapproche du rôle de wallet agent et de passerelle de paiement, en emballant les API tierces sous forme d'interfaces directement appelables et payantes à l'utilisation ; ATXP met l'accent sur la couche du protocole de transaction par代理, impliquant l'identité d'agent, la collaboration en tâches et le flux de paiement.
Concernant Merit Systems, Corbits, PayAI et Tektonic Company, ils ne sont pas simplement des plugins de paiement, mais plutôt des fournisseurs de services et des couches d'agrégation pour l'économie d'agent, aidant les fournisseurs de services à connecter leurs API, données et capacités de paiement à ce système. Merit Systems propose déjà, dans le répertoire pay.sh, diverses API de données, de médias, de communication et de téléchargement facturées en plusieurs stables-coins.
Autrement dit, pay.sh ne cherche pas seulement à résoudre la question « comment payer », mais à relier l’ensemble du processus : comment les agents découvrent les services, obtiennent des devis, accomplissent l’autorisation et effectuent des règlements en temps réel. Il agit davantage comme une couche de coordination, rassemblant dans un annuaire unifié des capacités déjà existantes mais dispersées entre différents facilitateurs et fournisseurs de services, afin d’offrir aux agents et développeurs une entrée unique.
Si Google Cloud fournit une entrée API d'entreprise de niveau supérieur et un soutien infrastructurel, les partenaires communautaires apportent quant à eux la diversité et l'offre de longue traîne.
À l'avenir, les consommateurs pourraient être une couche après une autre d'agents exécutant des tâches pour les humains. Si ce changement se produit réellement, les modèles de facturation et la logique de distribution du marché API devront être adaptés.