Comerç agentiu i la capa d'identitat: Visa TAP, Google AP2 i Mastercard Agent Pay

Punts clau

• Visa Trusted Agent Protocol (TAP), Google Agent Payments Protocol (AP2) i Mastercard Agent Pay fan que les compres gestionades per agents siguin més segures, però resolen diferents parts del problema de confiança.
• TAP ajuda els comerciants a reconèixer agents aprovats i verificar la intenció de comerç signada. AP2 crea evidència del que un usuari va autoritzar. Agent Pay combina agents registrats, credencials de pagament tokenitzades, consentiment i visibilitat de la xarxa.
• Cap d'aquests mecanismes elimina la necessitat de demostrar qui és la persona o l'empresa, examinar el risc, aplicar controls específics de la jurisdicció i conservar un registre d'auditoria.
• Didit és una infraestructura neutral per a la identitat i el frau, no una xarxa de targetes ni una empresa de pagaments. El seu servidor de Protocol de Context de Model (MCP) allotjat exposa 115 eines en 11 categories, mentre que la Interfície de Programació d'Aplicacions (API) de Transferència d'Estat Representacional (REST) admet fluxos de producció incrustats.
• Un paquet complet de Know Your Customer (KYC) costa 0,33 $, cada compte inclou 500 verificacions gratuïtes al mes i el servidor MCP és gratuït.

El comerç agentiu comença quan un agent d'intel·ligència artificial (IA) fa més que recomanar un producte. Compara ofertes, munta un carretó, tria un mètode de pagament i pot completar una compra dins dels límits establerts per una persona o empresa. Aquest canvi crea diverses preguntes de confiança alhora: Quin agent va fer la sol·licitud? Qui la va autoritzar? Qui és la persona o entitat legal darrere? Està permesa la transacció? I quina evidència existirà si es disputa la compra?

Els estàndards de pagament emergents responen a parts importants d'aquesta seqüència. No tots responen a la mateixa part i no s'han de tractar com a intercanviables. Per als desenvolupadors, la pregunta útil no és quina marca “guanyarà”. És quins controls continuen sent necessaris sota cada arquitectura creïble.

Tres estàndards, tres límits de confiança

Visa TAP: pot el comerciant reconèixer i confiar en aquest agent?

Visa Trusted Agent Protocol està orientat al comerciant. La seva tasca principal és ajudar un comerciant a distingir un agent de comerç aprovat d'un rastrejador ordinari, un bot abusiu o una automatització desconeguda. Un agent signa una sol·licitud amb credencials amb límit de temps i propòsit específic. El comerciant o el seu proveïdor de protecció verifica la signatura i pot decidir si permet la navegació, la compra o una acció més limitada.

TAP descriu tres senyals relacionats: una signatura de reconeixement d'agent, una identitat de consumidor o dispositiu vinculada i signada, i un contenidor de pagament vinculat i signat. Aquesta és una separació útil. El reconeixement d'agent estableix quin agent aprovat està present; la intenció signada estableix quin tipus d'interacció se sol·licita; el senyal del consumidor pot ajudar un comerciant a reconèixer un client existent.

Aquest senyal del consumidor no és automàticament equivalent a una nova prova d'identitat. El model de Visa inclou un rol de proveïdor d'identitat a la cadena, però un comerciant encara necessita una política per a un client nou o d'alt risc: quina evidència es va verificar, quina és la força de la garantia, si es requereix KYC i quan és necessària la reverificació. TAP pot transportar informació d'identitat de confiança sense prescriure cada decisió d'incorporació jurisdiccional.

Google AP2: què va autoritzar l'usuari a comprar a l'agent?

Google Agent Payments Protocol se centra en l'autorització i l'evidència. Utilitza mandats signats per connectar la intenció de l'usuari, el contingut de la compra i el pagament. Un mandat obert pot donar a un agent una discreció limitada, com ara restriccions del comerciant o límits de despesa. Un mandat tancat vincula l'aprovació a un carretó i una quantitat específics. Els rebuts completen la cadena d'evidència.

AP2 distingeix els fluxos amb presència humana i sense presència humana. Quan la persona està present, pot aprovar un mandat de compra i pagament tancat directament. Quan està absent, l'agent opera dins de les restriccions prèviament aprovades i signa els mandats tancats finals. Un comerciant o proveïdor de credencials encara pot tornar a incloure la persona en el procés quan no es pot resoldre una restricció.

