What Is Agentic Commerce? Payments AI Agents Make

Agentic commerce is commerce where an AI agent, not a human clicking a button, initiates and completes a purchase. The agent finds a product or service, decides to buy it, and settles payment within limits you set in advance. The interesting part is what happens after the click never happens: a machine spent money on your behalf, and now someone has to prove which agent paid whom, for what, and whether it was authorized.

That verification step is where agentic commerce gets hard, and it is why several of the largest payment networks and crypto firms have shipped competing standards in the space of a year.

Key takeaways

• Agentic commerce means an AI agent executes a transaction end to end, including authorization and payment, under constraints a human set beforehand.
• The bottleneck is not letting an agent spend money. It is reconciling and verifying each machine-initiated payment afterward, at machine speed and machine volume.
• Multiple standards now compete to structure agent payments: Coinbase's x402, Google's Agent Payments Protocol (AP2), Visa Intelligent Commerce, and Mastercard Agent Pay.
• Stablecoins and onchain rails are attractive for agent payments because settlement is fast, programmable, and produces a permanent record. That record is raw and needs normalizing before anyone can reconcile it.
• Trust in agentic commerce depends on an audit trail that ties an agent, its mandate, a payment, and a merchant into one verifiable chain.

Why four payment giants shipped agent standards in one year

Large language models became good enough to plan and act, not just answer, over 2024 and 2025. Once an agent can navigate a checkout, the question stops being technical and becomes financial: how does the agent pay, and who is liable if it pays wrong?

The answers arrived quickly. Coinbase published x402, an open protocol that revives the dormant HTTP 402 "Payment Required" status code so a server can demand a stablecoin payment before returning a resource, with settlement onchain. Google announced the Agent Payments Protocol (AP2), an open specification built around cryptographically signed "mandates" that prove a user authorized an agent to transact within stated limits. Visa launched Visa Intelligent Commerce, which issues agents tokenized payment credentials tied to a real Visa account. Mastercard introduced Agent Pay, extending its tokenization and Agentic Tokens to agent-initiated transactions.

These are not the same product, and they do not all settle the same way. Some run on card rails, some run onchain, and some are protocol layers that can sit on either. What they share is a bet that a meaningful share of near-future purchases will be initiated by software acting for a person or a business.

The chain of events behind one agent purchase

Strip away the branding and every agentic payment follows the same sequence. Understanding it is the fastest way to see where the difficulty lives.

