Visa Trusted Agent Protocol

Visa's Trusted Agent Protocol (TAP) is an open framework that enables merchants to distinguish legitimate AI shopping agents from bots, verify agent authorization to transact on behalf of a user, and process payments securely using delegated credentials.

Posted Apr 19, 2026

8 min read

Visa’s Trusted Agent Protocol (TAP) is an open framework that enables merchants to distinguish legitimate AI shopping agents from bots, verify agent authorization to transact on behalf of a user, and process payments securely using delegated credentials. Built on existing web standards (HTTP Message Signatures, JWT, WebAuthn), it is designed to slot into current merchant infrastructure with minimal changes.

What is it?

TAP solves a specific problem that sits upstream of payment processing: how does a merchant know that the AI agent arriving at their checkout is legitimate, authorized by a real user, and not a scraper or fraud bot?

Visa introduced TAP in 2025 as part of its broader Visa Intelligent Commerce (VIC) initiative. The protocol was developed in collaboration with Cloudflare and is available via the Visa Developer Center and GitHub. Visa has been running pilots with over 100 partners globally, with 30+ actively building in the VIC sandbox and 20+ agents and agent enablers integrating directly.

TAP is not a full commerce protocol (that is UCP’s role) or a payment authorization protocol (that is AP2’s or ACP’s role). TAP is an identity and trust layer – it answers the question “is this agent who it claims to be, and is it authorized to act for this user?” Once trust is established, the actual payment flows through existing Visa network infrastructure.

Problem it solves

As AI agents begin transacting at scale, merchants face a new version of the bot problem:

Agent vs. bot disambiguation – A merchant’s checkout receives an HTTP request claiming to be from “ChatGPT Shopping Agent.” Is it really ChatGPT, or is it a scraper posing as one? Merchants currently have no standardized way to verify agent identity.
Authorization verification – Even if the agent is legitimate, how does the merchant verify that this specific user authorized this specific agent to make this specific purchase? A stolen session token or a compromised agent could initiate unauthorized transactions.
Credential exposure – If agents need card numbers to transact, every agent becomes a target for credential theft. The attack surface multiplies with every agent integration.
Liability clarity – When a transaction is disputed, current chargeback rules assume a human initiated the purchase. Agent-mediated transactions create ambiguity about who bears liability.

TAP addresses all four by providing a cryptographic identity framework where agents prove who they are, what they are authorized to do, and merchants can verify both claims without trusting the agent itself.

Architecture / How it works

Trust establishment flow

┌──────────┐     ┌──────────────┐     ┌─────────────┐     ┌──────────┐
│   User   │     │   AI Agent   │     │  Merchant   │     │   Visa   │
│          │     │              │     │             │     │          │
└────┬─────┘     └──────┬───────┘     └──────┬──────┘     └────┬─────┘
     │                  │                     │                 │
     │ 1. Register +    │                     │                 │
     │ delegate to agent│                     │                 │
     │─────────────────>│                     │                 │
     │                  │                     │                 │
     │                  │ 2. Agent registers  │                 │
     │                  │ with Visa (gets     │                 │
     │                  │ keypair + ID token) │                 │
     │                  │────────────────────────────────────-->│
     │                  │                     │                 │
     │                  │ 3. Initiate purchase│                 │
     │                  │ (signed request +   │                 │
     │                  │  ID token)          │                 │
     │                  │────────────────────>│                 │
     │                  │                     │                 │
     │                  │                     │ 4. Verify agent │
     │                  │                     │ (check signature│
     │                  │                     │  + validate JWT │
     │                  │                     │  via Visa keys) │
     │                  │                     │────────────────>│
     │                  │                     │                 │
     │                  │                     │ 5. Process via  │
     │                  │                     │ Visa network    │
     │                  │                     │────────────────>│
     │                  │                     │                 │
     │                  │ 6. Confirmation     │                 │
     │                  │<────────────────────│                 │

Key technical components

Agent keypair and HTTP Message Signatures (RFC 9421)

Every registered agent holds a cryptographic keypair. When the agent sends a purchase request to a merchant, it signs the HTTP message using RFC 9421 (HTTP Message Signatures). The merchant retrieves the agent’s public key from Visa’s well-known URL and verifies the signature. This proves the request genuinely came from the registered agent and was not tampered with in transit.

ID Token (JWT per RFC 7519)

Visa issues a JSON Web Token to the agent, digitally signed by Visa. The token contains the agent’s identity, capabilities, and the user delegation scope. Merchants validate this token using Visa’s public key (per JWS specification RFC 7515). This is compatible with OpenID Connect, so merchants with existing OIDC infrastructure can integrate with minimal changes.

Public key infrastructure

Visa hosts a well-known URL (/.well-known/visa-tap) for public key retrieval. Merchants fetch the agent’s public key from this endpoint to verify message signatures. This is the same pattern used by OpenID Connect discovery and JWKS endpoints – no new infrastructure required.

Payment credential delegation