Aquest disseny respon a "Aquesta persona va autoritzar aquesta acció sota aquestes condicions?" de manera més directa que "Com es va verificar originalment aquesta persona?". El marc d'autorització d'AP2 assumeix que existeixen les credencials d'inscripció i d'usuari rellevants. Per tant, un desenvolupador encara necessita un procés de prova d'identitat i de cicle de vida de les credencials abans que aquests mandats puguin oferir una garantia significativa.

Mastercard Agent Pay: pot la xarxa reconèixer i governar un pagament agentiu?

Mastercard Agent Pay es basa en la tokenització de pagaments. El marc d'acceptació de Mastercard registra i verifica agents, assigna una identitat d'agent única i utilitza Agentic Tokens perquè les transaccions siguin rastrejables i les credencials de pagament romanguin protegides. El reconeixement orientat al comerciant pot funcionar amb la infraestructura de compra existent, mentre que les integracions més profundes admeten un intercanvi de dades més ric.

El model també emfatitza el consentiment del consumidor, l'autenticació i la capacitat dels emissors, adquirents i comerciants per reconèixer que un agent va participar. Això fa que l'activitat de l'agent sigui visible dins d'un model de risc de xarxa de targetes familiar en lloc de fer que l'automatització sigui indistinguible d'una sol·licitud normal de targeta no present.

Agent Pay és més fort en seguretat de credencials de pagament, visibilitat d'agents i controls de xarxa. No elimina l'obligació d'un comerciant de decidir quan s'aplica la verificació d'identitat, Know Your Business (KYB), el control Anti-Money Laundering (AML), les comprovacions d'edat o la revisió millorada. Aquestes decisions depenen del producte, el client, la transacció i la jurisdicció, no només del canal de pagament.

On els estàndards se superposen, i on la identitat encara encaixa

Les tres aproximacions intenten fer que el comerç delegat sigui comprensible. Un comerciant hauria de poder saber que hi ha automatització implicada, verificar que l'agent és de confiança, connectar l'acció amb la intenció de l'usuari, restringir la compra i conservar proves. El seu èmfasi difereix:

• TAP: reconeixement d'agent i intenció signada al límit del comerciant, amb senyals opcionals de consumidor i pagament vinculats.
• AP2: artefactes criptogràfics d'autorització que vinculen la intenció de l'usuari amb els resultats de la compra i el pagament.
• Agent Pay: agents registrats, credencials de pagament tokenitzades, consentiment, autenticació i visibilitat a través de la xarxa de targetes.

La prova d'identitat se situa abans i al costat d'aquests controls. Una autorització signada només és vàlida si la credencial pertany a la persona correcta. Un agent aprovat encara pot ser instruït per un compte sintètic, robat, sancionat, menor d'edat o ineligible. Un token pot protegir les credencials de pagament sense establir que un venedor o beneficiari comercial hagi passat la diligència deguda requerida.

La identitat de l'agent respon a "quin programari va actuar?". L'autorització respon a "què se li va permetre fer?". La verificació d'identitat respon a "qui hi ha darrere?". Els controls de frau i compliment responen a "ha de continuar aquesta acció?".

Què han de construir els desenvolupadors independentment de quina aproximació guanyi

• Inscripció i prova. Verifiqueu la persona o empresa abans de concedir una credencial reutilitzable o una autoritat de despesa delegada. Apliqueu KYC, KYB, vivacitat, documents, bases de dades o controls biomètrics segons el risc.
• Vinculació de credencials. Vinculeu el subjecte verificat a un compte, dispositiu, clau d'accés, cartera o altra credencial que pugui participar en el flux agentiu.
• Autorització amb àmbit. Captureu límits com ara comerciant, categoria, import, freqüència, caducitat i si un humà ha de tornar per a l'aprovació.
• Decisions de risc en temps d'execució. Examineu la persona, l'empresa, la cartera i la transacció en el moment de l'acció. Els controls de Know Your Transaction (KYT) i les comprovacions AML segueixen sent rellevants fins i tot quan la intenció està signada.
• Revocació i recuperació. Atureu l'autoritat delegada quan una credencial estigui compromesa, l'usuari retiri el consentiment o el risc canviï.
• Auditable. Conserveu el resultat de la verificació, l'artefacte d'autorització, la identitat de l'agent, la decisió de la transacció, les marques de temps i les accions de revisió posteriors com a evidència separada.

