Visa
Trusted Agent Protocol: The Merchant’s Side of the Payment
Tokens solve the issuer’s problem: the agent does not hold the card number. They do not solve the merchant’s problem. A merchant’s edge looks at traffic and has spent twenty years learning that automated traffic at checkout is an attack. A Find & Buy Agent that shows up as a browser with a stolen cookie will be treated like one. Visa’s Trusted Agent Protocol is the attempt to make the agent legible instead.
What TAP is
Visa introduced the Trusted Agent Protocol on 14 October 2025, developed with Cloudflare and built on the HTTP message signature standard. The merchant can verify a signed agent request. The signature is how the request claims an identity. Verification is how the merchant checks that the identity is the one it thinks it is, and that the message was not rewritten on the way.
That is a different object from a login. A login says a human session exists. A TAP signature says a registered agent is speaking, and the bytes of this request are its. In the October 2026 BILL and Billtrust pilot, the distinction stopped being theoretical. The buyer’s agent is registered using the protocol and Visa’s agentic directory. The supplier platform recognizes that agent and lets it complete an approved payment, instead of forcing a person to type into a portal that was never going to be automated.
The firewall paradox
Security teams were not wrong to hate bots. Card testing, credential stuffing, and inventory hoarding are automated, and they look, at the edge, like a careful shopping agent. The mistake was having only one bucket. TAP’s bet is a second door: unverified automation still dies at the wall; attested agents are routed to a catalog or checkout API that can speak in structured data rather than in pixels.
A Find & Buy Agent should prefer that door even when scraping would be faster. Scraping borrows a human interface and then has to lie about being human. The lie is the entire fraud model. An agent that signs its request can be refused honestly — not registered, mandate missing, merchant not in scope — and the refusal is a protocol response, not a CAPTCHA.
What the merchant learns, and what it still must not trust
- That this request was signed by an agent identity the directory will stand behind.
- That the agent is acting under a principal’s instruction, when the signature is bound to a mandate rather than to a blank “pay anything” key.
- Not that the principal wanted this specific SKU if the mandate was vague. Identity is not intent.
- Not that the price is fair. TAP does not shop.
Merchants who treat a TAP pass as permission to skip product accuracy will lose the next dispute. The agent believed the feed. If the feed said refundable and the ticket was not, the signature that proves the agent was real also proves what the merchant claimed. Recognition cuts both ways.
A directory is not a marketplace
Visa’s agentic directory, as used in the BILL pilot, is a place an agent is registered so a counterparty can resolve the signature to a known actor. It is not a store, and it should not become one. The moment the directory is the only place an agent is allowed to shop, the protocol has collapsed back into a mall. Find stays competitive — many merchants, many endpoints. Buy stays accountable — one signed actor, one mandate, one token.
For FindBuyAgent.com that means the shopping surface can remain a phone, a link, and a photo. The payment surface, when it is a Visa purchase, should be able to present an agent the merchant can verify. We do not pretend that signature exists in the demo. We do insist that the product’s shape — find freely, buy only after approval — is the shape TAP is for.
Published by FindBuyAgent.com. Canonical URL findbuyagent.com/blog/trusted-agent-protocol.