Note de contexte : cet article a été reformulé pour refléter le marché actuel. Stripe construit activement une infrastructure pour le commerce agentic. L'argument n'est pas que Stripe est hors de propos. L'argument est que le commerce autorisé par l'acheteur et le règlement du travail autonome sont des couches différentes.
L'ancienne version de ce débat était trop simple :
« Les agents IA ne peuvent pas utiliser Stripe. »
Ce titre capturait un vrai problème, mais n'est plus assez précis. Stripe commercialise maintenant explicitement l'infrastructure pour le commerce agentic. Il prend en charge la découverte de marchands, le checkout piloté par agents, les jetons de paiement partagés, les protocoles de paiement machine et les garde-fous pour l'acheteur. Toute analyse sérieuse doit reconnaître cela.
La meilleure affirmation est :
Les agents IA ont besoin de plus que Stripe quand la tâche n'est pas seulement d'acheter, mais de vérifier et de régler le travail autonome.
Stripe peut aider un agent à acheter un produit pour le compte d'un utilisateur. x402 peut aider un agent à payer une API sur HTTP. Ergo et Accord s'adressent à une couche différente : les accords de travail programmables, les acceptance predicates, les Notes de crédit et les reçus de règlement.
Deux marchés, pas un
L'expression « paiements d'agents » cache deux marchés différents.
1. Commerce agentic
Un humain veut qu'un agent achète quelque chose : des chaussures, un voyage, un logiciel, de l'épicerie, des billets, des fournitures ou des abonnements. L'agent agit sous l'autorité humaine. Le marchand a toujours besoin de contrôles antifraude, de checkout, de gestion de la relation client, de remboursements, de conformité et de méthodes de paiement.
Stripe est bien positionné ici.
2. Règlement du travail autonome
Un agent logiciel paie un autre agent, outil, API ou service pour un travail. La question importante n'est pas seulement « le paiement était-il autorisé ? » C'est « le travail a-t-il été complété selon l'accord ? »
C'est là que les prédicats programmables, les Notes et les reçus sont importants.
Ce que Stripe fait bien
Stripe est fort parce qu'il résout la réalité désordonnée du commerce :
- l'intégration des marchands;
- le traitement des paiements;
- le checkout;
- la détection de fraude;
- les réseaux de cartes;
- le support des stablecoins;
- la couverture des méthodes de paiement;
- l'autorisation de l'acheteur;
- les litiges et remboursements;
- les rapports et la réconciliation.
Pour les entreprises qui veulent que leurs produits soient disponibles via des agents, la direction de Stripe a du sens. Un marchand ne devrait pas avoir besoin d'une intégration personnalisée pour chaque assistant d'achat IA. Un acheteur ne devrait pas avoir besoin d'exposer les détails bruts de sa carte à chaque agent. Un agent devrait avoir des garde-fous.
C'est une véritable infrastructure.
Où Stripe n'est pas la réponse complète
La pile de commerce de Stripe n'est pas conçue pour être un protocole décentralisé de vérification du travail.
Considérez ces tâches :
- payer un agent de données uniquement si le fichier retourné correspond à un hash engagé;
- payer un agent modèle uniquement si un vérificateur accepte la qualité de la sortie;
- émettre à un sous-agent un budget qui expire après 24 heures;
- permettre à un prestataire de collecter de nombreuses petites demandes et de les échanger plus tard;
- prouver qu'un accord de travail autonome s'est réglé sur un rail particulier;
- encoder l'acceptation de tâche à l'intérieur de l'instrument de paiement.
Ce ne sont pas des problèmes ordinaires de checkout. Ce sont des problèmes de règlement programmable.
Le problème des micropaiements
La tarification standard de Stripe pour les cartes nationales est un pourcentage plus une commission fixe. C'est correct pour les achats normaux. Ce n'est pas conçu pour les appels API à 0,001 $. Si la commission fixe est plus grande que le prix du service, la facturation directe par appel de carte devient non économique.
Stripe peut traiter des parties de cela via le traitement par lots, les abonnements, la facturation basée sur l'utilisation, les paiements en stablecoin et les protocoles de paiement machine. Mais le traitement par lots crée du crédit. Le crédit crée la confiance. La confiance crée un ledger. Si le ledger est contrôlé uniquement par l'application, l'économie des agents hérite d'une couche comptable centralisée.
Cela peut être acceptable pour de nombreuses entreprises. Ce n'est pas la même chose qu'un protocole de règlement du travail programmable, vérifiable et indépendant du rail.
Où x402 s'insère
x402 est l'un des développements les plus importants dans les paiements machine car il transforme « Payment Required » en un vrai flux web.
Un service peut dire :
402 Payment Required
Voici le prix.
Voici l'actif accepté.
Voici comment payer.
Retournez avec une charge utile de paiement.
C'est exactement ce dont les API payantes ont besoin. Cela rend le paiement machine plus naturel que de créer des comptes et des tableaux de bord de facturation API pour chaque petit service.
Mais x402 vérifie principalement le paiement et déverrouille l'accès. Il ne répond pas automatiquement à :
- quel travail a été promis après le paiement?
- qui a vérifié la réalisation?
- le travail a-t-il été partiellement accepté?
- que se passe-t-il si la sortie est invalide?
- un acheteur peut-il émettre une Note de crédit bornée à un sous-agent?
- un reçu de règlement peut-il être utilisé sur plusieurs rails?
Ces questions appartiennent à la couche d'accord.
Où Accord s'insère
Accord Protocol transforme une demande payante en accord de travail.
Il enregistre ou normalise trois objets :
- Agreement — tâche, prix, parties, vérificateur, délai et règles.
- Verification Receipt — travail accepté, rejeté ou partiellement accepté.
- Settlement Receipt — le résultat économique sur un rail comme Ergo, Rosen, EVM ou x402-compatible payment.
Cela signifie qu'Accord peut compléter les flux de type Stripe ou x402. L'agent peut payer en utilisant un rail, mais l'accord de travail peut toujours être décrit et vérifié dans un format portable.
Où Ergo s'insère
Ergo est l'environnement de règlement où cette conception devient particulièrement concrète.
eUTXO
Un objet de paiement a un état explicite et une règle de dépense explicite. Cela aide les agents à raisonner sur les transactions avant de les soumettre.
ErgoScript
La logique d'acceptation peut résider dans la condition de dépense. C'est la primitive centrale pour la rédemption contingente au travail.
Notes
Les Notes peuvent représenter un crédit bornée et expirant, conditionnellement remboursable. C'est plus sûr que de donner à un agent un solde de portefeuille illimité.
Reserves
Une Reserve rend le soutien inspectable. Une contrepartie peut vérifier si une Note est soutenue par une Reserve spécifique.
Trackers
Un Tracker empêche la double-rédemption dans le système de Notes.
Babel Fees
Babel Fees peut réduire le frottement de l'exigence que chaque agent détienne l'actif de commission natif, sous réserve des contraintes de marché et de mise en œuvre.
Une meilleure comparaison
| Besoin | Stripe | x402 | Ergo/Accord |
|---|---|---|---|
| Achat autorisé par humain | Excellent | Partiel | Pas principal |
| Checkout marchand | Excellent | Limité | Pas principal |
| Accès API payant | Bon via outils de plateforme | Excellent | Possible |
| Défi de paiement programmatique | Émergent via protocoles machine | Fort | Peut intégrer |
| Accord de travail | Spécifique à l'app/plateforme | Limité | Objectif principal |
| Acceptance predicate | Couche hors chaîne/application | Pas principal | Motif de conception natif |
| Notes de crédit programmable | Pas natif | Pas natif | Primitive principale |
| Reçu de règlement décentralisé | Dépend du rail | Dépend du facilitateur/rail | Objectif principal |
| Expérimentation testnet | Pas le modèle | Oui | Oui |
| Maturité de production | Élevée pour le commerce | Croissante | Tôt/testnet pour Accord |
Ce tableau est plus crédible que de dire « Stripe échoue ». Stripe réussit dans ce pour quoi il est conçu. Ergo/Accord cible une couche manquante différente.
Exemple : acheter des chaussures vs payer un agent travailleur
Un agent d'achat achetant des chaussures pour un humain devrait utiliser l'infrastructure de commerce. Le marchand a besoin d'inventaire, de checkout, de contrôles antifraude, d'expédition, de retours et d'assistance client. L'infrastructure de type Stripe est appropriée.
Un agent de recherche payant un agent de nettoyage de données est différent. Il n'y a peut-être pas de vitrine marchande. L'acheteur veut des enregistrements normalisés correspondant à un schéma. Le travailleur veut un paiement. Le système doit vérifier la sortie et régler. Une Note avec un acceptance predicate est un meilleur ajustement conceptuel.
Exemple : API payante vs tâche acceptée
Pour une API payante qui retourne une réponse statique, x402 peut suffire. Le client paie, le serveur vérifie le paiement, le serveur retourne les données.
Pour une tâche où le fournisseur doit produire un résultat personnalisé, le paiement seul ne suffit pas. Le résultat doit être accepté. Accord peut définir la tâche. Ergo peut encoder les règles de rédemption. Le reçu peut montrer ce qui s'est passé.
Quoi construire au lieu d'argumenter
Le moyen le plus fort de prouver la thèse est de construire une démo qui compose les couches :
- Une API payante retourne une exigence de paiement de style 402.
- L'exigence inclut un ID d'Accord Agreement.
- L'agent paie ou présente une Note Ergo.
- Le fournisseur complète le travail.
- Un vérificateur émet un Verification Receipt.
- La Note ne se rembourse que si le prédicat est satisfait.
- Le système publie un Settlement Receipt.
Cette démo montrerait que l'argument n'est pas « Stripe mauvais, Ergo bon ». L'argument est : l'autorisation de commerce, la vérification de paiement et le règlement du travail sont des couches différentes.
Note SEO : pourquoi cet article devrait garder « Stripe » dans le titre
Les gens rechercheront « AI agents Stripe », « Stripe agentic commerce », « can AI agents use Stripe » et « agent payments Stripe ». L'article devrait répondre honnêtement à cette intention de recherche. Un article anti-Stripe de clickbait vieillira mal. Une comparaison nuancée peut se classer et rester crédible.
Brouillon JSON-LD d'article
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Pourquoi les agents IA ont besoin de plus que Stripe : Commerce Agentic vs Règlement du Travail Autonome",
"description": "Stripe, x402 et MPP activent le commerce agentic et les paiements machine. Ergo et Accord ajoutent la vérification du travail programmable, les Notes, les acceptance predicates et le règlement on-chain.",
"datePublished": "2026-01-23",
"dateModified": "2026-05-08",
"author": { "@type": "Organization", "name": "Ergo Developer Relations" },
"publisher": { "@type": "Organization", "name": "Ergo Platform" },
"mainEntityOfPage": "https://www.ergoblockchain.org/blog/agents-cant-use-stripe",
"keywords": ["Stripe agentic commerce", "AI agent payments", "x402", "Accord Protocol", "Ergo"]
}
Notes sources
- Article original : https://www.ergoblockchain.org/blog/agents-cant-use-stripe
- Stripe Agentic Commerce : https://stripe.com/use-cases/agentic-commerce
- Tarification Stripe : https://stripe.com/pricing
- Documentation x402 : https://docs.cdp.coinbase.com/x402/welcome
- Dépôt Accord Protocol : https://github.com/accord-protocol/accord-protocol