Visa Europe, TAP and Payment Passkeys: what is proven
Published . Product claims are attributed to Visa; independent measurements are identified as missing.
Short answer: Visa stated on 2 July 2026 that AI agents had completed purchases in live environments at participating European merchant sites, using Trusted Agent Protocol signals to identify agents and Visa Payment Passkeys to authenticate cardholders. Visa named more than 30 issuers and four merchants: lastminute.com, Frasers, Cleverbridge and BrickDepot. That is stronger evidence than an unnamed sandbox demonstration. It remains a supplier announcement. Visa did not publish transaction counts, completion rates, consumer counts, an audit report or a control group.
What Visa says happened
In its 2 July release, Visa says agents browsed products, selected items and initiated purchases at participating independent merchants, within user-defined parameters. The company describes the transactions as taking place in live environments rather than controlled storefront tests.
The same release names the issuer group and participating merchants, and says every transaction in the programme used Visa Payment Passkeys. It also says Cloudflare and Akamai supported merchant-side implementation of the agent-recognition layer.
Those are precise, attributable statements. They support the conclusion that Visa operated a named live programme. They do not establish its scale or economics.
Three separate trust questions
| Question | Mechanism in Visa's account | What it does not establish alone |
|---|---|---|
| Who is calling the merchant? | TAP agent-recognition signature and Agent Directory | That the requested purchase is appropriate |
| Which customer is involved? | Linked consumer or device identity, where provided | That the customer approved this exact amount and basket |
| Who authorized payment? | Visa Payment Passkey tied to user instruction | How a later refund, return or dispute will be resolved |
What TAP adds at the merchant edge
The official TAP merchant specification is designed for a difficult case: an approved agent is initially unknown to the merchant and arrives through ordinary web or message infrastructure. A conventional bot-control system could treat it like a scraper or an attack.
TAP describes three linked signatures:
- an agent-recognition signature in a message header;
- a signed consumer or device identity in the request body, when applicable;
- a signed payment container for payment-related information.
The merchant or its site-protection provider retrieves public keys and verifies the signals. It can then apply its own policy to the interaction. The specification says merchants may ignore the mechanism, so TAP is a signal framework rather than a mandatory internet gate.
The specification also distinguishes the generic TAP framework from Visa-specific examples. That distinction should be preserved when documenting an implementation.
Where Payment Passkeys fit
TAP identifies and describes the agent interaction. Payment Passkeys address cardholder authentication in Visa's implementation. Visa says the passkey flow linked participating transactions to a verified user and explicit instruction, and supported issuer compliance with European Strong Customer Authentication requirements.
Legal limit: this article reports Visa's statement. It does not conclude that a merchant, issuer or agent implementation complies with SCA or any other legal duty. Compliance depends on roles, flow, evidence and jurisdiction, and requires qualified review.
Evidence table
| Claim | Status | Reason |
|---|---|---|
| Visa announced live European agentic transactions | Confirmed as a Visa statement | Dated official release with named programme participants |
| TAP has a published merchant specification | Confirmed | Technical specification is publicly readable on Visa Developer |
| Payment Passkeys authenticated all transactions in the programme | Provider-claimed | Visa states this; no independent transaction dataset was published |
| More than 30 issuers participated | Provider-claimed with names | Visa lists the institutions in its release |
| The programme improves conversion or fraud outcomes | Not measurable from the source | No outcome comparison is published |
| Agentic commerce is broadly adopted in Europe | Not established | A named programme is not a market-wide adoption measure |
Questions a merchant should ask before integration
- Which agents and payment schemes can produce the signals the merchant will accept?
- Who maintains the trust registry and signing keys?
- What happens when a signature is missing, expired or invalid?
- Which browsing data is available before the customer is identified?
- How is the exact basket, amount and instruction bound to authentication?
- How do the merchant's bot controls, fraud engine and checkout consume the signal?
- Which logs are retained for support, refund and dispute handling?
For the broader verification layer, read how merchants verify AI agents. For operational controls after recognition, use the agentic payment controls guide.