An agent shops on a merchant website with a Visa card

The situation

A consumer asks an AI agent to buy one item from a merchant’s own website and pay with a Visa card already linked to the agent. The agent browses like a person would, but it signs every request so that the merchant’s CDN can tell it apart from an unknown bot. The consumer is present at one moment only: to approve the purchase with a passkey.

Two Visa layers work together here. The Trusted Agent Protocol (TAP) lets the agent prove its identity by signing its web requests, and it does not move money by itself.^{Source [1, 2, 3]} Visa presents TAP as an enhancement to Visa Intelligent Commerce (VIC), which holds the consumer’s consent, the limits and the agent-specific token.^{Source [1, 3, 4]}

Parts of this run live today. Visa says live European agent purchases used TAP and the Agent Directory, at merchant websites rather than test storefronts.^{Source [5]} Cloudflare and Akamai support TAP at the infrastructure level.^{Source [5]} No count of merchants that verify TAP signatures is published, and the specification page has no version number or date.^{Source [1, 5]}

Actors

• Consumer, who approves the Payment Instruction with a passkey.
• AI agent, an Agent Provider: a certified AI platform onboarded to the payment scheme.^{Source [1]}
• Visa Intelligent Commerce, which enrolls the card, holds instructions and returns credentials.
• Visa key store, the public JWK Set that verifiers use.^{Source [1]}
• CDN, a Site Protection Provider in front of the merchant site.^{Source [1]}
• Merchant, which may verify signatures itself or let the CDN do it.^{Source [1]}
• Acquirer, network and issuer, on ordinary card rails.

Step by step

1. Ask (no protocol). The consumer names the item and the merchant.
2. Enroll the card (VIC). The agent enrolls the card with POST /vacp/v1/cards, as Visa’s VIC API client names the call.^{Source [6]} VIC provisions an agent-specific token after step-up verification of the cardholder and setup of a passkey.^{Source [3]}
3. Browse with a signature (TAP). The agent sends RFC 9421 Signature-Input and Signature headers.^{Source [1, 7]} The signature covers at least @authority and @path and carries created, expires, keyid, alg, nonce and tag.^{Source [1]} For browsing the tag is agent-browser-auth.^{Source [1]}
4. Fetch the key (TAP). The CDN resolves keyid against Visa’s key store. On 2026-10-11 that JWK Set held one 2048-bit RSA key and no Ed25519 key.^{Source [8]} The key carried a certificate for vic-oauth-jwe.visa.com from a Visa sandbox issuing CA.^{Source [8]} Visa has not published how production agent keys are distributed.^{Source [1, 8]}
5. Verify at the edge (TAP). The CDN checks, in order, the tag, the minimum fields, the time window, the nonce, the key and the signature.^{Source [1]} The window is at most 8 minutes.^{Source [1]}
6. Forward (TAP). The CDN passes the request on as a verified agent.^{Source [9]}
7. Product page (TAP). The merchant returns product details, availability and the final cost after taxes and shipping.^{Source [1]} It may show a simpler agent-specific page.^{Source [1]}
8. Create a Payment Instruction (VIC). The agent calls POST /vacp/v1/instructions.^{Source [6]}
9. Approve with a passkey (VIC). The consumer authenticates the instruction with a passkey before the agent can retrieve credentials.^{Source [3]}
10. Get credentials (VIC). The agent calls POST /vacp/v1/instructions/{instructionId}/credentials.^{Source [6]}
11. Check out with the payer tag (TAP). The agent signs with agent-payer-auth.^{Source [1]} VIC payments start as guest checkout with key entry, so the agent fills the merchant’s card form.^{Source [3]} The body carries agenticConsumer (nonce, idToken, contextualData, kid, alg, signature) and agenticPaymentContainer (nonce, kid, alg, signature).^{Source [1]} For key-entered guest checkout the container carries a payment credential hash.^{Source [1]} Both objects use the header’s key and nonce.^{Source [1]}
12. Verify the payer signature (TAP). The CDN repeats the header checks for the payer tag.^{Source [1]}
13. Verify the body (TAP). The merchant verifies each object over all fields in the order received except the signature.^{Source [1]} If its own hash of the key-entered card data does not match, it should decline.^{Source [1]}
14. Authorize (card rails). The merchant authorizes through its acquirer; TAP plays no part in this step.^{Source [1, 3]}
15. Confirm (no protocol). The merchant returns the order result; TAP defines no receipt.^{Source [1, 3]}
16. Report (VIC). The agent calls POST /vacp/v1/instructions/{instructionId}/confirmations.^{Source [6]}

