Protocole de paiement des agents AP2 : un guide du développeur avec plus de 60 partenaires

Google a expédié le protocole de paiement d'agent (AP2) avec plus de 60 partenaires, dont Mastercard et Visa. (via Worldpay), American Express, PayPal, Coinbase, Salesforce, ServiceNow, Adyen et JCB. La spécification répond à une question : lorsqu'un agent IA paie quelque chose en votre nom, qui a signé quoi et comment un réseau de cartes résout-il une rétrofacturation trois semaines plus tard ?

Stripe Checkout et Apple Pay supposent qu'un humain a cliqué sur un bouton. Le commerce d’agents brise cela hypothèse. Si votre agent commercial réserve un hôtel à 3 heures du matin pendant que vous dormez et qu'il y a des punaises de lit dans la chambre, le processus de litige doit déterminer si vous avez autorisé Cette acheter ou donner le agent un chèque en blanc. AP2 répond par des Mandats signés : de petits objets structurés qui lient un agent à une intention d'utilisateur avec une preuve cryptographique.

Voici la répartition en six parties dont les développeurs ont besoin pour connecter AP2 à un agent, ainsi que le chemin de chiffrement. via l'extension A2A x402 déjà en production.

Partie 1 : Les mandats sont l'unité atomique

Un mandat est un objet JSON que le fournisseur d'identité de l'utilisateur signe lorsque l'humain autorise une classe d'achats. Chaque paiement en aval fait référence au Mandat par ID ; les commerçants vérifient signature, vérification des contraintes et règlement. Voici à quoi cela ressemble sur le fil :

Quatre champs ont du poids. intent est la chose en anglais simple demandée par l'utilisateur. constraints est l'enveloppe lisible par machine : montant maximum, devise, liste autorisée de la marque, catégorie. valid_until limite la durée pendant laquelle l'agent peut agir sur le mandat. signature est une preuve Ed25519 ou ECDSA que l'émetteur (Google Pay, Auth0 pour Agents, service d'identité d'une banque) ont en fait signé la charge utile.

Les contraintes sont le lieu où se produit le travail sur le produit. Un mandat avec max_amount: 10000 et aucune liste autorisée de marque n'est un chèque en blanc en forme d'agent. Un mandat avec max_amount: 200, brand_allowlist: [...], category: "footwear" est une portée autorisation sur laquelle un commerçant peut raisonner. Traitez la conception des contraintes de mandat de la même manière que vous traitez Conception de la portée OAuth : l'ensemble le plus serré autorisé par le produit.

Partie 2 : AP2 fonctionne comme une extension A2A

AP2 ne réinvente pas le transport. Il utilise Agent2Agent, le protocole ouvert JSON-RPC de Google publié en 2025 pour la communication agent à agent. Une tâche A2A avec intention de paiement porte le Mandat à l'intérieur du extensions.ap2 champ de l'enveloppe :

L'agent destinataire (ici, l'agent commercial du commerçant) lit la tâche A2A, voit le ap2 extension, vérifie le mandat via son PSP et accepte la tâche ou renvoie un rejet signé. Pour les développeurs qui parlent déjà A2A, l'ajout d'AP2 est une clé d'extension dans l'enveloppe de la tâche plus un appel de vérification ; ce n'est pas une pile parallèle.

Partie 3 : x402 gère les paiements cryptés aujourd'hui

Les sociétés de cartes négocient toujours la responsabilité en matière de rétrofacturation. La crypto a évolué plus rapidement. L'A2A x402 (co-conçue avec Coinbase, la Fondation Ethereum et MetaMask) est prêt pour la production et réutilise le paiement HTTP 402 requis pour négocier le règlement :

Le flux comporte quatre étapes : demande, 402 avec exigences de paiement, transfert signé liant le nonce au Mandat, réessayez avec le reçu. Les commerçants vérifient le transfert en chaîne avant de le publier la ressource. Le règlement est USDC sur base ou optimisme aujourd'hui ; Les rails stablecoin maintiennent l'UX proche aux achats par carte sans dérive de monnaie flottante entre la signature et la confirmation.