1. Mandate. A human grants an agent authority: buy this category, up to this amount, from these merchants, this often. In AP2 this is a signed mandate; in Visa and Mastercard it is a scoped, tokenized credential.
2. Discovery and decision. The agent finds the good or service and decides to transact.
3. Payment request. The merchant or its endpoint asks for payment. Under x402, the server returns a 402 response describing the amount and accepted asset.
4. Settlement. Value moves. On card rails this is authorization and capture through the network. On stablecoin rails it is a transfer recorded on a blockchain.
5. Reconciliation and verification. Someone (the user's bank, the merchant, an auditor, the platform) confirms the right agent paid the right merchant the right amount under a valid mandate, and flags anything that does not match.

Steps one through four are the parts the standards focus on. Step five is where the volume problem shows up. A person makes a handful of purchases a day. An agent fleet buying data, compute, API calls, and micro-services can generate far more, each one small, each one needing to be tied back to a mandate and a merchant.

Comparing the named agent-payment standards

The four leading standards differ on who backs them, what rails they use, and whether the settlement record lands onchain. That last column matters most for reconciliation, because an onchain settlement produces a public, permanent record that anyone can independently verify.

Read the table as a spectrum. The card networks bring reach and consumer protections and settle inside their own systems. The onchain approaches bring speed, programmability, and a public record, at the cost of building the verification tooling that card networks have refined over decades. AP2 sits in the middle by design, defining the authorization layer and leaving the rail open.

Why stablecoins keep showing up in agent payments

Agents transact in small amounts, often across borders, sometimes many times a minute. Card rails were built for human-scale, human-frequency purchases and carry per-transaction economics that strain under machine volume. Stablecoin transfers on public chains settle in seconds, can be denominated in fractions of a cent, and clear without a multi-day wait.

Here is a concrete before and after. A traditional card micro-payment for an API call can take days to fully settle, and the fixed portion of interchange makes a few-cent charge uneconomic. A stablecoin transfer for the same call settles in seconds and can be sized at a few cents without a fixed fee swallowing the payment. That difference is why x402 chose stablecoins and why AP2 explicitly supports them.

The catch is on the back end. A card settlement arrives pre-labeled inside a closed network: the issuer already knows the account, the merchant, and the amount. A stablecoin transfer arrives as a raw blockchain record.

The reconciliation problem a raw onchain record creates

Consider a single agentic payment that settles onchain. What the blockchain actually stores is a log entry: a token contract emitted a Transfer event, from one address, to another address, for some integer number of base units, in some block. Nothing in that record says "stablecoin," "merchant," "agent mandate #4821," or a dollar amount.

To reconcile that payment against the mandate that authorized it, and to compare agent activity across x402 flows on one chain versus another, the same transfer has to resolve to the same fields every time: the asset and its issuer, the sending and receiving parties, the raw amount, the USD value at settlement, and the transaction type. An integer of base units has to become a human-readable amount using the token's decimals. An address has to be attributed. A contract has to be identified as a stablecoin and matched to its issuer. And it all has to hold consistently across every blockchain an agent might use, because agent fleets are not loyal to one network.

This normalization is the work that stands between a settled agent payment and a verifiable audit trail. Allium ingests raw records from public blockchains and standardizes them into consistent fields for assets, issuers, senders, recipients, amounts, and USD values, which is the shape reconciliation and verification actually need. The payments data tables turn raw transfers into records a finance or compliance team can tie back to a mandate. We wrote more about the gap in the missing layer in AI payments.

What changes for merchants, users, and platforms

Merchants: a new class of buyer that never sees your storefront. Instead of optimizing a checkout page for humans, you expose an endpoint an agent can query and pay. Faster settlement means capital is not locked up for days waiting on a card batch, but you inherit the job of matching each machine payment to an order.

Users: you delegate spending inside limits you set once, instead of approving every purchase. The upside is convenience. The requirement is a clear record of what your agent bought, so you can audit it after the fact rather than trusting it blindly.

Platforms and auditors: the unit of trust shifts from confirming a person authorized a purchase to confirming a valid mandate authorized this agent to pay this amount. Answering that at scale requires payment records that are already structured, not raw log entries to decode by hand.

Risks and open questions

Authorization and liability. If an agent overspends, buys the wrong thing, or is manipulated by a malicious prompt, who is liable? Signed mandates and scoped tokens are the answer in theory. In practice, the case law and network rules for machine-initiated payments are still forming.

Fragmentation. Four standards is not one standard. A merchant may need to accept several, and an agent may need to speak several, until the market consolidates or interoperates.

Fraud at machine speed. Automation cuts both ways. A compromised agent can drain a mandate faster than a human would notice. Real-time monitoring, not end-of-month reconciliation, becomes the requirement.

Privacy versus verifiability. Onchain settlement is transparent and permanent, which is excellent for audit and awkward for commercial confidentiality. Balancing the two is unresolved.

Attribution accuracy. Reconciliation is only as good as the labeling of addresses and contracts. Misattributing a receiving address to the wrong merchant produces a clean-looking but wrong audit trail, which is worse than no trail at all.

Where this is heading

Agentic commerce will not arrive as a single switch flipping. It will grow first where the economics are obvious: machine-to-machine payments for compute, data, and API access, where amounts are small, volume is high, and both sides are software already. Consumer agentic shopping through card networks will follow more slowly, gated by trust and liability rather than technology. Across both, the constant is the fifth step in the chain. Every agent that acts creates a payment that someone has to reconcile and verify, and that job only works when the underlying records are consistent, attributed, and comparable across chains.

Frequently asked questions

What is agentic commerce in simple terms?

Agentic commerce is commerce where an AI agent, rather than a human clicking buy, finds a product or service, decides to purchase it, and completes payment on your behalf. You set limits in advance (what it can buy, how much, from whom), and the agent transacts within them. The defining feature is that a machine initiates and settles the payment autonomously.

How is agentic commerce different from a normal online purchase?

In a normal purchase a person reviews the cart and authorizes each payment. In agentic commerce the person authorizes an agent once, through a mandate or scoped credential, and the agent then transacts repeatedly without further clicks. This shifts the hard work from the checkout to the verification afterward: proving which agent paid which merchant, for how much, under what authority.

What are x402, AP2, Visa Intelligent Commerce, and Mastercard Agent Pay?

They are competing standards for agent payments. x402, from Coinbase, uses the HTTP 402 status code to request stablecoin payment that settles onchain. Google's AP2 is a rail-agnostic protocol built on cryptographically signed mandates. Visa Intelligent Commerce and Mastercard Agent Pay issue agents tokenized credentials that settle through their respective card networks.

Why do stablecoins matter for AI agent payments?

Agents make frequent, small, often cross-border payments that strain card economics. Stablecoin transfers on public blockchains settle in seconds, can be sized in fractions of a cent, and clear without a multi-day wait. They also leave a permanent, public record. The trade-off is that this record is raw and must be normalized before it can be used for reconciliation.

What is the biggest technical challenge in agentic commerce?

Reconciliation and verification at machine scale. When an agent settles a payment onchain, the blockchain stores a raw log entry with an address, a contract, and an integer amount, and nothing that says which merchant, which asset, or which mandate. Turning those raw records into structured fields you can tie back to an authorization is the core data challenge.

Who is liable if an AI agent makes a wrong purchase?

This is still being worked out. In principle, signed mandates and scoped tokenized credentials define exactly what an agent was allowed to do, so a payment outside those limits is unauthorized. In practice, network rules, consumer-protection frameworks, and legal precedent for machine-initiated payments are still forming, which is one of the main open risks in the space.