Comparaison X402, MPP et AP2 : risques et crédits

La comparaison entre X402, MPP et AP2 se résume à deux choix : comment le règlement se fait (atomique par demande vs compensation de session) et comment l'autorisation est prouvée (mandats). X402 et MPP sont des rails de paiement pour les paiements machine à machine, tandis qu'AP2 est la couche de gouvernance qui rend le paiement agentique auditable et sécurisé pour les entreprises.

Points clés

• x402 est un rail de règlement de stablecoin natif HTTP construit autour du HTTP 402 : le serveur propose des conditions, le client paie, puis réessaye la demande avec une preuve de paiement.
• MPP est un protocole de paiement machine basé sur des sessions : un agent préautorise une limite, diffuse des micropaiements pendant la session, et règle en lot à la fermeture de la session.
• AP2 n'est pas un rail. C'est un cadre d'autorisation et d'audit utilisant des mandats signés cryptographiquement basés sur les Credentials Vérifiables W3C.
• Le modèle de production est stratifié : AP2 pour « qui est autorisé à dépenser quoi », puis x402 ou MPP en dessous pour le règlement, selon les frais généraux et la tolérance au risque.

Comment ces protocoles diffèrent par couche

Le moyen le plus rapide de comparer correctement x402, mpp et ap2 est de cesser de les traiter comme trois substituts. Deux d'entre eux déplacent de l'argent, l'un d'eux prouve la permission. Le "paiements agentiques carte" de xpay cadre cela comme une pile : les rails de règlement en bas (où les fonds se déplacent réellement), un plan de contrôle au milieu (politiques et audit), et des protocoles de découverte ou de commerce au-dessus.

Ce cadre de pile est important car il change la question d'ingénierie de "quel protocole gagne" à "quel mode de défaillance est acceptable à chaque couche."

Du côté du règlement, x402 et MPP réutilisent tous deux HTTP 402 Payment Required comme la poignée de main qui transforme un appel API en un événement facturable. La différence réside dans la surface comptable. x402 est conçu autour d'un règlement atomique par demande, ce qui maintient le risque de crédit serré et la réconciliation granulaire.

MPP introduit une session, ce qui réduit les frais de règlement par interaction mais crée une fenêtre d'exposition jusqu'à ce que la session se ferme et se règle.

AP2 se situe au-dessus des deux. C'est une spécification de gouvernance et d'autorisation qui répond à une question différente : "Cet agent était-il autorisé à dépenser ?" Cela se fait avec des mandats signés cryptographiquement qui peuvent être vérifiés plus tard, ce qui est la pièce manquante lorsqu'un agent dépense au nom d'un humain ou d'une organisation.

Côte à côte, le modèle mental clair est :

1. x402 : règlement sans état par demande en stablecoins. 2. mpp : facturation d'état par session avec des micropaiements en streaming et règlement par lot. 3. ap2 : permissionnement signé et audit qui peuvent envelopper n'importe quel modèle de règlement.

C'est le cœur de l'économie des agents expliqué : les agents ont besoin d'un moyen de payer, et les opérateurs ont besoin d'un moyen de prouver que l'agent était autorisé à payer.

Flux de paiement x402 et compromis

Le flux x402 est une boucle serrée qui ressemble à ce qui apparaît sur une trace réseau, pas à une page de paiement. Un client demande une ressource payante. Le serveur répond avec HTTP 402 Paiement requis et des conditions de paiement structurées. Le client signe un paiement en stablecoin et l'attache à la prochaine demande, et le serveur retourne la ressource une fois le paiement vérifié et réglé.

Plusieurs sources décrivent un rôle de « facilitateur » dans cette boucle, qui existe pour que le serveur n'ait pas besoin de devenir un processeur de paiements en chaîne complet juste pour vendre une réponse API.

Cette atomicité est le point. Chaque demande est son propre reçu, ce qui rend la mesure et la résolution des litiges simples. Si un agent appelle un point de terminaison 500 fois, il y a 500 événements payés discrets. C'est aussi le coût. Les frais de règlement par demande deviennent le goulot d'étranglement lorsque le volume d'appels est élevé, même si les frais de chaîne sous-jacents sont bas.

