Agentic checkout moved from research demo to shipping product in the last twelve months. Mastercard's Agent Pay opened to developer preview in October 2025, Visa's Trusted Agent Protocol went GA for select merchant partners in Q1 2026, Stripe shipped its AI Agents SDK in May 2025, Coinbase published Onchain Payments Protocol (x402) in May 2025, and Eco's stablecoin route API exposes the same agent-friendly primitives for any token on any chain. This guide walks through what a developer actually wires up today, with the authentication model each rail uses and code patterns that work across stacks.
​

At the API layer, agent pay is a delegated checkout. A human (the principal) issues a credential to an AI agent that constrains what, where, and how much the agent can spend. The agent presents that credential to a payment endpoint, the endpoint verifies the constraints and the agent's identity, and the rail settles. The differences between Mastercard, Visa, Stripe, Coinbase, and Eco come down to who holds the credential, what format it takes, and which rail moves the value.
​

Mastercard's Agent Pay sits on top of its existing tokenization service. The flow uses Agentic Tokens, which are network tokens that carry agent-specific cryptographic constraints. The developer integration has three pieces: a consumer-side consent capture (where the cardholder authorizes the agent and sets spending rules), a token provisioning call to the Mastercard Token Service, and a runtime authorization where the agent presents the token plus a signed intent payload.
​

The cryptographic envelope follows the Agentic Commerce Protocol (AP2) that Google open-sourced in September 2025 and Mastercard co-signed. AP2 defines three nested mandates (Intent, Cart, Payment) signed as verifiable credentials. Mastercard's SDK wraps that envelope in its own token format. Reference: developer.mastercard.com Agent Pay documentation.
​

Visa's Trusted Agent Protocol takes a different posture. Instead of provisioning a constrained token to the agent, Visa keeps the credential on its side and exposes a Trusted Agent endpoint where the agent posts an authenticated intent. The merchant's PSP receives a standard Visa authorization on the back end; the agent never holds card data.
​

The developer surface is closer to a federated identity pattern. The agent registers as a Trusted Agent (with a Visa-issued agent certificate), the consumer links the agent to their Visa account through their issuing bank's app, and at checkout the agent presents a JWT signed with its agent key plus the consumer's consent reference.
​

Visa publishes the schema in its Trusted Agent Protocol developer docs. The trade-off versus Mastercard: Visa centralizes the credential (less surface area on the agent side) but the agent must make a network round trip to Visa for every authorization rather than presenting a self-contained token.
​

Stripe shipped its AI Agents SDK in May 2025 and has iterated it through 2026. The approach reuses Stripe's existing primitives instead of inventing a new credential format. The merchant issues a Restricted API Key scoped to a single Customer and a spending cap; the agent presents that key to attach a PaymentMethod and create a PaymentIntent on behalf of the user. Stripe added an Issuing flow in late 2025 where the agent receives a single-use virtual card with merchant and amount controls baked in, which works at any merchant on the Visa or Mastercard rails.
​

Stripe's docs at docs.stripe.com/agents cover the toolkit's LangChain, Vercel AI SDK, and CrewAI bindings. The model card is straightforward: the agent is just an automated client of the merchant's Stripe account, with permissions narrowed via Restricted Keys.
​

Coinbase published the x402 protocol in May 2025 as an HTTP-native way for agents to pay for resources. The name refers to the long-dormant HTTP 402 Payment Required status code. A resource server returns 402 with a payment requirement in headers, the agent constructs a USDC payment on Base (or another supported chain), and the server settles before returning 200.
​

x402 uses ERC-3009 transfer-with-authorization signatures so the agent does not need to submit the transaction itself. A facilitator (Coinbase Commerce or a self-hosted one) submits the USDC transfer and verifies inclusion. The full spec is at x402.org and on the Coinbase developer platform. Authentication is purely cryptographic: the agent's wallet signature is the credential, with no centralized issuer.
​

Eco exposes the same primitive at the routing layer. An agent that needs to pay a merchant in USDC on Base but holds USDT on Tron, or USDC on Solana, posts an intent to the Eco Routes API. Eco quotes a route, the agent signs an ERC-20 permit (or equivalent on Tron and Solana), and a solver fills the destination side within seconds while the source side settles asynchronously. The agent's wallet signature is again the credential.
​

For an agent that already lives onchain, this means no card network, no PSP, and no per-merchant integration. The merchant only needs an address. Eco's route API treats the agent as a normal client; spending limits are enforced by the agent runtime or by a smart-account policy (Safe modules, ERC-7579 validators) on the agent's wallet.
​

The four rails sit on three distinct credential models: delegated network tokens (Mastercard), federated identity with a server-side credential (Visa), restricted merchant API keys (Stripe), and cryptographic wallet signatures (Coinbase x402, Eco). Each model has a different threat surface and a different per-merchant integration cost.

A practical read: if you are building an agent that buys from existing card-accepting merchants, Stripe is the lowest-friction starting point and Mastercard or Visa become relevant when you need network-level guarantees. If you are paying APIs, other agents, or onchain merchants, x402 plus an Eco route is the shortest path and avoids the PSP entirely.
​

Three of the four card rails share the AP2 protocol layer. AP2 defines Intent Mandates (what the user authorized), Cart Mandates (what the merchant offered), and Payment Mandates (how settlement happens), each signed as a W3C Verifiable Credential. Mastercard Agent Pay, Visa Trusted Agent, and Stripe's Agent Toolkit all consume AP2 mandates as inputs. x402 does not use AP2; the wallet signature is the mandate. Eco accepts either model since its API only cares about the destination payment.
​

For agent identity itself (separate from payment authorization), the emerging pattern is Decentralized Identifiers (DIDs) plus attested agent certificates. Mastercard, Google, and the AP2 working group publish reference implementations at github.com/google-agentic-commerce/AP2.
​

A working stack for a shopping agent in 2026 typically uses one card rail and one stablecoin rail. The card rail (Stripe is easiest to start with) handles long-tail merchants on existing checkout. The stablecoin rail (x402 and Eco) handles API calls, agent-to-agent payments, and any merchant that publishes an onchain endpoint. The agent code branches on the merchant's accepted methods, falling back to the card rail when no x402 header is present.
​

Spending limits live in two places. The credential itself (token constraints, restricted key scope, smart-account policy) is the hard floor. A runtime policy engine in the agent enforces softer rules (per-merchant caps, category blocks, human-in-the-loop for unusual purchases). Most production deployments add a logging layer that streams every authorization attempt to a merchant of record for reconciliation.
​

This guide is built from primary developer docs only. APIs and SDK details are accurate as of May 2026; specifics can shift between SDK releases, so verify against the linked references before shipping. Code examples are illustrative; consult each provider's reference for exact field names and signatures.