Agentic payments: the definitive field guide

Start here

What are agentic payments?

Agentic payments are transactions that an AI agent prepares, authorizes, initiates, or completes on behalf of a person or organization under explicit constraints. The agent may discover a product, negotiate a choice, assemble a cart, select a rail, present a scoped credential, and record the result. Financial authority remains bounded by policy rather than inferred from the model’s confidence.

The useful definition is broader than autonomous checkout and narrower than ordinary payment automation. A recurring card charge is automated but not necessarily agentic. An AI assistant recommending a product is agentic but not a payment. The category begins where adaptive software participates in a transaction while carrying or invoking delegated authority.

An agentic payment is not an AI clicking “Pay.” It is a verifiable chain from intent to authority to transaction to outcome.

The six-layer operating model

Most confusion comes from treating agentic payments as one protocol. In practice, a complete system spans discovery, identity, authority, execution, settlement, and assurance. Different standards solve different slices, and those slices have to be joined by durable identifiers and evidence.

Authority is the product

The model can plan; it should not invent permission. A robust system converts natural-language intent into normalized, machine-enforceable constraints: maximum amount, currency, merchant or category, allowed items, deadline, frequency, refundability, and conditions that require a human to approve the final transaction.

Authority can be human-present, where the user confirms the exact order, or delegated, where a standing mandate covers a bounded class of transactions. In either case, the transaction must be bound to the authorization. A generic approval such as “buy the best option” is not enough evidence once the price, seller, fees, or cancellation terms change.

• Authenticate the principal independently of the language model.
• Normalize constraints before the agent reaches a payment credential.
• Bind approval to seller, amount, currency, order, expiry, and purpose.
• Fail closed when the cart or terms move outside the approved envelope.
• Keep step-up approval available for ambiguity, risk, and irreversible actions.

Where AP2, x402, MCP, and card networks fit

Google’s AP2 centers on cryptographically signed mandates that preserve user intent and transaction authorization across agents and merchants. Coinbase x402 centers on an HTTP-native payment challenge and stablecoin settlement flow. MCP exposes tools and resources but is not itself a payment rail. Visa and Mastercard are developing recognition, tokenization, and network controls for trusted agents using existing commerce infrastructure.

These approaches are complementary more often than they are substitutes. An MCP tool can be payment-gated with x402. An AP2 mandate can authorize a card or stablecoin payment. A recognized agent can still be denied by merchant policy. A settled transaction can still require fulfillment, a refund, or a dispute process.

The production test

A system is not production-ready because a demo completed one payment. It is ready when operators can answer the hard questions after the happy path disappears: Which principal authorized this? What exact data did the agent see? Which policy version allowed it? Was the request replayed? Did the rail settle? Was the item fulfilled? Can the user obtain a refund? What happens if the agent, seller, or facilitator is unavailable?

The minimum control plane combines policy evaluation, isolated credentials, idempotency, replay protection, transaction simulation where available, durable receipts, reconciliation, anomaly detection, and a clear recovery path. Observability must follow business identifiers across systems instead of ending at a model trace or blockchain hash.

Payment success is a state transition, not the end of the transaction.

Where to go next

Start with the architecture if you are designing a platform, authorization if you own policy, x402 or AP2 if you are evaluating protocols, and merchant readiness if you operate the acceptance side. The landscape report tracks how the pieces are converging without pretending the market has already standardized.

• Architecture: map system boundaries and identifiers.
• Authorization: design mandates, budgets, and step-up rules.
• Protocols: compare responsibility, maturity, rails, and evidence.
• Build guide: move from demo to an auditable implementation.
• Glossary: align teams on terms before choosing vendors or standards.