A small set of primitives have appeared specifically to make agentic commerce on tokenised rails workable. They split cleanly into two layers: payment primitives that move value, and identity primitives that prove authority. The interesting architectural question is which combinations actually compose, and which are layered on rails that fight the agentic shape.
Payment primitives
The x402 protocol revives the HTTP 402 Payment Required status code as a machine-readable payment-request mechanism. An API that wants to be paid per call returns a 402 with a structured payment request, the agent's wallet client interprets it, signs and broadcasts a payment, retries the request with proof, and receives the response. The spec is open. Coinbase has been the most prominent driver, with its reference implementation tied to USDC and other tokenised assets. For a stablecoin or tokenised deposit issuer, x402 is the cleanest existing primitive for "agent pays for something" without bespoke integration work.
The Stripe Agent Toolkit provides primitives for agent-initiated payments inside Stripe's existing infrastructure. It bridges agent flows into traditional rails, with the legal weight resting on existing Stripe terms and the merchant relationship. Not chain-native; the agent talks to Stripe as a payments processor and Stripe handles the rails. The advantage is the existing merchant network. The constraint is that the rails are still card and bank rails, with their settlement times and fees.
Skyfire and Catena Labs are the named agent-native payment infrastructure startups. Skyfire issues agent-specific virtual cards that route through traditional networks, treating the agent as a managed extension of an existing card programme. Catena is closer to true agent wallet infrastructure, with the agent operating its own wallet under the principal's authority. Both are early; both illustrate the design split between virtual-card abstraction on traditional rails and chain-native wallet infrastructure with new identity and authority mechanics.
Visa Intelligent Commerce and Mastercard Agent Pay are the legacy network responses, tokenising card credentials for agent use with the human principal still in the legal seat. Card networks bring decades of experience with delegated credentials and a mature dispute apparatus. The rails are still card rails, with their settlement times, fees, and chargeback logic, which makes the fit awkward for machine-to-machine settlement where neither party is a merchant in the traditional sense.
The split worth seeing clearly. x402 plus a stablecoin like USDC is chain-native end-to-end: the agent holds a wallet, the API expects on-chain settlement, the value moves at chain finality. Stripe and the card-network programmes route through traditional rails with the agent as a software extension of an existing payment relationship. Skyfire sits closer to the card model, Catena closer to the chain-native model. For a tokenisation product team, the integration question is which of these primitives the product needs to recognise as inbound or outbound, not which to bet on as winners.
Identity and authority
The harder problem in agentic commerce is not payment, it is identity and authority. Verifiable credentials and decentralised identifiers, under the W3C Verifiable Credentials (VC) Data Model and the W3C Decentralised Identifier (DID) Core standards, give the architectural shape: a credential issued by a principal that travels with the agent's transactions, signed, presentable on demand, revocable. The agent does not need a legal personality of its own; it presents proof of authorisation, and the relying party verifies the credential rather than the agent.
The legal hook is traditional agency law. The principal grants authority. The agent acts within it. The principal is bound by authorised acts and not bound by acts outside the authority unless the third party can rely on apparent authority, the doctrine that protects a counterparty who reasonably trusts an agent's outward-facing claim of authority even when the principal's instructions are narrower. A VC is the technical mechanism for making the authority machine-readable; the underlying doctrine does the work. Courts have not yet had many disputes where the agent in question was an LLM, but the general doctrines apply by analogy in the same way they applied to earlier waves of automated agents. KYC and AML run on the principal and on the destination addresses the agent transacts with. What the agent needs is a documented authority trail the relying party can verify at transaction time.
The W3C standards are chain-agnostic. They work as well with off-chain identity providers, traditional certificate authorities, or on-chain DID registries. For a regulated tokenisation product, the practical move is to accept VC presentation as one of several supported authentication paths, alongside the existing principal-side authentication the product already uses. The credential is not a replacement for KYC of the principal. It is a runtime proof that this specific transaction is within the authority the principal has already granted.
The right frame for a product team. Payment primitives are a near-term integration question; the menu is small and the standards are settling. Identity and authority primitives are the slower question, because the legal doctrines are stable but the operational interfaces (which credential format, which trust anchors, which revocation mechanism) are still moving. A product that treats payment as the load-bearing problem and identity as a stretch goal is reading the architecture upside down.