Visa Trusted Agent Protocol for Merchants: Verifying AI Agents at Checkout

Short answer: the Visa Trusted Agent Protocol (TAP) lets a merchant cryptographically verify that an incoming request comes from a known AI agent acting for a known consumer, using RFC 9421 HTTP Message Signatures. Visa introduced it on October 14, 2025, co-developed with Cloudflare, and published a reference implementation on GitHub. The agent signs the request, the merchant or its CDN verifies the signature against a public key registry, and a tag value in the header says whether the agent is only browsing or is carrying a real payment instruction. It replaces a bad default, blocking all automated traffic, with a decision you can make per request.

The problem TAP was built for

Until recently, automated traffic was something you defended against. A bot hitting your product pages was almost certainly a scraper, a competitor tracking your prices, or a card tester probing checkout, so the sensible posture was to block anything that did not look like a browser driven by a person. That posture is now expensive. Visa reported a 4,700% rise in AI-driven traffic to US retail sites over the year to late 2025, and said 47% of US shoppers were already using AI for shopping tasks. A meaningful share of the automated requests hitting your storefront are now customers, arriving through an assistant instead of a tab.

The trouble is that a shopping agent and a scraper look identical at the HTTP layer. Both are programs. Both send requests fast. User agent strings are trivially spoofed and IP reputation is a blunt instrument that punishes legitimate cloud-hosted agents. Without a way to tell them apart you get one of two bad outcomes: block everything and turn away buyers, or allow everything and hand your catalog and your checkout to whoever asks. TAP exists to give you a third option.

What is the Visa Trusted Agent Protocol?

TAP is an open specification for proving agent identity inside an ordinary HTTPS request. It does not introduce a new transport, a new endpoint or a new handshake. It adds two header fields to a request you are already receiving, and it builds on RFC 9421, the IETF standard for HTTP Message Signatures, aligned with the Web Bot Auth effort. Visa describes the aim as letting sellers trust AI agents as much as they trust their best customers.

The launch partner list was unusually broad for a network-led specification: Adyen, Ant International, Checkout.com, Coinbase, Cybersource, Elavon, Fiserv, Microsoft, Nuvei, Shopify, Stripe and Worldpay. Cloudflare co-developed it, which matters practically rather than politically. A large share of the web already passes through Cloudflare, so signature verification can happen at the edge before a request reaches your origin, and most merchants will get TAP as a feature of infrastructure they already run rather than as a project they have to staff.

What the signature actually carries

Two header fields do the work. Signature-Input is a structured field carrying the metadata about what was signed, and Signature carries the signature itself. The fields inside Signature-Input are what make the guarantee useful.

Beyond agent recognition, the protocol can convey consumer identity and payment data in the request body, subject to consumer consent: verified consumer identifiers, Payment Account References for stored cards, loyalty numbers, email and phone. That is the part that lets a returning customer be recognized through an agent rather than arriving as an anonymous new session.

What is the difference between agent-browser-auth and agent-payer-auth?

This is the field to build your logic around, and it is the detail most write-ups skip. TAP carries agent intent as one of two exact values in tag. agent-browser-auth means the agent is reading: fetching product pages, comparing prices, assembling a cart, with no commitment. agent-payer-auth means the consumer has authorized this agent to charge a specific amount at your store, so the request should be treated as a binding payment instruction.

Those two deserve genuinely different handling. Browse-intent traffic is an audience question: serve it, make sure your product data is complete enough to be quoted accurately, and stop counting it as an attack. Payment-intent traffic is a checkout question: you now have cryptographic evidence of delegated authority, which is stronger than what you get from a typical card-not-present order, and you can price your fraud posture accordingly. Treating both the same way wastes the distinction the protocol exists to give you.

How does a merchant verify a TAP signature?

1. Detect the headers. Check for Signature-Input and Signature on inbound requests. Absence just means an ordinary request, so nothing about your existing traffic changes.
2. Resolve the key. Take keyid and look up the agent public key in the registry. Visa ships an agent registry component in its reference implementation for exactly this.
3. Validate the envelope before the crypto. Reject anything where expires has passed, alg is not one you accept, @authority is not your domain, or the nonce has been seen before. Cheap checks first.
4. Verify the signature over the covered components per RFC 9421.
5. Branch on the tag. Route agent-browser-auth to your normal catalog path with bot rules relaxed. Route agent-payer-auth into checkout with the delegation evidence attached to the order record.
6. Log the decision. Keep the agent identifier, the tag and the outcome. When a dispute arrives months later, the fact that a specific verified agent presented payment intent is the thing you will want in the file.

Visa published a working reference implementation at github.com/visa/trusted-agent-protocol covering all five pieces: a TAP agent that generates signatures, a React merchant frontend, a FastAPI merchant backend that verifies, a Node.js CDN proxy doing RFC 9421 verification at the edge, and the public key registry. If you are scoping this, read the CDN proxy first, because for most merchants that is where verification belongs.

