AP2 : le protocole qui autorise un agent à payer.

Une définition courte

AP2 (Agent Payments Protocol) est un protocole ouvert qui standardise la façon dont un paiement déclenché par un agent est autorisé. Plutôt que de partager un identifiant de carte, l'agent présente une preuve d'autorisation signée cryptographiquement. AP2 est la brique « autorisation » de la couche de paiement agentique. Établi

Les deux types de mandats de la version 0.2

La spécification AP2 v0.2 définit deux types de preuves signées liées au même checkout :

1. Checkout Mandate : la preuve destinée au marchand que l'agent est autorisé à acheter le checkout assemblé.
2. Payment Mandate : la preuve destinée aux acteurs du paiement que l'agent est autorisé à payer ce checkout.

Les deux mandats peuvent être ouverts, avec des contraintes autorisées à l'avance, ou fermés, liés à une transaction déterminée. AP2 décrit ainsi les modes avec présence humaine et autonome. Établi

Contribution à la FIDO Alliance

La FIDO Alliance indique que Google a contribué AP2, aux côtés de Verifiable Intent de Mastercard, à ses travaux sur une couche de confiance commune. Cette formulation décrit une contribution au processus de standardisation. Elle ne permet pas de déduire une adoption générale ni un déploiement en production. Émergent

AP2 dans la pile agentique

AP2 ne fonctionne pas seul. Il se combine avec les autres protocoles de la pile :

• UCP et ACP : les opérations de commerce (catalogue, panier, checkout). Voir UCP vs ACP.
• A2A : la communication entre agents (porté par la Linux Foundation).
• MCP : l'accès des agents aux outils et données.
• x402 : un protocole de paiement HTTP utilisable dans certains exemples AP2 ; la spécification AP2 reste indépendante de l'instrument de paiement.

UCP est explicitement conçu pour être compatible avec AP2 : un marchand qui prépare son offre pour les agents travaille un socle commun, quel que soit le protocole d'autorisation retenu. Établi

Deux modes d'autorisation

AP2 v0.2 décrit un mode direct, où l'utilisateur approuve un checkout fermé, et un mode autonome, où des mandats ouverts signés par l'utilisateur encadrent ce que l'agent pourra approuver ensuite. Les vérificateurs reçoivent dans les deux cas des mandats Checkout et Payment fermés. Établi

Le protocole précise aussi que la communication de commerce, catalogue, mises à jour de checkout et API entre rôles, reste hors de son périmètre. AP2 apporte la couche de sécurité ; le protocole de commerce apporte le parcours.

Source : spécification AP2 v0.2, contrôlée le 27 août 2026.

Ce que ça change pour un marchand

Pour un marchand, AP2 est surtout une garantie côté confiance et conformité : l'autorisation est prouvée et traçable, et le marchand reste vendeur de record. La spécification précise d'ailleurs que la capacité Checkout n'ajoute pas d'obligation de conformité PCI DSS pour les paiements par carte. Établi Le travail à fournir reste le même que pour le commerce agentique : une offre lisible par la machine et une gouvernance claire. La méthodologie d'audit aide à évaluer cet état.

Un point pratique souvent négligé : la session de checkout expose un statut qui pilote l'agent, avec les états incomplete, requires_escalation, ready_for_complete, complete_in_progress, completed et canceled. L'état requires_escalation est le passage normalisé vers un humain. Un marchand qui impose une vérification d'âge, une pièce justificative ou une validation manuelle au-delà d'un montant n'a donc pas à sortir du protocole pour le faire. Établi

Questions fréquentes