Partie 4 : Demander un mandat à Python

Voici à quoi ressemble le côté agent en Python en utilisant le SDK AP2 de référence. L'agent demande au le fournisseur d'identité de l'utilisateur pour un mandat, reçoit un objet signé et le transmet via un A2A tâche au commerçant:

Deux détails comptent. La clé de signature réside dans un KMS (Google Cloud KMS, AWS KMS, HashiCorp Vault) donc un agent binaire exfiltré ne peut pas forger une identité. Le Mandat est réutilisable chez tous les commerçants pendant valid_until; l'utilisateur autorise une fois, l'agent magasine dans plusieurs endroits. Cela la réutilisation est la seule raison pour laquelle AP2 existe ; sans cela, chaque commerçant invite à nouveau l'utilisateur et le l’expérience de l’agent s’effondre.

Partie 5 : Vérifier un mandat depuis le backend de votre marchand

C’est du côté des commerçants que se situe la majeure partie de la surface de la fraude. La vérification doit couvrir quatre choses : validité de la signature, confiance de l'émetteur, correspondance des contraintes et expiration. Économisez sur l'un des eux et vous expédiez un trou :

Trois modèles à copier. Gardez un issuerAllowlist; n'acceptez pas les mandats de tout émetteur qui se présente. Imposer clockSkewSeconds; les agents sur les réseaux instables envoient horodatage 15 secondes dans le futur régulièrement. Stockez l'ID de mandat, l'ID d'agent et l'ID d'utilisateur dans vos métadonnées PSP afin qu'un litige de rétrofacturation dans trois semaines puisse rejouer la chaîne sans ingénieur d'assistance plongeant dans les journaux.

Partie 6 : Construire un panier multi-devises autour du mandat

Les acheteurs agents traversent constamment les devises. Un utilisateur à Tokyo remet à un agent un mandat en USD ; le L'agent trouve une affaire chez un commerçant européen avec un prix en EUR. Le commerçant doit savoir quel plafond en USD se convertit en EUR avant d'accepter le Mandat. Un appel de conversion de devises conserve les calculs honnête :

Mettre en cache le taux pour toute la durée du mandat. Si le taux dépasse une bande configurée (typique : 2 %), demander à l'utilisateur de se re-signer. Se contenter d'un taux obsolète, c'est ainsi que les agents produisent tickets d'assistance.

Ce que AP2 change dans votre pile

Points clés à retenir

• Les mandats remplacent les pouvoirs du porteur. L'agent porte une intention signée, pas un numéro de carte ; le commerçant vérifie la portée avant de facturer.
• AP2 fonctionne sur A2A. Une clé d'extension dans l'enveloppe JSON-RPC, pas une nouvelle transports; si votre agent parle déjà A2A, vous êtes à un appel de vérification.
• x402 est la voie cryptographique en production aujourd’hui. HTTP 402 plus USDC sur base ou Optimisme, avec Coinbase et MetaMask expédiant déjà des clients.
• La conception par contraintes est une conception de portée. Traiter max_amount, les listes autorisées, et valid_until comme les portées OAuth des paiements des agents.
• Stockez la chaîne Mandate dans vos métadonnées PSP. Une rétrofacturation dans trois semaines vous ne pouvez pas contester ce que vous n’avez pas enregistré.

Botoi fournit les points de terminaison sur lesquels s'appuie un flux marchand AP2 : conversion de devises, recherche de pays, détection IP et VPN, validation d'adresse et recherche BIN pour les métadonnées de la carte. Un Clé API, 5 req/min sur le niveau gratuit. Parcourez le documents interactifs ou câblez le Serveur MCP dans votre agent afin que Claude ou Cursor puisse appeler les mêmes points de terminaison depuis l'éditeur.