Le commerce agentique et la couche d'identité : Visa TAP, Google AP2 et Mastercard Agent Pay (FR)

Points clés à retenir

• Visa Trusted Agent Protocol (TAP), Google Agent Payments Protocol (AP2) et Mastercard Agent Pay rendent tous les achats effectués par un agent plus sûrs, mais ils résolvent différentes parties du problème de confiance.
• TAP aide les commerçants à reconnaître les agents approuvés et à vérifier l'intention commerciale signée. AP2 crée des preuves de ce qu'un utilisateur a autorisé. Agent Pay combine des agents enregistrés, des informations de paiement tokenisées, le consentement et la visibilité du réseau.
• Aucun de ces mécanismes n'élimine la nécessité de prouver qui est la personne ou l'entreprise, de filtrer les risques, d'appliquer des contrôles spécifiques à la juridiction et de conserver une piste d'audit.
• Didit est une infrastructure neutre pour l'identité et la fraude, et non un réseau de cartes ou une société de paiement. Son serveur hébergé Model Context Protocol (MCP) expose 115 outils répartis dans 11 catégories, tandis que l'interface de programmation d'applications (API) Representational State Transfer (REST) prend en charge les flux de production intégrés.
• Un ensemble complet Know Your Customer (KYC) coûte 0,33 $, chaque compte comprend 500 vérifications gratuites par mois, et le serveur MCP lui-même est gratuit.

Le commerce agentique commence lorsqu'un agent d'intelligence artificielle (IA) fait plus que recommander un produit. Il compare les offres, assemble un panier, choisit un mode de paiement et peut effectuer un achat dans les limites fixées par une personne ou une entreprise. Ce changement soulève plusieurs questions de confiance simultanément : Quel agent a fait la demande ? Qui l'a autorisée ? Qui est la personne physique ou morale derrière elle ? La transaction est-elle autorisée ? Et quelles preuves existeront si l'achat est contesté ?

Les normes de paiement émergentes répondent à des parties importantes de cette séquence. Elles ne répondent pas toutes à la même partie, et elles ne doivent pas être traitées comme interchangeables. Pour les développeurs, la question utile n'est pas de savoir quelle marque va « gagner ». C'est de savoir quels contrôles restent nécessaires dans chaque architecture crédible.

Trois normes, trois frontières de confiance

Visa TAP : le commerçant peut-il reconnaître et faire confiance à cet agent ?

Visa Trusted Agent Protocol est orienté commerçant. Son rôle principal est d'aider un commerçant à distinguer un agent commercial approuvé d'un robot d'exploration ordinaire, d'un bot abusif ou d'une automatisation inconnue. Un agent signe une demande avec des identifiants limités dans le temps et spécifiques à un usage. Le commerçant ou son fournisseur de protection vérifie la signature et peut décider d'autoriser la navigation, le paiement ou une action plus restreinte.

TAP décrit trois signaux connexes : une signature de reconnaissance d'agent, une identité de consommateur ou d'appareil liée et signée, et un conteneur de paiement lié et signé. C'est une séparation utile. La reconnaissance de l'agent établit quel agent approuvé est présent ; l'intention signée établit le type d'interaction demandé ; le signal consommateur peut aider un commerçant à reconnaître un client existant.

Ce signal consommateur n'est pas automatiquement équivalent à une nouvelle vérification d'identité. Le modèle de Visa inclut un rôle de fournisseur d'identité en amont, mais un commerçant a toujours besoin d'une politique pour un client nouveau ou à haut risque : quelles preuves ont été vérifiées, quelle est la force de l'assurance, si le KYC est requis et quand une reverification est nécessaire. TAP peut transporter des informations d'identité fiables sans prescrire chaque décision d'intégration juridictionnelle.

Google AP2 : qu'est-ce que l'utilisateur a autorisé l'agent à acheter ?

Google Agent Payments Protocol se concentre sur l'autorisation et les preuves. Il utilise des mandats signés pour relier l'intention de l'utilisateur, le contenu du paiement et le paiement. Un mandat ouvert peut donner à un agent une discrétion limitée, comme des contraintes de commerçant ou des limites de dépenses. Un mandat fermé lie l'approbation à un panier et un montant spécifiques. Les reçus complètent la chaîne de preuves.