Les sources positionnent x402 comme étant axé sur les stablecoins, souvent décrit avec USDC sur Base, et comme un primitif sans autorisation où l'acheteur n'a pas besoin d'ouvrir un compte avec le vendeur.

Le modèle de risque est simple : l'exposition du vendeur est essentiellement le temps entre la réception de la preuve de paiement et la livraison de la ressource. Il n'y a pas de « note » laissée ouverte. C'est pourquoi x402 s'adapte parfaitement aux paiements machine à machine comme les API payantes, les flux de données et les appels de service agent à agent.

En termes de calendrier, les sources placent le lancement de x402 par Coinbase en mai 2025, avec une mise à jour V2 le 11 décembre 2025 qui a ajouté des fonctionnalités de session ou d'identité basées sur un portefeuille et un support multi-chaînes, bien que la liste exacte des fonctionnalités V2 varie selon les résumés. Les sources notent également que Stripe a intégré x402 pour les paiements USDC sur Base en février 2026.

Modèle de sessions MPP et couverture des rails

MPP change l'unité de compte de « demande » à « session ». Au lieu de payer chaque appel, un agent préautorise une limite de dépenses, puis diffuse des micropaiements à mesure que l'utilisation s'accumule, et la session se règle par lot à la clôture. C'est la principale différence mécanique derrière la plupart des débats « x402 contre mpp ». Ce n'est pas seulement une question de vitesse. C'est un profil d'exposition différent et un objet de réconciliation différent.

MPP a été lancé le 18 mars 2026 aux côtés du mainnet Tempo, et les sources décrivent plus de 100 services intégrés au lancement. Le protocole est positionné comme multi-rail : stablecoins plusfiatdes cartes via des mécanismes de token Stripe, avec des extensions décrites pour Lightning via Lightspark et un support de réseau de cartes via Visa.

Cette couverture ferroviaire est la raison pratique pour laquelle les équipes se tournent vers MPP lorsqu'elles ont besoin d'un « point de terminaison unique capable d'accepter à la fois des crypto et des cartes. »

Le commerce est une dépendance. Les sources associent systématiquement MPP à Stripe plus Tempo, ce qui signifie que l'intégration hérite des outils et de la surface marchande de Stripe, mais hérite également du couplage de la plateforme. Ce couplage n'est pas abstrait.

Il se manifeste sous forme d'hypothèses opérationnelles : gestion du cycle de vie des sessions, délais d'attente et ce qui se passe lorsqu'un client plante en milieu de session avant la clôture.

D'un point de vue des risques, MPP est une ligne de crédit de session avec compensation à la fin de la session. Le vendeur prend plus d'exposition que x402 car la valeur peut être livrée pendant la session avant que le règlement final ne soit complété.

Le gain est une surcharge par interaction inférieure et un modèle de facturation qui convient à une utilisation à haute fréquence comme l'inférence, le calcul ou toute ressource mesurée où le règlement par appel dominerait le flux de travail.

Les mandats AP2 pour l'autorisation et l'audit

AP2 appartient à une catégorie différente de x402 et MPP. Il n'exécute pas le règlement. Il définit comment un agent prouve qu'il avait la permission de dépenser, en utilisant des mandats signés cryptographiquement basés sur des Credentials Vérifiables W3C, qui sont conçus pour être vérifiables et non répudiables.

AP2 définit trois types de mandats qui correspondent clairement aux modes d'achat courants des agents :

1. Mandat d'Intention : autonomie déléguée, où un humain ou une organisation signe des règles à l'avance et l'agent dépense plus tard dans ces contraintes. 2. Mandat de Panier : paniers approuvés par l'utilisateur, où un humain valide un ensemble spécifique d'articles et de totaux avant le paiement. 3.

Mandat de Paiement : un signal aux réseaux de paiement et aux émetteurs qu'un agent était impliqué, afin que les systèmes de risque et de conformité puissent évaluer la transaction en conséquence.

C'est pourquoi les comparaisons de « protocole AP2 » déraillent souvent. AP2 ne concurrence pas x402 ou MPP sur le débit ou les frais car ce n'est pas un rail. C'est l'enveloppe de permission et d'audit qui transforme « l'agent a dépensé de l'argent » en « l'agent a dépensé de l'argent sous un mandat signé. »