The agent never sees the user’s raw card number. Instead, Visa issues a hashed Intelligent Commerce payment credential that the agent passes to the merchant. The merchant processes this credential through the standard Visa network. If the credential is intercepted, it cannot be used outside the specific agent-merchant-transaction scope.

Key concepts

Web Bot Auth integration

Both Visa and Mastercard leverage Web Bot Auth as the agent authentication layer at the network edge. Cloudflare (Visa’s development partner) can verify at the CDN level whether incoming traffic is from a registered AI agent or an unidentified bot. This happens before the request even reaches the merchant’s servers.

This is the practical difference TAP makes: a merchant behind Cloudflare can automatically reject unverified agent traffic while fast-tracking verified agents, without writing any custom bot-detection logic.

Visa Intelligent Commerce (VIC)

TAP is one component of Visa’s broader VIC initiative, which includes:

Trusted Agent Protocol – Agent identity and authorization (this document).
VIC Sandbox – Testing environment for agent developers.
VIC Payment Credentials – Delegated tokens for agent-mediated payments.
Merchant integration toolkit – SDKs and documentation for accepting agent-initiated transactions.

Spending controls

Users can set constraints on their agent delegations:

Maximum transaction amount
Merchant category restrictions
Geographic limits
Time-based expiration
Cumulative spending caps

These constraints are encoded in the delegation token and enforced by the Visa network at authorization time, not by the agent. The agent cannot override them.

Comparison: Visa TAP vs. Mastercard Agent Pay / Verifiable Intent

Dimension	Visa Trusted Agent Protocol	Mastercard Verifiable Intent + Agent Pay
Trust anchor	Program participation + key registries at web layer	Payment-credential issuer with Layer 1-2-3 delegation chain
Signature model	RFC 9421 HTTP Message Signatures	SD-JWT with `cnf` proof-of-delegation semantics
Privacy	Agent presents ID token + signed request	SD-JWT selective disclosure (least-disclosure by design)
Token type	Hashed VIC payment credential	16-digit tokenized card number with spending parameters
Standards	IETF, OpenID Foundation, EMVCo, Web Bot Auth	FIDO Alliance, EMVCo, IETF, W3C
Edge authentication	Cloudflare integration	Cloudflare integration (both use Web Bot Auth)
Maturity	Hundreds of pilot transactions, 100+ partners	Similar pilot stage

The architectural philosophies differ. Visa anchors trust at the web layer – agents register with Visa, get keys, and merchants verify at the HTTP level. Mastercard anchors trust at the payment credential layer – the issuer creates a signed delegation chain from card to user to agent, with each layer adding cryptographic proof.

Mastercard’s approach has a stronger privacy property through SD-JWT selective disclosure (merchants see only what they need for checkout, the network sees only what it needs for payment). Visa’s approach is simpler to integrate because it uses standard HTTP signatures that any web developer understands.

For merchants, the practical difference is minimal in the near term – both require registering with the respective network’s sandbox and adding signature verification middleware. In the medium term, the market will likely converge on a single standard, or both will be required (similar to accepting both Visa and Mastercard today).

Relationship to ACP and UCP

TAP is complementary to both commerce protocols:

With ACP: TAP can verify agent identity before ACP checkout begins. OpenAI has indicated alignment between ACP and Visa TAP. An agent arrives at a merchant’s ACP endpoint, TAP verifies the agent’s identity, then ACP handles the checkout flow with Stripe processing the payment.
With UCP: TAP can serve as an identity verification layer alongside AP2’s Mandate model. UCP orchestrates the commerce flow, AP2 handles payment authorization, and TAP provides an additional layer of agent identity verification at the Visa network level.

TAP does not compete with ACP or UCP – it solves a different problem (identity) that both commerce protocols need but neither fully addresses on their own.

Current adoption / Maturity

Pilot status: Hundreds of secure, agent-initiated transactions completed in pilot with ecosystem partners.
Partner scale: 100+ partners globally, 30+ building in VIC sandbox, 20+ agent platforms integrating directly.
Geographic expansion: Asia Pacific and Europe pilots anticipated in early 2026. Latin America readiness being prepared.
Production timeline: Visa predicts millions of consumers will use AI agents to complete purchases by the 2026 holiday season. This suggests production rollout in H2 2026.
Developer access: Spec and SDK available via Visa Developer Center and GitHub.

Market context

Visa’s positioning statement is that 2025 was “the final year consumers shop and checkout alone.” Whether or not that proves true, the investment signals are clear: Visa, Mastercard, and the major card networks are all building agent payment infrastructure. The question is not whether agent-mediated payments will happen, but which trust and identity framework becomes the standard.

Spec links

Visa Developer Center: https://developer.visa.com/capabilities/trusted-agent-protocol/overview
Specifications: https://developer.visa.com/capabilities/trusted-agent-protocol/trusted-agent-protocol-specifications
Visa Intelligent Commerce: https://corporate.visa.com/en/products/intelligent-commerce.html

References

AI & Agents, Protocols

agent-patterns

This post is licensed under CC BY 4.0 by the author.