How AI agents pay: checkout, delegated tokens and x402

An AI agent can help a customer reach checkout, use a delegated payment credential, or pay for a software resource. The right approach depends on what you sell and who authorizes the purchase. Here is how to choose a payment flow and verify that it works.

Reviewed October 1, 2026 · 9 min read

AI agents can initiate payments through existing checkout systems, delegated credentials or protocols such as x402. The agent is acting for a person or organization with a budget. Its ability to make a request does not, by itself, give it permission to spend.

For most retailers and service businesses, the starting point is familiar: an accurate total, a supported payment method and an order confirmation. Sellers of APIs or metered content may also need a way for software to purchase access automatically. These are different workflows, and they deserve different integration decisions.

OpenAI’s move toward merchant-owned checkout makes the distinction useful. An assistant can discover a product and send a buyer to your store without becoming the payment processor. A checkout handoff is progress, but it is not a completed sale.

Customer purchases: hosted checkout and delegated tokens#

In a hosted checkout, the customer completes payment through your existing provider. In a delegated flow, an authorized agent supplies a credential that your payment integration can use. Prefer scoped credentials over exposing payment secrets to the model, and check the provider’s actual restrictions rather than assuming every token is identical.

Stripe Shared Payment Tokens, for example, grant a seller access to a payment method with usage and expiration limits. AP2 addresses authorization through signed mandates, including purchases approved directly and purchases made within previously approved constraints. UCP and ACP describe commerce interactions; the supported payment integration still matters.

Before choosing an integration, establish three things:

• Who is responsible for the sale? Confirm the merchant of record, receipt sender, support owner and refund process in the platform agreement.
• What exactly did the customer authorize? Bind approval to the merchant, items, currency and total, with a clear expiry and a way to handle changes.
• What proves completion? Use your payment provider’s verified status and your order system’s record. A token, browser redirect or agent message alone is not proof of a paid order.

Test declined payments, expired credentials and changes to the final amount. If shipping raises a $90 basket above a customer’s $100 limit, the system should request fresh approval or stop. It should never silently reinterpret the budget.

Software purchases: paying for an API call or resource#

A software agent may need a paid dataset, an API response or a short compute job. Its owner can authorize a budget in advance, allowing routine purchases without approving every request. The owner still needs spending records and a way to revoke access.

Per-call card charges can be uneconomic for very small amounts. Existing alternatives include prepaid credits, subscriptions and metered usage billed in batches. Compare those with a machine-payment protocol before adding another currency, wallet or settlement system.

x402 defines a payment exchange around HTTP’s 402 Payment Required response. A service advertises its payment requirements, and a compatible client supplies a payment payload. A simplified flow looks like this:

1. The client requests a resource.
2. The server returns 402 with the accepted payment terms.
3. The client checks those terms against its spending policy and prepares a signed payment payload.
4. The client retries with the payload; the server verifies it and handles settlement, directly or through a facilitator.
5. The service returns the resource and payment information according to the supported payment scheme.

This can remove a separate account signup from the purchase flow. It does not remove the need for an authorized budget, or prevent a service from requiring authentication for protected resources. A payment proves that payment conditions were met, not that the caller owns every record behind the endpoint.

Start with one resource whose price and delivery conditions are easy to explain. Record the payment reference alongside the request and result. Decide what happens if the payment succeeds but the response is lost before the client receives it.

Who controls the wallet and its spending?#

An agent wallet needs a responsible owner. Establish who can fund it, approve destinations, change limits and revoke its credentials. Keep those administrative powers separate from the credentials an agent uses for routine purchases.

For example, a research agent might have a $5 daily budget, a 10-cent limit per request and permission to buy from three data providers. Enforce those rules in the payment service or application, outside the model’s instructions.

Keep enough information to reconcile each charge: the requesting agent, the approved task, the payee, the amount, the payment reference and the delivery result. Avoid logging raw payment credentials or private customer data unnecessarily.

Custody is a separate question. A network, wallet interface, processor and bank perform different roles. Do not infer who holds funds from the logo on a checkout button.

Ask the provider who holds funds or signing keys, how withdrawals work, what fees apply, and what happens during a dispute or outage. Those answers are more useful than a broad promise that the payment is autonomous.

Choose the payment approach by the job#

AP2 is included here as an authorization mechanism, not as a substitute for moving money. Likewise, choosing UCP or ACP does not settle every question about payment methods, geography or eligibility. Confirm the particular platform integration you plan to use.

Keep untrusted content away from spending authority#

An agent may read instructions embedded in a web page, document or API response. That content must not be allowed to change its budget, payee or task. A page saying that an extra payment is required is a claim to evaluate, not permission to make one.

Use limited credentials, approved destinations, transaction caps and independent approval for higher-risk actions. Enforce those controls in code or provider settings. A reminder in the agent’s prompt is not an adequate spending control on its own.

On the merchant side, verifying the agent’s identity answers who sent a request. Customer authentication, purchase authorization and payment confirmation answer different questions. Keep all four checks in the flow where they are needed.

What should your business do first?#

Choose the smallest integration that supports a real customer or software workflow:

• Retailers and service businesses: test your existing checkout or booking handoff, including the selected item, price and confirmation.
• Merchants joining a shopping platform: check eligibility and the required catalog, checkout and payment capabilities before building.
• API and data sellers: compare prepaid or metered billing with x402 using actual transaction sizes, fees and support requirements.
• Agent builders: implement spending limits, approval rules, revocation and an auditable transaction record before enabling purchases.
• Platforms and marketplaces: define responsibility for settlement, refunds, disputes and customer support in every supported flow.

Verify the whole purchase, not just the charge#

Run a successful purchase and the failures that are likely to happen in production. Check the order record, payment record and customer confirmation together. Then test a cancellation or refund and confirm that every system shows the same outcome.

Preserve the selected variant, quantity, currency and delivery details when handing off to checkout. Keep necessary authentication and approval steps, while making errors and recovery instructions clear enough for both a person and an agent to follow.

Accurate structured data, product feeds and supported MCP tools can help an agent find and act on the right offer. They complement the payment flow; they do not replace its authorization or confirmation checks.

Finally, measure discovery, referrals and completed orders separately. Server logs can reveal automated requests, while browser analytics and order records capture other parts of the journey. No single traffic count tells you whether an agent-assisted purchase succeeded.