How an AI agent buys something: the technical breakdown

You say “buy me the HEAD Delta Pro padel racket.” Your AI assistant does the research, chooses the item, and reaches checkout. The hard part is not finding the product. The hard part is proving three things before money moves:

1. The request came from a registered agent, not a scraper or card-testing bot.
2. The consumer authorized this purchase or this class of purchases.
3. The payment credential is scoped enough that a stolen token is not a general-purpose card.

That is the problem Visa Intelligent Commerce and the Trusted Agent Protocol are built around. The public documentation is clear on the primitives. It is less public about VisaNet field-level implementation details, so this post treats ISO 8583 examples as illustrative rather than official field assignments.

What Visa has publicly announced

Visa announced Visa Intelligent Commerce in April 2025 as a way for AI agents to search, select, and purchase based on a consumer’s preferences. The published architecture centers on tokenized credentials, consumer choice and control, passkeys, and agent access to Visa services through APIs and examples.

Visa then unveiled Trusted Agent Protocol on October 14, 2025, developed with Cloudflare. TAP gives merchants and edge networks a way to distinguish approved shopping agents from malicious automation by verifying signed HTTP requests. Visa’s open-source TAP repository shows a reference agent, merchant backend, CDN proxy, and agent registry.

The important part: TAP is not a new payment rail. It is an identity and intent layer that sits before checkout and can be combined with tokenized card credentials.

Layer 1: agent identity at HTTP

TAP builds on HTTP Message Signatures, standardized in RFC 9421. The agent signs request components such as method, path, authority, digest, timestamp, nonce, key identifier, and intent tag. The verifier reconstructs the same signature base and checks it against the agent’s registered public key.

GET /product/head-delta-pro HTTP/1.1
Host: merchant.example
Signature-Input: sig1=("@method" "@path" "@authority" "content-digest");
  created=1742518234; expires=1742518534;
  keyid="agent-key-001"; alg="Ed25519"; nonce="a3f8c2e1";
  tag="agent-browser-auth"
Signature: sig1=:base64-signature:
Content-Digest: sha-256=:base64-digest:

Cloudflare’s public write-up describes the validation pipeline at a high level: confirm the signature headers, pull the key ID, check the timestamp window, reject reused nonces, validate the browsing/payment tag, reconstruct the canonical signature base, and verify the Ed25519 signature.

That gives the merchant a better question than “does this look human?” The question becomes “did a registered agent sign this exact request, and is it fresh?”

Layer 2: tokenized payment credential

Visa’s VIC examples and documentation point to Visa Token Service and passkey-backed enrollment. In a card-based agent checkout, the agent should not hold the consumer’s underlying PAN. It should receive a tokenized credential scoped to the agent, consumer authorization, and transaction context.

The public Visa material supports the broad model:

• Agentic commerce uses tokenized digital credentials instead of raw card credentials.
• Passkeys and step-up verification can bind the consumer to enrollment or payment instruction creation.
• The agent receives only the credential needed to complete the authorized flow.

The public material does not publish a complete production payload for every credential exchange. Any code sample below is therefore a model of the control boundary, not an official API contract.

// Conceptual flow, not a public Visa API contract.
const instruction = await payments.createInstruction({
  consumer: "consumer-123",
  merchant: "merchant.example",
  amount: "249.00",
  currency: "USD",
  authenticator: "passkey-assertion"
});

const credential = await payments.retrieveCredential({
  instructionRef: instruction.id,
  agentSignature: tapSignature
});

Layer 3: authorization on existing rails

Card authorization still rides the existing merchant, acquirer, network, and issuer path. That is the point. Agentic commerce does not work at scale if every merchant must replace checkout infrastructure.

What changes is the evidence attached to the authorization:

• A tokenized credential in place of the raw PAN.
• Agent identity and request integrity from TAP or a similar protocol.
• A consumer-authorized instruction or mandate.
• Policy context such as merchant, amount, category, limit, velocity, and revocation state.

Public Visa and Cloudflare documents do not publish exact ISO 8583 data element numbers or values for agentic transactions. The diagram below is therefore packet anatomy: where this kind of context can travel in a card-network authorization, not a public Visa field specification.

How TAP compares with AP2, ACP, and x402

TAP + VIC is Visa’s card-network approach: signed agent requests, tokenized credentials, passkeys, and Visa-controlled payment infrastructure.

AP2, announced by Google in September 2025, is an open protocol for agent payments built around signed mandates and verifiable credentials. It is payment-method agnostic and explicitly covers cards, bank rails, and stablecoin extensions.

ACP / Instant Checkout, announced by Stripe and OpenAI in September 2025, is an application-layer commerce protocol that lets ChatGPT complete purchases with participating merchants while Stripe handles the payment integration.

x402 is HTTP-native payment infrastructure. A server can return 402 Payment Required; the client pays, commonly with stablecoins, and retries with payment proof. That makes it much better suited to API access and agent-to-agent services than ordinary retail card checkout.

These protocols are not clean substitutes. TAP is strongest at agent identity and card-network trust. AP2 is strongest at portable mandate evidence. ACP is strongest where the AI platform controls the shopping surface. x402 is strongest where the product is an API call or digital resource.

What is still unresolved

Exact public rail mapping. Visa’s public TAP material explains the HTTP identity layer well. It does not disclose the full card-network message mapping, issuer rules, or private VisaNet controls.

Multi-agent delegation. If a planning agent delegates checkout to a subagent, the public specs do not yet give a shared cross-network answer for which agent identity, key, and mandate should be authoritative.

Prompt injection. Signatures prove what request was sent. They do not prove the agent made a good decision before the request existed.

Merchant rollout. Cloudflare can make edge validation easier, but merchants, PSPs, issuers, and networks still need operational rules for bot controls, refunds, disputes, and consumer support.

Sources

• Visa: What is agentic commerce?
• Visa: Trusted Agent Protocol announcement
• Visa Trusted Agent Protocol GitHub repository
• Visa AI GitHub repository
• Cloudflare: Securing agentic commerce
• RFC 9421: HTTP Message Signatures
• Google Agent Payments Protocol announcement
• Google AP2 GitHub repository
• Stripe: OpenAI and Stripe launch Instant Checkout
• x402 protocol