Aquest disseny en capes és deliberadament neutre respecte als estàndards. Un equip pot adoptar TAP a la vora del comerciant, mandats AP2 en un flux de treball d'agent, Agent Pay per a la liquidació de targetes, o una combinació. La decisió d'identitat i frau segueix sent portable perquè no està incrustada en una única xarxa de pagament.

Com Didit cobreix avui la meitat de la identitat

Didit proporciona infraestructura per a la identitat i el frau utilitzada per més de 2.000 empreses en producció. Les mateixes capacitats estan disponibles a través d'un servidor MCP allotjat per a operacions impulsades per agents i una API REST per a fluxos controlats per aplicacions. Per a una visió general de l'arquitectura més àmplia, vegeu com un servidor MCP gestiona la verificació d'identitat i com MCP connecta les comprovacions d'identitat i frau per a agents d'IA.

L'extrem MCP allotjat és https://mcp.didit.me/mcp. Utilitza Streamable Hypertext Transfer Protocol (HTTP), amb Open Authorization (OAuth) 2.1, Proof Key for Code Exchange (PKCE) i Dynamic Client Registration. Un usuari inicia sessió a través de la Consola de Negocis de Didit i concedeix accés amb àmbit; l'extrem MCP allotjat no utilitza autenticació per clau d'API.

Després de l'autorització, un agent pot cridar 115 eines en 11 categories. Una seqüència de verificació pràctica pot utilitzar:

didit_context_get
didit_session_create
didit_verify_id
didit_verify_passive_liveness
didit_verify_face_match
didit_session_get_decision

Aquestes eines poden crear una sessió de verificació, executar les comprovacions seleccionades i recuperar una decisió estructurada. Altres eines reals inclouen didit_verify_aml, didit_verify_kyb_search, didit_verify_kyb_select i didit_transaction_screen_wallet. Les escriptures d'alta conseqüència segueixen subjectes als permisos i al comportament de confirmació de l'usuari connectat.

L'API REST cobreix la ruta de l'aplicació: creeu sessions des del vostre backend, envieu usuaris a través de la verificació allotjada o incrustada, consumiu webhooks i emmagatzemeu decisions al vostre propi sistema. Les sol·licituds de servidor a servidor REST utilitzen una capçalera x-api-key; això és independent de la connexió MCP allotjada autenticada per OAuth. Llegiu la visió general de MCP, la guia d'autenticació i la referència d'eines per obtenir detalls d'implementació.

El preu és independent de l'estàndard de pagament agentiu. El servidor MCP és gratuït. Un paquet KYC complet —Verificació d'identitat, Liveness passiu, Face Match i Anàlisi d'IP— costa 0,33 $, i cada compte inclou 500 verificacions gratuïtes al mes.

Una ruta d'implementació neutra respecte als estàndards

Comenceu definint la garantia requerida per a cada acció, no escollint un logotip de xarxa. La navegació de baix risc pot necessitar només el reconeixement d'agent. La creació de comptes pot requerir una identitat verificada. Una compra regulada pot requerir KYC o KYB més control AML. Una transferència de criptoactius pot afegir el control de carteres. Imports més alts o un risc canviat poden retornar l'humà al bucle.

Després, connecteu l'artefacte de pagament a la decisió d'identitat amb identificadors interns estables. Mantingueu la signatura de l'agent, l'autorització de l'usuari, les proves de verificació i el resultat del pagament diferents perquè cadascun pugui ser revocat, revisat i actualitzat independentment a mesura que els estàndards evolucionen.

Exploreu la pàgina de desenvolupadors de Didit MCP o inspeccioneu el repositori públic de GitHub amb llicència permissiva. Els usuaris de Claude poden afegir el connector Didit i completar l'inici de sessió OAuth.

L'arquitectura duradora està en capes: els estàndards de pagament proven la participació i l'autorització de l'agent; la infraestructura d'identitat i frau prova qui hi està implicat i si l'acció és acceptable. Aquesta divisió permet als desenvolupadors donar suport als estàndards actuals sense codificar la confiança a un de sol.