Choose the business role before the integration
A retailer exposing a product catalog needs a seller integration. An AI application embedding a checkout needs an agent-side commerce integration. A developer charging for a financial-data API needs machine-payment handling. An assistant that looks up revenue or creates a Stripe resource is performing account administration. These activities can coexist, but success in one does not prove support for the others.
Stripe's current agentic-commerce documentation explicitly separates sellers from agents, and retail commerce from machine payments. Its integration table maps retail to UCP or ACP, and machine payments to MPP or x402. This provides a practical way to navigate the product family without treating every protocol as an alternative implementation of the same operation. [2]
The role selector and component map explain where to begin. They are reading aids, not an account eligibility test. Follow the current official guide for the component you select, then check the available payment methods, required credentials and permitted customer locations. A general Stripe account does not by itself settle those questions.
Find the relevant documentation branch
Stripe components by responsibility
Scroll the table to compare all columns.
| Component | Primary job | Boundary to verify |
|---|---|---|
| Agentic Commerce Suite | Seller catalog, checkout and payment integration [1] | Seller access, agent channel and merchant fulfillment; public offer marked US only. |
| ACP and UCP | Commerce protocol paths in seller documentation [2] | Which operations and checkout mode the integration implements. |
| Link Agent Wallet | Customer-approved purchase credentials and optional financial insights [5] | Separate scopes, consumer geography and approval for each purchase. |
| Issuing for agents | Issuing-based buyer infrastructure identified by Stripe [1] | Exact issuing program, cardholder eligibility and controls. |
| MPP and x402 | Programmatic payment for APIs or services [3] | Supported method, network, currency and seller account access. |
| Agent Toolkit, MCP and skills | Work with Stripe resources and technical guidance [7] | Administrative permissions; this does not establish purchase consent. |
Merchant checkout includes the order lifecycle
The Agentic Commerce Suite lets businesses publish catalogs, choose agent channels and connect discovery, checkout and payments. Stripe's public use-case page says merchants retain control of products, pricing and fulfillment and remain the merchant of record. The page carries a US-only label for the offer; do not infer worldwide Suite availability from Stripe's broader payments footprint. [1]
For an illustrative $64 office-supply order, the catalog entry is only the start. The seller must return the selected quantity, shipping option and final total. The agent surface needs to present or obtain the required approval, submit the order and preserve the seller's order reference. Payment acceptance does not replace these steps. The $64 amount is a planning example, not a Stripe price or reported transaction.
An embedded checkout and a redirect are different experiences. In a redirect, the buyer completes the purchase at the seller. In an embedded experience, the agent interface participates in the checkout flow. Stripe's documentation currently marks its agent commerce integration as private preview. A developer planning that experience should confirm access and the required integration mode before promising it to customers. [2]
Keep responsibilities visible in your design. Name the seller who fulfills the order, the party providing the payment credential, the system that records completion and the support route for returns. This prevents a common failure in agent commerce: an interface reports payment success while the user cannot find the actual order.
Buyer wallets and issuing solve a different problem
Link Agent Wallet provides programmatic access to a consumer's Link account with separately requested capabilities for payments and financial insights. For a purchase, the agent creates a spend request, the customer approves it, and Link returns a one-time-use credential. Reading connected financial accounts is a different permission; an application can use either capability or both. [5]
As checked on 8 October 2026, the technical guide lists agent payments for US and Canadian consumers, and financial insights for US consumers. It says the integrating business and the sellers can be elsewhere. The public Link landing page still says currently available in the US. These statements differ in geographic detail; use the technical guide as the integration starting point and confirm the intended consumer's eligibility rather than treating either statement as an unrestricted global offer. [5] [6]
Do not describe Link's current approval flow as unattended spending within a standing budget. The documented payment flow obtains customer approval for the purchase. The public page places granular controls for spending without approval in its coming-soon section. If an overnight agent task cannot wait for a person, that requirement needs a different verified path or a revised task design. [6]
Stripe also lists Issuing for agents on its public product map. That identifies a route to investigate for issuing-based deployments; it does not establish every issuer program's countries, cardholder eligibility or spending rules. The application should name the particular program and its approved controls before relying on them. [1]
Machine payments use a challenge and a credential
For paid APIs, Stripe describes a server challenge, an agent-supplied payment credential and settlement into the seller's Stripe balance. Its machine-payment guide supports cards and stablecoins over MPP, and stablecoins over x402. That is a concrete product support statement, narrower than assuming every protocol can accept every method advertised elsewhere. [3]
The current guide gives separate network and currency entries: MPP with Tempo USDC.e or Solana USDC, and x402 with Base USDC. It also documents different minimums for card payments, stablecoin payments and MPP session settlement. A seller designing low-priced requests should use the relevant current limits rather than assume a tiny per-call price works on every route. [3]
Availability is product-specific. The guide lists stablecoin machine payments for US businesses outside New York, with access requests for businesses in additional countries. Card credentials have their own supported-country documentation. Protocol openness, merchant account approval and customer eligibility remain separate requirements. Check the live guide when selecting the deployment; this page does not reproduce a complete country list. [3]
For an illustrative research service, define what a paid call returns and how retries refer to the same purchase. If a request times out after payment submission, retrieve or reconcile the original state. Do not send another payment simply because the application lacks a response. Stripe's machine-payment guide describes refunds through its API and Dashboard, but the seller still needs a policy for a missing or defective result. [3]
Scoped credentials still require correct handling
Shared Payment Tokens give a seller limited access to a customer's payment method. The agent-side documentation explains issuing a token to the intended seller profile with usage limits such as currency, maximum amount and expiration. A token represents a permitted payment use; it is not a product delivery receipt or a blanket authorization for future sellers. [4]
The same guide documents a requires-action state, including card authentication or redirects, and revocation. Your agent interface needs to handle that state honestly: stop the automated purchase, present the customer's required action and resume the existing transaction when it is resolved. Labeling every token as ready to spend would hide a material condition of completion. [4]
Link also has a distinct authentication boundary. Its guide uses customer OAuth access to the Link API, rather than a Stripe secret API key. Use the corresponding SDK or documented HTTP interface and keep credentials out of conversational logs. An existing server-side Stripe integration should not be assumed to cover those endpoints. [5]
These distinctions matter during an integration review. Inspect the exact permission and seller binding, the credential lifetime, the treatment of cancellation and the event that your application considers final. Then inspect the separate order or resource-delivery record. The model's narrative of what happened should follow those records, rather than becoming the source of truth.
Agent Toolkit and MCP are not purchase approval
Stripe's Agents and AI documentation groups development tools, MCP access, agent skills and live account data. Those tools can help an agent work with Stripe resources or documentation. They do not make account administration equivalent to a customer-authorized purchase through a wallet. [7]
Keep their authority separate in your own application. A revenue-analysis assistant may need read access to business data, while a buying assistant needs permission tied to a customer's purchase. The latter should not inherit broad account credentials merely because both workflows use an LLM. Likewise, a tool that can create a resource should not be called evidence that the customer approved its financial effect.
Choose the smallest documented path that completes the task. Use commerce docs for orders, machine-payment docs for paid resources, Link docs for customer spend requests, and administration tools for account operations. The protocol comparison explains where those layers meet. This review is based on current official documentation, not a live transaction, access approval or measured performance test.