Which protocol does what

Two warnings for implementers. The specification’s header examples reuse a Web Bot Auth draft test vector that signs a different base.^{Source [1, 10]} Its browsing and checkout examples show the same signature under different tags, and its example window is 3,600 seconds, so the examples cannot verify.^{Source [1]} TAP publishes no test vectors.^{Source [1, 11]}

Where controls apply

• Before authorization. VIC holds consent: the consumer approves each Payment Instruction with a passkey.^{Source [3]} Spending limits and step-up also sit in VIC, invisible to the merchant in the TAP request.^{Source [1, 3]}
• At signing. TAP allows extra signature fields beyond the minimum.^{Source [1]} The minimum leaves out @method, the query string and a content digest, so an agent platform that adds them narrows what a stolen signature could be reused for.^{Source [1]}
• At the edge. The CDN is the natural verifier.^{Source [1]} Nonce checks work only if the verifier keeps an 8-minute record.^{Source [1]} The sample CDN proxy checks only /product/ paths and skips the tag and window checks, so a controls layer should not copy it.^{Source [12]}
• At settlement. Issuer and network risk decisions apply to the token, and Visa says TAP feeds telemetry into its fraud and risk models.^{Source [13]}
• After the fact. VIC confirmations and commerce signals support disputes.^{Source [1, 3]} TAP has no revocation list or key status endpoint.^{Source [1]}

What is observable from outside

The key store is public and cacheable for an hour, so anyone can watch keys appear or disappear.^{Source [8]} Visa newsroom releases name adopting merchants and issuers with dates.^{Source [5]} Everything else is private. TAP is off-chain and defines no events or explorers.^{Source [1]} Signature headers reach only the CDN, the merchant and the path between them.^{Source [1]} On Cloudflare the zone owner can read cf.bot_management.signed_agent, which needs an Enterprise plan with Bot Management.^{Source [14]} The consumer object sends the consumer’s IP address, device data, country and postal code to the merchant.^{Source [1]}

What can go wrong

• Untagged request. Without a TAP tag the request was not signed by a trusted agent; the merchant treats it as any other bot.^{Source [1]}
• Stale or replayed signature. A bad window, a reused nonce, a missing key or a failed signature each lead to a block.^{Source [1]} A passkey approval that takes longer than the window forces a fresh signature.
• Unresolvable key. With only an RSA sandbox key at the public URL, a verifier that relies on it cannot check an Ed25519 signature like the specification’s examples.^{Source [1, 8]}
• Tampered body. The header signature does not cover the body.^{Source [1, 15]} A payment container that fails its checks should not be used for payment.^{Source [1]} A consumer object that fails may still be used, at the merchant’s risk.^{Source [1]}
• Who bears the loss. Worldpay wrote that no liability shift for agentic transactions exists yet.^{Source [16]} It says properly authenticated, tokenized agent transactions follow existing tokenized-transaction rules.^{Source [16]}

Variants

• Encrypted payload instead of key entry. A merchant that onboards its public key to the scheme can receive an encrypted payload holding the token, expiry, cardholder name and dynamic data.^{Source [1]} No form fill is needed.
• Pay-per-access with a browsing IOU. When the merchant answers with HTTP 402, the container can carry a browsingIOU instead.^{Source [1]} TAP defines neither the 402 format nor how the IOU is settled.^{Source [1]}