AP2 distingue les flux avec présence humaine et sans présence humaine. Lorsque la personne est présente, elle peut approuver directement un paiement fermé et un mandat de paiement. En son absence, l'agent opère dans les limites précédemment approuvées et signe les mandats fermés finaux. Un commerçant ou un fournisseur d'informations d'identification peut toujours ramener la personne dans la boucle lorsqu'une contrainte ne peut pas être résolue.

Cette conception répond plus directement à la question « Cette personne a-t-elle autorisé cette action dans ces conditions ? » qu'à la question « Comment cette personne a-t-elle été initialement vérifiée ? ». Le cadre d'autorisation AP2 suppose que les informations d'inscription et d'identification de l'utilisateur pertinentes existent. Un développeur a donc toujours besoin d'un processus de vérification d'identité et de cycle de vie des informations d'identification avant que ces mandats ne puissent offrir une assurance significative.

Mastercard Agent Pay : le réseau peut-il reconnaître et régir un paiement agentique ?

Mastercard Agent Pay s'appuie sur la tokenisation des paiements. Le cadre d'acceptation de Mastercard enregistre et vérifie les agents, attribue une identité d'agent unique et utilise des jetons agentiques afin que les transactions soient traçables et que les informations de paiement restent protégées. La reconnaissance côté commerçant peut fonctionner avec l'infrastructure de paiement existante, tandis que des intégrations plus profondes prennent en charge un échange de données plus riche.

Le modèle met également l'accent sur le consentement du consommateur, l'authentification et la capacité des émetteurs, des acquéreurs et des commerçants à reconnaître qu'un agent a participé. Cela rend l'activité de l'agent visible dans un modèle de risque de réseau de cartes familier au lieu de rendre l'automatisation indiscernable d'une demande ordinaire sans carte présente.

Agent Pay est le plus fort en matière de sécurité des informations de paiement, de visibilité des agents et de contrôles réseau. Il ne supprime pas l'obligation d'un commerçant de décider quand la vérification d'identité, le Know Your Business (KYB), le filtrage Anti-Money Laundering (AML), les vérifications d'âge ou l'examen approfondi s'appliquent. Ces décisions dépendent du produit, du client, de la transaction et de la juridiction, et pas seulement du canal de paiement.

Où les normes se chevauchent — et où l'identité s'intègre toujours

Les trois approches tentent de rendre le commerce délégué lisible. Un commerçant doit pouvoir dire qu'une automatisation est impliquée, vérifier que l'agent est fiable, lier l'action à l'intention de l'utilisateur, contraindre l'achat et conserver des preuves. Leur accent diffère :

• TAP : reconnaissance de l'agent et intention signée à la frontière du commerçant, avec des signaux de consommateur et de paiement liés facultatifs.
• AP2 : artefacts d'autorisation cryptographiques qui lient l'intention de l'utilisateur aux résultats du paiement et du règlement.
• Agent Pay : agents enregistrés, informations de paiement tokenisées, consentement, authentification et visibilité sur le réseau de cartes.

La vérification d'identité se situe avant et à côté de ces contrôles. Une autorisation signée n'est valable que si l'information d'identification appartient à la bonne personne. Un agent approuvé peut toujours être instruit par un compte synthétique, volé, sanctionné, mineur ou autrement inéligible. Un jeton peut protéger les informations de paiement sans établir qu'un vendeur de marché ou un bénéficiaire commercial a satisfait aux obligations de diligence raisonnable requises.

L'identité de l'agent répond à la question « quel logiciel a agi ? » L'autorisation répond à la question « qu'a-t-il été autorisé à faire ? » La vérification d'identité répond à la question « qui est derrière ? » Les contrôles de fraude et de conformité répondent à la question « cette action doit-elle se dérouler ? »

Ce que les développeurs doivent construire quelle que soit l'approche qui l'emporte

• Enregistrement et vérification. Vérifiez la personne ou l'entreprise avant d'accorder une information d'identification réutilisable ou une autorité de dépense déléguée. Appliquez les vérifications KYC, KYB, de vivacité, de documents, de base de données ou biométriques en fonction du risque.
• Liaison des informations d'identification. Liez le sujet vérifié à un compte, un appareil, une clé d'accès, un portefeuille ou d'autres informations d'identification pouvant participer au flux agentique.
• Autorisation scope. Capturez les limites telles que le commerçant, la catégorie, le montant, la fréquence, l'expiration et si un humain doit revenir pour approbation.
• Décisions de risque en temps réel. Examinez la personne, l'entreprise, le portefeuille et la transaction au moment de l'action. Les contrôles Know Your Transaction (KYT) et les vérifications AML restent pertinents même lorsque l'intention est signée.
• Révocation et récupération. Arrêtez l'autorité déléguée lorsqu'une information d'identification est compromise, que l'utilisateur retire son consentement ou que le risque change.
• Auditabilité. Conservez le résultat de la vérification, l'artefact d'autorisation, l'identité de l'agent, la décision de transaction, les horodatages et les actions d'examen ultérieures comme preuves distinctes.

