How Visa Trusted Agent Protocol gives merchants a cryptographic way to tell good shopping agents from bots before checkout.
What is the Visa Trusted Agent Protocol?
The Visa Trusted Agent Protocol (TAP) is an open framework that lets an AI shopping agent cryptographically prove its identity, the consumer’s consent, and its purchase intent directly to a merchant during checkout. Visa introduced it on October 14, 2025 as an ecosystem-led specification co-developed with Cloudflare, and it is published as an open framework on GitHub under visa/trusted-agent-protocol.
The problem TAP solves is blunt. Merchants have always sorted human traffic from bots using the user-agent string and IP address, but as Cloudflare notes, both fields can be trivially spoofed. With AI-driven traffic to U.S. retail sites surging 4,700% over the past year, that old defense is useless: a legitimate shopping agent and a credential-stuffing bot can look identical. The Visa Trusted Agent Protocol replaces a guessable label with a cryptographic signature a merchant can actually verify.
Crucially, TAP is a trust and identity layer, not a new payment rail. It does not move money on its own. Instead it rides on top of the existing HTTPS request your agent already sends, attaching signed headers that attest who the agent is and what it is authorized to do. That design choice means merchants can adopt it with minimal UX changes rather than rebuilding checkout.
How does the Visa Trusted Agent Protocol work technically?
TAP works by having the agent attach RFC 9421 HTTP Message Signatures to its requests, which a merchant (or its CDN) verifies against a public-key directory that Visa operates. It builds on the same Web Bot Auth foundation that lets a bot present a stable, verifiable identifier using public-key cryptography rather than a spoofable string.
The mechanics are tractable for any builder who has handled signed requests before. The agent registers and publishes its public key in a well-known directory. On each request it adds a Signature-Input header containing the keyid (a pointer to that public key), a creation and expiry timestamp, a unique nonce, and a tag such as agent-browser-auth for the browsing phase or agent-payer-auth at payment. A separate Signature header carries the actual ed25519 signature.
The merchant side, often handled at the edge by a provider like Cloudflare, runs a tight verification sequence: confirm the signature headers exist, fetch and cache the keyid from the directory, check the timestamps fall inside the valid window, reject reused nonces to block replay attacks, confirm the tag matches the interaction, reconstruct the canonical signature base, and finally run ed25519 verification. If it all checks out, the merchant knows it is talking to a registered agent acting with consent.
The GitHub reference implementation ships five runnable components: a TAP agent for signature generation, a React merchant frontend, a FastAPI verification backend, a Node CDN proxy, and an agent registry. Builders can stand the whole loop up locally before committing to a vendor SDK.
POST /checkout HTTP/1.1
Host: merchant.example
Signature-Input: sig1=("@authority" "@path");\
created=1730000000; expires=1730000300;\
keyid="visa-dir:agent-xyz"; nonce="a1b2c3";\
tag="agent-payer-auth"
Signature: sig1=:MEUCIQ...ed25519-signature...:
# Merchant/edge verification (pseudocode)
# 1. headers present? 2. fetch keyid from Visa directory
# 3. timestamps in window? 4. nonce unused? 5. tag matches phase?
# 6. rebuild signature base 7. ed25519_verify(pubkey, base, sig)What does the Visa Trusted Agent Protocol let a merchant verify?
The Visa Trusted Agent Protocol lets a merchant verify three distinct things: the agent’s intent, whether it represents a recognized consumer, and trusted payment information. Visa packages these as the protocol’s three core data elements, and they map cleanly to the moments a merchant cares about.
First, Agent Intent signals that this is a trusted agent with intent to retrieve product details or purchase a specific item, letting the merchant distinguish it from a scraping or rogue bot. Second, Consumer Recognition carries data elements indicating whether the consumer already has an account or has previously interacted with the merchant, so the agent’s session can be personalized rather than treated as a cold stranger. Third, Payment Information lets the agent carry payment data that fits the merchant’s preferred checkout method.
On that payment element, TAP does not stuff identity into the card token. Instead the agent can pass a tokenized credential, such as a one-time card token or a hash of the card data tied to Visa Intelligent Commerce. Merchants validate that credential against Visa’s public key, with the signature following the JSON Web Signature spec (RFC 7515). The agent can even pass card metadata so the merchant displays the right card art and product name, smoothing the consumer-facing experience.
Browsing phase (agent-browser-auth)
During product discovery, the agent presents Agent Intent and optional Consumer Recognition so the merchant serves accurate pricing and availability to a trusted, non-malicious agent rather than rate-limiting or blocking it.Payment phase (agent-payer-auth)
At checkout the agent adds the Payment Information element with a tokenized Visa Intelligent Commerce credential. The merchant verifies the signature and the token, completing the purchase with cryptographic proof the agent was authorized.How does TAP differ from ACP, AP2, and x402?
TAP differs from ACP, AP2, and x402 because they operate at different layers of the agentic-commerce stack: TAP is the identity and trust layer, not a checkout flow, a spending mandate, or a payment rail. Treating them as rivals is the most common analyst mistake; in practice a production system composes several of them. We unpack the full landscape in our agentic payment protocols compared guide.
The cleanest mental model: AP2 (Google’s Agent Payments Protocol) defines what an agent is allowed to spend via a cryptographic mandate signed by the buyer; ACP (the Agentic Commerce Protocol behind OpenAI and Stripe’s Instant Checkout) handles product discovery and the checkout flow; x402 revives the HTTP 402 status code for instant machine-to-machine payment execution, often onchain; and the Visa Trusted Agent Protocol supplies the cryptographic proof of who the agent is and that the consumer consented. Visa has explicitly said TAP is designed to complement ACP, and it is collaborating with Coinbase on x402 interoperability.
So a real flow might use ACP for vendor discovery, an AP2-style mandate for spending governance, the Visa Trusted Agent Protocol to prove the agent’s identity to the merchant, and the card network to settle. None of these fully replaces another. The Visa Trusted Agent Protocol’s bet is that identity is the layer everyone else has to trust, regardless of which checkout flow or rail wins.
| Protocol | Layer | Core question it answers | Backed by |
|---|---|---|---|
| Visa Trusted Agent Protocol (TAP) | Identity / trust | Is this agent real and consented? | Visa, Cloudflare |
| AP2 | Authorization / mandate | What is this agent allowed to spend? | Google + partners |
| ACP | Discovery / checkout flow | How does the agent find and buy the item? | OpenAI, Stripe |
| x402 | Payment execution | How does value actually move, instantly? | Coinbase + ecosystem |
Who is behind the Visa Trusted Agent Protocol and when does it go live?
4,700%
surge in AI-driven traffic to U.S. retail sites
Visa / Cloudflare, past year
12
launch partners for TAP
October 14, 2025
100+
partners across Visa Intelligent Commerce
Dec 2025 update; figures move
47%
of U.S. shoppers using AI for a shopping task
Visa, Dec 2025
The Visa Trusted Agent Protocol launched with twelve initial partners and sits inside Visa Intelligent Commerce, which now spans 100+ partners, with mainstream consumer rollout targeted for the 2026 holiday season. The launch cohort included Adyen, Ant International, Checkout.com, Coinbase, CyberSource, Elavon, Fiserv, Microsoft, Nuvei, Shopify, Stripe, and Worldpay, alongside co-developers Visa and Cloudflare.
Momentum has continued into 2026. In a December 18, 2025 update, Visa said it and its partners had completed hundreds of secure, agent-initiated transactions in controlled production environments, with named participants including Skyfire, Nekuda, PayOS, and Ramp. Visa frames Visa Intelligent Commerce as having 30+ partners actively building in its sandbox and 20+ agents and agent enablers integrating directly. The company predicts millions of consumers will use AI agents to complete purchases by the 2026 holiday season.
The figures move quickly, so treat partner counts and transaction milestones as snapshots rather than guarantees. What is stable is the architectural direction: an open, signature-based identity layer that aligns with IETF, the OpenID Foundation, and EMVCo, designed so the broader ecosystem (including Mastercard’s parallel Agent Pay work) can interoperate rather than fragment.
“The entire payments ecosystem has a responsibility to ensure sellers can trust AI agents as much as they trust their best customers.”
Jack Forestell, Chief Product and Strategy Officer, Visa
Should merchants and builders adopt the Visa Trusted Agent Protocol now?
Adopt the identity layer early, scope it narrowly
Merchants and builders should start integrating the Visa Trusted Agent Protocol now in test environments, because the verification layer is what lets you welcome legitimate agents without opening the door to spoofed bots. The riskiest posture in 2026 is a blanket block on automation, which quietly kills conversion from a fast-growing channel of AI agents that are ready to buy.
For merchants, the practical first step is wiring signature verification at the edge (the GitHub repo’s CDN proxy is a working template) and treating verified agents as an allow-list rather than retraining your entire bot ruleset. Because TAP requires minimal UX changes and rides existing HTTPS, the integration cost is closer to adding a header check than rebuilding checkout. For agent builders, the work is key management: register your public key in the directory, sign requests with RFC 9421, and isolate private keys per deployment so a single leak cannot impersonate your whole fleet.
The honest caveat is maturity. As of mid-2026 this is early-production, not a settled standard, and consumer-scale volume is still ahead of the holiday rollout. Build to the open specification rather than a single SDK, keep your identity layer cleanly separated from your payment rail, and you will be positioned to support the Visa Trusted Agent Protocol and whatever interoperable directories emerge alongside it.
Builder’s take
I build Cyntr, an agent-orchestration runtime, so I spend my days thinking about how an agent proves who it is to a system that has every reason to be suspicious. The Visa Trusted Agent Protocol is the first card-network attempt to make that proof a boring, verifiable header rather than a vibe. That is a bigger deal than the press releases convey.
- Treat TAP as identity plumbing, not a payment method. Your agent still needs an authorization layer (AP2-style mandates) and an execution rail. TAP only answers ‘is this agent real and consented?’ Do not over-scope it.
- If you operate a merchant surface, the dangerous default is blocking all automation. TAP lets you allow-list verified agents instead of nuking conversion. Wire signature verification at the edge before you tighten your bot rules.
- Rotate and scope your keys like you mean it. The whole model collapses to spoofing if an agent’s ed25519 private key leaks, so on Cyntr we treat per-deployment key isolation as non-negotiable from day one.
- Build to the open spec on GitHub, not to a single vendor’s SDK. The protocol is RFC 9421 plus Web Bot Auth; if you keep that layer clean you can support Visa’s directory and others without a rewrite.
Frequently asked questions
It is an open framework that lets an AI shopping agent cryptographically prove to a merchant that it is a legitimate, consented agent rather than a malicious bot. Visa launched it on October 14, 2025 with Cloudflare, and it works by adding signed headers to the agent’s normal web requests that the merchant verifies.
No. TAP is an identity and trust layer, not a payment rail. It rides on top of existing HTTPS requests and can carry a tokenized payment credential, but the actual settlement still flows through standard card-network or processor infrastructure.
The merchant (often via its CDN) checks the agent’s RFC 9421 HTTP Message Signature: it fetches the agent’s public key from Visa’s directory using the keyid, validates timestamps and the nonce to prevent replay, and runs an ed25519 signature check. If verification passes, the agent is trusted for that interaction.
They sit at different layers. ACP handles checkout flow, AP2 defines spending mandates, and x402 executes payments, while the Visa Trusted Agent Protocol supplies the identity and trust layer underneath them. Visa designed TAP to complement these protocols rather than compete with them.
Visa is targeting mainstream consumer adoption around the 2026 holiday season, predicting millions of consumers will use AI agents to complete purchases by then. Hundreds of controlled agent-initiated transactions were already completed by a December 2025 update, but figures move quickly.
Yes. It is published as an open framework on GitHub at visa/trusted-agent-protocol and in the Visa Developer Center, with a reference implementation that includes an agent, a merchant frontend and backend, a CDN proxy, and an agent registry. It builds on open standards including RFC 9421 and Web Bot Auth.
Primary sources
- Visa Introduces Trusted Agent Protocol: An Ecosystem-Led Framework for AI Commerce — Visa
- Visa and Partners Complete Secure AI Transactions, Setting the Stage for Mainstream Adoption in 2026 — Visa
- Securing agentic commerce: helping AI Agents transact with Visa and Mastercard — Cloudflare
- visa/trusted-agent-protocol (open framework and reference implementation) — GitHub / Visa
- Agentic Payments: The Complete Protocol Comparison (x402 vs ACP vs AP2 vs TAP) — HyperTrends
- Trusted Agent Protocol overview — Visa Developer
Last updated: May 30, 2026. Related: Commerce.
