Deep Dive: Mastercard Verifiable Intent vs Visa Trusted Agent Protocol

Agentic commerce breaks a core assumption of online payments, that a human is directly clicking “buy” on a trusted surface. Once software can browse, decide, and transact, merchants and networks lose the simplest security primitive: “the customer was here.”

That creates three concrete trust failures that show up as operational costs:

Merchants need a way to distinguish a legitimate, user-authorized agent from malicious automation and bot traffic, without rewriting their stack or blocking valuable sessions by accident.

Payment networks and issuers need a deterministic audit trail of what the user authorized, what the agent did, and what the merchant charged, so disputes and fraud decisions can anchor to evidence rather than inference.

Agents need a portable way to carry proof of authority across merchants, devices, and protocols, in both human-present and human-not-present execution modes.

Both Mastercard Verifiable Intent and Visa Trusted Agent Protocol are “trust layers,” but they sit in different parts of the stack, and they optimize for different verifiers.

Where they differ in stack position and evidence model

I see the contrast as “credential-chain evidence” versus “HTTP-edge attestation.”

Mastercard Verifiable Intent is structured as a multi-party evidence object meant to survive beyond the browsing session. The chain binds issuer identity assurance, user authorization, and agent fulfillment, with explicit integrity bindings between checkout and payment artifacts.

Visa Trusted Agent Protocol is structured as a real-time interaction signal for merchants and their protection layers. The core artifact is a signed HTTP request context, plus linked body objects for consumer recognition and payment container data. It optimizes for “is this a trusted agent interacting with my web property right now,” not “can an issuer adjudicate delegated intent later.”

The trust anchors are different.

Verifiable Intent anchors on a payment-credential issuer (financial institution or network in the issuer role) issuing Layer 1, then user signing Layer 2, then agent signing Layer 3 with keys bound through cnf semantics. This is proof-of-delegation as a cryptographic chain.

Trusted Agent Protocol anchors on program participation and key registries at the web layer, with the agent proving possession of a key through RFC 9421 signatures and the merchant retrieving the public key from a trusted store. Separately, Visa signs the ID token used for consumer recognition in Visa’s implementation.

The privacy posture is also structurally different.

Verifiable Intent uses SD-JWT selective disclosure to make least disclosure a core property: merchant sees checkout mandate disclosures; network sees payment mandate disclosures; the split L3 binding is explicitly designed to preserve that boundary.

Trusted Agent Protocol uses obfuscation and payload partitioning, but it is not built around selective disclosure commitments inside a single credential chain. It expects merchants may need mapping tables to reconcile obfuscated identity fields, and it allows payment container content to vary by checkout method.

If I reduce this to one line: Verifiable Intent is designed for auditability across roles and time; Trusted Agent Protocol is designed for safe interaction and recognition at the merchant boundary.

Integration realities for fintech builders

These solutions are not mutually exclusive. They are addressing different failure modes that will coexist in production.

If I’m building merchant infrastructure, Trusted Agent Protocol maps to immediate engineering artifacts: edge verification of RFC 9421 request signatures, key retrieval and caching, nonce replay tracking, and an internal handler that decides whether to treat an incoming session as “agent commerce intent” based on the tag.

That is the right scope if my pain is bot mitigation false positives and unknown automated traffic. Visa explicitly frames the protocol as a way to avoid blocking legitimate agents and to distinguish them from malicious bots, with minimal merchant changes.

If I’m building wallet, issuer, payments orchestration, or network-adjacent infrastructure, Verifiable Intent is the more relevant primitive because it defines what the verifier can hold onto as dispute evidence and how the authorization chain binds to keys and constraints. The credential format is normative, the constraints vocabulary is normative, and the threat analysis is built around delegation boundaries.

The non-obvious integration cost is key custody and signing surfaces.

Verifiable Intent assumes a user signing key bound in Layer 1 and used to sign Layer 2. The spec explicitly discusses deployment models where “the user creates L2” can mean an authorized system holding the user private key, and it treats user key compromise as full account takeover for the life of the Layer 1 credential.

Trusted Agent Protocol assumes an agent keypair used to sign HTTP message signatures and to sign linked body objects. It treats key discovery and caching as a merchant responsibility and it provides explicit operational guidance around timestamps, expiry, and replay.

If I’m building an agent platform, I plan for both, because I still need to traverse merchant properties safely before I ever reach a payment authorization event.

TAP-like attestation solves “let me browse and interact without being blocked” and provides a channel for merchants to request additional info or payment for access to resources like reviews.

VI-like delegation evidence solves “let me authorize autonomously within user-defined constraints and preserve proof for the network and dispute path,” with explicit binding between checkout and payment mandates.

The standards posture is convergent even if the artifacts differ. Mastercard explicitly says Verifiable Intent builds on widely adopted standards bodies including FIDO Alliance, EMVCo, Internet Engineering Task Force, and World Wide Web Consortium.

Visa explicitly states alignment with standards bodies like the IETF, the OpenID Foundation and EMVCo, and frames Trusted Agent Protocol as built upon the HTTP Message Signatures standard and aligned with Web Bot Auth.

Disclaimer:

Fintech Wrap Up aggregates publicly available information for informational purposes only. Portions of the content may be reproduced verbatim from the original source, and full credit is provided with a “Source: [Name]” attribution. All copyrights and trademarks remain the property of their respective owners. Fintech Wrap Up does not guarantee the accuracy, completeness, or reliability of the aggregated content; these are the responsibility of the original source providers. Links to the original sources may not always be included. For questions or concerns, please contact us at _ sam.boboev@fintechwrapup.com._