TAP is a layer on top of Web Bot Auth, not a replacement for it

This is the part that clears up most of the confusion about where TAP fits. The signing mechanism TAP uses is not Visa's invention. It is Web Bot Auth, the Cloudflare and Google authored profile of RFC 9421 that lets any automated client prove which operator it belongs to by signing its requests with an Ed25519 key published at a discoverable directory. TAP adopts that machinery wholesale and adds the payments-specific part on top: tag values that separate an agent that is only browsing from one carrying a consumer-authorized payment instruction, plus the ability to convey a Payment Account Reference and consented consumer identity.

Two practical consequences follow. First, if your edge already verifies Web Bot Auth signatures, you have most of a TAP verifier already, because the signature base, the key resolution and the replay protection are the same code path. Cloudflare shipped signature verification into its Verified Bots Program on July 1, 2025 and AWS WAF added it on November 21, 2025, so a large share of US merchants get this without writing any. Second, the identity layer is moving faster than the payment layer. Shopify began applying its strictest rate limits to unsigned agents on May 30, 2026, which means agent operators have a commercial reason to sign long before any of them have a reason to implement TAP. Expect to see signed agents that carry no payment tag at all, and decide in advance how you will treat them.

Should your business implement TAP?

Honestly, it depends on which side of the transaction you are on, and for a lot of readers the answer is not yet.

One thing to plan for regardless: an agent-initiated order still lands in the same fulfilment, billing and support queue as a human one, except the buyer never saw your site and may not know what they agreed to. If you accept this traffic, look at the back-office and support workflows behind every order before volume arrives, not after. Agentic orders surface returns and dispute questions that a normal checkout flow answers on the confirmation page.

What TAP does not tell you

TAP answers one question extremely well: is this agent who it claims to be, and does it have authority for this specific request at this specific merchant. It deliberately answers nothing else. It does not tell you whether the purchase is a good idea, whether the consumer will recognize the charge, or whether the agent has already made eleven similar purchases today. The signature is scoped to one request by design, and that scope is correct for a merchant-side identity protocol.

The asymmetry is worth stating plainly, because it is where most of the confusion sits. TAP is a gift to the seller. It gives the company that owns the agent nothing at all. If your agents are the ones spending, a perfectly valid agent-payer-auth signature is not reassurance, it is just proof that your agent successfully spent money somewhere. The controls Visa advertises alongside it, the spending limits inside Visa Intelligent Commerce, belong to the consumer mandate and the issuer rather than to your finance team. The same structural gap runs through Google AP2, ACP and x402, and it exists because a rail is built to authorize transactions rather than to govern budgets.

If your agents are the buyers

Then the work is on the other side of the wire and it does not look like signature verification. Every agent needs its own funded wallet with a hard limit, so overspending is structurally impossible rather than merely against policy. Every intended purchase needs checking against policy before a credential exists: per-transaction ceiling, budget over a window, merchant allowlist, velocity rules. Anything above your threshold needs to pause for human approval instead of completing and being discovered at month end. The agent should then receive a scoped virtual card good for that one purchase, riding Visa rails underneath, and every decision belongs in one audit trail covering card spend, stablecoin settlement and metered API calls together.

Both halves are real work and they are not substitutes. Verify agents that come to you. Govern agents that spend for you. If you are weighing which network program to build against first, our comparison of Visa Intelligent Commerce and Mastercard Agent Pay lays out where each one stops.

Frequently asked questions

Is the Visa Trusted Agent Protocol open, or Visa only?

It is an open ecosystem specification with a public reference implementation on GitHub, and it was co-developed with Cloudflare rather than built inside Visa alone. It is not restricted to Visa card transactions. Because it operates at the HTTP layer on agent identity rather than at the payment layer, a merchant can verify a TAP signature regardless of which card or rail eventually settles the purchase.

Does TAP replace bot management?

No, it narrows what bot management has to guess about. Unsigned automated traffic still needs your existing rules. What changes is that a signed request from a registered agent no longer has to be scored on heuristics, so you can stop blocking legitimate shopping agents as collateral damage while keeping your defenses against everything else.

What happens if an agent sends a payment tag it is not entitled to?

Verification fails or the signature is not honored. The tag is inside the signed material, so an agent cannot upgrade a browse request to a payment request without a valid signature from the key the registry lists, over the exact authority, path, nonce and expiry window. That is the point of putting intent inside the signature rather than in a plain header.

Does TAP work with the Agentic Commerce Protocol or Google UCP?

It sits underneath rather than beside them. TAP handles agent identity in the HTTP request; ACP and UCP describe how a catalog and checkout are exposed to agents. Visa has been explicit about protocol neutrality, and Intelligent Commerce Connect accepts payments initiated through several competing agent protocols, so implementing TAP does not commit you to a checkout standard.