TRENDS
Agentic Commerce by 2030: The $3–5T Forecast Explained
Anyway Team
· 9 min read ·
Agentic commerce could help orchestrate $3–5 trillion in global consumer-goods purchases by 2030, according to [McKinsey's forecast](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-agentic-commerce-opportunity-how-ai-agents-are-ushering-in-a-new-era-for-consumers-and-merchants). The important word is purchases. That's the value of goods agents may help people buy, not revenue that AI companies will keep. It also excludes services and B2B commerce.
Agentic commerce means agents helping people or businesses find, compare and buy products within an agreed level of authority. An assistant might help choose a $1,000 purchase while earning only a small subscription fee. That gap explains why a large market forecast doesn't automatically make an agent product a good business.
If you run a SaaS or API business, there's a more useful question than whether to chase a trillion-dollar headline: can an agent understand your offer, get permission to pay and receive what it bought? Here's what the forecast measures, and what it means for that purchase flow.
In this guide
What the 2030 forecast actually measures
How an AI-agent purchase works
What payment protocols do
Where the business opportunity sits
A merchant-readiness checklist
Where Anyway fits
What the 2030 agentic commerce forecast actually measures
McKinsey's October 2025 research estimates a $900 billion–$1 trillion US B2C retail opportunity and $3–5 trillion globally by 2030, under assumptions about adoption and merchant readiness. The estimates cover goods; services and the substantial B2B market are outside that calculation. Read the scope in the original McKinsey research.
Keep these measures separate when you're planning a business:
Measure | What it tells you | What it doesn't establish |
|---|---|---|
Agent-orchestrated commerce | Purchase value that agents may influence or help execute | Revenue retained by an agent vendor |
A merchant's agent-assisted sales | Orders attributed to an agent-related journey | Whether those orders are incremental |
An agent product's revenue | What customers pay for that product | Its margin after model, tool and support costs |
For an API business, start a revenue estimate with the customers who need your API and the usage they'll pay for. The global goods forecast gives context for a possible change in buying behavior; it doesn't supply those customers or tell you what they will spend.
What could slow adoption before 2030?
Price comparison is easier to delegate than a non-refundable purchase. Adoption will depend on how much trust a task requires, whether offers can be compared reliably, and how errors are resolved. An agent buying another batch of approved API calls has a different risk profile from one choosing an unfamiliar supplier for a large business order.
Plan for mixed behavior. A customer may let an agent research options but still approve checkout personally. That is a useful buying journey even if the final payment isn't autonomous.
How an AI-agent purchase works
Imagine a research assistant that needs a paid data API to finish a report. Finding the API is the easy part. Before it spends money, the product needs a clear path through the purchase:
Discover the offer. Read the API's capabilities, price, usage limits and cancellation or refund terms.
Match the task. Check whether the resource is suitable for the user's request, including data-use restrictions.
Obtain authority. Confirm the allowed vendor, maximum spend, currency and whether human approval is required.
Complete payment. Use a supported payment flow without exposing a reusable credential to the model or an untrusted page.
Verify and fulfill. The merchant checks payment server-side and grants the purchased access once.
Record the result. Connect the order, resource consumed and delivered output so a person can review the purchase later.
Two questions remain after checkout: did the user authorize the spend, and did the research actually answer their question? A successful charge answers neither on its own. Keep the purchase evidence alongside, but separate from, the task result.
For builders selling the agent itself, see how to monetize AI agents. That guide addresses pricing and margins; this article focuses on the commerce journey an agent participates in.
What agentic commerce protocols do and do not do
You may see MCP, ACP and AP2 mentioned in the same announcement. They work on different parts of the journey, so it helps to ask what each one lets your application do.
Layer | Example | Question it helps answer |
|---|---|---|
Tool and context access | Model Context Protocol (MCP) | How can an AI application discover and call a tool? |
Merchant checkout interaction | Agentic Commerce Protocol (ACP) | How can an agent and merchant exchange commerce information? |
Payment authorization | Agent Payments Protocol (AP2) | What evidence shows the purchase and payment were authorized? |
Stripe and OpenAI announced ACP alongside Instant Checkout in September 2025. That announcement established a concrete commerce integration, not universal availability across every store and product. Stripe's announcement is useful historical context; a merchant still needs to verify current enrollment and integration requirements.
MCP, introduced by Anthropic, standardizes access to tools and context. It should not be confused with a payment network or permission to spend a user's money. Its official architecture describes the protocol's scope.
The current AP2 specification describes signed checkout and payment mandates, including human-present and delegated modes. These provide authorization evidence. They don't, by themselves, determine whether the agent chose a good product or whether the seller delivered it.
Choose the protocol and version your merchant or payment integration supports. Adding tool access alone won't make an agent able to complete a purchase, and implementing one checkout protocol won't connect it to every wallet.
Where the business opportunity sits
The opportunity isn't limited to building a shopping assistant. A small team can make an existing product easier to buy and use through an agent.
For API businesses, the offer needs a clear unit: a lookup, document, minute, completed job or reserved capacity. Publish what counts as billable usage and what happens when a request fails. An agent should not have to infer pricing from a sales presentation.
For SaaS businesses, expose enough product information to support an accurate buying decision. Explain the included usage, seat rules, integrations and cancellation terms. A machine-readable price that disagrees with the checkout creates a worse experience than a normal page requiring human review.
For agent developers, the opportunity may be a paid workflow rather than a transaction commission. A useful procurement assistant might earn a subscription because it reduces review work. Charging a percentage of spend could create the opposite incentive. Choose a model that customers can understand and audit.
Watch where the buyer stops. An AI answer may send someone to your site, but that still leaves checkout and delivery to solve. Measure those steps separately before calling the channel a success.
A merchant-readiness checklist
Start with one offer and one supported purchase route. Review these failure cases before expanding autonomy:
Area | Minimum useful test |
|---|---|
Product truth | The product page, API response and checkout agree on price, availability and limits. |
Authorization | A purchase outside the allowed vendor, amount or task scope stops for review. |
Credentials | The model can't read raw payment credentials or merchant secrets. |
Confirmation | Product access depends on verified server-side payment state, not a success-page URL. |
Duplicate handling | Repeated callbacks can't create a second entitlement or charge. |
Refunds | Support can connect the buyer, order and unused or delivered service. |
Audit trail | A reviewer can explain who authorized the purchase and what the customer received. |
Our payment-webhook guide covers the confirmation and duplicate-delivery steps. Keep these controls in ordinary application code rather than asking a model to decide whether they passed.
Measure a small set of outcomes: eligible checkout attempts, confirmed orders, successful fulfillment, support requests and refunds. Separate agent-referred visits from agent-executed purchases. A rise in bot traffic alone isn't evidence of commercial demand.
Where Anyway fits
Anyway Business provides products, hosted payment links, order records, recurring Card/USD subscriptions and merchant payouts. For an eligible developer, that makes it possible to start with a shareable checkout and connect confirmed purchases to the application's own access rules.
There is also a separate buyer-side product: Anyway Agents, with funded agent wallets, spending policies and paid API access. It addresses controlled resource spending. Business sales balances aren't agent-wallet funds, and merchant revenue should not be treated as automatically available for an agent to spend.
Anyway acts as the legal seller for eligible MoR transactions. Its current MoR documentation states that automated per-order tax calculation, collection and remittance hasn't launched. Confirm the treatment of your intended sales rather than assuming the MoR label proves every tax workflow is available.
If your project requires ACP or AP2, ask about that exact integration before building around it. A shared checkout link and a funded wallet don't by themselves establish compatibility with either protocol.
Frequently asked questions
How big could the agentic commerce market be by 2030?
McKinsey projects $3–5 trillion in global consumer-goods commerce orchestrated through agents. It is a scenario-based transaction-value estimate, not a measured current market or AI-vendor revenue forecast. Services and B2B are outside that particular calculation.
Does agentic commerce require fully autonomous payments?
No. An agent can research and prepare an order while a human approves payment. The level of delegation should match the task, spending authority and consequences of a mistake.
Is an MCP server enough to accept agent payments?
No. Tool access doesn't replace merchant onboarding, a payment flow, authorization controls or order fulfillment. Add those explicitly and test them together.
Will AI shopping agents replace websites?
That isn't a safe assumption. Product pages, documentation, support policies and checkout remain useful sources of truth. Make them clear and consistent before investing in a new channel.
Start with a purchase you can explain
Start with the purchase your customers already make. Can an agent find the price and limits, get the right approval, then receive the purchased service? Making that path work is useful even if the 2030 market turns out smaller than the forecast.
If hosted checkout fits your product, check eligibility and create a product with Anyway. If your agent needs to buy APIs, evaluate the separate Agents workflow and its spending controls.
You might also like
How to monetize AI agents: choose a billable unit and calculate contribution margin.
How to monetize an API: connect API access to a paid offer.
SaaS payment webhooks: verify orders and grant access without duplicate delivery.