How Agents Buy

Why a secure payment method was not enough for an agent to buy anything, and how one API covers every merchant

Once an agent has a secure card, a second problem appears: it still cannot buy much. Almost every merchant built its checkout for a human with a mouse.

Problems

An agent that can pay with the user’s card still has no way to complete most purchases programmatically:

• Most merchants have no purchase API. There is nothing to call. The only path to a purchase is the same web checkout a human uses.
• Checkouts are built to keep bots out. CAPTCHAs, bot detection, and multi-factor prompts are aimed precisely at automated buyers.
• Every merchant is different. Carts, guest checkout, account login, shipping forms, coupon fields, and payment pages all vary. A hand-rolled integration works for one store and breaks on the next.
• Browser automation is slow and expensive even when it works. A general-purpose browser agent has to look at every page, decide what to click, and recover from every surprise. One checkout can take minutes and cost several dollars in tokens.
• Generic automation is not a checkout solution. A browser agent built for any task treats a purchase like any other web page. A checkout needs things it does not provide: a spending cap enforced outside the model, a way to enter card details without exposing them to the model, a structured way to ask the buyer a question mid-run, and a structured result at the end. It also starts from scratch at each merchant instead of reusing what worked there before.

Three approaches to closing that gap emerged, and each covers only part of the market:

Approach	Where it works	Where it falls short
Merchant APIs	The few merchants that expose one	Nearly every other merchant
Agentic commerce protocols (UCP, ACP, AP2, …)	Merchants that have adopted a given protocol	Adoption is early and fragmented across several protocols, and many implementations hand back a checkout link rather than completing the purchase
Browser automation	Anywhere a human could buy	Slow, brittle, and expensive: with frontier models a single checkout can cost several dollars in tokens, and it needs constant maintenance

To buy anywhere, an agent developer would have to build and maintain all three, choose between them per merchant, and keep up as protocols change. That is the effort most teams cannot afford, and the reason many “shopping agents” stop at a product link.

Solutions

Agent Checkouts

Agent Checkouts puts all three approaches behind one API. Hand it a link, a natural-language task, and a hard spending cap. Agent Checkouts finds the products, builds the cart, and checks out for your user:

• The right rail for each merchant. The checkout uses an agentic commerce protocol, such as the Universal Commerce Protocol (UCP), where the merchant supports one. Everywhere else, it uses an optimized browser session that Crossmint runs. You integrate once and get every rail, including new ones as merchants adopt them.
• A complete purchase, not a cart. The checkout runs end to end and returns a receipt with the merchant order id, not a link for the user to finish.
• Your user is the buyer. The merchant is the seller and the merchant of record. It sends the receipt to your user and handles returns.
• Any payment method the merchant accepts. An order intent on your user’s saved card, an agent card from another provider such as Ramp or Link, a card already on file in the user’s merchant account, Klarna, Shop Pay, or a local method such as bank transfer, Bizum, or Pix.
• Bounded and observable. No purchase goes above the cap you set. You can embed the live browser session so the user watches the purchase happen, and the agent asks the user only for what you did not provide up front.
• Crossmint runs the browser side. The browser infrastructure, the models, the prompts, and the per-merchant behavior live in Crossmint’s service rather than in your integration. Improvements to them apply to every checkout without a change on your side.

x402 and MPP

Not every purchase has a checkout page. When the counterparty is an API or another agent, the payment is a protocol exchange settled in stablecoins:

Protocol	How it works	Best for
x402	The agent calls an endpoint, receives 402 Payment Required, pays in stablecoin, and retries	Pay-per-call APIs and micropayments
MPP	Agent-to-agent and service-to-service payments over the Machine Payment Protocol	Programmatic machine economies

Both are paid from an Agent Wallet, with the same scoped, revocable permissions described in How Agents Pay.

One integration covers both kinds of counterparty: Agent Checkouts for merchants, x402 and MPP for machines. The per-merchant work lives in Crossmint’s service, not in your codebase.

See Also

How Agents Pay

Scoped cards and wallets the user controls

Agent Checkouts

The product, its features, and where to start

Checkouts Quickstart

Create your first checkout from a product URL