Agentic Commerce Explained: Protocols, Risks, Next Steps

For most online businesses, agentic commerce does not require rebuilding checkout this quarter.

It does, however, change who may arrive at that checkout.

Instead of a person browsing a product page, comparing options and manually pressing “Pay,” an AI agent can discover a product, negotiate the purchase conditions, select a payment method and complete all or part of the transaction on the buyer’s behalf.

That creates a new set of questions: 

• How does the merchant know the agent was authorised to spend?
• How does an AI system receive payment credentials without seeing the customer’s raw card details? 
• How can an autonomous service pay another service $0.01 for an API call? 
• What happens if the agent buys the wrong product?

Several standards are trying to answer different parts of this problem. 

The main ones in 2026 are the Agentic Commerce Protocol (ACP), Google’s Agent Payments Protocol (AP2), Coinbase’s x402 protocol and the Machine Payments Protocol (MPP) developed by Stripe and Tempo.

What is agentic commerce?

Agentic commerce is commerce in which an AI agent performs some of the work traditionally carried out by the customer.

At the simpler end, an agent might find three suitable laptops and let its user choose one. At the more autonomous end, the user could say:

“Buy a replacement laptop with at least 32 GB of RAM for no more than $1,500 before Friday.”

The agent could then search merchants, compare specifications, select an offer and execute the purchase within those spending guardrails.

Agentic payments are the payment component of that process. They need to connect the buyer’s authority, the agent’s actions, the merchant’s checkout and the actual movement of money.

This is different from an ordinary chatbot connected to a payment page. A genuine AI agent payment may happen without the buyer visiting the merchant’s website at all.

That distinction explains why new protocols are appearing around checkout, credentials, mandates and machine-to-machine settlement.

Four protocols, four different jobs

A good way to understand the market is to ask what each standard is trying to prove or accomplish.

The boundaries can overlap. An agentic checkout could use one standard for the shopping interaction and another mechanism for settlement.

For merchants, this is important. Supporting agentic commerce does not necessarily mean integrating every agent payment protocol.

ACP: checkout between the AI agent and merchant

The OpenAI Agentic Commerce Protocol was developed with Stripe and launched alongside Instant Checkout in ChatGPT in September 2025. Although Instant Checkout was later discontinued, the case study remains useful. 

ACP gives AI applications and sellers a common format for creating, updating, completing and cancelling a checkout. OpenAI describes the merchant as remaining the merchant of record, meaning the seller still controls pricing, inventory, payment processing, fulfilment, returns and the customer relationship.

The flow is straightforward:

1. The agent sends the merchant a request to create a checkout;
2. The merchant returns the current basket, price and fulfilment options;
3. The agent presents these choices to the customer;
4. The agent and seller update the checkout as necessary;
5. The customer authorises payment;
6. The merchant receives a constrained payment credential and processes the transaction through its payment provider;
7. Order and fulfilment updates can then travel back to the agent.

The important point is that ACP does not replace a merchant’s commerce backend.

Your inventory database still decides whether an item is available, your system still calculates the final price, and your fulfilment software still ships the order.

ACP creates a machine-readable checkout flow that an agent can use instead of requiring a human to navigate the website.

What is a SharedPaymentToken?

One of the more concrete mechanisms behind ACP is Stripe’s SharedPaymentToken, or SPT, which solves an awkward problem.

An agent may need to deliver a usable payment credential to the merchant, but giving an AI application unrestricted access to the customer’s card details would create obvious security problems.

A SharedPaymentToken acts as a constrained substitute.

Stripe describes SPTs as time-limited and scoped to a particular transaction. The credential can include controls such as:

• Maximum amount;
• Currency;
• Expiration time;
• Authorised seller;
• Checkout or seller identifier.

Suppose a user approves a $79 purchase from Merchant A.

Instead of handing Merchant A or the AI agent a reusable card credential, the payment provider can issue a token that effectively says: this payment method may be charged by this merchant, for up to this amount, within this limited period.

The agent supplies the SPT when completing the checkout. The seller then uses it through its payment provider.

If somebody steals the token later, its value is limited by its amount, merchant and expiry restrictions.

Indeed, the SharedPaymentToken is a concrete ACP mechanism for delegating enough payment authority to complete an order without passing unrestricted payment credentials through the agent.

AP2: proving what the customer actually authorised

ACP primarily deals with commerce interaction. Google AP2 concentrates on a different problem: trust.

Traditional online payments usually have evidence that a person was present somewhere in the flow. Autonomous agents weaken that assumption.

Google introduced AP2 in September 2025 with more than 60 organisations participating in its development, including Mastercard, PayPal, Coinbase, Adyen and American Express. 

The original AP2 material described three important concepts:

1. Intent Mandate. The user records what they want and the limits within which the agent can act.
2. Cart Mandate. The exact product, price and merchant are recorded when a specific purchase has been selected.
3. Payment Mandate. Payment authorization is cryptographically bound to the approved purchase.