Cette conception en couches est délibérément neutre en matière de normes. Une équipe peut adopter TAP à la périphérie du commerçant, les mandats AP2 dans un flux de travail d'agent, Agent Pay pour le règlement par carte, ou une combinaison. La décision d'identité et de fraude reste portable car elle n'est pas intégrée à un seul réseau de paiement.

Comment Didit couvre la moitié de l'identité aujourd'hui

Didit fournit une infrastructure pour l'identité et la fraude utilisée par plus de 2 000 entreprises en production. Les mêmes capacités sont disponibles via un serveur MCP hébergé pour les opérations pilotées par agent et une API REST pour les flux contrôlés par application. Pour un aperçu architectural plus large, voir comment un serveur MCP gère la vérification d'identité et comment MCP connecte l'identité et les contrôles de fraude pour les agents IA.

Le point de terminaison MCP hébergé est https://mcp.didit.me/mcp. Il utilise le protocole Streamable Hypertext Transfer Protocol (HTTP), avec Open Authorization (OAuth) 2.1, Proof Key for Code Exchange (PKCE) et l'enregistrement dynamique de client. Un utilisateur se connecte via la Didit Business Console et accorde un accès limité ; le point de terminaison MCP hébergé n'utilise pas l'authentification par clé API.

Après l'autorisation, un agent peut appeler 115 outils répartis dans 11 catégories. Une séquence de vérification pratique peut utiliser :

didit_context_get
didit_session_create
didit_verify_id
didit_verify_passive_liveness
didit_verify_face_match
didit_session_get_decision

Ces outils peuvent créer une session de vérification, exécuter les vérifications sélectionnées et récupérer une décision structurée. D'autres outils réels incluent didit_verify_aml, didit_verify_kyb_search, didit_verify_kyb_select et didit_transaction_screen_wallet. Les écritures à forte conséquence restent soumises aux autorisations et au comportement de confirmation de l'utilisateur connecté.

L'API REST couvre le chemin de l'application : créez des sessions depuis votre backend, envoyez les utilisateurs via une vérification hébergée ou intégrée, consommez des webhooks et stockez les décisions dans votre propre système. Les requêtes REST de serveur à serveur utilisent un en-tête x-api-key ; ceci est distinct de la connexion MCP hébergée authentifiée par OAuth. Lisez l'aperçu MCP, le guide d'authentification et la référence des outils pour les détails d'implémentation.

La tarification est indépendante de la norme de paiement agentique. Le serveur MCP est gratuit. Un ensemble KYC complet — vérification d'identité, vivacité passive, correspondance faciale et analyse IP — coûte 0,33 $, et chaque compte comprend 500 vérifications gratuites par mois.

Un chemin d'implémentation neutre aux normes

Commencez par définir l'assurance requise pour chaque action, et non par choisir un logo de réseau. Une navigation à faible risque peut nécessiter uniquement la reconnaissance de l'agent. La création de compte peut nécessiter une identité vérifiée. Un achat réglementé peut nécessiter un KYC ou un KYB plus un filtrage AML. Un transfert de crypto peut ajouter un filtrage de portefeuille. Des montants plus élevés ou un risque modifié peuvent ramener l'humain dans la boucle.

Connectez ensuite l'artefact de paiement à la décision d'identité avec des identifiants internes stables. Gardez la signature de l'agent, l'autorisation de l'utilisateur, les preuves de vérification et le résultat du paiement distincts afin que chacun puisse être révoqué, examiné et mis à niveau indépendamment à mesure que les normes évoluent.

Explorez la page développeur Didit MCP ou inspectez le référentiel GitHub public sous licence permissive. Les utilisateurs de Claude peuvent ajouter le connecteur Didit et effectuer la connexion OAuth.

L'architecture durable est stratifiée : les normes de paiement prouvent la participation et l'autorisation de l'agent ; l'infrastructure d'identité et de fraude prouve qui est impliqué et si l'action est acceptable. Cette division permet aux développeurs de prendre en charge les normes actuelles sans coder en dur la confiance à une seule d'entre elles.