Comment maîtriser facilement les tendances du marché, les évolutions technologiques, les progrès de l'écosystème et la dynamique de gouvernance en cours dans l'industrie Web3 ? La rubrique « Analyse du pouls du marché » lancée par Web3Caff Research explore en première ligne les événements actuels, les sélectionne et en fournit une analyse de valeur, des commentaires et une explication des mécanismes sous-jacents. Voyez au-delà des apparences et suivez-nous pour capter rapidement les tendances du marché Web3 en temps réel.
Auteur de l'article : Hendrix, chercheur à Web3Caff Research
Source : Web3Caff Research
À mesure que les capacités des agents IA s'améliorent et qu'ils prennent en charge un nombre croissant de tâches end-to-end, la création de systèmes de paiement dédiés aux agents devient une nécessité pour les commerçants et fournisseurs de services traditionnels. Toutefois, les solutions existantes présentent chacune leurs limites : les systèmes de paiement traditionnels, tels que les cartes de crédit ou les plateformes de paiement tierces, ont été conçus pour des utilisateurs humains réels et exigent des processus complexes d'authentification et d'évaluation des risques, inadaptés aux agents ; tandis que les nouveaux protocoles de paiement pour agents, comme x402 (développé et promu par Coinbase), MPP (Machine Payment Protocol créé par Tempo et Stripe), semblent créer un nouveau système entièrement dédié aux paiements chain-on-chain, où l'intégralité du paiement est traitée sur la chaîne et sécurisée par une vérification sur chaîne. Les fournisseurs de services doivent alors mettre en place un système de paiement distinct en parallèle de leurs canaux traditionnels, ce qui augmente la barrière à l'entrée. Les solutions traditionnelles et les nouveaux protocoles pour agents ressemblent à deux voies parallèles qui ne se rejoignent pas, limitant ainsi les services que les agents peuvent acheter de manière autonome aux écosystèmes compatibles avec Web3, empêchant une intégration à grande échelle des flux de travail. À cet égard, Solana Foundation et Google Cloud ont lancé Pay.sh, positionné comme « passerelle de paiement entre les agents et les infrastructures d'entreprise », pour franchir la dernière étape permettant aux agents d'accéder à davantage de services.
Avertissement de conformité : Le contenu suivant constitue uniquement une analyse objective de Pay.sh ainsi que de ses principes techniques et règles de conception, et ne constitue en aucun cas une proposition ou une offre. Veuillez ne pas prendre de décisions sur la base de ces informations et respectez strictement les lois et réglementations de votre pays ou région (les lecteurs de la Chine continentale sont fortement invités à consulter le document « Résumé des lois et réglementations chinoises continentales relatives à la blockchain et aux cryptomonnaies ») et à ne pas participer à toute activité financière interdite par la législation de votre pays ou région.
Pay.sh permet aux utilisateurs de recharger rapidement leur portefeuille Solana par carte de crédit ou parstablecoinpour que le portefeuille Solana puisse servir d’agent et decomptede paiement dans le monde des ressources Web2. Lorsqu’un agent doit appeler un service, il n’est plus nécessaire de créer un compte ou de saisir une clé API : la passerelle Pay.sh déclare l’identité légitime de l’agent, comme un système d’authentification Google, permettant à l’agent d’utiliser une identité de compte unifiée pour acheter des ressources de développement auparavant difficiles à obtenir, telles que Google Cloud ou Alibaba Cloud.compte
Les services API actuellement pris en charge par Pay.sh — Crédit image : site officiel du projet
Le processus de paiement de Pay.sh est similaire au protocole x402, qui a connu un grand succès récemment : tous deux reposent sur le code d'état HTTP 402. Lorsqu'un agent détecte qu'un service externe nécessite un paiement, il envoie une requête vers la ressource payante ; le serveur répond alors avec le code d'état 402 (paiement requis), accompagné des détails du paiement, tels que le montant, le plan de paiement, l'adresse de réception, la durée de validité, etc. Pay.sh analyse ces informations et demande une autorisation au portefeuille. Une fois le paiement effectué et le reçu généré, Pay.sh soumet à nouveau la requête de service avec le reçu pour obtenir une réponse normale. Toutefois, afin de couvrir divers scénarios d'utilisation d'API, Pay.sh est également compatible avec les logiques de paiement x402 et MPP : lorsque le serveur renvoie le code d'état 402, Pay.sh détermine le mode de paiement du service cible. Si l'accès est ponctuel (paiement pour une seule utilisation) ou basé sur la consommation (paiement pour un volume fixe d'accès), Pay.sh génère et diffuse sur la chaîne un virement unique d'un montant fixe. Si le paiement est continu ou basé sur la session (facturation unique selon la consommation totale), Pay.sh prend en charge le certificat d'autorisation de session du protocole MPP (Machine Payment Protocol), en inscrivant une limite budgétaire dans l'autorisation et en la renvoyant au serveur. L'agent peut alors appeler répétitivement le service en peu de temps, évitant ainsi des autorisations répétées. Pay.sh met à jour le solde restant à chaque appel ; lorsque le solde est épuisé ou que le service expire, une nouvelle autorisation de session est automatiquement relancée. Pay.sh sélectionne automatiquement le canal de paiement le plus adapté selon les exigences du service cible, réduisant ainsi les coûts d'utilisation et de gestion. Pay.sh garantit également que le portefeuille reste stocké en toute sécurité localement et ne demande la confirmation de l'utilisateur qu'au moment du paiement. Lorsqu'une réponse est reçue, Pay.sh distingue les données des instructions : tout contenu externe retourné par le fournisseur (y compris le titre, le corps et la description de l'API) est considéré comme une entrée non fiable ; l'agent ne doit jamais exécuter directement les instructions fournies par le service afin d'éviter les injections de prompts malveillants ou d'autres attaques.
Le principal avantage de Pay.sh réside dans le fait qu'il offre aux fournisseurs de services une passerelle facile à déployer, permettant d'intégrer la passerelle de paiement dans leur réseau de services sans avoir à modifier massivement leurs canaux de paiement ou leurs API. Le fournisseur de services doit simplement fournir un fichier déclaratif spécifiant les paramètres liés au paiement pour s'adapter à divers scénarios complexes : par exemple, en définissant des règles de routage, il est possible de permettre aux agents d'utiliser le service gratuitement jusqu'à un certain seuil, puis de facturer au-delà, voire d'implémenter une tarification progressive (des prix différents selon les niveaux d'utilisation). En outre, Pay.sh propose une fonction de répartition des paiements : les revenus reçus par le fournisseur peuvent être automatiquement transférés vers plusieurs adresses, par exemple 2 % pour les droits d'auteur sur les données de paiement, 5 % pour les coûts cloud, et le reste conservé pour les opérations internes. Le fournisseur n'a qu'à définir les pourcentages ou montants différents lors de la configuration des adresses de réception pour effectuer un règlement unique sur plusieurs comptes. Après inscription, le fournisseur peut publier les données de son service API sur le Pay Skill Registry ; les agents peuvent alors consulter le registre pour découvrir et sélectionner les services API appropriés.
Pay.sh n'est pas un concurrent direct de x402 et MPP. Alors que les protocoles x402 et MPP visent à rendre les paiements aux agents sur chaîne plus fiables, Pay.sh cherche à relier les écosystèmes de paiement Web2 et Web3, en attribuant une identité aux agents pour accéder aux ressources. Le portefeuille de l'agent est à la fois une identité et un moyen de paiement, lui évitant ainsi de devoir s'inscrire manuellement sur les sites des fournisseurs de services (certains fournisseurs considèrent actuellement comme une violation le fait qu'un agent s'inscrive en se faisant passer pour un humain). De plus, grâce à son partenariat avec Google, Pay.sh permet aux agents d'exécuter des proxy API et de gérer le routage du trafic directement sur Google Cloud, garantissant ainsi le contrôle d'accès et la conformité aux journaux, tout en encadrant le comportement des agents dans des limites raisonnables. Pay.sh offre un répertoire de services sélectionnés et une découverte de prix, permettant aux agents d'éviter de découvrir aléatoirement des services dans des environnements non protégés, tout en étant en mesure d'utiliser différents modes de paiement issus de x402 et MPP. Le processus de service peut être réalisé sur Google Cloud tout en respectant les exigences de conformité entreprise, comblant ainsi les lacunes des protocoles x402 et MPP, qui, en tant que simples canaux de paiement, ne couvrent pas entièrement les capacités de paiement des agents, tout en ouvrant une voie vers le commerce intelligent dans Web3. En outre, Pay.sh complète le dernier maillon des nombreux protocoles commerciaux pour agents lancés par Google : A2A (Agent2Agent Protocol) permet la communication et la délégation de tâches entre agents, AP2 (Agent Payments Protocol) assure la vérification de conformité, UCP (Universal Commerce Protocol) gère la découverte et l'exécution des services, tandis que Pay.sh assure le règlement fluide de la valeur du service. L'apparition de Pay.sh complète également les composantes commerciales Web2 pour les agents, en devenant un point de convergence entre les flux de valeur des deux mondes. Cette étape représente également une opportunité d'évolution pour l'écosystème de la chaîne Solana. Dans l'environnement du protocole x402, de nombreux API sont des réplicas malveillants ; certains fournisseurs de services contournent les conditions d'utilisation des fournisseurs d'origine en revendant leurs services — par exemple en extrayant illégalement des données de sites web ou en reconditionnant des API de grands modèles pour les revendre. Dans un tel environnement, les agents ne peuvent pas distinguer les services autorisés des services malveillants ou indésirables. Grâce à la passerelle de paiement Pay.sh et à son intégration avec Google, les agents utilisant Pay.sh pour accéder aux services peuvent réduire significativement les risques potentiels. Le lancement de Pay.sh marque le fait que la chaîne Solana s'engage activement à fournir un soutien et une infrastructure pour les paiements d'agents — ce qui non seulement attire davantage de flux de paiement Web2 vers Solana, mais renforce également les capacités du portefeuille Solana et accélère son adoption.
Cependant, Pay.sh est encore loin d’être une solution de passerelle de paiement parfaite. Le registre des fournisseurs de services de Pay.sh manque actuellement de mécanismes d’admission et de vérification décentralisée, ce qui rend toujours difficile de distinguer efficacement les services tiers non autorisés et les services malveillants ; les agents courent donc un risque élevé de se connecter à des services contrefaits, entraînant des pertes pour les utilisateurs. En outre, comme Pay.sh ne conçoit pas lui-même les protocoles de paiement sous-jacents, la sécurité du processus de paiement repose principalement sur la conception même de ces protocoles, ce qui introduit des risques externes incontrôlables pour Pay.sh et peut également entraîner des échecs de paiement potentiels en raison d’une adaptation insuffisante aux différents protocoles. Du point de vue des fournisseurs de services, bien qu’il y ait le soutien de la plateforme Google, les fournisseurs d’API dans différents pays et régions pourraient néanmoins hésiter à proposer les services de Pay.sh en raison des exigences de conformité liées à la gestion de la confidentialité des données et à la réglementation des paiements. Cela limitera non seulement le nombre de fournisseurs de services utilisant Pay.sh, mais pourrait également exiger à l’avenir davantage d’efforts de conformité de la part de Pay.sh. Toutefois, le lancement de Pay.sh marque néanmoins une étape importante dans la mise en œuvre concrète de l’intégration entre Web2 et Web3 pour les infrastructures de paiement des agents, offrant aux portefeuilles sur chaîne la possibilité de servir d’authentification pour la participation des agents à diverses tâches. Nous pouvons donc continuer à observer les développements futurs de Pay.sh.
Schéma des points clés :