The specification has continued to evolve. Current AP2 v0.2 documentation centres on Checkout Mandates and Payment Mandates, with open mandates used for autonomous instructions and closed mandates for a finalised transaction.

Consider a user who tells an agent:

“Buy two economy tickets from London to Madrid for less than £500 total, leaving on 10 October and returning on 13 October.”

For a human-not-present purchase, the initial authorization establishes those constraints. The agent can search independently, but the cryptographic evidence allows other participants to check that the final transaction fits the authority it received.

A merchant or payment provider can therefore verify more than “this agent has access to a wallet.”

It can verify what that agent was allowed to do.

AP2 is payment-agnostic, so the underlying payment method can potentially be a card, bank-based method or crypto asset. This makes the AP2 protocol closer to an authorization framework than a standalone payment rail.

x402: when the thing being bought is an HTTP resource

Imagine that an autonomous agent needs one weather forecast, ten seconds of GPU capacity or a single database query.

Opening an account, selecting a subscription and storing an API key creates unnecessary friction for a purchase that may cost fractions of a cent.

x402 uses the HTTP 402 Payment Required status code to attach payment directly to the web request.

A typical x402 payment works like this:

1. An AI agent requests a paid API endpoint.
2. The server responds with ‘402 Payment Required’ and machine-readable payment conditions.
3. The agent wallet signs the required payment authorization.
4. The agent retries the request with its payment signature.
5. The server or an x402 facilitator verifies and settles the payment.
6. The requested resource is returned.

The resulting machine-to-machine payment can occur without a conventional account or monthly billing relationship.

At the time of writing, x402’s public network statistics reported approximately 75.4 million transactions and $24.2 million of volume during the previous 30 days, involving around 94,000 buyers and 22,000 sellers.

For more detail, see 0xProcessing’s guide to the x402 protocol.

MPP: a wider payment protocol for machines

Stripe and Tempo launched the Machine Payments Protocol in March 2026.

MPP also allows software to receive a payment request and respond programmatically, but it is designed around several billing patterns rather than only one-off pay-per-call transactions.

MPP currently supports three main payment intents:

• Charge for a fixed one-time payment;
• Session for metered usage;
• Subscription for recurring access.

Sessions are especially interesting for AI services.

Instead of settling a separate blockchain transaction for every token generated or every byte transferred, a client can authorize a funded session and increase its cumulative authorization as it consumes the service.

Stripe says MPP is already being used by businesses including Browserbase for agent-purchased browser sessions and Parallel for paid web access. MPP can also work with stablecoins and, through Stripe, conventional payment methods.

Cloudflare additionally documents MPP as backwards-compatible with existing x402 services.

ACP vs AP2 vs x402 vs MPP

The agentic commerce protocol a merchant should prioritise, therefore, depends on what it sells.

After all, a fashion store, API provider and autonomous procurement platform have different requirements.

What happens when an AI agent makes the wrong purchase?

This is where agent payments become more complicated than the demo.

Imagine a customer instructs an agent to buy a refundable hotel room for no more than $300. The agent purchases a non-refundable $450 room.

There are several possible failures:

• The user may have written ambiguous instructions;
• The AI platform may have interpreted them incorrectly;
• The agent may have ignored a spending guardrail;
• The merchant may have received valid-looking authorization even though the request exceeded the original mandate.

AP2 attempts to make these disputes easier to investigate by preserving cryptographically signed evidence of what was authorised and what was eventually purchased.

That does not automatically decide legal liability.

Payment networks, merchant terms, platform contracts, consumer-protection rules and applicable law still determine who ultimately bears the loss.

Card-funded purchases can also retain the possibility of card disputes and chargebacks even when the checkout was initiated by an agent.

Crypto settlement works differently. A confirmed on-chain transfer generally cannot be reversed through a card-style chargeback process. Refunds normally require a new outbound transaction from the merchant.

Logging is, therefore, especially important for merchants. 

At minimum, keep the agent identity or credential, original instruction where available, approved amount, cart, authorization evidence, transaction identifier, timestamps and refund history.

Do you need to support all four protocols now?

For most mid-sized businesses, no.

If AI agents are unlikely to buy your product this year, focus on making your existing checkout and APIs clean, documented and automation-friendly. Monitor the standards rather than building four integrations.

If you run ordinary e-commerce and want distribution through AI shopping interfaces, ACP is the most relevant standard to investigate because it deals directly with agent-to-merchant checkout.

If customers will delegate purchases with meaningful budgets or compliance requirements, AP2-style authorization and auditable mandates become more important.

If you sell APIs, data, compute or digital resources by usage, investigate x402 and MPP first. The commercial opportunity is much closer to the product itself.

A business should also separate experimentation from core payment operations. Protocols are still evolving, and current specifications may change

 

FAQ