AP2 est également explicitement encadré comme étant composable avec des rails de règlement. Les sources décrivent les implémentations AP2 utilisant x402 en dessous via une extension A2A x402, qui est l'exemple concret de l'architecture en couches vers laquelle l'écosystème converge. Dans cette pile, AP2 est le plan de contrôle, et x402 ou MPP est le rail de règlement choisi par flux de travail.

Pour les constructeurs, l'implication pratique est que les décisions AP2 sont des décisions de gouvernance : quelles contraintes existent, qui les signe et quelles preuves sont conservées pour un examen ultérieur. C'est une surface de conception différente de « comment déplaçons-nous l'USDC. »

Choisir x402, MPP, AP2 pour des cas d'utilisation

Le cadre décisionnel n'est pas « choisir un protocole ». C'est « choisir une ergonomie de règlement, puis choisir une posture d'autorisation ». La carte en couches de xpay rend cela explicite, et le paysage des paiements agentiques traite déjà ces éléments comme des composants composables.

Une façon utile de choisir est de décider ce qui doit être réconcilié et où l'exposition est autorisée à s'accumuler.

1. Choisissez x402 lorsque le produit souhaite des reçus atomiques par appel et un état minimal. Cela convient aux API payantes et aux services agent-à-agent où le contrat le plus propre est « payer, puis obtenir la réponse ». Le chemin d'échec à concevoir est la boucle 402 → payer → réessayer, y compris l'idempotence et ce qui se passe lorsque le client réessaie après avoir payé. 2.

Choisissez MPP lorsque les frais de règlement par demande deviennent le goulot d'étranglement et que la comptabilité au niveau de la session est acceptable. Cela convient à une utilisation mesurée à haute fréquence où un objet de session est déjà naturel. Le chemin d'échec à concevoir est l'expiration de la session, l'utilisation partielle et la récupération après un crash avant la fermeture de la session. 3.

Ajoutez AP2 lorsque le système a besoin de contraintes prouvables et de pistes de vérification pour les dépenses des agents. Cela est courant dans l'approvisionnement des entreprises, les environnements réglementés et tout flux de travail où « qui a autorisé cela » doit être répondu par un artefact signé, et non par une ligne de base de données.

Les architectures combinées courantes découlent directement de ces choix :

1. AP2 + x402 : les mandats définissent des limites et des destinataires, puis chaque appel API se règle de manière atomique sur des stablecoins. 2. AP2 + MPP : les mandats définissent le budget de session et les contraintes, puis les flux d'utilisation se déroulent à l'intérieur d'une session pré-autorisée et se règlent par lots. 3.

x402 + MPP côte à côte : un agent utilise les deux rails, utilisant x402 pour des points de terminaison à faible fréquence ou sans autorisation et MPP pour des charges de travail à haute fréquence ou lorsque l'acceptation de carte est requise.

Près du bas de la pile, ce sont juste différentes façons d'implémenter le comportement du protocole de paiement machine. Près du sommet, ce sont les canalisations qui rendent l'économie agentique expliquée viable sans transformer chaque agent en un risque de dépense illimité.

Le point clé

J'ai vu des équipes perdre des semaines à débattre de « x402 contre MPP » comme si c'était une guerre de normes à vaincre, puis être surprises par la partie ennuyeuse : la réconciliation et les chemins d'échec. Le bug coûteux n'est pas le paiement sur le chemin heureux. C'est le crash en milieu de session, le réessai après un 402, ou la demande d'audit six mois plus tard lorsque quelqu'un demande pourquoi un agent a été autorisé à dépenser.

Si le système a besoin d'un risque de crédit strict et de reçus propres par appel, le modèle atomique de x402 est difficile à battre. Si le volume des appels rend les frais de règlement par demande la contrainte, le netting de session de MPP est le changement ergonomique évident, avec le compromis que l'exposition vit à l'intérieur de la session jusqu'à la fermeture. AP2 est le morceau que la plupart des gens classifient mal.

C'est la couche de mandat qui rend chaque rail défendable lors d'un examen d'entreprise car elle transforme les dépenses en autorisation signée et vérifiable.

Sources

• xpay.sh
• fluxapay.xyz
• openfort.io
• crossmint.com